SOC 2 Compliance
Service Organisation Control reporting framework for managing customer data based on five Trust Service Criteria: security, availability, processing integrity, confidentiality, and privacy.
Overview
SOC 2 is built around five Trust Service Criteria defined by the AICPA. Security is the foundational criterion required in every engagement, covering logical and physical access, system operations, change management, and risk mitigation. The remaining four criteria - availability, processing integrity, confidentiality, and privacy - are selected based on the nature of services provided.
The examination is conducted by an independent CPA firm that evaluates the design and, for Type II reports, the operating effectiveness of controls over a defined review period. The resulting report includes a description of the system, management assertions, the auditor's opinion, and detailed testing results. Any exceptions or qualifications are documented transparently.
SOC 2 is not a certification; it is an attestation. The CPA firm provides an opinion on whether controls are suitably designed and operating effectively. This distinction matters because it means there is no pass/fail binary - the report provides nuanced information that readers interpret in the context of their own risk tolerance.
Organisations benefit most from SOC 2 when they treat it as a continuous program rather than an annual project. Embedding evidence collection into daily workflows, automating control monitoring, and maintaining a living control inventory ensures readiness year-round and reduces the burden of each successive audit cycle.
Key Areas
- Security (Common Criteria) - foundational controls required for every SOC 2 engagement
- Availability - controls ensuring systems are operational and accessible as committed
- Processing Integrity - controls ensuring system processing is complete, valid, accurate, and timely
- Confidentiality - controls protecting information designated as confidential
- Privacy - controls governing the collection, use, retention, disclosure, and disposal of personal information
- Logical and Physical Access Controls - identity management, authentication, and facility security
- System Operations - monitoring, incident detection, and response procedures
- Change Management - controls over changes to infrastructure, software, and configurations
- Risk Assessment - ongoing identification and evaluation of risks to the control environment
Who It's For
- SaaS companies and cloud service providers that handle customer data
- Technology vendors needing to demonstrate security posture to enterprise buyers
- Managed service providers and data processors seeking competitive differentiation
- Any service organisation whose clients require independent assurance of internal controls
Core Requirements
- Policies and Governance
- Organisations must establish and maintain information security policies approved by management, define roles and responsibilities, and implement a governance structure that oversees the control environment. Board or executive oversight of the security program is expected.
- Risk Management
- A formal risk assessment process must identify threats and vulnerabilities relevant to the Trust Service Criteria in scope. Risks must be evaluated for likelihood and impact, with documented treatment plans and acceptance criteria.
- Security Controls
- Technical and administrative controls must address access management, encryption, network security, vulnerability management, and endpoint protection. Controls should be mapped to the applicable Trust Service Criteria and tested regularly.
- Incident Response
- An incident response plan must define procedures for detecting, reporting, evaluating, and resolving security events. The plan should include communication protocols, escalation paths, root cause analysis, and lessons-learned reviews.
- Evidence and Reporting
- Organisations must collect and retain evidence demonstrating that controls operate effectively over the review period. Evidence includes system configurations, access reviews, change records, monitoring logs, and policy attestations. This evidence is examined during the SOC 2 audit.
Implementation Steps
- Scope and objectives - Determine which Trust Service Criteria are in scope based on your services and customer expectations. Define the system boundaries, including infrastructure, software, people, procedures, and data. Establish a project timeline and assign an internal owner.
- Gap assessment - Evaluate your current control environment against SOC 2 requirements. Identify missing or immature controls, process gaps, and documentation deficiencies. Prioritise remediation based on risk and audit readiness.
- Control implementation - Design and deploy controls that satisfy each criterion in scope. This includes drafting policies, configuring technical controls, implementing monitoring and alerting, and establishing operational procedures. Ensure controls are assigned to owners.
- Evidence and documentation - Establish processes to collect, organise, and retain evidence of control operation. Document control descriptions, testing procedures, and results. Build an evidence repository that auditors can review efficiently.
- Review and continuous improvement - Conduct internal reviews to validate control effectiveness before the external audit. After the audit, address any findings or recommendations. Establish a cadence for ongoing monitoring, evidence collection, and annual re-examination.
Frequently Asked Questions
- What is the difference between SOC 2 Type I and Type II?
- Type I evaluates the design of controls at a specific point in time. Type II evaluates both design and operating effectiveness over a period, typically six to twelve months. Type II reports are considered more rigorous and are preferred by most enterprise buyers.
- Is SOC 2 mandatory?
- SOC 2 is not legally mandated. However, it is effectively required for service organisations selling to enterprise customers, as many buyers include SOC 2 Type II reports in their vendor due diligence requirements.
- How long does it take to get SOC 2 compliant?
- Initial readiness typically takes three to six months for organisations with some existing controls. The Type II observation period adds another six to twelve months. Organisations starting from scratch should plan for nine to eighteen months total.
- Who performs the SOC 2 audit?
- SOC 2 examinations must be performed by an independent CPA firm licensed to issue SOC reports. The firm evaluates evidence, tests controls, and issues the attestation report.
- Which Trust Service Criteria should we include?
- Security (Common Criteria) is always required. Add availability, processing integrity, confidentiality, or privacy based on your services and customer expectations. Start with security and expand in subsequent audits as needed.
- How much does a SOC 2 audit cost?
- Costs vary based on scope, organisational complexity, and the CPA firm selected. Typical engagements range from USD 30,000 to USD 100,000 or more for large, complex environments.
- Can SOC 2 controls be mapped to other frameworks?
- Yes. SOC 2 controls often overlap with ISO 27001, NIST CSF, and CIS Controls. Mapping controls across frameworks reduces duplication and streamlines multi-framework compliance.
- Do we need to share our full SOC 2 report?
- SOC 2 reports are restricted-use documents. Organisations typically share them under NDA with prospective and existing customers. Some organisations provide a SOC 3 report, which is a general-use summary.
Why It Matters
- Enterprise buyers increasingly require SOC 2 Type II reports before onboarding new vendors. Without one, service organisations face longer sales cycles, lost deals, and reduced competitiveness. SOC 2 provides a standardised way to demonstrate that your organisation takes data security seriously and has implemented effective internal controls.
- SOC 2 addresses the trust gap between service providers and their customers. By engaging an independent CPA firm to examine controls, organisations provide third-party assurance that goes beyond self-reported security questionnaires. This is especially important for organisations handling sensitive financial, healthcare, or personal data.
- Beyond customer trust, SOC 2 drives meaningful internal improvements. The process of scoping, implementing, and evidencing controls forces organisations to formalise security practices, assign ownership, and build repeatable processes that reduce risk and improve operational resilience.
Common Challenges
- Underestimating the volume of evidence required for a Type II examination, leading to last-minute scrambles during the audit window
- Selecting too many Trust Service Criteria in the initial scope without adequate resources to implement and evidence all required controls
- Treating SOC 2 as a one-time project rather than an ongoing program, resulting in control degradation between audit periods
- Lack of executive sponsorship causing delays in policy approvals and resource allocation
- Difficulty maintaining consistent evidence collection across distributed or remote teams
- Over-reliance on manual controls when automated alternatives would be more reliable and auditable
- Failing to align SOC 2 controls with other frameworks the organisation must also satisfy, leading to duplicated effort