Operational Resilience Critical-Service Dependency Crosswalk: Reconcile Processes, Systems, Vendors, Facilities, and People

TL;DR

• A critical-service crosswalk reconciles five separate dependency inventories—processes, systems, vendors, facilities, and people—under a shared service ID, so your resilience program has one source of truth instead of five competing lists
• FCA and PRA supervisory reviews in 2026 are examining whether firms’ dependency maps were actually challenged, tested, and maintained—not just produced for the initial policy deadline
• DORA requires financial entities to maintain ICT asset registers mapping third-party services to critical functions; the crosswalk satisfies both UK and EU obligations from a single evidence base
• The most common failure mode is fragmented ownership: IT, vendor management, HR, and facilities each maintain their own lists, but nobody reconciles them to a specific critical service

Every operational resilience program produces inventories. The IT team has a CMDB. Vendor management has a supplier register. HR has a key-person succession list. Facilities has a site inventory. The BCM team has a process map.

What most programs don’t have is a document that reconciles those inventories against a specific important business service, using a shared identifier, with a single owner and a coherent tolerance.

That’s the critical-service crosswalk. And without it, your resilience program is built on five parallel lists that were never designed to speak to each other.

When an FCA supervisor pulls a thread—“show me the full dependency picture for your payment processing service”—they’re not asking for your CMDB. They’re asking for a reconciled artifact that traces that service through every resource layer: the processes that deliver it, the systems that support it, the vendors that underpin those systems, the facilities it depends on, and the people who own it.

If you have to assemble that answer live in a supervisory meeting, you’re already in a difficult position.

What Regulators Are Actually Requiring

FCA and PRA (UK)

Under FCA SYSC 15A and PRA SS1/21, firms must:

• Identify important business services (IBS)—services where disruption would cause significant harm to consumers or financial markets
• Map each IBS to the underlying resources that deliver it, across five categories: people, processes, technology, facilities, and information
• Set impact tolerances defining the maximum disruption duration before harm becomes unacceptable
• Conduct scenario testing to demonstrate that tolerances can be met
• Maintain self-assessments documenting current resilience position

The March 2026 FCA observations report made clear that regulatory patience for “in progress” has run out. Firms are now expected to demonstrate operationalized resilience, not planned intent.

FCA’s published observations identified specific mapping weaknesses: firms that stopped at the application layer, didn’t integrate facilities and people into IBS maps, and hadn’t updated maps after material changes. These aren’t minor deficiencies—they undermine the entire self-assessment.

DORA (EU)

DORA requires financial entities to:

• Maintain a register of ICT assets supporting critical or important functions
• Map ICT third-party service arrangements to those functions
• Assess concentration risk across critical third parties
• Maintain contractual arrangements with specific oversight rights

For firms with both UK and EU obligations, maintaining separate evidence bases is operationally inefficient. A crosswalk designed to satisfy both regimes—mapping five dependency layers for each critical service, with third-party ICT arrangements integrated—creates one audit-ready artifact rather than two parallel workstreams.

The FCA/PRA vs. DORA comparison guidance is explicit: apply the stricter of the two regimes’ requirements, and design the evidence base to satisfy both. DORA’s contractual and ICT register requirements are generally more prescriptive; UK mapping requirements for people and facilities are generally more granular.

New incident reporting requirements—FCA PS26/2 and PRA SS1/26—come into force March 2027. A current, accurate crosswalk is a precondition for accurate incident reporting: you can’t report on “which important business services were affected” if you haven’t mapped services to their dependencies.

The Five Dependency Layers

Every critical-service crosswalk is built from the same five source inventories:

The crosswalk artifact joins these layers using the critical service as the organizing unit—not IT ticket numbers, vendor contract IDs, or org chart positions.

How to Build the Crosswalk

Step 1: Confirm Your Critical-Service List

Your important business services (FCA/PRA terminology) or critical functions (DORA terminology) are the organizing unit for the crosswalk. Before mapping dependencies, confirm:

• Which services are on the list, and why
• The impact tolerance set for each
• The primary owner for each service
• Any recent material changes to the service scope

If your IBS list hasn’t been reviewed since the original policy submission, it needs to be current before the crosswalk is built. Services are added (new products), removed (discontinued lines), or scoped differently as the business changes.

Step 2: Assign Shared Service IDs

Create a naming convention for critical-service IDs that can be used across all five inventory sources. Example: CS-PAY-001 for the payment processing service.

These shared IDs are what make the crosswalk possible. Without them, IT calls the same service “Payment Gateway App,” vendor management calls it “PSP Contract - Stripe,” and the BIA calls it “Transaction Processing.” The crosswalk reconciles those labels under a single ID.

Shared IDs also enable:

• Change management: when any dependency changes, it can be traced to affected services
• Testing evidence: scenario test results can be filed against specific service IDs
• Audit traceability: examiners can trace from a regulatory obligation to a specific service to its full dependency picture

Step 3: Conduct a Structured Source-Inventory Pull

For each critical service, pull the relevant records from all five source inventories. This typically requires coordinators in each domain—IT, vendor management, HR, facilities, and BCM—to confirm the current records for that service.

Do not rely on the BCM team doing this in isolation. The crosswalk’s value comes from cross-functional ownership; if BCM populates it alone, you’re rebuilding the siloed-list problem in a different format.

A useful workshop structure: send each domain owner a service-specific information request (e.g., “For CS-PAY-001, Payment Processing: list the systems, vendors, facilities, and key roles that directly support this service”). Collect responses, normalize them, and draft the crosswalk row. Then bring domain owners together to challenge each other’s entries.

Step 4: Identify Single Points of Failure

For each dependency layer, flag entries that represent a single point of failure—a dependency with no documented backup or alternative:

• Systems: An application with no failover instance, or a dependency on a third-party API with no manual workaround
• Vendors: A vendor providing a service for which there’s no alternative supplier and no contractual exit plan
• Facilities: A site that houses a function with no backup location
• People: A role where one named individual holds all operational knowledge with no documented succession

Single points of failure don’t automatically mean your tolerance will be breached—but they’re the entries that require documented treatment plans, not just acknowledgment.

Step 5: Map to Tolerances and Vulnerabilities

For each critical service, record:

• The impact tolerance (the maximum acceptable disruption duration)
• Whether the current dependency picture is within tolerance based on scenario testing
• Any known vulnerabilities—dependencies that could cause a tolerance breach under a plausible stress scenario
• Open remediation items with owners and due dates

This is where the crosswalk connects to your scenario testing and self-assessment. The FCA’s operational resilience observations specifically noted that firms’ scenario testing was weakest when the test didn’t trace through the dependency map—testers assumed capabilities that the map showed were single-threaded.

Step 6: Document Change-Event Rules

Define when the crosswalk triggers an update:

• New vendor contract or vendor change for a mapped dependency
• System migration or major upgrade
• Facility change (new site, site closure, capacity reduction)
• Key-person departure with no documented succession
• New product or service added to the IBS list
• Tolerance breach or near-miss in a test or live event

Without explicit change-event rules, crosswalks become stale between annual reviews. Material changes happen faster than annual cycles in most organizations—a vendor transition, a key hire departure, a cloud migration. The crosswalk that was accurate in January is not necessarily accurate in August.

The Crosswalk Record Format

A crosswalk row captures, at minimum:

The record doesn’t need to replicate all source-inventory data—it needs to link to it by shared ID and capture the crosswalk-specific fields: vulnerabilities, tolerance status, and change records.

What Good Looks Like vs. What Examiners Actually Find

Based on FCA supervisory observations and published DORA examination guidance:

The FCA’s March 2026 observations report noted that the firms with the strongest evidence positions were those where mapping was genuinely operational—used in change management, in testing design, and in incident response—not filed as documentation for the original deadline and left alone.

The Downstream Connections

The crosswalk is not an end in itself. It feeds:

BIA updates. The IT systems dependency mapping underlying a BIA needs to be consistent with the crosswalk. If the crosswalk identifies a new single point of failure in the vendor layer, the BIA’s recovery assumptions for that service need to be revisited.

Scenario testing. Effective scenarios test the actual dependency architecture, not a hypothetical one. The crosswalk defines which vendors to include in a supply-chain outage scenario, which systems to simulate as unavailable in a cyber-incident scenario, and which facilities to exclude in a geographic disruption scenario.

Vendor oversight. For vendors mapped to critical services, the crosswalk informs the oversight intensity in your TPRM program. A vendor on the crosswalk for five critical services requires a different oversight posture than one on the crosswalk for a single non-critical service.

Third-party incident response. When a vendor has an outage, the crosswalk answers “which of our critical services are affected?” without requiring a manual search through separate inventories. That 72-hour window in which you need to assess impact and notify the board and relevant regulators is much harder to manage if the dependency picture isn’t pre-assembled.

So What?

Five inventories maintained in five different systems, owned by five different teams, with no reconciliation artifact, is not operational resilience. It’s operational documentation that happens to cover the same topics.

The crosswalk is the reconciliation artifact. It takes the IBS list as the organizing unit, links every dependency layer using shared IDs, assigns one owner per service, captures vulnerabilities and tolerance status, and triggers updates on material changes.

For FCA and PRA reviews, it’s the evidence that mapping is operational. For DORA compliance, it’s the ICT asset register mapped to critical functions. For your board, it’s the answer to “do we know what we depend on and what happens when those dependencies fail?”

Building the crosswalk takes time. The structured source-inventory pull, the domain-owner workshops, the single-point-of-failure review, the change-event rules—this isn’t an afternoon project for a solo BCM analyst. But it’s faster than assembling the answer live in an FCA supervisory meeting from five systems that were never designed to speak to each other.

Get it built before someone asks to see it. Then keep it current as if someone is about to ask to see it again.

The Business Continuity & Disaster Recovery Kit includes dependency mapping templates and structure for linking BIA findings, recovery objectives, and vendor dependencies to critical business services.