The hardest part of a SOC 2 audit is not understanding the criteria — it is producing the evidence that your controls actually operated. This guide walks through the evidence auditors typically ask for, control area by control area, so you can build a clean evidence room instead of scrambling during fieldwork.
How SOC 2 evidence works
A SOC 2 report is an auditor’s opinion on whether your controls are designed well (Type I) and operating effectively over a period (Type II). For Type II, the auditor samples evidence across your observation window. That means evidence must show a control working repeatedly over time — not a single snapshot. A screenshot from the day before fieldwork proves nothing about the prior three months.
Good evidence has three qualities:
- Sufficient — it actually demonstrates the control happened.
- Time-stamped and attributable — it shows when and by whom.
- Repeatable — it exists across the window, not just once.
Access control
Controls here cover who can access what, and proof that access is least-privilege and reviewed.
- User access listings from your IdP, cloud console, and key apps
- MFA enforcement configuration and reports
- Periodic access reviews — the review itself, who performed it, what changed, and when
- Privileged access records showing admin rights are limited and justified
Auditors love access reviews because they prove the control runs on a cadence. Keep the review artefact, not just the current state.
Onboarding and offboarding
- New-hire provisioning tickets showing access granted per role
- Termination/offboarding records showing access revoked promptly after departure
- A sample reconciliation between HR’s leaver list and actual access removal
Offboarding is one of the most common findings. Tie revocation to your HR system so it is automatic and evidenced.
Change management
- Pull requests / change tickets showing code and infrastructure changes
- Evidence of peer review / approval before merge or deploy
- CI/CD logs linking the change to a deployment
- Separation between who writes and who approves/deploys where feasible
Vulnerability and patch management
- Scan reports on a regular cadence
- Remediation tracking showing issues triaged and fixed within SLA
- Patch records for systems and dependencies
Logging and monitoring
- Configuration showing centralised logging is enabled
- Alerting rules and evidence that alerts route to a responder
- Sample alerts and their resolution across the window
Incident response
- A documented, version-controlled incident response plan
- Evidence of a tabletop exercise or a real incident handled per the plan
- Post-incident reviews with action items closed
Even if you had no real incidents, run a tabletop — auditors want proof the plan is more than a document.
Risk assessment
- An annual risk assessment with identified risks, owners, and treatments
- Evidence that the assessment fed into your controls and roadmap
Vendor and sub-processor management
- A current vendor inventory with risk tiers
- Security reviews for material vendors (their SOC 2, ISO cert, or questionnaire)
- Evidence of periodic re-review of critical vendors
Backup and disaster recovery (Availability)
- Backup configuration and success logs
- Evidence of a restore test — the strongest proof backups actually work
- A DR / business continuity plan and any test results
Encryption
- Configuration showing encryption in transit (TLS) and at rest
- Key management practices
HR and security awareness
- Policy acknowledgements from staff
- Security awareness training completion records
- Background check evidence where applicable
The evidence cadence cheat sheet
Map each control to how often it produces evidence so nothing is missing at fieldwork:
- Continuous: logging, MFA enforcement, encryption config, change reviews
- On event: onboarding, offboarding, incidents, vendor onboarding
- Periodic (monthly/quarterly): access reviews, vulnerability scans, alert reviews
- Annual: risk assessment, DR test, policy reviews, training
Avoiding screenshot fatigue
The single biggest reason SOC 2 feels painful is manual evidence collection — engineers taking screenshots they will redo at the next audit. The fix is to collect evidence automatically and continuously from the systems of record (cloud, IdP, code host, ticketing) so the evidence room fills itself across the observation window.
When you collect continuously, you also get an early warning: if a control stops producing evidence — say access reviews lapse — you find out in week two, not during fieldwork.
For the broader playbook on scoping and timelines, see our companion article on SOC 2 for Indian SaaS. And if you also process personal data of people in India, much of this same evidence supports your DPDP obligations — run them together.
Build the evidence room once
Comply connects to your stack with no-code connectors, collects SOC 2 evidence continuously, and scores its quality so gaps surface early — then maps the same controls to DPDP so one evidence set serves multiple frameworks. See how it works on the platform page, explore the SOC 2 framework, and review transparent pricing to plan your audit.