Change Management Under DORA: Why Baseline Control Is the Most Underrated Requirement

The Quiet Killer of Operational Resilience

Cyberattacks make headlines. Change failures make outages.

The UK banking sector's 803 hours of IT outages across 18 months — 158 incidents affecting millions of customers — were overwhelmingly caused not by sophisticated cyber threats but by failed changes: software deployments that introduced bugs, configuration changes that broke integrations, database migrations that corrupted data, and infrastructure changes that caused cascading failures.

This pattern is not unique to the UK. Across European financial services, failed changes are the single largest source of self-inflicted operational disruption. They are also the most preventable source — because every change passes through a decision point where it can be reviewed, tested, approved, or rejected before it touches production.

DORA addresses change management through multiple articles: Art. 9(4)(e) requires policies for "changes to ICT systems, including software updates, upgrades and other changes." Art. 7 requires that ICT systems are "reliable" and "maintained." Art. 9(2) requires "procedures and protocols to ensure the protection of ICT assets and information." And Art. 25 connects testing to change control by requiring that deficiencies identified through testing be "duly addressed."

Yet change management is the DORA requirement that most institutions treat as administrative overhead rather than a resilience discipline. The change advisory board (CAB) meets weekly, stamps approvals, and changes go to production. The process exists on paper. The discipline does not exist in practice.

Baseline Control: The Foundation

What Is a Baseline?

A baseline is a documented, versioned snapshot of a production system's configuration at a known-good state. It includes: application versions, configuration parameters, infrastructure specifications, database schema version, integration endpoints, certificate expiry dates, and access control configurations.

The baseline is the reference against which all changes are evaluated, approved, and — if necessary — rolled back.

Why Baseline Control Matters

Without baseline control, the institution cannot answer fundamental questions:

• "What exactly is running in production right now?" (Art. 8 asset identification)
• "What changed between the known-good state and the current state?" (incident investigation)
• "Can we roll back to the previous known-good state?" (Art. 11 recovery)
• "Is the production configuration consistent with what was tested?" (Art. 24 testing validity)

The ECB and national supervisors expect institutions to maintain configuration management with version control and audit trails. A production environment where changes are made without documentation is ungovernable — and ungovernable systems are non-compliant.

The DORA-Compliant Change Management Framework

Change Classification

Not all changes carry equal risk. Classification determines the governance level:

The Change Lifecycle

Every non-standard change must follow a lifecycle with documented evidence at each stage:

1. Request and Impact Assessment.

• What is being changed?
• Which ICT assets and business functions are affected?
• What is the risk if the change fails?
• What is the risk if the change is not made? (The risk of not patching a critical vulnerability may exceed the risk of the patch failing.)

2. Approval.

• Standard: automated against pre-defined criteria
• Normal: CAB review with impact assessment, rollback plan, and test results
• Emergency: minimum two authorized approvers with documented justification
• Major: management body awareness (Art. 5 governance)

Separation of duties is non-negotiable: the person requesting the change must not be the sole approver. The person implementing the change must not be the sole approver. This maps to DORA's governance principles and the maker-checker pattern required for high-risk operations.

3. Implementation.

• Execute per the approved change plan
• Record actual implementation steps (deviations from plan must be documented)
• Monitor impacted systems during and after implementation

4. Post-Implementation Verification.

• Confirm the change achieved its intended outcome
• Verify no unintended side effects (performance degradation, error rate increase, integration failures)
• Compare production state to the new baseline
• Update the ICT asset register if the change affects registered assets

5. Closure.

• Document the outcome (success/partial success/failure/rollback)
• If rolled back: document root cause and lessons learned
• Update baseline documentation

Emergency Change Control

Emergency changes are the highest-risk category because they bypass normal approval timelines. DORA requires that even emergency changes are governed:

Hard rules for emergency changes:

• Minimum two authorized approvers (not one, regardless of urgency)
• Scope must be minimal — fix the immediate issue, nothing more
• Post-implementation review within 24 hours
• Full retrospective at the next CAB meeting
• Emergency change volume is a KPI — frequent emergency changes indicate a failing change management process

Rollback Capability

Every change must have a documented and tested rollback plan. Art. 11 business continuity applies to change-induced failures as much as to external incidents. The rollback plan must specify:

• Trigger criteria: What conditions trigger a rollback? (e.g., error rate > 5%, P95 latency > 2x baseline, critical integration failure)
• Procedure: Step-by-step rollback instructions that can be executed under pressure
• Time estimate: How long will rollback take? This must be within the function's RTO.
• Verification: How to confirm the rollback succeeded and the system is at the previous known-good state

Baseline Control in Practice

Infrastructure as Code (IaC)

For institutions using cloud or containerized infrastructure, Infrastructure as Code provides baseline control by definition: the infrastructure configuration is version-controlled, reproducible, and auditable. Every change to infrastructure is a code change subject to the same review and approval process as application changes.

DORA alignment: IaC provides Art. 8 asset identification (infrastructure is documented as code), Art. 9 configuration management (changes are reviewed and approved), and Art. 11 recovery capability (infrastructure can be rebuilt from code).

Configuration Management Databases (CMDB)

For institutions with traditional infrastructure, the CMDB is the baseline control mechanism. It must be:

• Accurate: Reflect the actual state of production, not an aspirational state
• Current: Updated within 24 hours of any change (automated discovery preferred)
• Auditable: Every change to the CMDB is logged with actor, timestamp, and justification

Database Schema Versioning

Database schema changes are among the highest-risk changes in financial services. A failed migration can corrupt data, break applications, and create audit trail inconsistencies. Schema versioning tools (Flyway, Liquibase, or framework-specific migration systems) provide:

• Sequential, versioned migration scripts
• Forward and backward migration capability
• Migration state tracking (which version is deployed in each environment)
• Schema drift detection (is production schema consistent with the expected version?)

Measuring Change Management Effectiveness

The CISO dashboard should include change management metrics as an operational resilience KPI. A rising trend in change failure rate or emergency change percentage is a leading indicator of future outages.

Key Takeaways

• Change failures cause more outages than cyberattacks in financial services. The UK's 803 hours of banking outages in 18 months were predominantly change-related.
• Baseline control is the foundation: know what is in production, control what changes, and maintain the ability to roll back to a known-good state.
• Change classification drives governance level: standard (automated), normal (CAB), emergency (expedited), major (management body).
• Separation of duties is non-negotiable: requester ≠ approver ≠ implementer.
• Rollback capability is an Art. 11 requirement — every change must have a documented, tested rollback plan with defined trigger criteria.
• Emergency change volume is a KPI. Frequent emergency changes indicate a failing change management process, not an agile one.

---

Resume en francais

Les echecs de changement causent plus de pannes que les cyberattaques dans les services financiers — les 803 heures d'interruptions bancaires au Royaume-Uni en 18 mois etaient principalement liees a des changements echoues. L'article 9(4)(e) de DORA exige des politiques de gestion des changements TIC, et l'article 7 exige des systemes fiables et maintenus. Le controle de la ligne de base (baseline control) est le fondement : documenter l'etat de chaque systeme de production en version controlee — versions applicatives, configurations, schemas de base de donnees, dependances tierces et controles d'acces. Chaque changement est classifie (standard, normal, urgence, majeur) avec un niveau de gouvernance proportionnel. La separation des taches est non-negociable : le demandeur ne peut pas etre le seul approbateur. Chaque changement doit avoir un plan de retour en arriere documente et teste avec des criteres de declenchement definis. Le volume de changements d'urgence est un indicateur cle — s'il depasse 20 % du total, le processus de gestion du changement est defaillant. L'Infrastructure as Code fournit un controle de baseline naturel pour les environnements cloud et containerises.