Organisations increasingly rely on cloud platforms, software providers, data centres, payment services, payroll systems, and other external technology partners to support important business functions.
Customers need assurance that these providers protect information appropriately and that their security controls operate as described. A SOC 2 report is one of the most widely recognised ways for a service organisation to provide that assurance.
SOC 2 examines controls relevant to security, availability, processing integrity, confidentiality, and privacy. It is commonly used by software-as-a-service companies and other providers that store, process, or transmit customer information.
Although the phrase SOC 2 certification is widely used, SOC 2 does not technically result in a certification. It results in an independent attestation report prepared by a qualified CPA firm.
This article explains what SOC 2 is, the difference between SOC 2 Type I and SOC 2 Type II, the Trust Services Criteria, and the main SOC 2 compliance requirements organisations should address.
What Is SOC 2?
SOC 2 stands for System and Organisation Controls 2.
It is an assurance framework developed by the American Institute of Certified Public Accountants, or AICPA, for examining controls at service organisations.
The AICPA describes a SOC 2 engagement as an examination of a service organisation’s system and controls relevant to:
- Security
- Availability
- Processing integrity
- Confidentiality
- Privacy
A SOC 2 report helps customers and business partners assess risks associated with outsourcing services and understand whether the provider has designed and operated appropriate controls.
SOC 2 is voluntary rather than a law. However, it is frequently requested during procurement, supplier due diligence, and enterprise sales.
For many technology providers, obtaining a report becomes commercially necessary because customers may not be willing to share sensitive information or depend on a critical service without independent assurance.
Who Needs SOC 2 Compliance?
SOC 2 is relevant to service organisations that handle customer systems, information, or business processes.
Typical examples include:
- Software-as-a-service providers
- Cloud hosting companies
- Data centres
- Managed service providers
- Cyber security companies
- Payment and financial technology platforms
- Healthcare technology providers
- Human resources and payroll providers
- E-commerce services
- Telecommunications providers
- Data-processing companies
A business may pursue SOC 2 compliance when:
- Enterprise customers request a report
- Security questionnaires are delaying sales
- Sensitive customer information is processed
- The service is operationally critical
- The organisation wants to strengthen internal controls
- Investors or partners require independent assurance
- The business is expanding into the United States
SOC 2 is especially common in North American technology procurement, but organisations in other regions may also obtain reports when serving United States customers or multinational clients.
SOC 2 Compliance or SOC 2 Certification?
The term SOC 2 certification is commonly used in marketing and search queries, but it is not technically accurate.
SOC 2 is an attestation engagement. An independent service auditor examines the organisation’s system description and relevant controls and then issues a SOC 2 report containing an opinion.
The organisation is therefore better described as:
- Having completed a SOC 2 examination
- Having received a SOC 2 report
- Being aligned with SOC 2 requirements
- Having controls assessed against the Trust Services Criteria
The report does not provide a permanent pass or universal guarantee of security.
It reflects the systems, controls, scope, criteria, and period covered by the examination.
The Five Trust Services Criteria
SOC 2 examinations use the AICPA Trust Services Criteria.
The five categories are:
- Security
- Availability
- Processing integrity
- Confidentiality
- Privacy
The AICPA uses these criteria to evaluate controls in SOC 2 engagements and other assurance services.
Security is included in every SOC 2 examination. The remaining criteria are selected according to the service provided, customer expectations, contractual commitments, and the information handled.
An organisation should not automatically include every category. The scope should reflect the service and the risks that report users need to understand.
Security
Security addresses whether information and systems are protected against unauthorised access, disclosure, and damage.
It is sometimes referred to as the Common Criteria because it forms the foundation of every SOC 2 report.
Relevant controls may include:
- Identity and access management
- Multi-factor authentication
- Network security
- Secure configuration
- Vulnerability management
- Patch management
- Security monitoring
- Incident response
- Employee awareness training
- Change management
- Supplier security
- Physical and environmental protection
The organisation must demonstrate that controls are designed to prevent, detect, and respond to security events.
Availability
Availability addresses whether systems and information are available for operation and use as committed or agreed.
It does not require a service to be available at all times. The organisation defines relevant availability commitments, and the auditor assesses controls supporting those commitments.
Controls may include:
- Service monitoring
- Capacity planning
- System redundancy
- Backups
- Disaster recovery
- Business continuity
- Incident escalation
- Recovery testing
- Service-level monitoring
Availability is particularly relevant where customers depend on the provider for critical or time-sensitive operations.
Processing Integrity
Processing integrity considers whether system processing is complete, valid, accurate, timely, and authorised.
This criterion may be relevant to platforms that process financial transactions, payroll, customer orders, insurance claims, or other important data.
Controls may cover:
- Input validation
- Authorisation
- Error handling
- Reconciliation
- Output review
- Quality assurance
- Software testing
- Change approval
- Transaction monitoring
Processing integrity does not mean that every item of data submitted by a customer is correct. It focuses on whether the system processes information according to its intended purpose and commitments.
Confidentiality
Confidentiality addresses the protection of information specifically designated as confidential.
This may include:
- Customer information
- Commercial agreements
- Financial information
- Intellectual property
- Source code
- Business plans
- Security documentation
Controls may include:
- Data classification
- Encryption
- Access restrictions
- Retention rules
- Secure transmission
- Confidentiality agreements
- Secure destruction
- Data-loss prevention
Confidentiality differs from privacy. Confidential information may relate to an organisation, while privacy criteria relate specifically to personal information.
Privacy
Privacy addresses how personal information is collected, used, retained, disclosed, and disposed of.
Relevant controls may cover:
- Privacy notices
- Consent
- Data collection
- Purpose limitation
- Individual rights
- Data retention
- Disclosure practices
- Complaints
- Secure disposal
- Privacy incident management
The privacy criterion can support assurance concerning privacy practices, but completing a SOC 2 examination does not automatically prove compliance with laws such as the UK GDPR, EU GDPR, HIPAA, or CCPA.
Those laws may contain additional requirements outside the scope of the SOC 2 report.
SOC 2 Type I and Type II
There are two main types of SOC 2 report.
SOC 2 Type I
A SOC 2 Type I report assesses whether the organisation’s controls are suitably designed at a specified point in time.
It answers a question similar to:
Were the relevant controls appropriately designed and implemented on the assessment date?
A Type I report can be useful for an organisation completing its first SOC 2 audit because it provides assurance over control design without requiring a long operating period.
However, it does not demonstrate that the controls operated consistently over time.
SOC 2 Type II
A SOC 2 Type II report assesses both:
- Whether controls were suitably designed
- Whether controls operated effectively during a defined period
The examination period is commonly several months, although the appropriate period depends on the engagement.
A Type II report provides stronger assurance because the auditor tests evidence showing how controls operated throughout the review period.
For example, the auditor may examine:
- Access reviews performed during the period
- Security incidents and responses
- Employee onboarding and off-boarding
- Vulnerability scans
- Change approvals
- Backup tests
- Training records
- Supplier assessments
Customers often prefer a Type II report because it demonstrates sustained control operation rather than control design at one date.
| SOC 2 Type I | SOC 2 Type II |
| Assesses a point in time | Assesses a defined period |
| Focuses on control design | Tests design and operating effectiveness |
| Usually completed first | Usually provides stronger assurance |
| Does not prove sustained operation | Includes evidence from throughout the period |
Who Can Perform a SOC 2 Audit?
A SOC 2 examination must be performed by an appropriately licensed and independent CPA practitioner or CPA firm under AICPA attestation standards.
The service auditor must remain independent of the organisation being examined.
Consultants and compliance platforms may help an organisation prepare, identify gaps, organise evidence, or implement controls. However, they cannot issue the formal SOC 2 opinion unless they are appropriately qualified and independent to perform the engagement.
The AICPA describes SOC services as assurance offerings provided by CPAs in connection with controls at service organisations.
The SOC 2 Process
The SOC 2 process normally includes readiness, implementation, evidence collection, external examination, and continued monitoring.
1. Define the Scope
The organisation identifies:
- The service being assessed
- The systems supporting that service
- The Trust Services Criteria to include
- The organisational boundaries
- Relevant locations
- Suppliers and sub-service organisations
- The intended report type
A scope that is too broad can create unnecessary work. A scope that is too narrow may not provide the assurance customers require.
2. Conduct a Readiness Assessment
A readiness assessment compares existing controls against the selected criteria.
It identifies:
- Missing policies
- Weak controls
- Incomplete evidence
- Unclear ownership
- Unsupported systems
- Monitoring gaps
- Supplier risks
- Inadequate documentation
The organisation can then create a remediation plan before the formal audit begins.
3. Implement and Document Controls
The organisation develops or improves controls covering relevant areas such as:
- Risk assessment
- Access control
- Incident response
- Vulnerability management
- Change management
- Business continuity
- Supplier management
- Workforce security
- Data protection
Policies should describe what is required, while procedures explain how activities are performed.
4. Operate the Controls
For a Type II report, controls must operate throughout the examination period.
The organisation should retain evidence as work is performed rather than attempting to reconstruct it before the audit.
Evidence may include:
- Access approvals
- Review records
- System logs
- Training records
- Security reports
- Incident tickets
- Change records
- Backup results
- Supplier reviews
- Management approvals
5. Complete the External Examination
The CPA firm reviews the system description, obtains evidence, performs walkthroughs, selects samples, and tests relevant controls.
The auditor then issues a report containing an opinion.
Possible opinions include:
- Unmodified opinion, where the relevant criteria are met without material qualification
- Qualified opinion, where specific material exceptions affect part of the report
- Adverse opinion, where significant problems prevent the criteria from being met
- Disclaimer of opinion, where the auditor cannot obtain sufficient evidence
SOC 2 is not simply a pass-or-fail checklist. The content of the opinion, identified exceptions, scope, and management response all matter.
6. Maintain Ongoing Compliance
A SOC 2 report has no universal statutory expiry date. However, customers commonly expect a new report each year.
Ongoing SOC compliance requires:
- Continuous monitoring
- Evidence collection
- Periodic access reviews
- Risk assessments
- Control testing
- Policy updates
- Supplier oversight
- Remediation tracking
The organisation should also issue a bridge letter where appropriate if customers require assurance concerning the period between the latest report and the current date.
SOC 2 Compliance Requirements
There is no single fixed list of identical controls for every organisation.
The Trust Services Criteria define outcomes, while each service organisation designs controls appropriate to its systems, risks, services, and commitments.
Common SOC 2 requirements include:
- Formal risk assessments
- Documented security policies
- Defined roles and responsibilities
- Access approval and removal
- Multi-factor authentication
- Secure system configuration
- Vulnerability and patch management
- Logging and monitoring
- Incident response
- Change management
- Security awareness training
- Supplier risk management
- Business continuity and recovery
- Data classification and encryption
- Evidence retention
- Management review
An organisation must also prepare a clear description of its system, including relevant services, infrastructure, software, people, procedures, data, and boundaries.
Benefits of SOC 2 Compliance
Building Customer Trust
A SOC 2 report gives customers independent information about the provider’s controls.
This can strengthen confidence in how the organisation manages customer systems and information.
Supporting Sales and Procurement
Enterprise customers frequently request detailed security questionnaires and supporting evidence.
A SOC 2 report can reduce repetitive due-diligence work and help organisations progress opportunities that require formal assurance.
Improving Security
Readiness and audit work can identify:
- Excessive access
- Missing policies
- Weak monitoring
- Inconsistent processes
- Unsupported systems
- Incomplete supplier reviews
- Poor evidence collection
Correcting these issues can strengthen the organisation beyond the immediate audit requirement.
Improving Accountability
SOC 2 requires controls to have clear ownership and supporting evidence.
This can improve operational visibility and make it easier to identify where controls have failed or remediation is overdue.
Supporting Regulatory Alignment
SOC 2 controls may overlap with requirements under ISO/IEC 27001, HIPAA, GDPR, CCPA, and other frameworks.
However, SOC 2 does not replace those obligations. Organisations must assess each law or standard separately.
SOC 1 Versus SOC 2
SOC 1 examines controls relevant to customers’ internal control over financial reporting.
SOC 2 examines controls relevant to security, availability, processing integrity, confidentiality, or privacy.
The AICPA describes SOC 1 engagements as examinations of service-organisation controls that may affect user entities’ financial reporting.
A payroll provider might require both reports:
- SOC 1 for controls affecting payroll and financial reporting
- SOC 2 for controls protecting systems and information
SOC 2 Versus SOC 3
SOC 2 and SOC 3 use the same Trust Services Criteria.
The principal difference is distribution and detail.
A SOC 2 report contains detailed system and control information and is intended for restricted users with sufficient understanding of the service.
A SOC 3 report provides less detail and is designed for general use, allowing it to be distributed publicly.
SOC 2 Versus ISO/IEC 27001
ISO/IEC 27001 is an international standard specifying requirements for an information security management system.
It results in certification by an accredited certification body when the organisation successfully completes the required audit process.
SOC 2 results in an attestation report issued by a CPA firm.
The frameworks overlap in areas such as:
- Risk management
- Access control
- Incident response
- Supplier management
- Vulnerability management
- Business continuity
- Security governance
SOC 2 is often requested by United States customers, while ISO/IEC 27001 is widely recognised internationally.
An organisation may choose one or both depending on customer expectations, geographic markets, and assurance objectives.
SOC 2 Versus SOX
The Sarbanes-Oxley Act, commonly called SOX, is a United States federal law concerning corporate governance and financial reporting for public companies.
SOC 2 is a voluntary assurance framework concerning service-organisation controls related to security and the other Trust Services Criteria.
The two may overlap in certain control areas, but they have different purposes and should not be treated as interchangeable.
Strengthening Assurance Through SOC 2
SOC 2 provides customers and stakeholders with independent assurance about controls at a service organisation.
The framework uses five Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. Security is included in every examination, while the remaining criteria are selected according to the service and customer requirements.
A Type I report assesses control design at a point in time. A SOC 2 Type II report assesses design and operating effectiveness over a defined period and normally provides stronger assurance.
Achieving and maintaining SOC 2 compliance requires clear scope, appropriate controls, documented procedures, reliable evidence, independent examination, and continuous monitoring.
SeCore helps organisations assess their security posture, map controls to assurance requirements, identify gaps, and prioritise remediation. By establishing structured and measurable controls before a SOC 2 compliance audit, service providers can improve audit readiness while strengthening wider cyber resilience.
