How to prepare audit evidence for SOC 2: an engineer's guide

SOC 2 evidence is the documentation and system records proving your security controls existed and operated during the audit period. Preparing it well comes down to three moves: map each control to the system that evidences it, collect that evidence continuously rather than quarterly, and make the records trustworthy enough that an auditor can rely on them. This guide covers all three from the engineering side.

The audience is the technical lead a few months out from a first audit, staring at an evidence request list that seems to want everything the company has ever done. It is more tractable than it looks, and most of the pain is self-inflicted by treating evidence as something you gather at the end rather than something your systems produce as they run.

What counts as evidence in a SOC 2 audit?

Audit evidence is the set of records an auditor examines to conclude that your controls were suitably designed and operated effectively: documents, system-generated records, configurations, and the outputs of the controls themselves.

Evidence takes three broad shapes. Configurations and screenshots capture how something is set: the MFA policy, the firewall rule, the S3 bucket permissions. Documents capture what you committed to: policies, procedures, risk assessments, vendor reviews. System records capture what actually happened: audit logs, access reviews, deployment records, tickets, alerts. The first two are gathered; the third is generated, and it is where audits are won or lost.

The Type 1 versus Type 2 distinction determines how much the third category matters. A Type 1 report assesses whether controls were suitably designed at a point in time. A Type 2 report assesses whether they operated effectively across a period, commonly three to twelve months, and it is the report your customers will actually ask for. Type 2 is what makes record-keeping the hard part: a control that ran for eleven months but has records for nine is, to an auditor, a control with a two-month hole in it, and holes cannot be backfilled honestly after the fact.

What evidence do auditors actually request?

Auditors request evidence per control, grouped by the Trust Services Criteria areas, and the requests are more predictable than first-timers expect. A realistic tour of the recurring items:

Access control (the CC6 series). User access reviews with sign-off, showing each system's accounts were reviewed and exceptions acted on. Provisioning records tying each new account to an approval. Deprovisioning records showing leavers lost access promptly, with the leaver list cross-checked against HR. MFA configuration and its enforcement. Privileged access lists and the justification for each entry. The deprovisioning cross-check is a perennial finding: the auditor samples leavers and asks for the timestamped removal record, and "we definitely did it" is not a record.

Change management (CC8). Evidence that changes were reviewed, approved, and tested before production: pull request approvals, CI results, deployment logs tying the deploy to the approved change. Auditors sample changes from the period and walk each one end to end, so the chain from ticket to approval to deploy needs to be reconstructable for any given change, not just describable in general.

Incident response (CC7). Incident tickets with timelines, severity, and resolution; post-incident reviews for the significant ones; evidence the response procedure was followed rather than improvised. If you had no incidents, expect to evidence that monitoring existed and would have caught one.

Monitoring and logging (CC7). Alert configurations, samples of alerts firing and being handled, and audit logs from the systems in scope. The logs themselves get sampled: the auditor picks events and asks who did this, when, and how do you know this record is accurate.

The pattern across all four areas: auditors sample, then trace. They rarely read everything; they pick items from the period and follow each one through your records. Evidence preparation is therefore about traceability per item, not volume in aggregate.

How to collect evidence without a fire drill

Continuous collection beats the quarterly scramble on every axis: less effort, fewer gaps, better evidence. The method is unglamorous. For each control, decide the single system of record that evidences it, and write the mapping down: access reviews live in this tool, change approvals are pull requests in this repo, incidents are tickets in this project, admin actions are in this audit log. Ambiguity about where evidence lives is how gaps happen, because everyone assumes another system caught it.

Then automate the exports. Anything that requires a human to remember monthly will develop holes; anything scheduled will not. Timestamp everything at generation, in UTC, from synchronised clocks, because evidence with vague or conflicting times invites exactly the scepticism you are trying to avoid. Assign an owner per control, since evidence without an owner is evidence nobody notices has stopped.

A word on compliance automation platforms, because most first-time SOC 2 journeys involve one. They are genuinely good at the workflow: mapping controls, chasing tasks, integrating with your stack to pull configurations, and keeping the programme organised. Use one if it helps. Be clear-eyed about what they collect, though: ordinary records from ordinary systems. The platform proves collection happened; it does not make the underlying records more trustworthy than the systems that produced them. That question, the reliability of the records themselves, is a separate one.

Can your evidence survive scrutiny?

The uncomfortable question underneath all evidence preparation is whether the records could have been altered, because most of them could. The access review lives in a spreadsheet anyone can edit. The audit log is a database table the application, and every administrator, can UPDATE. Screenshots prove a moment and are trivially remade. For most first audits this passes, because auditors work within the norms of what organisations can produce. The norms are shifting, and for period-based controls the better auditors have started asking the sharper question: how do you know these records are the records?

Tamper-evident evidence is evidence stored such that any alteration after the fact is detectable, typically through append-only storage, cryptographic hash chains linking each record to its predecessor, and digital signatures sealing batches of records.

The escalation ladder for record integrity runs from restricted write permissions, through write-once storage, to cryptographic tamper-evidence, and each rung strengthens what you can claim. The top rung changes the conversation with an auditor in kind rather than degree: instead of describing controls that should have prevented edits, you hand over records whose integrity can be checked by computation. This is the problem Sigilbase exists to solve: applications write audit events into hash-chained, checkpoint-sealed streams, and evidence exports verify offline with an open-source verifier, so an auditor can confirm for themselves that nothing was modified, deleted, or reordered, without taking anyone's word for it, including ours.

You do not need the top rung for every record in a first audit. You do need to know which of your evidence sources would survive the sharper question, because the systems that evidence your most sensitive controls, admin actions, access changes, production data access, are exactly where it will land first.

A 90-day preparation plan

Ninety days is enough runway for a first Type 2 audit if the period is already underway and the controls broadly exist. The plan, deliberately boring:

The single highest-value hour in the whole plan is the dry run: pick a control, sample five items from the period, and trace each to its records as a stranger would. Whatever you cannot trace, the auditor will not be able to either, and you have just found it first.

The mindset that makes audits cheap

Companies that find SOC 2 painful treat evidence as a deliverable assembled before the audit. Companies that find it routine treat evidence as a property of how their systems run: actions produce records, records are owned, protected, and traceable, and the audit becomes an export rather than a project. Every improvement above, systems of record, automation, integrity protection, moves you from the first category to the second, and each is worth having even if no auditor ever asked.

Primary sources: the AICPA Trust Services Criteria define what auditors assess. For the logging side in depth, including what SOC 2, ISO 27001 and PCI DSS each require from audit logs, see our companion guide to audit log requirements.