NIS2 Art.17–21: Liability, Jurisdiction, DNS Data, Governance, and the 10 Risk Management Measures — Developer Guide (2026)

Articles 13–16 completed the EU-level coordination framework (crisis response plans, international cooperation, peer reviews, ENISA reporting). Articles 17–21 shift from institutional architecture to entity obligations — the rules that directly govern what your organisation must do.

Chapter IV of NIS2 contains two distinct layers. The first layer (Art.17–19) determines who is subject to obligations, where supervision applies, and which entity types must maintain DNS registration data. The second layer (Art.20–21) defines what those obligations are: board-level governance approval and the 10 mandatory cybersecurity risk-management measures.

For most developers at essential or important entities, Art.20 and Art.21 are the high-priority articles — they produce the security policies you must implement and the board approvals you must facilitate. Art.17's liability rules and Art.18's jurisdictional rules are equally important for compliance teams structuring multi-country operations.

Art.17: Liability of Natural Persons Responsible for an Essential or Important Entity

Article 17 introduces personal liability for the natural persons who bear responsibility for managing an essential or important entity. This is the NIS2 mechanism that connects board-level failures to individual accountability.

Who Is Liable Under Art.17

Art.17 applies to natural persons who hold a "responsibility" role — defined by reference to the entity's internal governance and national company law. In practice this means:

• Chief Executive Officers and Managing Directors — they have general management responsibility
• Chief Information Security Officers — where they hold delegated authority for cybersecurity measures
• Board members and supervisory board members — where they have approved (or failed to approve) risk management measures under Art.20
• Legal representatives — in entities without a traditional corporate structure

The liability connects specifically to infringements of Art.21 (risk management measures) and Art.23 (incident reporting). A CEO who directed staff to delay an incident report, or a board that refused to approve a required security measure, can be held personally liable under national implementing law.

What Liability Means in Practice

Art.17 does not create direct criminal liability — member states implement the personal accountability mechanism through their national NIS2 transposition laws. The typical range of consequences includes:

Germany's BSIG (§64 et seq.) and the Netherlands' Wet beveiliging netwerk- en informatiesystemen implement Art.17's individual accountability framework. Both allow NCAs to identify the responsible natural person and impose direct sanctions.

The Art.17–Art.20 Liability Chain

Art.17 operates together with Art.20's governance obligations. The chain runs:

1. Art.20(1): Management body must approve cybersecurity risk management measures
2. Art.20(1): Management body must oversee implementation
3. Art.20(2): Management body must complete cybersecurity training
4. Art.17: If management body fails steps 1–3, the natural persons responsible are individually liable
5. Art.32(6): NCAs may require a temporary ban on management functions

from dataclasses import dataclass
from enum import Enum
from typing import Optional

class LiabilityExposure(Enum):
    NONE = "no_exposure"
    LOW = "minor_procedural_gap"
    MEDIUM = "systematic_non_compliance"
    HIGH = "directed_infringement"
    CRITICAL = "repeated_or_severe"

@dataclass
class NIS2ManagementLiabilityAssessment:
    role: str  # "ceo", "ciso", "board_member", "legal_representative"
    approved_art21_measures: bool
    oversaw_implementation: bool
    completed_training: bool
    directed_non_compliance: bool
    prior_infringement: bool

    def exposure_level(self) -> LiabilityExposure:
        if self.directed_non_compliance:
            return LiabilityExposure.CRITICAL if self.prior_infringement else LiabilityExposure.HIGH
        gaps = sum([
            not self.approved_art21_measures,
            not self.oversaw_implementation,
            not self.completed_training,
        ])
        if gaps == 0:
            return LiabilityExposure.NONE
        if gaps == 1:
            return LiabilityExposure.LOW
        if gaps == 2:
            return LiabilityExposure.MEDIUM
        return LiabilityExposure.HIGH

    def requires_board_resolution(self) -> bool:
        return not self.approved_art21_measures

    def remediation_priority(self) -> list[str]:
        steps = []
        if not self.approved_art21_measures:
            steps.append("Draft Art.21 security policy for board approval — schedule board resolution")
        if not self.oversaw_implementation:
            steps.append("Establish quarterly CISO board reporting cadence")
        if not self.completed_training:
            steps.append("Enrol management body in NIS2 cybersecurity training programme")
        return steps

Art.18: Jurisdiction and Territoriality

Article 18 determines which member state's NCA supervises a given entity. For organisations operating across multiple EU countries, this is a critical question: one entity, one lead NCA.

The Main Establishment Rule

The default jurisdiction rule is the main establishment principle: the entity is subject to supervision by the NCA of the member state where its main establishment is located.

"Main establishment" is determined by reference to where the entity:

• Has its registered seat (registered office under company law), AND
• Makes decisions related to its cybersecurity risk management measures

Where the registered seat is in a different member state than the place where decisions are made, the decision-making location controls. This prevents forum shopping by formally registering in a member state with lighter enforcement while running operations elsewhere.

Multi-Establishment Entities

An entity with establishments in several member states is subject to the NCA of the member state of its main establishment, but it must also notify all other member states where it has establishments. The Art.18 rule creates a single lead supervisor (like GDPR's lead supervisory authority mechanism) while requiring notification across all jurisdictions.

from dataclasses import dataclass

@dataclass
class Establishment:
    member_state: str  # ISO 3166-1 alpha-2, e.g. "DE", "NL", "AT"
    is_registered_seat: bool
    cybersecurity_decisions_made_here: bool
    employee_count: int
    is_main_establishment: bool = False

@dataclass
class NIS2JurisdictionAnalysis:
    entity_name: str
    establishments: list[Establishment]
    entity_type: str  # "standard", "dns_registry", "tld_operator", "cloud_provider", "managed_service"

    def determine_lead_nca(self) -> str:
        # Art.18(1): decision-making location controls over registered seat
        decision_sites = [e for e in self.establishments if e.cybersecurity_decisions_made_here]
        if len(decision_sites) == 1:
            return decision_sites[0].member_state
        # Fallback to registered seat
        registered = [e for e in self.establishments if e.is_registered_seat]
        if registered:
            return registered[0].member_state
        # Fallback to largest employee base
        return max(self.establishments, key=lambda e: e.employee_count).member_state

    def notification_obligations(self) -> list[str]:
        lead = self.determine_lead_nca()
        return [e.member_state for e in self.establishments if e.member_state != lead]

    def needs_eu_representative(self) -> bool:
        # Art.18(6): third-country entities must designate EU representative
        # Approximated here as no EU establishment present
        return not any(e.member_state != "THIRD_COUNTRY" for e in self.establishments)

Special Jurisdiction Cases

Certain entity types follow modified jurisdiction rules:

Third-country entities — companies headquartered outside the EU that provide network/information system services within the EU — must designate a representative in a member state where they offer services (Art.18 read with Art.26). That representative becomes the point of contact for NCA supervision.

Art.19: Database of Domain Name Registration Data

Article 19 addresses WHOIS — the database mapping domain names to registrant contact information. For most SaaS developers this article is not directly applicable, but it becomes relevant if you operate any DNS infrastructure.

Who Art.19 Applies To

• TLD name registry operators (.de, .nl, .at, .eu registries)
• DNS service providers as defined in Annex I and Annex II

Standard SaaS companies and cloud platforms that use DNS but do not operate registries are not directly subject to Art.19.

What the Database Must Contain

Art.19 requires TLD registries to maintain a database with "accurate and complete" domain name registration data. The mandatory data fields include:

Art.19(3) creates a tension with GDPR: registrant contact data for natural persons constitutes personal data. The resolution is that publicly accessible WHOIS is limited to non-personal data (organisation name, registration dates, technical data), while personal contact data is accessible only to legitimate access requestors under Art.19(4).

Legitimate Access Requests

Art.19(4) requires TLD registries to provide "unduly delayed" access to domain registration data to:

• NCAs and CSIRTs acting under NIS2
• Law enforcement authorities
• ENISA for cybersecurity research
• Entities with a "legitimate interest" (cybersecurity researchers, threat intelligence providers)

from dataclasses import dataclass
from enum import Enum

class AccessRequestType(Enum):
    NCA_CSIRT = "nca_csirt"
    LAW_ENFORCEMENT = "law_enforcement"
    ENISA = "enisa"
    LEGITIMATE_INTEREST = "legitimate_interest"
    PUBLIC = "public"

@dataclass
class WHOISAccessPolicy:
    requestor_type: AccessRequestType

    PERSONAL_DATA_ACCESSIBLE = {
        AccessRequestType.NCA_CSIRT,
        AccessRequestType.LAW_ENFORCEMENT,
        AccessRequestType.ENISA,
        AccessRequestType.LEGITIMATE_INTEREST,
    }

    def can_access_personal_data(self) -> bool:
        return self.requestor_type in self.PERSONAL_DATA_ACCESSIBLE

    def response_sla_hours(self) -> int:
        if self.requestor_type in {AccessRequestType.NCA_CSIRT, AccessRequestType.LAW_ENFORCEMENT}:
            return 24  # "without undue delay" interpreted as 24h for authorities
        if self.requestor_type == AccessRequestType.ENISA:
            return 72
        return 168  # legitimate interest: one week

    def requires_documentation(self) -> bool:
        return self.requestor_type == AccessRequestType.LEGITIMATE_INTEREST

Art.20: Governance

Article 20 is the management obligation that connects board-level decision-making to NIS2 compliance. It is the most frequently referenced article in NCA audit findings because it creates formal approval requirements that most organisations have never operationalised.

The Three Board Obligations

Obligation 1: Approve cybersecurity risk management measures (Art.20(1))

The management body — not the CISO, not the IT department — must formally approve the entity's cybersecurity risk management measures under Art.21. This requires a documented board resolution, not just sign-off on a policy document.

In practice, this means:

• A board meeting agenda item on cybersecurity risk management
• Minutes recording approval of the security policy framework
• Periodic re-approval when measures change materially

Obligation 2: Oversee implementation (Art.20(1))

Approval is not enough — the board must actively oversee that approved measures are implemented. This is operationalised through:

• Regular CISO reporting to the board (quarterly minimum)
• Board-level KPIs for security measure effectiveness
• Escalation protocols when measures fail

Obligation 3: Complete cybersecurity training (Art.20(2))

Management body members must undergo cybersecurity training sufficient to understand the entity's cybersecurity risks and their implications. Training must be:

• Tailored to the entity's sector and risk profile
• Completed at least annually
• Documented (attendance records, training content)
• Offered to employees where appropriate (Art.20(2) encouragement, not mandate)

Who Counts as the Management Body

"Management body" in NIS2 means the board of directors, supervisory board, or equivalent body with governance authority. In a startup with no board, it typically means the founders/managing directors who collectively govern the entity.

from dataclasses import dataclass
from datetime import date, timedelta

@dataclass
class ManagementBodyComplianceRecord:
    entity_name: str
    last_art21_approval_date: date | None
    last_training_date: date | None
    ciso_reporting_cadence_days: int
    approved_measures_documented: bool

    MAX_APPROVAL_AGE_DAYS = 365
    MAX_TRAINING_AGE_DAYS = 365
    MAX_REPORTING_GAP_DAYS = 92  # ~quarterly

    def art20_1_compliant(self) -> bool:
        if not self.approved_measures_documented:
            return False
        if self.last_art21_approval_date is None:
            return False
        return (date.today() - self.last_art21_approval_date).days <= self.MAX_APPROVAL_AGE_DAYS

    def art20_2_compliant(self) -> bool:
        if self.last_training_date is None:
            return False
        return (date.today() - self.last_training_date).days <= self.MAX_TRAINING_AGE_DAYS

    def oversight_compliant(self) -> bool:
        return self.ciso_reporting_cadence_days <= self.MAX_REPORTING_GAP_DAYS

    def next_approval_due(self) -> date | None:
        if self.last_art21_approval_date is None:
            return date.today()
        return self.last_art21_approval_date + timedelta(days=self.MAX_APPROVAL_AGE_DAYS)

    def compliance_gaps(self) -> list[str]:
        gaps = []
        if not self.art20_1_compliant():
            gaps.append("Art.20(1): Board approval of Art.21 measures missing or expired")
        if not self.art20_2_compliant():
            gaps.append("Art.20(2): Management body cybersecurity training overdue")
        if not self.oversight_compliant():
            gaps.append(f"Art.20(1): CISO reporting gap exceeds {self.MAX_REPORTING_GAP_DAYS} days")
        return gaps

For a deeper dive into Art.20 obligations including Germany, Netherlands, and Austria enforcement patterns, see NIS2 Art.20: Management Body Cybersecurity Obligations.

Art.21: Cybersecurity Risk-Management Measures — The 10 Mandatory Measures

Article 21 is the technical core of NIS2 for developers. It defines the risk management framework and — in Art.21(2) — the 10 categories of measures that all essential and important entities must implement.

Art.21(1): The Proportionality Principle

Measures must be "appropriate and proportionate" based on four factors:

1. State of the art — what is technically feasible and available today
2. Cost of implementation — measures should not be disproportionate to the entity's resources
3. Size of the entity — large enterprises face stricter expectations than SMEs
4. Exposure to risks — entities with high risk profiles must do more

The proportionality principle means there is no single NIS2 compliance checklist valid for all entities. A 50-employee SaaS processing payment data in financial services faces higher expectations than a 50-employee logistics software company.

Art.21(2): The 10 Mandatory Measure Categories

The ten categories are:

(a) Risk Analysis and Information Security Policies

Entities must maintain documented risk analysis processes and information security policies. The risk analysis must be:

• Conducted at regular intervals (minimum annually, more often after incidents)
• Documented with risk treatment decisions
• Connected to the Art.21(2) measures implemented

from dataclasses import dataclass
from datetime import date

@dataclass
class NIS2RiskManagementMeasures:
    entity_name: str

    # (a) Risk analysis
    risk_analysis_date: date | None
    security_policy_approved: bool

    # (b) Incident handling
    incident_response_plan_exists: bool
    incident_handling_tested: bool

    # (c) Business continuity
    backup_policy_exists: bool
    dr_plan_tested: bool
    crisis_management_plan: bool

    # (d) Supply chain
    supplier_security_requirements: bool
    supplier_assessments_conducted: bool

    # (e) Secure development
    sdlc_security_integrated: bool
    vulnerability_handling_process: bool

    # (f) Effectiveness assessment
    security_metrics_defined: bool
    audit_schedule_exists: bool

    # (g) Cyber hygiene + training
    baseline_hygiene_policy: bool
    employee_training_programme: bool

    # (h) Cryptography
    encryption_policy_exists: bool
    key_management_process: bool

    # (i) Access control + HR security
    access_control_policy: bool
    asset_management_process: bool
    hr_security_procedures: bool

    # (j) MFA + secure communications
    mfa_deployed_admin: bool
    mfa_deployed_users: bool
    secure_comms_available: bool

    def compliance_matrix(self) -> dict[str, bool]:
        return {
            "21(2)(a) Risk analysis + IS policy": self.risk_analysis_date is not None and self.security_policy_approved,
            "21(2)(b) Incident handling": self.incident_response_plan_exists and self.incident_handling_tested,
            "21(2)(c) Business continuity": self.backup_policy_exists and self.dr_plan_tested and self.crisis_management_plan,
            "21(2)(d) Supply chain security": self.supplier_security_requirements and self.supplier_assessments_conducted,
            "21(2)(e) Secure development": self.sdlc_security_integrated and self.vulnerability_handling_process,
            "21(2)(f) Effectiveness assessment": self.security_metrics_defined and self.audit_schedule_exists,
            "21(2)(g) Cyber hygiene + training": self.baseline_hygiene_policy and self.employee_training_programme,
            "21(2)(h) Cryptography": self.encryption_policy_exists and self.key_management_process,
            "21(2)(i) Access control + HR": self.access_control_policy and self.asset_management_process and self.hr_security_procedures,
            "21(2)(j) MFA + secure comms": self.mfa_deployed_admin and self.mfa_deployed_users and self.secure_comms_available,
        }

    def compliance_score(self) -> float:
        matrix = self.compliance_matrix()
        return sum(matrix.values()) / len(matrix)

    def gaps(self) -> list[str]:
        return [measure for measure, compliant in self.compliance_matrix().items() if not compliant]

(b) Incident Handling

An incident response plan must exist, be tested, and include:

• Detection and classification procedures
• Containment and eradication workflows
• Recovery and post-incident review
• Connection to Art.23 reporting timelines (24h early warning, 72h notification)

(c) Business Continuity, Backup, Disaster Recovery, and Crisis Management

Three distinct sub-requirements:

• Backup management: regular, tested, off-site or offline backups
• Disaster recovery: documented RTO/RPO targets, tested recovery procedures
• Crisis management: defined communication lines and escalation paths during incidents

See DORA Art.11 BCP Policy: RTO/RPO for an in-depth treatment of BCP/DR requirements applicable under both DORA and NIS2.

(d) Supply Chain Security

Entities must ensure security in supply chain relationships, including:

• Security requirements in supplier contracts
• Risk assessment of suppliers before onboarding
• Periodic review of supplier security posture
• Specific attention to software supply chain (SBOMs, vulnerability disclosure from suppliers)

The Art.21(2)(d) supply chain requirement is broader than it appears. "Suppliers and service providers" includes:

• Cloud infrastructure providers (AWS, Azure, GCP — even for EU-hosted workloads)
• SaaS tools with privileged access to your systems
• Open source dependencies (via software supply chain)
• Managed service providers (MSPs, MSSPs)

For the intersection of supply chain security with DORA ICT Third-Party Risk Management, see NIS2 Art.22: EU-Level Coordinated Security Risk Assessment.

(e) Security in Network/Information System Acquisition, Development, and Maintenance

This is the Secure Development Lifecycle (SDLC) requirement. It covers:

• Security requirements in procurement (both buying and building)
• Vulnerability handling and disclosure (PSIRT process)
• Secure coding practices and security testing in development
• Patch management for deployed systems

The phrase "including vulnerability handling and disclosure" creates an Art.21(2)(e)–Art.12 bridge: your vulnerability disclosure policy serves both the Art.12 CVD framework and the Art.21(2)(e) SDLC obligation.

(f) Policies and Procedures to Assess the Effectiveness of Risk Management Measures

Security measures must be evaluated. This requires:

• Defined security KPIs and metrics
• Periodic security audits or assessments
• Penetration testing (required by the Commission implementing acts for higher-risk entities)
• Audit findings feeding back into the risk analysis process

(g) Basic Cyber Hygiene Practices and Cybersecurity Training

Cyber hygiene is the baseline: patch management, least-privilege, password policies, email filtering, endpoint protection. The "basic" qualifier does not mean optional — it means these are the floor, not the ceiling.

Training requirements:

• Annual cybersecurity awareness training for all employees
• Role-specific training for developers (secure coding), admins (privileged access), and executives (Art.20(2))
• Phishing simulation is recommended but not mandated

(h) Cryptography and Encryption Policies

A documented cryptography policy must specify:

• When encryption is required (data at rest, data in transit, backups)
• Which algorithms are approved (avoiding deprecated ciphers)
• Key management lifecycle (generation, rotation, destruction)
• Certificate management (expiry monitoring, revocation procedures)

(i) Human Resources Security, Access Control, and Asset Management

Three sub-components:

HR security: background checks for privileged roles, onboarding security briefings, offboarding procedures (access revocation within 24 hours of departure).

Access control: role-based access control (RBAC), principle of least privilege, periodic access reviews (at least annually), privileged access management (PAM) for administrative accounts.

Asset management: inventory of all network and information systems, classification by criticality, lifecycle management including secure disposal.

(j) MFA, Continuous Authentication, and Secure Communications

This is the most prescriptive of the 10 measures. Art.21(2)(j) requires:

• Multi-factor authentication (MFA) for all privileged access and, where appropriate, for all users
• Continuous authentication mechanisms — session monitoring, anomaly detection
• Secure voice, video, and text communications for internal emergency communications
• Secure emergency communication systems within the entity

The MFA requirement is absolute for administrative/privileged accounts. For end-users, "where appropriate" allows proportionality — but NCA guidance in Germany (BSI Orientierungshilfe NIS2) and the Netherlands (NCSC NIS2 Handreiking) both recommend mandatory user MFA for all entities processing sensitive data.

For detailed implementation guidance, see NIS2 Art.21(2)(j): MFA Implementation Guide.

Art.21(3) and (4): Commission Implementing Acts

Art.21(3) authorises the Commission to adopt implementing acts specifying technical and methodological requirements for specific entity categories by February 2025.

Art.21(4) adds a further category of implementing acts covering:

• Cloud computing service providers
• Content delivery networks (CDN)
• Managed service providers (MSPs) and managed security service providers (MSSPs)
• Online marketplace, online search engine, and social networking platform operators
• Trust service providers
• DNS service providers and TLD registry operators

These implementing acts may impose requirements beyond the 10 base measures — including penetration testing, SOC 2 equivalents, or specific cryptographic standards. Monitor the ENISA NIS2 implementation guidance for sector-specific updates.

The Art.17–Art.21 Compliance Chain

The five articles form a closed loop of accountability:

Art.18 (Jurisdiction)
  → determines WHICH NCA supervises you
  → NCA from your main establishment applies Art.21 standards

Art.19 (DNS Data) — DNS/TLD operators only
  → WHOIS accuracy requirements
  → Legitimate access obligations

Art.20 (Governance)
  → Board MUST approve your Art.21 security policy
  → Board MUST oversee implementation
  → Board MUST complete training
  → Non-compliance → Art.17 personal liability

Art.21 (10 Measures)
  → 10 measure categories implemented proportionately
  → Non-compliance → Art.32 penalties on the entity
  → If management body directed non-compliance → Art.17 personal liability

Art.17 (Liability)
  → Natural persons responsible bear individual consequences
  → Sanctions, temporary bans, publication

Implementation Checklist: Art.17–21

Next in the NIS2 Series

Article 22 extends the supply chain obligation from entity-level (Art.21(2)(d)) to EU-level: the Commission and the Cooperation Group must conduct coordinated security risk assessments of critical supply chains that feed into national NCA guidance and affect your Art.21(2)(d) obligations.

For detailed guidance on each individual security measure, the deep-dive series covers: Art.21(2)(a) Risk Analysis · Art.21(2)(b) Incident Handling · Art.21(2)(c) Business Continuity · Art.21(2)(j) MFA.

See Also

• NIS2 Art.13–16: Union Crisis Response Plan, International Cooperation, Peer Reviews, ENISA Reporting — the EU governance tier that Art.17 liability and Art.18 jurisdiction plug into
• NIS2 Art.22–24: Supply Chain Risk Assessment, Incident Reporting, and Registration — extends Art.21(2)(d) supply chain obligations to EU level
• NIS2 Art.20: Management Body Cybersecurity Obligations — deep-dive on board approval, CISO reporting, and training requirements
• NIS2 Art.21(1): Proportionality Framework — how to calibrate the 10 measures to your entity size and risk profile
• NIS2/GDPR Dual Reporting: Simultaneous Incident Notification — Art.23 incident reporting in parallel with GDPR Art.33