What evidence does a SOC 2 auditor actually ask for?
A SOC 2 auditor asks for two kinds of thing: policies that say a control exists, and evidence that the control actually operated. For a startup with the Security criteria in scope that is roughly 28 items — about ten approved policies plus eighteen operational artefacts, of which access reviews, offboarding records, MFA enforcement settings, backup restore tests and vendor reviews are the most heavily tested.
The full list is below, with what satisfies each one.
Every founder preparing for a first SOC 2 hits the same wall. The framework is written as criteria, not as a list of files, so "implement logical access controls" tells you nothing about what to put in a folder. Then a request list arrives from the auditor and it turns out the answer was concrete all along.
This is that list. Twenty-eight items, grouped the way an audit actually works: ten policies, and eighteen pieces of proof that what the policies claim is really happening. It is the same catalogue SOC2Starter generates, which is where the specificity comes from.
Why an auditor asks for two different things
A SOC 2 examination tests two questions, and they need different artefacts.
Is there a control? That is what a policy answers. A document that says who may reach production, approved by someone with the authority to approve it, on a date.
Did the control operate? That is evidence. A quarterly access review with a date on it, an offboarding checklist showing the revocation actually happened, a restore test that someone genuinely ran.
A Type 1 report leans on the first. A Type 2 report lives on the second — it tests whether controls operated over a period, so a policy written the week before fieldwork proves very little. If you are unsure which you need, the difference is worth ten minutes.
The ten policies
Every one of these needs the same three things: an owner, an approval date, and a review date in the future. An unapproved draft is not a policy, and an auditor will say so.
| Policy | Priority | What proves it |
|---|---|---|
| Information Security Policy | High | Approved document with an approval date and an approver. |
| Access Control Policy | High | Approved access control policy. |
| Incident Response Policy | High | Approved policy and, ideally, one incident or tabletop write-up. |
| Password Management Policy | Medium | Approved policy plus your password manager settings. |
| Vendor Management Policy | Medium | Approved policy plus your vendor inventory. |
| Data Retention Policy | Medium | Approved retention policy and a deletion runbook. |
| Change Management Policy | Medium | Approved policy plus a sample of reviewed pull requests. |
| Security Awareness Policy | Medium | Approved policy plus training completion records. |
| Business Continuity Policy | Low | Approved BC/DR policy and your last restore test result. |
| Acceptable Use Policy | Low | Approved policy plus employee acknowledgements. |
The eighteen pieces of evidence
Priority here means what to do first if you are starting from nothing, not what an auditor cares least about. The high-priority items are the ones that are both heavily tested and slow to fix retroactively.
| Area | What the auditor asks for | What satisfies it | Priority |
|---|---|---|---|
| Security | MFA enforced on critical systems | Screenshot or export of the MFA enforcement setting in each identity provider — email, code hosting, cloud console, password manager. | High |
| Security | Annual risk assessment | A risk register with owners, ratings and a review date. | Medium |
| Security | Incident log | An incident log export — or a signed statement that there were no incidents this period. | Medium |
| Access control | Production access inventory | An export of IAM users and roles, or your cloud console member list. | High |
| Access control | Quarterly access review | A signed-off review showing the date, the reviewer, and the access that was removed. | High |
| Access control | Employee onboarding records | Completed onboarding checklists for recent hires. | Medium |
| Access control | Employee offboarding records | Completed offboarding checklists showing revocation dates. | High |
| Infrastructure | Backup configuration | A backup settings screenshot showing schedule and retention. | High |
| Infrastructure | Backup restore test | A restore test write-up: date, who ran it, what happened. | Medium |
| Infrastructure | Monitoring and alerting | Alert rule configuration, plus one example of an alert that actually fired. | Medium |
| Infrastructure | Vulnerability management | Scanner output, plus evidence that the findings were remediated. | High |
| Infrastructure | Encryption at rest and in transit | The database encryption setting and your TLS configuration or an SSL Labs report. | High |
| People | Security awareness training | A training completion report listing every current employee. | Medium |
| People | Confidentiality agreements | Signed agreements, or an HR report showing signature status. | Medium |
| People | Background checks | Completion records — not the reports themselves. | Low |
| Vendors | Vendor inventory | A vendor list with the data each handles, a risk rating and an owner. | Medium |
| Vendors | Annual vendor review | Review notes for each critical vendor, with a date and a reviewer. | Medium |
| Vendors | Vendor security documentation | Your vendors' own SOC 2 or ISO 27001 reports, or their security summaries. | Low |
The four requests that catch people out
The quarterly access review
Not a list of who has access — a record that somebody looked at the list, on a date, and made decisions. A screenshot of your IAM console proves the state of the world today. The review proves the control operates. You cannot reconstruct four quarters of these the week before fieldwork, which is why it is the single most common finding for startups.
Offboarding evidence
An auditor will take your list of leavers and check that access ended when employment did. This is one of the few places where a gap is objectively provable from timestamps, so it is one of the first things sampled. If somebody left in March and their GitHub account was disabled in June, that is a finding no policy can talk away.
The restore test
Backups configured is a setting. A restore test is an event: a date, a person, an outcome, ideally a note about what broke. Most teams have the first and have never done the second.
An incident log with nothing in it
Teams often skip this because nothing happened. An empty log is fine; a missing one is not. A signed statement saying there were no security incidents this period is a perfectly acceptable artefact — the control being tested is that you would have recorded one.
What evidence has to look like
Auditors reject artefacts for boring reasons far more often than substantive ones. In practice, evidence needs to be:
- Dated, and dated inside the audit period. An undated screenshot proves nothing about when the control operated.
- Attributable. Who ran the review, who approved the policy, who performed the test.
- Complete. A user list showing eight of your twelve accounts invites a question you do not want.
- Native where possible. A CSV export from the source system beats a photograph of a monitor.
- Reproducible. If the auditor asks how you produced it, the answer should be a procedure, not a memory.
Where to collect it from
Most of this list already exists inside tools you pay for. The access review comes out of Google Workspace, Okta or Microsoft 365. The production access inventory comes from AWS IAM. Branch protection and code review evidence comes from GitHub or GitLab. Pulling those on a schedule and filing them against the requirement they prove is exactly what SOC2Starter's twelve read-only connectors do, and it is the difference between a quarterly afternoon of screenshots and a button.
A sensible order to do this in
- Turn on MFA everywhere and capture the settings. Highest impact, lowest effort, and it is tested every time.
- Write and approve the four high-priority policies. Information Security, Access Control, Incident Response, and one of Change Management or Vendor Management depending on your risk.
- Start the evidence clock. Do the first access review now, even if it is imperfect, because a Type 2 needs a history and history only accumulates forwards.
- Fix offboarding. Make revocation part of the checklist, not part of somebody's memory.
- Run one restore test and write down what happened.
- Inventory your vendors and collect their reports. Slow, dull, and entirely parallelisable across the team.
Questions people ask
How much evidence does a SOC 2 audit need?
For a startup with the Security criteria in scope, expect roughly 28 distinct items: about ten approved policies and eighteen pieces of operational proof such as access reviews, offboarding records, backup restore tests, vulnerability scans and vendor reviews. The number of individual files is larger, because a Type 2 report samples recurring controls across the whole observation period rather than once.
What is the difference between a policy and evidence in SOC 2?
A policy states that a control exists and who owns it. Evidence proves the control actually operated. A Type 1 report tests mainly the first; a Type 2 report tests the second across an observation period, which is why policies written just before fieldwork carry little weight.
Can I create SOC 2 evidence retroactively?
Not for controls that are supposed to recur. An auditor tests whether a quarterly access review happened each quarter, and a review dated the week before fieldwork shows the control did not operate during the period. Point-in-time artefacts such as configuration settings can be captured at any time, but recurring evidence only accumulates forwards, which is the main argument for starting early.
What is the most common SOC 2 finding for startups?
Access management: quarterly reviews that were never performed, and offboarding where accounts outlived employment. Both are provable from timestamps, so they are sampled early and cannot be argued away after the fact.
Do I need a penetration test for SOC 2?
SOC 2 does not name a penetration test as a requirement. It expects a vulnerability management process, and most auditors accept a combination of automated scanning and evidence that findings get remediated. Many customers ask for a pen test separately in security questionnaires, which is usually the real reason startups buy one.
See this against your own company. SOC2Starter turns 19 questions into a personalised list of what you are missing, drafts the policies, and files the evidence against the requirement it proves. Fourteen days free, no card.