SOC 2

What is SOC 2?

SOC 2 is a type of report produced when an independent certified public accountant (CPA) firm examines a service organisation’s controls. The examination follows attestation standards issued by the AICPA. Controls are evaluated against the AICPA’s Trust Services Criteria (TSC).

SOC 2 exists because customers increasingly hand important data and processes to outside providers: SaaS platforms, data centres, payment processors and managed service providers. Instead of every customer auditing every provider, the provider commissions one independent examination and shares the report with customers who need it.

SOC 2 is part of the AICPA’s System and Organization Controls (SOC) suite. SOC 1 covers controls relevant to customers’ financial reporting. SOC 3 is a shorter, general-use report based on the same criteria as SOC 2.

Purpose and objectives

A SOC 2 report helps customers and their auditors answer one question: can we rely on this provider’s controls for the commitments it has made to us? Those commitments might cover security, uptime, accurate processing, protecting confidential data or handling personal information.

For the service organisation, the report:

• reduces repeated customer audits and questionnaires;
• gives a structured, independent view of control design and operation;
• often becomes a sales requirement for enterprise and regulated customers, particularly in North America.

Who does it apply to?

No law requires SOC 2. It is market-driven: customers write it into contracts, procurement policies and vendor-risk programmes. It is most common for:

• cloud and SaaS providers;
• data-centre, hosting and managed IT providers;
• fintech, payroll, healthcare technology and other providers processing sensitive data for clients.

The organisation that is examined is the service organisation. Its customers are user entities.

Scope and applicability considerations

Scoping decisions shape what the report says.

• The system. The report covers a defined system: infrastructure, software, people, procedures and data used to deliver specific services.
• Trust Services Criteria categories. Security is always included. The organisation adds Availability, Processing Integrity, Confidentiality and Privacy where relevant to its service commitments.
• Subservice organisations. If the provider relies on others, for example a cloud hosting provider, the report uses either the carve-out method (the subservice organisation’s controls are excluded, and the customer must look at that provider’s own report) or the inclusive method (they are included and tested).
• Period. For a Type 2 report, the service organisation and auditor agree the review period. Periods of several months up to a year are common.

How are the criteria structured?

The Trust Services Criteria are publicly available from the AICPA. Their structure follows the COSO internal control framework.

The common criteria are grouped into series covering the control environment, communication and information, risk assessment, monitoring activities, control activities, logical and physical access, system operations, change management and risk mitigation. Each criterion has points of focus: illustrative characteristics that help with design and evaluation. They are not a mandatory checklist.

Type 1 and Type 2 reports

What is inside a SOC 2 report?

1. The independent service auditor’s report. The opinion, including any qualification.
2. Management’s assertion. Management’s own statement about the description and the controls.
3. The description of the system. Prepared by management using the AICPA description criteria (DC 200). It covers services, components, boundaries, commitments and relevant changes.
4. Trust Services Criteria and related controls. And, for a Type 2, the auditor’s tests of controls and results, including any exceptions.
5. Complementary user entity controls (CUECs). Controls the customer must operate for the overall control objectives to be met, such as managing their own users’ access.

Readers should go beyond the opinion. They should check the period, the scope, the carved-out subservice organisations, the exceptions and the CUECs that apply to them.

Readiness and the examination lifecycle

1. Define services and commitments. What do contracts, SLAs and the website promise customers?
2. Choose TSC categories and scope the system.
3. Readiness assessment. Compare existing controls to the criteria and fix the gaps. This is advisory work, separate from the examination.
4. Operate the controls. For a Type 2, controls must run for the whole period and produce evidence.
5. Examination. The auditor requests evidence, samples transactions, inspects configurations and interviews staff.
6. Report issued. Then the cycle repeats. Most organisations aim for continuous, back-to-back Type 2 periods.

Evidence and documentation concepts

Auditors typically look for evidence such as:

• governance records: policies, risk assessments, board or management oversight;
• access records: provisioning tickets, periodic access reviews, termination evidence;
• change records: approvals, testing and segregation between development and production;
• operations: monitoring alerts, incident tickets, vulnerability scans and remediation;
• vendor management: due diligence on subservice organisations and review of their reports;
• HR: background checks where permitted, training completion and policy acknowledgements.

Evidence that systems produce automatically, consistently across the whole period, is far stronger than screenshots gathered just before fieldwork.

Governance and accountability

Management, not the auditor, is responsible for the system description, for designing and operating controls, and for its written assertion. An effective SOC 2 programme has a named owner, control owners across engineering, IT, HR and legal, and a calendar of recurring control activities. That way the report reflects normal operations rather than an annual effort.

The difference between advisory support and an examination

Only a licensed CPA firm can perform a SOC 2 examination and sign the report. Readiness consultants, compliance-automation platforms and educational resources such as MajorCyber™ can help an organisation prepare. They cannot issue a SOC 2 report, and a readiness assessment is not a substitute for one. Professional independence rules limit how far an auditing firm can help design the controls it then examines.

Common misconceptions and pitfalls

• “We passed SOC 2.” There is no pass mark. There is an opinion, and possibly exceptions.
• Treating points of focus as mandatory. They guide design. Controls should fit the organisation’s actual risks.
• Ignoring carve-outs. A clean report that carves out the hosting provider says nothing about that provider’s controls.
• Forgetting CUECs. Customers are often responsible for part of the control picture and must operate those controls themselves.
• Evidence gaps mid-period. One missed quarterly access review can become a reported exception.

Relationship with other frameworks