Upcoming Workshop: Citizen Developer Agentic Software Factory on AWS
Register Here!
Independence of approval, with agents in the loop
Article 17 of the RTS asks for mechanisms that keep the function that approves a change independent of the functions that request and implement it. An agent that runs with a developer’s cloud role requests, implements, and in effect approves its own change. Your supervisor will ask where the independent approval was.
DORA requirements mapped to Massdriver controls
Each row names a DORA article or RTS article, what it requires, what Massdriver does for infrastructure changes that run through it, and the evidence your ICT risk function can request. This page is about the EU regulation, not the DevOps DORA delivery metrics.
| Article | What it requires | What Massdriver does | Evidence produced |
|---|---|---|---|
| DORA Art. 9(4)(e) | Documented ICT change management that makes sure all changes to ICT systems are recorded, tested, assessed, approved, implemented, and verified in a controlled manner. | Every infrastructure change, from a person, a pipeline, or an agent, takes one path: configured from the approved catalog, planned, checked against policy, approved where your policies require it, and run in a deterministic pipeline. | A per-change record with the proposer, the approver, the plan diff, and the policy results |
| RTS Art. 17(1)(a) | Change procedures include a verification that ICT security requirements have been met. | Policy checks run before every deploy, and Massdriver integrates with Checkov, Snyk, OPA, and Wiz. | Policy results attached to each change |
| RTS Art. 17(1)(b) | Mechanisms keep the functions that approve changes independent of the functions that request and implement them. | Proposing and deploying are separate permissions held by separate groups. An agent group proposes a production change, and an approver group deploys it. | Group policies; the proposer and approver of each production change |
| RTS Art. 17(1)(e) | Fall-back procedures for aborting changes or recovering from changes that were not implemented successfully. | Deterministic execution keeps the deployment history of each resource, so a change can be traced back and rolled back. | Deployment history per resource |
| DORA Art. 9(4)(c); RTS Art. 21 | Access limited to approved functions, least privilege, segregation of duties, and users identifiable for the actions they perform. | Attribute-based policies limit access by environment, project, and team. Each agent has its own service account, and cloud credentials stay in Massdriver. | Policy definitions; the actor on every audit log entry |
| DORA Art. 8(4); RTS Art. 4 | Identify ICT assets, map their configuration and interdependencies, and record each asset’s owner. | A live inventory lists every resource Massdriver provisioned, with its owner and its dependency graph. | Queryable inventory export |
Massdriver records the changes that go through it. Your auditor or assessor decides whether these records meet a control, and changes made outside Massdriver, in a cloud console or with a cloud key, do not appear in them.
What Massdriver does not cover
DORA is a full operational resilience regime. Massdriver covers the change path for the infrastructure it manages.
- Incident management and reporting. Classifying ICT-related incidents and reporting major ones to your competent authority, under Chapter III, stay with your incident process.
- Resilience testing. The testing programme and threat-led penetration testing under Chapter IV are outside the change path.
- Third-party risk and the register of information. Your contract with Massdriver belongs in your register of information under Article 28(3), like any other ICT service arrangement.
- Emergency changes and changes made outside Massdriver. Your procedures for emergency changes, and any change made in a cloud console or with a cloud key, need their own controls and records.
DORA questions about AI-built infrastructure
Does Massdriver make us DORA compliant?
No. DORA compliance is the responsibility of the financial entity and its management body. Massdriver controls and records changes to the infrastructure it manages, which supports the change management, access, and asset inventory requirements. Your ICT risk function and your supervisor decide how that evidence fits your framework.
When did DORA start to apply?
Regulation (EU) 2022/2554 applies from 17 January 2025. The RTS on the ICT risk management framework, Delegated Regulation (EU) 2024/1774, sets the detailed change management and access control requirements.
Can Massdriver run inside our own environment?
Yes. Massdriver runs self-hosted in your cloud account, so its state, deployment history, and audit logs stay inside your environment.
Other framework mappings
SOC 2
Change management, logical access, and monitoring criteria, mapped to the record each change leaves.
See the mapping →HIPAA
Security Rule access, audit, and integrity standards for the infrastructure that holds ePHI.
See the mapping →NIST AI RMF
Govern, Map, and Manage subcategories for the coding agents your teams already use.
See the mapping →One governed path, for agents and every other change.
Give us an hour with your platform and security leads, and within a day you have a governed path running on your own infrastructure, ready to prove for 30 days.