Is SOC 2 accepted under DORA and NIS2 for EU customers

Is SOC 2 accepted by European customers under DORA and NIS2?

A bank, insurer or essential entity that asks for a SOC 2 report is usually trying to answer one question: does this provider's security evidence meet our own policy? DORA and NIS2 do not name SOC 2 as a required certificate, and the customer decides whether a SOC 2 report satisfies its own third-party risk policy. The answer is not the same for every buyer. It depends on the customer's entity type, the services it buys from you, and whether those services support critical or important functions. Under DORA, Delegated Regulation (EU) 2024/1773 Article 6 requires a financial entity's policy to name the assurance it uses on a provider, such as its own audits, independent audit reports or appropriate third-party certifications, and it may combine several. A SOC 2 report can be one input to that assessment, but it is the customer's call.

Divide the work clearly. Your organization owns its controls, its contracts and the commitments it makes to customers, including audit rights, incident notification and exit terms. An implementation partner such as DeployOpen can prepare the systems, configuration and evidence that those controls rely on, and the customer's assessors can test them. Only an independent CPA firm issues a SOC 2 report, and only an accredited certification body issues an ISO/IEC 27001 certificate. Before you commit to a SOC 2 timeline in a bid, ask the customer in writing which assurance it will accept, whether it requires ISO 27001 or the German C5 attestation, and which audit rights a report will not replace. A useful first step is to read the AICPA 2017 Trust Services Criteria alongside the customer's contract schedule to see where the report scope stops.

Which DORA and NIS2 duties reach your SOC 2 scope

European customers rarely ask for SOC 2 because a regulation names it. They ask because their own supervised obligations push requirements down to suppliers through policy and contract. The cards below show which duty applies to which entity type, and why the customer, not the provider, decides how far a SOC 2 scope has to reach.

DORA third-party assurance policy

Under Delegated Regulation (EU) 2024/1773, Article 6, a financial entity's policy must say which assurance it relies on for each ICT provider. The list includes the entity's own audits, independent audit reports, the provider's internal audit reports and appropriate third-party certifications, often in combination. A SOC 2 report is one possible input. Ask your customer which assurance types their policy accepts for your service, and whether a single report is enough for their risk tier.

Appropriate standards before contracting

DORA Article 28(5) allows a financial entity to contract only with providers that comply with appropriate information security standards. For critical or important functions, the entity must also consider the most up-to-date and highest quality standards. Applies to banks, payment institutions and other DORA financial entities. Expect questions on which standards you meet and why, so map your SOC 2 criteria to the customer's risk assessment rather than presenting the report alone.

Enhanced terms for critical functions

Article 30(3) of DORA applies when a provider supports a critical or important function. The provider must accept precise service level targets, implement and test business contingency plans, take part fully in the customer's threat-led penetration testing, and grant unrestricted access, inspection and audit rights to the customer, its appointed third parties and the competent authority. A SOC 2 report does not replace these rights. Confirm in the contract which of these clauses your organization must sign before the audit scope is discussed.

NIS2 supplier security through contracts

Article 21(2)(d) of NIS2 requires essential and important entities to address security in their relationships with direct suppliers and service providers. Your provider may be outside NIS2 scope, yet your customer still has to deal with you in its risk management. Expect the requirement to arrive as a security questionnaire, a contract addendum or a request for evidence. Clarify early which of these your customer will accept as proof, since NIS2 itself does not name a report type.

Digital provider contract content

Implementing Regulation (EU) 2024/2690, Annex point 5.1.4, sets out what supplier contracts for digital infrastructure and digital provider entities should cover where appropriate. The list includes cybersecurity requirements, staff training, background checks, incident notification without undue delay, audit rights or audit reports, vulnerability handling, subcontracting and exit obligations. Use it as a checklist when a customer sends its contract template, and note which items your SOC 2 report can evidence and which need separate contract language.

Where a SOC 2 report stops and audit rights begin

A SOC 2 report does not replace the audit rights a financial customer must hold over a critical or important service. Under DORA Article 30(3), a provider supporting such a function must grant the customer, its appointed third parties and the competent authority unrestricted access, inspection and audit rights. GDPR Article 28(3)(h) separately requires the processor to provide information and allow audits, including inspections. A SOC 2 gives the customer an independent opinion on controls, but it is a report on a period, prepared for a defined set of users. It cannot give a regulator or an auditor of the customer the ability to walk into systems, test samples or ask new questions. Treat the report as the baseline evidence and the contract as the place where the broader access is granted.

The contract therefore has to say what the report covers and what sits outside it. Check whether the report's system description includes the services the customer actually buys, the subservice organizations used and the dates of the examination period. Then write the access rights in the agreement: who may audit, how much notice applies, whether on-site inspection is permitted, how the provider supports the customer's threat-led penetration testing, and how cooperation with the competent authority works. Confirm these terms with your own counsel and the customer's procurement team, since the exact wording depends on the customer's regulator and the service in question.

Report access is a separate question from audit rights. A SOC 2 report is generally restricted use, so the customer can read it only if the provider's NDA and the report's intended users allow it. Ask the provider early whether its NDA permits sharing the report with the customer's internal risk functions, auditors and regulators, and whether the customer's own regulator can receive a copy. A report that cannot leave the customer's legal team may not satisfy a due diligence file. Where access terms are unclear, agree them in writing before the report is requested, not after a regulator asks for it.

SOC 2, ISO 27001 or C5: which assurance a European buyer accepts

This table compares three assurance options a European buyer may ask for, showing what each attests, who issues it and when it tends to fit. Read it as a starting point: the buyer's own regulator and contract decide which report is acceptable, so confirm that policy before choosing.

Option	What it attests	Who issues it	When it fits a European buyer
SOC 2 Type 2	Management's description of a service system and the operating effectiveness of controls against the Trust Services Criteria over a period	An independent CPA firm, under the AICPA attestation framework	Fits US-origin SaaS vendors and buyers who accept a North American trust services report; confirm whether the buyer's policy names it
ISO/IEC 27001:2022 certification	Conformity of an information security management system with the standard, checked at a point in time and through surveillance	An accredited or unaccredited certification body; ISO does not certify organizations	Often preferred by European buyers and regulators; the certificate can be checked in IAF CertSearch, and the buyer should confirm the body's accreditation
C5 (BSI Cloud Computing Compliance Criteria Catalogue)	Cloud security controls defined by Germany's Federal Office for Information Security (BSI)	An auditor recognized for C5 attestations, reporting to the cloud provider's customers	Relevant mainly for German public sector and cloud buyers; cloud providers such as Microsoft publish combined C5, SOC 2 and STAR reports, so check which one the buyer's regulator expects

Your team, your partner and the independent auditor

Your organization owns the controls. The controls have to operate in your business, be approved by your leadership and be performed by your staff, and no outside party can take that responsibility over. Your team also decides which assurance you offer, what each customer contract says about it and whether a given report or certificate is enough for a particular buyer. Under DORA, a financial entity customer must document how it relies on a provider's assurance, so your contract and due diligence answers will be read closely. Expect your team to keep these responsibilities:

Controls and policies: approving the information security policy, access rules and change process, and running them every day.
Scope decisions: choosing which systems, services and trust service categories the report covers, and which services sit with subservice organizations.
Customer contracts: agreeing audit rights, incident notification timing, subcontracting terms and exit obligations with each customer.
Evidence ownership: making sure access reviews, tickets and logs exist and are retained in the form the auditor will test.
Customer acceptance: deciding what a European customer's risk and procurement teams should receive, and answering their follow-up questions.

Check whether your own staff can run each control after the partner and auditor have left, because a control that depends on an outside person will not produce evidence for the next period.

How to prepare the package a European customer asks for

This sequence turns a European customer's questionnaire into one agreed package of evidence, report scope, NDA terms and contract addenda, so the customer's assessment rests on what your organization can actually show. Each step ends with a document or check that the next step depends on.

Confirm the customer's entity type and required terms
Start by asking the customer which regime applies to it: whether it is a financial entity under DORA, an essential or important entity under NIS2, a controller or processor under GDPR, or several at once. The answer decides which provisions its contract must carry and which evidence its third-party risk policy will accept. Ask for the clauses it requires in writing, including audit rights, incident notification timing, service level targets, subcontracting conditions and exit terms. The output is a short requirements note, signed off by the customer's contact, that lists the regimes and the contract terms in play. If the customer cannot say which regime applies, treat that as an open item for its legal or third-party risk team, not something to guess at.
Map each request to a control in your scope
Take the customer's questionnaire and every regulatory request and tag each one to a control in your SOC 2 or ISO 27001 scope, or record it as outside scope. Examples include access reviews, incident response, business continuity testing, vulnerability handling, subcontractor management and data deletion. Name the control owner and the evidence item that backs each answer. Mark any request with no control behind it as a gap, because that gap must be closed or disclosed before the package goes out. The output is a request-to-control map that a second person in your organization has reviewed for accuracy.
Decide which report or certificate to share
Decide which assurance artifacts answer which requests. A SOC 2 report, an ISO/IEC 27001 certificate, a penetration test summary and your own internal audit results each cover different ground, and Delegated Regulation (EU) 2024/1773 expects a provider's policy to name the assurance used and to combine more than one where appropriate. Check the report's period, the scope and system description, and any exceptions, then state which categories and subservice organizations it covers. Confirm with the customer whether it accepts a SOC 2 report in place of an ISO certificate or wants both. The output is a written decision record listing each artifact, the requests it answers and the requests it does not.
Agree the NDA and distribution terms
Before sending any report, agree a non-disclosure agreement that matches how the report may be used. A SOC 2 report is generally restricted to specified parties, so confirm that the customer, and any regulator or appointed third party it names, falls within those parties. Clarify whether the customer may share the report with its own auditors or supervisors, and under what conditions. If the customer only needs a general summary, check whether a SOC 3 report or a published statement fits its need, since those are distributed more freely. The output is a signed NDA and a short record of who may receive each document.
Prepare a bridge letter or current report summary
If the most recent report period ends well before the customer's review date, or if the audit period has moved on since the report was issued, prepare a bridge letter from management covering the gap, and check that the report and the bridge letter together leave no uncovered period. Confirm with your CPA firm what it will sign and what it will not. Where there are exceptions in the report, prepare a short written explanation of each, the remediation and its status. The output is a dated bridge letter or summary, reviewed by your auditor's stated position and approved by the accountable executive.
Prepare the contract addenda for audit, incident and exit
Draft the contract addenda the customer's regime requires, tailored to what you can deliver. These typically cover audit and inspection rights for the customer and its appointed third parties, incident notification within the agreed time, service level targets, business continuity testing, subcontracting notice, data return and deletion at exit, and, for personal data, the processor terms set out in GDPR Article 28. Confirm with legal counsel what your organization can accept and where your own audit reports are the natural substitute for on-site audits. The output is a draft addendum marked up against the customer's requirements and a list of the points still under negotiation.
Assemble and version the shared package
Bring the request-to-control map, the decision record, the NDA, the report or certificate, any bridge letter, exception explanations and the contract addendum into one package. Give it a version number and date, and include a cover note stating what the package covers, what it does not and who to contact for follow-up questions. Keep an internal copy with the same version so that later questions can be answered from the same record. The output is a versioned package sent to the customer's named contact, with a log of what was sent and when.
Track follow-up questions and keep the record current
Expect the customer to ask about scope, exceptions, subservice organizations and any control it reads differently from the report. Route each question to the control owner, answer it in writing, and add the answer to the request-to-control map so the next reviewer sees the same position. When the report period changes, when a control changes or when an incident affects the service, update the package and notify the customer under the terms agreed in the addendum. The output is a maintained question log and an updated package that is never allowed to drift from the evidence behind it.

Why the policy's assurance mix matters under DORA

Under DORA, a financial entity's ICT third-party risk policy must name the assurance it uses on each provider. The Delegated Regulation (EU) 2024/1773 lists the options: the entity's own audits, independent audit reports, the provider's internal audit reports and appropriate third-party certifications, and it expects more than one to be used where appropriate. In practice, a SOC 2 report is rarely the only document a bank or insurer relies on. It usually sits beside the customer's own assessment of your controls, a penetration test or resilience test result, your answers to its due diligence questionnaire and the contract itself. Your report is one input to that file, and the customer decides how much weight it carries.

That is why a provider should ask early which assurance mix the customer's policy names for providers of its kind. The answer shapes the deliverable. If the policy relies on independent reports for a service that supports a critical or important function, a SOC 2 Type 2 report covering an operating period will usually be asked for, because a Type 1 report only describes control design as of a date. If the customer's policy names your report as one input among several, a Type 1 report with a committed Type 2 date may be discussed. Ask the customer's third-party risk team which report types, periods and bridge letters they accept, and get the answer in writing before you commit to a timeline.

Confirm three things with the customer before the contract is drafted: which assurance sources their policy names, whether they accept a SOC 2 report in place of their own audit or only alongside it, and what they expect to see for the services in scope. Note that the customer, not the provider, decides whether the mix is sufficient. An independent auditor issues the SOC 2 report, and only the customer can determine how it fits its policy. Keep a short record of these answers so that the report, the contract clauses and the customer's file all describe the same services and the same period.

What delays European security reviews and how to avoid it

European security reviews rarely fail on the SOC 2 report itself. They stall when the report does not cover what the customer buys, when its type or period does not match the customer's policy, or when the paperwork around it is missing. Each card below names one stall point, the fix, and who owns that fix.

Scope leaves out the hosted service

The customer buys a hosted service, but the examination covers only the corporate environment or a narrower product. Reviewers then ask whether the production system that processes their data is in the system description at all. Check the system description against the actual service boundary, including support tooling, APIs and any hosted components. The organization owns the boundary decision; the auditor confirms it is described accurately.

Type 1 offered where Type 2 is expected

A Type 1 report describes control design as of one date and does not test operation over time. Many European customers' policies expect evidence of operation across a period, so a Type 1 alone often triggers a follow-up request. Confirm the customer's required report type and period before committing to a date. The organization sets the observation timeline, and the auditor decides what the report can state.

Exceptions nobody has explained

A report with exceptions invites questions, and an unexplained exception invites escalation. Reviewers want to know what failed, over what population, how it was corrected and whether the same failure can recur. Prepare a short written response for each exception before sharing the report. The organization writes the remediation account; the auditor's report stands as issued.

No contract clauses for audit and exit

A SOC 2 report does not replace the audit rights, incident notification, subcontracting terms or exit provisions that a financial entity or essential entity must secure through contract. Without them, the report becomes the only assurance, and the customer's supervisor may question that. Draft these clauses with counsel before the review starts. The organization owns the contract terms; legal counsel drafts them.

Cloud subservice report missing or outdated

Most hosted services rely on a cloud provider whose SOC report is carved out of the examination. If that provider's report is missing, expired or does not cover the regions and services in use, the customer cannot close the gap in the chain. Collect the current subservice reports, map them to the services used, and note any complementary controls the customer must maintain. The organization maintains the register; the auditor tests the carve-out treatment.

No plan for sharing under NDA

Reviewers often need the full report, not a summary, and sharing it usually requires an NDA and a defined distribution path. Teams that have no process end up delaying the review while legal drafts terms under pressure. Agree on the NDA template, the named recipients and the copy that goes to each European reviewer in advance. The organization runs the process; the auditor's restrictions on use of a SOC 2 report still apply.

Questions European buyers ask about SOC 2

Do DORA or NIS2 name SOC 2 as an accepted report?

No, neither regulation names SOC 2. DORA and NIS2 set outcomes and leave providers and customers to weigh the assurance that supports them. DORA's delegated rules list the kinds of assurance a financial entity may use on a provider, including the entity's own audits, independent audit reports and appropriate third-party certifications, and they allow more than one. A SOC 2 report is an independent audit report that can fit that list, but whether a given customer accepts it is decided by the customer's policy and its risk assessment. Ask the customer which assurance its third-party policy names, and whether it accepts a SOC 2 Type 2 report, a bridge letter or a certification in its place.

Is a SOC 2 Type 1 report enough for an EU customer?

It depends on the customer's policy and on the service being bought. A Type 1 report describes the system and whether controls were suitably designed as of one date, but it does not test whether they worked over a period. Customers supporting critical or important functions usually ask for evidence of operating effectiveness, which points toward a Type 2 report. Confirm in writing which report type, observation period and report age the customer requires, and whether it accepts a Type 1 report as a bridge while a Type 2 observation period runs.

What must a provider do to support customer audits?

Under DORA, contracts for services supporting critical or important functions must grant the customer, its appointed third parties and the competent authority unrestricted access, inspection and audit rights. NIS2 pushes similar expectations through supplier contracts, including audit rights or audit reports. In practice, the provider should be ready to answer a written questionnaire, provide its SOC 2 report and bridge letter, allow inspections of relevant sites or systems where the contract requires it, and take part in the customer's threat-led penetration testing where the contract says so. A report does not replace these rights, so check each clause with counsel.

Is ISO 27001 required for European customers?

No regulation requires ISO/IEC 27001 by name. DORA's rules say a financial entity should contract only with providers that follow appropriate information security standards, and for critical functions should consider the most up-to-date and highest quality standards. Many European buyers read that as a preference for an international management system standard, so they often ask for ISO 27001 certification alongside or instead of SOC 2. Certification is issued by a certification body, not by ISO. Check whether the customer will accept a SOC 2 report in that role, and whether the AICPA's mapping of the 2017 Trust Services Criteria to ISO 27001 helps them compare the two.

What does the work need from our own staff?

Expect staff time from engineering, IT, HR, legal and whoever owns the vendor relationships. Engineers provide system configuration, access and logging evidence, and change records. HR supplies joiner, leaver and training records. Leadership approves policies, reviews risk and signs the management assertion and representation letter that the CPA firm requests. Someone must also own the control matrix and answer auditor requests on time. Staff who do this work need to understand the controls well enough to explain them to an assessor, which is the main reason outside help is used for preparation rather than for the audit itself.

Can our own team prepare for SOC 2 without a partner?

Yes, many teams do, provided someone can own the project and has time to build controls, collect evidence and run an internal review before fieldwork. The CPA firm performs the examination and issues the report, so it cannot prepare the controls for you without raising independence questions, which is worth confirming. An implementation partner can configure systems, document controls and produce evidence, but it does not issue reports or certificates. Decide early which parts your team will keep and which parts to buy, and agree the scope in writing before any work starts.

What drives the cost and effort of a SOC 2 for European buyers?

The main drivers are the scope (which trust services categories and systems are included), the number of systems and third parties, how mature the existing evidence is, and the report type and observation period. Costs fall into the CPA firm's examination fee, preparation work, tooling and staff time, and some of these recur each year. No supplied figure sets a price for this work. Ask the CPA firm for a written engagement letter that states the scope, report type, observation period, fees and what is excluded, and ask any implementation partner for a fixed-scope written proposal with deliverables and timelines.

How do we check a SOC 2 report or certificate?

Ask the vendor for the full report, not only a seal or summary, and confirm that it was issued by an independent CPA firm, that it states the trust services categories and period covered, and that it includes the auditor's opinion and any exceptions. A SOC 3 report is a general use summary that can be shared freely, while a SOC 2 report is usually restricted to specific users under an NDA. For ISO 27001, check that the certification body is accredited and look up the certificate in IAF CertSearch, which lists certificates issued by accredited bodies. Confirm the scope and the expiry date for both, and ask the customer which checks its own policy requires.

How DeployOpen prepares your systems and evidence for a European review

DeployOpen works with the organization that owns the controls, preparing the self-hosted platforms, configurations and evidence that a European customer or supervisor will ask to see. Independent auditors and certification bodies issue any report or certificate, and DeployOpen does not.

How we scope

We agree in writing which services, platforms and customer-facing functions fall inside the engagement before work starts.
We map the contract clauses your European customers request against the assurance you already hold, so gaps are named early.
Scope, deliverables and timelines are fixed in writing, and the quote follows from that written scope.

How we build

We implement and harden self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks.
We configure access, logging, backup, incident and vulnerability handling so each control leaves records a reviewer can inspect.
We run security testing of applications, APIs and infrastructure where the scope calls for it, and document the findings and fixes.

How we hand over

We document system descriptions, control design, ownership and evidence locations so your team can answer audit rights requests.
We prepare the evidence pack and control matrix for review by your independent auditor, without issuing any report ourselves.
We confirm with you which points the report does not cover, such as the customer's own audit and inspection rights, and record them.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can keep evidence current between assessment cycles and update documentation when platforms change.
Ask us to confirm in writing which parts of your evidence require your own staff, your auditor or your regulator's review.

Is SOC 2 accepted by European customers under DORA and NIS2