SOC2 Evidence Auto-Collection

SOC2 audits demand evidence. Auto-collect it.

Audit logs

SOC 2 audits live or die on evidence. The auditor asks "do you have a control for X" and the team has minutes to produce evidence that satisfies the request. Teams that scramble during the audit produce thin evidence and weak reports; teams that have been collecting evidence continuously produce comprehensive packets and clean reports. The discipline is automated evidence collection, not annual scrambling.

What audit log evidence collection requires:

• Auto-retained logs across systems.: Every system that produces audit-relevant logs (cloud provider, identity provider, source control, CI, deploy pipeline, application audit logs) has retention configured to satisfy SOC 2 requirements. Typically 12 months minimum, with the most critical logs retained longer.
• Per-control mapping documented.: Each SOC 2 control has a documented mapping to specific log sources that satisfy it. CC6.1 (logical access) maps to IDP login logs and IAM audit logs. CC8.1 (change management) maps to deploy events and PR history. The mapping is reviewable; the auditor can trace from control to evidence in seconds.
• Auditors verify, not interpret.: When the auditor pulls a sample, the evidence should answer their question directly. "Show me 10 random user logins from last quarter" produces a clean log query and a clean answer. Auditors that have to piece together evidence from disparate sources rate the control lower.
• Tamper-evident retention.: Logs go to storage that cannot be modified after the fact. Append-only buckets with versioning and object-lock. The integrity is the property that makes the evidence admissible; logs that could have been modified are weaker evidence.
• Pre-staged for the audit.: The week before the audit, the team pre-runs the standard queries the auditor will ask. The evidence is in a folder ready to share. The audit proceeds in days rather than weeks because the evidence is ready when the questions arrive.

Audit log discipline is the foundation of SOC 2 evidence. Teams without it spend the audit scrambling; teams with it spend the audit answering questions calmly.

Change records

The other large evidence category is change management. Every change to production systems needs evidence: who proposed it, who approved it, what it changed, when it deployed. SOC 2 controls CC7.1, CC8.1, and several others depend on this evidence directly.

• PR history is the change record.: Every code change goes through a pull request. The PR has the proposer, the reviewer, the approval, the merge timestamp, the diff. The git history is the audit trail; SOC 2 controls map to it directly.
• Deploys are change events.: Every production deploy is logged with the artifact, the commit, the deployer, the environment, the timestamp. The deploy log links to the PR that produced the artifact. The chain from "engineer proposed change" to "change is in production" is queryable.
• Documented in version control.: Configuration changes (Terraform, Kubernetes manifests, IAM policies) live in version control. The same PR-and-merge process applies. The same evidence is produced. The auditor sees one consistent change-management story across code and config.
• Out-of-band changes are exceptions.: Sometimes a change happens outside the normal process (emergency hotfix, manual intervention during incident). These exceptions are documented at the time, with rationale, approver, and follow-up to bring the change back into the normal process. Auditors expect exceptions; they expect them documented.
• Multi-quarter history.: The change record is retained for the SOC 2 attestation period (typically 12 months) plus enough buffer for the next attestation. Auditors sample from across the period, not just the most recent quarter.

Change records done right require no audit-time scrambling. The PR history, the deploy log, and the config version control already produced the evidence as part of normal operation.

Review records

The third evidence category is the periodic reviews SOC 2 requires. Access reviews, vendor reviews, risk assessments, security training completion. Each review is a periodic event with documented inputs, outputs, and approvals.

• Access reviews quarterly.: Every quarter, managers confirm their team's current access is appropriate. The review pulls a list of bindings, sends to managers, captures their approvals. The output is a record of what was reviewed, who approved, what was changed. Auditors sample the records.
• Vendor reviews annually.: Every third-party vendor with access to production data gets reviewed annually. The review covers their SOC 2 attestation, their data handling, the access they have, whether the access is still needed. The output is a structured record per vendor.
• Risk assessments annually.: An annual risk assessment identifies the company's primary risks, the controls that mitigate them, and any gaps. The output is a document; the document is signed by leadership. Auditors verify it exists and is current.
• Training records.: Annual security awareness training, secure coding training for engineers, role-specific training for sensitive functions. Each completion is recorded with the user, the training, the date, the score if applicable. Auditors sample to verify completion rates.
• Documented as evidence packets.: Each review produces a packet: the inputs (the list of items reviewed), the activities (who reviewed, what they decided), the outputs (what changed). The packets are filed by quarter or by year, ready for audit sampling.

SOC 2 evidence collection is the ongoing discipline that makes the audit a routine event rather than a fire drill. Nova AI Ops automates the evidence collection across the major SOC 2 control categories (audit logs, change records, periodic reviews), produces audit-ready packets per control, and tracks the freshness of each piece of evidence so the team can see at a glance whether the audit will go smoothly or require last-minute scrambling.