Skip to content
Back to the Handbook
Executive briefing, 2026 editionFree PDF

DORA and NIS2: The Strategic IT Roadmap

A field guide that maps ICT risk, third-party concentration, incident reporting and resilience testing to a 90/180/365-day operating plan.

Free. No account, no email and no checkout. You may share the PDF unchanged.

29
pages
12
chapters
3
named sources
Cover of DORA and NIS2: The Strategic IT Roadmap. It lists 12 chapters, from The Regulatory Reality to The 90 / 180 / 365-Day Roadmap.

PDF field guide

Reviewed 18 July 2026 · PDF edition

About this guide

Who it is for and what it covers

DORA and NIS2 move ICT resilience from a technical concern to a management-board responsibility. The question a regulator asks is no longer "do you have a policy" but "can you prove the control runs, who owns it, and how fast you recover".

This briefing maps the obligations to decisions an executive actually makes: scope, framework, incident reporting timelines, resilience testing, third-party concentration and an evidence system that survives an audit.

The output is a sequenced plan with owners and dates, in the language each reviewer expects.

Inside the PDF

What comes with the PDF

  • 12-chapter executive roadmap across DORA and NIS2.

  • Article-to-reality matrix mapping obligations to operational work.

  • Incident reporting timeline aid (DORA major-incident path; NIS2 24h / 72h / 1 month).

  • ICT third-party register and exit-strategy starter structure.

  • Board briefing and accountability pack outline.

  • 90 / 180 / 365-day prioritised roadmap with a decision matrix.

Sample page

One chapter as it appears in the PDF

Previewed chapter: The ICT Risk Management Framework

DORA wants one coherent framework, not a folder of disconnected controls.

DORA Art. 5-15ISO/IEC 27001:2022NIS2 Art. 21(2)(a)

DORA and NIS2: The Strategic IT Roadmapitsailor.io

Chapter 3

The ICT Risk Management Framework

DORA wants one coherent framework, not a folder of disconnected controls.

  • DORA Art. 5-15
  • ISO/IEC 27001:2022
  • NIS2 Art. 21(2)(a)

DORA Articles 5 to 15 require a documented ICT risk management framework with real governance behind it. It is built on familiar pillars: identify your important business functions and the ICT assets behind them; protect them; detect anomalies; respond and recover; and learn from incidents and tests. The difference from a generic ISO programme is the supervisory expectation that the framework is owned at management-body level and demonstrably operates.

Start with the dependency map, not the control list. You cannot protect what you have not connected to a business outcome. For each important function, record the systems, data, identities and third parties it relies on, and the maximum tolerable disruption. That single artefact drives recovery objectives, testing priorities and third-party scrutiny for the rest of the programme.

Table of contents

Contents

  1. DORA (Regulation (EU) 2022/2554)NIS2 (Directive (EU) 2022/2555)

    The Regulatory Reality

    DORA and NIS2 turn ICT resilience into management accountability, not a technical side project.

    What the chapter asks you to keep

    • A one-page scope statement: which entity, which framework(s), which competent authority.
    • A named executive owner for the resilience programme.
    • A decision log that records why each obligation applies or does not.
  2. DORA Art. 2NIS2 Art. 2-3, Annexes I-II

    Are You In Scope?

    Scope is the first and most expensive mistake. Get it wrong and you either over-build or sit exposed.

    What the chapter asks you to keep

    • Scope determination memo with legal references per entity.
    • Registration confirmation with the relevant national authority where required.
    • Reassessment trigger list (new product, new entity, new Member State).
  3. DORA Art. 5-15ISO/IEC 27001:2022

    The ICT Risk Management Framework

    DORA wants one coherent framework, not a folder of disconnected controls.

    What the chapter asks you to keep

    • Board-approved ICT risk framework with version history.
    • Dependency map signed off by business and ICT owners.
    • RTO/RPO table derived from a business impact analysis, not a guess.
  4. DORA Art. 17-19NIS2 Art. 23

    Incident Management and the Reporting Clock

    When an incident hits, the timeline is unforgiving. The runbook has to exist before, not during.

    What the chapter asks you to keep

    • Incident classification policy with worked examples.
    • Tabletop exercise report against the reporting timelines.
    • A reporting log template capturing each deadline and who met it.
  5. DORA Art. 24-27NIS2 Art. 21(2)(f)

    Proving It: Digital Operational Resilience Testing

    Resilience you have not tested is a claim. DORA wants the claim proven on a schedule.

    What the chapter asks you to keep

    • Annual testing plan approved by the risk owner.
    • Restore and failover test reports with measured times.
    • Remediation tracker showing findings closed and retested.
  6. DORA Art. 28-30NIS2 Art. 21(2)(d)

    Third-Party and Concentration Risk

    Your resilience is only as strong as the provider you cannot see and cannot leave.

    What the chapter asks you to keep

    • ICT third-party register with criticality flags.
    • Board-level concentration risk summary.
    • Exit-strategy documents and the date each was last tested.
  7. NIS2 Art. 21(2)(a)-(j)

    The NIS2 Risk-Management Measures

    NIS2 Article 21 is a baseline of ten measures. Treat it as the floor, evidenced, not aspired to.

    What the chapter asks you to keep

    • Article 21 coverage matrix with evidence links.
    • Cryptography and access-control policies in force.
    • Supply-chain security documentation cross-referenced to Chapter 6.
  8. NIS2 Art. 20DORA Art. 5

    Governance and Board Accountability

    NIS2 makes management personally answerable. The board cannot delegate the obligation, only the work.

    What the chapter asks you to keep

    • Management-body approval and review minutes.
    • Training completion records for directors and senior management.
    • Decision log for risk acceptance and major ICT investments.
  9. DORA Art. 6, 13NIS2 Art. 21(2)(f)

    Building the Evidence System

    The programme is judged on what you can show, not what you intended. Engineer the evidence, not just the control.

    What the chapter asks you to keep

    • Evidence index covering every in-scope obligation.
    • Refresh schedule with owners.
    • A mock audit walkthrough that tests the index end to end.
  10. DORA Art. 28-30NIS2 Art. 21(2)(d)

    Build, Buy or Outsource

    Most resilience gaps are sourcing decisions made by default. Decide them on purpose, with the regulator in the room.

    What the chapter asks you to keep

    • Sourcing decision log mapped to important functions.
    • Exit and transferability assessment for each critical supplier.
    • Concentration summary that survives a board question.
  11. NIS2 Art. 20DORA Art. 5

    The Board Briefing Pack

    The board cannot govern what it cannot see in ten minutes. Build the pack that makes oversight real and recorded.

    What the chapter asks you to keep

    • The current board pack plus the last four, to show the trend.
    • Minutes recording the decisions taken on each.
    • A distribution and confidentiality note for the pack.
  12. DORA Art. 5-30NIS2 Art. 20-23

    The 90 / 180 / 365-Day Roadmap

    Sequence beats effort. Bank the high-impact, low-effort controls first, then build the structural ones.

    What the chapter asks you to keep

    • A signed-off 90 / 180 / 365-day plan with owners.
    • A board-approved budget mapped to the roadmap.
    • A first-quarter status review proving the plan moved.

What this guide is not

Strategic and technical guidance only, not legal advice. DORA is a directly applicable EU Regulation; NIS2 is a Directive transposed into national law, so detail varies by Member State. Confirm scope and obligations with qualified counsel before relying on this roadmap for a regulatory submission.

Written and maintained by

Michal Jatczak

ITSailor is the trading name. The legal publisher is Michal Jatczak, Malta VAT registered.

About the publisher
In your own tenant

The Microsoft 365 side, in your own tenant

Use the guide to brief the board and sequence the work. The Architecture & Security Design Workshop covers the Microsoft 365 and Azure side of that plan in your own tenant.

See the workshop
The companion field guide

Tenant Hardening for Microsoft 365

A field guide for EU teams on Microsoft 365: DORA Article 9, NIS2 Article 21 and NIST CSF 2.0 mapped to tenant controls, evidence and routines.

See the companion guide