NIS2 and DORA for platform teams: what you actually have to build.
Where NIS2 and DORA converge on the platform
NIS2 and DORA are different regulations with different scopes. NIS2 covers critical infrastructure sectors: energy, water, finance, health, digital infrastructure. DORA covers financial entities specifically: banks, insurers, payment processors, and their ICT third-party providers. The overlap for EU platform teams is narrower than the compliance consultancy industry suggests, but the overlapping section is precisely where the platform engineering work lives.
Both regulations require four things from platform teams: the ability to detect and report significant incidents within 24 to 72 hours, a documented dependency map of critical services and their ICT providers, evidence of operational resilience testing, and access control and audit logging sufficient to reconstruct who did what during an incident.
If your platform already runs OpenTelemetry, maintains a service catalogue, runs game days, and logs all control-plane actions to an immutable destination, you are 70 to 80 percent compliant with both regulations' platform-level controls. The missing 20 to 30 percent is mostly documentation structure and retention policy, not new engineering.
The four platform controls you actually need
Control one: incident pipeline. A documented, tested escalation path from alert to response to report. The pipeline must satisfy the 72-hour notification threshold of NIS2 Article 23 and the 4-hour initial notification of DORA Article 19. If your current on-call runbook does not include a regulatory notification step, add one. The alert fires, the on-call responds, the response is logged to your immutable audit trail, and the notification to the national competent authority or regulator triggers from the same workflow. No separate compliance process needed.
Control two: dependency register. A machine-readable map of your critical services, the ICT providers they depend on, and the contractual status of those relationships. DORA Article 28 requires a register of ICT third-party service providers. NIS2 Article 21 requires supply chain security measures. The register is a YAML file in your platform repo: provider name, service function, criticality classification, contract reference, exit plan reference. Updated via PR, audited quarterly. The auditor reads the YAML directly.
Control three: resilience testing. Both regulations require evidence that you have tested recovery from disruption. The platform contribution is a game day programme: scheduled quarterly per critical service, scenario-driven, output logged to a structured record. Running game days as code means the evidence is generated automatically as a byproduct of normal operations. The game day log is the compliance evidence.
Control four: audit logging and access control. CloudTrail, Azure Monitor, or the equivalent must capture all control-plane actions with immutable retention of at least 3 years for DORA. All human access to production must flow through a federated identity provider with time-limited credentials. No shared passwords, no long-lived access keys. The access control model must be reviewable: who has access to what, when they last used it.
Where NIS2 and DORA diverge on the platform
DORA imposes stricter requirements on ICT provider relationships than NIS2. DORA Article 30 requires contractual provisions in every ICT third-party agreement covering audit access rights, incident support obligations, and exit assistance. If your infrastructure uses a managed service from a provider who will not agree to these terms, DORA compliance requires you to migrate or negotiate. This is a commercial and legal matter, but the platform team needs to know which providers are in scope.
NIS2 imposes sector-specific controls that DORA does not. If your organisation operates critical infrastructure services, NIS2 Article 21 requires supply chain security that extends to assessing the security practices of your software vendors and suppliers, not just your ICT service providers.
For mid-market companies building cloud platforms for financial services: DORA's ICT risk framework is the more prescriptive standard. For mid-market companies in healthcare, energy, or public sector: NIS2 is the more demanding one. The four platform controls above satisfy both at the overlap. The divergent requirements are best handled with legal counsel alongside the platform work.
"If your platform runs OpenTelemetry, maintains a service catalogue, runs game days, and logs control-plane actions, you are 70 to 80 percent compliant with NIS2 and DORA's platform controls."
Maikel Vlasman / Cloud Architect
The 90-day implementation sequence
Weeks 1 to 4: audit what you have. Map your current monitoring and alerting against the incident pipeline requirements. List your critical ICT dependencies against the dependency register requirements. Identify the gaps. Most teams find the monitoring is adequate and the logging exists, but the documentation is missing or stale.
Weeks 5 to 8: build the missing controls. This usually means adding the regulatory notification step to the on-call runbook, writing the dependency register YAML and committing it to the platform repo, and scheduling the first game day if none has happened in the past 90 days.
Weeks 9 to 12: generate and retain the evidence. Run the first game day. Export the dependency register. Export the audit log retention configuration. This is the evidence pack: a directory in the platform repo with a README that maps each artefact to the specific article and paragraph it satisfies.
Week 12 onwards: maintain the cadence. Quarterly game days. Quarterly dependency register review. Annual access control audit. The evidence regenerates itself from the platform. Compliance becomes a byproduct of running the platform correctly, not a separate annual project.