Structuring an Operational Resilience Self-Assessment That Satisfies SS1/21

The March 2025 deadline has passed, but SS1/21 self-assessments are now living documents under active supervisory review. The PRA is no longer testing whether firms can identify important business services and set impact tolerances. It is testing whether the self-assessment tells the truth about what would actually happen in severe but plausible scenarios, and whether the firm knows what it depends on. That second question is where most self-assessments quietly fall apart, because mapping honestly exposes third-party chains the firm has never formally documented.

Key Executive Takeaways

• Your self-assessment must evidence how you have tested impact tolerances against severe but plausible scenarios, not just declared them, and the PRA reads gaps in scenario coverage as gaps in capability.
• Undocumented third-party and intragroup dependencies are the single largest source of self-assessment fragility; you need a defensible process for surfacing them rather than a claim they do not exist.
• The board narrative should lead with vulnerabilities and remediation timelines, not with green ratings; supervisors interpret over-assurance as immaturity.

Start With the Service, Not the System

The most common structural mistake is building the self-assessment around technology assets or business lines rather than the important business service itself. Each service section should open with the end-to-end customer or market outcome, then move outward through the process, people, technology, facilities, information, and third-party layers that support it. This ordering forces mapping discipline and makes gaps visible. If your mapping starts with an application inventory, you will document what you already know and miss what you do not.

Impact Tolerance Evidencing: Where Firms Get Marked Down

SS1/21 expects impact tolerances to be set at the point beyond which intolerable harm crystallises. The PRA's reviews have highlighted three recurring weaknesses:

• Tolerances expressed only in time (e.g., 24 hours) without volume, value, or customer-segment dimensions.
• No articulation of the harm curve, meaning the assumption that harm accrues linearly when in practice it steps up sharply at specific thresholds.
• Scenario testing that validates the tolerance rather than stresses it. If every scenario concludes the tolerance holds, the scenario set is too narrow.

Good practice is to include at least one scenario per service that breaches the tolerance, with a clear account of what the firm would do, who decides, and what the residual harm looks like. Supervisors want evidence of thinking, not evidence of comfort.

The Third-Party Problem

The uncomfortable reality: most firms have material dependencies on fourth and fifth parties that no single function owns. Cloud sub-processors, outsourced print, payment message routing, sanctions screening feeds. A rigorous mapping exercise will surface these, and once surfaced they must be addressed in the self-assessment or the document becomes actively misleading.

The answer is not to avoid mapping. It is to sequence disclosure alongside remediation. Before the self-assessment is finalised:

1. Run the mapping to fourth-party level for each important business service.
2. Log every dependency that lacks a contractual right, exit plan, or substitutability assessment on a remediation tracker with owners and dates.
3. In the self-assessment, describe the dependency, acknowledge the gap, and reference the remediation milestone.

This approach satisfies the PRA's expectation of honest self-appraisal without leaving the vulnerability unaddressed. What supervisors punish is an undisclosed dependency that emerges through a supervisory visit or incident. What they accept is a disclosed dependency with a credible plan.

Governance and the Board Sign-Off

The self-assessment must be approved by the board, and the minutes must show challenge. If the board paper contains no dissenting views, no unresolved issues, and no vulnerabilities rated above appetite, the PRA will assume the challenge did not happen. Structure the paper to give the board something to push back on: the two or three services where tolerance evidence is thinnest, the third-party gaps you cannot close within twelve months, the scenarios you chose not to run and why.

What to Do Next

Before your next self-assessment cycle, commission an internal audit or second-line review specifically on the completeness of your third-party mapping and the stress-worthiness of your scenario set. Those are the two areas where the PRA's questioning has sharpened, and where the gap between a compliant document and a credible one is widest.

Frequently Asked Questions

How often should the self-assessment be updated?

At least annually, and after any material change to an important business service, its mapping, or its impact tolerance. Material third-party changes, including sub-processor changes disclosed by cloud providers, should trigger a review even if the tolerance itself does not move.

Should we disclose vulnerabilities we have not yet remediated?

Yes. The PRA has been explicit that self-assessments should be honest about gaps. Undisclosed vulnerabilities that emerge later are treated far more seriously than acknowledged ones with credible remediation plans.

How does DORA interact with the SS1/21 self-assessment?

For UK firms in scope of both, the ICT third-party register required under DORA will surface dependencies that must also appear in the SS1/21 mapping. Treat them as one exercise with two outputs, not two parallel workstreams.

What level of board challenge is enough?

Enough that the minutes record specific questions on specific services, and that at least one aspect of the self-assessment was revised as a result. A paper approved without amendment is a red flag to supervisors.