MICKAI®ArticlesNIS2 and the documentation burden…
Article · 31 July 2026

NIS2 and the documentation burden on critical infrastructure

NIS2 obliges essential and important entities to document cyber risk management, supply chain security and incident handling, and to prove it on demand, with management personally accountable.

Author
Micky Irons
Published
31 July 2026
Follow Micky Irons
LinkedInX
nis2critical-infrastructuresovereign-aicyber-risk-managementcompliance-documentation
NIS2 and the documentation burden on critical infrastructure

NIS2 requires essential and important entities across the European Union to document how they manage cyber risk, secure their supply chains and handle incidents, and to produce that documentation whenever a regulator asks for it. The directive, which member states were required to transpose into national law by 17 October 2024, turns cyber security from a technical practice into an evidence discipline, and it makes management personally accountable for the result.

For operators of energy grids, water networks and transport systems, this is not a marginal change. The NIS2 framework reaches further than the original NIS directive, and the documents it demands (network architectures, risk registers, supplier assessments, incident timelines) are among the most sensitive papers an operator holds. How you review them, and what you can prove about that review, now matters as much as what they contain.

What does NIS2 actually require us to document?

NIS2 requires documented cyber risk management measures that cover the whole of your operations on an all hazards basis, not a single annual policy. Article 21 of the directive sets out the measures every essential and important entity must take and must be able to evidence. In practice, the documentation programme includes:

  • Risk analysis and information system security policies, kept current as the estate changes
  • Incident handling procedures and the records of every incident worked under them
  • Business continuity plans, backup management and crisis response documentation
  • Supply chain security assessments covering direct suppliers and service providers
  • Policies on cryptography, access control and asset management, plus evidence that the measures themselves are effective

None of this is static. Supervision of essential entities is proactive, so regulators can inspect without waiting for an incident. A policy that was accurate in January and wrong by June is not evidence of compliance, it is evidence of drift.

Why is management personally accountable under NIS2?

Because the directive says so explicitly. Article 20 requires management bodies to approve the cyber risk management measures and oversee their implementation, and it allows member states to hold managers liable for infringements. Board members must also undergo training so they can genuinely assess the risks they are signing off. NIS2 treats a cyber security failure as a governance failure, not an IT failure. For a board, the question is no longer whether the security team has a policy. It is whether the organisation can prove, on paper, that the policy was implemented, reviewed and kept current.

Why can we not put NIS2 documentation through a cloud AI service?

Because the documents NIS2 obliges you to hold are exactly the documents you can least afford to expose. Network diagrams, incident records and supplier assessments describe how your infrastructure works and where it is weakest. Sending them to a third party cloud AI service creates a new supply chain dependency, and a new disclosure surface, of precisely the kind Article 21 requires you to assess and control. An operator that uploads its incident records to an external service has extended its trust boundary to that provider's staff, subprocessors and jurisdictions. For most critical infrastructure operators that trade is not defensible.

How does sovereign on premise review change the evidence problem?

It lets you apply modern AI to the documentation workload without a single document leaving the building. Our platform runs entirely on hardware the operator owns, on premise and air gapped, so review of risk registers, supplier files and incident records happens inside the existing security boundary. It reads document packages, cross references them against the records behind them, drafts the paperwork a regulator will ask for, and holds anomalies for a person to decide. Consequential actions wait for a person's clearance, and every disposition is sealed to the Open Audit Record before the action runs, producing a cryptographically signed, tamper evident record that can be verified offline years later.

NIS2 asks operators to prove what they did and when they did it. A record written after the fact is a recollection. A record sealed before the action runs is evidence.

Mickai

How do incident reporting deadlines change the documentation burden?

They compress it to hours. Under Article 23, entities must issue an early warning within 24 hours of becoming aware of a significant incident, a fuller notification within 72 hours, and a final report within a month. Meeting those deadlines depends on how fast the underlying evidence can be assembled: what was affected, what was done, who decided what and when. If that record lives in ticket systems, mailboxes and memories, the 72 hour notification becomes a scramble. If every action was sealed as it happened, the notification is largely a query against a record that can be shown to be intact.

Enforcement under NIS2 is still maturing, and national regulators are building their supervisory practice sector by sector. The direction is already clear. Documentation obligations for critical infrastructure are growing, inspection is becoming proactive, and accountability now reaches the boardroom. Operators who treat the evidence trail as an afterthought will keep paying for it in scrambles and findings. Operators who run review on their own hardware, with a sealed record of every action, will find that the evidence largely assembles itself. We built for the second group.

Frequently asked questions

What is NIS2 and when did it take effect?

NIS2 is the EU's second Network and Information Security Directive, successor to the 2016 NIS directive. Member states were required to transpose it into national law by 17 October 2024. It sets cyber risk management, incident reporting and supervision duties for essential and important entities across sectors including energy, transport, water, health and digital infrastructure.

Which organisations count as essential or important entities?

Essential entities include operators in sectors such as energy, transport, drinking water, waste water, health, banking and digital infrastructure, generally above size thresholds. Important entities cover sectors such as postal services, waste management, chemicals, food and manufacturing. Both carry the same risk management duties; the differences are supervision intensity and maximum penalties.

Can we use cloud AI tools on NIS2 documentation?

You can, but you take on a supply chain and disclosure risk that the directive itself obliges you to assess, because passing your most sensitive operational documents through a third party service extends your trust boundary to that provider. Many operators conclude that the defensible route is to keep AI review inside their own estate, on hardware they control.

What are the penalties for falling short of NIS2?

Member states must provide for fines of up to 10 million euros or 2 per cent of worldwide annual turnover for essential entities, and up to 7 million euros or 1.4 per cent for important entities, whichever is higher in each case. Regulators can also issue binding instructions and order audits, and for essential entities member states can go further, including temporary suspension of authorisations and restrictions on managers.

How does Mickai help with NIS2 without becoming a third party risk itself?

Mickai runs entirely on the customer's own hardware, on premise and air gapped, so no document, prompt or output ever leaves the operator's estate, and there is no external service to add to a supplier register. Reviews are sealed to the Open Audit Record before actions run, so the system produces regulator ready evidence instead of consuming trust.

What is MICKAI?

MICKAI is a Sovereign Intelligence Operating System, a SIOS that runs on the customer's own hardware, on premise and air gapped, with no cloud dependency. Every consequential action is sealed to the Open Audit Record, a cryptographically signed, post quantum, tamper evident record that is verifiable offline and sealed before the action runs. The system comprises 87 studios, with ten production ready at launch and 77 in development, and it is protected by 104 filed UK patent applications across 2,340 claims, filed rather than granted, owned by Mickai LTD.

Subscribe
Get every new Mickai article by email.

Long-form essays on sovereign AI from Micky Irons. One email per article. No tracking, no marketing, no third parties. Every email includes a one-click unsubscribe link.

Prefer RSS? Subscribe at /articles/feed.xml.

Originally published at https://mickai.co.uk/articles/nis2-critical-infrastructure-documentation. If you operate in a regulated sector or want sovereign AI on your own hardware, the audit form on mickai.co.uk is the entry point.
More articles