Operational resilience software helps a bank meet the UK operational resilience rules in one place: it holds the important business services and their impact tolerances, maps each service to the people, processes, technology, facilities, information and suppliers behind it, plans and records scenario tests, tracks remediation, and produces the self-assessment the board approves. Whichever product a bank chooses, it does not create those facts; it reads them from records the bank already keeps, in a configuration database, a third-party register, continuity plans, runbooks, test and incident reports, contracts and payment systems. That is why the inventory of those records, and how far they agree with each other, decides when a programme can start more than any feature list does. Botminds' Operational Resilience Management is an agentic solution that runs on exactly those records: its agents read them, compare them and cite them, and people confirm, check and sign what the agents find.
The examples come from the solution's fictional sample bank, Corvane Bank UK, with 11 important business services and 38 material third parties. The rules are quoted and linked where they appear.
The inputs operational resilience software runs on: the minimum to start, and the ideal
| Input | Minimum to start | Ideal | What it feeds |
|---|---|---|---|
| Service list and tolerances | The board-approved list and current tolerances, with their rationale | Plus the harm analysis and customer metrics behind each tolerance | Every view; the self-assessment, records 1 and 2 |
| Service maps | Last year's maps for one important business service, in any format | Versioned maps with an owner and confirmation date for each service | Mapping (SYSC 15A.4); scenario design |
| CMDB or asset inventory | An export of applications and servers behind the first service | Read access with change records, refreshed nightly | Keeping technology in the maps current |
| Third-party register | Material suppliers with the services they support and contract owners | Plus hosting locations, sub-processors, exit plan status and assurance dates | Concentration, exit plans, the annual register |
| Continuity plans and runbooks | Current versions for the first service | All plans and runbooks, with version history | Recovery steps; mapping of people and facilities |
| Test and exercise reports | The last failover or recovery test for the first service | All tests in 12 months, with step timings | Timing recovery from evidence |
| Incident records | Major incidents in the last 12 months, with timelines | Live feed from the incident system | Recovery evidence; lessons learned; the disruption clock |
| Contracts | Schedules for notification, recovery and exit with the first service's suppliers | All material supplier contracts | Supplier steps in a scenario |
| Transaction volumes | One typical and one peak day for the first service, in aggregate | Hourly aggregates from the payments hub and core system | Counting customer harm |
What does operational resilience software do?
It keeps the records the rules require current and connected, and turns them into decisions and a document. The FCA's rules ask for five things a spreadsheet struggles to keep consistent over a year: identified services and tolerances, kept under review; maps good enough to find vulnerabilities and fix them; a testing plan and tests; lessons learned and improvements; and the written self-assessment, each version kept for six years (SYSC 15A.2 to 15A.6).
Products on the market approach this from different starting points. Some are registers and workflows: forms for each service and test, with approvals. Some are dependency-mapping tools that draw the service from configuration data. Some focus on exercises and testing. The newer approach reads the bank's existing evidence and assembles the record from it. The question that separates them for a buyer is the same: when a supervisor asks where a recovery time came from, does the software answer with a document, or with a field someone typed?
What data does operational resilience software need?
It needs the nine inputs in the table above, but it needs very few of them complete on the first day. One important business service can run end to end on last year's map, its current continuity plan and runbook, its most recent failover test, the past year's incidents, its suppliers' contract schedules and two days of volumes. The rest arrives service by service.
The inputs most often missing are the ones that make recovery times defensible: step-level timings from tests, and incident timelines precise enough to say when each phase ended. The FCA has told firms that testing should move on from judgement and desk exercises to tests that produce measured data, naming "disaster recovery/fail over tests" and "lessons learned from real scenarios" (FCA, May 2024). If those reports record only start and finish, the first improvement is to the test template, not the software.
What a usable test report gives the software: a duration for every step
Do you need a CMDB for operational resilience?
No rule requires one, but the technology part of every map has to come from somewhere, and a configuration database is usually the most current source. SYSC 15A.4.1R requires a firm to "identify and document the people, processes, technology, facilities and information necessary to deliver each of its important business services", and the PRA expects firms to develop "their own methodology and assumptions for mapping" in a form that is "accessible and usable" and proportionate to their size (SS1/21, 5.8).
The trap is to treat the CMDB as the map. The FCA's 2026 review found maps built mostly around technology and asked firms to add facilities, people, processes, information, and the resilience and test results of third parties (FCA, March 2026). A CMDB says which servers run the payments hub; it does not say that two of three people certified to run the night shift have moved team. In the sample bank, nine map differences waiting for their owners came from four sources, and only two of them were technology.
Nine map differences found across four systems of record, by kind
How do you import a third-party register into operational resilience software?
Import it with the fields that let a supplier be placed on a service map, not just in a contract list: the important business services each supplier supports, where it hosts and from which region, its own material subcontractors, its exit plan and when that was tested, and the dates its assurance evidence expires. The PRA expects firms to know how far they rely on their suppliers' own subcontractors (SS1/21, 5.6), and the FCA found after the July 2024 software outage that firms which had mapped their suppliers, and their suppliers' suppliers, in detail saw their exposure quickly (FCA, October 2024; the critical third parties guide quotes both).
There is now a template worth aligning to. From 18 March 2027, banks must notify the FCA before entering into or significantly changing a material third-party arrangement and submit a register of those arrangements every year; the FCA expects to open the first submission window at the end of the 12-month implementation period, with 90 calendar days to file the register (FCA, reporting material third party arrangements; PS26/2). An internal register built to that template serves both the map and the regulator.
A third-party register that knows where each supplier hosts
The minimum set and the ideal set
A programme can start on the minimum and grow toward the ideal, but it should know which it is running on, because the difference shows up as estimates in the self-assessment. The comparison below is what changes for one service as its inputs improve.
One important business service on the minimum inputs, and on the ideal ones
Running on the minimum: Last year's map, re-confirmed by the owner once
Running on the ideal: Compared nightly with four systems; differences proposed with sources
Running on the minimum: Some steps timed from the last test; the rest labelled estimates
Running on the ideal: Every step timed from evidence under 12 months old
Running on the minimum: Two days of volumes: one typical, one peak
Running on the ideal: Any day replayed hour by hour, counts only
Running on the minimum: Contract owner and services supported
Running on the ideal: Hosting region, sub-processors, exit test date, assurance expiry
Running on the minimum: Sections drafted with estimates flagged
Running on the ideal: Every statement cited; a section flagged when its evidence changes
Can spreadsheets meet SYSC 15A?
Yes, the rules do not require software, and a firm with a few important business services and simple suppliers can comply with well-kept spreadsheets. SYSC 15A asks for "sound, effective and comprehensive strategies, processes and systems", "proportionate to the nature, scale and complexity of the firm's activities" (SYSC 15A.3.1R and 15A.3.2R), and the PRA lets firms document mapping in a way proportionate to their size.
Spreadsheets fail on four duties that grow with scale. Retention: "each version" of the self-assessment records for six years, which a shared file overwritten through the year does not keep. Ownership: the FCA's 2026 review credits named ownership of mapping data with keeping it current, and a cell has no owner. Separation: nothing stops the person who ran a test from marking it passed. Freshness: a map in a workbook is correct on the day it was confirmed and drifts from then, a problem a nightly comparison exists to solve.
What operational resilience software features actually matter?
The features that matter are the ones that make the record defensible, not the ones that make it look complete. A heat map of services and a library of scenario templates are easy to demonstrate and do little for the next supervisory question. The checklist below is the set we would test on any product, ours included.
Nine features to test in operational resilience software, on your own records
- Every recovery time opens its source.
One click from a minute to the test report, incident timeline, runbook or contract passage.
- Evidence has an age, and old evidence is flagged.
A rule you set, such as 12 months, after which a step becomes an estimate.
- Maps are versioned with an owner and a confirmation date.
And differences from the systems of record are proposed, not applied.
- The person who runs a test cannot sign it.
Enforced for tests, map changes, tolerance changes and remediation items.
- Suppliers are mapped by where they host, not only by contract.
Including their own subcontractors, so a shared failure point is visible.
- Harm is counted from real volumes, in aggregate.
Any day replayable, with customers counted and never named.
- Remediation items carry an owner, a date, funding and an acceptance.
And fixes are re-tested on the same scenario before closure.
- Each version of the self-assessment is kept.
With what changed since the last version, and who approved it.
- Internal audit can export the evidence itself.
A pack with every version and its sources, customer data reduced to counts.
How long does it take to implement operational resilience software?
The first important business service takes as long as it takes to gather its minimum inputs; the rest of the programme takes as long as its records take to agree. That is not an evasion: configuring the software is the smaller task, while the first comparison of a CMDB, a supplier register and a set of runbooks usually produces a backlog of disagreements that only service owners can resolve. A realistic plan starts with one service, runs it end to end, and adds services as their owners clear their differences.
A useful sequence is the one the rules imply. Load the board-approved services and tolerances. Run the first service's map against its sources and let its owner confirm the differences. Time its most recent scenario from the evidence that exists, and see which steps are estimates. Count harm on one typical and one peak day. Then compare the result with what last year's self-assessment said about the same service. The gap between the two is the strongest argument for or against the purchase.
How to evaluate operational resilience software vendors
Evaluate on one of your own services and last year's self-assessment, not on the vendor's sample. Give each shortlisted product the same inputs for the same service and ask three questions of the output: which recovery minutes does it say are proven, and can you open the evidence; what did it find in your records that your team did not know; and what will it never do without a person. A product that cannot answer the third in writing has not drawn its limits.
Two procurement questions follow from the rules. Where does the product host, and with whom, because a resilience tool is itself a dependency that belongs in your map and, if material, in your register from 2027. And can you take every version of your records out in a usable form, because the six-year retention duty is yours, not the vendor's.
Where Operational Resilience Management fits, and where it does not
It fits a bank under SYSC 15A and SS1/21 that has its records in several systems, wants every recovery time and statement tied to evidence, and wants agents to do the comparing, timing, counting and drafting while its people keep every decision. Its agents read the CMDB, the third-party register, the continuity system, the incident system, the payments hub and core banking volumes in aggregate, and the libraries of tests, runbooks and contracts; they map, time, count and draft; service owners confirm, the head of operational resilience checks, and the SMF24 accepts.
It fits less well where the evidence does not exist yet. A bank with no failover tests will get honest estimates, not proven minutes, until it runs some. A firm with two or three simple services may not need more than disciplined spreadsheets. And a US bank working to the interagency sound practices rather than SYSC 15A would configure its own framework rather than the UK sections. What each agent does and never signs covers the limits in detail; to try it on one of your own services, start from Operational Resilience Management.
Questions people ask
What is the best operational resilience software?
The one that answers a supervisor's question with a document. Test any product on one of your own important business services: it should show which recovery minutes are proven and open the evidence for each, keep every version of the self-assessment for six years, and stop the person who ran a test from signing it.
What is the difference between operational resilience software and business continuity software?
Business continuity software manages plans and exercises for recovering the firm's own operations. Operational resilience software works from the customer outward: important business services, impact tolerances set by harm, maps, scenario tests against those tolerances, and the board's self-assessment under SYSC 15A. Continuity plans are one of its inputs.
Can operational resilience software build the service maps for us?
It can propose them from your systems of record, and keep them current, but a person has to confirm them. SYSC 15A.4.1R requires the firm to identify and document the resources; the FCA's 2026 review credits clear ownership of mapping data, which means a named service owner confirming each change.
Does operational resilience software need customer data?
To count harm it needs transaction volumes, but only in aggregate: payments, value, customers and customers with a support need, counted by hour. In the sample bank, no customer-level data leaves the payments hub and no customer is named on any screen.
Will operational resilience software cover the FCA's 2027 third-party register?
It should hold the data the register needs, since the same supplier facts feed the service maps. From 18 March 2027 firms must notify new or significantly changed material arrangements and submit the register annually; check that a product can export to the FCA's template.
Is operational resilience software needed for DORA as well?
Banks with EU entities also answer to the EU's Digital Operational Resilience Act, which EIOPA notes "entered into application on 17 Jan 2025" and which the EBA describes as setting rules on ICT risk management, incident reporting, resilience testing and ICT third-party risk. Its requirements are not the same as SYSC 15A's, so check a product's coverage of each separately.