SOC 2 Type 2 Audit: What Happens During Fieldwork and How to Prepare

SOC 2 Type 2 is not a certification — it's an attestation. An independent auditor examines your controls over a defined period (typically 6-12 months) and opines on whether those controls were suitably designed and operating effectively. Understanding exactly what auditors look for, how evidence collection works, and what causes findings transforms a stressful audit into a predictable process.

SOC 2 Type 1 vs Type 2: The Core Difference

Type 1: Point-in-time assessment. The auditor evaluates whether your controls are suitably designed as of a specific date. It answers: "Did you have these controls in place on October 31st?"

Type 2: Period-of-time assessment. The auditor evaluates whether controls were operating effectively over the audit period — typically 6-12 months. It answers: "Did those controls actually work every day for the past year?"

Type 2 is what prospects and enterprise customers want. A Type 1 proves you set up controls once; a Type 2 proves you maintained them. Most enterprise procurement requirements and SOC 2 provisions in SaaS contracts require Type 2.

Selecting an Auditor

Only licensed CPA firms can issue SOC 2 reports (it's an AICPA attestation standard). When evaluating auditors:

Relevant criteria:

• AICPA membership: Verify the firm is an AICPA member firm and the lead auditor holds a CPA license in good standing
• Technology industry experience: Auditors who primarily audit banks or manufacturers will not understand your infrastructure. Look for firms that regularly audit SaaS, cloud, and software companies
• Report quality: Ask to see a sample redacted report. Is it detailed and specific, or filled with generic boilerplate?
• Use of shared questionnaires: Some firms automate heavily and use the same evidence requests for every client. This creates friction. Look for firms that tailor evidence requests to your actual environment
• Timeline commitments: Get a specific fieldwork start date and report delivery date in writing
• Ongoing relationship: You'll want the same auditor for subsequent years for continuity

Questions to ask prospective auditors:

• How many SOC 2 audits has your team conducted in the past 12 months?
• Who specifically will lead our audit, and what is their background?
• What is your process for handling new cloud service providers not in your standard checklist?
• How do you handle automated evidence (e.g., evidence pulled directly from Vanta, Drata, or your own tooling)?
• What are the most common findings you see in companies at our stage?

The Audit Timeline

A typical 12-month SOC 2 Type 2 audit follows this structure:

Month 1-2:   Readiness Assessment (optional but recommended for first-time)
Month 3-14:  Audit period begins (12 months of control operation)
Month 13:    Auditor sends initial evidence request list
Month 13-14: Evidence collection and auditor Q&A (fieldwork)
Month 14-15: Auditor drafts report and management responses
Month 15:    Report issued

For subsequent years with the same auditor and a rolling audit period, the timeline compresses significantly — often 6-8 weeks from fieldwork start to report issuance.

What Auditors Actually Test During Fieldwork

Auditors test controls across the five Trust Service Criteria (TSC): Security (CC), Availability (A), Processing Integrity (PI), Confidentiality (C), and Privacy (P). Security is required; the others are optional. Most SaaS companies include Security and Availability.

Evidence Types

Inquiry: The auditor interviews personnel to understand processes. These conversations are documented in the auditor's workpapers.

Observation: The auditor watches a process be performed — a new employee onboarding, a vulnerability scan run, an access review conducted.

Inspection: The auditor reviews documents, configurations, logs, and records. This is where most evidence collection happens.

Re-performance: The auditor independently re-runs a process to verify the control works (e.g., attempting to access a system without proper credentials to verify access controls reject the request).

What Gets Tested for Each Control

CC6.1 – Logical Access Controls

What auditors request:

• Complete list of users with access to production systems, compared to HR records
• User provisioning workflow documentation and tickets for new employees hired during the period
• Evidence that access reviews were performed (usually quarterly) — meeting minutes, screenshots, exported reports
• Screen recordings or screenshots of access approval workflows

What causes findings:

• Terminated employees with active accounts (very common — often 1-2 months of stale access)
• No documented access review for the period
• Service accounts with human-level privileges and no owner documentation
• Shared accounts (no individual accountability)

Sample evidence request:

CC6.1 Evidence Request:
1. Export of all active user accounts in AWS IAM, GitHub org, and production
   databases as of [audit end date]
2. HR termination report for the audit period
3. Access review reports for each quarter of the audit period, including
   reviewer name, date, and attestation
4. Ticket or approval workflow records for access provisioned during the period

CC7.1 – Vulnerability Management

What auditors request:

• Evidence that vulnerability scans were run on the defined cadence (e.g., weekly automated scans)
• Scan reports from throughout the period showing you actually reviewed results
• Vulnerability tracking records showing mean time to remediation (MTTR) for critical findings
• Patch management policy and evidence of patching

What causes findings:

• Scans were run but findings were not reviewed or tracked
• Critical vulnerabilities unpatched for more than your stated SLA (often 30 days)
• Scan scope doesn't cover all production systems
• Infrastructure as Code changes not scanned before deployment

CC6.6 – Network Security / Boundary Protection

What auditors request:

• Network architecture diagram
• Firewall ruleset review evidence (who reviewed it and when)
• Penetration test report from the period (or evidence of continuous testing)
• IDS/IPS configuration and alert evidence

CC9.2 – Third-Party Risk Management

What auditors request:

• Vendor inventory with criticality classification
• Evidence of vendor security reviews (security questionnaires, SOC 2 reports from key vendors)
• Contracts with security requirements for critical vendors
• Evidence that vendor security reviews are performed at least annually

This is frequently an area of weakness — companies list vendors in their inventory but have no evidence of actual review.

A1.2 – Availability / Recovery Testing

What auditors request:

• Disaster recovery plan
• Evidence that a DR test or tabletop exercise was conducted during the audit period
• Backup execution logs (showing backups actually ran on schedule)
• Evidence of at least one backup restore test

Common Findings and How to Prevent Them

Terminated employee access: Run an automated comparison of your identity provider (Okta, Azure AD) against your HR system weekly. Any account active for more than 24 hours after termination should trigger a ticket. This is the single most common finding across all SOC 2 audits.

Access review not documented: Conducting a review without evidence is the same as not conducting it. Use your IAM tool's export function or a compliance platform to generate timestamped, exportable review records. The auditor needs to see who reviewed what on what date.

Vulnerability exceptions without approval: If a critical vulnerability cannot be patched within your stated SLA, document the exception: the vulnerability, the risk, the compensating control, the approver, and the planned remediation date. Undocumented exceptions become findings; documented exceptions with compensating controls typically do not.

Training not completed: Annual security training with no evidence that it was completed during the audit period is a finding. Export completion records from your LMS with dates and the user list.

How the Report Is Structured

A SOC 2 Type 2 report has five sections:

Section 1: Independent Service Auditor's Report — The auditor's formal opinion. The opinion can be: Unqualified (clean), Qualified (controls exist but had exceptions), Adverse (controls did not work), or Disclaimer (auditor couldn't complete the work).

Section 2: Management's Assertion — Management's statement that the controls were suitably designed and operating effectively.

Section 3: System Description — Your company's description of the service being audited, the infrastructure, data flows, and control environment. You write this section.

Section 4: Trust Service Criteria, Controls, and Tests — The main body. For each control, this section lists: the control description, the auditor's test procedures, the sample size tested, and the result (no exceptions noted, or exceptions noted with description).

Section 5: Other Information (optional) — Includes management's responses to any findings.

When sharing the report with prospects, you may share the full report (all sections) or a "bridge letter" between report periods. Some companies only share Section 1 (the opinion) for competitive reasons, but most enterprise security reviews require at least Sections 1 and 4.

Management Response to Findings

If the auditor identifies exceptions, you have the opportunity to include a management response in Section 5. A good management response:

• Acknowledges the finding factually without minimizing it
• Explains what happened (root cause)
• Describes the corrective action taken and the date it was completed
• Does not argue with the auditor's finding

Management Response to Exception in CC6.1:

During the audit period, one terminated employee's account in the
GitHub organization remained active for 18 days past their termination date
due to a gap in our manual offboarding checklist.

Corrective action: As of [date], we have integrated our HR system (BambooHR)
with our SSO provider (Okta) via automated provisioning/deprovisioning.
Termination events in HR now automatically trigger account suspension within
4 hours. We completed validation testing of this integration on [date].

A finding with a clear, credible remediation response is far less damaging to a prospect's evaluation than a finding with a weak or defensive response.