SOC 2 vs DORA: when a SOC 2 satisfies a customer and when it does not
A SOC 2 is not DORA compliance, and DORA is not a certificate you can buy. If you are an ICT provider selling to an EU bank, insurer or payment firm, your customer must meet Regulation (EU) 2022/2554, and most of what it demands reaches you through the contract it signs with you. The SOC 2 is one input the customer may accept under its own ICT third-party policy, not a substitute for the clauses that policy requires. DORA sets no certification scheme, and the only authority-issued attestation it provides for is the one confirming that a threat-led penetration test met the requirements (Article 26(7)).
Article 30 is where the obligations land. For services supporting critical or important functions, the contract must oblige you to accept precise service level targets, test business contingency plans, participate fully in the customer's TLPT, and grant unrestricted access, inspection and audit rights to the customer, its appointed third parties and the competent authority. Article 30(2) adds location of services and data, advance notice of location changes, data return on insolvency or termination, and incident assistance at no extra cost or a cost fixed in advance. Delegated Regulation (EU) 2024/1773 Article 6 lets the customer rely on its own audits, independent audit reports, your internal audit reports and third-party certifications, using more than one where appropriate. Ask each customer which of these it will accept and whether it wants the SOC 2 Type 2 report, not only the Type 1.
A SOC 2 does not cover most of this. It tests the security, availability, processing integrity, confidentiality or privacy controls you chose to include, and it says nothing about your customer's audit rights, exit terms, subcontracting chain or TLPT cooperation. Use of a SOC 2 report is generally restricted, so confirm the customer's NDA terms before sharing it. Plan to answer the contract clauses directly, and treat the SOC 2 as one piece of evidence. DeployOpen prepares control evidence and documentation for these reviews, but it does not issue attestations, and an independent CPA firm performs any SOC 2 examination.
Where a SOC 2 overlaps DORA work and where it does not
A SOC 2 gives a DORA-regulated customer evidence on the security controls a provider runs. It does not supply the contract terms, TLPT participation and authority access that Article 30 requires. The cards mark where the two meet and where a SOC 2 stops.
Access, change and operations
Common criteria CC6 to CC9 cover logical and physical access, system operations, change management and risk mitigation. A Type 2 report can give an opinion on whether these controls operated over a period, which is the evidence a DORA-regulated customer can test against its own ICT controls. Ask for the sampling period, the exception list and the systems in scope, because a report covers only what its system description includes.
Overlap checked through CIS mapping
The CIS Controls Navigator for v8.1 lists mappings to both SOC 2 and DORA, so it is the supplied starting point for matching safeguards to each framework. Use it to pull the safeguards both reference, then test the provider's report against them. ENISA states that its own mapping is not a measure of equivalence and does not assess whether a standard fully covers the regulation's requirements, so the same caution applies to any crosswalk.
Vendor risk and assurance mix
The risk mitigation criteria in CC9 cover how the provider manages risk, including risk from its own suppliers. DORA asks more of the customer: its ICT third-party policy must specify the assurance used on each provider. Delegated Regulation (EU) 2024/1773 Article 6 lists the entity's own audits, independent audit reports, internal audit reports and certifications, using more than one where appropriate. A SOC 2 is one input to that policy, not the whole of it.
Points of focus are optional
The Trust Services Criteria treat points of focus as characteristics that help design and evaluate controls. They are not separate requirements, and not every point of focus has to be addressed. A clean SOC 2 therefore does not prove that every point of focus was covered. Ask the auditor which points of focus the provider addressed and whether any were excluded, then compare the answer with the controls your policy asks for.
Contract terms and exit
Article 30(2) requires the contract to state where services are provided and data is processed, with advance notice of location changes. It also covers data protection, data return on insolvency or termination, and incident assistance at no additional cost or at a cost set in advance. The Trust Services Criteria do not address these terms. Your legal team must write them into the agreement, because a SOC 2 cannot stand in for them.
TLPT and competent authority access
For services supporting critical or important functions, Article 30(3) requires the provider to participate fully in the customer's threat-led penetration test. It also requires unrestricted access, inspection and audit rights for the customer, its appointed third parties and the competent authority. A SOC 2 says nothing about TLPT participation or regulator access. Plan TLPT scope and access rights in the contract, since DORA's only authority-issued attestation covers whether a TLPT met its requirements.
Where independent audit reports fit in the customer's ICT third-party policy
A SOC 2 report is not a DORA compliance document that you hand over once. It is one input your financial customer may choose to use when it evaluates you. Under Delegated Regulation (EU) 2024/1773 Article 6, the customer's ICT third-party policy must specify the assurance it relies on for each provider. The listed options are the entity's own audits, independent audit reports, the provider's internal audit reports and appropriate third-party certifications, and the entity may combine more than one where that is appropriate. A SOC 2 would normally sit in the independent audit report category, but the decision to accept it, how much weight it carries and whether it needs supplementing belong to the customer, not to you.
Two distribution rules shape how that input moves. Use of a SOC 2 report is generally restricted, so it is usually shared only with parties the report names as intended users, which typically means existing customers and their auditors. A SOC 3 report is a general use report that can be freely distributed, but it covers the same categories in less detail and gives a financial entity's supervisory file less to test. Confirm with your CPA firm which intended users your SOC 2 names, and expect a customer to ask for the full report under confidentiality terms rather than a SOC 3 when it needs to show a competent authority how it assessed you.
Ask each financial customer, early and in writing, which assurance it accepts for your services: its own audit, your SOC 2 Type 2, your internal audit reports, or a certification. Ask whether it expects more than one, which report period it wants covered, and whether it needs the report scoped to the services it buys. Then check that your SOC 2 system description and selected criteria match those services and the locations where data is processed, because a report that omits the relevant service will not satisfy the policy. Where the answer is that the customer will run its own audit, agree the audit rights and access terms in the contract now, since Article 30(3) gives the customer and the competent authority unrestricted access, inspection and audit rights for services supporting critical or important functions.
Who assesses each and what it produces
This table compares who does the assessment, what document or decision comes out of it, the period it covers and how often it is refreshed for a SOC 2 and for DORA. Read it to see why a SOC 2 can support a bank's third-party file without satisfying DORA's own supervision and testing duties.
| Dimension | SOC 2 (AICPA attestation) | DORA (EU supervision) |
|---|---|---|
| Who performs the work | A CPA firm acting as service auditor under AT-C section 205, using written representations from management | National competent authorities supervise compliance using the powers in Article 50; the ESAs oversee designated critical providers |
| What is issued | A Type 1 or Type 2 report with the auditor's opinion, not a certificate | No DORA certificate or certification scheme exists; the only authority-issued attestation is the Article 26(7) confirmation that a threat-led penetration test met requirements |
| Scope of the opinion | Management's system description and the controls against chosen Trust Services Criteria | Obligations set in law and in the contracts financial entities sign under Article 30, covering ICT risk, incidents, testing and third-party risk |
| Period covered | Type 1: suitability of control design as of a date. Type 2: operating effectiveness over a period | Compliance is continuous; there is no equivalent period opinion, so evidence must be kept current for each supervisory request |
| Who can use the output | Use of a SOC 2 report is generally restricted to specified parties; a SOC 3 is for general use | The financial entity must document its own assessment of each provider and may request information and audit access under the contract |
| Update cadence | Set by the engagement; Type 2 reports are normally issued on a recurring audit cycle agreed with the auditor | Set by the financial entity's contract and supervisory requests; confirm reporting and audit frequency in each Article 30 contract |
| What to confirm with your customer | Which TSC categories and subservice organizations are in scope and whether the report period matches the customer's review window | Which provider functions support critical or important functions, and whether the customer expects TLPT participation and unrestricted audit rights |
What to pursue first by provider situation
A SOC 2 report is useful evidence for an EU bank, insurer or payment firm, but it is one form of assurance that the customer's ICT third-party policy may accept, not a substitute for the contract terms DORA requires. Start by mapping the report to the customer's requests rather than sending it unprompted.
- Check the report type and period: Confirm whether you hold a Type 1 or Type 2 report, the trust services categories in scope and the period covered. Type 1 shows design as of a date; Type 2 adds operating effectiveness over a period.
- Check distribution rights: Use of a SOC 2 report is generally restricted. Offer a SOC 3 report for general distribution and share the full SOC 2 under the customer's non-disclosure terms.
- Gap-test against Article 30: Compare the report with the contract clauses for audit and inspection rights, participation in threat-led penetration testing, business continuity testing, data location and incident assistance. Most of these are not covered by an attestation.
- Prepare the bridge document: Provide a short note that states which controls the report covers and which DORA-specific obligations are handled by contract, testing or other evidence.
Confirm with the customer's compliance team which assurance types its policy accepts under Delegated Regulation (EU) 2024/1773.
A provider without a SOC 2 cycle should first establish the control baseline a bank or insurer will test, because the customer's policy may require one or more forms of assurance. Deciding whether a SOC 2 is the right report depends on what your customers ask for and which other assurance you already have, so confirm those requests before committing to a scope.
- Collect the customer's requirements: Ask each financial customer which assurance it accepts, whether it requires a SOC 2 specifically and what scope it expects, in writing.
- Choose trust services criteria deliberately: Security covers the common criteria CC1 to CC9 in every SOC 2. Add availability, processing integrity, confidentiality or privacy only where the service and the customer need them.
- Document the system description early: The description of the system is evaluated against the AICPA's 2018 description criteria, so start that document before the examination window opens.
- Ask for a quote from the auditor: A CPA firm will scope the examination from the agreed criteria and system boundary. Ask for the fee basis, the fieldwork schedule and what the firm will need from you.
- Plan for testing outside the report: Schedule the penetration testing and resilience exercises the contract may require, since a SOC 2 does not supply them.
Confirm with your auditor and customers which report type and period will be accepted before fieldwork begins.
When a service supports a critical or important function, Article 30(3) requires the provider to accept precise service level targets, implement and test business contingency plans, participate fully in the customer's TLPT, and grant unrestricted access, inspection and audit rights to the customer, appointed third parties and the competent authority. These obligations are contractual and operational, so a report cannot discharge them alone.
- Accept precise service levels: Agree targets the customer can measure, and report against them with evidence the customer can verify.
- Test contingency plans: Run and document business continuity tests that the customer can review, with dated results.
- Prepare for TLPT participation: Define the roles, access and data handling for a threat-led penetration test before a customer requests one, so participation is not negotiated under time pressure.
- Agree audit and access terms: Confirm how unrestricted access and inspection will work for the customer, its appointed third parties and the competent authority, including the confidentiality terms for each.
- Consider the highest quality standards: Under Article 28(5), the customer must consider the most up-to-date and highest quality standards for these functions, so document which standards you follow and why.
Confirm with the customer whether its own assessment classifies the service as supporting a critical or important function, since that classification drives these terms.
The ESAs' first list of designated critical ICT third-party providers, dated 18 November 2025, names 19 providers, which the ESAs describe as offering services from core infrastructure to business and data services. For a designated provider, oversight is direct, run by the ESAs as Lead Overseers under Articles 31 to 44, rather than only through the contracts its financial customers sign. A provider that is not on the list can still ask whether its services are likely to be considered in future designations.
- Check the list yourself: Review the 18 November 2025 list and compare your service descriptions with the categories the ESAs use. Do not assume your status from your size or sector alone.
- Prepare for direct oversight: If designated, expect requests from the Lead Overseer for information and examination in addition to customer audits. Assign a named owner for regulator interaction.
- Map your dependencies: Document which customers, sub-processors and locations depend on the service, since oversight will examine concentration and substitutability.
- Track the review: The Commission must report on the designation criteria by 17 January 2028 under Article 58(1), so monitor for changes in the criteria.
- Keep the SOC 2 in its place: A SOC 2 may still help with customer reviews, but it does not replace the direct oversight regime.
Confirm your current status with your competent authority and the ESAs' published materials, rather than relying on this summary.
Doing a SOC 2 and DORA contract readiness in order
This sequence turns a DORA contract request into a scoped SOC 2 plan, so the report you hand over answers the questions the customer's Article 30 terms actually ask.
Map the customer contract clauses
Start by listing every clause your financial customer has put in the contract or addendum, sorted against the Article 30 terms: service levels, business contingency testing, TLPT participation, unrestricted access and audit rights, service locations, data return on insolvency or termination, and incident assistance at no additional cost or a cost set in advance. Assign each clause an owner on your side, usually legal, the service owner and security. The output is a clause register that marks each term as one a SOC 2 could evidence, one it could only partly evidence, or one it cannot evidence at all. Confirm the register with the customer's contracting team before anyone writes control text.
Confirm the assurance the customer accepts
Ask the customer's ICT third-party risk team which forms of assurance their policy accepts for your service. Delegated Regulation (EU) 2024/1773 expects the policy to name the assurance used, such as the entity's own audits, independent audit reports, the provider's internal audit reports or third-party certifications, and to use more than one where appropriate. Record the answer in writing, including whether a SOC 2 Type 2 report is acceptable as the independent report and whether the customer needs its own audit rights in addition. The output is a written statement of accepted assurance that you can reference in scoping.
Scope the SOC 2 system and categories
Define the system boundary for the SOC 2 around the services the customer buys, including the infrastructure, people, data flows and subservice organizations that support them. Security is covered by the common criteria in every SOC 2, so decide whether availability, processing integrity, confidentiality or privacy are added, based on what the contract promises. Confirm this scope with each customer separately, because a shared platform may serve several financial entities with different clauses. The output is a written scope statement for each customer or customer group, approved by the engagement sponsor and the auditor before fieldwork.
Prepare the system description under DC 200
Management writes the system description and evaluates it against the AICPA's 2018 description criteria (DC 200), using the revised implementation guidance issued in 2022. The description should cover the services, components, processes and the controls that support the customer's contract scope, and state where data is processed when that matters to the customer. Management also prepares the written representations the auditor requires under AT-C section 205. The output is a draft description and representation set reviewed by legal and the auditor, with gaps in the description flagged rather than hidden.
Close gaps the SOC 2 does not cover
Compare the clause register against the controls the SOC 2 will test. A SOC 2 can show that controls operated, but it does not by itself deliver precise service level targets, a tested business contingency plan, unrestricted audit access for the competent authority, or a commitment to assist with incidents at a set cost. Write a remediation plan for each uncovered term, with an owner, a decision on whether the term is met by contract language, a separate operating procedure or a new control, and a check that the change exists. The output is a gap list signed off by the customer's contract owner, so both sides know which terms the report will not answer.
Reuse shared evidence across assessments
Where the same controls serve several customers or other frameworks, map each control once and reuse its evidence across assessments, so the team does not collect duplicate artifacts for each request. Keep evidence tied to the in-scope system and period, and record which customer scope each item supports. Reuse does not replace confirmation: a control that serves one customer's scope may not match another's, so check each scope before you reuse evidence. The output is an evidence index linking each control to its artifacts and the customer scopes they support.
Plan TLPT participation with the customer
For services that support critical or important functions, the contract may require full participation in the customer's threat-led penetration test. Agree with the customer, in writing, the test scope, the rules of engagement, who from your side takes part, how systems and data are protected during testing, and how findings are handled. Confirm with the customer whether any attestation of the test is expected, since the only authority-issued attestation DORA provides for relates to whether a threat-led test met its requirements under Article 26(7). The output is an agreed participation plan that sits outside the SOC 2, with named contacts and a confirmed process for sharing results.
Confirm scope with each customer
Before the audit starts, send each customer a short written confirmation of the scope, the accepted assurance, the gap list and the TLPT plan, and ask for their agreement. Repeat this check whenever the service, subservice providers, data locations or contract terms change, because the report only covers the scope it was given. Restrict distribution of the SOC 2 report to parties allowed to receive it, since use of a SOC 2 report is generally restricted. The output is a signed scope record for each customer and a distribution log for the final report.
Questions providers ask about SOC 2 and DORA
Does a SOC 2 report make a provider DORA compliant?
No. DORA sets no certification scheme, so no SOC 2 report, certificate or badge makes a provider DORA compliant. Competent authorities supervise compliance using the powers in Article 50, and the only authority-issued attestation the Regulation provides for confirms that a threat-led penetration test met the requirements (Article 26(7)). A SOC 2 is one form of assurance a financial customer may accept under its ICT third-party policy. Delegated Regulation (EU) 2024/1773 Article 6 requires that policy to name the assurance used on each provider, and it may combine several sources. A SOC 2 does not replace the contract terms, audit rights and TLPT participation that the customer must put in place with you.
What does a DORA-ready contract package require from a provider?
For services supporting critical or important functions, Article 30(3) asks providers to accept precise service level targets, implement and test business contingency plans, participate fully in the customer's threat-led penetration test, and grant unrestricted access, inspection and audit rights to the customer, its appointed third parties and the competent authority. Article 30(2) adds the location of services and data with advance notice of changes, data protection and data return on insolvency or termination, and incident assistance at no additional cost or at a cost set in advance. Article 28(5) requires providers to meet appropriate information security standards. The effort comes from mapping each clause to an existing control, evidence source and owner, then closing gaps in contingency testing and access procedures. Confirm the full clause list with the customer's legal and risk teams.
Can our team prepare the DORA contract and evidence work internally?
Often yes for the mapping work, if your staff understand both your controls and the regulation. An internal team can inventory the Article 30 clauses, map each one to an existing control and evidence source, and list the gaps. Work that often needs outside help includes independent testing of contingency plans, evidence packs an customer's assessors will accept, and preparation for threat-led penetration test participation. Check whether your team has capacity during customer audit cycles, because each financial customer may send its own questionnaire and audit request. The right split depends on your team's skills, time and the number of customer clause sets you must answer.
How long do a SOC 2 and contract alignment take?
The supplied sources do not give a duration for either task, so confirm timing with your CPA and with each financial customer rather than planning from a generic figure. Timing depends first on the report type. A Type 1 report covers the system description and the suitability of control design as of a date. A Type 2 report adds an opinion on operating effectiveness over a period, so the controls must operate throughout that period before the auditor can test them. Contract alignment depends on how many customers send their own clause sets and whether each set needs individual negotiation. Ask your CPA for the observation window and your customers for their review calendars, then build a written timeline from those dates.
Can we share our SOC 2 report with financial customers?
Usually only under restriction. Use of a SOC 2 report is generally restricted, while a SOC 3 report is a general use report that can be freely distributed. For DORA customers, a SOC 2 is typically one input their policy may accept, so check the restricted use language in the report and the distribution terms your auditor sets before you send it to a bank, insurer or payment firm. A SOC 3 covers the same categories in less detail, so it may answer a public trust question but rarely satisfies a third-party risk team on its own. Agree in writing with each customer what they may receive and how they will handle it. Confirm the specific terms with your CPA.
What drives the cost of SOC 2 and DORA readiness, and what should a quote include?
No fee figure is supplied for either route, so a quote is the only reliable source. The main cost components are the CPA's examination fee for the SOC 2, internal staff time for controls and evidence, legal review of customer clause sets, and any remediation or testing the gaps require. Costs rise with the number of trust services categories in scope beyond security, the number of systems and locations, the number of customers with individual contract terms, and a Type 2 observation period. Recurring costs include each periodic examination and the updates that new customer requests trigger. A quote should list the written scope, deliverables, the clauses and controls covered, assumptions, who performs each task, and which items are one-time and which recur.
Does a provider need DeployOpen to prepare DORA evidence?
No. A provider can prepare its systems, controls and evidence with its own staff, its CPA and its legal advisers. DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside a client's own infrastructure, runs security testing, and prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications, because independent auditors and certification bodies perform that work. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope. Outside help makes most sense when you need extra capacity for evidence preparation or for security testing your customers will ask about.
What a SOC 2 leaves open for DORA
A SOC 2 report can support a financial customer's assurance file, but it does not give that customer most of the contract and access terms Article 30 of DORA requires. Treat the report as one input to the ICT third-party risk policy, and check each gap below against your contracts before a bank, insurer or payment firm relies on it. A SOC 2 does not show participation in the customer's threat-led penetration testing (TLPT), because the report tests your controls, not your willingness to take part in the customer's TLPT exercise. Confirm that your agreements oblige you to participate fully, as Article 30(3) requires for services supporting critical or important functions.
The report also leaves open the contract clauses and rights a customer's supervisor expects. A SOC 2 says nothing about the location where services are provided and data processed, or about advance notice of location changes under Article 30(2). It does not guarantee data return on insolvency or termination, or set incident assistance at no additional cost or at a cost fixed in advance. Nor does it grant the customer, its appointed third parties or the competent authority unrestricted access, inspection and audit rights. Ask legal counsel to map each Article 30 obligation to a clause in the master agreement, and do not assume the report's restricted-use terms cover any of them. Also check the distribution terms: a SOC 2 is generally restricted, so a customer may need a SOC 3 for general distribution.
Finally, a SOC 2 carries no designation status. The ESAs' list of critical ICT third-party providers, dated 18 November 2025, names 19 providers, and a designation brings direct oversight by the ESAs. Your SOC 2 neither shows nor changes whether you are designated, so confirm your status against that list and plan for it. The Commission must review DORA and report by 17 January 2028, including the criteria for designating critical providers, so the rules may shift. Separately, the AICPA proposed revisions to its baseline attestation standards in February 2026, which would apply to engagements beginning on or after 15 June 2029 if adopted. Ask your CPA firm how those changes would affect your next report and build the contract review into each renewal cycle.
How DeployOpen prepares DORA and SOC 2 readiness
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For SOC 2 vs DORA, we prepare the systems, controls and evidence a financial customer may ask a provider for, while the independent auditor issues any report and the financial entity keeps its own supervisory duties.
How we scope
- Written scope agreed before work starts, listing the systems, services and financial customers in question
- Mapping of the Article 30 contract clauses to the controls and evidence each one requires
- Agreement on which assurance the customer accepts, such as a SOC 2 report, and which gaps remain for its ICT third-party policy
How we build
- Implementation and hardening of self-hosted platforms in the client's cloud accounts, data centers or air-gapped networks
- Documented controls for incident assistance, business contingency testing and data return on termination
- Security testing of applications, APIs and infrastructure, including support for participation in threat-led penetration testing
How we hand over
- Documentation of system descriptions, control design and operating procedures in a form an independent auditor can examine
- Evidence packs organized by the criteria or contract clauses agreed in the scope document
- Handover sessions so the client's own staff can run, monitor and update the controls after delivery
How we support
- Ongoing support, upgrades and continuous testing available as a retainer after handover
- Confirmation with the client's auditor and legal team of which evidence and wording they need before fieldwork
- Quotes built from the written scope, with the client asked to confirm assumptions about its environment and customers
Sources and further reading
- Regulation (EU) 2022/2554 (DORA), Article 2, EUR-Lex ↗
- Regulation (EU) 2022/2554 (DORA), Articles 28 to 30, EUR-Lex ↗
- Commission Delegated Regulation (EU) 2024/1773, EUR-Lex ↗
- AICPA SOC 2: SOC for Service Organizations, Trust Services Criteria ↗
- AICPA 2017 Trust Services Criteria (revised points of focus, 2022) ↗
- List of designated critical ICT third-party service providers (18 November 2025), ESAs ↗
