NIS2's most significant practical shift for information security functions is the conversion of what was previously a matter of internal discretion into a binding legal obligation with personal management accountability. The ten minimum security measures that Article 21 requires will be broadly familiar to anyone working with ISO 27001 or the NIST Cybersecurity Framework. What changes is that implementing them becomes a legal requirement, that failure to implement them adequately has direct financial consequences, and that the individuals responsible for security governance at the management level face personal liability.
For organisations that have invested seriously in information security, NIS2 provides a regulatory framework that validates and, in some respects, formalises what they were already doing. For those that have treated information security as a compliance formality or a purely technical discipline without adequate governance, NIS2 requires a more fundamental shift.
The starting requirement of Article 21 is that entities must have documented risk analysis processes and information security policies. This is not simply a requirement to have a policy document. It requires a genuine, current assessment of the risks to the organisation's network and information systems, and policies that define how those risks are managed.
The risk analysis must be kept current. Static risk assessments conducted once and never revisited are not adequate: the risk environment changes, the organisation's technology changes, and the threat landscape changes. Information security policies must reflect current risk management decisions, not historical ones.
In practice, this requirement integrates directly with the enterprise risk management discipline. The ISO 27001 approach to information security risk assessment, which involves identifying assets, threats, vulnerabilities, and existing controls, and assessing likelihood and impact for each risk, provides a recognised methodology for satisfying this requirement.
Entities must have established, documented processes for handling security incidents, covering detection, classification, response, recovery, and post-incident review. The incident handling process must be capable of operating within NIS2's notification timelines, which means it must be designed for speed, not just comprehensiveness.
Key elements the process must include are: a clear definition of what constitutes a significant incident triggering notification obligations; a defined escalation path from technical teams to senior management and then to the competent authority; communication protocols both internal and external; and a post-incident review process that captures lessons and implements improvements.
The most common gap in existing incident handling processes is the absence of defined timelines for internal escalation. An incident that takes 18 hours to reach a decision-maker because nobody has defined who needs to be told and when cannot meet the 24-hour early warning requirement.
Entities must implement business continuity management appropriate to the nature and scale of their operations, covering backup management, disaster recovery, and crisis management. For information security purposes, this means specifically addressing how network and information systems and services would be maintained or restored following a significant security incident.
The backup management component requires not just having backup processes but testing them. Backups that are never tested may be incomplete, corrupted, or incompatible with current system versions. Discovering this during a ransomware recovery when the backups are the only remaining copy of critical data is a governance failure that NIS2 compliance should prevent.
Supply chain security is one of the most practically demanding Article 21 requirements. Entities must address security in their relationships with direct suppliers and service providers of ICT systems, products, and services.
This requires assessment of each supplier's security practices, specifically considering the overall quality of their products and services, the security practices they apply, and any contractual arrangements they have with their own sub-suppliers that could affect the security of the services they provide. The supply chain requirement recognises that an organisation's own strong security practices are partly undermined if critical suppliers have poor security.
In practice, supply chain security assessment is most tractable when it is risk-tiered. Critical suppliers whose products or services are deeply integrated into the organisation's operations, or who have access to sensitive data or systems, warrant detailed assessment. Lower-risk suppliers may be assessed through questionnaires or by verifying certification against recognised standards.
Security must be embedded into how systems are acquired, developed, and maintained, not added as an afterthought after systems are in production. This covers the evaluation of security in procurement processes, secure development practices for any in-house development, security testing before systems are deployed, and security considerations in ongoing maintenance and patching.
The patching dimension is practically significant. Unpatched vulnerabilities in operating systems and applications are the most common route for many categories of attack. Patch management processes that apply critical patches quickly to all relevant systems, and monitoring that identifies systems where patches are outstanding, are foundational to compliance with this requirement.
This requirement separates NIS2 from frameworks that focus only on implementing security measures. Entities must have policies for assessing whether their security measures are working, not just for implementing them. This is the governance principle that design effectiveness and operating effectiveness are distinct questions, and both must be addressed.
In practice, this means regular security assessments, internal audits of security controls, penetration testing, and KPI tracking for security performance. The assessment process must be systematic and documented, producing findings that feed into the improvement cycle.
All staff must receive cybersecurity training appropriate to their role. Senior management must receive specific training that allows them to assess and manage cybersecurity risks. This extends the security responsibility explicitly beyond the technical team to the entire organisation and to its leadership.
Basic cyber hygiene covers the foundational practices that reduce the most common attack surfaces: strong authentication, phishing awareness, secure handling of sensitive data, incident reporting procedures, and device and network security basics. These are not advanced technical topics. They are practices that every staff member with access to organisational systems should maintain.
Where appropriate given the risk profile of the information being protected, entities must use cryptography and encryption. The specification of "where appropriate" reflects a proportionality principle: entities are expected to apply cryptography based on the sensitivity of the data and the risks involved, not to apply it uniformly regardless of context.
In practice, most organisations processing personal data, financial data, or commercially sensitive information will need to demonstrate encryption of data at rest and in transit for sensitive information as a baseline. The policy requirement means this should be explicitly decided and documented, not handled inconsistently across different systems and teams.
Entities must implement processes covering the security aspects of employment, from pre-employment screening through to off-boarding; access controls that limit access to systems and data to those who need it for their role; and asset management that maintains a current inventory of the technology assets the organisation uses.
Access control is particularly significant: the principle of least privilege, granting access only to the minimum required for each role, and regular review of access rights to remove those no longer needed, are foundational practices that many organisations implement inconsistently.
Entities must use multi-factor authentication or continuous authentication for access to sensitive systems, and must use secured communications for voice, video, and text where appropriate. For most organisations, MFA for remote access to systems, for privileged accounts, and for access to sensitive data is the minimum implementation of this requirement.
NIS2 requires member states to ensure that management bodies of essential and important entities can be held personally liable for failures to comply with the security measures. This goes significantly beyond the collective organisational liability that characterised previous cybersecurity regulation.
In practical terms, this means security governance is a personal responsibility for the individuals who make up the management body, not only an organisational one. Boards that rubber-stamp security policies without genuinely engaging with their adequacy, or that fail to ensure security risks receive adequate attention and resources, are exposing their members to personal liability.
The appropriate response is not to make this a purely legal risk management exercise. It is to ensure that boards genuinely understand the security risk the organisation faces, receive adequate reporting to exercise meaningful oversight, and can demonstrate that engagement in governance documentation.
For most organisations, the practical starting point is a structured gap assessment against the ten Article 21 measures. This identifies where existing security practices already satisfy the requirements, where they partially satisfy them, and where material gaps exist. The assessment should produce a prioritised remediation plan with assigned ownership and timelines.
NIS2 compliance that cannot be evidenced is not compliance for regulatory purposes. Every significant security measure should have associated documentation: the policy that establishes it, the process that implements it, evidence that it is operating, and records of testing and review. Building an evidence management approach from the outset is considerably more efficient than assembling evidence retrospectively under supervisory pressure.
For organisations in the financial sector, NIS2 obligations sit alongside DORA requirements. Where DORA's more specific financial sector requirements cover the same ground as NIS2, DORA takes precedence. Building a governance framework that satisfies the more demanding of the two requirements typically produces more durable compliance than maintaining separate programmes, and is considerably less resource-intensive.
