SOC 2 Evidence Collection: What Auditors Expect from SaaS Companies

In this article

1. What Do SOC 2 Auditors Actually Expect as Evidence?
2. What Makes SOC 2 Evidence Good Evidence?
3. What Evidence Do Auditors Request for Each Control Area?
4. How Do Populations and Sampling Work in a Type 2 Examination?
5. Should SaaS Teams Collect Evidence Manually or Automatically?
6. A Practical SOC 2 Evidence Collection Process
7. Five Evidence Mistakes That Cause Audit Delays
8. How AnnexOps Helps With SOC 2 Evidence Collection
9. Ready to Get Your SOC 2 Evidence Under Control?
10. Related Reading
11. Ready to Get Your SOC 2 Evidence Under Control?
12. Author: Nitin Grover

SOC 2 auditors expect evidence that each in-scope control was designed appropriately and, in a Type 2 examination, that it operated throughout the observation period. For a SaaS company, that means system-generated records relevant to the control, complete for the period, and traceable to a date, an owner, and a criterion. Screenshots taken the week before fieldwork rarely meet that bar.

This guide is part of our SOC 2 readiness guide for SaaS companies. It explains what a CPA firm typically asks for, how sampling works, which evidence to collect for each control area, and how engineering teams can build collection into the stack they already run.

30 minutes. We map your SOC 2 scope and show where your evidence has gaps.

What Do SOC 2 Auditors Actually Expect as Evidence?

A SOC 2 report is the result of an examination by an independent CPA firm under the AICPA attestation standards. The CPA tests whether your controls are suitably designed and, for Type 2, whether they operated effectively. The tests rely on evidence, gathered through the usual audit procedures: inquiry, observation, inspection of records, and re-performance.

A policy shows what you intend to do. Evidence shows what happened. Auditors therefore look for records that show a control operating on real events, such as an access approval, a reviewed pull request or a restored backup. The CPA decides what is sufficient, so agree on the expectations early. Our guide to SOC 2 readiness covers scope and report type.

What Makes SOC 2 Evidence Good Evidence?

Useful evidence passes five checks:

• Relevant: it shows the control working, not just that a tool exists.
• Complete: it covers the whole population, for example, every production deployment in the period.
• Traceable: it links to a control, a criterion, a date, and a named owner.
• In period: for Type 2, it comes from across the observation window, not from the last week.
• Trustworthy: it comes from the source system and has not been edited by hand.

Auditors also test the reports you give them. Any list or export produced from your systems, such as a user list or a deployment log, must be shown to be complete and accurate. Pull it from the system of record, keep the query or export settings, and avoid rebuilding it in a spreadsheet.

A good evidence record usually carries these fields:

Field	Why the auditor cares
Control and criterion	Shows what the record proves
Source system and export date	Supports completeness and accuracy
Period covered	Matches the observation window
Owner and reviewer	Shows accountability
Approval or outcome	Shows the control operated, not just that it existed

What Evidence Do Auditors Request for Each Control Area?

Requests vary by CPA firm and scope. This table shows typical requests for a SaaS stack. The mapped criteria are indicative and depend on your own control design.

Control area	Typical request	Where it usually lives	Criteria
User provisioning and removal	List of joiners and leavers in the period, access tickets, removal timestamps	Identity provider, HR system, ticketing	CC6
Periodic access review	Review records with reviewer sign-off and follow-up on removals	Access review register, tickets	CC6
Change management	Population of production changes, pull request approvals, test results, deployment logs	Git, CI/CD, ticketing	CC8.1
Monitoring and vulnerabilities	Scan reports, alert triage, remediation tracking	Scanner, SIEM, ticketing	CC7
Incident response	Incident register, investigation and post-incident review records	Incident tool, ticketing	CC7
Vendor oversight	Vendor inventory, risk assessments, supplier assurance reports and their review	Vendor register, shared drive	CC9
Backup and recovery	Backup job records, restore test results, recovery plan	Cloud console, runbooks	Availability
Governance and people	Risk assessment, policy approvals, security training completion, background checks	GRC tool, HR system	CC1 to CC5

If your suppliers include AI vendors, see our guide to AI vendor and third-party risk management for what to ask them.

How Do Populations and Sampling Work in a Type 2 Examination?

For controls that operate repeatedly, the CPA does not review every event. The auditor asks for the full population for the period, selects a sample and tests each item in it. Sample sizes depend on the CPA firm and on how often the control operates, so do not plan around a fixed number.

Three consequences matter for your team:

• The population must be complete. If your deployment export misses emergency changes, every sampled gap becomes an exception.
• Every sampled item needs its own proof. One approval ticket per change, not a general statement that changes are approved.
• Exceptions are reported. A deviation found in testing appears in the CPA’s results, and its effect on the opinion depends on its nature and severity. Find and fix gaps during the period, and tell your CPA about them early.

Your Type 2 observation window should therefore be treated as a live evidence timeline, not an archive you assemble afterwards.

Should SaaS Teams Collect Evidence Manually or Automatically?

Manual collection works for a first look at Type 1. It breaks down in a Type 2, when the same control must be evidenced month after month by several teams.

Engineering teams get better results when evidence is a by-product of systems they already run:

• Pull configuration and activity records from the identity provider, source control, CI/CD, and cloud accounts with read-only access.
• Store each record with its control, criterion, source, and timestamp.
• Keep records tamper-evident, so you can show they were not edited after the fact.
• Replace screenshots with exports, logs, and tickets that carry context.

Automation does not replace judgement. A tool can show that multi-factor authentication is enforced, but an access review still needs a person to review, decide, and sign. Automated checks find gaps. Owners fix them.

A Practical SOC 2 Evidence Collection Process

1. Map controls to criteria and owners. Start with the control mapping for your in-scope Trust Services Criteria, and name one accountable owner per control.
2. Define the evidence for each control. Record the source system, the format, the frequency, and the retention period.
3. Set a cadence. Group controls as continuous, monthly, quarterly or annual, and schedule collection to match.
4. Capture at the source. Collect from the system of record and tag each item with its control and date.
5. Review monthly for gaps. Check populations for completeness, chase missing approvals, and log remediation while the period is still open.
6. Prepare the CPA package. Hand over population exports and supporting records by control and period, with scoped read-only access where possible.

Five Evidence Mistakes That Cause Audit Delays

1. Screenshots without context. A screenshot shows a screen, not who approved what and when. Keep the underlying record.
2. Evidence created after the period. Records produced afterward for a control that didn’t run at the time will not support the control.
3. Access reviews without follow-up. A review that finds a leaver with access and never removes it is an exception, not evidence.
4. Changes outside the pipeline. Emergency and hotfix changes still need approval records and must appear in the change population.
5. Different populations in different tools. If the spreadsheet and the system export disagree, the auditor will ask why. Use one source of truth.

How AnnexOps Helps With SOC 2 Evidence Collection

AnnexOps is built so that evidence collection is part of your normal operations, not a quarterly scramble.

• Evidence collection: read-only, metadata-based, and hash-chained, so records are traceable and tamper-evident.
• Automated control checks: 743 checks, graded, with gaps surfaced for owners.
• Access and vendor reviews: registers for CC6, CC7, and CC9 activities.
• Type 2 window tracker: evidence organised against your observation period.
• CPA Audit Room: read-only, time-boxed access scoped to one framework.
• Control mapping: 154 controls with a crosswalk, so existing ISO 27001 work can count where it fits.

AnnexOps does not issue SOC 2 reports or replace the CPA’s examination. Coverage percentages are indicative and are not a prediction of an audit outcome.

Ready to Get Your SOC 2 Evidence Under Control?

Evidence is where SOC 2 projects stall: too many tools, too many owners, and too little time before fieldwork. AnnexOps turns it into a continuous, read-only process, so your engineers keep shipping and your CPA gets organised records.

• Collect once: read-only, hash-chained evidence, mapped to the criteria you scoped.
• See gaps early: 743 graded checks show where controls or records are missing while your Type 2 window is still open.
• Hand over cleanly: a read-only, time-boxed CPA Audit Room scoped to one framework.

Book a 30-minute SOC 2 Expert Call. We map your scope and show where your evidence has gaps across the criteria you need.

Related Reading

• SOC 2 Readiness for SaaS Companies: Scope, Controls and Audit Preparation
• SOC 2 compliance automation
• ISO 27001 compliance automation
• AI Vendor & Third-Party Risk Management Software for EU AI Act Compliance
• SOC 2 Access Controls: Managing User Access, Reviews and Audit Evidence 
• SOC 2 Vendor Risk Management: How to Assess and Monitor Third-Party Providers

Author: Nitin Grover

Nitin Grover is an AI compliance strategist and writer focused on EU AI Act compliance, AI governance, Annex IV documentation, AI risk management, and AI compliance operations for AI startups, SaaS companies, and enterprise AI teams across Europe.