Contents
ICT project management and application development
Analogous requirements for ICT project management
(Page 19)
DORA’s RTS RMF Art. 15 defines minimum mandatory elements of ICT project methodology.
1. Core project-methodology requirements remain similar to BAIT/VAIT
The RTS requires:
- A policy for ICT project management (Art. 15(1)–(3)).
- Structured project phases.
- Defined responsibilities.
- A risk-oriented methodology.
This aligns with BAIT Chapter 7.3 and VAIT Chapter 7.4.
2. Significant simplifications vs. BAIT/VAIT
DORA removes some BAIT/VAIT burdens:
- No requirement for interdependency risk assessment across multiple projects.
BAIT demanded that dependencies between projects must be risk-assessed; RTS RMF drops this explicitly. - Less formal documentation requirements.
RTS RMF does not require:- a classical project documentation set,
- lessons-learned documentation,
- detailed governance descriptions.
3. Stronger focus on the material impact of projects
Instead of BAIT/VAIT’s process governance:
- Projects must be evaluated based on impact on critical or important functions.
- Criticality must be reported to the management body (Art. 15(5) RTS RMF).
This aligns with DORA’s new “critical/important function” concept.
Detailed stipulations regarding ICT system acquisition, development and maintenance
(Page 20)
This is the area where DORA adds the most technical depth.
RTS RMF Art. 16 introduces concrete, technical, security-driven minimum requirements for:
- acquisition,
- development,
- maintenance,
- testing,
- source-code handling.
Compared to BAIT/VAIT, DORA is far more technical and prescriptive.
1. New minimum policy requirements (Art. 16(1))
The BAIT/VAIT focus on documentation; RTS RMF focuses on secure implementation:
- Secure development lifecycle requirements
- Requirements identification
- Design for security
- Secure coding principles
- Controlled environments
- Management of development and test systems
No explicit requirement for a classic “Pflichtenheft” / functional specification.
2. Significantly expanded testing requirements (Art. 16(2))
The RTS now mandates:
- Mandatory security testing for IT systems
- More specific procedures than BAIT/VAIT
- A structured security test regime
Mandatory source-code analysis for Internet-facing systems (Art. 16(3))
This is new and does not exist in BAIT/VAIT:
- Static code analysis (SAST)
- Dynamic code analysis (DAST)
- Includes:
- internally developed code AND
- third-party code AND
- compiled proprietary software (yes: compiled binaries must be tested for anomalies)
This significantly increases compliance work.
3. Third-party and open-source code (Art. 16(8))
Explicit requirement:
- All third-party source code, supplied code modules, and proprietary compiled code must undergo anomaly testing before productive use.
BAIT/VAIT contain no comparable specification.
4. Inclusion of end-user computing (EUC) (Art. 16(9))
RTS RMF does not distinguish between:
- End-User Computing (EUC) tools (Excel, Access, PowerQuery, VBA, RPA)
- Standard applications
- In-house developed systems
Under DORA:
- All non-IT developments must be risk-assessed.
- EUC loses its “special status” and becomes subject to full testing obligations.
This is a major operational impact for banks and insurers.
Removal of the materiality threshold for ICT change management
(Page 20–21)
This is one of the most consequential DORA changes.
RTS RMF Art. 17 replaces BAIT/VAIT’s risk-based limitation (“only significant changes”) with a strict requirement:
“All ICT changes must be governed, tested and approved.”
— RTS RMF Art. 17(1)(c)
This means:
1. Every change is in scope
- Patches (OS, DB, middleware)
- Parameter changes
- Firewall rule changes
- Configuration settings
- PowerShell/Shell script updates
- Cloud configuration changes (IaC)
- API version updates
- Data model adjustments
- Minor release increments
- Infrastructure changes
- Firmware updates
2. Mandatory steps for ALL changes
RTS RMF requires that each change must:
- Be recorded/documented
- Undergo impact analysis
- Be tested
- Have a fallback/rollback plan
- Be approved (with separation of functions; Art. 17(1)(b))
- Be verified after implementation
- Be logged and traceable
This is a substantial uplift compared to BAIT/VAIT.
3. No requirement for involvement of additional departments
BAIT/VAIT required extra involvement depending on materiality. RTS RMF does not require involvement of additional units.
Source: BaFin, Supervisory statement: Guidance notes on the implementation of DORA for ICT risk management and ICT third-party risk management