SOC 2 CC6.1 and secrets: the evidence auditors ask for, and what you can produce
Short answer: for secrets, CC6.1 evidence boils down to being able to show an inventory of your non-human credentials with owners, who and what can access them, how they are protected and rotated, and a log of changes. Most teams fail on the first item: there is no register, so the population can't even be produced. This page lists what auditors commonly ask for, and says exactly what Dynv gives you today and what it doesn't. We are not auditors and Dynv is not "SOC 2 compliant": it can help you produce some evidence.
Read this first. SOC 2 is an attestation about your organisation’s controls, issued by a licensed auditor. No tool makes you compliant. What follows is a practical engineering view built from published criteria summaries and practitioner checklists; ask your own auditor which evidence they accept, in what format, and for which period.
What CC6.1 says
CC6.1 is one of the Security (“common criteria”) requirements in the AICPA’s Trust Services Criteria. As quoted in a practitioner checklist that reproduces the AICPA text: “The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity’s objectives.” The AICPA’s published points of focus break that into items; two matter most for secrets: manages credentials for infrastructure and software and protects encryption keys. We read the points of focus and example evidence from Iden’s CC6 evidence checklist, a third-party document that says it quotes the AICPA’s 2017 criteria (with revised points of focus, 2022) verbatim; it is not the AICPA itself, so check the primary text.
The two items that matter for secrets
From that checklist (our paraphrase, with its stated auditor tests):
- Credentials for infrastructure and software. Evidence: a register of non-human identities (service accounts, API keys, CI credentials, integration users, agents and MCP servers), with owner, purpose, scope and creation date for each, plus evidence that credentials are removed when the software is no longer in use. The auditor samples non-human credentials and asks who owns each and what removed the last one you retired. The listed common exception: “There is no register at all, so the population cannot be produced and the control cannot be tested.”
- Protecting encryption keys. Evidence: a key management procedure covering generation, storage, use and destruction, plus who can export or delete a key.
The same checklist notes how auditors work: they ask for the full population of an event first and then sample from it, and every artefact needs the source system, extraction date, reporting period, who pulled it, and a stable file name. An export nobody can reproduce is not evidence.
What Dynv can produce today (tested)
We ran these on 2026-11-01 against a local server with two services, tokens, a description on a variable, a rotation and some changes. Output shortened; names are fake.
A register of services, variables and tokens, with labels:
$ dynv admin ls
api v4 gen 1 [REyQZWRv5aKHXnhf]
DB_PASSWORD (Restart)
STRIPE_KEY (Restart)
token -nZv4U3YOs7OeNJY live "prod-api-2026-11"
worker v4 gen 1 [_GpEpZAYLH-3MVUL]
DB_PASSWORD (Restart)
token TdVbchtNh8u9cAzh live "prod-worker-2026-11"An owner and purpose per variable, stored in the object’s encrypted notes (not sent to deployments):
$ dynv admin describe api DB_PASSWORD
Primary database login; owner: platform team; rotated quarterlyRotation records, one job per rotation:
$ dynv rotate status
Ol1H_DehMBKWoa34 done DB_PASSWORD 2/2 writes generatedA change log with the action, actor, token label and source IP (timestamps are epoch milliseconds):
$ dynv admin audit --limit 12
1793540416952 rotation.job.done ok actor=initial process= ...
1793540416836 env.update ok actor=initial process=api ...
1793540416632 token.create ok actor=initial process=worker token=prod-worker-2026-11 ...Evidence on the vulnerability side: dynv vulns and dynv vulns events show what is installed in running services (how), and the process firewall and canaries have their own event feeds.
The protection model itself: names and values are encrypted on the client with AES-256-GCM, with ciphertext-only storage on the server, signed documents and token-scoped access (security model, what zero-knowledge means). That describes a design; an auditor will want your configuration and procedures, not our documentation.
What Dynv does not give you yet
Be clear-eyed about the gaps, because these are what an auditor will probe:
- No evidence export. The audit log is a CLI and dashboard view. Audit log export, a year of retention and compliance-evidence packages are listed as planned on our pricing page, not available. You must capture and date the output yourself.
- The register is thin. The token listing has a label and a status, but no creation date, owner or scope column. Put the owner in the label or in the variable description, and keep your own inventory sheet.
- Human access evidence. Teams are opt-in and give roles per workspace. SCIM, per-service grants, custom roles, change requests and two-person rules are planned; SSO is coming soon. Evidence of who has access to what is therefore limited today, and the security page notes that invited members can read every secret in an account.
- Zero-knowledge means we cannot run reports on your secrets. Anything that depends on knowing names or values runs on your machines.
- Dynv’s own SOC 2 status is not something this page asserts. Ask us for current reports rather than relying on a blog post.
A checklist you can adapt
- Inventory every non-human credential: system, owner, purpose, scope, creation date, location(s), rotation interval. Reconcile it against what each tool shows.
- Remove what is unused and keep proof (a dated log line or ticket).
- Rotate on a schedule and after events; keep each rotation record and the date (rotation).
- Restrict and review access: who can read, write and mint tokens; review quarterly; keep the review record.
- Protect the keys: where the master or recovery credentials are stored, who can use them, how they are recovered.
- Monitor and respond: vulnerability reports and alerts, and a record of how you handled a critical finding (playbook).
- Capture evidence with provenance: for each export, the source, date, period and who pulled it.
Limits
- This is not legal, audit or compliance advice and not an AICPA reproduction. Criteria wording and points of focus are as summarised by the linked third-party checklist.
- We tested Dynv’s CLI commands on a small local account; real accounts will have more objects, and the formats may change.
Facts last verified . Spotted an error? Tell us.