A secure system can become less secure even when no new application code is released. Configuration drift occurs when the settings, software, infrastructure or access state observed in an environment no longer match the approved baseline, whether through manual work, failed automation, provider change or an incomplete recovery.
An approved baseline makes drift measurable
The bank defines the expected configuration for each material system or component, including software versions, security settings, network rules, identities, logging, encryption, resilience parameters and relevant cloud-service controls. The baseline is versioned, owned and connected to the system's risk and change records.
Different development, test, recovery and production environments may have different approved baselines. Drift means a difference from the baseline that applies to that environment; it does not mean every system must have identical settings or that a vendor default is automatically approved.
Drift can be authorized, accidental or malicious
An engineer may make an emergency change during an incident, an automated deployment may update only part of a fleet, a restored server may use an old image or a cloud provider may introduce a new default. An attacker or misused privileged account can also alter a control while attempting to avoid detection.
The same observed difference can therefore have very different significance. The investigation asks who or what changed the setting, when it changed, whether the change was approved, which assets share it and what security, availability, data or customer processes could be affected.
Continuous comparison finds differences early
Configuration and asset-management tools collect observed state and compare it with the approved source. Alerts can identify an open network path, disabled log, outdated component, excessive permission or other variation before a scheduled manual review would find it.
Detection coverage matters as much as alert volume. The bank accounts for short-lived cloud resources, managed services, containers, recovery environments and third-party components so a clean dashboard does not simply reflect systems that were never inventoried or queried.
Response is risk-based and preserves evidence
A high-risk unauthorized change can be isolated or reverted immediately, while a lower-risk difference may be held for owner review. Before correction, the bank preserves relevant logs and state so it can distinguish an intrusion, failed deployment, unrecorded emergency action or stale baseline.
Automated remediation is tested because a blind rollback can interrupt service, remove a legitimate fix or conflict with a provider-managed dependency. Where immediate correction is unsafe, temporary safeguards, monitoring, ownership and a deadline keep the exception visible.
Change control and reconciliation prevent recurrence
Approved changes update the baseline, deployment code and supporting records together. Privileged access, peer review, segregation of duties and controlled pipelines reduce untracked manual changes, while emergency procedures require later validation and documentation rather than allowing incident work to become permanent by accident.
Teams reconcile drift findings with change tickets, vulnerability results, incidents and recovery tests. Repeated differences can reveal unstable automation, unclear ownership, inaccurate templates or a service design that relies on manual repair, leading to correction of the process rather than endless one-off resets.
Read the primary material
Banking Explained prioritizes regulators, official publications and first-party announcements.