Why Your CMDB Is the Real Test of FCA Operational Resilience in London
On 27 July 2026, a fault on the UK’s shared Faster Payments rail stopped many customers from completing transfers the same afternoon. Reporting from FSTech described disruption affecting users of banks including Lloyds, HSBC, and Barclays, with related coverage also naming Halifax and other retail brands in the same window.
The cause sat in infrastructure no single firm fully owns. Firms without a current map of which important business services touch that rail spent early hours establishing exposure rather than answering the board, the regulator, or the customer. This is where a CMDB for FCA operational resilience in London stops being a configuration project and becomes the evidence layer behind resilience testing, incident reporting, and Payment Card Industry Data Security Standard (PCI DSS) scope. Some customers that afternoon saw failure messages for payments that had already cleared, which raised duplicate-payment risk while support queues filled.
It is not a one-day story. Coverage of Treasury Committee data appears in FSTech’s summary and The Guardian’s report. Nine of the UK’s largest banks and building societies logged at least 803 hours of unplanned IT outages across 158 incidents between January 2023 and February 2025. Firms had until 31 March 2025 to complete core Financial Conduct Authority (FCA) and Prudential Regulation Authority (PRA) mapping and testing obligations. Newer operational incident and third-party reporting rules under FCA PS26/2 and the aligned Bank of England PS7/26 apply from 18 March 2027. Mapping and testing already bind; reporting windows will tighten further.
The outage cause was the shared rail, not any named bank’s asset register. What varies by firm is how fast leadership can answer: which of our important business services and cardholder-data paths depend on the failed component?
If your board asks whether runtime inventory and dependency truth keep pace with those obligations, start with Trusted Runtime Truth.
What Is FCA Operational Resilience, and Where Does PCI DSS Fit?
The FCA’s operational resilience hub frames the regime around identifying important business services, setting impact tolerances, mapping the resources those services need, and testing whether the firm can stay within tolerance through severe but plausible disruption. The Bank of England’s operational resilience overview places this work within financial stability, not just firm-level IT hygiene.
PRA Supervisory Statement SS1/21 is explicit on mapping. For each important business service, firms must understand the people, processes, technology, facilities, and third parties that support delivery. That technology line is not a slide. It is a living inventory of systems, connections, and ownership that must match what runs when an incident starts.
PCI DSS sits beside that regime for any London bank, fintech, or payment processor that stores, processes, or transmits cardholder data. The PCI Security Standards Council document library holds the current standard. Schellman’s explainer on PCI DSS v4.0.1 scoping validation covers Requirement 12.5.1: maintain an inventory of in-scope system components for PCI DSS. It also covers Requirement 12.5.2: confirm the accuracy of PCI DSS scope at least annually, and every six months for service providers. Scope is a map of in-scope components and how they connect to the cardholder data environment (CDE), the same class of question the PRA asks for technology under important business services: what exists, what depends on what, and who owns the record.
Side by side, the core asks look like this:
- FCA/PRA: identify important business services; set impact tolerances; map people, processes, technology, facilities, and third parties; scenario-test; keep mapping current as the estate changes.
- PCI DSS: define the CDE; inventory in-scope system components (12.5.1); reconfirm scope on the required cycle (12.5.2); treat change as a scope event, not only an audit event.
Two regulators. One underlying data problem. If the configuration management database (CMDB) and dependency map lag the estate, both exercises describe last year’s environment.
The hidden problem
Firms that still run resilience mapping and PCI scoping from workshops and spreadsheets typically see the same failure pattern:
| Situation | What happens |
|---|---|
| Firm completes its annual FCA self-assessment mapping exercise | The underlying CMDB was last reconciled months earlier; the map describes an environment that has since changed |
| QSA requests PCI DSS CDE scope confirmation | Team manually cross-checks spreadsheets against a network scan and finds cloud assets in neither |
| A shared-infrastructure incident hits (Faster Payments-style) | The firm spends the first hours of its incident window establishing its own exposure, not reporting it |
| Resilience mapping and PCI scoping run as two separate spreadsheets | The same asset shows up differently in each, and reconciling them becomes its own project before every audit |
None of those rows require a careless team. They require an estate that changes faster than a point-in-time workbook.
Why This Matters for London’s Banking and Payments Sector
London concentrates retail banks, investment banks, payment institutions, and fintechs that share rails, cloud regions, core-banking vendors, and card processors. A CMDB for the banking and payments sector in this market has to hold third-party technology relationships as first-class configuration items, not footnotes in a policy pack.
Two verified pressure points:
- Operational disruption volume. Treasury Committee-linked reporting (FSTech; The Guardian) put at least 803 hours of unplanned outages across 158 incidents at nine major UK banks and building societies between January 2023 and February 2025. That is more than a month of cumulative disruption in under 26 months.
- Breach economics in financial services. IBM’s Cost of a Data Breach Report places financial services among the highest-cost industries. Secondary reporting of the 2026 edition commonly cites about $6.29 million average for financial services, above the global average near $4.99 million. Treat round numbers as directional until your GRC team pulls the exact table for the year you cite.
Failure modes that show up in London estates
- Important business services mapped once a year by workshop, not validated against live infrastructure.
Workshop maps freeze ownership and topology at a point in time. Hybrid estates add instances, retire hosts, and change vendor paths between workshops.
Result: the FCA self-assessment describes an environment that no longer exists by the next incident. - PCI DSS CDE boundary set at the last assessment, not after every material change.
New cloud workloads, vendor integrations, and M&A consolidations move cardholder-data-adjacent systems without updating the inventory that Requirement 12.5.1 expects to stay current.
Result: systems sit outside documented scope before anyone notices. - Shared and third-party dependencies are not tracked as owned configuration items.
Payment rails, cloud accounts, and core banking platforms appear in contracts and runbooks, not as CIs with relationships and owners. The FCA’s March 2026 review of resilience testing named this a consistent gap: firms mapped internal technology but stopped at the edge of third-party providers instead of mapping through them to the services those providers support (FCA insights and observations).
Result: when shared infrastructure fails, the firm loses first reporting hours to discovery instead of response. - Resilience and PCI teams keep separate asset records.
One spreadsheet serves the resilience self-assessment. Another serves the QSA, and neither is fed by the same discovery cadence.
Result: duplicated reconciliation and two answers to “is this system in scope?”
An older but still clear illustration sits outside any single outage day: the FCA’s press release on TSB’s £48.65m fine (with the PRA) for operational risk management and outsourcing governance failures after a major IT migration. Change risk invisible in the asset and dependency record becomes customer harm, then supervisory action. Migration and outsourcing complexity without configuration truth carries regulatory cost, not only engineering cost.
The Real Cost of Getting CMDB Accuracy Wrong for FCA and PCI DSS
For boards and CIOs
Operational resilience failures sit under senior manager accountability under the Senior Managers and Certification Regime (SMCR). When mapping cannot be evidenced against a current technology record, the board is defending process language rather than runtime facts. KPMG’s Regulatory Barometer (April 2026) flags third-party and supply-chain failure as an expanding supervisory focus — one that lands on firms that cannot show which important services depend on which external platforms on the day something breaks.
For SecOps and compliance teams
PCI DSS 12.5.2 turns scope confirmation into a recurring evidence job, not a one-off project. Schellman’s scoping guidance makes the cycle clear: inventory must match what is in scope, and service providers face a six-month confirmation rhythm. Without a discovery-fed CMDB, each cycle restarts as spreadsheet archaeology, and hours go to proving the boundary rather than hardening controls inside it.
For CMDB owners and configuration managers
You already carry two regulator-facing stories: important-business-service technology maps for FCA/PRA, and CDE component inventory for PCI. When discovery is manual, those stories diverge after every change weekend, and the job becomes endless join work across cloud consoles, CMDBs, and GRC workbooks — hours every week, not abstract “data quality” language.
For the London market at scale
PwC UK and TheCityUK’s “Operational resilience in Financial Services: Time to act” frames resilience as a competitiveness issue for UK financial services, not only a compliance checkbox — a framing the FCA has echoed. Firms that can produce dependency truth under pressure protect customer trust and supervisory confidence in the same motion.
How a Discovery-Sourced CMDB Fixes This
A discovery-sourced CMDB does not replace your GRC platform, your QSA engagement, or your resilience self-assessment narrative. It supplies the infrastructure-of-record those exercises assume is true.
1. High-frequency scheduled discovery
IT discovery that runs on a high-frequency scheduled cadence across on-premises estate, AWS, and Azure replaces the annual freeze. Agent-based and agentless methods each have a place; the practical guide is agent-based vs agentless discovery. The product-safe claim is scheduled, high-frequency refresh, not continuous or event-driven capture. New instances, retired hosts, and drifted attributes enter the record on the scan cycle your change rate requires.
2. ViVID™ dependency mapping
Once service definitions are supplied (manually, via import, or via integration), service mapping builds the dependency map that shows which CIs support which important business services and which paths sit near the CDE. That map is the raw material for PRA technology mapping and for PCI 12.5.1 inventory-with-function context. Why the map matters operationally is covered in service mapping and its criticality. Third-party platforms appear as owned relationships, so a rail or cloud region failure has a query path instead of a war-room guess.
3. ITSM-integrated governance
Resilience and PCI evidence have to live where UK banking IT already works. ITAM and CMDB practice only stick when the record syncs into ServiceNow, Jira Service Management, Ivanti, HaloITSM, and related platforms rather than sitting in a third spreadsheet. Virima integrates with ServiceNow, Jira, Ivanti, and many more. Governance habits that keep a ServiceNow CMDB trustworthy after imports are covered in ServiceNow CMDB governance best practices.
| Dimension | Manual / spreadsheet-based | Discovery-sourced CMDB |
|---|---|---|
| Refresh cadence | Point-in-time, ahead of an audit | High-frequency scheduled scans across hybrid environments |
| Source of truth during an incident | Static diagram, often out of date | Live dependency map, queried in the moment |
| PCI CDE scope confidence | Confirmed manually per cycle | Reconciled against actual infrastructure on the discovery schedule |
| Third-party dependency visibility | Tracked informally or not at all | Mapped as owned configuration items |
| Effort before an FCA self-assessment | Weeks of reconciliation | A query against a maintained record |
Virima’s CMDB and ViVID™ maps give resilience and compliance teams the dependency data their mapping and scoping exercises are built on. They do not “ensure” FCA compliance or “satisfy” PCI DSS. Discovery covers network-connected infrastructure and cloud accounts in product scope. It does not inventory browser-rendered payment-page scripts under PCI DSS Requirement 6.4.3; that control stays with application security and payment-page monitoring programmes.
Operational Resilience and PCI DSS in Practice
- Shared-rail outage, scoped inside the reporting window.
A firm with a maintained dependency map queries which important business services touch the affected rail as soon as the incident is known. Ownership, supporting CIs, and third-party links are already recorded. The first hours go to customer communication and regulatory notification, not to rebuilding topology from tickets. - Cloud migration that does not silently expand PCI scope.
A settlement workload moves to AWS mid-year. High-frequency scheduled discovery picks up the new instances. ViVID™ relationships show whether those instances sit inside or adjacent to the documented CDE path. Scope confirmation for 12.5.2 becomes a controlled update, not a surprise finding at the next assessment.
Both examples are illustrative. They are unnamed on purpose. No London bank is presented here as a product customer.
How Virima Supports Operational Resilience and PCI DSS Teams
- Immediate operational impact: Teams that need a first dependency map quickly can evaluate Virima CMDB against the public claim used across Virima materials: a first dependency map inside 60 minutes once discovery and service definitions are in place. Confirm that claim against current product materials in your evaluation, then measure it on your estate.
- Long-term accuracy: CMDB health and confidence practices reduce drift between FCA self-assessment cycles and PCI 12.5.2 confirmation windows. CMDB audit essentials cover the accuracy habits that keep the record defensible.
- Integration with existing workflows: Resilience and PCI evidence should travel with change, incident, and asset processes already running in ITSM. For the broader financial-services compliance companion (SOX, PCI, DORA, and related regimes outside the London FCA lens), see IT asset management for financial services compliance. US metro siblings on the same pain-point pattern are PCI DSS CMDB accuracy for Atlanta payment processors and PCI DSS compliance for Chicago enterprises.
Moving from Annual Mapping Exercises to a Live, Map-Driven Record
| From | To |
|---|---|
| Point-in-time inventory, refreshed for the audit | High-frequency scheduled discovery across on-prem and cloud |
| Static diagrams and spreadsheets | ViVID™ dependency maps used beside incidents, changes, and vulnerability context |
- Immediate: faster incident scoping inside FCA-relevant reporting windows because exposure is a query.
- Medium-term: PCI scope confirmation becomes a controlled check against discovered inventory, not a multi-week project.
- Long-term: board-level assurance rests on evidence that can be reproduced after the next change weekend, not on a snapshot that aged out.
Getting started
- Inventory important business services and the documented CDE boundary as they stand today.
- Run discovery across on-premises and cloud environments to surface the gap between documented and actual.
- Build the dependency map that connects CIs to business services and to PCI-relevant paths.
- Connect the CMDB to the ITSM and GRC workflows already in use so the record is used, not only built.
- Set a review cadence that matches ongoing FCA mapping obligations and PCI 12.5.2 confirmation cycles.
Prove Resilience Mapping Against Runtime Truth
FCA operational resilience and PCI DSS both assume you can show what technology supports critical services and cardholder-data paths. London’s shared rails and hybrid estates make annual workbook maps a fragile answer. A discovery-sourced CMDB with ViVID™ dependency maps gives resilience and compliance teams a maintained record under those exercises. When you are ready to see that map on your own estate, start with the CMDB capability overview, or see it live: schedule a demo.
Frequently Asked Questions
What does the FCA’s operational resilience policy actually require firms to do?
Firms must identify important business services, set impact tolerances, map supporting resources including technology and third parties, and test severe but plausible scenarios. Mapping must stay current as the estate changes, not only for a one-time deadline.
Does Virima’s CMDB integrate with ServiceNow, Jira Service Management, or Ivanti for FCA and PCI evidence?
Yes. Virima’s CMDB syncs with ServiceNow, Jira Service Management, Ivanti, HaloITSM, and other ITSM platforms already used by London banking IT teams, so resilience and PCI evidence travels with existing change, incident, and asset workflows instead of living in a separate spreadsheet.
Why does London’s banking and payments sector face particular scrutiny on operational resilience?
London concentrates firms that share payment rails, cloud regions, and core vendors. Shared outages and dense third-party chains raise supervisory and customer impact quickly, so mapping quality is tested in public incidents as well as in assessments.
How fast can Virima build a first dependency map for FCA and PCI scoping?
Once discovery and service definitions are in place, Virima’s public claim is a first dependency map inside 60 minutes. Confirm that claim against current product materials and measure it against your own estate before relying on it for a specific compliance deadline.
Can one CMDB support both FCA operational resilience mapping and PCI DSS scoping?
Yes, when the CMDB is discovery-sourced and carries service and dependency relationships. It remains the infrastructure evidence layer under GRC and QSA work. It does not replace policies, testing programmes, or assessor judgment.
