SOC 2 (AICPA)

Introduction: SOC 2 in Plain Terms

SOC 2 (System and Organization Controls 2) is an attestation report developed and governed by the American Institute of Certified Public Accountants (AICPA). It is the most widely recognised assurance report for technology and cloud service organisations that store, process or transmit customer data. Unlike a certification with a fixed pass/fail checklist, SOC 2 is a report of independent opinion issued by a licensed CPA firm on the suitability of design and, in Type II engagements, the operating effectiveness of a service organisation's controls relevant to one or more of the five Trust Services Criteria (TSC): Security, Availability, Processing Integrity, Confidentiality and Privacy.

For B2B SaaS vendors, managed service providers, data centres, payroll processors and any organisation to whom customers outsource part of their information system, a SOC 2 report has become a de facto prerequisite to close enterprise deals. Procurement, vendor risk and security teams routinely demand a current SOC 2 Type II report before signing. This guide provides an auditor-grade walk-through of the framework, the full Trust Services Criteria control set, a master assessment checklist, a phased implementation approach, scoping guidance, and the evidence expectations that a CPA examiner will hold you to.

What is SOC 2

SOC 2 is one of a family of AICPA System and Organization Controls reports performed under attestation standards AT-C Section 105 and AT-C Section 205. The examination results in a report containing the independent service auditor's opinion, management's assertion, a description of the system, and the auditor's tests of controls and results (in a Type II).

The three most commonly confused SOC reports are distinguished as follows:

SOC 2 itself comes in two report types, which every buyer will ask you to distinguish:

The report opinion may be unqualified (clean), qualified (one or more controls did not operate effectively or were not suitably designed), adverse, or a disclaimer. A clean Type II covering a 12-month period is the market objective.

Who Must Comply

SOC 2 is voluntary in the strict legal sense; there is no statute mandating it. In practice it is contractually mandated by customers. An organisation typically needs SOC 2 when it acts as a service organisation holding or processing another entity's data. The trigger is usually commercial, contractual or driven by the vendor risk function of a prospective customer.

• Only the Security category (the 'Common Criteria') is mandatory in every SOC 2 report; the other four categories are elective and included based on customer commitments and the nature of the service.
• Sub-service organisations (e.g. AWS, Azure, GCP) are typically handled by the carve-out method, where their controls are excluded but complementary sub-service organisation controls (CSOCs) are identified.
• User entities are expected to implement complementary user entity controls (CUECs) described in the report.

Structure of SOC 2: The Trust Services Criteria

SOC 2 is built on the Trust Services Criteria (TSC 2017, revised points of focus 2022). The Security category is expressed as the Common Criteria (CC series), which are organised around the five components of the COSO 2013 internal control framework. The other four categories add their own criteria (A, PI, C, P series) on top of the Common Criteria. Every SOC 2 must include all Common Criteria; additional criteria apply only if that category is in scope.

The Common Criteria (CC) are grouped into nine families aligned to COSO components:

Master Assessment Checklist

This is the core section. Each criteria family is enumerated with what an examiner will verify and the typical evidence you must be able to produce. Treat every row as a potential test of control. Nothing here should be skipped during readiness.

CC1 — Control Environment

CC2 — Communication and Information

CC3 — Risk Assessment

CC4 — Monitoring Activities

CC5 — Control Activities

CC6 — Logical and Physical Access Controls

CC7 — System Operations

CC8 — Change Management

CC9 — Risk Mitigation

A1 — Availability (if in scope)

PI1 — Processing Integrity (if in scope)

C1 — Confidentiality (if in scope)

P1 to P8 — Privacy (if in scope)

Scoping the SOC 2 Examination

Scoping decisions drive cost, timeline and buyer value. They must be settled before the observation period begins, because a Type II report tests controls across the whole period.

1. Select the Trust Services Categories. Security is mandatory. Add Availability, Confidentiality, Processing Integrity or Privacy only where you make explicit commitments to customers or where a category materially reflects your service.
2. Define the system boundary. Document the in-scope product(s), infrastructure, software, people, data and procedures that make up the 'system' under examination.
3. Decide report type. Type I for a first-year point-in-time bridge; Type II for the operating-effectiveness report enterprise buyers expect.
4. Set the observation period. Common first Type II periods are 3 to 6 months; recurring reports usually cover 12 months for continuous coverage.
5. Choose the sub-service organisation method. Carve-out (exclude and monitor via their SOC report) is typical for AWS/Azure/GCP; inclusive method incorporates their controls into your report.
6. Identify complementary user entity controls (CUECs) that your customers must operate for the controls to be effective.
7. Confirm legal entities, environments (prod only vs prod plus corporate IT) and geographic locations covered.

Implementation Approach (Phased)

A structured programme takes a typical mid-size SaaS from zero to a clean Type II in roughly 6 to 12 months. The following phases sequence the work and set deliverables.

Phase 1 — Readiness and Gap Assessment

• Activities: select TSC categories, define system boundary, perform a gap assessment against every applicable criterion, build the risk register and control matrix.
• Deliverables: scoping document, gap assessment report, prioritised remediation roadmap, project plan and RACI.

Phase 2 — Policy and Governance Foundation

• Activities: author and approve the information security policy suite (access, change, incident, risk, vendor, BCP/DR, data classification, HR security), establish security governance forum, assign control owners.
• Deliverables: approved policy set with review dates, governance charter, control-ownership register.

Phase 3 — Technical and Operational Remediation

• Activities: deploy SSO/MFA, PAM, encryption, logging and SIEM, vulnerability management, endpoint protection, secure SDLC gates, backup and DR, and access review automation.
• Deliverables: hardened baseline configurations, monitoring dashboards, remediated access model, DR test results.

Phase 4 — Operate and Collect Evidence (Observation Period)

• Activities: run controls in production over the observation window; perform quarterly access reviews, risk assessments, incident drills, vendor reviews; continuously collect evidence.
• Deliverables: populated evidence repository, control operation logs, management review records covering the full period.

Phase 5 — Independent Examination

• Activities: engage a licensed CPA firm, prepare management's assertion and system description, support fieldwork, respond to sample requests and clarifications.
• Deliverables: draft and final SOC 2 report, auditor opinion, management response to any exceptions.

Phase 6 — Continuous Compliance and Renewal

• Activities: maintain controls, automate evidence collection, monitor drift, feed findings into risk assessment, plan the next annual period with no coverage gap.
• Deliverables: continuous monitoring reports, updated risk register, renewal plan and next-period timeline.

Maturity and Capability Model

SOC 2 does not itself assign maturity levels, but a capability model is invaluable for tracking readiness and communicating progress to leadership. The following five-level model maps organisational maturity to SOC 2 outcomes.

Assessment and Audit Approach

The examination follows AICPA attestation standards. The service auditor executes an evidence-based process from planning through opinion.

1. Engagement acceptance: the CPA firm confirms independence, competence and scope, and agrees the categories, system boundary, report type and period.
2. Understanding the system: the auditor documents the service, controls and the description prepared by management.
3. Risk assessment and control identification: the auditor maps management's controls to each applicable Trust Services Criterion.
4. Design evaluation (Type I and II): the auditor tests whether controls are suitably designed to meet the criteria.
5. Operating effectiveness testing (Type II only): the auditor selects samples across the period and performs inquiry, observation, inspection and re-performance.
6. Exception evaluation: any control failures are assessed for severity and impact on the opinion.
7. Forming the opinion: unqualified, qualified, adverse or disclaimer, based on results.
8. Reporting: the auditor issues the report containing the opinion, management's assertion, the system description, and (Type II) the tests of controls and results.
9. Management response: management addresses any exceptions and describes remediation.

Evidence Request List

Auditors request evidence by category. Prepare a repository organised as follows before fieldwork.

• Governance: board/committee minutes, org chart, code of conduct, policy suite with approval and review dates.
• HR security: background-check records, onboarding and offboarding checklists, security-awareness training completion.
• Access management: IAM/SSO/MFA configuration, joiner-mover-leaver tickets, quarterly access review records, PAM logs.
• Change management: change tickets with approvals, CI/CD pipeline configuration, QA sign-offs, deployment logs.
• System operations: vulnerability scan and penetration test reports, SIEM/EDR alerts, incident tickets and post-mortems.
• Availability: backup success logs, DR test results, capacity monitoring, uptime/status reports.
• Encryption and network: TLS/KMS configuration, firewall rules, network diagrams, disk-encryption settings.
• Vendor risk: vendor inventory, due-diligence assessments, executed contracts and DPAs, sub-service SOC report reviews.
• Risk and monitoring: risk register, risk assessment methodology, internal audit and control self-assessment records.
• Privacy (if in scope): privacy notice, consent records, DSAR logs, retention and disposal evidence.

Roles and Responsibilities

KPIs to Track

• Percentage of controls with a named owner and current evidence.
• Access review completion rate and time to remediate access exceptions.
• Mean time to detect and mean time to respond for security incidents.
• Percentage of changes following the approved change-management process.
• Vulnerability remediation SLA adherence (critical/high within target days).
• Backup success rate and DR test pass rate against RTO/RPO targets.
• Vendor risk assessments completed for in-scope third parties.
• Security-awareness training completion rate.
• Number and severity of audit exceptions per period (trend downward).
• Policy review currency (percentage reviewed within the last 12 months).

Readiness Checklist

• Trust Services Categories selected and system boundary documented
• Full information security policy suite authored, approved and communicated
• Risk register and control matrix completed and mapped to every applicable criterion
• SSO, MFA and least-privilege access enforced across production and corporate systems
• Quarterly access reviews scheduled and evidence retained
• Change management with approvals, testing and dev/prod separation operating
• Centralised logging, SIEM/EDR monitoring and incident response plan in place and tested
• Vulnerability management and annual penetration testing performed
• Encryption enforced at rest and in transit with key management
• Backups running with verified restores and a tested DR/BCP plan
• Vendor risk assessments and DPAs completed; sub-service SOC reports reviewed
• Security-awareness training and background checks completed for all staff
• Evidence repository organised by criteria and covering the full observation period
• Licensed CPA firm engaged and management assertion and system description drafted

Common Gaps

• Access reviews performed once for the audit rather than consistently throughout the period, causing operating-effectiveness exceptions.
• Terminated users not de-provisioned promptly, leaving stale accounts detectable in samples.
• Change management bypassed for 'quick fixes' with no ticket, approval or test evidence.
• Policies written but never approved, dated or communicated to staff.
• Incident response plan documented but never tested; no evidence of tabletop or drill.
• Vendor risk programme absent; sub-service organisation SOC reports never reviewed.
• Backups configured but restores never tested, and no DR exercise evidence.
• Security-awareness training incomplete for a subset of the workforce.
• Evidence collected only near audit time, leaving gaps earlier in the observation period.
• Overscoping with Privacy or Processing Integrity before those controls are mature, leading to qualifications.

SOC 2 Mapped to Other Frameworks

SOC 2 controls overlap heavily with other frameworks, enabling a build-once, comply-many approach. The mapping below is indicative and should be validated against the authoritative crosswalks.

Frequently asked questions

Need help with SOC 2?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.