NIS2 does not prescribe a specific framework or cloud stack. It requires essential and important entities to manage cybersecurity risk, report significant incidents, secure suppliers, maintain continuity, handle vulnerabilities, and give management bodies real approval and oversight responsibilities. Engineering must turn those duties into controls that run every day.
NIS2 covers 18 critical sectors and distinguishes essential and important entities, generally using sector, entity type, and size thresholds while including some entities regardless of size. Scope, registration details, competent authority, supervision, sanctions, and reporting channels depend on national transposition. Build a jurisdiction register and validate it with counsel instead of assuming one EU-wide onboarding form.
Article 20 requires management bodies to approve cybersecurity risk-management measures, oversee implementation, and receive training; national law can hold them liable for infringements. Engineering evidence therefore needs an executive path: risks, exceptions, overdue remediation, incident readiness, supplier concentration, exercise outcomes, and control effectiveness must be understandable and approved at the right level.
| NIS2 measure | Backend/platform requirement | Evidence | Operational signal | Release or risk gate |
|---|---|---|---|---|
| Risk analysis and system security policies | Service catalog, asset/dependency graph, threat model, risk owner, classification, control mapping, residual-risk workflow, and annual/change-triggered review. | Approved risk record, architecture and exception history. | Unowned asset, new exposure, expired review, control drift. | No critical service without owner and accepted risk. |
| Incident handling | Detection rules, case schema, severity model, evidence preservation, communications, escalation, legal clock, playbooks, and CSIRT contacts. | Exercises, alert-to-case traces, timeline and report templates. | MTTD, triage delay, missing logs, reporting deadline risk. | No production launch without tested response path. |
| Business continuity, backup, disaster recovery and crisis management | RTO/RPO per service, immutable/isolated backups, restore automation, failover, emergency communication, manual fallback, and crisis roles. | Restore/failover tests and unresolved gaps. | Backup failure, replication lag, capacity or dependency loss. | Critical recovery objectives must pass tests. |
| Supply-chain security | Supplier registry, criticality, due diligence, contract controls, access boundary, SBOM/model BOM, provenance, change notices, concentration, and exit plan. | Assessments, contracts, attestations and dependency inventory. | New subprocessor, compromised package, vendor outage, unsupported version. | Block unapproved critical supplier/dependency. |
| Secure acquisition, development and maintenance; vulnerability handling | Secure SDLC, code review, SAST/DAST/SCA, secrets scanning, patch SLAs, coordinated disclosure, CVE triage, signed artifacts, and emergency change process. | Pipeline reports, remediation tickets, signatures and exceptions. | Exploitability, age, internet exposure, active exploitation, failed patch. | Risk-based vulnerability gate with accountable exception. |
| Effectiveness assessment | Control tests, purple-team exercises, detection validation, restore tests, access sampling, supplier exercises, and metrics tied to risk reduction. | Test results, failures, remediation and retest. | Coverage loss, repeat failure, ineffective control. | Evidence freshness and minimum success thresholds. |
| Cyber hygiene and training | Role-based training for developers, operators, incident teams and management; phishing-resistant practices; secure defaults and checklists. | Completion, scenarios, competency and exercise results. | Repeated risky action or missing trained coverage. | Privileged roles require current training. |
| Cryptography and encryption | Data classification, approved algorithms/protocols, key ownership, KMS/HSM, rotation, certificate inventory, backup, revocation, and migration. | Crypto policy, key/certificate inventory and rotation logs. | Expiry, weak protocol, unmanaged key, decrypt failure. | Reject noncompliant transport/storage configuration. |
| HR security, access control and asset management | Joiner/mover/leaver, least privilege, PAM, periodic review, service identities, ownership, device posture, asset lifecycle, and logging. | Approvals, access reviews, revocations and inventory reconciliation. | Orphan account, excessive privilege, unknown asset. | No privileged access without owner, MFA and expiry. |
| MFA, secured communications and emergency communications | Phishing-resistant MFA for critical access, conditional access, protected admin paths, secure voice/text alternatives, and break-glass controls. | MFA coverage, access policy and emergency-channel exercise. | MFA bypass, risky login, communication outage. | Block critical access outside approved assurance. |
Article 23 uses a staged process for significant incidents: an early warning within 24 hours of awareness, an incident notification within 72 hours, intermediate reporting when requested, and a final report no later than one month after the incident notification. National transposition and sector rules determine the authority, format, and additional requirements. The system must preserve the exact awareness timestamp and distinguish observed facts, current assessment, uncertainty, and later corrections.
Do not let every engineering team invent its own reporting threshold. Create a jurisdiction- and sector-aware rules service using service disruption, users affected, duration, geography, financial/material damage, data and system compromise, cross-border impact, recurrence, and implementing-regulation criteria where applicable. The rules produce a recommendation; an authorised incident lead and legal/compliance owner make and record the determination.
Responders need permission to contain quickly without destroying the record. Use synchronized clocks, immutable security logs, snapshots, forensic collection, chain of custody, case timelines, decision logs, report versions, and access controls. The production fix, customer communication, regulator report, and later root-cause analysis should all reference the same incident ID.
A vendor questionnaire is insufficient. Know which critical service uses which package, container, cloud service, MSP account, CI action, firmware, model, and data provider. Capture version, provenance, maintainer/vendor, support status, privileges, data access, network reach, substitution options, and concentration. Signed artifacts and SBOMs help, but teams still need exploitability, deployment, ownership, and response workflows.
Combine external disclosure, bug bounty, scanners, vendor advisories, CISA KEV or equivalent intelligence, exploitability, asset exposure, business criticality, compensating controls, patch availability, maintenance windows, and verification. A CVSS-only queue is not risk management. Track discovery, acknowledgement, triage, owner, due date, exception, fix, rollout, retest, disclosure coordination, and recurrence.
Backups do not prove continuity. Test identity-provider loss, DNS failure, cloud-region outage, compromised CI/CD, unavailable MSP, ransomware, inaccessible office, communication outage, and simultaneous supplier failure. Maintain offline contact lists, emergency communication, manual service procedures, clean-room recovery, minimum staffing, known-good artifacts, and a path to operate without the primary control plane.
Collect control evidence through APIs and events: repository protection, branch reviews, artifact signatures, cloud configurations, MFA/PAM coverage, endpoint posture, vulnerability state, backup tests, restore results, supplier status, incident exercises, and training. Every item needs scope, source, observation time, collector version, owner, result, expiry, exception, and remediation link. Screenshots are a fallback, not a scalable evidence model.
Commission Implementing Regulation (EU) 2024/2690 defines technical and methodological requirements and significance criteria for DNS providers, TLD registries, cloud providers, data-centre providers, CDN providers, managed service and managed security service providers, online marketplaces, search engines, social networking platforms, and trust service providers. ENISA's 2025 guidance adds implementation advice, evidence examples, and mappings. Other sectors still need to follow the Directive and relevant national law.
Member States had until October 17, 2024 to transpose NIS2, but implementation has progressed unevenly. Maintain country modules for scope, registration, competent authority, incident channels, language, format, sanctions, retention, sector-specific rules, and deadlines. Do not hard-code one country's portal or assume the Directive alone is the complete operational rulebook.
An entity/jurisdiction registry; critical-service and dependency graph; risk/control catalog; policy-as-code gates; supplier and software inventory; vulnerability lifecycle; identity/asset evidence collectors; backup/restore test service; incident case and legal-clock engine; significance rules; regulator/CSIRT contact registry; report generator with version history; crisis communication service; management dashboard and approvals; exercise scheduler; and control-effectiveness analytics.
NIS2 becomes actionable when every obligation maps to an owner, system control, runtime signal, test, evidence record, deadline, and management decision. Compliance documents should be outputs of a resilient security program, not substitutes for one.
Legal note: this is an engineering interpretation, not legal advice. Verify the national transposition, competent authority guidance, sector rules, and facts of each entity and incident.
Article about NIS2 backend requirements, governance, risk management, incident reporting, continuity, supply-chain security, vulnerability management, access control, evidence, and management accountability.