NIS2 vs SOC 2: 3 Mandatory Requirements Your SOC 2 Type II Report Cannot Satisfy

When a US SaaS provider lands its first major EU enterprise client, someone on the compliance team eventually asks: “We have SOC 2 Type II — does that satisfy NIS2?” The answer is partial at best, and for three specific obligations, the answer is no.

SOC 2, defined by the AICPA Trust Services Criteria (2022 revision), is a voluntary attestation standard. An independent CPA firm examines your controls against five criteria and issues a report — valuable for winning enterprise contracts, but carrying no weight with EU regulators. NIS2 (Directive (EU) 2022/2555) is EU law. It became enforceable when the October 2024 national transposition deadline passed, and competent authorities across the EU can now audit, instruct, and fine organisations that fail to meet its requirements.

The productive question for any compliance team that already holds a SOC 2 Type II report is not “which framework is better” — it’s “which controls and evidence transfer across, and what do we need to build from scratch?” This article answers that question with a control-by-control mapping of each SOC 2 Trust Service Criterion to the relevant NIS2 Article 21(2) security measure, and a clear verdict on whether existing evidence can be reused or whether original documentation is required.

What Makes SOC 2 and NIS2 Fundamentally Different

SOC 2 and NIS2 differ in nature before they differ in requirements — and that distinction shapes everything about how evidence is structured and reported.

SOC 2 is an attestation framework. An independent Certified Public Accountant tests your organisation’s controls against the AICPA Trust Services Criteria and issues an opinion report. A Type II report covers a minimum six-month observation window during which the auditor tests whether controls operated effectively. That report is a commercial asset — it satisfies procurement questionnaires and enterprise security due diligence — but your organisation is under no legal obligation to hold one.

NIS2 is mandatory EU law. Directive (EU) 2022/2555 places binding cybersecurity obligations on essential and important entities across 18 sector categories defined in Annexes I and II. National competent authorities and CSIRTs can conduct on-site inspections, issue binding instructions, and impose administrative fines. Compliance is not optional.

The table below captures the structural differences that matter most for compliance teams assessing where the two frameworks align and where they diverge:

Dimension	SOC 2	NIS2
Legal status	Voluntary attestation standard	Mandatory EU law (Directive (EU) 2022/2555)
Issuing body	AICPA (US accounting professional body)	European Parliament and Council of the EU
Enforcement mechanism	None — market-driven adoption	National competent authorities and CSIRTs
Maximum penalty	None	€10M or 2% of global turnover (essential entities); €7M or 1.4% (important entities)
Evidence recipient	Customers, procurement teams	Regulators, national CSIRTs
Audit cycle	Point-in-time (Type I) or 6–12 months (Type II)	Continuous operational obligation
Geographic scope	Global — primarily US market adoption	EU-wide; extraterritorial for digital service providers
Management liability	Not applicable	Article 20 — personal liability for management body members

Neither framework substitutes for the other. A SOC 2 Type II report tells your customers that your controls operated effectively during the audit period. NIS2 compliance tells EU regulators that your organisation meets mandatory baseline security measures. An organisation can hold a clean SOC 2 Type II opinion and be non-compliant with NIS2 — and vice versa.

Does NIS2 Apply to Your Organisation? — US Companies Included

NIS2 scope is not limited to EU-incorporated entities. For digital service categories, the directive applies extraterritorially: any entity providing services in the EU market falls in scope regardless of where it is incorporated or where its infrastructure is located. According to Skadden’s October 2024 NIS2 compliance guidance, non-EU companies are in scope if they “provide their services or carry out their activities within the EU” — regardless of establishment location, and including US companies whose marketing material mentions EU customers or whose services are available in EU languages or currencies.

Thresholds for essential and important entities

The base size trigger applies to organisations with more than 50 employees or annual turnover and balance sheet exceeding €10 million. This threshold is calculated on a consolidated group basis — a 30-person EU subsidiary of a 10,000-person US parent does not benefit from the small-entity exemption because the group as a whole exceeds the threshold.

The US company decision tree

1. Does your organisation provide services consumed in the EU? If yes, continue.
2. Does your organisation operate in one of the 18 NIS2 sectors listed in Annexes I and II of the directive? If yes, continue.
3. Does the consolidated group exceed 50 employees or €10 million annual turnover? If yes, the organisation is likely in scope as an essential or important entity.
4. Does your service category fall under digital providers — cloud computing, managed services, DNS, content delivery networks, data centres, online marketplaces, or search engines? If yes, extraterritorial scope applies regardless of EU establishment.

US-based MSPs, SaaS providers, and cloud companies frequently find themselves in scope not through direct registration but through their EU clients’ supply chain security obligations. When an EU essential entity — a hospital, energy operator, or financial institution — contracts a US-based managed security services provider, that provider may fall under Article 21(2)(d) obligations as a direct supplier. The EU client’s compliance team will require contractual flow-down, and your SOC 2 vendor management documentation will not satisfy that requirement. The full NIS2 scope and size threshold guide covers sector-specific analysis in detail.

SOC 2 Trust Services Criteria Mapped to NIS2 Article 21

Article 21(2) of Directive (EU) 2022/2555 defines 10 mandatory security measure categories that all essential and important entities must address. The AICPA Trust Services Criteria cover five categories. The mapping below shows where SOC 2 audit evidence carries weight in NIS2 compliance, and where the two frameworks diverge completely.

SOC 2 Trust Service Criterion	NIS2 Article 21(2) Measure(s)	Overlap Level	Evidence Verdict
Security (CC1–CC9, mandatory criterion)	(a) risk analysis and IS security policies; (i) access control and asset management; (h) cryptography; (j) MFA and secure communications	Strong	Reuse — access control policies, risk assessments, MFA documentation transfer with minor adaptation
Availability (A1.1–A1.3)	(c) business continuity, backup management, disaster recovery, crisis management	Moderate	Reuse — BCP, disaster recovery plans, backup schedules, and RTO/RPO documentation carry over
Confidentiality (C1.1–C1.2)	(h) cryptography and encryption policies	Moderate	Reuse — encryption policy and data classification documentation transfer directly
Processing Integrity (PI1.1–PI1.5)	(f) policies to assess the effectiveness of cybersecurity risk-management measures	Weak	Partial — control testing methodology overlaps, but NIS2 requires a broader periodic review covering all 10 Article 21(2) measures
Privacy (P1–P8)	No direct equivalent under Article 21	None	No equivalent — NIS2 defers personal data protection to the GDPR; Article 21 does not address privacy controls

Four NIS2 Article 21(2) measures have no meaningful SOC 2 counterpart: (b) incident handling directed toward public authorities; (d) supply chain security with contractual flow-down obligations; (e) security in acquisition, development, and maintenance of network and information systems across the full procurement lifecycle; and (g) basic cyber hygiene and cybersecurity training, which SOC 2 touches in CC1.4 but which NIS2 pairs with mandatory Article 20 management body training requirements that go well beyond general security awareness.

Compliance teams reviewing SOC 2 Type II reports alongside NIS2 gap analyses consistently find that the Security criterion evidence transfers with the least friction. CC6 access control policies, MFA implementation evidence, and access review logs often require only a formatting update to sit in a NIS2 evidence dossier — the substantive control is the same. The friction appears precisely at the boundary between internal operational controls and external regulatory obligations. For the full breakdown of each Article 21(2) measure, see the NIS2 requirements guide.

What SOC 2 Type II Evidence Can Be Reused for NIS2

SOC 2 Type II evidence is most transferable in four areas. In each case, the tested documentation satisfies the corresponding NIS2 Article 21(2) measure with specific additions to make it NIS2-native rather than SOC 2-native.

Access control and identity management

SOC 2 CC6 (Logical and Physical Access Controls) generates policies and auditor-tested evidence covering access provisioning, MFA implementation, privileged account management, and periodic access reviews. This maps directly to NIS2 Article 21(2)(i) (access control and asset management) and Article 21(2)(j) (MFA and secure communications). The primary NIS2 addition is linking the access control register to a formal risk assessment that traces each control to a named threat scenario. Most SOC 2 programmes already maintain this linkage — it typically requires a mapping appendix rather than new control work.

Encryption and cryptography

SOC 2 CC6.7 (encryption of data in transit and at rest) produces policies and auditor-tested evidence that map cleanly to NIS2 Article 21(2)(h). Standard controls — AES-256 at rest, TLS 1.3 in transit — satisfy both frameworks at the technical level. NIS2’s specific addition is a documented rationale for cryptographic choices referencing “the state of the art,” as required by Article 21(1). A one-page cryptography policy preamble citing the relevant technical standard (such as CIR 2024/2690 implementation guidance) completes the evidence package.

Business continuity and disaster recovery

SOC 2 Availability criterion documentation — business continuity plans, disaster recovery procedures, backup schedules, recovery time and recovery point objectives — maps to NIS2 Article 21(2)(c). The SOC 2 evidence package typically satisfies initial NIS2 compliance demonstrations for this measure. The NIS2-specific addition is crisis management procedures relevant to the entity’s sector: an energy operator needs crisis protocols different from a cloud provider, and this sector-specific layer is not something SOC 2 auditors test.

Risk assessment methodology

SOC 2 CC3 (Risk Assessment) produces a risk register and methodology documentation. This supports NIS2 Article 21(2)(a) (risk analysis and information system security policies). The adaptation required is to restructure or annotate the risk register so that each identified risk links explicitly to the relevant Article 21(2) measure category — a formatting change rather than a substantive control change in most cases.

The boundary of reuse is the boundary between controls you implement internally and obligations directed externally. SOC 2 Type II evidence covers what your organisation does inside its own perimeter. NIS2 includes obligations performed toward public authorities, supply chain partners, and the governing body. Those externally-directed obligations are not internal control questions — they are regulatory duties that fall entirely outside what a SOC 2 audit tests.

The 3 NIS2 Obligations That SOC 2 Cannot Satisfy — and Where Personal Liability Lives

Three NIS2 obligations have no SOC 2 equivalent. They are not gaps in SOC 2’s design — SOC 2 was never intended to be a regulatory compliance framework. These obligations address dimensions of mandatory law that a voluntary attestation standard was not built to handle.

Gap 1: Mandatory incident reporting to public authorities (Article 23)

NIS2 Article 23 requires essential and important entities to notify their national CSIRT or competent authority in three stages when a significant incident occurs:

• Within 24 hours of becoming aware: an early warning indicating whether the incident was caused by malicious acts or has cross-border impact
• Within 72 hours: an incident notification with an initial assessment, severity indication, and available indicators of compromise
• Within one month: a final report with a detailed description, root cause analysis, applied mitigation measures, and cross-border impact assessment

SOC 2 CC7.3 requires incident logging, classification, and escalation — but to internal stakeholders and, where contractually required, to affected customers. There is no requirement to notify any government body or CSIRT at any timeline. A US managed security services provider with a mature SOC 2 incident response programme and a 48-hour internal triage SLA is non-compliant with Article 23 the moment a significant incident occurs — not because their processes are inadequate, but because those processes terminate at the wrong recipient.

Gap 2: Supply chain co-liability (Article 21(2)(d))

Article 21(2)(d) requires entities to address supply chain security “including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.” In practice, regulators expect three layers of evidence:

• A documented supplier criticality register classifying direct suppliers by risk level, with the classification methodology recorded
• Contracts with critical suppliers containing clauses that require those suppliers to implement Article 21-equivalent security measures, notify you of incidents within your own 24-hour reporting window, and permit security audits
• Documented evidence that those clauses have been exercised — at least one audit report, one correctly relayed incident notification, or one formal supplier security assessment per regulatory audit cycle

SOC 2 CC9.2 (Vendor and Business Partner Management) documents that your organisation assesses and monitors supplier risk. It does not require suppliers to be contractually obligated to implement specific security measures, nor does it require proof that those contractual obligations were exercised. This is the distinction that creates upstream risk for US companies serving EU entities: when an EU essential entity’s compliance team requires supplier security evidence, your SOC 2 vendor management documentation addresses the question of whether you assessed your suppliers — not whether your suppliers meet NIS2-equivalent security obligations.

Gap 3: Governing body personal accountability (Article 20)

NIS2 Article 20 places direct obligations on the management body of essential and important entities — the board of directors, supervisory board, or equivalent governance structure. Three specific requirements apply:

• The management body must formally approve all cybersecurity risk-management measures and oversee their implementation; this obligation cannot be delegated away
• All management body members must complete cybersecurity training at appointment and at least annually thereafter, with completion documented and available for regulatory inspection
• Member states may hold individual management body members personally liable for infringements — not just the organisation, but named directors, with sanctions that can include temporary bans from exercising managerial functions

Penalties for essential entities reach €10 million or 2% of global annual turnover; for important entities, €7 million or 1.4%. SOC 2 assesses organisational control maturity with no concept of management body approval of controls, mandatory board-level cybersecurity training, or personal liability for individual directors. A board that governs a SOC 2-certified organisation has met no NIS2 governance standard whatsoever.

A Practical Compliance Strategy When You Hold Both Frameworks

Organisations that need both SOC 2 and NIS2 compliance should build one evidence base and document it twice — running two separate compliance programmes in parallel duplicates effort and typically produces inconsistent evidence that creates audit risk in both directions.

1. Map your existing SOC 2 controls to Article 21(2) — using the reuse table above, identify which tested controls already satisfy NIS2 measures. The Security criterion (particularly CC6 and CC3) and the Availability criterion will cover the most ground.
2. Extend the risk register to NIS2 format — add an Article 21(2) measure column to your existing SOC 2 risk register so that each documented risk links to the relevant NIS2 obligation. This satisfies Article 21(2)(a) without duplicating the underlying risk assessment.
3. Build the three gap areas separately — create authority-facing incident response procedures for Article 23 (separate from your SOC 2 internal escalation runbook), update critical supplier contracts with NIS2 flow-down clauses for Article 21(2)(d), and implement a board approval and documented training process for Article 20.
4. Layer NIS2-specific documentation — NIS2 regulators expect evidence structured against the 10 Article 21(2) measures. A compliance matrix mapping your existing SOC 2 controls to each measure, with the three gap areas clearly filled, is the most efficient way to demonstrate coverage.

ISO 27001 is an optional bridge, not a prerequisite. NIS2 Article 21(1) explicitly references European and international standards as relevant reference points, and ENISA technical guidance identifies ISO 27001 as a recognised implementation path. If your organisation already holds ISO 27001 certification, the gap to NIS2 compliance narrows substantially. If you do not, pursuing certification alongside NIS2 compliance is an additional investment rather than a required step. The NIS2 vs ISO 27001 comparison covers that decision in detail.

In practice, the most efficient approach is to treat your SOC 2 control library as the starting layer and build NIS2-specific modules on top — particularly for Article 23 incident notifications, where the trigger thresholds, notification format, and reporting recipient differ entirely from SOC 2 internal incident escalation procedures and require a completely separate notification runbook.

Frequently Asked Questions

Does SOC 2 Type II compliance satisfy NIS2 requirements?

No. SOC 2 Type II attestation satisfies a subset of NIS2 Article 21(2) security measures — primarily access control, encryption, business continuity, and risk assessment — but does not address mandatory incident reporting to public authorities (Article 23), supply chain contractual obligations with evidence of exercise (Article 21(2)(d)), or governing body formal approval and personal accountability (Article 20). An organisation with a full SOC 2 Type II opinion remains non-compliant with NIS2 until those three obligation gaps are addressed.

Is SOC 2 accepted as equivalent to NIS2 compliance in the EU?

No. The AICPA Trust Services Criteria are a US professional standard with no formal recognition under EU law. NIS2 does not list SOC 2 as an acceptable compliance demonstration. ENISA technical guidance references ISO 27001:2022 and CIR 2024/2690 as recognised implementation frameworks for Article 21(2) measures — SOC 2 is not referenced.

If I am a US company, where should I start?

First confirm whether you are in scope by working through the decision tree above or reviewing the detailed NIS2 scope guide. If in scope, map your existing SOC 2 controls to Article 21(2) using the reuse table in this article. Then build the three gap areas: Article 23 incident notification procedures, Article 21(2)(d) supply chain contractual clauses, and Article 20 board approval and training processes. These three areas require original documentation regardless of how mature your SOC 2 programme is.

SOC 2 Type II is credible evidence that your organisation maintains mature security controls. For EU regulatory compliance under NIS2, it addresses the technical control layer — access control, encryption, business continuity, risk assessment — but leaves three mandatory obligations entirely untouched: real-time incident reporting to public authorities, contractual supply chain security with documented evidence of exercise, and individual management body accountability with mandatory training. The reuse is real and worth capturing. The three unbridgeable gaps require original work regardless of how complete the SOC 2 programme is, and they are the gaps where enforcement exposure — including personal director liability — concentrates.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. European Union. Directive (EU) 2022/2555 — NIS 2 Directive. EUR-Lex, 2022. Articles 20, 21, 23, 32, 33.
2. American Institute of Certified Public Accountants. 2017 Trust Services Criteria (with Revised Points of Focus — 2022). AICPA and CIMA, 2022.
3. Skadden, Arps, Slate, Meagher and Flom LLP. Navigating the New Cybersecurity Landscape: Key Implications of the EU’s NIS 2 Directive. Skadden, October 2024.
4. NIS-2-directive.com. NIS 2 Directive, Article 23: Reporting obligations.
5. European Union Agency for Cybersecurity (ENISA). NIS Directive 2. ENISA, 2023–2026.