Operational Resilience One Year On: What the Data Demands and How to Meet It

The FCA’s most recent operational resilience update made the position clear: resilience is not static, and scenarios that seemed implausible are now plausible. Regulators have moved from asking firms to be resilient to demanding they prove it through live reporting, stress testing that reflects actual operational complexity, and asset data granular enough to survive scrutiny.

With PS7/26 now active in the UK and DORA fully enforceable across the EU, businesses operating within both regimes face a compounding challenge. The obligations differ in detail but converge on the same dependency: the quality and connectedness of your technology asset data.

Get that foundation wrong and every reporting obligation built on top of it is compromised.

The 24-hour reporting window needs live data

PS7/26 introduces a strict 24-hour notification window for major operational incidents. DORA imposes comparable obligations with even tighter initial thresholds for ICT-related disruptions. The question isn’t whether your incident team can draft a notification in that time. It’s whether they can assess the impact accurately.

That assessment depends entirely on knowing which business services run on which infrastructure. If your Configuration Management Database is a static inventory that gets updated quarterly, your incident team is working blind when it matters most. They can’t determine which Important Business Services are affected or establish whether impact tolerances have been breached. And they certainly can’t give regulators the specificity PS7/26 demands.

ServiceNow’s CMDB solves this when it’s treated as operational infrastructure rather than an IT asset list. Service Mapping traces live relationships between assets and business services. Auto-discovery scans the network continuously, logging servers, databases, and cloud instances without manual input. Between them, they keep asset data current enough to answer the question regulators are asking: what broke, and what does it affect?

That same data gap undermines your regulatory registers

Incident reporting is the most visible pressure point, but fragmented asset data creates just as much exposure in your supply chain obligations. The UK’s Material Third Party reporting regime and DORA’s ICT Asset Register both demand a level of transparency that most firms can’t produce from what they currently hold.

Under PS7/26, firms must notify the PRA of all MTP arrangements and submit an annual register via RegData. DORA extends that to a granular register of all ICT third-party providers, sub-contractors included, along with any shadow IT your procurement team may not have documented.

Most firms maintain these as separate exercises, and that creates regulatory drift. You end up reporting different things to different agencies because the source data doesn’t reconcile. If your technology asset data doesn’t track software versions, dependencies, and contract terms in one place, your MTP register will be incomplete. Your DORA ICT register will contradict it.

The practical fix is a single data model that serves both. In ServiceNow, the MTP register and DORA ICT register can pull from the same source. One data model, two reporting outputs. Otherwise, the alternative is two teams keeping parallel spreadsheets and hoping they agree.

Regulators want proof it holds together under pressure

Accurate data and unified registers address the reporting obligations. Regulators are now asking a harder question: does your resilience actually hold when something breaks?

The PRA is rejecting stress tests that don’t account for interconnectivity. They want to see how a failure in a single component cascades across dependent services and third parties. DORA’s Threat-Led Penetration Testing requirements go further, demanding evidence that firms understand their full attack surface.

A tabletop exercise built around one server going down doesn’t satisfy either regime anymore.

This kind of testing is data-hungry. You need a precise inventory of hardware, software, and firmware versions. You need to understand upstream and downstream dependencies and connect them to the Important Business Services you’ve mapped and set tolerances against.

ServiceNow’s Business Service Mapping within BCM handles the criticality linkage here. Business Impact Assessments determine RPO, RTO, and criticality ratings. Service mapping data then shows which Important Business Services sit upstream of any given asset, so when something fails, the team knows immediately what to prioritise.

The compliance deadline was a starting gate

Live data for incident reporting, unified registers for regulatory transparency, and connected service maps for credible stress testing. These three workstreams are the same requirement expressed differently: technology asset data that is accurate, connected to the business services it supports, and kept current.

The organisations getting this right have stopped treating their CMDB as a static inventory. They’ve unified regulatory registers into one data model and connected criticality assessments directly to the services regulators care about. While those still relying on quarterly refreshes and disconnected spreadsheets are building up risk they’ll eventually need to explain.