Audience
What evidence should exist for controls, releases, and formal reviews?
Security reviewers, audit stakeholders, and release owners.
Security Evidence
Controls auditors usually ask about.
| Area | What to evidence |
|---|---|
| Access | RBAC roles, MFA/passkey posture, API token scope, webhook secrets, collector enrollment, and support access. |
| Secrets | Non-default NETBOX_INGESTER_SECRET_KEY, license secret, database password, SMTP/SES credentials, reCAPTCHA secret, source credentials, and rotation evidence. |
| Encryption | TLS termination, database/storage encryption, optional Vault transit configuration, token lifecycle, backup separation, and FIPS module evidence when in scope. |
| Release | Commit SHA, immutable image tags, image digests, CI status, dependency/SAST/secret/image scan artifacts, runtime-contract validation, and post-deploy smoke results. |
| Data collection | Source inventory, source owner, business purpose, service-account permissions, active-scan authorization, data categories, review records, and retention policy. |
Audit Reports
Expected evidence reports.
For a formal review, prepare a scoped audit binder rather than one generic product statement. The binder should include the deployment scope, architecture/data flow, release evidence, hosting controls, tenant/data/collector controls, vulnerability management, continuity evidence, supplier evidence, and open gaps.
Published policy documents
Use the live public-host policy pages when a reviewer asks for privacy, data protection, GDPR, supplier, or regulated-readiness material that should stay customer-safe.
VeridataOps is designed to support ISO/IEC 27001, FIPS-aligned, and PCI DSS-aligned deployments when paired with the appropriate hosting controls, encryption boundary, retention policy, access model, and audit evidence process.
Next Step
Move from documentation to a scoped review.
Use the implementation reviewer path when you want to turn this page into a concrete source, deployment, or assurance discussion.