SOC 2 vs ISAE 3402: Mapping Controls Across Both Frameworks

Key takeaways

Why a SOC 2 report cannot substitute for an ISAE 3402 report when you need audit evidence over controls relevant to financial reporting
How the control objectives in each framework map to each other, and where they don't overlap at all
When a client's service organisation has both reports, how to determine which one supports your audit procedures
What documentation ISA 402 requires from the user auditor when a service organisation provides a SOC 2 instead of an ISAE 3402

The fundamental difference: what each report covers

Your client's SaaS provider sends over a SOC 2 Type 2 report. The engagement partner asks you to use it to support your reliance on the provider's controls over financial reporting. You open it. The report covers security, availability, and confidentiality. It says nothing about controls over financial transaction processing. That's not an oversight. That's the difference between SOC 2 and ISAE 3402.

ISAE 3402 exists for one purpose: to provide user auditors with evidence about controls at a service organisation that are relevant to user entities' financial statements. The control objectives in an ISAE 3402 report are defined in terms of financial reporting assertions. A payroll processor's ISAE 3402 report covers controls over the completeness and accuracy of payroll calculations, the authorisation of payroll runs, and the timeliness of payroll data transmitted to the user entity's general ledger. Every control objective ties back to a financial statement assertion.

SOC 2 exists for a different purpose. It reports on a service organisation's controls relevant to the AICPA Trust Services Criteria, which are organised around five categories: security, availability, processing integrity, confidentiality, and privacy. These criteria were designed for evaluating IT service providers, cloud platforms, and data processors. They answer the question "is this service organisation managing its IT environment responsibly?" They don't answer the question "can I rely on this organisation's controls for my financial statement audit?"

The overlap between the two frameworks is partial and asymmetric. Some ISAE 3402 control objectives (logical access, change management, data backup) will also appear in a SOC 2 report under the security and availability criteria. But many ISAE 3402 control objectives (transaction processing accuracy, financial reconciliation controls, authorisation of journal entries) have no SOC 2 equivalent because the Trust Services Criteria don't address financial reporting.

How the control populations map across both frameworks

Security (CC series)

This is the only mandatory category in a SOC 2 report. It covers logical access controls, network security, encryption, incident response, and vulnerability management. These controls have direct parallels in ISAE 3402 reports for IT-dependent services, because logical access and change management controls are relevant to the integrity of financial data processing.

The difference is in how the controls are framed. In the ISAE 3402, the logical access control objective might read: "Access to the application and underlying data is restricted to authorised users, supporting the completeness and accuracy of user entities' financial transactions." In the SOC 2, the same control might appear as: "The entity restricts logical access to information assets using access control mechanisms," with no reference to financial reporting. Same control activity. Different framing. Different audit utility.

Availability (A series)

Covers uptime commitments, disaster recovery, backup, and capacity monitoring. Relevant to ISAE 3402 only when service availability directly affects the user entity's ability to process financial transactions. The availability criterion is optional in SOC 2, so not all reports include it.

Processing integrity (PI series)

This is the Trust Services Criterion closest to ISAE 3402's scope. It covers whether system processing is complete, valid, accurate, and timely. For a service organisation that processes financial transactions, the PI-series controls overlap significantly with the ISAE 3402 control objectives covering transaction processing.

But "closest" is not "equivalent." The PI criterion addresses processing integrity in general terms. A SOC 2 PI control might state that "the system processes transactions in a timely manner." The ISAE 3402 equivalent would specify that "payroll calculations are processed accurately per the user entity's submitted data, and the resulting payroll journal entries are transmitted to the user entity's general ledger within one business day of the payroll run date." The ISAE 3402 version gives the user auditor something to test against. The SOC 2 version is too broad.

Confidentiality and privacy

Confidentiality covers protection of data designated as confidential. Privacy covers personal data handling under applicable privacy regulations. Neither category has a meaningful ISAE 3402 equivalent because neither directly addresses controls over financial reporting. A user auditor relying on a SOC 2's confidentiality or privacy sections for financial statement audit purposes is relying on controls that weren't designed or tested for that purpose.

SOC 2 criterion	ISAE 3402 overlap	Audit utility for financial statements
Security (CC)	Logical access, change management	Partial — supports IT general controls
Availability (A)	Disaster recovery, backup	Limited — only if availability affects transaction processing
Processing integrity (PI)	Transaction processing controls	Closest overlap, but framed in IT terms not financial assertions
Confidentiality (C)	None	Not relevant to financial reporting controls
Privacy (P)	None	Not relevant to financial reporting controls

The decision framework: which report does your file need?

The decision depends on what the service organisation does for your client and what audit evidence you need.

If the service organisation processes financial transactions on behalf of your client (payroll, accounts payable, revenue processing, fund administration), you need an ISAE 3402 report. A SOC 2 report, even one that includes the processing integrity criterion, does not provide control objectives framed in terms of financial reporting assertions. ISA 402 requires you to understand the service organisation's controls relevant to the user entity's financial reporting (ISA 402.9). A SOC 2 doesn't address that.

When the service organisation provides IT infrastructure only (cloud hosting, data centre services, network management) and doesn't process financial transactions, a SOC 2 may be sufficient depending on your risk assessment. You should document why you concluded that a SOC 2 was sufficient and that ISAE 3402-level assurance over financial reporting controls was not required (ISA 402.12).

If the service organisation has both reports, use the ISAE 3402 for financial reporting reliance and the SOC 2 as supplementary evidence for IT general controls if needed. Don't substitute one for the other.

If the service organisation only has a SOC 2 and you need financial reporting control assurance, you have a gap. Document the gap. Consider alternative procedures: direct testing of the controls at the service organisation, substantive audit procedures that reduce reliance on the service organisation's controls, or a request to the service organisation's management for an ISAE 3402 engagement.

Worked example: Bakker Logistics B.V. and CloudSync SaaS

Client scenario: Bakker Logistics B.V. (€42M revenue, transport and logistics) uses CloudSync SaaS for its transport management system (TMS). CloudSync processes approximately €31M of Bakker's revenue transactions annually: customer shipment orders enter CloudSync, CloudSync calculates freight charges based on contract terms, and the calculated revenue is exported nightly to Bakker's SAP general ledger via an automated interface. CloudSync provides a SOC 2 Type 2 report covering security, availability, and processing integrity.

Step 1: Determine what CloudSync does for financial reporting purposes

CloudSync isn't just hosting data. It's calculating revenue. The freight charge calculation that determines €31M of recognised revenue runs inside CloudSync's application logic. This makes CloudSync a service organisation that directly affects Bakker's revenue recognition. ISA 402.9 requires you to understand the nature of the services and their significance to the user entity's financial statements.

Step 2: Evaluate whether the SOC 2 report covers the controls you need

You review the SOC 2 Type 2 report. The processing integrity section includes controls over data input validation, system processing logic, and output completeness. One control states: "The system validates input data for completeness and format before processing." Another states: "Processing is performed accurately per configured rules."

Neither control specifically addresses whether the freight charge calculation logic correctly applies the contractual pricing terms for each customer. That's the financial reporting control you need for revenue accuracy. The SOC 2 tells you the system processes inputs accurately "per configured rules" but doesn't test whether the configured rules match the customer contracts. An ISAE 3402 report would typically include a control objective stating: "Freight charges are calculated in accordance with customer-specific contract terms, and discrepancies between calculated and contracted rates are identified and resolved before revenue is recorded."

Step 3: Design alternative procedures to cover the gap

Because the SOC 2 doesn't cover the revenue calculation controls at a financial-reporting level of specificity, you cannot rely on it for the revenue accuracy assertion. You design alternative procedures. You select a sample of 40 shipment transactions from the year, trace the contracted freight rate for each customer to the rate applied by CloudSync, and verify that the calculated charge matches the contract terms.

The file shows a user auditor who received a SOC 2 report, identified that it didn't cover the financial reporting controls needed, and designed targeted alternative procedures. A reviewer would see the gap analysis, the substantive testing that filled it, and a clear rationale for why the SOC 2 alone was insufficient.

Practical checklist for evaluating SOC 2 vs ISAE 3402 on your file

Before opening any service organisation report, document what the service organisation does for your client and which financial statement assertions are affected. This determines what controls you need evidence for (ISA 402.9).
If the report is a SOC 2, check which Trust Services Criteria are included. Security only? Then the report covers IT access and infrastructure but says nothing about transaction processing. Processing integrity included? Closer, but still framed in IT terms.
Map the SOC 2 control objectives to your audit assertions. For each financial reporting assertion affected by the service organisation, identify whether the SOC 2 includes a control that directly addresses that assertion.
If you conclude that a SOC 2 is insufficient, document the gap and design alternative procedures. Do not note "SOC 2 received" and move on. ISA 402.15 requires sufficient appropriate audit evidence, not just evidence that a report exists.
If the service organisation has both reports, use the ISAE 3402 for financial reporting reliance. File the SOC 2 as supplementary evidence for IT general controls if relevant. Document which report you relied on for which purpose.

Get practical audit insights, weekly.

No exam theory. Just what makes audits run faster.

No spam — we're auditors, not marketers.

Frequently asked questions

Can a SOC 2 report substitute for an ISAE 3402 report for financial statement audit reliance?

No. A SOC 2 report covers controls relevant to the AICPA Trust Services Criteria (security, availability, processing integrity, confidentiality, privacy), not controls relevant to financial reporting. ISAE 3402 specifically addresses controls relevant to user entities' financial statements. Even a SOC 2 that includes the processing integrity criterion frames controls in IT terms rather than financial reporting assertions, creating a gap that ISA 402 does not permit you to overlook.

What is the processing integrity criterion in SOC 2 and how does it relate to ISAE 3402?

Processing integrity (PI series) is the Trust Services Criterion closest to ISAE 3402's scope. It covers whether system processing is complete, valid, accurate, and timely. However, the PI criterion addresses processing integrity in general terms, while ISAE 3402 control objectives address specific financial reporting assertions. A SOC 2 PI control might state that "the system processes transactions accurately per configured rules" but does not test whether the configured rules match contractual terms that drive revenue recognition.

What should a user auditor do if the service organisation only has a SOC 2?

Document the gap between the SOC 2's coverage and the financial reporting controls you need. Then design alternative procedures: direct testing of controls at the service organisation (if the client's contract permits), substantive audit procedures that reduce reliance on the service organisation's controls, or a request to the service organisation's management to commission an ISAE 3402 engagement. A SOC 2 is not a workaround for a missing ISAE 3402.

When is a SOC 2 report sufficient for audit purposes?

When the service organisation provides IT infrastructure only (cloud hosting, data centre services, network management) and does not process financial transactions, a SOC 2 may be sufficient depending on your risk assessment. You must document why you concluded that a SOC 2 was sufficient and that ISAE 3402-level assurance over financial reporting controls was not required (ISA 402.12).