Which should an EU-facing SaaS or cloud provider pursue first?
NIS2 is a legal duty only if your entity is in scope under the national law that transposes Directive (EU) 2022/2555 in each Member State where you operate, while a SOC 2 report is a voluntary attestation that buyers request. So the first decision is not which to buy but whether you are in scope at all. Check the sector and size criteria in the NIS2 Directive, then confirm with the competent authority or your national transposition text how it applies to your entity. Ask your customers which of them are essential or important entities, because their supplier contracts may require cybersecurity terms even if you are not in scope yourself.
Once scope is settled, the decision rule is short. If you are out of scope, a SOC 2 Type 2 is usually the faster evidence to hand to EU enterprise buyers, and it can be scoped to the trust services criteria your customers test. If you are in scope, NIS2 duties apply directly through registration, staged incident reporting and risk management measures, and authorities can ask for evidence such as audit results and the underlying records. Doing both is common for providers in scope, but a SOC 2 report does not discharge NIS2 duties, and it does not cover registration, incident reporting deadlines or management body obligations. Plan those separately, and check whether your national authority expects the security audit evidence described in the NIS2 Directive text.
Sequence the work so that evidence is reused. Map your existing controls to both the SOC 2 criteria and the Article 21 measures, and use the ENISA technical implementation guidance as a non-binding reference for the evidence examples it gives. Note that the Commission proposed targeted NIS2 amendments in January 2026, so confirm the current scope and obligations before you commit budget. Ask any assessor or consultant for a written scope that separates attestation work from NIS2 readiness work.
Who must comply with NIS2, and who asks for SOC 2
NIS2 is a directive, so its duties reach a provider through the national law that each Member State adopted, and the 18 covered sectors include digital infrastructure and digital provider entities. Cloud computing, data center, CDN, managed service, managed security service, DNS, TLD, online platform and trust service providers are named in Implementing Regulation (EU) 2024/2690, which sets the technical requirements for their Article 21(2) measures. Managed and managed security service providers fall under Annex I when they meet the size-cap rule, and the classification decides the supervisory regime.
- Essential or important: Essential entities face ex ante supervision, meaning authorities can act before an incident. Important entities face ex post supervision, meaning action follows evidence of a failure. Both carry the same risk-management and incident reporting duties.
- Registration: In-scope providers must register with the national authority (Articles 3 and 27), so check your national transposition law for the exact process.
- Staged incident reporting: Notifications follow the 24-hour, 72-hour and one-month steps in Article 23.
- Evidence on request: Authorities may ask for implementation evidence, including results of security audits by a qualified auditor and the underlying files (Articles 32(2)(g) and 33(2)(f)).
- Proposal status: The Commission's January 2026 proposal (COM(2026) 13) would add a small mid-cap category. It is still a proposal, so confirm current status before scoping.
Confirm your classification and national registration route with counsel or the competent authority.
A company can fall outside NIS2 and still be affected because its in-scope customers must manage security across their supplier relationships. Article 21(2)(d) places that duty on the customer, and Implementing Regulation 2024/2690 lists what supplier contracts should cover where appropriate. This is where most SaaS and managed service vendors meet NIS2, usually through a questionnaire or contract addendum rather than a regulator letter.
- Contract terms: Expect requests on cybersecurity requirements, staff training, background checks, incident notification without undue delay, audit rights or audit reports, vulnerability handling, subcontracting and exit obligations.
- Audit reports as an option: Customers may accept a SOC 2 report as one form of assurance, but the contract text decides whether it satisfies an audit right.
- Subcontractors: Your own suppliers may be pulled into the same flow, so map them early.
- Incident timing: Your notification clock may need to fit the customer's 24-hour first stage, so check it against your own runbook.
- Scope drift: If a customer's classification changes, the contract terms they request may change too.
Ask each customer which clauses they must meet and whether a SOC 2 Type 2 report is acceptable evidence under their policy.
If you have no EU customers and no EU-established operations that bring you into a national NIS2 scope, the directive does not create a legal duty for you. Your security obligations then come from other laws, contracts and the buyers you serve. SOC 2 is requested by buyers, not required by law, so for a US-only provider the question is usually which customers ask for it and what they need the report to cover.
- Legal duty: NIS2 binds through national transposition, so no EU national law applies unless the entity or its services reach an EU Member State under the relevant rules.
- Buyer requests: US enterprise and public buyers often ask for SOC 2 in procurement, which is a commercial choice rather than a legal one.
- Report scope: A SOC 2 covers the trust services criteria you select, so the Security category is the base for most questionnaires.
- Change in footprint: A later EU customer, subsidiary or data center may bring you into scope, so track that trigger.
- Voluntary alignment: Some teams map controls to NIS2 anyway because the 2024/2690 guidance is a useful checklist.
Confirm your EU exposure with counsel before concluding you are out of scope.
How SOC 2 and NIS2 differ on scope, proof and enforcement
This table sets NIS2, a binding EU directive enforced by national authorities, beside SOC 2, a CPA attestation a customer requests. Read it to separate what a SOC 2 report can evidence from what NIS2 obliges you to do and show to a regulator.
| Dimension | SOC 2 | NIS2 |
|---|---|---|
| Legal basis | Voluntary attestation under AICPA attestation standards (AT-C section 205); no law requires it | Directive (EU) 2022/2555, applied through national transposition laws; binding once transposed |
| Who requires it | Customers and partners who ask for it in procurement or contracts | National competent authorities, for entities in scope as essential or important |
| Scope | Systems and trust services criteria the provider chooses; security is always in scope | 18 sectors across Annex I and Annex II, with size-cap and classification rules |
| What is issued | A CPA report: Type 1 on design at a date, Type 2 on operating effectiveness over a period | No certificate of compliance is issued |
| Who examines it | Independent CPA firm acting as service auditor | National authorities through inspections, security audits, scans and information requests |
| Incident reporting | Not part of the SOC 2 examination | Early warning within 24 hours, incident notification within 72 hours, final report within one month (Article 23) |
| Fines | No regulatory fines arise from the report itself | Maximums of at least EUR 10 million or 2% of worldwide turnover for essential entities, and at least EUR 7 million or 1.4% for important entities, whichever is higher (Article 34) |
| Shareable with customers | SOC 2 use is generally restricted to specified parties; a SOC 3 report is general use and can be freely distributed | Authorities hold the evidence; customers receive what your contracts and supplier diligence require |
How NIS2 reaches suppliers through Article 21(2)(d)
A SaaS, managed service or cloud provider outside NIS2 scope still feels the Directive through its customers' contracts. Article 21(2)(d) requires in-scope entities to address supply chain security, including the security relationships with their direct suppliers and service providers. In practice, an essential or important customer will send you a security addendum, a questionnaire or a redline of its master agreement, and those documents decide what you must do regardless of whether you are in scope yourself.
Implementing Regulation (EU) 2024/2690, Annex point 5.1.4, lists what supplier contracts must where appropriate cover for digital infrastructure and digital provider entities: cybersecurity requirements, staff training, background checks, incident notification without undue delay, audit rights or audit reports, vulnerability handling, subcontracting and exit obligations. Read that list as a term sheet. For each item, check whether your current master agreement, data processing terms and service descriptions already say something specific, and who on your side owns the answer. Vague wording such as "commercially reasonable security" will not satisfy a buyer that must show its own regulator how it managed the supplier.
A SOC 2 report can serve as one input to audit rights, because it gives the customer independent evidence of controls over a stated period. It does not replace the contract terms. The report does not commit you to a notification clock, a subcontractor approval process or an exit plan, and it covers only the trust services criteria and system boundary the auditor tested. Managed security service providers deserve particular attention: recital 86 calls for increased diligence when selecting them, so expect buyers to ask for more than a standard report. Confirm with counsel and with each customer which terms are negotiable and which are fixed in their own NIS2 policy.
Where SOC 2 and NIS2 overlap, and the duties no audit report covers
The overlap between SOC 2 and NIS2 is real but partial, and the gap is larger than most vendors expect. ENISA's non-binding technical implementation guidance for Implementing Regulation 2024/2690, published 26 June 2025, maps its evidence examples to ISO/IEC 27001:2022 and NIST CSF 2.0, and the CIS Controls Navigator for v8.1 lists both SOC 2 and NIS2, so a control set built for one can be traced to the other. ENISA states that its mapping is not a measure of equivalence and does not assess whether a standard fully covers the regulation. A SOC 2 report therefore reduces evidence work for the Article 21 measures, but it does not prove them. Ask your auditor to show, criterion by criterion, which common criteria (CC6 to CC9 in particular) map to the Implementing Regulation's technical requirements, and where a point of focus is left unaddressed.
Several NIS2 duties sit outside any attestation. In-scope entities must register with the national competent authority, and the staged incident reporting clock runs at 24 hours, 72 hours and one month under Article 23. Article 20 places duties on the management body, including approving cybersecurity risk-management measures, overseeing their implementation and following training, and it carries personal liability. A SOC 2 examines controls over a period and does not test whether an incident was reported on time or whether a board completed its training. Supervisory audits and information requests under Articles 32 and 33 also remain the authority's tools, not the auditor's. Confirm the registration deadline, the reporting channel and the training expectations with your national competent authority, because transposition rules differ by Member State.
Plan for these gaps before a customer or regulator asks. Assign an owner for each NIS2 duty, keep a dated record of board approvals and training, and rehearse the 24-hour early warning against a written procedure. Then decide which SOC 2 evidence you can share with a customer under Article 21(2)(d) supplier-management clauses, and which NIS2 evidence (such as incident timelines) you will hold internally. Note that a SOC 2 report is generally restricted in use, so the contract should define who may receive it. Your NIS2 readiness review should be scoped separately from the SOC 2 examination, with its own deliverables and sign-off.
Controls that can serve both frameworks
A SOC 2 Type 2 and NIS2 supervision both ask for evidence that controls ran over time, not just that they were designed. The cards below cover the work areas where one evidence set can often serve both, provided each item is mapped to the Implementing Regulation's requirements and the mapping is checked.
Access control evidence
A SOC 2 Type 2 tests logical access criteria over a period, so the population of access grants, reviews and removals already exists in many firms. NIS2 supervisors can ask for evidence of access management under the Implementing Regulation's Article 21(2) measures. Check that your review records show who approved access, when it was revoked, and whether privileged accounts are covered, since a SOC 2 sample may not reach every privileged account.
Change management records
Change tickets, peer review and release approvals tested under the SOC 2 change management criteria can show how modifications reached production. NIS2 covers secure development and maintenance in the same risk-management measures, so the same tickets may serve both. Confirm that the Implementing Regulation's technical requirements for this area are addressed in your own change procedure, not only in the auditor's test script.
Incident response process
A SOC 2 tests whether incidents are identified, handled and documented, but it does not test the NIS2 clock. Reporting under Article 23 runs as an early warning within 24 hours, an incident notification within 72 hours and a final report within one month. Your SOC 2 incident procedure can be the base, but you must add the notification steps, contacts and timers the regulation requires.
Supplier management
Vendor reviews, contract clauses and audit reports collected for SOC 2 CC9 work can support the supplier obligations that Article 21(2)(d) places on in-scope customers. Implementing Regulation point 5.1.4 lists items such as incident notification, audit rights and exit obligations. Check each supplier contract for those clauses, because a vendor's SOC 2 report does not itself prove the contract terms exist.
Vulnerability handling
Patch timelines, scan results and remediation tickets gathered for a SOC 2 Type 2 show whether vulnerabilities were handled over the audit period. NIS2 supervisors may ask for the results of security scans and audits, and for the underlying evidence behind them. Confirm that your scan scope covers the systems in your NIS2 scope, since a SOC 2 system description may define a narrower boundary.
Logging and evidence retention
Audit logs and evidence stores built for SOC 2 testing often serve as the record an authority asks to see. Authorities may request underlying evidence and the results of audits carried out by a qualified auditor. Confirm that the retention period, integrity controls and access to these records meet what your national authority expects, because a SOC 2 sample set does not guarantee completeness.
Who assesses each framework, what it issues and how often
This table compares who assesses SOC 2 and NIS2, what each produces and what period it covers. Read it to see which proof a customer can request and which proof a national authority can demand, since the two never substitute for each other.
| Dimension | SOC 2 | NIS2 |
|---|---|---|
| Assessor | A CPA firm acting as service auditor, performing the examination under AICPA attestation standards | National competent authority supervises compliance; authorities may request security audits carried out by a qualified auditor |
| Output | A SOC 2 Type 1 or Type 2 report issued by the CPA firm, which customers may request under use restrictions | No certificate of compliance is issued; oversight comes through inspections, audits, scans, information requests and fines |
| Period covered | Type 1 covers the system description and control design as of a date; Type 2 adds operating effectiveness over a period | Obligations apply continuously once in scope; there is no attestation window to point to |
| Observation period | Set by the engagement and the AICPA 2017 Trust Services Criteria with 2022 points of focus; confirm the length with your auditor | No defined observation period; authorities decide what evidence and timing they request |
| Cycle | Annual or periodic reissue is common practice, not a legal requirement; confirm the cadence customers expect | Supervision depends on essential or important status: ex ante for essential entities, ex post for important entities |
| Upcoming change | AICPA proposed attestation standard revisions in February 2026; if adopted, they apply to engagements beginning on or after June 15, 2029 | Commission proposed targeted amendments on 20 January 2026 (COM(2026) 13); still a proposal pending Parliament and Council approval |
In what order to do SOC 2 and NIS2 work
This sequence settles whether NIS2 applies before any audit spend, then builds the control evidence once so that a SOC 2 report and NIS2 supervision both draw on the same records.
Confirm NIS2 scope under national law
Start with the sector and size of your organization, then check the national transposition law in each EU Member State where you provide services. NIS2 is a directive, so the obligations that apply to you come through that national law, and Member States may adopt or keep rules that go further (Article 5). Check whether your service type is named in Annex I or Annex II, whether you meet the size-cap rule, and whether you are classed as essential or important under Article 3. Ask counsel to confirm the position in writing, because a proposal to amend NIS2 (COM(2026) 13) is pending and may change thresholds. The step is done when you have a written scope memo listing each entity, Member State and classification, with a named owner for re-checking it.
Map Implementing Regulation 2024/2690 to existing controls
For cloud, data center, managed service, managed security service and other covered providers, the technical requirements of the Article 21(2) measures are set by Commission Implementing Regulation (EU) 2024/2690. Your security lead or an external assessor maps each requirement to the controls you already run, and marks each one as covered, partly covered or missing. ENISA's non-binding technical implementation guidance of June 2025 gives examples of evidence and mappings to ISO/IEC 27001:2022 and NIST CSF 2.0, which helps build the map. The step closes with a gap register that records the evidence owner and the artifact that proves each control, such as logs, test results or signed procedures.
Close gaps in incident reporting and registration
NIS2 duties that no SOC 2 report covers sit here: registration with the authority (Articles 3 and 27), and staged incident reporting at 24 hours, 72 hours and one month (Article 23). Assign an incident owner, write the notification decision tree, and rehearse it against your customer and authority contacts. Confirm the registration route and any national portal with the competent authority, since the procedure depends on the Member State. Management body training and liability (Article 20) also belong in this step, with attendance records kept. The step is done when registration is filed or scheduled, the reporting clock is documented, and a tabletop exercise has produced a dated record of what was tested.
Choose TSC categories and scope for SOC 2
Decide which trust services categories the SOC 2 will include. Security is covered by the common criteria CC1 to CC9, which apply to every SOC 2, while availability, processing integrity, confidentiality and privacy are added only when they are in scope. Set the system boundary to match the services your EU customers buy, and align it with the NIS2 scope from step one so the two do not describe different systems. Management prepares the system description against the AICPA's 2018 description criteria. The step is done when the scope statement, system description and list of in-scope categories are approved by management and reviewed by the planned service auditor.
Run the SOC 2 Type 1 or Type 2 engagement
A Type 1 report covers the system description and the design of controls as of a date. A Type 2 report adds an opinion on operating effectiveness over a period, so it needs evidence that controls ran throughout that period. Your CPA firm, not DeployOpen, issues the report, and management signs the written representations required under AT-C section 205. Ask the auditor to confirm which Type fits the customer request, the observation period, and what evidence samples they will request. The step closes when the auditor issues the report and you have decided how to share it, bearing in mind that use of a SOC 2 report is generally restricted while a SOC 3 report can be freely distributed.
Reuse mapped evidence across both obligations
Use the gap register and the SOC 2 control evidence as one library, tagged by control so each item can be pulled for an authority request or an auditor sample. Authorities may ask for evidence of implementation, including the results of security audits carried out by a qualified auditor and the underlying evidence (Articles 32(2)(g) and 33(2)(f)). Keep the NIS2-specific items, such as reporting records and registration proof, in a separate section, because no SOC 2 report covers them. Re-run the mapping after each audit cycle and after any change to the NIS2 scope or the proposed amendments. The step is done when a named owner can produce any mapped item within a set internal time, which you should test rather than assume.
Questions buyers ask before choosing or combining SOC 2 and NIS2
Does a SOC 2 report make us NIS2 compliant?
No. A SOC 2 report is a CPA attestation on the controls you chose to examine, and it does not certify NIS2 compliance. NIS2 is national law, and it creates no certificate of compliance. National competent authorities oversee it through inspections, security audits, security scans, information requests and administrative fines under Articles 32 to 34. A SOC 2 can serve as one piece of evidence for the risk-management measures under Article 21, and it may help with supplier diligence. It does not cover registration with the authority, the staged incident reports due within 24 hours, 72 hours and one month under Article 23, or management body training and liability under Article 20. Confirm with your national competent authority which evidence it accepts.
How do we know if we are in scope for NIS2?
Start with the sector and size. NIS2 covers 18 sectors, split between 11 high-criticality sectors in Annex I and 7 other critical sectors in Annex II, and in-scope entities are classified as essential or important under Article 3. Cloud, data center, managed service and managed security service providers are named in Implementing Regulation (EU) 2024/2690, and managed providers are themselves in scope under Annex I when they meet the size-cap rule. Even if you are out of scope, your in-scope EU customers must manage security in their relationships with direct suppliers under Article 21(2)(d), so they may ask you for evidence. Your national transposition law sets the final test, so confirm your classification with the national authority or with qualified legal counsel in each Member State where you serve customers.
What drives NIS2 and SOC 2 cost and effort?
Two different kinds of work are paid for. A SOC 2 is an examination, so the auditor's fee is the largest recurring line, and it depends on the systems in scope, the trust services categories you include beyond security, the number of control owners to interview, and whether you buy a Type 1 or a Type 2 covering an observation period. NIS2 cost is mostly internal and advisory: building the risk-management measures that Implementing Regulation 2024/2690 describes, registering, setting up 24-hour reporting, and training management. Costs rise with the number of customers, environments and subcontractors in the supplier chain. Ask any quote to separate one-time build work from recurring evidence collection, audits and retainer support, and to state which NIS2 items are excluded.
Can our team do this ourselves?
Often part of it, but the independence requirement applies to the SOC 2 examination. Your team can build the control set, write policies, collect evidence and run the internal reviews, but a licensed CPA firm must perform the SOC 2 examination, and an independent authority decides NIS2 supervision outcomes. For NIS2, the work is mostly engineering and governance: asset inventory, incident response, backup, supplier management and vulnerability handling mapped to the implementing regulation. Teams with prior ISO 27001 or similar programs usually have more of this in place. If your staff have not run an audit before, ask a partner to scope the readiness work in writing so you can see which tasks stay in-house.
What does the work need from our engineering, legal and leadership teams?
Each team owns different evidence. Engineering supplies configuration evidence, logging, access reviews, change records, backup tests and vulnerability handling, and runs the 24-hour early warning and incident workflow. Legal reviews customer contracts for the supplier clauses listed in Implementing Regulation 2024/2690, including incident notification, audit rights, subcontracting and exit obligations, and checks national transposition rules and registration duties. Leadership has to approve the scope, accept the residual risk, and complete the management body training that Article 20 requires. Because SOC 2 relies on written management representations under AT-C section 205, leadership also signs off on the system description. Name a single owner for each evidence stream before work starts.
How long does it take to get both in place?
Timing depends on your starting point, not a fixed schedule. A SOC 2 Type 1 covers the system description and control design as of a date, and a Type 2 adds an opinion on operating effectiveness over a period, so a Type 2 cannot be issued until the observation window has run. NIS2 timing depends on when your national authority requires registration and on how much of the incident reporting process already exists. No supplied source gives a duration for either, so ask the auditor for the observation period it expects and ask the national authority for its registration deadlines. Plan the two workstreams to share evidence, since a control built for NIS2 can often be examined for SOC 2.
What should we ask a quote to include?
Ask for the written scope, deliverables and timelines first, since most engagements are fixed-scope and agreed in writing before work starts. For a SOC 2 quote, ask which trust services categories and systems are in scope, whether the price covers Type 1, Type 2 or both, what the observation period is, and whether the auditor's fee is included or billed separately. For a NIS2 quote, ask which Implementing Regulation 2024/2690 measures are covered, whether registration and incident reporting procedures are included, and how evidence will be stored for an authority information request. Also ask what is excluded, what recurs each year, and which items need your legal counsel. DeployOpen does not publish a price list, and a quote follows from the written scope.
How DeployOpen prepares SOC 2 and NIS2 readiness
DeployOpen works on SOC 2 and NIS2 as two separate pieces of work: a service evidence package for customers and a set of technical and organizational controls that an authority could ask an in-scope provider to show. We plan, implement, document and hand over the systems, controls and evidence inside your own infrastructure, and we do not issue audit reports or certifications.
How we scope
- We agree scope, deliverables and timelines in writing before any work starts, as fixed-scope engagements.
- We first confirm whether your organization falls under NIS2 as a provider and which services are in scope.
- We identify which SOC 2 trust services criteria your customers actually request, with the auditor's input.
How we build
- We implement the technical controls that supplier and risk-management duties depend on, inside your own cloud or data center.
- We set up the evidence trail auditors and competent authorities would ask for, such as logs, change records and access reviews.
- We run security testing against the controls, so gaps are found before the independent auditor or authority reviews them.
How we hand over
- We deliver a documented system description, control narratives and an evidence index mapped to the agreed scope.
- We document the NIS2 duties that no SOC 2 report covers, including registration, incident reporting steps and management training records.
- We train your staff on running the controls and collecting evidence, so the work continues after the engagement ends.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- A retainer can keep evidence current for the next SOC 2 examination period and for changes in NIS2 national law.
- Before you sign, ask us to confirm in writing which deliverables sit with your auditor and which sit with us.
