DORA & NIS2 Are Detection-Engineering Problems, Not Paperwork
There is a cottage industry of DORA and NIS2 content that treats these regulations as a documentation exercise — gap assessments, policy templates, a RACI matrix, a binder for the auditor. That content is not wrong, but it misses where the real work is. For a security team that already runs a SOC, most of what DORA and NIS2 demand is detection-engineering work you are either already doing or already able to do. The compliance layer is a translation problem, not a new discipline.
This post maps the requirements that actually bite onto the controls, telemetry, and evidence a working security function produces. It is written from the seat of someone who has to operate the SIEM and answer to the regulation, in the Luxembourg financial sector specifically.
The reframe
DORA (Digital Operational Resilience Act) and NIS2 are often read as “we need more documents.” Read them instead as a set of operational capabilities the regulator wants evidence of. Almost every one of those capabilities is something a detection engineer recognises:
- Can you detect an ICT incident? → detection coverage
- Can you classify its severity quickly and consistently? → incident triage and severity criteria
- Can you report it inside the mandated window? → incident response runbook + evidence trail
- Can you show your controls work, not just that they exist? → detection validation / purple teaming
- Can you demonstrate this for your critical third parties too? → supply-chain monitoring
None of that is paperwork. All of it produces paperwork as a byproduct if your SOC is built right.
DORA’s incident reporting clock is a SIEM requirement
DORA’s incident-reporting timeline is the requirement that exposes whether your detection is real. You have a window to submit an initial notification of a major ICT-related incident, with intermediate and final reports to follow. Meeting that window is not a writing problem — it is a detection-and-classification latency problem.
To report inside the window you must, in order and fast:
- Detect the incident — coverage and alerting.
- Classify it against the severity thresholds — consistent, pre-agreed criteria, not a judgment call made under pressure.
- Assemble the evidence — timeline, scope, affected services — from data you already retain.
If your detection is signature-thin, step 1 is slow. If your severity criteria live in someone’s head, step 2 is inconsistent and indefensible. If your retention and correlation are weak, step 3 is a fire drill. The clock turns three SOC weaknesses into three compliance failures.
The detection-engineering move: pre-build the classification logic as detection content. The DORA severity thresholds (clients affected, data losses, duration, geographic spread, economic impact) can be partially mapped to fields you already enrich. The closer your alerts already carry that context, the faster classification becomes — and the more defensible, because the criteria are codified rather than improvised.
NIS2 widens scope; the controls are familiar
NIS2 broadens which entities are in scope and raises the bar on governance and incident handling, with management accountability that has teeth. For a security team, the substantive demands — risk management measures, incident handling, business continuity, supply-chain security — are the standard control families. The shift that matters operationally is the accountability and evidence expectation: you must be able to show the controls function.
This is where detection-as-code and validation become compliance assets rather than nice-to-haves. A detection you can version-control, test, and demonstrate firing on a known technique is evidence. “We have an EDR” is a statement; “here is the detection, here is its last validation run against the technique it covers, here is the alert it produced” is proof. NIS2’s accountability posture rewards the second.
The mapping
| Regulatory demand | What it actually is | Evidence your SOC already produces |
|---|---|---|
| Detect ICT incidents | Detection coverage | Alert catalogue, coverage map vs. ATT&CK |
| Report within the window | Detection + classification latency | Triage runbook, enriched alerts, retention |
| Severity classification | Codified criteria | Severity logic as detection content / fields |
| Demonstrate controls work | Detection validation | Purple-team runs, detection-as-code history |
| Incident handling | IR process | Runbooks, case records, timelines |
| Supply-chain / third-party risk | External monitoring | Third-party telemetry, attack-surface recon |
| Business continuity / resilience testing | Resilience exercises | Tabletop records, recovery validation |
| Governance & accountability | Ownership + evidence trail | Versioned controls, sign-off records |
Read the table in one direction it is a compliance checklist. Read it the other direction it is a SOC maturity model. They are the same table.
Where the genuine extra work is
Honesty matters more than selling here, so: not everything collapses neatly into existing SOC work. Three areas are genuinely additional.
Third-party / ICT concentration risk. DORA’s focus on critical third-party providers pushes monitoring outside your perimeter — attack-surface management, abuse monitoring, and contractual evidence for providers you do not control. This is new telemetry to acquire, not existing telemetry to relabel.
The classification thresholds are specific and external. You do not get to invent your severity criteria; they are defined for you. Mapping your internal alert context to the regulator’s thresholds is real translation work, and getting it wrong cuts both ways — over-report and you flood the regulator and yourself; under-report and you are in breach.
Evidence retention with a compliance lifetime. Detection data retained for operational need and detection data retained as regulatory evidence are not the same retention policy. The compliance lifetime is often longer and the integrity requirements stricter.
The practical takeaway
If you run a SOC and you are facing DORA or NIS2, do not start with the document binder. Start with three questions, all of which are detection-engineering questions:
- What is my detection coverage, expressed against a framework I can show an auditor (ATT&CK is the lingua franca)?
- Is my severity classification codified — in detection content and enriched fields — rather than improvised under the reporting clock?
- Can I demonstrate my controls fire, with validation evidence, not just assert they exist?
Answer those three well and the binder mostly writes itself, because the evidence is a byproduct of doing the security work properly. Answer them poorly and no amount of policy documentation will survive contact with an actual incident under a reporting deadline.
The regulation is not asking you to become a compliance function. It is asking you to be a good SOC that can prove it. Those are the same thing.
An independent piece by johlem.net — IT security consulting, Luxembourg. DORA/NIS2 readiness for regulated financial entities.