SOC 2 evidence
SOC 2 auditors ask for architecture evidence in a recognizable shape. In Drata’s control framework the requests are DCF-21 (the current architectural diagram plus evidence it was updated or reviewed within the past year) and DCF-22 (the same for the network diagram), and Drata’s own guidance names “confirmation from responsible personnel” as an acceptable form of review evidence. Other GRC platforms and audit firms phrase the same requests differently; the artifacts they want are the same two diagrams, current and reviewed.
The mapping
| The auditor asks | Zindex evidence |
|---|---|
| The current diagram | The scene at its latest revision, rendered with a watermark carrying scene id, revision, and date |
| Evidence it was reviewed | A dated attestation by a named workspace member - the “confirmation from responsible personnel” form, with an identity and a timestamp attached |
| Evidence it is kept current | The revision history: every change immutable, timestamped, and attributed, with approvals recorded where the review loop produced the revision |
| What changed during the period | The structural diff between any two revisions, and a changelog in every evidence pack |
| The diagram as of a past date | Point-in-time access: any date in the audit period resolves to the exact revision, and the export reproduces byte-identical packs |
| How the diagram relates to the environment | Source lineage: derive-created revisions record the schema snapshot’s SHA-256, computed by the server at derivation time |
The compliance checklist in the dashboard tracks this per framework: bind a scene to each evidence slot and the slot shows its live readiness - attestation freshness, protection, and legal hold.
The boundary
Two claims are deliberately not made, because they would not survive an auditor’s scrutiny and do not need to be made for the evidence to be useful.
The provenance history documents the evidence, not your change management. A revision chain shows that the diagram was controlled: who changed it, who approved the change, when. An auditor testing change-management controls (CC8.1-class operating effectiveness) works from your underlying change records - pull requests, tickets, deployment logs. Revision messages and proposal links can point the auditor at those records; they do not replace them.
A diagram is evidence of what management approved, not proof of what is deployed. Auditors corroborate architecture evidence against the environment it describes. Source lineage helps them do that - a derive-created revision carries the fingerprint of the schema it was computed from, so “does this match production?” becomes a hash comparison rather than a walkthrough - but the corroboration is theirs to perform.
Practical setup
- Keep one long-lived scene per evidence artifact (architecture diagram, network diagram). Never recreate them; the revision history is the record.
- Turn on protection so every change lands through a human approval, and legal hold so retention never trims the history an audit relies on.
- Attest each scene quarterly from the audit view - comfortably inside the annual review window the DCF-21/22-class requests ask about.
- Bind the scenes to their slots on the compliance page.
- At audit time, export the evidence pack for the period, or hand the auditor packs pinned to specific dates with
?asOf=.