1. What NIS2 actually asks of an engineering team
NIS2 is an EU directive on the security of network and information systems. It replaced the original 2016 NIS directive, widened the sectors it covers, and made management personally accountable for the result. The part that matters to whoever runs the infrastructure is short: Article 21 lists ten areas of risk-management measures you must implement, and Article 23 sets the clock for reporting incidents.
Two practical notes before the detail. First, scope reaches further than the sector list suggests: most medium and large organisations in the covered sectors are in, and everyone else gets pulled in through supply-chain clauses, because your customer's obligation becomes your contract. Second, NIS2 is not a certification. There is no NIS2 certificate to hang on the wall. There is a supervisory authority that can ask for evidence, and there is an operational reality that either produces that evidence or does not.
2. Where the deadline really stands
The transposition deadline was 17 October 2024. Member states had to turn the directive into national law by that date, and most of them missed it. The Commission opened infringement proceedings, and by mid-2026 the large majority of countries have transposed and started supervising, while a handful are still finishing the legislative work.
The consequence for planning: this is not a future deadline you can schedule around. In most EU countries the obligation is already live, and the first national fines have landed. If you are waiting for a date, the date has passed.
3. The document engineers should actually read
The directive itself is written for legislators. Two documents translate it into technical language:
- Commission Implementing Regulation (EU) 2024/2690, in force since November 2024. It sets the technical and methodological requirements for a specific set of entities: DNS providers, TLD registries, cloud providers, data centres, CDNs, managed service providers, managed security service providers, online marketplaces and search engines, social platforms and trust service providers. If you are one of those, its Annex is your requirements document, not a summary of one.
- ENISA's technical implementation guidance on cybersecurity risk-management measures, published in 2025, which walks through the same requirements with examples of evidence and tips per control.
Everyone outside the list of nine entity types follows national law, which in practice mirrors the same structure. Reading the implementing regulation is still the fastest way to understand what an auditor will expect.
4. The ten measures, translated into infrastructure work
Here is Article 21(2) as an engineering backlog. The right-hand column is the part teams underestimate: the artifact you have to produce on request.
| Measure | What it means in your infrastructure | Evidence to produce |
|---|---|---|
| Risk analysis and security policy | A written policy that maps to real systems, reviewed when the architecture changes | Policy document with version history and management approval |
| Incident handling | Alerting that reaches a human, triage, root cause, corrective actions tracked to closure | Incident timeline, post-incident review, the pull request that fixed it |
| Business continuity and backups | Backups defined as code, off-site copies, rehearsed restores, agreed recovery objectives | Restore drill records with dates, durations and who ran them |
| Supply chain security | Inventory of providers and dependencies, security terms in contracts, review cadence | Supplier register, SBOM per service, dependency scan results |
| Secure acquisition, development and maintenance | Reviewed changes, tested rollback, patch cadence for images and dependencies | Pull request history, pipeline logs, image scan and patch reports |
| Effectiveness assessment | Measuring whether controls work, not whether they exist | Coverage and drift metrics over time, test results, findings closed |
| Cyber hygiene and training | Baseline practices for everyone with access, including contractors | Training records, onboarding and offboarding checklists |
| Cryptography | Encryption in transit and at rest, key custody and rotation defined | Key management policy, TLS and storage configuration as code |
| Access control and asset management | Least privilege, named identities instead of shared accounts, an asset inventory that matches reality | Role definitions in code, access review records, inventory export |
| Multi-factor authentication and secure communications | MFA on every administrative path, secured internal and emergency channels | Identity provider configuration, MFA coverage report, exception list |
5. The clock: 24 hours, 72 hours, one month
Article 23 turns incident response into a schedule with three checkpoints, and the clock starts when you become aware of a significant incident, not when it began:
- 24 hours: early warning. What happened, whether it looks malicious, whether there is cross-border impact. This is not a forensic report.
- 72 hours: incident notification. An initial assessment of severity and impact, indicators of compromise where you have them.
- One month: final report. Detailed description, likely root cause, mitigations applied, cross-border effects.
Read that as an operational requirement rather than a paperwork one. To hit the first checkpoint you need to know, within hours, which services are affected, what changed recently, and who owns them. Teams that discover incidents from customer emails do not make 24 hours; teams whose alerts carry context and change history do it comfortably.
6. Policy as code is what turns a document into a control
The gap between a written policy and an enforced one is where most programmes fail. Encoding the rules into the delivery path closes it:
- Admission control with OPA Gatekeeper or Kyverno rejects workloads that violate the rules before they run: no privileged containers, no latest tags, required labels and owners, mandatory resource limits.
- Infrastructure as code scanning catches the same classes of problem in the pull request, when fixing them is cheap.
- Drift detection answers the question an auditor eventually asks: does the running system still match the reviewed definition, and how would you know if it stopped.
The by-product is the evidence. A rejected deployment is a dated record that the rule is real. A merged pull request names the person who approved the change. A Kubernetes audit log shows every API action against the cluster. None of that has to be assembled later, because the system produces it while doing its normal work.
7. What auditors actually accept as evidence
Three properties decide whether an artifact counts: it is timestamped, it is attributable to a person or a system, and it is reproducible on request rather than screenshotted once. A screenshot of a dashboard from last March fails all three.
In practice the strongest evidence sets we see are boring: pull request history with reviewers, policy engine denials, backup restore drills with durations, access reviews signed off quarterly, patch reports per image, and incident timelines that link to the fix. Decide the retention period up front, because an auditor asking about last year is the normal case, not the edge case.
8. Five failure modes worth avoiding
- Buying a tool and calling it a programme. A compliance platform tracks controls; it does not implement them. The engineering work stays yours.
- Backups nobody restored. A backup that has never been restored is an assumption, and continuity is one of the ten measures.
- Shared administrative accounts. They quietly break access control, attribution and the evidence chain at the same time.
- Policies that live only in a document. If nothing rejects a violation, the control is a statement of intent.
- Ignoring the supply chain. Your obligations pass down to your providers, and theirs pass to you through contracts.
9. A first ninety days that actually moves
If you are starting from an ordinary production setup rather than from zero:
- Weeks 1-2: scope and inventory. Which entity type applies to you, which services and data are in scope, who owns each system. Most of this exists already, scattered.
- Weeks 3-6: the gaps that carry the most risk. MFA on every administrative path, named identities, secrets out of repositories, backups defined as code with a rehearsed restore.
- Weeks 7-10: enforcement. Admission policies in audit mode first, then enforcing; IaC scanning in the pipeline; alerts routed to an owner with context attached.
- Weeks 11-13: evidence and drill. Automate the collection, agree retention, and run one incident exercise against the 24 and 72 hour checkpoints.
The order matters more than the speed. Enforcement before inventory produces noise; evidence before enforcement produces paperwork.
10. Where we fit, and where we do not
DigitalCare is an engineering partner. We implement the technical controls in your infrastructure as code, keep them enforced and monitored, and make the evidence a by-product of operations rather than a quarterly scramble. Our agents watch posture continuously and remediation ships as pull requests your engineers review and merge, so every change carries an approver and an audit trail.
We do not certify anyone and we do not promise an audit outcome. Certification is issued by your auditor, and the assessment is theirs to make. What we can promise is that when they ask for evidence, the system has been producing it all along. If that is the part you are missing, see Security and Compliance Automation, or send us your current setup and we will tell you where the real gaps are.
This article is engineering guidance, not legal advice. National transposition differs by country, and the applicable requirements depend on your sector, size and entity type.
