A SOC 2 audit document request list is the spreadsheet your auditor will send once fieldwork starts, and it is usually the moment your compliance program stops being theoretical. The Trust Services Criteria look tidy on a slide, but Type I and Type II reports live or die on whether you can hand over the right evidence, in the right format, on the right date. Miss a few artifacts and the auditor writes exceptions. Chase them badly and your engineering team resents you for a quarter.
This guide gives you a full SOC 2 audit document request list you can copy today, organized the way most auditors actually ask for evidence. It covers the five Trust Services Criteria, the difference between Type I and Type II populations, and the workflow that keeps requests moving without a hundred email threads.
What goes in a SOC 2 audit document request list
The list is a structured inventory of the evidence an auditor needs to test controls against the Trust Services Criteria: Security (mandatory), Availability, Processing Integrity, Confidentiality, and Privacy. A workable list has four columns:
- Control reference. Which control the evidence maps to (CC1.1, CC7.2, A1.2, and so on).
- Requested artifact. The specific document, screenshot, export, or ticket the auditor wants.
- Period covered. For Type II, the exact window the sample must fall within.
- Status. Requested, uploaded, under review, accepted, or exception.
The mistake most first-time auditees make is treating the list as one big folder of files. Auditors sample. If you upload a year of change tickets as one PDF, they will still ask for the five specific tickets that fall inside their sample window. Build the list so every request can be answered with a discrete artifact.
Type I vs Type II: what changes in the request list
The document request list looks similar in both cases, but the evidence you need to produce is very different.
Type I is a point-in-time review. The auditor confirms that your controls are designed correctly on a specific date. Expect requests for policies, org charts, vendor lists, system diagrams, and a single instance of each control operating (one access review, one deployment ticket, one incident response run).
Type II covers a period, usually 3, 6, or 12 months. The auditor tests whether the controls operated effectively throughout that window. Expect population lists (all hires, all terminations, all deployments in the period) plus samples pulled from each population. The document request list balloons because every recurring control needs evidence for every occurrence the sample selects.
Set expectations with your team early: a Type II is not a paperwork drill at the end of the year. It is a full period of evidence-generating routines you need to keep clean as you go.
The master SOC 2 audit document request list (copy this)
Below is a working baseline that mirrors what a Big Four or mid-market auditor typically requests. Adapt it to your scope and the criteria you selected. If you use a shared workspace or a client portal, structure it as one folder per section so nothing lands in the wrong place.
Company and governance (CC1)
- Certificate of incorporation and organizational chart
- Board or leadership meeting minutes for the audit period
- Ethics and code of conduct policy, with signed acknowledgments
- Whistleblower and grievance policy, with any reports filed
- Roles and responsibilities documentation for the compliance function
- List of active employees and contractors as of the period end
- Background check policy and evidence of checks on new hires
Risk assessment (CC3)
- Enterprise risk assessment (most recent version, with methodology)
- Risk register with owners, likelihood, impact, and mitigation status
- Vendor risk assessment procedure and completed vendor scorecards
- Fraud risk analysis, if applicable
- Evidence that risks were reviewed at the required cadence (usually annual)
- Change-in-scope analysis for any new products or entities
Communication and training (CC2)
- Security awareness training curriculum
- Completion records for all employees in the audit period
- Onboarding checklist showing security training assigned at hire
- Internal communication samples (all-hands slides, wiki pages) on security topics
- External communication policy (public status page, customer notifications)
Access control (CC6)
- Access control policy and role definitions
- User access list for each in-scope system (production, cloud console, code repo, ticketing, HRIS)
- Quarterly or semi-annual access review evidence for each in-scope system
- Joiner, mover, leaver tickets for a sample of hires, role changes, and terminations
- Privileged access review evidence
- Password and MFA policy with configuration screenshots
- SSO configuration and identity provider settings
- Terminated user list from HRIS matched to deprovisioning tickets
- Physical access logs and badge audits if you operate offices or data centers
Change management (CC8)
- Change management policy and workflow diagram
- Sample of production change tickets with approvals, code review, test evidence, and deployment logs
- CI/CD pipeline configuration screenshots
- Emergency change procedure and any invoked emergency changes in the period
- Rollback records for failed deployments
- Segregation of duties evidence between developers and deployers
System operations (CC7)
- Monitoring and alerting policy
- Sample of production alerts and how they were resolved
- Vulnerability scan reports for the audit period
- Penetration test report and remediation plan
- Patch management policy and evidence of patch cycles
- Anti-malware or endpoint protection reports
- Incident response plan and tabletop exercise results
- Sample of incident tickets with timelines, root cause, and corrective actions
Risk mitigation and vendors (CC9)
- Vendor inventory, tiered by risk
- Signed contracts and DPAs for critical vendors
- Vendor SOC 2 or ISO 27001 reports, or subservice organization letters
- Vendor onboarding and offboarding evidence
- Business continuity plan and last test result
- Cyber insurance certificate
Availability (A1)
- Availability commitments and SLA documentation
- Capacity monitoring dashboards and thresholds
- Backup policy, backup logs, and restore test evidence
- Disaster recovery plan and last DR test result
- Uptime reports for the audit period
- Redundancy diagrams for critical infrastructure
Confidentiality (C1)
- Data classification policy
- Encryption policy with configuration evidence (at rest and in transit)
- Key management procedures and rotation logs
- Confidentiality clauses in customer and vendor contracts
- Data retention and disposal policy, plus evidence of scheduled disposals
Processing integrity (PI1)
- Data flow diagrams for in-scope processes
- Input validation and reconciliation controls
- Error handling and rejection queue evidence
- Sample of processed transactions with expected vs actual outcomes
- Change logs for processing rules or business logic
Privacy (P1–P8)
- Privacy policy (public and internal)
- Data subject request procedure and log of requests handled
- Consent capture evidence for applicable jurisdictions
- Records of processing activities (ROPA)
- Cross-border transfer safeguards (SCCs, adequacy decisions)
- Privacy impact assessments for new products or vendors
Industry-specific additions
Auditors adjust the request list based on how you deliver your service.
SaaS platforms. Expect deep requests around cloud console access (AWS, GCP, Azure), IaC repos, secrets management, tenant isolation evidence, and application-level logging.
Fintech and payments. Add reconciliation controls, transaction integrity samples, KYC and AML procedures, and evidence of segregation of environments handling cardholder data. Cross-reference to your PCI DSS scope where applicable.
Healthtech. Add HIPAA overlays: BAAs with subprocessors, PHI access logs, breach notification procedures, and evidence of minimum necessary access.
AI and ML products. Expect requests for model change logs, training data provenance, human review sample evidence, and controls around prompt or output handling if you process customer content.
Managed services or agencies. Add client acceptance procedures, engagement letters, and evidence of confidentiality controls when handling multiple client tenants.
How auditors want the evidence delivered
Read the fine print in the engagement letter. Most firms accept evidence through a shared drive or their own audit portal, but they all impose the same practical rules:
- File naming. “CC6.1_UserAccessReview_2026Q1.pdf” beats “screenshot.png”. Auditors process hundreds of files a week and will fail to match a poorly named one to your control.
- Populations before samples. Never send only the sampled items. Send the full population (all deployments, all hires) and let the auditor sample from it. Otherwise they will suspect you cherry-picked.
- Screenshots with timestamps and URLs visible. A screenshot without a browser URL bar or a visible date proves nothing.
- No PII in production evidence. Redact customer names, payment details, and PHI before uploading. If the auditor needs unredacted data, share it through a secure channel.
- One artifact per request, not a zip of everything. Zips slow the reviewer and create back-and-forth about missing files.
Running the list without email chaos
The document request list is a project management problem more than a compliance problem. Small teams try to run it in a shared spreadsheet with a folder tree next to it. That works until three auditors, five engineers, and one CTO all edit the same row at the same time.
A better setup:
- A single source of truth. One list, one owner, one status per row. The auditor pulls from the same view your team updates.
- A structured intake for each request. The engineer uploading the evidence should see the exact request, the period covered, and the expected file format, without opening a Google Doc from three months ago.
- Automated reminders. Every open request needs a nudge on a schedule so nothing sits at “requested” for two weeks. Manually chasing 200 items is how audits blow through deadlines. Read our guide to automated document reminders for the reminder cadence that works.
- Approval and re-upload flow. If the auditor rejects an artifact, the engineer needs to know why and what to send instead, without a new email thread.
- A clean handoff at year end. Your list should be exportable so next year’s auditor starts from the same structure, and so leadership sees status without reading emails.
Superdocu was built for this exact shape of work. You define the SOC 2 request list once as a workflow, invite the internal owners as contacts, and each one gets a branded portal that shows only their open items. Uploads get reviewed, rejected artifacts come back with a comment, reminders fire automatically, and everything exports as an organized ZIP for the auditor at the end. It is the same pattern that works for KYC document collection and vendor risk reviews, applied to audit evidence.
SOC 2 audit prep timeline
A realistic timeline for a first Type II, working backward from the report delivery date:
- T-12 months. Scope the report, select criteria, pick an auditor, and fix the audit period.
- T-9 months. Complete a readiness assessment. Write missing policies, close gaps, and turn on the recurring controls (access reviews, change reviews, backups tests).
- T-6 months. Begin operating all controls at the required cadence. This is your evidence-generation window.
- T-3 months. Dry-run the document request list. Pull the artifacts you would deliver if fieldwork started tomorrow.
- T-0. Fieldwork begins. Deliver evidence on the schedule the auditor sends. Turn around exceptions within days, not weeks.
If you are inside three months and the request list still scares you, focus on the recurring populations first (access, change, incident). Auditors care more about a working recurring control than a perfect policy document.
Common exceptions and how to avoid them
Auditors write the same handful of exceptions across most first-time SOC 2 engagements:
- Access reviews performed late or not signed off. Set a calendar cadence and require an approver signature on the export.
- Terminated users still active in a system. Match the HRIS termination list to the access list of every in-scope system on the last day of every month.
- Change tickets without evidence of code review or testing. Enforce required reviewers and test attachments in the ticket template.
- Missing vendor SOC reports or DPAs. Track vendor documents with expiration dates and start renewal requests 60 days before they expire. This is exactly the pattern we cover in our document expiration tracking guide.
- Incident response tickets without post-mortems. Require a written post-mortem for every incident above a set severity.
Every one of these is a workflow fix, not a policy fix.
Frequently asked questions
What is a SOC 2 audit document request list?
A SOC 2 audit document request list is the itemized list of policies, screenshots, exports, tickets, and reports an auditor asks for to test your controls against the Trust Services Criteria. It is usually delivered as a spreadsheet at the start of fieldwork and drives most of the day-to-day audit work.
How many documents does a SOC 2 audit request?
A Type I typically requests 60 to 120 discrete artifacts, and a Type II covering 6 to 12 months usually runs 200 to 500 items once populations and samples are counted. The number depends on your scope, the criteria in scope, and how much your systems produce automatically.
What is the difference between a SOC 2 Type I and Type II document request list?
Type I focuses on control design at a point in time and needs one instance of each control operating. Type II covers a period and needs the full population of events plus samples for every recurring control, which multiplies the request count.
How long should we keep SOC 2 audit evidence?
Most firms keep audit evidence for at least seven years to cover regulatory retention and to hand it to future auditors. Store it in a system that tracks who uploaded what and when, not a shared drive that anyone can edit.
Can we automate SOC 2 evidence collection?
Yes. Recurring evidence (access reviews, change tickets, backup logs) can be pulled automatically from your source systems, and the human-in-the-loop items (policy signoffs, vendor forms, screenshots) can be collected through a structured request workflow. Automating just the reminder and approval loop typically saves the most time.
Ready to run your next SOC 2 audit without an inbox full of “Bumping this” replies? Start a free 7-day trial of Superdocu and build your audit request list as a reusable workflow. No credit card required.