SOC Reports Explained: SOC 1, SOC 2 and SOC 3 for CISSP

A SOC report is a formal attestation, issued by an independent CPA firm, describing whether a service organisation’s controls are designed and operating as claimed. It exists so that a customer can rely on a supplier it has no right to inspect. SOC 1 covers controls affecting financial reporting, SOC 2 covers security and the other Trust Services Criteria, and SOC 3 is the publishable summary of a SOC 2.

That distinction matters well beyond compliance paperwork. Every time an organisation moves a process to a cloud provider, a payroll bureau or a SaaS platform, it inherits risk from a system it cannot walk into and cannot scan. The SOC report is the instrument the accounting profession built to close that gap, and CISSP Domain 6 candidates are expected to know which report answers which question. This guide covers the three report types, the two report forms, what is actually inside the document, and the distinctions most likely to appear as distractors.

What is a SOC report?

SOC stands for Service Organization Control. The reports are a framework from the American Institute of Certified Public Accountants (AICPA), performed as attestation engagements under SSAE 18, the Statement on Standards for Attestation Engagements.

The word “attestation” is doing real work there. The CPA firm is not writing a consultancy report or a list of recommendations. It is expressing a formal opinion, in the same professional register as a financial audit opinion, and it carries professional liability.

Service organisation and user entity

Two terms recur throughout every SOC document, and getting them the wrong way round makes the whole framework confusing.

A service organisation is the company providing the service: a cloud host, a payment processor, a data centre, a SaaS platform, a payroll bureau. A user entity is the customer organisation that consumes that service and relies on the provider’s controls as part of its own control environment.

The relationship is asymmetric, and that asymmetry is the entire reason SOC reports exist. The user entity carries the consequences when the provider’s controls fail, but has no right to enter the provider’s data centre, review its change tickets, or run a scan against its infrastructure.

Why a report exists instead of an inspection

If every customer audited every provider directly, a cloud host with 4,000 customers would host 4,000 audits a year, and each customer would still see only what the provider permitted. The SOC model inverts that: the provider commissions one independent examination, and every customer relies on the resulting report.

This is a security audit in the strict sense, and the governing principle is the same one that recurs everywhere else in this area: independence determines who can rely on the result. A third-party CPA firm’s opinion is relied upon by outsiders precisely because that firm did not build, run or manage the controls it examined.

Reviewing a supplier’s SOC report is also a textbook act of due diligence, the investigation that precedes and justifies a decision. It sits inside the wider discipline of supply chain risk management, where the exam’s recurring caveat applies in full: you can outsource the process, but you cannot outsource accountability for it.

SOC 1, SOC 2 and SOC 3: what each one covers

The three reports differ on three axes: what they examine, who is allowed to read them, and how much detail they carry.

SOC 1: controls over financial reporting

A SOC 1 report examines controls at the service organisation that could affect its user entities’ internal control over financial reporting, usually abbreviated ICFR. It is performed under SSAE 18, AT-C section 320.

The classic case is a payroll provider. If its systems miscalculate deductions or process transactions twice, the errors flow directly into its customers’ financial statements. The customer’s own financial auditor therefore needs assurance about controls sitting inside a company they are not auditing, and the SOC 1 report supplies it.

SOC 1 is a restricted-use report, released to the service organisation, its user entities and those user entities’ auditors. It has limited direct relevance to security work, but you should recognise it on sight so that you do not accept one when the question at hand is about security.

SOC 2: the Trust Services Criteria

SOC 2 is the report that matters most to a security professional. It examines controls against the AICPA’s Trust Services Criteria, and it is performed under SSAE 18, AT-C section 205.

A SOC 2 is detailed. It contains a description of the system, management’s written assertion about it, the auditor’s opinion, and then the part practitioners actually read: each control, the tests the auditor performed on it, and the results, including any exceptions found.

SOC 2 is also restricted use. A provider will normally release it to existing customers and serious prospects under a non-disclosure agreement, because the document describes its control environment in enough detail to be useful to an attacker.

SOC 3: the public version of a SOC 2

A SOC 3 report covers exactly the same Trust Services Criteria as a SOC 2, over the same period, from the same engagement. What changes is what is published: the system description is condensed and the detailed control tests and results are removed.

That makes SOC 3 a general use report. Providers post them on their websites and cite them in sales material. The trade-off is that a SOC 3 tells you an unqualified opinion was reached without letting you see what was tested or what exceptions were noted, so it is evidence of assurance rather than a basis for your own assessment.

CISSP Exam Note: There is no such thing as a “SOC Type 3”. Type 1 and Type 2 are forms that SOC 1 and SOC 2 reports take. SOC 3 is a separate report type. A question that mixes the two vocabularies is testing whether you know the difference between the report family and the report form.

The five Trust Services Criteria

A SOC 2 is scoped against five criteria, and the most commonly missed fact about them is that only one is compulsory.

Security is the common criteria, and it appears in every SOC 2 without exception. It addresses protection of the system against unauthorised access, whether physical or logical.

The remaining four are optional, and the service organisation selects them based on the commitments it makes to its customers:

• Availability: the system is available for operation and use as committed or agreed. This is about meeting a commitment, not about achieving some absolute uptime figure.
• Processing integrity: system processing is complete, valid, accurate, timely and authorised. Note that this addresses processing, not the data itself; a system can process incorrect input perfectly.
• Confidentiality: information designated as confidential is protected as committed. This depends on the organisation having a working data classification scheme, because something must designate what is confidential in the first place.
• Privacy: personal information is collected, used, retained, disclosed and disposed of in line with the organisation’s privacy notice.

The practical consequence is that “we have a SOC 2” tells you less than it appears to. A provider whose report covers security alone has a genuine SOC 2 and has been examined on nothing about availability or privacy. Reading the scope section is the difference between assurance and the appearance of assurance.

Type 1 vs Type 2: what the exam is really asking

Both SOC 1 and SOC 2 come in two forms. The distinction is about time, and it is the single most testable thing in this topic.

A Type 1 report evaluates whether controls are suitably designed as at a specified date. It is a snapshot. It answers the question “if these controls worked as described, would they achieve the objective?” and it makes no claim whatsoever about whether they actually ran.

A Type 2 report covers a period, typically 6 to 12 months, and evaluates both design and operating effectiveness. The auditor samples evidence across the whole window: change tickets from March, access reviews from June, backup restoration tests from September.

The gap between them is large in practice. An organisation can pass a Type 1 by writing good policies the week before the examination date. It cannot pass a Type 2 that way, because a Type 2 asks for a year’s worth of evidence that those policies were followed.

CISSP Exam Note: When a scenario asks which report to request from a vendor, the answer is Type 2 unless the scenario gives a specific reason it cannot be. The usual legitimate reason is that the provider is new to the market and has not yet completed an observation period, in which case a Type 1 is a reasonable interim position with a Type 2 to follow.

What is actually inside a SOC 2 report

Candidates who have never opened one tend to imagine a certificate. It is a document of typically 60 to 100 pages, in a fixed structure.

The auditor’s opinion

The opinion is the report’s conclusion, and it takes one of four forms. Unqualified means the controls met the criteria, and it is the outcome providers advertise. Qualified means they met the criteria except in specified respects, and the exceptions are named. Adverse means they did not meet the criteria. A disclaimer means the auditor could not gather enough evidence to form an opinion at all.

A qualified opinion is not automatically disqualifying. What matters is whether the named exception touches the controls you are relying on, which is a judgement only the user entity can make.

Complementary user entity controls

Near the back of every SOC 2 sits a section listing complementary user entity controls, or CUECs. These are the controls the report assumes you are operating, without which the provider’s controls do not achieve their objectives.

A cloud provider may state that it enforces multi-factor authentication only if the customer configures it, or that access revocation depends on the customer submitting leaver notifications promptly. Skipping this section is how organisations end up believing they have inherited protections they were actually required to build.

Carve-out vs inclusive method

Service organisations depend on other service organisations. A SaaS platform runs on a cloud host, which is itself a subservice organisation. The report has to say how those dependencies were handled.

Under the carve-out method, the subservice organisation is named and its controls are excluded from the scope of the examination. Under the inclusive method, they are tested within the same engagement and reported together.

The carve-out method is far more common, and it is not a red flag by itself. It does mean the assurance is incomplete until you obtain the subservice organisation’s own SOC report, which is exactly how a supply chain assessment ends up several layers deep.

How SOC reports differ from audits, assessments and penetration tests

Adjacent activities that all produce a document about security are easily confused, and plausible distractors are built from them. Separating them by deliverable works reliably.

A SOC 2 and a penetration test answer genuinely different questions. The SOC 2 asks whether a control environment exists and functions over time. The penetration test asks whether a particular defence holds against a particular attack today. Neither substitutes for the other, and a scenario that offers both as options is usually testing whether you know which question was asked.

International equivalents

SOC reports come from a United States professional body, but the model is used worldwide, and several jurisdictions maintain closely aligned frameworks.

The international equivalents are the ISAE standards from the International Auditing and Assurance Standards Board: ISAE 3402 corresponds to SOC 1, and ISAE 3000 underpins engagements analogous to SOC 2. Canada uses CSAE 3416 and Australia ASAE 3402 for the SOC 1 equivalent.

For the exam, the useful point is not the numbering but the principle: third-party assurance about a service provider’s controls is a globally recognised model, and a multinational assessing suppliers across borders will encounter the same structure under different names.

Where SOC reports fall short

Treating a SOC 2 as proof of security is a mistake a well-written scenario will expose.

A SOC report is historical. A Type 2 covering January to December, issued in February, tells you about controls that operated in a period that has ended. It says nothing about the reorganisation the provider went through last month.

The service organisation defines its own scope. It selects which criteria to include, which systems are in scope, and which subservice organisations to carve out. A narrow scope produces a clean report cheaply, and the scope section is where you find out.

It attests to controls, not to outcomes. A provider can hold an unqualified SOC 2 and still suffer a breach, because a control environment judged effective is not a control environment that is perfect.

It does not transfer accountability. This is the point most worth holding on to. Reading a supplier’s SOC 2 discharges your duty of investigation; it does not move the consequences of a supplier failure onto the supplier or its auditor.

Conclusion

SOC reports are the mechanism by which trust in a service provider becomes evidence rather than assertion. SOC 1 addresses financial reporting controls, SOC 2 addresses security and the other Trust Services Criteria, and SOC 3 makes a publishable summary of the same work. Type 1 asks whether controls were designed properly on one date; Type 2 asks whether they actually operated across a period, and that is the one worth having.

Questions in this area rarely ask you to recite these definitions. They are more likely to ask you to pick the right report for a scenario, to spot that a clean opinion covers a narrower scope than the question implies, or to recognise that accountability stayed with the customer all along.

Third party assurance questions tend to reward candidates who have practised distinguishing these under time pressure. Our LSM CISSP practice tests drill exactly these scenarios: which SOC report a situation calls for, Type 1 against Type 2, and the audit against assessment against penetration test distinctions, with full explanations for every answer.

Quick reference for the CISSP exam

The three reports

• SOC 1: internal control over financial reporting. SSAE 18, AT-C 320. Restricted use.
• SOC 2: Trust Services Criteria. SSAE 18, AT-C 205. Restricted use, usually under NDA.
• SOC 3: same criteria as SOC 2, detail removed. General use, freely publishable.

Type 1 against Type 2

• Type 1: design only, as at a single date. A snapshot.
• Type 2: design and operating effectiveness across a period, typically 6 to 12 months.
• When assessing a vendor, ask for Type 2.

The five Trust Services Criteria

• Security is the common criteria and is mandatory in every SOC 2.
• Availability, processing integrity, confidentiality and privacy are optional and selected by the service organisation.

Common exam mistakes

• Calling SOC 3 a “Type 3”. Types belong to SOC 1 and SOC 2; SOC 3 is a report type.
• Assuming a SOC 2 covers all five criteria. Most cover security alone or security plus availability.
• Treating an unqualified opinion as proof of security rather than an opinion on controls.
• Forgetting complementary user entity controls, which are obligations placed on the customer.
• Believing a carve-out indicates weakness. It indicates a scope boundary, and it means another report is needed.
• Accepting a SOC 2 where the scenario actually calls for a penetration test, or the reverse.

Spotting the topic in a scenario

Wording about a vendor, supplier, cloud provider or outsourced process, combined with a request for assurance or evidence of controls, points at SOC reports. If the scenario mentions financial statements, it is SOC 1. If it mentions security, availability or privacy commitments, it is SOC 2. If it needs to be shared publicly, it is SOC 3.