NIS2, DORA and the AI Act: One Control Set, Three Regulators, One Evidence Problem

On August 2, 2026 a chunk of the EU AI Act went live, another chunk quietly slid eighteen months into the future, and most compliance teams are now working from a mental model that is wrong on both counts. The transparency obligations came due. The heavy high-risk regime did not. And underneath that reshuffle sits a problem that has nothing to do with AI specifically: a European operator of any size now answers to NIS2, DORA and the AI Act at the same time, and all three want to see roughly the same evidence about roughly the same controls — measured, tested, logged, and dated.

The instinct is to run three programmes. That is how you end up paying for three audits of one network. This article is about what actually changed on August 2, why the three regimes converge on a single control set, and why the thing that trips organisations up is never the rule text — it is proving, on the day an auditor asks, that the control was working.

What actually came due on August 2

Two things happened, and they pull in opposite directions.

First, the Article 50 transparency obligations took effect. Deployers and providers of generative and interactive AI now have to disclose when a person is dealing with a machine, and mark AI-generated or manipulated content (synthetic audio, image, video, text) as artificial. These are live now, enforceable now, and carry real penalties.

Second — and this is the part most summaries get backwards — the high-risk obligations under Annex III were deferred. The Digital Omnibus, now Regulation (EU) 2026/1744, was signed on July 8 and entered into force on July 27, 2026. It pushes the compliance date for Annex III high-risk systems — biometrics, employment and worker management, credit scoring, education, and critical-infrastructure safety components — from August 2, 2026 to December 2, 2027.

"We're covered until December 2027" — the sentence a room full of legal and security leads talked themselves into last month, right before someone asked who owned the chatbot disclosure on the customer portal.

The deferral is real, but it is narrow. It moves the heaviest regime; it does not create a holiday. Article 50 is in force. General-purpose AI model obligations have been running since August 2025. Governance, market-surveillance and the penalty architecture are all standing. Assuming eighteen months of nothing-to-do is how a transparency-obligation fine lands on a company that thought it had until 2027.

And the penalties are not symbolic. Article 99 sets three tiers:

Violation	Maximum penalty
Prohibited practices (Article 5)	€35M or 7% of global annual turnover
Other obligations, incl. transparency (Art. 50) and high-risk provider duties	€15M or 3% of global annual turnover
Misleading information to authorities	€7.5M or 1% of global annual turnover

Note where transparency sits: the 3% tier. The obligation that came due on August 2 is not the cheap one.

One control set, three regulators

Here is the structural fact that reframes the whole exercise. NIS2, DORA and the AI Act were written by different directorates for different populations, but they regulate the same small set of capabilities: risk management, incident handling and reporting, third-party oversight, logging and record-keeping, and technical resilience testing. The vocabulary differs. The underlying evidence does not.

Map one control — "we test our critical systems for exploitable weaknesses and remediate what we find" — across the three and the overlap is obvious:

Underlying control	NIS2	DORA	AI Act
Risk management	Art. 21 measures	Art. 6 ICT risk framework	Art. 9 risk-management system (high-risk)
Incident reporting	24h early warning / 72h / 1-month final	4h initial / 72h / 1-month final	Art. 73 serious-incident reporting
Third-party / supply chain	Supply-chain security in Art. 21	Ch. V ICT third-party risk, Register of Information	Provider ↔ deployer obligations
Logging & traceability	Detection & handling evidence	ICT event logging	Art. 12 automatic record-keeping (high-risk)
Resilience / security testing	Art. 21 testing expectation	TLPT (threat-led penetration testing)	Robustness & accuracy testing (high-risk)

For financial entities the picture is cleaner than it looks: DORA is lex specialis, so where both apply, an ICT-related incident is reported under DORA, not NIS2. That resolves the "24 hours or 4 hours?" question — a bank in scope for both reports the ICT incident under DORA's clock. But it does not collapse the evidence. You still have to demonstrate the risk framework, the third-party register, the testing, and — if you deploy AI in a high-risk function — the AI Act's overlay, all from the same underlying facts.

Three regulators. Largely one control set. The waste is in proving it three separate times.

The clocks don't line up — and that's the tell

Incident reporting is where the "one control set" claim gets tested, because the timers are deliberately different:

• NIS2 — early warning within 24 hours of awareness, a fuller notification within 72 hours, a final report within one month.
• DORA — initial notification within 4 hours of classifying an incident as major (and no later than 24 hours from awareness), an intermediate report within 72 hours, a final report within one month.

DORA's 4-hour initial clock is the tightest in EU cyber regulation. And it exposes the real problem: the deadline is not the hard part — the classification is. You cannot report a major incident in four hours if it takes you three days to notice the anomaly and another two to decide whether it crossed the "major" threshold. The clock only starts once you know something is wrong. Detection latency eats the whole budget before the report template is even open.

This is why an incident-reporting obligation is, in practice, a detection obligation wearing a compliance hat. The regime that looks like paperwork is really asking whether your network tells you what is happening while it happens.

It's an evidence problem, not a rules problem

The rule text is public and, honestly, not that hard to read. What sinks organisations is the gap between having a control and being able to prove it was working on a specific date.

ENISA's third annual maturity assessment, the NIS360 2026 report published on June 2, 2026, makes the gap concrete. It flags seven sectors where systemic criticality outruns cybersecurity maturity — health, railway, maritime, ICT service management, space, public administration, and drinking/waste water. In the water sector, one in three surveyed entities had never conducted a risk assessment. In public administration, roughly a third have no structured process for ensuring cybersecurity expertise at management level, and about half provide no cybersecurity training to management at all. These are not organisations short on regulation. They are short on demonstrable practice.

The traditional answer — an annual penetration test, a point-in-time audit, a PDF in a shared drive — was built for a world with one framework and one auditor a year. It fails three ways under the new load:

• It's stale. A pentest dated last November says nothing about the control that broke in March. Auditors under all three regimes increasingly ask for evidence of continuous assurance, not a one-off snapshot.
• It's siloed. The same finding gets re-documented for the ISO audit, the NIS2 supervisor, and the DORA examiner — three write-ups of one fact.
• It's unprovable after the fact. "We remediated that in April" is a claim. Without a signed, time-stamped record of the finding, the fix, and the re-test, it is an unverifiable claim — exactly the kind that turns a routine review into a finding.

What to do before the auditor asks

Concrete moves that pay off across all three regimes at once, ordered by leverage:

1. Inventory once, map many. Build a single control inventory and map each control to its NIS2 / DORA / AI Act obligation. One control, three citations — not three programmes.
2. Resolve overlap explicitly. For financial entities, document that ICT incidents flow through DORA (lex specialis). Write down which clock governs so no one improvises at hour three.
3. Fix classification before you optimise the report. DORA's 4-hour timer assumes you already know an incident is major. Invest in the detection and triage that makes classification fast; the report template is the easy 20%.
4. Make assurance continuous, not annual. Replace the once-a-year test with change-triggered and scheduled validation, so the evidence for "the control worked" is dated this week, not last autumn.
5. Sign your evidence. A time-stamped, tamper-evident record of finding → remediation → re-test is the difference between "we handled it" and a defensible artefact you can hand an examiner, an insurer, or opposing counsel.
6. Don't assume the December 2027 deferral buys silence. Article 50 transparency is live now. If you deploy customer-facing generative AI, that disclosure control is in scope today.

Where continuous, signed evidence changes the audit

Everything above converges on a single operational requirement: a stream of dated, verifiable proof that your controls work, mapped to every framework that asks. That is the specific problem Zero Hunt's automatic compliance engine is built for. It continuously maps every scan, finding and remediation against 32 frameworks — including NIS2 (with Title 13), DORA (including the TLPT RTS), ISO 27001, SOC 2 and the rest — with severity-weighted scoring and cross-framework control mapping, so one validated finding satisfies its NIS2, ISO and DORA obligations simultaneously instead of generating three separate write-ups. Cross-framework mapping of this kind cuts redundant audit work by up to 70%.

Two properties matter for the scenarios above. Every report is ECDSA-signed with chain-of-custody at write time, so the "we remediated that in April" claim becomes a verifiable artefact rather than an assertion — the auditor, insurer or legal team can check the signature. And the whole thing runs on a 100% on-prem appliance with no cloud callbacks, which matters when the systems under assessment are the critical-infrastructure and financial workloads these regimes exist to protect. The Trust Center turns that continuous stream into one-click, auditor-ready export — the answer to "show me evidence the control was working on this date" for whichever of the three regulators is asking.

The AI Act deadline moved. The evidence problem didn't. The organisations that treat NIS2, DORA and the AI Act as one control set — proven continuously, signed once, mapped everywhere — are the ones that will spend August 2027 producing a report instead of reconstructing a year.