SOC 2 is an audit framework developed by the AICPA to evaluate a service organisation’s data protection controls across trust services criteria. The mapping of ISMS controls to AICPA criteria is the primary implementation requirement, delivering the business benefit of verified operational assurance and enterprise trust.
What is SOC 2 ?
Service Organisation Control 2 (SOC 2)
A Service Organisation Control 2 (SOC 2) report is an audit report used by service organisations to show how they protect customer data. A service organisation is a business that provides a service to another company. For example, a cloud hosting provider, a data centre, or a payroll company. The report proves that the service organisation has controls in place to protect the privacy and security of a client’s information. It is based on a set of criteria called the Trust Services Criteria (TSC). There are five of these criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. The SOC 2 report is an important way for businesses to build trust with their clients.
Examples
Here are some examples of companies that would get a SOC 2 report:
- A cloud service provider: A company like Amazon Web Services (AWS) or Microsoft Azure, which stores customer data on their servers, would need a SOC 2 report to show that they keep this data safe.
- A payroll processing company: A company that handles employee salaries and personal information for other businesses would need a SOC 2 report to prove they protect that data.
- A software-as-a-service (SaaS) company: If a company offers an online tool where clients store their data, they would get a SOC 2 report to show that the tool is secure.
Context
Imagine you are a small business owner. You want to use an online company to manage your employees’ payroll. This company will have access to sensitive information like names, addresses, and bank details. How can you be sure they will keep this information safe? This is where a SOC 2 report comes in.
You can ask the payroll company for their SOC 2 report. The report, written by an independent auditor, will tell you how the company handles and protects your data. It will explain their security measures and show that they follow the rules. This report gives you peace of mind that your data is in good hands. A SOC 2 report is a way for a company to show its customers that it is trustworthy and responsible with their data.
How to implement SOC 2
Implementing SOC 2 (System and Organisation Controls 2) within an ISO 27001 framework is a highly efficient strategy for SaaS providers. As a Lead Auditor, I have observed that because ISO 27001 covers approximately 80% of SOC 2 technical requirements, organisations can achieve dual attestation by mapping their ISMS controls directly to the AICPA Trust Services Criteria. This 10-step technical sequence defines how to formalise your SOC 2 environment to meet the rigorous demands of enterprise procurement teams.1. Provision a SOC 2 Scoping Statement
Define the specific system boundaries and the Trust Services Criteria (TSC) to be included in the audit: This ensures the technical scope is aligned with customer expectations. Key requirements include:
- Identifying the specific applications, infrastructure, and people involved in data processing.
- Selecting additional TSCs beyond the mandatory “Security” criteria, such as Availability or Confidentiality.
- Documenting the physical and logical boundaries of the system within the ISMS.
2. Audit ISO 27001 Controls against AICPA Criteria
Conduct a cross-walk analysis between existing ISO 27001 Annex A controls and the SOC 2 Trust Services Criteria: This identifies technical gaps and reduces redundant audit effort by up to 40%. Technical actions include:
- Mapping Annex A 5.15 access controls to SOC 2 Logical Access criteria.
- Verifying that ISO 27001 risk treatment plans address AICPA-specific security risks.
- Identifying unique SOC 2 requirements not found in ISO 27001, such as specific system description mandates.
3. Formalise the SOC 2 System Description
Formalise a detailed System Description document that explains how the organisation’s infrastructure and software function to protect customer data: This document is a citable requirement for any SOC 2 attestation. Necessary components include:
- Documenting technical architecture diagrams and data flow maps.
- Detailing the software lifecycle and deployment procedures.
- Specifying the technical safeguards used for data encryption and isolation.
4. Provision Identity and Access Management (IAM) Roles
Enforce granular IAM roles based on the Principle of Least Privilege to restrict access to the SOC 2 system boundary: Restricting access is a core requirement for the TSC Security criteria. Implementation steps involve:
- Mandating Multi-Factor Authentication (MFA) for 100% of administrative logins.
- Provisioning unique user IDs to ensure complete auditability of data access.
- Implementing automated account revocation workflows for employee terminations.
5. Formalise Change Management and Authorisation Workflows
Provision a formal change management process to ensure that all system alterations are authorised, tested, and documented: This provides technical evidence for the Processing Integrity criteria. Technical requirements include:
- Enforcing peer review requirements for 100% of production code changes.
- Utilising automated CI/CD pipelines to log deployment timestamps and authorisations.
- Revoke access to production environments for developers to maintain segregation of duties.
6. Provision Continuous Vulnerability Scanning
Audit the technical estate through regular vulnerability scans and annual penetration testing: This satisfies the requirement for proactive threat detection within the TSC Security criteria. Key actions include:
- Configuring authenticated scans to identify misconfigurations in cloud environments.
- Executing a penetration test with a formal Rules of Engagement (ROE) document.
- Integrating scan results into a centralised technical remediation tracker.
7. Formalise Incident Response and Notification Protocols
Provision a citable Incident Response Plan that includes specific thresholds for notifying customers of a security event: This ensures compliance with the TSC Availability and Security requirements. Components involve:
- Defining technical triggers for incident escalation within the SOC.
- Establishing 24/7 monitoring for anomalous system behaviour.
- Conducting annual tabletop exercises to verify response effectiveness.
8. Audit Third-Party Vendor Risk
Formalise the process for assessing the security posture of critical sub-service organisations: SOC 2 requires 100% oversight of the vendors that support your system. Technical actions include:
- Collecting and reviewing the SOC 2 Type 2 reports of your cloud hosting providers.
- Ensuring that Business Associate Agreements (BAA) or DPAs are signed and citable.
- Updating the Supplier Register to reflect the risk categorisation of each vendor.
9. Formalise the SOC 2 Type 1 Readiness Assessment
Audit the design of controls at a single point in time to verify that technical safeguards are properly implemented: This serves as the prerequisite for the Type 2 attestation. Verification methods include:
- Collecting a “point-in-time” snapshot of active user accounts and MFA status.
- Verifying that all policies have been formalised and approved by management.
- Documenting the successful implementation of all controls identified in the gap analysis.
10. Audit Operational Effectiveness for SOC 2 Type 2
Execute an observation period, typically 6 to 12 months, to prove that controls operate effectively over time: This provides the 100% assurance required for a Type 2 attestation. Necessary actions include:
- Maintaining tamper-proof logs of change requests and incident tickets.
- Audit quarterly access reviews to ensure logical access remains appropriate.
- Collecting citable evidence of control operation for the external CPA auditor.
SOC 2 FAQ
What is SOC 2?
SOC 2 (System and Organisation Controls 2) is a voluntary compliance standard for service organisations, developed by the AICPA, which specifies how organisations should manage customer data based on five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. It is the primary security framework for SaaS providers in the North American market.
What is the difference between SOC 2 Type 1 and SOC 2 Type 2?
The primary difference is the period of evaluation: SOC 2 Type 1 audits the design of controls at a single point in time, whereas SOC 2 Type 2 audits the operational effectiveness of those controls over a period, typically between 6 and 12 months. Type 2 is generally required by enterprise procurement teams for 100% assurance of ongoing security.
How does ISO 27001 compare to SOC 2?
While ISO 27001 is an international standard for an ISMS, SOC 2 is an attestation report focused on specific Trust Services Criteria. There is an approximate 80% overlap in technical requirements. Organisations often map ISO 27001 Annex A controls to SOC 2 criteria to achieve dual compliance, reducing redundant audit efforts by up to 40%.
What are the five Trust Services Criteria of SOC 2?
SOC 2 reports are structured around five Trust Services Criteria (TSC). While Security is mandatory (the “Common Criteria”), organisations can choose to add the others based on business needs:
- Security: Protection of information and systems against unauthorised access (Mandatory).
- Availability: Ensuring systems are available for operation and use as committed or agreed.
- Processing Integrity: Ensuring system processing is complete, valid, accurate, timely, and authorised.
- Confidentiality: Protection of information designated as confidential until its intended disposal.
- Privacy: Collection, use, retention, disclosure, and disposal of personal information in conformity with the organisation’s privacy notice.
Related ISO 27001 Controls
| Related ISO 27001 Control / Concept | Relationship Description |
|---|---|
| ISO 27001 Annex A 5.19: Information Security in Supplier Relationships | Supplier Due Diligence: A SOC 2 report is one of the most common pieces of evidence used by organizations to satisfy the requirement of assessing and managing the security risks of their third-party suppliers. |
| ISO 27001 Annex A 5.22: Monitoring of Supplier Services | Continuous Assurance: Organizations often require an annual SOC 2 Type 2 report from their vendors to fulfill the mandatory ISO 27001 requirement for regular monitoring and auditing of supplier security performance. |
| ISO 27001 Annex A 5.23: Information Security for Use of Cloud Services | Cloud Security Verification: Since SOC 2 is the industry standard for SaaS and cloud providers, it is the primary tool used to verify that a cloud company meets the security expectations defined under this control. |
| ISO 27001 Annex A 5.35: Independent Review of Information Security | Objective Validation: Much like the independent review required by ISO 27001, a SOC 2 report is authored by an independent auditor to provide a neutral, third-party assessment of an organization’s security controls. |
| Glossary: CIA Triad | Shared Objectives: The SOC 2 Trust Services Criteria (Security, Availability, Confidentiality, Processing Integrity, and Privacy) directly overlap with the Confidentiality, Integrity, and Availability principles of ISO 27001. |
| Glossary: Right to Audit | Contractual Fulfillment: Many suppliers offer a SOC 2 report to their clients as a way to satisfy “Right to Audit” clauses without allowing hundreds of individual customers to perform their own physical site inspections. |
| ISO 27002:2022 | Mapping Standards: ISO 27002 provides the implementation guidance that many organizations use to build the controls that will eventually be audited against the SOC 2 Trust Services Criteria. |
| ISO 27001 Glossary of Terms (Main Index) | Parent Directory: The central index where SOC 2 is categorized as an essential external audit and compliance reporting framework. |
About the author
