How it works
Your client's finance team tells you they migrated the ERP database to a US-based cloud provider last March. There's no ISAE 3402 report because the provider doesn't touch transactions directly. What they do have is a SOC 2. Whether that report actually helps your audit depends on what you do with it.
A SOC 2 report is an assurance report on a service organization's IT controls, mapped to the AICPA Trust Services Criteria (security, availability, processing integrity, and confidentiality/privacy). European auditors encounter them most often when their client uses a US-based SaaS provider for a function that affects financial reporting indirectly. ISA 402.9 requires you to obtain an understanding of the services provided and the controls at the service organization that are relevant to the audit. A SOC 2 gives you that understanding for IT general controls.
The report contains four sections you need to read, not one. The service auditor's opinion sits in Section I. Section II is management's description of the system. Section III contains the control objectives, the controls tested, the test procedures performed, and the results. Section IV lists complementary user entity controls (CUECs) that the service organization assumes your client operates. ISA 402.15 requires you to evaluate whether the description and tests of controls are sufficient for your purposes. The file should tell a story: that evaluation means reading Sections II through IV, not skipping to the opinion and calling it done.
Key Points
- A SOC 2 report covers IT controls, not financial reporting controls (that is a SOC 1).
- The report's period must overlap with your client's fiscal year or you need a bridge letter.
- User entity controls listed in the report are your client's responsibility to operate, not the service organization's.
- Reading only the opinion page is the single most common shortcut that produces inspection findings.
Worked example: Schiphol Payments B.V.
Schiphol Payments B.V. is a Dutch fintech company (FY2024, revenue €85M, IFRS reporter) that uses CloudVault Inc., a US-based provider, for production database hosting.
The engagement team obtains CloudVault's SOC 2 Type II report. It covers January 1 to September 30, 2024. The client's fiscal year ends December 31, so there's a three-month gap to deal with.
Section III reveals two control exceptions. The first: access reviews completed 14 days late in Q2. The second: a backup restoration test that failed and was re-performed. For each exception, the team documents the control, the nature of the deviation, the period affected, and whether additional procedures are needed. The late access review doesn't affect financial data integrity because compensating detective controls (audit logging with daily review) operated throughout the period. This is the ticking and bashing that matters most: systematically tracing each exception back to its impact on the assertions you're testing.
Section IV lists four CUECs: the user entity must enforce MFA on all accounts accessing CloudVault, review user access quarterly, maintain its own backup verification process, and restrict administrative access to named individuals. Schiphol Payments' IT team confirms all four are in place. The engagement team tests a sample.
For the three-month gap, the team obtains a bridge letter from CloudVault confirming no significant changes to controls between October 1 and December 31, 2024.
Taken together, the SOC 2, the bridge letter, the CUEC testing, and the documented exception analysis provide sufficient appropriate evidence over IT general controls at the subservice organization level for Schiphol Payments' FY2024 audit.
What reviewers and practitioners get wrong
Auditors frequently rely on SOC reports without evaluating the CUECs listed in Section IV. The same pattern appears in AFM inspections of Dutch firms using US-hosted platforms, and it's one of the easiest findings to avoid. If the report says "the user entity must enforce MFA," your client needs to actually enforce MFA, and you need to test that they do.
The other recurring mistake is treating a clean SOC 2 opinion as blanket assurance over IT controls without reading Section III. ISA 402.15 requires evaluating whether the specific controls tested and the results are sufficient for the assertions relevant to your audit. A SOC 2 that tested availability controls doesn't cover processing integrity unless those criteria were also in scope. That distinction gets missed more often than anyone in the profession wants to admit.
SOC 1 vs SOC 2
| Dimension | SOC 1 | SOC 2 |
|---|---|---|
| What it covers | Controls relevant to user entities' financial reporting (ICFR) | Controls relevant to the Trust Services Criteria (security, availability, processing integrity, confidentiality, privacy) |
| Governing standard | ISAE 3402 / AT-C 320 | ISAE 3000 (Revised) / AT-C 205 |
| Primary user | External auditors assessing ICFR at a service organization | External auditors, management, regulators, customers assessing IT controls |
| Typical trigger | Payroll processing, fund administration, claims handling, transaction recording | Cloud hosting, SaaS platforms, data centres, identity providers |
The practical question is whether the service affects a financial statement number directly (SOC 1) or affects the IT environment that supports financial reporting indirectly (SOC 2). A cloud payroll processor that calculates wages and posts journal entries needs a SOC 1. A cloud hosting provider that stores the database needs a SOC 2.
Key standard references
AT-C 205 (AICPA) governs SOC 2 engagements in the US. Its international equivalent is ISAE 3000 (Revised), which governs SOC 2-equivalent engagements for European and other non-US jurisdictions. On the user auditor's side, ISA 402.9 requires obtaining an understanding of controls at the service organization, while ISA 402.15 requires evaluating whether the report is sufficient for the specific assertions in your audit.
Related terms
Related reading
Frequently asked questions
What is the difference between a SOC 1 and a SOC 2 report?
A SOC 1 covers controls relevant to user entities' financial reporting (ICFR), governed by ISAE 3402 or AT-C 320. A SOC 2 covers IT controls mapped to the AICPA Trust Services Criteria (security, availability, processing integrity, confidentiality, privacy), governed by ISAE 3000 (Revised) or AT-C 205. The practical question is whether the service affects a financial statement number directly (SOC 1) or affects the IT environment that supports financial reporting indirectly (SOC 2).
Can I rely on a SOC 2 report without reading the full document?
No. ISA 402.15 requires evaluating whether the specific controls tested and the results are sufficient for the assertions relevant to your audit. Reading only the opinion page is the single most common shortcut that produces inspection findings. You must read Section II (system description), Section III (controls and test results), Section IV (CUECs), and the service auditor's description of test procedures.