Regulations state outcomes, not products. Designing from a shopping list of tools risks buying things that miss the mandate. So we work the other way: we take each requirement of NIS2 and DORA and map it to the design property that satisfies it. Follow that mandate → principle chain and the architecture is compliant by construction — and any conformant technology can satisfy it.
This framework deliberately names no technology. It stays at the level of what the law requires and what design property answers it. The concrete tools are mapped per product elsewhere; this is the upstream artefact that drives every solution design and every audit gap-analysis.
Are you in scope, what NIS2 actually requires, and how to meet it on open-source you host yourself — with a 90-day starting path. Just your work email.
Trust zones separated at L2/L3, default-deny between zones, blast-radius containment.
Access by role/need; management plane isolated from user and data planes.
Multi-factor / phishing-resistant auth for privileged and remote access.
Encrypted links and stored data; managed keys/certs; no plaintext control channels.
Critical paths duplicated; graceful degradation; defined RTO/RPO.
Immutable, offsite copies; recovery proven by test, not assumed.
Centralised, time-correlated logs; alert thresholds; monitored egress/ingress.
Reviewed, versioned, reversible changes; reproducible state.
Continuous discovery; scheduled, evidenced remediation; coordinated disclosure.
Authoritative register of assets, addresses and dependencies.
Vetted suppliers/software; provenance and update integrity.
Periodic failover/DR and — where in scope — threat-led penetration testing.
Detect → classify → respond → report within regulatory timelines; evidence retained.
Security built into acquisition, development, maintenance and decommissioning.
Baseline hygiene, RBAC discipline, awareness/training as a design assumption.
Article 21(2) risk-management measures "shall include at least" the following. Art. 23 governs incident reporting.
| NIS2 mandate | Requirement (abridged) | Principles |
|---|---|---|
| 21(2)(a) | Policies on risk analysis & information system security | DP-10, DP-8, DP-14 |
| 21(2)(b) | Incident handling | DP-7, DP-13 |
| 21(2)(c) | Business continuity — backup, disaster recovery, crisis management | DP-5, DP-6, DP-12 |
| 21(2)(d) | Supply chain security (direct suppliers/providers) | DP-11 |
| 21(2)(e) | Security in acquisition, development & maintenance; vulnerability handling & disclosure | DP-9, DP-14 |
| 21(2)(f) | Assessing effectiveness of risk-management measures | DP-12, DP-8 |
| 21(2)(g) | Basic cyber hygiene & training | DP-15 |
| 21(2)(h) | Cryptography and, where appropriate, encryption | DP-4 |
| 21(2)(i) | HR security, access control, asset management | DP-2, DP-10, DP-15 |
| 21(2)(j) | MFA / continuous authentication, secured comms | DP-3, DP-4 |
| Art. 23 | Incident reporting to CSIRT (early warning ≤24 h / notification ≤72 h) | DP-13, DP-7 |
| DORA mandate | Requirement (abridged) | Principles |
|---|---|---|
| Art. 8 — Identification | Identify ICT assets, functions & dependencies | DP-10 |
| Art. 9 — Protection & prevention | Segregation, access control, encryption, resilient design | DP-1, DP-2, DP-3, DP-4 |
| Art. 10 — Detection | Multi-layer detection; alert thresholds | DP-7 |
| Art. 11 — Response & recovery | ICT continuity; respond & recover to targets | DP-5, DP-13 |
| Art. 12 — Backup & restoration | Backup policies; restoration methods; separated copies | DP-6 |
| Art. 13 — Learning & evolving | Post-incident learning; continuous improvement | DP-12, DP-8 |
| Art. 17–23 — Incident mgmt (Ch. III) | Classify & report major ICT incidents | DP-13, DP-7 |
| Art. 24–27 — Resilience testing (Ch. IV) | Test programme; threat-led penetration testing (TLPT) | DP-12 |
| Art. 28–44 — Third-party risk (Ch. V) | Contractual, concentration & oversight controls on providers | DP-11 |
Every high- and low-level design is checked against DP-1…DP-15. A design that cannot demonstrate a principle records a residual risk — nothing is waved through.
Each principle is translated into concrete controls and evidence per product — the technology layer this framework intentionally leaves out.
Gap analysis scores your current state against the same principles, so every finding ties straight back to a regulatory mandate.
Acceptance and sandbox tests demonstrate the redundancy, backup, detection and resilience principles (DP-5/6/7/12) with evidence — proven, not assumed.
Sources (authoritative). NIS2 = Directive (EU) 2022/2555, esp. Art. 21(2)(a)–(j) and Art. 23 — EUR-Lex 32022L2555. DORA = Regulation (EU) 2022/2554, esp. Ch. II Art. 8–13, Ch. III Art. 17–23, Ch. IV Art. 24–27, Ch. V Art. 28–44 — EUR-Lex 32022R2554.
Copyright © XpertOne Security Consulting GmbH. All Rights Reserved. | Impressum | Datenschutz