NIS2 Outsourcing to an MSSP: The Article 20 Liability You Can Never Delegate

Every MSSP sales conversation eventually lands on the same reassurance: “We’ll handle your NIS2 compliance.” It’s not false, exactly — a good MSSP genuinely can carry a large share of the technical workload. But Article 20 of the NIS2 Directive draws a line that no service agreement, however comprehensive, can cross: the approval and oversight of your risk-management measures sits with your management body personally, and that duty doesn’t transfer with the invoice. [1]

This isn’t a theoretical distinction. It determines what you can safely hand to a provider, what has to stay with an internal owner even if a vendor executes the work, and — when something goes wrong — whose contract cap absorbs the damage versus whose regulatory fine doesn’t care whose staff made the mistake. This guide works through that line measure by measure: what an MSSP can genuinely cover under Article 21(2), the four obligations no contract reassigns, the liability mechanics that catch most outsourcing decisions off guard, and the specific contract clauses Commission Implementing Regulation 2024/2690 requires you to negotiate before you sign.

Who This Applies To: Outsourcing Under NIS2 in Plain Language

If your organisation is in scope for the NIS2 Directive (EU) 2022/2555 — classified as an essential or important entity under Annex I or II — and you use, or are evaluating, a managed service provider (MSP) or managed security service provider (MSSP) for any part of your security operations, this applies to you. It doesn’t matter whether the MSSP runs your entire SOC or just monitors one firewall: the moment a third party touches a control that maps to Article 21(2), the outsourcing question is live.

Two quick checks decide whether the rest of this guide is your operating manual:

• Is your organisation an essential or important entity under NIS2 Annex I/II?
• Are you using, or planning to use, an external provider for any function inside Article 21(2)(a)–(j) — risk analysis, incident handling, business continuity, supply chain security, system security, effectiveness assessment, cyber hygiene, cryptography, HR/access control, or authentication? [2]

If both answers are yes, the fines below apply to your organisation directly — not to whichever provider’s staff configured the control that failed:

Entity type	Maximum fine	Trigger
Essential entity	€10,000,000 or 2% of worldwide annual turnover, whichever is higher	Infringement of Article 21 or Article 23
Important entity	€7,000,000 or 1.4% of worldwide annual turnover, whichever is higher	Infringement of Article 21 or Article 23

[8] For the full penalty framework by member state, see the penalties guide.

Article 20: You Can Delegate Execution, Not Liability

Article 20(1) of the NIS2 Directive requires the management body of an essential or important entity to approve the cybersecurity risk-management measures taken under Article 21, oversee their implementation, and states that members of that body “can be held liable for infringements by the entities of that Article.” [1] That sentence is doing all the work in this guide: the approval and oversight duty sits with your board or equivalent management body, and it cannot be reassigned by a service agreement.

Recital 83 of the Directive removes any ambiguity about outsourcing specifically: the risk-management and reporting obligations “should apply to the relevant essential and important entities regardless of whether those entities maintain their network and information systems internally or outsource the maintenance thereof.” [3] Hiring an MSSP doesn’t create a second regulated party who inherits your Article 20 duty — it creates a vendor whose work product your management body still has to approve and oversee.

Recital 86 adds a layer specific to security providers: MSSPs are valuable for incident response, penetration testing, security audits, and consultancy, but the Directive flags that these providers are themselves frequent attack targets and are unusually deeply integrated into client systems — so entities are expected to “exercise increased diligence in selecting a managed security service provider.” [3] In practice, that diligence obligation is itself something the board has to be able to evidence, not just hand to procurement.

Germany’s competent authority states this in the plainest terms available from any national regulator: “Even if IT is completely outsourced, you as a particularly important or important entity remain personally responsible.” [4] The BSI FAQ goes on to specify what that responsibility looks like operationally — the entity must ensure its providers implement the required measures, verify that regularly, and confirm incidents are reported correctly. [4] For the full mechanics of board obligations, see Article 20: Management Liability.

Article 21, Measure by Measure: What an MSSP Can and Cannot Cover

Article 21(2) lists ten categories of measures. [2] Some translate cleanly into a managed service — an MSSP’s SOC can run 24/7 monitoring more consistently than most internal teams. Others require decisions, sign-offs, or organisational knowledge no outside provider has access to. The table below rates each category on how well outsourcing typically fits, based on what the measure actually requires — a decision versus a technical execution — rather than what a vendor’s sales page claims it covers.

Article 21(2) measure	What it requires	MSSP fit
(a) Risk analysis & information security policy	Board-approved policy + entity-specific risk register	Partial — MSSP can run the assessment; approval stays internal
(b) Incident handling	24/7 detection, triage, playbooks	Good — core MSSP/SOC service
(c) Business continuity, backup, disaster recovery	Tested recovery procedures + crisis decision authority	Partial — MSSP executes backups/DR tests; activation decision is internal
(d) Supply chain security	Assessing your own suppliers’ cybersecurity practices	Cannot delegate — your obligation about your OTHER vendors
(e) Secure acquisition, development & maintenance	Secure procurement criteria, patch management	Good — common MSSP/MSP function
(f) Effectiveness assessment procedures	Internal audit and management review cadence	Partial — MSSP supplies data; review is a governance function
(g) Cyber hygiene & security training	Organisation-wide training delivery	Good — often bundled by MSSPs
(h) Cryptography and encryption policy	Policy decisions on what/how to encrypt	Partial — MSSP implements; policy authorship stays internal
(i) HR security, access control, asset management	Employee vetting, joiner/leaver process, asset inventory	Partial — MSSP administers access; HR decisions are internal
(j) MFA, secured communications, emergency comms	Technical deployment	Good — standard MSSP/MSP deployment

Read down that middle column and a pattern emerges: measures that are pure execution — detection, patching, MFA deployment, training delivery — delegate well. Measures that require a judgment call tied to your organisation’s specific risk tolerance — what counts as an acceptable supplier, what triggers disaster recovery activation, what the encryption policy actually says — don’t, because judgment calls are exactly what Article 20 puts on the board. For the complete measure-by-measure breakdown independent of outsourcing, see Article 21: The Complete Guide.

Four Things That Stay Yours No Matter Who You Hire

Beyond the measure-by-measure breakdown, four obligations sit entirely outside what any MSSP contract can cover, regardless of price tier:

1. Registration and formal notifications to your competent authority. The Directive assigns this to the entity, not its service providers — even when an MSSP’s SOC is first to spot a significant incident, the notification obligation belongs to the client entity, not the SOC operator.
2. Article 20 approval and oversight itself. The management body has to actually review and sign off on the risk-management measures, not receive a vendor’s monthly report and file it. [1]
3. Assessing your own supply chain under Article 21(2)(d) — including, technically, assessing the MSSP itself as one of your suppliers. [2] An MSSP cannot audit itself on your behalf and have that count as your Article 21(3) supplier assessment.
4. Legal and reputational accountability for a breach. A contractual liability cap in your MSSP agreement limits what you can recover from the provider — it does nothing to limit what the competent authority can fine your organisation, up to €10,000,000 or 2% of turnover for essential entities, whichever is higher. [8]

The Liability Flow-Down Problem: Why Their Contract Cap Isn’t Your Exposure

This is the mechanism most outsourcing decisions get wrong, and it’s rarely explained outside a law firm’s client memo. Managed security services agreements typically cap the provider’s liability for direct damages at a multiple of the fees you pay them, with a separate, higher cap carved out specifically for data-security breaches. [7]

The gap opens when the failure isn’t classified as a “data security” breach but as a services failure — a missed alert, a misconfigured detection rule, a delayed escalation. That kind of failure typically falls under the lower direct-damages cap and often excludes consequential damages entirely. [7] Meanwhile, the entity that hired the MSSP is still exposed to the full weight of Article 34: administrative fines up to the higher of a fixed amount or a percentage of global turnover, [8] plus breach notification costs, client relationship damage, and — under Article 20 — potential personal exposure for management body members if the failure traces back to inadequate oversight. [1]

In plain terms: your MSSP’s contract was priced to cover their risk, not yours. A modest monitoring contract with a liability cap tied to those fees was never going to absorb a seven-figure regulatory fine, and it isn’t meant to — that’s not what the cap is for. The fix isn’t demanding a bigger cap; most providers won’t offer one at a price you’d pay. It’s building your own compliance evidence trail so the fine is never triggered by an unreviewed gap in the first place.

The 8 Contract Clauses CIR 2024/2690 Requires You to Negotiate

Commission Implementing Regulation (EU) 2024/2690 gives supply chain security a specific technical shape under Article 21(2)(d), and Section 5.1.4 of its Annex lists exactly what your contract with a supplier — including an MSSP — has to specify. [5] These aren’t suggestions; they’re the documentation a regulator will ask to see when reviewing your supply chain security policy.

1. Cybersecurity requirements for the provider, including security expectations for any ICT products or services they supply
2. Staff awareness, skills, training, and certifications — proof the analysts on your account are actually qualified
3. Background verification of the provider’s employees who touch your systems
4. An obligation on the provider to notify you of risk-relevant incidents without undue delay — set this tighter than the statutory 24 hours, because their detection has to leave you enough runway to make your own notification
5. Audit rights — the right to audit the provider directly, or at minimum receive their audit reports
6. A vulnerability-handling obligation covering how the provider manages weaknesses they discover
7. Subcontracting terms, including a cybersecurity requirements cascade to any subcontractor the MSSP uses
8. Termination obligations — data retrieval and disposal when the relationship ends

Most standard MSSP master service agreements cover perhaps half this list by default. The other half — audit rights and the subcontracting cascade especially — usually has to be negotiated in explicitly. For a clause-by-clause negotiation guide, see Vendor Contract Clauses.

5 Questions to Ask Before You Sign an MSSP Contract

Put these five questions to any MSSP candidate — and to your own team if the honest answer isn’t clear yet.

1. What’s my notification window with you, and does it leave enough time for my own 24-hour early-warning report? See the notification-cascade breakdown if you’re unsure how that clock actually starts.
2. Which CIR §5.1.4 clauses are already in your standard agreement, and which need a rider? [5]
3. Can I audit you, or only receive a summary report? Audit rights are on the mandatory list — a “no” here isn’t just inconvenient, it’s non-compliant. [5]
4. If your SOC misses something, what direct-damages cap applies — the lower “services” cap or the higher “data security” cap? [7]
5. What documentation will I actually have in front of a competent authority six months from now — supplier assessment records, board sign-off, the risk register — versus what only exists in your provider’s dashboard?

If a candidate can’t answer all five clearly, that’s diagnostic information about the relationship you’re about to sign, not just about their compliance maturity.

Frequently Asked Questions

Does hiring an MSSP satisfy my Article 21(2)(d) supply chain security obligation?
No. Article 21(2)(d) requires you to assess the cybersecurity practices of your own suppliers [2] — the MSSP is one of the suppliers you have to assess, not a mechanism for meeting the requirement on your behalf.

Is an MSSP itself regulated under NIS2?
Often yes. Managed service providers and managed security service providers are named digital infrastructure entities under NIS2 and CIR 2024/2690, meaning many MSSPs carry their own separate Article 21 obligations independent of yours — see The MSSP NIS2 Compliance Paradox for how that dual-obligation structure works.

If our MSSP causes the breach, do we still get fined?
Yes, potentially. The competent authority’s Article 34 fine is assessed against your organisation as the regulated entity, not your provider, [8] regardless of whose staff or tooling caused the failure — your recourse against the MSSP runs through your contract’s liability terms, separately.

Is full outsourcing ever the wrong call, even for a small entity?
Not inherently — Recital 83 explicitly acknowledges outsourced maintenance as a normal, accepted arrangement [3] — but small entities often assume outsourcing removes the governance workload too. It doesn’t; a two-person compliance team still has to review and sign off on what the MSSP is doing. That’s a smaller job than running a SOC internally, but not a zero job.

Key Takeaways

• Article 20 puts approval and oversight of your Article 21 risk-management measures on your management body — a services contract cannot reassign that duty. [1]
• Recital 83 confirms obligations apply the same whether systems are run internally or outsourced; Recital 86 signals that entities should exercise increased diligence specifically when selecting an MSSP. [3]
• Rate each Article 21(2) measure on whether it’s execution (delegates well) or judgment (doesn’t) before deciding what to outsource.
• An MSSP’s contractual liability cap protects the MSSP’s exposure, not your Article 34 fine exposure. [7][8]
• CIR 2024/2690 §5.1.4 gives you an 8-item checklist for what your MSSP contract legally needs to say. [5]

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. NIS 2 Directive, Article 20: Governance
2. NIS 2 Directive, Article 21: Cybersecurity risk-management measures
3. NIS 2 Directive, Preamble 81–90 (Recitals 83 & 86)
4. BSI (Germany) — NIS-2 FAQ
5. Commission Implementing Regulation (EU) 2024/2690, Annex Section 5.1.4
6. DLA Piper — ENISA Guidelines on Compliance with the NIS 2 Directive
7. “Navigating Service Provider Liability in Managed Security Services Agreements” — Loeb & Loeb LLP (loeb.com)
8. NIS 2 Directive, Article 34: Maximum Administrative Fines