Pillar deep dive

Chain-of-Custody Evidence for SOC 2: The Audit-Defensible Pattern

The structured evidence pattern that satisfies modern SOC 2 auditors: who ran the check, when, from what system, with what input, producing what output, retained where, accessible to whom.

By Hemant Attri, Founder, Attri Edge Updated July 14, 2026 1 min read

Audit-defensible evidence has six attributes. Most companies satisfy two of them. Here’s the full pattern we implement — the second Attri Edge pillar, and the answer to why auditors are rejecting screenshots.

The six attributes of audit-defensible evidence

Every piece of strong evidence answers: (1) who ran the check, (2) when, (3) from what system, (4) with what input, (5) producing what output, and (6) retained where, accessible to whom. Screenshots typically satisfy only “what output” — and weakly. Hit all six and the evidence holds.

Implementation per control area

  • Access control: export the access list from the IdP via a scheduled job; capture the run, the operator, and the timestamp.
  • Encryption: export the config/KMS state directly, not a console screenshot.
  • Vulnerability remediation: the scan-ticket-fix-rescan chain from the remediation pillar.
  • Change management: pull the change record (PR, approval, deploy) from the source system.

The principle is constant: produce direct system output through a documented procedure.

Evidence repository architecture

One controlled repository (not personal drives), organized by control, with raw outputs and their metadata. The GRC platform can reference or store automated evidence; manually produced evidence lands here first so you keep the source of truth.

Access controls on evidence itself

Evidence is sensitive. Apply least privilege to who can create and view it, prefer append-only/immutable storage, and log access. Auditors may test the controls on your evidence, not just the evidence itself.

Retention policies

Define a retention schedule by evidence type (audit period plus your policy’s tail, often 1–7 years), automate disposal at end-of-life, and log deletions. Retention is a control too — it ties into the data-retention discipline in the DPDPA cross-mapping playbook.

Where Attri Edge fits

Designing the evidence architecture and running the collection cadence is core to the Active Retainer. The diagnostic scores your current evidence against the six attributes.

Related reading:

Frequently asked questions

How long must evidence be retained?
At least the full audit period plus the report's useful life — commonly the observation window plus one to seven years depending on your retention policy and any regulatory overlay. Define it in a retention schedule and apply it consistently.
Can evidence live in the GRC platform?
Yes for connected, automated evidence. For manually produced evidence, store the raw output in a controlled repository (with the platform referencing it) so you retain the source, not just a platform rendering.
What about evidence access permissions?
Restrict who can create, view, and (ideally never) alter evidence. Access to the evidence repository is itself a control auditors may test — least privilege and access logging apply to evidence as much as to production.
Common chain-of-custody failures?
Missing timestamps, no owner attribution, editable formats, and evidence stored in personal drives. Each breaks the chain. The fix is a defined procedure, a controlled repository, and direct system output.