From Regulatory Text to Operational Reality
The NIS2 directive runs to fifty-one articles. The compliance conversation that productive programmes focus on runs to four. Articles 20, 21, 23, and 29 define the governance, risk management, incident reporting, and information sharing obligations that constitute the operational core of NIS2 compliance. Understanding each in practical operational terms, rather than as regulatory text, is the step that separates programmes building genuine capability from those assembling documentation.
This article translates each of the four pillars from what the directive requires to what an organisation needs to do, build, and operate to satisfy that requirement.
Article 20: Governance and Management Accountability
The operational requirement of Article 20 is that the management body of the organisation approves and oversees the cybersecurity risk management programme. This is not a one-time approval act. It is a continuing governance obligation that requires organisational structure to support it.
The technology capabilities that support Article 20 are governance reporting tools: the dashboards, reporting frameworks, and metrics systems that translate security programme performance into terms that the management body can interpret and act on. A CISO who can produce a monthly governance report showing policy compliance rates, incident response performance, supply chain assessment progress, and training coverage against the measures the management body approved has the evidence basis for the ongoing oversight that Article 20 requires.
The organisational changes that Article 20 requires are more significant than the technology changes. Formal designation of cybersecurity responsibility within the management body, scheduled board-level cybersecurity agenda items with documented discussion and resolution, and a defined escalation path for cybersecurity risks that warrant management body attention all need to be established and maintained.
The maturity assessment for Article 20 asks: can the organisation demonstrate, with documented evidence, that the management body has approved the cybersecurity risk management framework, receives regular performance reporting against it, and has engaged substantively with cybersecurity risk decisions in the last twelve months?
Article 21: Risk Management
Article 21 specifies the minimum measures that organisations must put in place. The full list runs to ten categories; the four that most commonly represent significant gaps in enterprise programmes are incident handling, supply chain security, access control and multi-factor authentication, and policies on the use of cryptography.
Incident handling requires not just a documented incident response plan but operational capability to execute it: detection tooling that identifies significant incidents within the timeframes that Article 23 reporting requires, response runbooks that are tested and current, communications templates that enable rapid regulatory notification, and escalation procedures that reach the management body for incidents of appropriate significance. The technology investment is primarily in detection and response tooling. The organisational investment is in the response practice, which requires regular testing to remain current.
Supply chain security requires a systematic programme rather than an ad hoc process. The technology capabilities needed include a supplier risk assessment platform or process, integration between the supplier assessment results and the organisation’s vendor management records, and contractual mechanisms that impose NIS2-equivalent security requirements on key suppliers. The organisational requirement is a supplier security programme with defined assessment cadence, clear remediation expectations, and escalation processes for suppliers that cannot meet required security standards.
Multi-factor authentication and access control are technical requirements with significant coverage gaps in most enterprise environments. The assessment of current MFA coverage, including service accounts, privileged access, and remote access, typically reveals gaps that require tooling investment, policy updates, and enforcement mechanisms. The priority is coverage of the access vectors most likely to be targeted: privileged user access, remote access, and administrative interfaces.
Cryptography policy compliance requires verification that data at rest and in transit is protected with current encryption standards, that cryptographic key management processes are documented and operating, and that deprecated or weak cryptographic implementations are identified and remediated.
Article 23: Incident Reporting
The operational requirement of Article 23 is the most time-sensitive of the four pillars. An early warning to the competent authority within twenty-four hours of becoming aware of a significant incident, a full notification within seventy-two hours, and a comprehensive report within one month are the required deliverables when a significant incident occurs.
“Significant incident” under NIS2 is defined as an incident that has caused or is capable of causing severe operational disruption to services or other financial or social impacts. The early warning requires characterisation of whether an incident crosses this threshold within twenty-four hours of detection. This requires detection tooling that provides rapid incident characterisation, not just alert generation.
The technology requirements for Article 23 compliance are: detection capability that identifies incidents of potential significance within hours of onset; investigation capability that characterises the incident’s scope, impact, and likely cause within twenty-four hours; and a regulatory reporting workflow that can produce the required notifications within the specified timeframes without requiring excessive manual assembly effort.
The organisational requirements are the response procedures and roles that activate those technology capabilities: who declares a significant incident, who notifies the competent authority, who gathers the information required for the full notification, and who prepares the final comprehensive report. Testing these procedures through tabletop exercises before a real incident is the difference between a compliant response capability and a compliant-looking procedure that fails under operational conditions.
Article 29: Cybersecurity Information Sharing
Article 29 establishes a framework for voluntary cybersecurity information sharing within the NIS2 ecosystem. Organisations can share threat intelligence, attack indicators, and vulnerability information with competent authorities, sector-specific authorities, and other organisations within information-sharing arrangements.
The operational requirement is not mandatory: Article 29 is a voluntary sharing framework, not a mandatory reporting obligation. Its compliance relevance is in the benefit it provides. Organisations that participate in relevant information sharing communities receive earlier warning of threat intelligence relevant to their sector, better context for assessing whether an event in their environment represents a significant incident under Article 23, and a documented relationship with the competent authority that is relevant if a compliance conversation becomes necessary.
The technology capability required to participate in information sharing is, at minimum, the ability to consume threat intelligence feeds and share indicators of compromise in the standard formats that information-sharing communities use. The organisational requirement is a designated contact for information sharing activities and a process for assessing incoming intelligence against the organisation’s specific environment.
The Maturity Assessment Framework
A practical maturity assessment for NIS2 compliance rates each of the four pillars on a five-level scale: from no documented requirement, through documented but not operational, through operational but not tested, through tested and continuously monitored, to continuously monitored with demonstrated regulatory communication capability.
Most organisations beginning their NIS2 programme in late 2023 will find themselves at levels one or two across most of the four pillars. The programme goal by October 2024 is level three or above across all four, with level four for the highest-priority gaps identified in the assessment.
This is achievable with the right programme structure, the right resourcing, and the right executive engagement. The fifth and final article in this series addresses the most frequently underestimated pillar: supply chain security and the third-party risk obligation that most organisations are not ready for.