---
name: fca-op-resilience-mapper
description: Map an SMB's current IT and operational controls to the FCA's operational-resilience expectations (PS21/3 and DORA-adjacent), identifying Important Business Services, impact tolerances, vulnerabilities, and a gap-closure plan.
version: 1.0.0
author: VantagePoint Networks
author_url: https://www.vpnetworks.co.uk
audience: IT Managers, CTOs, CISOs, Compliance Leads, COOs at FCA-regulated firms, MSPs serving finance-sector clients
output_format: Formatted Markdown assessment with IBS register, impact tolerance table, mapping matrix, severe-but-plausible scenarios, gap register, and board-ready summary.
license: MIT
last-reviewed: 2026-04
---

# FCA Operational-Resilience Mapper

A Claude Code skill for FCA-regulated SMBs translating PS21/3 (and the DORA-style controls increasingly expected in client assessments) into a concrete, evidence-backed operational-resilience assessment — not a 60-page document nobody will read.

## How to use this skill

1. Download this `SKILL.md` file.
2. Place it in `~/.claude/commands/` (macOS/Linux) or `%USERPROFILE%\.claude\commands\` (Windows).
3. In Claude Code, run `/fca-op-resilience-mapper`. Describe your firm in plain English. Answer the clarifying questions. Receive a structured assessment.

## When to use this

- Your firm has grown past the point where "we have a BCP" is enough and you need a proper operational-resilience framework.
- A client or counterparty has asked "what are your important business services and impact tolerances?" and you need an answer in writing.
- Your Board has asked for the operational-resilience position ahead of an audit or regulator visit.
- You're preparing for a supervisory conversation or SREP and want a document that shows structured thinking.
- You're a supplier TO a bank / insurer and their operational-resilience questionnaire lands on your desk.

## What you'll get

A single Markdown document containing:

- An **Important Business Service (IBS) register** with a rationale for each
- **Impact tolerances** per IBS in specific units (minutes/hours of downtime, volume, type of disruption)
- A **control mapping matrix** (your existing controls → FCA expectations → gap)
- **Severe-but-plausible scenarios** (cyber attack, key person loss, cloud outage, supplier failure) mapped to IBSes with tolerance impact
- A **resource-mapping view** (what people, processes, technology, facilities, third parties, data each IBS depends on)
- A **gap register** with specific, dated remediation items and owners
- A **board-ready one-page summary**
- A **testing schedule** for the year ahead
- A **recovery playbook** referencing your existing runbooks

## Clarifying questions I will ask you

1. **FCA authorisation type?** (e.g. MiFID investment firm, IFPR SNI/non-SNI, E-money, Payment Institution, Crypto)
2. **Headcount and key locations?**
3. **What's your revenue-generating activity in one sentence?**
4. **What services do you provide to customers?** (list the public-facing services)
5. **Which of those would cause customer harm or market integrity impact if disrupted?** (candidate IBSes)
6. **Do you have an existing BCP/DR document?** (yes, date of last review / no / in progress)
7. **Critical third parties?** (custodian, broker-dealer, market-data provider, cloud, managed service, licence reporting)
8. **Cloud posture?** (single region / multi-region / on-prem / hybrid)
9. **Do you already have impact tolerances articulated?** (yes / conceptually / no)
10. **Have you run severe-but-plausible testing?** (yes — when; no)
11. **Board reporting cadence?** (monthly / quarterly / annually)
12. **Scale for context?** (AUM, transaction volume, customers served — helps calibrate tolerances)

## Output template

```markdown
# Operational Resilience Assessment — <firm>

**Prepared:** <date> · **Owner:** <role> · **Review cadence:** annually + on material change
**Regulatory basis:** FCA PS21/3, SYSC 15A; aligned where practical to DORA principles

## 1. Executive Summary
<Half-page. What the firm does, the IBSes identified, overall resilience posture, top three gaps, proposed remediation budget.>

## 2. Scope & Approach
This assessment covers <entities in scope>. We identify Important Business Services, set impact tolerances, map resources and controls, test against severe-but-plausible scenarios, and maintain a remediation register.

## 3. Important Business Services (IBS) Register
An IBS is a service that, if disrupted, could cause:
- **Intolerable harm** to customers, or
- **Risk to market integrity** or **financial stability**.

| IBS # | Service | Rationale | Customer count | Harm if disrupted |
|---|---|---|---|---|
| IBS-1 | <e.g. Execute client equity orders> | <why it matters> | <N> | <harm type> |
| IBS-2 | <e.g. Produce and submit regulatory reporting> | <why> | <N> | <harm> |
| IBS-3 | <e.g. Client funds movement / settlement> | <why> | <N> | <harm> |

## 4. Impact Tolerances
For each IBS, the maximum duration / extent of disruption beyond which customer harm becomes intolerable.

| IBS | Impact tolerance | Rationale | Expressed as |
|---|---|---|---|
| IBS-1 | <e.g. 2 hours within market hours> | <market impact / client-agreed SLAs> | Minutes of unavailability within trading hours |
| IBS-2 | <e.g. 24 hours before regulatory deadline> | <SUP / reporting rules> | Hours to regulator deadline |
| IBS-3 | <e.g. End of business day> | <T+N settlement> | Settlement day-end |

## 5. Resource Mapping (per IBS)
For each IBS, the resources required to deliver it:

### IBS-1: <service>
| Resource type | Specific item | Owner | Single point of failure? |
|---|---|---|---|
| People | <named roles / desks> | | |
| Processes | <documented process ref> | | |
| Technology | <systems, databases> | | |
| Facilities | <office, DC, alt-site> | | |
| Third parties | <supplier, broker, cloud> | | |
| Information / data | <market data, client records> | | |

(Repeat per IBS.)

## 6. Control Mapping Matrix
| FCA expectation | Your current control | Evidence | Gap |
|---|---|---|---|
| Identify IBSes | §3 above | This document | None |
| Set impact tolerances | §4 above | This document, board minutes <date> | None |
| Map resources | §5 above | This document, asset register | <partial?> |
| Test severe-but-plausible scenarios | <details> | Test report dates | <if not done> |
| Invest in resilience where needed | Budget <line item> | Board papers | <list> |
| Communicate with customers & regulators during disruption | Comms plan at <ref> | Drafts + past exercise | <gaps> |
| Self-assess annually, Board approval | This document | Board minutes | — |

## 7. Severe-But-Plausible Scenarios
For each scenario: how it impacts each IBS, whether impact tolerances would be breached, the current response, and identified remedies.

### S1: Ransomware compromise of primary IT estate
- **Immediate impact:** <systems affected>
- **IBS impact:** IBS-1 breached tolerance after <N> hours; IBS-2 at risk
- **Current response:** <IR runbook, backup restore approach>
- **Likely recovery time:** <N> hours
- **Tolerance breach?** Yes / No
- **Remedy:** <specific investment/action>

### S2: Cloud provider regional outage (<cloud> <region>)
- **Immediate impact:** <systems in that region unavailable>
- **IBS impact:** <>
- **Current response:** <failover / wait-out / degraded-ops>
- **Tolerance breach?**
- **Remedy:**

### S3: Loss of key operations staff (flu, resignation, incapacity)
- **Impact:** <processes requiring specific people>
- **IBS impact:** <>
- **Current response:** <cover arrangements, documented procedures>
- **Tolerance breach?**
- **Remedy:**

### S4: Critical third-party failure (custodian / broker / data vendor)
- **Impact:**
- **IBS impact:**
- **Current response:**
- **Tolerance breach?**
- **Remedy:**

### S5: Power / facility loss at primary office
- **Impact:**
- **IBS impact:**
- **Current response:**
- **Tolerance breach?**
- **Remedy:**

## 8. Gap Register
| Gap | Severity | Remediation | Cost estimate | Owner | Target date |
|---|---|---|---|---|---|
| <e.g. No documented third-party exit plan for custodian> | High | Draft exit plan, tabletop with finance team | £<N> | COO | <Q> |
| <e.g. Backup restore never tested end-to-end at scale> | High | Schedule quarterly restore test; automate verification | <internal> | IT Manager | <Q> |
| <e.g. Cloud region lock-in for IBS-1> | Medium | Multi-region design assessment | £<N> | CTO | <Q> |

## 9. Testing Schedule (next 12 months)
| Month | Test | Scenario | Observers | IBS covered |
|---|---|---|---|---|
| <M1> | Tabletop | S1 Ransomware | Board member + Compliance | IBS-1, IBS-2 |
| <M3> | Backup restore | Technical drill | IT + Audit | IBS-2 |
| <M6> | Third-party failure | S4 | COO + Compliance | IBS-3 |
| <M9> | Comms exercise | Customer & regulator notification | MD + Legal | All IBSes |
| <M12> | Full review & update | — | Board | All IBSes |

## 10. Board-Ready One-Page Summary
> **Operational Resilience at a glance — <firm> — <date>**
>
> **IBSes:** <N> identified. <N> breached tolerance in severe-but-plausible testing.
> **Top gaps:** (1) <gap>, (2) <gap>, (3) <gap>.
> **Remediation budget:** £<N> over <N> months.
> **Next milestone:** <what + when>.
> **Overall posture:** <Adequate / Developing / At-risk> with a defensible plan to reach <target state> by <date>.
> **Board decision required:** Approve remediation budget; approve impact-tolerance numbers; approve next testing schedule.

## 11. Recovery Playbook Index
This document is not a runbook — it identifies which runbooks must exist and stay current. Maintained separately:
- Incident Response Runbook — IBS-1, IBS-2
- Disaster Recovery Runbook — all IBSes
- Ransomware Readiness Playbook — S1
- Third-Party Failure Playbook — S4
- Customer Comms Runbook — all scenarios
```

## Example invocation

**User:** "28-person FCA-regulated IFPR SNI investment adviser. We manage £180m AUM. Platform relationship with Vanguard (execution), Pershing (custody). We use M365, Xero, our own CRM, and an outsourced IT provider. Board asking for operational-resilience paper before next audit in 4 months."

**What the skill will do:**
1. Ask the 12 questions, drilling on: whether client-onboarding is an IBS (borderline — generally not unless part of ongoing service), market-hours specifics for investment-advice IBS, and the concentration risk on Pershing/Vanguard.
2. Produce the assessment identifying 3 IBSes: (1) provide investment advice and place orders via execution broker, (2) produce and issue client valuations/reports, (3) maintain records for regulatory reporting.
3. Set impact tolerances: IBS-1 = 2 hours intra-day, IBS-2 = end of business day, IBS-3 = 48 hours.
4. Flag gaps: no tested third-party-exit plan for Pershing; MSP contract lacks tested DR; M365 has no tested secondary mailbox-restore path.
5. Produce a testing schedule starting with an April tabletop on "Pershing unreachable for 6 hours" and a June ransomware drill.
6. Generate the one-page Board summary as the starting point for the Board paper.

## Notes for the requester

- **Identify fewer IBSes, not more.** The FCA expects a small number of truly important services, not every internal function dressed up. Most SMB firms land on 2-4 IBSes.
- **Impact tolerances must be specific and defensible.** "Reasonable" is not a tolerance. "2 hours within market hours" is.
- **Test at least one severe-but-plausible scenario per year per IBS.** Untested resilience is a hypothesis, not a control.
- **Third-party concentration is the #1 finding** in most SMB finance assessments — a single custodian, a single cloud region, a single IT supplier. Have the exit conversation BEFORE you need it.
- **This is a living document.** Material change (new service, new key supplier, new regulator guidance) triggers an interim review, not just the annual.
- **Good looks like:** Board approves the paper, the remediation budget is realistic (£10-50k for most SMBs over 12 months), and a supervisor asking "what are your IBSes?" gets a sharp answer with backing evidence in under 30 seconds.

---
*VantagePoint Networks · <https://www.vpnetworks.co.uk> · Authored by Hak · Free under the MIT licence*