The 7 Documents Your Auditor Actually Needs (And How to Generate Them)

If you ask a GRC platform like Drata or Vanta what you need for a SOC 2 audit, they will generate 25+ policy templates for you. If you ask an auditor what they actually need to see, the list is much shorter, much specific, and much harder to fake.

SOC 2 audits require evidence, precise documentation, and verified screenshots that prove your controls are operating effectively. While policies set the rules, auditors spend 90% of their time verifying the artifacts that prove you followed those rules.

Most teams over-prepare on policies (which auditors barely skim) and under-prepare on the operational evidence (which auditors scrutinize). This guide covers the 7 specific document types your auditor will actually request in their Provided by Client (PBC) list, and how to generate them without losing a week of engineering time.

What Do SOC 2 Auditors Actually Read?

There is a massive difference between "Design of Controls" (your policies) and "Operating Effectiveness" (your evidence).

For a Type I audit, the auditor checks if your policies exist and if the system is designed correctly. For a Type II audit—the one enterprise customers actually care about—the auditor needs proof that you followed those policies over a 6-12 month period.

They do not read every word of your Information Security Policy. They do inspect the timestamp on a screenshot showing that you revoked access for a terminated employee within 24 hours.

Here are the 7 documents that matter.

1. The System Description (Management Assertion)

This is the narrative backbone of your SOC 2 report. It is a 15-30 page document that describes your infrastructure, software, people, and processes. It’s the "story" of your company that the auditor is verifying.

What it includes:

• Overview of services provided
• Principal service commitments (SLAs, uptime promises)
• System components (Infrastructure, Software, People, Procedures, Data)
• Boundaries of the system (what is in scope vs. out of scope)

How to generate it:

• Manual: You have to write this. GRC tools provide a skeleton template, but you must fill in the specific architectural details.
• Automation: None. This requires human judgment.
• Auditor Expectation: Accuracy. If you say you use AWS Inspector for vulnerability scanning in the description, but the evidence shows you use Tenable, you have a deviation.

2. The "Populations" Lists (The PBC Core)

This is usually the first thing an auditor asks for when fieldwork begins. They cannot test everything, so they ask for the "universe" of events to pick a sample from.

What it includes:

• Population of New Hires: List of every employee hired during the audit period.
• Population of Terminations: List of every employee who left.
• Population of Changes: List of every code change deployed to production.
• Population of Incidents: List of security incidents (hopefully empty or short).

How to generate it:

• Manual: Export CSVs from your HRIS (Rippling/Gusto) and version control (GitHub/GitLab).
• Automation: GRC tools can sometimes sync these lists, but auditors often prefer raw exports directly from the source system to prove completeness.
• Auditor Expectation: Completeness. If they find a hire on LinkedIn who isn't on your New Hire Population list, the audit halts until the discrepancy is explained.

3. The Sample Evidence Packs

Once the auditor has your populations, they will select a random sample (usually 5-25 items per population) and ask for detailed evidence for those specific items.

What it includes:

• New Hire Sample: For "John Doe," show the background check result, the signed offer letter, and the screenshot of their laptop encryption setup.
• Change Management Sample: For "Pull Request #402," show the screenshot of the peer review approval, the CI/CD build success log, and the deployment timestamp.
• Access Revocation Sample: For "Jane Smith," show the screenshot of her access being removed from AWS, GitHub, and Slack, with timestamps matching her termination date.

How to generate it:

• Manual: This is the biggest time sink in SOC 2. You have to manually search for old tickets, take screenshots, and paste them into Word documents.
• Automation: This is where Screenata handles the full workflow. Instead of manually hunting for evidence, Screenata's AI Compliance Officer can look up the specific PRs or user events requested by the auditor, capture the screenshots automatically, generate policies, and compile everything into a PDF evidence pack.
• Auditor Expectation: Context. A screenshot of a PR list isn't enough; they need to see the approval button clicked and the timestamp.

4. The User Access Review (UAR) Logs

Control CC6.1 requires you to periodically review who has access to your systems.

What it includes:

• A spreadsheet or report showing every user with access to critical systems (AWS, production DB, GitHub).
• Evidence that a manager reviewed this list.
• Evidence that access was removed for anyone who didn't need it.

How to generate it:

• Manual: Export user lists from every system into a spreadsheet. Add a column for "Manager Decision" (Keep/Remove). Have managers sign off.
• Automation: Tools like Drata and Vanta have built-in UAR workflows that pull these lists via API. However, for internal admin panels or tools without APIs, you still need to screenshot the user list manually to prove the API didn't miss anything.

5. The Risk Assessment (CC3.1)

You must identify risks to your business and score them based on likelihood and impact.

What it includes:

• A register of potential threats (e.g., "AWS region goes down," "Laptop stolen," "Insider threat").
• A score for each (Likelihood × Impact = Risk Score).
• A mitigation plan for high risks.

How to generate it:

• Manual: Excel template.
• Automation: Most GRC platforms include a Risk Assessment module that lets you click through standard risks. This is usually sufficient for auditors.

6. The Vendor Risk Management Packet (CC9.2)

You are responsible for the security of the tools you use.

What it includes:

• List of critical vendors (AWS, Slack, GRC tool, Payroll).
• Evidence that you reviewed their SOC 2 reports or security questionnaires.
• Analysis of their "Complementary User Entity Controls" (CUECs)—basically, checking if you are doing what their SOC 2 report says you should do (e.g., turning on MFA).

How to generate it:

• Manual: Email vendors asking for their SOC 2 report. Read it. Note any concerns.
• Automation: Some platforms offer "Trust Centers" to exchange these, but the actual review often requires human eyes or an AI agent to parse the CUECs.

7. The Penetration Test Report (CC4.1)

You cannot automate a penetration test with a scanner. You need a human (or a specialized firm) to try to break into your app.

What it includes:

• A report from a reputable third-party firm.
• List of vulnerabilities found.
• Crucially: Evidence that you fixed the critical/high issues found in the report.

How to generate it:

• Manual: Hire a firm (Cobalt, HackerOne, or a boutique firm).
• Automation: None. Automated vulnerability scanners (like AWS Inspector) satisfy a different control (CC4.2), not the penetration test requirement.

Where Traditional SOC 2 Automation Stops

GRC platforms like Drata and Vanta are excellent at generating policies (#2), running the Risk Assessment (#5), and pulling Populations (#2) for supported integrations.

However, they struggle with #3: The Sample Evidence Packs.

APIs can tell you that "PR #402 was merged," but auditors often demand visual proof—a screenshot showing the actual UI state, the comments, or the specific error message configuration in a custom internal tool.

This "evidence gap" is where teams lose weeks of engineering time. You end up with a GRC tool that says you are "100% Ready," but you still have to manually collect hundreds of screenshots for the auditor's sample list.

How to close the gap:

1. Use Screenata as your AI Compliance Officer: Screenata handles the full compliance workflow—policy writing, evidence collection, control mapping, and audit prep. For teams starting fresh, this replaces the need for a separate GRC platform.
2. If you already use Drata/Vanta: Screenata integrates with your existing stack and captures the visual evidence (screenshots of PRs, onboarding flows, admin panels) that APIs miss.
3. Write the System Description yourself: Don't outsource the narrative; nobody knows your architecture better than your CTO.

Learn More About SOC 2 for Bootstrapped Founders

For a complete guide to navigating the audit process without overspending, see our Bootstrapped Founder's Guide to SOC 2, which breaks down costs, timelines, and trade-offs in detail.