SOC 2 Compliance Documentation: What Your Auditor Actually Needs

Your enterprise prospect just asked for your SOC 2 report. You don’t have one. The CFO asks what it costs. The answer — $15,000 to $50,000 for a consulting engagement, plus $10,000 to $30,000 for the audit itself — gets everyone’s attention. Then the timeline: three to six months for documentation, another three to twelve months for the observation period if you’re going Type II.

The audit cost is unavoidable. SOC 2 reports must be issued by an independent CPA firm. But the documentation — the policies, procedures, control narratives, and evidence framework that the auditor evaluates — doesn’t have to cost five figures or take months to build.

What SOC 2 Actually Requires

SOC 2 is an attestation engagement under the AICPA’s AT-C Section 205. Your auditor evaluates your controls against the Trust Services Criteria, which define requirements across five categories: Security, Availability, Confidentiality, Processing Integrity, and Privacy.

Security is mandatory for every SOC 2 report. It spans nine Common Criteria groups (CC1 through CC9) covering control environment, communication, risk assessment, monitoring, control activities, logical and physical access, system operations, change management, and risk mitigation. The other four categories are optional and depend on the services you provide.

The auditor’s job is to determine whether your controls are suitably designed (Type I) and, for Type II, whether they operated effectively over a defined period. They do this by reading your documentation and testing your evidence. No documentation means no controls to evaluate.

The Five Documentation Pillars

System Description

This is the core of your SOC 2 report. The system description defines the boundaries of your audit — what’s in scope, what components make up the system, who’s responsible, and what commitments you’ve made to customers.

The AICPA specifies the structure: principal service commitments and system requirements, components of the system (infrastructure, software, people, procedures, data), relevant aspects of the control environment, complementary user entity controls, and subservice organisations.

Most companies have never written one. It’s not a marketing document or an architecture diagram. It’s a formal description of your control environment written in the language auditors expect. Getting this wrong — or leaving it vague — creates problems that cascade through the entire engagement.

Policies

Policies establish what your organisation commits to doing. For SOC 2, you need policies that map directly to the Common Criteria. At minimum: information security, access control, change management, incident response, risk management, data classification, encryption, network security, vulnerability management, vendor risk management, business continuity, and security awareness training.

Each policy should reference the specific CC criteria it addresses. Auditors trace from criteria to controls to evidence. If your policy doesn’t explicitly connect to the criteria, the auditor has to make that connection themselves — and they may conclude it doesn’t exist.

Procedures

Procedures describe how policies are executed operationally. User access provisioning and deprovisioning, access reviews, change management workflows, incident response steps, vulnerability scanning and remediation, security monitoring, employee onboarding and offboarding, backup and recovery testing.

Every procedure needs numbered steps, defined roles, prerequisite checks, and references to the governing policy and evidence form. “We review access quarterly” isn’t a procedure. “The IT Security Analyst exports the active user list from Azure AD on the first Monday of each quarter, compares it against the HR termination report, and documents confirm/remove/investigate decisions in the Access Review Log” is a procedure.

Control Matrix and Narratives

The control matrix maps each CC criterion to your specific control activities, control owners, testing frequency, and evidence requirements. Control narratives describe what each control does, how it operates, how often it runs, and who is responsible.

This is what your auditor reads first. Well-written narratives that match the TSC language reduce follow-up questions and accelerate the engagement. Vague narratives generate requests for information that consume your team’s time for weeks.

Evidence Framework

For Type II, your auditor needs to see evidence that controls operated over the observation period. Access review logs, change tickets, incident records, vulnerability scans, training completion records, vendor assessments, exception approvals.

The evidence framework — forms, trackers, and workbooks with proper structure — should be in place before the observation period begins, not assembled retroactively when the auditor asks for samples. Retroactive evidence assembly is one of the most common reasons SOC 2 engagements go over budget and over timeline.

Type I vs Type II: A Practical Decision

Type I evaluates control design at a single point in time. Type II evaluates design and operating effectiveness over a period, typically six to twelve months.

Most organisations start with Type I to demonstrate they have the documentation and controls in place, then move to Type II once they’ve accumulated a track record of evidence. Some buyers accept Type I as an interim step. Others require Type II from the start. Know what your customers and prospects require before you scope the engagement.

The documentation is identical for both. The difference is whether you need to show your controls work on paper (Type I) or that they worked in practice over time (Type II). Building the evidence framework into your documentation from day one means you’re collecting Type II evidence from the moment you implement controls.

The Cross-Mapping Advantage

If your organisation already maintains NIST CSF 2.0 or ISO 27001 documentation, you’re not starting from zero. The Trust Services Criteria map extensively to both frameworks. A TSC-to-framework crosswalk shows exactly which SOC 2 requirements your existing documentation already satisfies — and which gaps remain.

The SOC 2-specific elements — system description, control narratives, complementary user entity controls, and the evidence collection structure mapped to CC criteria — are unique to SOC 2 and won’t exist in generic NIST or ISO documentation. But the underlying policies and procedures overlap significantly.

Building vs Buying Documentation

Building SOC 2 documentation from scratch takes a security or compliance professional 200 to 400 hours. That’s two to four months of dedicated effort, assuming you know what the auditor expects. Hiring a GRC consultant to build it costs $15,000 to $50,000.

Pre-built documentation packages structured around the Trust Services Criteria compress this timeline from months to days. The trade-off is customisation effort — you’re adapting templates to your environment rather than writing from blank pages. For most organisations, that’s a favourable trade-off by an order of magnitude.

Ridgeline Cyber Defence provides the SOC 2 Readiness Suite — 39 to 69 documents including system description template, control matrix, control narratives, policies, procedures, evidence workbooks, and auditor preparation tools. Mapped to AICPA Trust Services Criteria with NIST CSF 2.0 and ISO 27001 cross-references.

Related Reading

• Security Policy Documentation: Enterprise Quality
• Cross-Mapping NIST, ISO & CIS Frameworks
• Risk Management Program: Assessment, BIA & Vendor Risk