Contents
- Operational information security
- Transitioning to DORA: impact on BAIT/VAIT ISMS requirements
- Use of cyberspace and network security controls (Art. 9(3)(e)(vi) DORA)
- Information security measures (RTS RMF Art. 8)
- ICT solutions for detection (RTS RMF Art. 13)
- Alert routing & security incident response linkage
- Vulnerability analysis (RTS RMF Art. 14)
Operational information security
Transitioning to DORA: impact on BAIT/VAIT ISMS requirements
(Page 24)
BaFin confirms:
- Most BAIT/VAIT expectations remain compatible with DORA.
- DORA, however, adds entirely new minimum requirements that go beyond BAIT, particularly in detection, monitoring, vulnerability handling, and alert routing.
Key areas of uplift compared with BAIT/VAIT:
1. Stronger link to risk analysis
- Information security controls must reflect the risk scenarios derived from the ICT risk analysis (Art. 8 RTS RMF).
- BAIT/VAIT were less explicit about this traceability requirement.
2. Mandatory, technology-agnostic control implementation
- DORA does not require specific technologies but requires institutions to implement controls that are:
- suitable,
- effective,
- regularly tested,
- and proportionate to ICT risk.
3. Universal applicability to all ICT systems
- “Minor” systems (e.g. internal tools, EUC solutions, small web applications, on-prem legacy tools) are not exempt.
Use of cyberspace and network security controls (Art. 9(3)(e)(vi) DORA)
(Page 25)
DORA requires institutions to implement network security measures appropriate to the institution’s size and risk profile.
Key measures explicitly listed:
- Network segmentation
- Boundary protection
- Secure gateways
- Firewalls
- Intrusion detection & prevention
- Secure remote access
- Protection against spoofing and man-in-the-middle attacks
- Logging of network events
- Full integration into the ICT incident-handling process
The PDF confirms that BAIT/VAIT already include similar expectations, but DORA renders them formally binding and auditable on the basis of EU law.
Information security measures (RTS RMF Art. 8)
(Page 25)
This subsection describes the mandatory foundational controls that underpin operational security.
DORA requires a complete set of:
- Information security policies
- Information classification and protection according to classification
- Identity & access management (including privilege governance and MFA)
- Cryptographic controls
- Logging & monitoring controls
- Secure configuration management
- Protection of data at rest, in use, and in transit
These controls are defined as minimum in RTS RMF Art. 8 and are not negotiable.
The key uplift from BAIT/VAIT is the binding nature and the explicit minimum scope.
ICT solutions for detection (RTS RMF Art. 13)
(Page 26)
This is one of the most important sections of the entire DORA operational framework.
Under RTS RMF Art. 13, institutions must deploy ICT solutions for security event detection covering the whole ICT environment.
Minimum mandatory detection requirements:
- Comprehensive visibility into:
- On-prem systems
- Cloud systems
- Hybrid architectures
- Virtualisation layers
- Network layers
- Application layers
- Event monitoring for:
- Access events
- Administrative actions
- Privileged usage
- Authentication events
- Network events
- System anomalies
- Indicators of compromise (IoCs)
- Tools for:
- Log centralisation
- Correlation of security events
- Pattern-based and anomaly-based detection
- Alert generation and routing
- Monitoring of vulnerabilities and misconfigurations
BaFin emphasises:
► These are minimum requirements, not optional enhancements.
Institutions without SIEM or equivalent integrated detection architecture must now implement one.
Alert routing & security incident response linkage
(Page 26)
One of DORA’s strongest changes compared to BAIT/VAIT:
Alerts must be routed to the ICT security function
- Explicitly required under RTS RMF Art. 13(3).
- This applies to all anomaly, security, incident and critical system alerts.
Under BAIT/VAIT, this was good practice; under DORA, it becomes a mandatory and auditable process.
BaFin stresses:
► Alerts must be aggregated, prioritised, and delivered without delay to the ICT security function.
This is a major uplift for institutions relying on reactive or decentralised alerting.
Vulnerability analysis (RTS RMF Art. 14)
(Page 27)
This subsection identifies the second major uplift area: structured vulnerability management.
Minimum mandatory vulnerability processes:
- Systematic identification of vulnerabilities
- Sources: scanners, advisories, threat intelligence, provider bulletins.
- Assessment & prioritisation
- Based on risk levels, criticality of the supporting function, and potential exploitability.
- Remediation
- Within timeframes consistent with the vulnerability category (e.g., critical/zero-day vs. low).
- Follow-up and verification
- Confirm that vulnerabilities have been successfully closed.
- Documentation
- Complete audit trail with timestamps, responsible teams, risk classification.
BAIT/VAIT contain vulnerability-handling requirements—but DORA:
- Introduces more explicit mandatory minimum steps,
- Clarifies the link to the classification of critical/important functions,
- Makes the process directly subject to ICT risk management review.
Source: BaFin, Supervisory statement: Guidance notes on the implementation of DORA for ICT risk management and ICT third-party risk management