Bringing AI agents into DORA's ICT risk management framework means treating each agent as an ICT asset with dependencies, owners and risks. Identify and classify it, protect it with tight access and change control, detect anomalies in its behaviour, respond and recover when it fails, back up its configuration and record, and learn from its incidents.
What does the DORA framework require, in plain words?
DORA (Regulation (EU) 2022/2554), applying from 17 January 2025, requires financial entities to keep a sound, comprehensive and well-documented ICT risk management framework. The management body defines, approves and oversees it and is ultimately responsible. In substance, the framework covers:
- Identification. Identify, classify and document ICT-supported business functions, information assets and ICT assets, with their roles and dependencies, and assess risk, including on major changes.
- Protection and prevention. Security policies, access control, change management and patching that keep ICT systems resilient.
- Detection. Mechanisms to detect anomalous activity promptly.
- Response and recovery. An ICT business continuity policy and response and recovery plans.
- Backup and restoration. Policies and procedures for backup and restoring systems and data.
- Learning and evolving. Post-incident reviews and lessons fed back into the framework.
- Communication. Plans for communicating with clients, counterparts and the public during incidents.
The framework is reviewed regularly and after major incidents, and internal audit checks it. A voluntary reference point, the NIST AI Risk Management Framework, can help with the AI-specific parts, but DORA's framework is the one supervisors examine.
Who has to maintain it?
Every financial entity within DORA's scope, with a simplified framework available to some smaller entities. The framework covers ICT the entity runs and ICT provided by third parties, so agents on a vendor's platform are included. The third-party side is set out in DORA ICT third-party risk when your AI agent runs on a vendor platform.
What changes when the ICT asset is an agent?
A word on terms first. Developers talk about an agent framework, meaning the software library used to build agents. That is an ICT asset to be inventoried. The ICT risk management framework is the governance structure around all assets. Teams that confuse the two end up assuming the developer library handles risk.
Agents change each part of the framework.
Identification must go beyond "an application exists". Record each capability, the depth it needs, its sources, the systems it writes to, its credentials and its model provider. A capability that moves money depends on different assets from one that reads balances.
Change management must treat a model update, a new source or a wider permission as a major change, even when no code changes, and trigger re-assessment and re-testing.
Detection must look at behaviour as well as infrastructure. A sudden fall in refusals, a rise in held actions or a cluster of overrides can signal a problem long before an outage.
Response and recovery need agent-specific options: drop to read-only, stop one capability, stop the agent, fall back to staff, and reconstruct every case touched while it was wrong.
Backup must include the agent's configuration and its action record, not only the data it works on.
How do you meet each framework function for agents?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Identify and classify assets and dependencies | Agent register with capabilities, depth, sources, systems, credentials and providers | Register reconciled to production |
| Assess risk, including on change | Model, source and permission changes treated as major changes | Change records with risk assessments |
| Protect and prevent | Least-privilege identities; every action checked against role scope, certificate, sources, limits and guardrails | Access reviews and filed verdicts |
| Detect anomalies | Thresholds on verdict rates, overrides, refusals and errors per capability | Alerts and investigation records |
| Respond and recover | Runbooks for depth reduction, stop, fallback and case reconstruction | Runbooks and exercise results |
| Backup and restore | Configurations and action records backed up and restorable | Restore test results |
| Learn and evolve | Post-incident reviews feed bound changes and new test cases | Review reports and resulting changes |
| Communicate | Templates for informing clients affected by agent errors | Approved templates and usage |
| Management body oversight | Regular reporting on agent risk and incidents | Board papers and minutes |
Incidents found through detection then need classifying, covered in DORA major ICT incident classification for agent failures.
What will a supervisor or internal audit ask?
- Are agents in your ICT asset inventory, with their dependencies?
- What counts as a major change to an agent, and show us the last one.
- How do you detect that an agent is behaving abnormally?
- Can you restore an agent's configuration and action history after loss?
- What did you change after your last agent incident?
- What does the management body know about agent risk?
What does the framework not cover?
It does not decide whether an agent's outcomes are lawful, fair or accurate in business terms. It does not replace model risk management, which assesses whether outputs are sound. It does not cover the vendor's internal controls, which you assess through third-party risk management; whether a vendor is a third-party provider at all is covered in are AI agent vendors ICT third-party providers under DORA. For the wider map, see AI agent regulation mapped to controls.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Where Pryme fits
Pryme records each agent with its depth, certificate and sources, and checks every action against five bounds before it happens. Each verdict is filed in an append-only record, which supplies identification, detection and reconstruction evidence for the framework, and a certification run that clears no depth drops the agent to depth 1 the same day.
Questions people ask
Is a model update by the vendor a change we must manage?
Yes. It can change how your agent behaves without any action by you. Your framework should require notice of such updates and re-testing before you rely on the updated agent.
Should the agent register be separate from the ICT asset inventory?
It can be a view of the same inventory with agent-specific fields. Keeping two unconnected lists invites gaps.
Do internal-only agents need to be in the framework?
Yes. If they run on the entity's ICT systems or access its information assets, they are within the framework, even if they never touch a customer.