A common mistake is treating compliance as a documentation exercise instead of an operating model. Teams may fail to maintain process registers, misclassify data and systems, or leave third-party and supply-chain exposure unassessed. The result is fragmented ownership, weak evidence for auditors, and slow incident response. Effective compliance depends on continuous governance, not one-time policy approval.
Why multi-regime compliance breaks down in practice
When organisations try to satisfy DORA, NIS 2, and the eu ai act together, they often inherit three different compliance grammars and fail to normalise them into one control model. DORA drives operational resilience and ICT third-party governance, NIS 2 drives essential-service risk and incident obligations, and the EU AI Act drives lifecycle governance for AI systems. The common failure is to map each law to a separate spreadsheet instead of a shared operating cadence.
That creates predictable gaps: registers drift out of date, ownership becomes split across legal, security, risk, and product teams, and evidence is assembled only when an audit or assessment is imminent. A better model is to treat the three regimes as overlapping views of the same control estate, with one inventory, one ownership model, and one incident path that can satisfy all three. NHIMG’s regulatory and audit perspectives are useful here because the recurring failure is not the rulebook itself, but the lack of durable governance around the assets the rulebook depends on.
In the underlying control estate, this usually includes access paths, service accounts, integration points, and third-party dependencies, all of which need to be visible before they can be assessed consistently. The same operating model also has to support AI-specific accountability, so teams can explain where an AI system sits, who owns it, what data it uses, and how changes are approved. The EU AI Act becomes easier to operationalise when it is treated as part of that same governance layer rather than as a separate legal exercise.
Where organisations misread the scope of each regime
Another recurring mistake is to assume the regimes are narrower than they are. Teams may focus on policies and controls for the most obvious in-scope systems, while overlooking supporting infrastructure, shared services, and supplier-managed components that carry operational or compliance impact. DORA and NIS 2 both push organisations toward better third-party oversight, while the AI Act adds traceability and lifecycle expectations for AI systems and their use in business processes.
This is why scope decisions need to be explicit, repeatable, and reviewable. If an AI system depends on outsourced hosting, external APIs, or managed platforms, the compliance question is not only whether the model is permitted, but whether the surrounding operational dependencies are governed to the same standard. The official DORA page is a useful anchor for the resilience and third-party side of that question, while the NIS2 Directive is the baseline for understanding why supply chain and incident handling cannot be treated as peripheral issues.
Practitioners also underestimate how much of the real work sits below the policy layer. Evidence only becomes trustworthy when the organisation can show how inventories are maintained, how exceptions are approved, and how incidents are escalated across functions. NHIMG’s State of Secrets in AppSec is relevant because hidden credentials, hardcoded secrets, and unmanaged access paths are exactly the kinds of operational weaknesses that sabotage repeatable compliance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 set the technical controls, while DORA, NIS2 and EU AI Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| DORA | ICT third-party risk management — ICT Third-Party Risk Management | DORA directly governs outsourced ICT dependencies and resilience obligations. |
| Recommendation — Assess and govern third-party ICT dependencies with contract, oversight, and resilience controls. | ||
| NIS2 | Article 21 — Cybersecurity Risk-Management Measures | NIS 2 requires risk management, supply-chain security, and incident handling. |
| Recommendation — Implement risk-management measures that cover supply chain security, incident response, and operational continuity. | ||
| EU AI Act | Article 9 — Risk Management System | The AI Act requires a lifecycle risk-management process for in-scope AI systems. |
| Article 11 — Technical Documentation | The AI Act depends on current technical documentation to evidence compliance and system behavior. | |
| Recommendation — Maintain a documented, iterative risk-management process for each in-scope AI system. Keep technical documentation current enough to demonstrate how the AI system is built, used, and controlled. | ||
| CIS Controls v8 | 5 — Account Management | Shared inventories and ownership break down when accounts and dependencies are not controlled. |
| Recommendation — Inventory, review, and revoke accounts and access paths continuously. | ||
Practitioner Guidance
What to prioritise: Build a single control inventory that covers ICT assets, AI systems, third parties, and the evidence needed to prove ownership. If a control cannot be traced to a named owner and a current system of record, it will fail under one regime even if it looks acceptable in a policy pack.
What to verify: Check whether incident reporting, risk review, and approval workflows are actually shared across the three regimes, or whether each team is maintaining its own process with different dates, artifacts, and definitions. Fragmented workflows usually produce the weakest audit trail, not the strongest one.
Practitioner takeaway: The winning approach is to govern the operating model first, then map the three laws onto it. If the organisation cannot keep inventory, ownership, and evidence continuously current, it is not complying at scale, it is merely preparing for inspection.
Related resources from NHI Mgmt Group
- What do organisations get wrong when they prepare for EU AI Act compliance too late?
- What do organisations get wrong when they try to use CIAM to support compliance and customer experience at the same time?
- What do organisations get wrong when they treat human, machine, and AI identities the same?
- What do organisations get wrong about post-market monitoring under the EU AI Act?
