SYSC 15A (operational resilience)

SYSC 15A introduced operational resilience requirements for FCA-regulated firms. In force from 31 March 2022 with a transitional period to 31 March 2025 [checked 2026-05-08, FCA PS21/3 "Building operational resilience" inserted SYSC 15A with effect from 31 March 2022 and required firms to be operating within their impact tolerances by 31 March 2025; confirmed via Sidley, Complyport, and FCA secondary sources], it requires firms to identify Important Business Services, set impact tolerances, and remain within those tolerances through severe-but-plausible disruption.

For principal firms with AR networks, the rule is consequential because an AR’s activity may materially support an Important Business Service. Where it does, the AR’s resilience posture is the principal’s resilience posture.

What SYSC 15A requires

The three core obligations:

1. Identify Important Business Services. Services whose disruption would cause intolerable harm to consumers or pose risk to market integrity.
2. Set impact tolerances. The maximum tolerable level of disruption for each service, expressed in time, scope, or both.
3. Remain within tolerance through severe-but-plausible scenarios. The firm must test its ability to deliver each service within tolerance under plausible disruption, including third-party failure, cyber incident, and personnel loss.

The principal’s resilience register lists every Important Business Service, its impact tolerance, the scenarios it has been tested against, and the dependencies (technology, third parties, ARs) that support it.

The supportsImportantBusinessService flag

Where a principal designates an AR’s activity as supporting an Important Business Service, that designation is captured on the appointment record:

supportsImportantBusinessService: boolean;  // SYSC 15A flag

The flag is editable only by users with the principal-admin role and every change emits an audit event. The product surfaces:

• A “supports IBS” tag on the AR detail header.
• A filter on the AR register list (“show only IBS-supporting ARs”).
• Inclusion in the resilience register surface (engineering-spec depth in v1).
• A higher weighting in the risk model for breach severity, because a breach in an IBS-supporting AR has resilience implications beyond the conduct dimension.

Resilience-relevant breaches on the triage queue

The breach triage queue surfaces resilience-relevant breaches with a distinct severity flag. A breach is resilience-relevant if either:

• The originating AR has supportsImportantBusinessService: true, and the breach category indicates a service disruption (operational failure, data protection incident, key person loss).
• The breach narrative explicitly references an Important Business Service even if the AR is not formally tagged.

The distinct flag exists because the SUP 15 timing and the resilience escalation route are both engaged. A resilience-relevant breach typically routes to immediate notification under SUP 15.3.11R and triggers a parallel internal escalation to the resilience function. The breach detail page renders both routes side by side.

Severe-but-plausible scenarios

SYSC 15A scenario testing is not in the v1 product surface. The engineering spec documents how AR-level incident data feeds into scenario selection at the principal level, but the scenario library and the testing workflow itself are out of scope for v1.

What is in scope: AR-level incident reporting feeds the principal’s incident log, which is one of the inputs to scenario design. The breach log, the conduct events log, and the AR availability indicators (where captured via MI returns) all contribute.

Cross-links

• SUP 15 for the breach reporting timing regime, and the distinct severity flag carried on the breach triage queue.
• Audit-as-evidence for the audit chain that records every change to the IBS flag.
• The architecture section’s resilience register page (engineering spec depth) for the data model linking ARs to Important Business Services.