Swedbank’s Outage Fine Exposes the Limits of Traditional Change Control
In April 2022, Swedbank suffered a major IT outage after an unapproved change was made to one of its central systems. Nearly a million customers were left with incorrect balances, and many couldn’t make payments. The Swedish financial regulator (Finansinspektionen) investigated and fined the bank SEK850M (~$85M USD) for failing to follow its own change management process.
The regulator’s judgment avoided technical specifics, but its reasoning is clear from the public decision. The bank’s internal controls “made it possible to make changes to one of the bank’s most central IT systems without following the process.” None of the bank’s control mechanisms detected the deviation. The regulator also noted that non-compliance likely slowed the incident analysis and increased operational impact.
While the fine is substantial, the regulator explicitly considered harsher penalties: “It is therefore not relevant to withdraw Swedbank’s authorisation or issue the bank a warning. The sanction should instead be limited to a remark and an administrative fine.” In other words, the bank kept its license.
The Self-Referential Logic of Compliance
This case follows a familiar pattern: an outage occurs, an unapproved change is blamed, the bank argues its controls work if followed, the regulator fines the bank for non-compliance and insufficient controls, and the bank responds by adding more controls.
That logic — you said you’d manage risk, you didn’t, therefore you’re in violation — treats change management as an end in itself. But following a process is not the same as reducing risk. Adherence to change management reduces the risk of undocumented changes, but fully documented changes can pass through approval gates with their risks unnoticed.
The UK’s Financial Conduct Authority (FCA) reached a similar conclusion through data. In a multi-firm review, the FCA found that Change Advisory Boards (CABs) approved over 90% of major changes they reviewed, and in some firms the CAB never rejected a single change during 2019. That raises serious questions about the CAB’s value as an assurance mechanism.
The FCA’s findings align with the research in Accelerate by Dr. Nicole Forsgren, Jez Humble, and Gene Kim:
“We found that external approvals were negatively correlated with lead time, deployment frequency, and restore time, and had no correlation with change fail rate. In short, approval by an external body (such as a change manager or CAB) simply doesn’t work to increase the stability of production systems, measured by the time to restore service and change fail rate. However, it certainly slows things down. It is, in fact, worse than having no change approval process at all.”
Approval by an external body is worse than no approval process at all. Yet banks and other regulated firms keep the process, largely because it protects individuals from liability. Tick the boxes, follow the steps, and a regulator can’t pin a fine on you personally — even if the system itself remains unsafe.
Smaller, More Frequent Changes Reduce Risk
The FCA’s research points to a more effective approach: “Firms that deployed smaller, more frequent releases had higher change success rates than those with longer release cycles. Firms that made effective use of agile delivery methodologies were also less likely to experience a change incident.”
Less risky changes reduce risk; paperwork does not. The regulators themselves acknowledge that frequent releases and agile delivery can help reduce both the likelihood and impact of change-related incidents.
A useful mental model: software changes are streams feeding into environments that are lakes. Change management gates what flows into the lake but doesn’t monitor the lake itself. If a change can reach production undetected, the gate only protects against one source of risk. The only way to catch undocumented production changes is runtime monitoring.
This gap between approved process and actual system state echoes the Knight Capital incident, documented by the SEC. In both cases, an incomplete understanding of what had been applied to production, due to insufficient observability and traceability, prolonged and amplified the outage.
It also leaves an unanswered question: how many similar changes were made that didn’t cause an outage? Without monitoring, it’s impossible to know.
Why the Process Persists
Traditional change management made sense when changes were rare, large, and risky — the annual upgrade, the monthly patch. Those big batches justified long testing, service windows, and checklist-driven approval. Before modern test automation, continuous delivery, and fast rollback existed, that was the only available approach.
But financial services remain full of legacy systems and outsourced environments where modern practices are technically difficult and uneconomic to implement. That combination is itself a major systemic risk in the sector — as is the opposite problem: next-generation financial systems so dynamic and distributed that tracking every change becomes nearly impossible.
Risk Management That Actually Works
The only reliable way to reduce change risk is to make changes less risky: move to smaller, more frequent releases, automate change controls and documentation, and add monitoring and alerting to detect unauthorized changes. This is the DevSecOps approach — harmonizing software delivery speed with cybersecurity, audit, and compliance demands.
Checklists help, but they aren’t a substitute for technical risk reduction. If change management exists mainly to demonstrate compliance, it will protect compliance officers, not production systems.
