What documents and evidence do you need for a SOC 2 audit?

What are the two kinds of evidence a SOC 2 auditor asks for?

A SOC 2 auditor asks for two distinct things: documentation that shows how your controls are designed, and evidence that shows those controls actually operate. Documentation answers the question "what is your policy?" Operational evidence answers "can you prove you followed it?"

For a Type I report, the auditor mainly evaluates control design at a single point in time, so well-written policies and a system description carry much of the weight. For a Type II report, the auditor tests whether controls operated effectively across an observation period (commonly three to twelve months), so you must produce dated, ongoing evidence — tickets, logs, approvals, and reviews — sampled from throughout that window, not assembled the week before fieldwork.

Which documents do you need to prepare for a SOC 2 audit?

You need a core set of written documents that describe your system and your security program. These are the foundation auditors review before they test a single control. The most commonly requested documents are:

• A system description: the boundaries of the system in scope, including the services, infrastructure, software, data, and people it covers.
• Information security and acceptable-use policies, plus supporting policies for access control, change management, incident response, business continuity and disaster recovery, vendor management, and data classification and retention.
• A documented risk assessment showing how you identify, rate, and treat risks to the in-scope system.
• Asset and data inventories, including where in-scope data lives and how it is classified.
• A vendor or sub-service-organization list with the due diligence you perform on critical third parties (for example, reviewing their own SOC 2 reports).
• Organization charts and clearly assigned security roles and responsibilities.
• Network and data-flow diagrams that show how data moves through the system.
• Your selection of Trust Services Criteria: security is always in scope, with availability, confidentiality, processing integrity, and privacy added as relevant.

What operational evidence proves your controls actually work?

Operational evidence is the proof that your documented controls ran consistently during the audit period. This is where most of a Type II audit's effort goes, because the auditor samples records from across the observation window rather than accepting a policy at face value. Typical evidence requests include:

• Access management: user access lists, periodic access reviews, and records of approvals for new or changed access.
• Onboarding and offboarding: tickets showing access was granted on hire and revoked promptly on departure.
• Change management: pull requests, deployment tickets, and approvals showing changes were reviewed and authorized before release.
• Monitoring and logging: configuration of logging and alerting tools, plus samples of alerts and how they were triaged.
• Vulnerability and patch management: scan results, remediation records, and any penetration-test report.
• Backups and resilience: backup configurations and evidence of restore or recovery testing.
• Incident response: the incident register and records of any incidents, including how they were handled and closed.
• Security-awareness training: completion records for staff covering the period.
• Endpoint and infrastructure controls: evidence that encryption, multi-factor authentication, and endpoint protection are enforced.

How is evidence collected for Type I versus Type II?

Type I evidence captures a single point in time, while Type II evidence must span the entire observation period. For a Type I, the auditor confirms that controls exist and are suitably designed as of a chosen date, so a current set of policies, configurations, and screenshots is often enough.

For a Type II, the auditor needs to see the control operating repeatedly. If access reviews are quarterly, they will want each quarter's review from the period; if change approvals happen per release, they will sample releases across all the months in scope. Evidence assembled retroactively is a common audit failure, because gaps in the historical record cannot be back-filled. This is why mature programs automate evidence collection, using compliance platforms, ticketing systems, and identity tools that timestamp activity as it happens.

How do you organize and present evidence to the auditor?

Auditors work from a request list (often called a PBC, or "prepared by client," list), so the cleanest approach is to map each request to a named owner and a single source of truth. Disorganized evidence lengthens fieldwork and invites follow-up questions, while well-labelled, dated artifacts keep the audit short.

Practical steps that smooth the process include keeping a control-to-evidence matrix that links every control to the document or system that proves it, exporting evidence with clear dates and system names so the auditor can trace it, and resolving exceptions (such as a missed access review) before fieldwork rather than during it. Many organizations run a readiness assessment first to surface gaps and build the evidence habit before the formal audit period begins, turning the audit into a confirmation exercise rather than a scramble.