SOC 2 evidence collection: building an audit-ready library

What counts as SOC 2 evidence

SOC 2 evidence collection is the work of gathering the records that show your controls exist and, for a Type 2 report, that they actually ran throughout the period your auditor examines. Your system description and policies say what you do. Evidence proves you did it.

Evidence falls into two broad groups.

Policies and their approvals

Auditors want to see the policies that define your controls, and proof that each one was approved by the right person, communicated to the people it applies to, and reviewed on schedule. A policy document on its own is weak evidence. A policy with a named approver, an approval date, a version history and a record of who acknowledged it is much stronger. (For which policies you need in the first place, see Which policies do you need for SOC 2?)

Records that controls operated

This is the bulk of the work. Typical examples:

• Reviews: a quarterly user access review showing the systems checked, who reviewed them, and which accounts were removed or changed.
• Tickets: onboarding and offboarding requests, change requests, remediation tickets for vulnerabilities.
• Logs and system exports: alert configurations, deployment histories, user lists exported from your identity provider.
• Screenshots with dates: a configuration screen showing MFA enforced or backups enabled, with the date and the system visible in the capture.
• Meeting notes: management security reviews with an agenda, attendees and decisions.
• Training records: the training material and a completion roster.
• Reports from third parties: a penetration test report, or the SOC reports you collected from your own vendors.

Your auditor decides what format they accept. Some are happy with screenshots, others prefer system-generated exports or a live walkthrough. Ask early so you collect the right thing the first time.

How auditors sample evidence across the observation period

A Type 1 report looks at whether your controls are designed properly as of a single date. A Type 2 report looks at whether they operated effectively over an observation period, commonly 3 to 12 months (your auditor sets yours). The difference matters a lot for evidence. If you are still choosing, see SOC 2 Type 1 vs Type 2.

For a Type 2 audit, auditors rarely look at every record. Instead they work with populations and samples:

1. They ask you for the full population of a control's occurrences in the period: every person who joined or left, every production change, every quarterly access review, every monthly scan review.
2. They select a sample from that population.
3. They ask for the evidence for each sampled item and test it against the control as you described it.

The auditor decides the sample size, usually based on how often the control runs and how much risk it carries. You don't get to choose which items they pick. That has two practical consequences:

• Every occurrence needs evidence. You can't predict which month's scan review will be sampled, so every month needs a complete record.
• The population must be complete and believable. If a quarterly review is missing from your list, the auditor will notice the gap. A missed occurrence that is visible, with an explanation, is usually easier to discuss than one that appears to have been hidden.

What makes evidence hold up

Before you file something away, check it against these five qualities:

• Dated. The record shows when the control was performed, not only when the file was saved. An undated screenshot proves very little.
• Attributable. It shows who did the work and, where the control requires it, who reviewed or approved it. Initials in a spreadsheet are weaker than a named approval in a system that records the account.
• Complete. It covers everything the control says it covers. An access review that lists three of your five in-scope systems is a finding waiting to happen.
• Tied to a control and a period. Anyone looking at it can tell which control it supports and which quarter, month or year it belongs to.
• Retrievable. You can find it in minutes when the auditor asks, months after it was created.

A sixth quality is worth adding: evidence should be unaltered after sign-off. If a reviewer approved a document and someone edited it afterwards, the auditor needs to be able to tell what was approved.

Common control areas and example evidence

The table below is a starting point, not a complete list. Your control set, and what your auditor asks for, will shape the details.

Criteria references follow the 2017 Trust Services Criteria. Treat the mapping as a guide and confirm it with your auditor.

How to organize a SOC 2 evidence library

An evidence library is simply one agreed place where every record lives, arranged so that you and your auditor can find things without help. A few rules make it work.

Organize by control or activity, then by period

Pick one primary axis and stick to it. Most teams organize by recurring activity (User Access Review, Vulnerability Scan Review, Backup Restore Test) with one folder or page per period below it. Others organize by criterion. Activity-first tends to be easier for the people doing the work, and a separate index (a controls matrix) maps activities to criteria for the auditor.

Use a consistent naming convention

Name every record with the activity and the period, for example "User Access Review, 2026 Q3" or "Vulnerability Scan Review, September 2026". Consistent names make the population easy to list and gaps easy to spot.

Keep it in one place

Evidence scattered across email, chat, personal drives and three different tools is the most common reason fieldwork drags on. Link out to systems of record where you must (a ticket, a pull request), but keep the record of the control itself, with the links, in the library.

Restrict access

Some evidence is sensitive: user lists, vulnerability findings, who has or hasn't completed training. Limit the library to the people who run the program and the auditors, and give auditors read-only access.

Keep an index

A controls matrix that lists each criterion, the policies and activities that support it, and their current status lets you see coverage at a glance and gives the auditor a map of where to look.

Collect evidence as you go, not before fieldwork

The most expensive way to collect SOC 2 evidence is to start a few weeks before the auditor arrives. By then the access review that should have happened in March can't be recreated, screenshots taken today don't prove what was true six months ago, and the people who did the work may have moved on.

Instead, build evidence into the control itself:

1. Put every recurring control on a calendar with an owner and a due date. See The SOC 2 compliance calendar.
2. Create the evidence record when the period starts, with a checklist of what it must contain.
3. Have the owner fill it in while doing the work, then have a second person review and sign off.
4. Check monthly for anything overdue, and record a reason when a period is deliberately skipped.

Done this way, preparing for fieldwork is mostly a matter of pointing the auditor at the library.

Organizing SOC 2 evidence in Confluence with Compliance in a Box

If your team already works in Confluence Cloud, Compliance in a Box turns one Confluence space into the evidence library described above. Everything it produces is an ordinary Confluence page in your space.

• An evidence page for every period. Each recurring activity (user access review, vulnerability scan review, backup restore test and so on) has a schedule, an owner and approvers. Before each period is due, the app creates a dated evidence page under the activity page, named after the activity and the period, with a checklist of what to provide. The owner fills it in and attaches exports or screenshots.
• Version-bound approvals. The owner submits the evidence page for approval. The approval is tied to that exact page version and a fingerprint of its content, and editing the page before it is approved cancels the submission. Policies go through the same approval flow.
• Visible gaps. Missed periods show as overdue instead of disappearing, and a Compliance Admin can only skip a period with a written reason.
• Generated Evidence & Reports pages. The app builds a Policy Approval Log, a Policy Acknowledgement Report, an Activity Completion Report and monthly Audit Log pages from its records, refreshed daily or on demand. The reports link to the exact page versions that were approved and record which version each person acknowledged.
• A controls matrix. The Controls Matrix page lists each SOC 2 criterion in your selected categories with its mapped policies and activities, and marks it Covered, Attention or Gap.
• An append-only audit log. Every submission, approval, acknowledgement, skip and settings change is recorded, and entries can't be edited or deleted.
• Restricted access with an optional Auditors group. The report pages and the controls matrix are visible only to Compliance Admins, an optional Auditors group (view only) and the app. Auditors read and export them with Confluence's own export.

The app doesn't collect technical evidence from your other systems: you still attach the exports and screenshots yourself. What it does is keep the structure, the schedule, the sign-offs and the index in order. The Evidence, reports and audits chapter of the user guide covers the reports and auditor access, and Recurring activities covers evidence pages.

Frequently asked questions

How much evidence do I need for a SOC 2 audit?

Enough to support every control in your system description for the whole period in scope. The auditor decides how many items to test for each control, so plan to have complete evidence for every occurrence rather than guessing which ones will be sampled.

Are screenshots acceptable SOC 2 evidence?

Often, if they show the date, the system and the setting or record clearly. Some auditors prefer system-generated exports for certain controls. Ask yours which format they expect.

What if we missed a control occurrence during the observation period?

Don't backfill it with a record made after the fact. Document what happened, why, and what you changed, and discuss it with your auditor. How it is reported is the auditor's call.

Who should have access to the evidence library?

The people who run the compliance program, the owners of each control for their own records, and your auditors with read-only access. Sensitive reports, such as who hasn't completed training, should not be visible to everyone.

← All articles