A NIS2 programme can fail long before an incident occurs: when policies exist but no one owns them, evidence is scattered across inboxes, and directors receive a reassuring status update that cannot be substantiated. NIS2 compliance requirements are designed to address this gap. They ask organisations to manage cyber risk as an ongoing business responsibility, not a once-a-year documentation exercise.
For leaders, the practical question is not simply whether a control is in place. It is whether you can show that risks are understood, decisions are accountable, improvements are progressing and evidence remains current.
What NIS2 is asking organisations to achieve
NIS2 is the EU’s revised network and information systems security directive. It raises the baseline for cyber risk management and incident reporting across a broader range of sectors than its predecessor. The directive is implemented through national laws, so the precise scope, deadlines, registration process and penalties depend on the relevant Member State.
The directive generally distinguishes between essential and important entities. Whether an organisation falls within scope depends on factors such as sector, size, services and national implementation. Energy, transport, health, digital infrastructure, public administration, manufacturing and managed digital services may be included, among others.
UK organisations should not assume that being outside the EU removes the issue. A UK business providing relevant services into the EU, or supporting customers that are in scope, may face contractual requirements that reflect NIS2 expectations. For many suppliers, the immediate impact will be customer due diligence, requests for assurance and closer scrutiny of incident management.
The objective is straightforward: reduce the likelihood and impact of incidents affecting important services. The route to that objective is broader than technical security. It includes governance, supplier oversight, continuity planning, people, evidence and timely reporting.
NIS2 compliance requirements in practice
NIS2 requires appropriate and proportionate technical, operational and organisational measures to manage risks to network and information systems. “Appropriate” matters. A smaller organisation is not expected to copy the security operation of a national infrastructure provider. However, limited resources do not remove the need to make reasoned decisions, act on material risks and demonstrate progress.
The practical areas to address include:
- Risk analysis and information security policies that reflect the services, systems, data and threats that matter to the organisation.
- Incident handling, including detection, escalation, decision-making, communications and documented lessons learned.
- Business continuity, covering backups, disaster recovery, crisis management and the ability to maintain or restore critical services.
- Supply chain security, with proportionate checks on suppliers, managed service providers, cloud services and software dependencies.
- Secure acquisition, development and maintenance of systems, including vulnerability handling and patch management.
- Testing whether security measures work, rather than assuming a policy or purchased tool delivers the intended outcome.
- Cyber hygiene and training that help staff recognise their responsibilities and respond appropriately.
- The sensible use of cryptography and, where appropriate, encryption.
- Controls for people, access and assets, including clear joiner, mover and leaver processes.
- Multi-factor authentication or continuous authentication solutions where appropriate, alongside secure communications arrangements.
This is not a checklist to complete and file away. These areas connect. An unpatched system may be a vulnerability management issue, but it also raises questions about asset visibility, supplier responsibility, risk acceptance and incident readiness. Treating each requirement as a separate document usually creates more work and less assurance.
Leadership accountability is not optional
NIS2 gives management bodies a direct role in approving and overseeing cybersecurity risk-management measures. They must also undertake training to identify risks and understand their impact. National legislation determines how this is enforced, but the direction is clear: cyber risk is a board and leadership responsibility.
This does not mean directors must become security engineers. It means they should be able to ask and answer practical questions. Which services cannot tolerate disruption? What are the organisation’s highest cyber risks? Who owns each improvement? Which risks have been accepted, by whom and for how long? Could the organisation produce reliable evidence if a regulator, customer or insurer asked tomorrow?
Useful leadership reporting should therefore show more than a red-amber-green dashboard. It should connect material risks to business impact, actions, owners, due dates and supporting evidence. A risk marked as accepted should have a recorded rationale and review date. An overdue action should not disappear because a policy has been approved.
Build an incident reporting process before you need it
NIS2 incident notification rules are among the areas that require careful attention. For significant incidents, the directive sets an early-warning expectation within 24 hours of becoming aware, followed by an incident notification within 72 hours and a final report generally within one month. National rules may add detail, so organisations should confirm the requirements that apply to them.
The difficult part is rarely writing a notification. It is knowing when the reporting clock starts, who can determine whether an event is significant, and how facts will be gathered outside normal working hours.
Create a simple, tested process that defines escalation thresholds, named decision-makers, contacts, fallback contacts and the evidence to retain. Include legal, operational and customer communication considerations. A ransomware event, for example, may involve service disruption, personal data concerns, supplier dependencies and contractual notifications at the same time.
Tabletop exercises are valuable here because they reveal uncertainty without the pressure of a live event. Test a realistic scenario, record what slowed decisions and assign owners to fix the gaps. The exercise itself becomes useful evidence that incident readiness is being managed.
Start with a clear picture, then prioritise
Trying to satisfy every requirement at once leads to a familiar result: a large action list with no meaningful movement. Start by understanding your current position. Identify critical services, the systems and suppliers they depend on, existing controls, available evidence and known gaps.
Then prioritise actions by risk and business impact. Addressing unsupported systems, weak privileged access, missing backups or untested incident escalation will often reduce more risk than rewriting a low-impact policy. The right sequence depends on your environment, threat exposure and service obligations.
Each action needs a named owner, a realistic due date and a clear definition of done. “Improve access control” is not an action that can be verified. “Enforce multi-factor authentication for all administrator accounts, retain configuration evidence and review exceptions monthly” can be assigned, checked and reported.
This is also where framework mapping helps. Many organisations already work with Cyber Essentials, ISO 27001, customer questionnaires or internal security standards. Map overlapping controls once, then identify what NIS2 adds or makes more explicit. Duplicating evidence across separate spreadsheets increases the chance that one version becomes outdated.
Cyber Fundamentals AI can bring assessments, evidence, actions, responsibilities and reporting into a single workspace, helping teams see what needs attention and demonstrate measurable improvement. Its AI guidance can explain findings and suggest priorities, while responsibility for risk decisions stays with people.
Prove progress with current evidence
Evidence is what turns an intention into assurance. Policies matter, but they are only one part of the picture. A current access review, backup restoration test, vulnerability report, supplier assessment, training record or incident exercise outcome can demonstrate that a control operates in practice.
Set an evidence owner and review cadence for each significant control. Automated collection can reduce manual effort, particularly for information held in systems such as Microsoft 365 and Entra ID, but automation is not proof on its own. Someone must still assess exceptions, understand changes and decide what action is required.
Avoid collecting evidence solely because an audit may happen. Use it to make better decisions. If backup evidence shows repeated failures, the valuable outcome is a prioritised remediation action and confirmation that recovery works, not a fuller folder of screenshots.
NIS2 rewards organisations that can show a credible cycle of understanding, improving and proving. Begin with the risks that could most seriously interrupt your services, give each improvement a real owner, and keep the evidence close to the work. That is how compliance becomes a clearer view of resilience rather than another periodic scramble.