Reference
The SOC 2 evidence checklist
Your auditor will send a PBC list: Provided By Client. For a small AWS-native SaaS company it commonly runs 60 to 120 line items. Fieldwork goes quickly or slowly depending almost entirely on whether those items were assembled before the request arrived. Here is what is on the list and where each artifact comes from.
Get your auditor's actual request list before you start collecting. Every firm structures theirs differently, grouped by criterion, by control, or by testing session. Collecting evidence into your own structure and then remapping it into theirs is the most common avoidable week of work in the whole engagement.
The shape of a request list
Each row typically carries a request number, the control or criterion it supports, a description of the artifact, the period it must cover, an owner, and a status. Requests fall into four kinds, and the kinds behave very differently:
| Kind | Example | Difficulty |
|---|---|---|
| Configuration | "Screenshot or export of the S3 account-level public access block settings" | Easy. Generate on demand from AWS |
| Document | "Approved information security policy with evidence of approval" | Easy if it exists, weeks if it does not |
| Population | "Complete list of employees hired during the period" | Deceptively hard. Completeness is the thing being tested |
| Sample | "For 15 selected terminations, evidence access was removed within one business day" | Hardest. The auditor picks; you cannot curate |
The order matters. The auditor asks for the population first, then selects the sample from it. If your population is wrong, everything downstream is wrong, and a population found to be incomplete is a finding in its own right.
AWS technical evidence, control by control
| Control | What the auditor asks for | Where it comes from |
|---|---|---|
| C1 Logging | Trail configuration showing organization-wide coverage, multi-region, log file validation, plus sample log entries | CloudTrail console or describe-trails, plus the archive bucket configuration showing Object Lock and retention |
| C2 Threat detection | GuardDuty enabled in all accounts and regions, delegated administrator configured, plus the findings triage workflow | GuardDuty console in the delegated admin account; a sample finding with the response taken |
| C3 Configuration monitoring | AWS Config recorder status and rule compliance summary | Config console. Note that a recorder with no rules attached will not satisfy this |
| C4 Storage exposure | Account-level Block Public Access settings, plus a full bucket inventory with per-bucket settings | S3 console account settings, plus an export listing every bucket |
| C5 Encryption at rest | Inventory of EBS volumes, RDS instances, and S3 buckets showing encryption status, plus the account default settings | EC2, RDS, and S3 consoles or the CLI. Any unencrypted resource needs an explanation |
| C6 Encryption in transit | TLS policy on load balancers and CloudFront distributions | ELB and CloudFront configurations, plus a scan of public endpoints |
| C7 Network logging | Flow log configuration on production VPCs, with destination and retention | VPC console |
| C8 Alerting | Alert routing configuration, plus sample alerts and the responses to them | EventBridge rules and the destination channel. The response is the part usually missing |
| C9 Backup and recovery | Backup plan configuration and at least one documented restore test with date and outcome | AWS Backup, plus your own written restore test record |
| C10 Vulnerability management | Scanner configuration, recent scan results, and remediation records showing your stated cadence held | Amazon Inspector and ECR scanning, plus your ticket system |
| C11 Network exposure | Security group listing showing no unrestricted access to management ports, plus a register for documented exceptions | EC2 console or describe-security-groups |
| C12 Environment separation | Documentation of account and VPC structure and how production access differs from development | Your architecture documentation, plus Organizations structure |
Identity and access evidence
| Control | What the auditor asks for | Notes |
|---|---|---|
| B1 SSO | Identity provider configuration and an application inventory showing which systems federate to it | The gaps are always the tools someone signed up for with a shared login |
| B2 MFA | Enforcement settings on the identity provider, AWS, and source control, plus a coverage report | The report must show zero exempt users, or an approved exception for each |
| B3 Least privilege | IAM credential report, list of principals with administrative access, password policy, evidence root is not in routine use | Root MFA and no root access keys are asked for essentially every time |
| B4 Access reviews | The completed review for every period in the window: who reviewed, when, what changed as a result | A review with no removals and no sign-off reads as a rubber stamp |
| B5 Offboarding | The complete termination population, then per sampled leaver, evidence of removal within the stated SLA | Timestamps are the evidence. "We remove access promptly" is not |
| B6 Secrets | Repository scan results and an inventory of the managed secret store | Historical secrets in git history come up more often than teams expect |
Process and governance evidence
This is the half that AWS cannot generate for you, and it is where first-time teams lose weeks.
| Area | Artifact | The part that gets missed |
|---|---|---|
| Policies | Each approved policy with version history and evidence of approval | Who approved it and on what date. A document with no approval trail is a draft |
| Policy acknowledgement | Acknowledgement records for every person | Contractors and part-time staff with system access |
| Risk assessment | Risk register with identified risks, ratings, and treatment decisions | Evidence it was actually performed in the period, not inherited from last year |
| Training | Completion records against the full personnel population | People who joined mid-period and were never enrolled |
| Vendor management | Vendor register, and review records for vendors with data access | The subprocessor list, and whether you collected their SOC 2 reports |
| Oversight | Notes from leadership security reviews showing security topics discussed | Having no board is not a gap. Having no record of oversight is |
| Change management | Complete population of production changes, then evidence of review for the sample | Emergency changes and anything deployed outside the pipeline |
| Incidents | Incident records and postmortems, or a documented attestation of none | "We had no incidents" still needs a statement and a definition of incident |
| Tabletop exercise | Exercise notes and follow-up actions | The follow-ups. An exercise with no findings looks like it did not happen |
| Personnel | Complete lists of joiners and leavers in the period | Completeness. This population drives the samples for several other controls |
IPE: the concept that catches people out
Information Produced by the Entity is any report, export, or list you generate and hand over. Because you produced it, the auditor cannot simply accept it; they have to be satisfied it is complete and accurate. So they will ask:
- What system did this come from?
- What query, filter, or date range produced it?
- Who ran it and when?
- How do we know nothing was excluded?
Capturing that context at the moment of export costs seconds. Reconstructing it three months later, for forty exports, costs days. Take the screenshot with the filter visible. Save the CLI command next to its output. Name files with the date they were generated.
Five evidence mistakes that extend fieldwork
- Collecting into your own structure instead of the auditor's. Get their request list first and organize to it directly.
- Screenshots with no context. No timestamp, no account identifier, no visible filter. The auditor cannot tell what they are looking at, so they ask again.
- Incomplete populations. A termination list missing a contractor is not a small error; it undermines every sample drawn from it.
- Evidence that contradicts your own policy. The policy says quarterly, the records show twice a year. The control failed the moment it was written, not when it was tested.
- Nobody owns the response. Requests land in a shared inbox, drift for a week, and fieldwork stretches from days into a month. One named owner with a tracker fixes it.
Frequently asked questions
What is a PBC list?
Provided By Client (sometimes Prepared By Client): the itemized list of evidence the auditor asks you to hand over, usually a spreadsheet or portal with one row per request. A first-year list for a small AWS SaaS company commonly runs 60 to 120 items.
What evidence does a SOC 2 auditor need from AWS?
Configuration exports and screenshots showing each control is in place: CloudTrail configuration, GuardDuty settings with delegated administrator, AWS Config rule compliance, S3 public access block, IAM credential report, security group listings, encryption inventories, VPC flow log configuration, and backup plans with a documented restore test. The full mapping is in the table above.
What is IPE?
Information Produced by the Entity: any report or export you generate and hand to the auditor. They must be satisfied it is complete and accurate, so they ask about the source system, the query, and who ran it. Capture that at export time.
How far back does evidence need to go?
A Type 1 shows the state as of a single date. A Type 2 must cover the entire observation window, with samples drawn across it. Process evidence such as access reviews and offboarding records cannot be produced retroactively for a window that has already passed.
Can a compliance platform collect all of this automatically?
A good portion of it, for the systems it integrates with. The gaps are consistent: tools with no integration, anything requiring human judgment or a signature, and any population where completeness is the point. Those become manual evidence for the full window, and they are worth identifying on day one rather than in fieldwork.
Have the evidence ready before the request list arrives
We build the evidence repository during readiness, organized to your auditor's actual request list, with the source and query captured for every export. By the time fieldwork starts, the answers are already assembled.
Book a 30-minute scoping callEvidence organized to your auditor's exact request list when they are in our partner network, and to standard SOC 2 conventions otherwise, remapped when they share theirs.