SOC 2 (System and Organization Controls 2): SOC 2 – Tutorial (about 60 minutes)

SOC 2 (System and Organization Controls 2) is a way for an independent accountant to tell the customers of a service company, in a formal report, whether that company's controls over its systems are well designed and, in the longer form of the report, whether they actually worked over a period of months. It was created by the American Institute of Certified Public Accountants (AICPA) and is now the most common way for software-as-a-service, cloud, hosting, payroll and data-processing companies to answer the question "can we trust you with our data?". After this tutorial you will be able to explain what a SOC 2 report is and is not, read its main sections, map controls to the Trust Services Criteria, plan a first SOC 2 project and use other companies' reports properly in vendor risk management.

Free tutorial · about 60 minutes · 7 lessons · 4 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: SOC 2 is not a single numbered standard but a reporting framework made of three AICPA pieces. The criteria that controls are evaluated against are the 2017 Trust Services Criteria (TSP section 100), in their current form "with revised points of focus – 2022"; the 2022 update changed only the supporting points of focus, not the criteria themselves. The system description is prepared against the 2018 Description Criteria (DC section 200), with implementation guidance revised in 2022. The examination is carried out under the AICPA attestation standards (AT-C sections 105 and 205), as explained in the AICPA Guide SOC 2 Reporting on an Examination of Controls at a Service Organization, whose latest edition appeared in October 2022. These remain the documents in force. On 26 October 2026 the AICPA Assurance Services Executive Committee released exposure drafts of proposed 2027 Trust Services Criteria and Description Criteria, announced publicly on 28 October 2026. They propose consolidating duplicated concepts, removing some criteria, adding others where clarity is needed and rewording the rest, and they add points of focus on artificial intelligence (AI governance, model monitoring, prompt manipulation, data poisoning, transparency of AI-generated outputs, training data management and risks from automated decision-making). Comments are invited until 15 January 2027; if approved, the 2027 criteria would apply to engagements beginning on or after 31 December 2027, with early adoption allowed. The proposals are drafts only: this tutorial teaches the 2017 criteria that apply today and points out where change is expected. Verified 2026-10-29.

Who this is for: engineers, site reliability and platform teams, security and compliance staff, product and engineering managers at service companies preparing for their first SOC 2, and the people on the other side of the table — procurement, vendor risk and internal audit teams who receive SOC 2 reports from suppliers and have to decide what they mean.

Prerequisites: none. A general idea of how a cloud application is built and operated helps, but every audit and security term is explained when it first appears.

By the end of this tutorial:

You will be able to explain what SOC 2 is, who issues it, and why it is an attestation report rather than a certificate.
You will be able to describe the five Trust Services Categories, the common criteria CC1–CC9 and the role of points of focus.
You will be able to tell a Type 1 report from a Type 2 report and choose which one an organisation needs.
You will be able to name the main sections of a SOC 2 report and the purpose of each one.
You will be able to plan a first SOC 2 project: scope, readiness, remediation, evidence and the observation period.
You will be able to review a supplier's SOC 2 report critically, including exceptions, complementary user entity controls and subservice organisations.
You will be able to explain how SOC 2 relates to SOC 1, SOC 3, ISO/IEC 27001 and other frameworks.

Lesson 1 – Origins, purpose and scope

The problem SOC 2 solves

Almost every organisation now hands part of its work to someone else. A hospital stores records in a cloud application, a bank uses an outside payroll processor, a retailer runs its website on a hosting platform and a software company sends support tickets to a help-desk service. Each of those suppliers holds data or runs processes that matter to the customer, and each customer has a legitimate question: how do I know the supplier protects my information and keeps the service running?

Without a common answer, every customer sends its own questionnaire, asks for its own audit visit and receives a slightly different story. A fast-growing supplier can end up answering hundreds of questionnaires a year, and the customers still have no independent evidence. SOC 2 replaces that chaos with one standardised report, written by an independent certified public accountant (CPA), which every customer can read. The supplier pays for one examination and shares the result many times; the customers get an opinion from a professional who is bound by auditing standards, independence rules and peer review.

From SAS 70 to the SOC family

Reports by auditors on outsourced services are not new. For many years the reference was SAS 70, an AICPA auditing standard from the early 1990s designed to help the financial statement auditors of a company rely on controls at a service provider, such as a payroll bureau. Over time SAS 70 reports were stretched far beyond their purpose: providers used them to reassure customers about security and availability, topics the standard was never designed for. In 2011 the AICPA replaced this arrangement with the System and Organization Controls (SOC) family. The report on controls relevant to customers' financial reporting became SOC 1, and a new report, SOC 2, was created specifically for security, availability, processing integrity, confidentiality and privacy. SOC 3, a short general-use report on the same subject matter, completed the family. The attestation standards behind these reports were later reorganised (SSAE 18 took effect in 2017 and further updates such as SSAE 21 followed), and in 2017 the old "Trust Services Principles" were replaced by today's Trust Services Criteria, aligned with the COSO internal control framework.

What SOC 2 is — and what it is not

Three ideas define SOC 2 and are worth fixing early:

It is an examination leading to an opinion. A licensed CPA firm examines the service organisation's description of its system and its controls and expresses a professional opinion. Nobody "passes SOC 2" or becomes "SOC 2 certified"; a company receives a report that contains an opinion, and the reader decides what the opinion and its details mean for them.
It is criteria-based, not control-prescriptive. The Trust Services Criteria describe outcomes, such as restricting logical access to authorised users. The company chooses and designs its own controls to meet them. Two companies with very different technology can both receive clean reports.
It is about a defined system and defined commitments. The report covers the system the company has chosen to describe — a product, platform or service — and judges controls against the promises the company makes to its customers and the requirements it needs to meet them.

Who uses SOC 2

The organisations that produce SOC 2 reports are called service organisations: SaaS vendors, cloud and data-centre providers, managed service providers, payment and payroll processors, data analytics companies and increasingly AI platform providers. The organisations that read the reports are user entities (customers) and their auditors, regulators and business partners. Although SOC 2 is an American framework, it is used worldwide because buyers in many countries recognise it, particularly in technology procurement. Outside the United States, comparable assurance reports are often issued under the international standard ISAE 3000, sometimes structured around the same Trust Services Criteria.

Scope of a SOC 2 examination

A SOC 2 report always covers the security category, because the common criteria apply to every engagement. The company may add any of the other four categories — availability, processing integrity, confidentiality and privacy — depending on what its customers rely on. It also chooses the boundaries of the system: which product lines, environments, locations and supporting teams are included. A narrow scope makes the examination easier but the report less useful; a scope that leaves out the parts customers care about will be noticed by careful readers.

Lesson 2 – Key concepts and vocabulary

SOC 2 uses accounting and audit language that can surprise engineers. These terms appear in every report and every audit conversation.

Service organisation – the company whose system and controls are examined and which provides services to customers.
User entity – a customer of the service organisation that uses the service and relies on the report. "Report users" also include their auditors and, for some reports, prospective customers.
Service auditor – the independent CPA firm that performs the examination and signs the opinion. In SOC 2 work the word "auditor" is common even though the engagement is formally an examination under the attestation standards.
Attestation – an engagement in which a practitioner reports on subject matter, or on someone else's assertion about it, against suitable criteria. SOC 2 is an attestation, which is why the output is a report and opinion rather than a certificate.
Management's assertion – a written statement by the service organisation's management that its description is fairly presented and its controls are suitably designed (and, for Type 2, operated effectively). The auditor's opinion addresses this assertion and the underlying subject matter.
Trust Services Criteria (TSC) – the AICPA criteria used to evaluate controls, grouped into five categories: security, availability, processing integrity, confidentiality and privacy.
Common criteria – the criteria labelled CC1 to CC9 that make up the security category and also underpin the other categories; they are always in scope.
Points of focus – illustrative characteristics that help management and auditors interpret a criterion. They are guidance, not a checklist: an organisation is not required to address every point of focus.
Service commitments and system requirements – the promises the company makes to customers (for example in contracts, service level agreements and published security pages) and the internal requirements needed to keep them. Controls are judged by whether they provide reasonable assurance these are achieved.
System description – the narrative written by management, using the Description Criteria, that explains the services, the system's components (infrastructure, software, people, procedures and data), the boundaries and the relevant controls.
Type 1 report – a report on the fairness of the description and the suitability of control design as of a specific date.
Type 2 report – a report that adds the operating effectiveness of controls throughout a defined period, with the auditor's tests and their results.
Exception (deviation) – a test result showing a control did not work as described for one or more samples, for example a leaver whose access was removed late.
Complementary user entity controls (CUECs) – controls the service organisation assumes its customers operate, without which the criteria may not be met, such as customers managing their own user accounts.
Subservice organisation – a supplier of the service organisation whose services are likely relevant to the criteria, such as a cloud infrastructure provider or data centre.
Complementary subservice organisation controls (CSOCs) – controls the service organisation assumes its subservice organisations operate, such as physical security at the cloud provider's data centres.
Carve-out and inclusive methods – the two ways to treat a subservice organisation: excluded from the description and opinion (carve-out, the most common) or included and tested (inclusive).
Bridge letter – a letter from the service organisation's management, not from the auditor, covering the gap between the end of the last report period and today; also called a gap letter.

Two further phrases are worth understanding. Reasonable assurance means a high but not absolute level of confidence: no set of controls can guarantee that nothing ever goes wrong, and the report never claims they do. Suitably designed means that, if the controls operate as described, they would be expected to meet the criteria; operating effectively means they did operate that way, consistently, during the period.

Lesson 3 – Structure of the Trust Services Criteria

Five categories, one foundation

The Trust Services Criteria are organised into five categories. Security is the foundation and is mandatory; the other four are optional additions that build on it.

Figure 1 – How the Trust Services Criteria are organised: mandatory common criteria plus four optional categories, each interpreted with points of focus.

A useful way to think about the categories:

Security asks whether information and systems are protected against unauthorised access, disclosure and damage that could compromise the other categories or the company's ability to meet its commitments.
Availability asks whether the system is available for operation and use as committed — capacity management, backups, recovery infrastructure and tested recovery plans.
Processing integrity asks whether processing is complete, valid, accurate, timely and authorised — relevant to services that calculate, transform or move transactions, such as payroll or payments.
Confidentiality asks whether information designated as confidential (contracts, intellectual property, customer business data) is identified, protected and disposed of as committed.
Privacy asks whether personal information about individuals is collected, used, retained, disclosed and disposed of in line with the company's privacy commitments.

Confidentiality and privacy are often confused. Confidentiality concerns any information an organisation has agreed to protect, whether or not it identifies a person; privacy concerns personal information specifically and focuses on the individual's rights and the organisation's notice and consent obligations.

The common criteria CC1–CC9

The first five groups of common criteria follow the five components of the COSO Internal Control – Integrated Framework (2013), the widely used model of internal control from the Committee of Sponsoring Organizations of the Treadway Commission. Its 17 principles are reflected in CC1 to CC5. The last four groups add criteria specific to information systems. In the 2017 criteria there are 33 common criteria in total.

Group	Theme (paraphrased)	Typical controls
`CC1`	Control environment: integrity, ethics, oversight, structure, competence, accountability	Code of conduct, board or leadership oversight of security, background checks, security training, defined roles
`CC2`	Communication and information: quality information, internal and external communication	Published security policies, system documentation, customer notices, a channel to report incidents
`CC3`	Risk assessment: objectives, risk identification, fraud risk, assessing change	Annual risk assessment, risk register, fraud risk review, review of significant changes
`CC4`	Monitoring activities: ongoing and separate evaluations, communicating deficiencies	Internal audits, control self-assessments, continuous compliance monitoring, tracking of remediation
`CC5`	Control activities: selecting controls, technology controls, policies and procedures	Control framework mapped to risks, documented procedures, technology general controls
`CC6`	Logical and physical access controls	Single sign-on, multi-factor authentication, joiner-mover-leaver process, access reviews, encryption, endpoint protection
`CC7`	System operations: detecting vulnerabilities and anomalies, responding to and recovering from incidents	Vulnerability scanning, logging and alerting, incident response plan, post-incident reviews
`CC8`	Change management	Peer-reviewed code changes, testing, approval before production deployment, separation of duties
`CC9`	Risk mitigation: business disruption and vendor/business partner risk	Business continuity planning, insurance, vendor due diligence and periodic vendor reviews

Within each group, criteria are numbered (CC6.1, CC6.2 and so on), and auditors and compliance tools use these numbers to map controls. The criteria themselves are short and outcome-focused; this course deliberately paraphrases them rather than reproducing the AICPA text, which you can download from the AICPA after free registration.

The additional categories

Each optional category adds a small set of criteria on top of the common criteria. Availability (A1) covers capacity planning, environmental protections, backup and recovery infrastructure, and testing of recovery plans. Confidentiality (C1) covers identifying and protecting confidential information and disposing of it when no longer needed. Processing integrity (PI1) covers defining processing specifications and controlling inputs, processing, outputs and stored data. Privacy is the largest addition, with eight groups P1 to P8: notice, choice and consent, collection, use and retention and disposal, access by individuals, disclosure and notification, data quality, and monitoring and enforcement.

Points of focus and the 2022 revision

Every criterion is followed by points of focus that suggest what a well-designed set of controls usually considers. The 2022 revision added and clarified points of focus to reflect changes in technology, threats and practice, without changing the criteria themselves. An auditor will not fail a company because it ignored a point of focus, but the points of focus are an excellent planning tool: if none of your controls touch a group of them, you probably have a gap.

The Description Criteria

The second set of criteria, DC section 200, governs the system description rather than the controls. In short, the description must explain the types of services provided, the principal service commitments and system requirements, the components of the system, the boundaries, any significant incidents relevant to the commitments, the applicable criteria and related controls, the complementary user entity and subservice organisation controls, and, for a Type 2, significant changes during the period. A misleading or incomplete description can lead to a modified opinion even when every control worked.

Lesson 4 – How it works in practice

Roles inside the service organisation

A SOC 2 programme is a cross-functional effort. A senior sponsor (often the chief technology officer, chief information security officer or head of compliance) owns the outcome and signs management's assertion with other executives. A compliance or governance, risk and compliance (GRC) lead runs the project, maintains the control list and coordinates evidence. Engineering, IT, human resources, legal and finance each own controls: engineering for change management and logging, IT for laptops and identity, HR for onboarding, training and background checks, legal for contracts and privacy notices, and finance or procurement for vendor management. Many companies also use compliance automation platforms that collect evidence from cloud accounts and identity providers; these help, but the auditor still makes the judgments and the company still owns the controls.

The SOC 2 lifecycle

1. Scope. Decide which service or product the report will cover, which Trust Services Categories to include and where the boundaries lie. Start from what customers ask for: if contracts promise uptime, availability belongs in scope; if the service stores customers' business secrets, confidentiality probably does; privacy is usually added only when the company processes significant personal data on its own behalf or makes public privacy commitments it wants examined.

2. Collect service commitments. Gather the promises the company has made: master service agreements, data processing agreements, service level agreements, the security page on the website and answers given in past questionnaires. These become the yardstick for the description and the controls.

3. Readiness assessment. Map existing practices to the criteria and identify gaps. This is often done with help from a consulting firm or the compliance platform. The independent service auditor can perform a readiness assessment too, but cannot design or operate the controls it will later examine without threatening its independence.

4. Remediate. Write missing policies, introduce tooling (for example multi-factor authentication everywhere, centralised logging, automated access reviews), formalise processes such as change approval and vendor review, and train people. Remediation is usually the longest phase for a first-time company.

5. Choose the report type and period. A Type 1 report can be issued soon after remediation and shows that controls exist and are suitably designed on a given date. A Type 2 requires the controls to operate for a period first. The standards set no fixed minimum length; many customers expect a period of six to twelve months, and a first Type 2 sometimes covers a shorter window such as three months. After the first report, most companies move to back-to-back twelve-month periods so that their reports cover every day of the year.

6. Run the controls and keep evidence. During the observation period every control must operate as described, and the company must keep records: tickets showing approved changes, quarterly access review sign-offs, training completion records, vulnerability scan results, incident tickets and vendor reviews. A control without evidence cannot be shown to have operated.

7. Fieldwork and reporting. The auditor tests the controls, discusses findings, and drafts the report. Management prepares the description and signs its assertion; the auditor issues the opinion.

Writing controls that can be tested

Good SOC 2 controls are specific statements of who does what, how often, and what evidence results. "Access is restricted" is not a testable control. "Production access requests are approved by the system owner in the ticketing system before access is granted; access is reviewed quarterly by engineering managers and removals are completed within five business days" is testable: the auditor can select samples and check approvals, reviews and timings. Make sure every control actually happens the way it is written. Over-promising in the description (for example "daily" reviews that really happen weekly) is one of the main sources of exceptions.

Evidence types and frequency

Auditors distinguish controls by how often they run: per event (each change, each new hire), daily, weekly, quarterly or annually, and automated configuration controls that are always on. Frequency drives sample sizes: a quarterly review in a twelve-month period has only four instances, so the auditor may test all of them, whereas thousands of code changes will be sampled. Automated controls are usually tested by inspecting the configuration and confirming it did not change during the period, which is one reason companies prefer automation where they can.

Lesson 5 – Assessment, reports and opinions

Who can issue a SOC 2 report

A SOC 2 report is issued by a licensed CPA firm that performs the examination under the AICPA attestation standards and is independent of the service organisation. Firms that perform these engagements are subject to quality management requirements and to peer review of their attestation practice. The AICPA advises service organisations to evaluate SOC providers carefully and states that it will act against members who perform these engagements while unlicensed or not enrolled in peer review; reports from unqualified providers or "quick-turn" engagements with little real testing undermine trust in the framework. Consultants, software platforms and non-CPA assessors can help prepare, but they cannot issue the opinion.

There is no certification

Unlike ISO/IEC 27001, SOC 2 has no certificate, no certification body and no register of certified companies. The deliverable is a report with an opinion for a specific system and date or period. Marketing phrases such as "SOC 2 certified" or "SOC 2 compliant" are common but imprecise; a careful reader asks for the report itself and reads it.

Type 1 and Type 2

Aspect	Type 1	Type 2
Time coverage	As of a specific date	Throughout a defined period
Opinion covers	Fair presentation of the description; suitability of design	The same, plus operating effectiveness of controls
Auditor's testing	Walk-throughs and inspection to confirm design and implementation	Detailed tests over samples across the period
Test results in the report	No	Yes, including any exceptions
Typical use	First report, quick evidence of a designed programme	What most customers and their auditors expect on an ongoing basis

Testing techniques

For a Type 2, the auditor combines several techniques for each control: inquiry (asking the people who run the control), observation (watching it happen), inspection (looking at documents, tickets, system configurations and logs) and re-performance (doing the control again independently, for example recalculating whether all leavers were removed). Inquiry alone is never sufficient. For frequent controls the auditor selects a sample from the complete population — every change deployed to production in the period, for instance — so the company must be able to produce complete and accurate populations from its systems.

Anatomy of a SOC 2 report

Figure 3 – The main sections of a SOC 2 Type 2 report and what a reader should look for in each.

Section numbering varies between firms, but the content is consistent. The auditor's report states the scope, the criteria used, the responsibilities of each party, the inherent limitations, any restriction on use and the opinion. Management's assertion mirrors the opinion. The system description is often the most informative part for a customer: it explains how the service is built and run. The controls and tests section lists each criterion, the company's controls, the auditor's tests and the results. Other information provided by management, such as responses to exceptions or descriptions of additional services, is not covered by the opinion.

Types of opinion

Unmodified – the auditor concludes that, in all material respects, the description is fairly presented and the controls were suitably designed (and operated effectively, for Type 2). This is the "clean" opinion.
Qualified – the opinion is clean except for a specific matter, for example controls supporting one criterion did not operate effectively.
Adverse – the problems are so material and pervasive that the description or the controls cannot be relied on.
Disclaimer of opinion – the auditor could not obtain enough evidence to form an opinion.

An unmodified opinion can still sit alongside exceptions. The auditor judges whether the deviations found prevent a criterion from being met; isolated exceptions with compensating controls often do not. That is why report readers must read the test results, not just the opinion paragraph.

Distribution and SOC 3

A SOC 2 report contains detailed information about controls and is intended for specified parties who understand the service and how to use such a report — management, customers, prospective customers and their auditors and regulators. Companies usually share it under a non-disclosure agreement, often through a trust portal. When a company wants something it can publish openly, it can obtain a SOC 3 report: a general-use report based on the same criteria and examination, but without the detailed description of tests and results.

Subservice organisations

Figure 4 – Parties in a SOC 2 examination and how responsibilities are shared through CUECs, CSOCs and subservice organisation reports.

Almost every modern service relies on suppliers such as cloud infrastructure, payment gateways or email delivery services. Under the carve-out method, the description explains what the subservice organisation does and lists the controls the company expects it to operate (CSOCs), but the auditor does not test those controls and the opinion does not cover them. The service organisation is expected to monitor the subservice organisation, typically by reviewing its own SOC 2 report each year; that monitoring control is in scope and tested. Under the inclusive method, the subservice organisation's relevant controls are described and tested as part of the examination, which requires its cooperation and its own assertion, so it is far less common.

Lesson 6 – Worked example: a SaaS company's first SOC 2

The situation

Ledgerly is a fictional 120-person company selling an invoice-automation application to mid-sized companies in Europe and North America. It runs on a public cloud platform, uses a third-party identity provider for staff single sign-on, sends email through a delivery service and stores customers' invoices, supplier bank details and contact data. Three large prospects have paused contracts until they receive a SOC 2 Type 2 report, and the sales team receives about forty security questionnaires each quarter.

Step 1 – Scope and categories

The security lead, Amara, gathers Ledgerly's customer contracts, the data processing agreement and the public security page. The contracts promise 99.9 % monthly availability, encryption of customer data and deletion of data within 30 days of contract end. From these commitments the leadership team chooses security (mandatory), availability (because of the uptime promise) and confidentiality (because of the deletion and protection promises). They consider processing integrity — invoices are calculated — but customers do not rely on Ledgerly's calculations for financial reporting, and the team decides to revisit it next year. Privacy is left out because Ledgerly acts mainly as a processor for its customers, and its personal-data obligations are addressed through the data processing agreement and its privacy programme. The system in scope is the production invoice platform plus the corporate IT, HR and vendor processes that support it; an internal analytics tool is outside the boundary.

Step 2 – Readiness and gaps

Working with a compliance platform and a consultant, Amara maps current practices to the criteria. Ledgerly is in better shape than expected technically — infrastructure is defined as code, production deployments go through pull requests and the cloud environment is encrypted — but the readiness review finds gaps that are typical of a young company:

No formal risk assessment has ever been documented (CC3).
Access reviews are informal and leavers are sometimes removed from secondary tools days later (CC6).
Emergency changes bypass review with no after-the-fact approval (CC8).
There is an incident response plan, but it has never been tested (CC7).
Nobody reviews the cloud provider's or email service's assurance reports (CC9).
Backups exist but restores have never been tested, and there is no capacity monitoring plan (A1).
Customer data deletion at contract end is manual and undocumented (C1).

Step 3 – Remediation

Over three months Ledgerly fixes the gaps. Leadership holds a facilitated risk workshop and records a risk register reviewed quarterly. The HR system now triggers automated removal from the identity provider at termination, and all applications are connected to single sign-on; managers complete quarterly access reviews in the compliance platform. Emergency changes get a mandatory retrospective approval ticket within two business days. The team runs a tabletop incident exercise and writes up lessons learned. A vendor inventory is created, critical vendors are rated, and their SOC 2 reports are collected and reviewed annually. Restore tests are scheduled quarterly and a capacity dashboard is reviewed monthly. A documented, ticketed deletion procedure with a deletion certificate replaces the manual process. Policies are approved by leadership and staff complete security awareness training.

Step 4 – Type 1 first

Because the prospects need something quickly, Ledgerly engages a licensed CPA firm for a Type 1 report as of 1 March. The auditor reviews the description, walks through each control and confirms it is designed and in place. The resulting report lets sales show that the programme exists while the Type 2 period runs, and some prospects accept it together with a commitment to provide the Type 2.

Step 5 – The observation period

The first Type 2 period runs from 1 March to 31 August. Amara's team checks evidence monthly rather than waiting for the auditor: are access reviews signed off, are all changes linked to approved pull requests, did the restore test happen, were vendor reviews completed? In June they discover that one quarterly access review for a finance tool was missed. They complete it late, record the reason, and add a calendar-driven reminder with escalation.

Step 6 – Fieldwork, results and the report

During fieldwork the auditor requests populations and selects samples: 25 production changes out of roughly 1,800, all new hires and leavers in the period, every quarterly access review, the incident tickets, the restore tests and the vendor reviews. Two exceptions are found: the missed access review for the finance tool, and one leaver whose access to a minor tool was removed eight days after departure. The auditor considers the exceptions, the compensating controls (single sign-on removal happened on time, and the minor tool had no customer data) and concludes the related criteria were still met. Ledgerly receives an unmodified opinion with two exceptions disclosed in the test results, and management adds a response describing the corrective actions in the other information section.

The description lists CUECs — for example, customers are responsible for managing their own users' access to Ledgerly, for configuring multi-factor authentication for those users and for reviewing exported data. It uses the carve-out method for the cloud provider and the email delivery service and lists the CSOCs expected from them, such as physical data-centre security.

Step 7 – Ongoing operation

Ledgerly moves to annual periods running from 1 September to 31 August. When a customer asks for assurance in November, the sales team provides the latest Type 2 report and a bridge letter from management stating that there have been no significant changes to the system or controls since 31 August. Amara also tracks the AICPA's proposed 2027 criteria: because Ledgerly is adding an AI-based invoice-matching feature, the new AI points of focus are likely to become relevant, and she adds a review of model monitoring and training-data controls to next year's plan.

What the example shows

Ledgerly's journey illustrates the central ideas of SOC 2: scope follows commitments; controls are the company's own design; evidence must exist for every instance of a control; exceptions are normal and must be read in context; and responsibilities shared with customers and suppliers are made explicit. It also shows the reader's side: a careful customer of Ledgerly would read the description, check that its own users' access management (a CUEC) is in place, note the two exceptions and confirm that the cloud provider is covered by its own report.

Lesson 7 – Relationship to other standards and frameworks

The SOC family

SOC 1 reports on controls at a service organisation that are relevant to user entities' internal control over financial reporting — for example a payroll processor or a fund administrator — and is used mainly by customers' financial auditors. SOC 1 uses control objectives defined by the service organisation rather than the Trust Services Criteria. SOC 2 addresses security, availability, processing integrity, confidentiality and privacy for a broader audience. SOC 3 is the general-use summary of a SOC 2 examination. The AICPA also offers SOC for Cybersecurity, which reports on an entity's whole cybersecurity risk management programme rather than a single service, and SOC for Supply Chain, which applies similar criteria to companies that produce, manufacture or distribute goods. A company may need both SOC 1 and SOC 2 if its service affects customers' financial reporting and also holds their sensitive data.

SOC 2 and other frameworks

Framework	What it is	Output	Relationship to SOC 2
ISO/IEC 27001	International standard for an information security management system (ISMS), with a reference set of controls in Annex A	Certificate from an accredited certification body, usually three-year cycle with surveillance audits	Overlaps heavily in controls; ISO certifies a management system, SOC 2 gives a detailed opinion on a specific system's controls. Many companies hold both and map one control set to both.
SOC 1 (AT-C 320 / ISAE 3402)	Report on controls relevant to customers' financial reporting	Type 1 or Type 2 report with opinion	Same report mechanics, different criteria and audience; ISAE 3402 is the international counterpart.
ISAE 3000	International standard for assurance engagements other than audits of historical financial information	Assurance report	Used outside the US for SOC 2-style reports, sometimes against the Trust Services Criteria.
CSA STAR	Cloud Security Alliance assurance programme based on the Cloud Controls Matrix (CCM)	Self-assessment or third-party attestation/certification listed in the STAR Registry	STAR Attestation is delivered as a SOC 2 examination with the CCM as additional criteria.
NIST Cybersecurity Framework 2.0	Voluntary framework of cybersecurity outcomes organised by functions	No certificate; used for self-assessment and target profiles	Useful for structuring a programme; the AICPA publishes mappings from the Trust Services Criteria to NIST and other frameworks.
PCI DSS	Payment card industry security standard	Report on Compliance or self-assessment questionnaire	Prescriptive for cardholder data; SOC 2 does not replace it, though controls can be shared.

Mapping and "SOC 2+"

Because SOC 2 is criteria-based, a company can design one set of controls that also satisfies ISO/IEC 27001, the Cloud Controls Matrix and customer-specific requirements. The AICPA publishes mapping documents between the Trust Services Criteria and other frameworks. A SOC 2 examination can also include additional subject matter or criteria — for example HIPAA security requirements or the CSA Cloud Controls Matrix — in what is informally called a "SOC 2+" report. This avoids a separate audit for each framework while keeping the SOC 2 structure.

Choosing between SOC 2 and ISO/IEC 27001

The choice is usually driven by the market. North American technology buyers commonly ask for SOC 2; buyers in Europe, Asia and the public sector often ask for ISO/IEC 27001. ISO/IEC 27001 demonstrates that a management system exists and improves continually; SOC 2 Type 2 gives a customer a detailed account of how specific controls were tested and what was found. The two complement each other, and the shared control work makes holding both much cheaper than doing them separately.

Common pitfalls and best practices

Pitfalls seen repeatedly in SOC 2 programmes:

Treating SOC 2 as a certificate – announcing "we are SOC 2 certified" and stopping there, when what matters is the opinion, the scope and the exceptions in a specific report.
Scoping to avoid scrutiny – leaving out the product, environment or category customers actually depend on. Experienced readers notice, and the report loses value.
Over-promising in the description – describing controls as more frequent or stricter than reality, which produces exceptions that could easily have been avoided.
Evidence as an afterthought – running controls without keeping records, then scrambling at fieldwork. A control that cannot be evidenced is treated as not having operated.
Ignoring the vendor criteria – never reviewing subservice organisations' reports, leaving CC9 and the CSOC assumptions unsupported.
Reading only the opinion – customers who file a supplier's report without checking scope, period, exceptions and CUECs gain false comfort.
Choosing the cheapest, fastest report provider – engagements with little real testing, or providers that are not licensed CPA firms, may be rejected by informed customers and are the reason the AICPA urges careful evaluation of SOC providers.

Best practices that make SOC 2 easier and more valuable:

Start from commitments – let contracts, service levels and published promises drive scope and controls.
Write testable controls – state who, what, how often and what evidence, and make sure reality matches the words.
Automate where possible – identity lifecycle, configuration baselines, logging and evidence collection reduce both effort and exceptions.
Monitor continuously – review evidence monthly during the period and fix missed controls quickly, documenting why they were missed.
Keep reports back-to-back – use consecutive twelve-month periods and issue bridge letters so there are no unexplained gaps.
Use one control framework for many standards – map controls to SOC 2, ISO/IEC 27001 and other requirements once.
Review suppliers' reports with a checklist – scope, period, opinion, exceptions, CUECs you must implement, and subservice organisations you need to cover separately.
Watch the 2027 criteria – follow the AICPA exposure drafts and plan for new AI-related points of focus if you build or use AI in the system.

Summary and key takeaways

SOC 2 is an AICPA attestation report in which an independent, licensed CPA firm gives an opinion on a service organisation's system description and controls; there is no certificate.
Controls are evaluated against the 2017 Trust Services Criteria (with 2022 revised points of focus) and the description against the 2018 Description Criteria; proposed 2027 criteria are out for comment and not yet in force.
Security, made of the common criteria CC1–CC9, is always in scope; availability, processing integrity, confidentiality and privacy are optional and chosen according to commitments.
A Type 1 report covers description and design at a point in time; a Type 2 adds operating effectiveness over a period, with test results.
Points of focus guide interpretation but are not a mandatory checklist; the company designs its own controls.
Exceptions are common and must be read in context; an unmodified opinion can coexist with disclosed exceptions.
CUECs and subservice organisations (carve-out or inclusive) show how responsibility is shared with customers and suppliers.
SOC 2 sits in a family with SOC 1 and SOC 3 and maps well to ISO/IEC 27001, CSA STAR and other frameworks.

Reflection questions

Think of a service your organisation provides or buys. Which of the four optional Trust Services Categories would its customers rely on, and which commitments justify including them?
Pick one control you know well, such as offboarding or code review. Rewrite it as a testable SOC 2 control and list the evidence an auditor would ask for.
A supplier's report contains an unmodified opinion but three exceptions in access controls. What would you check before accepting the report, and what would you ask the supplier?
Which complementary user entity controls would your organisation have to operate when using a typical SaaS application, and who in your organisation would own them?
How would you explain to a sales team the difference between "we have a SOC 2 Type 2 report" and "we are SOC 2 certified", and why does the difference matter to customers?