Operational resilience under SYSC 15A is a board accountability

Firms had to be fully compliant with SYSC 15A by 31 March 2025. The rules turn on four obligations, and each one asks the board to exercise judgement rather than the technology function to configure a system.

The first is to identify the firm’s important business services: the ones whose disruption could cause intolerable harm to clients or threaten market integrity. For a fund manager that usually means dealing and settlement, valuation and pricing, and the ability to meet redemptions. Deciding which services carry that weight is a judgement about where harm concentrates, not an inventory of systems.

The second is to set an impact tolerance for each of those services: the maximum level of disruption, measured as a duration or a degree of harm, past which the consequences become intolerable. The board is deciding, ahead of time, how long the fund could go without striking a NAV or processing a redemption before investors are harmed in a way the firm couldn’t defend. Impact tolerance is a board judgement, not an engineering one. It states the firm’s appetite for risk, and it belongs to the people accountable for the firm.

The third obligation is to map the resources behind each important business service (people, processes, technology, facilities and third parties) so the firm knows what the service rests on and where it could break. The fourth is to test, through scenario analysis, whether the firm can stay within its impact tolerances during a severe but plausible disruption, the standard set at SYSC 15A.2.9R, and to record all of it in a self-assessment that the board approves and the firm keeps for at least six years. The self-assessment is the board’s account of how it has decided, mapped, tested and assured the firm’s resilience.

Taken together, the four obligations describe a governance process with a technology input. The tolerances are set by the board, the mapping is a business exercise, the testing is a board-overseen assurance activity, and the self-assessment is a board document. A firm can build excellent technical resilience and still fail here, if it can’t show the board set the tolerances, tested against them and owns the assessment.

Accountability makes the point plainly. Under the senior managers regime a named senior manager carries responsibility for the firm’s operational resilience, and the self-assessment is approved by the governing body, not signed off inside the technology function. So when a supervisor looks at a firm’s resilience, it is looking at the decisions of accountable individuals: who set this tolerance, who approved this assessment, who satisfied themselves the testing was good enough. Regulatory accountability for the firm’s disruption appetite rests with the senior managers and the board, not the CTO. The technology function can’t speak to the board-level decisions the regime requires.

Under SYSC 8 the firm stays responsible for resilience across its third-party dependencies. SYSC 8 is explicit that outsourcing a critical or important function transfers none of the responsibility: the firm stays accountable, and a third-party failure that breaches an impact tolerance is the firm’s failure for resilience purposes. A manager relying on a fund administrator, transfer agent, cloud provider and market-data vendor keeps accountability for resilience under SYSC 8.

Two further layers sit on top. The Critical Third Parties regime, finalised in PS24/16 and in force since 1 January 2025, gives the regulators direct oversight of the systemically important providers on which much of the sector runs: the large cloud and technology firms whose failure could harm many firms at once. That regime applies to the third parties, not to most fund managers, but its existence carries a message for the board. The regulators treat third-party concentration as a systemic risk, and they expect each firm to understand and manage its own reliance rather than assume the new oversight has taken the problem away. The operational incident and third-party reporting rules finalised in PS26/2, in force from 18 March 2027, then require firms to report operational incidents against defined harm thresholds in a standard form and to maintain and report on their third-party arrangements. Across all three the direction is the same: firms must know their dependencies, manage them, and be able to report when one fails.

The CrowdStrike outage of 19 July 2024 was the live demonstration. A single faulty update to a single widely used product disabled millions of systems around the world. It was a concentration failure: one shared dependency that a great many firms leaned on at the same time. Firms came through CrowdStrike best where governance had already named the dependency, set a tolerance and had a tested, board-owned response ready.

CrowdStrike raised the substitutability question. For each critical third party the board should know whether the firm could switch to an alternative, how fast, and at what cost. An impact tolerance that assumes a provider can be swapped overnight is a fiction where no alternative exists or migration would take months. For many of the largest cloud and data dependencies there is no quick substitute, so the realistic answer isn’t “we’d switch providers” but “we have a tested plan to keep operating, degrade gracefully or communicate our way through the outage”. The self-assessment should say which dependencies the firm could replace and which it would have to ride out. The register the 2027 rules require is what forces that analysis to be done rather than assumed.

For any manager with operations or entities in the European Union, the Digital Operational Resilience Act adds a parallel and in places more prescriptive regime, applicable from January 2025, covering ICT risk management, incident reporting and oversight of ICT third parties. A firm with EU touchpoints runs two resilience regimes at once, and the governance that answers SYSC 15A is the same governance that has to answer DORA.

The clearest case predates the current rules but frames the concern: the £48.65m combined penalty the FCA and PRA imposed on TSB in December 2022 for the operational failures around its 2018 systems migration, which left large numbers of customers unable to reach their accounts. The finding was that the governance around the change was inadequate. The regulators took that lesson into the resilience regime. What presents as a technology failure is often a governance failure.

Supervisory reviews since point the same way. The FCA has repeatedly found limited evidence that firms have tested their response and recovery plans against severe but plausible scenarios, rather than only writing them. An untested impact tolerance, an unchecked map and an unquestioned self-assessment leave a resilience programme with no proof it works.

A resilience programme that answers the regime, not just the IT auditor, has six features a board should be able to see for itself.

Important business services chosen by judgement, not convenience. The firm should be able to explain why each service is important in terms of the harm its loss would cause, with the board’s reasoning recorded, rather than a list the operations team assembled.

Impact tolerances the board set itself. Each tolerance should be a recorded board decision about tolerable harm, with the thinking behind the number, not a figure carried over from a template. Everything else in the regime depends on this one.

Mapping that has been validated. The dependencies behind each important business service, third parties and the concentrations among them included, should be mapped and the map checked for accuracy, so the firm knows what each service rests on.

Scenario testing that is run and acted on. The firm should test against severe but plausible scenarios whether it can stay within tolerance, and should be able to show what each test exposed and what changed as a result. A scenario test that leads to no remediation fails the standard.

A self-assessment the board owns. The document SYSC 15A requires should be live and board-approved, recording the tolerances, the mapping, the testing and the gaps, kept for at least six years, and read as the board’s account of its resilience rather than a report from the technology function.

Third-party and incident readiness. The firm should manage its third-party arrangements and, from 2027, report on them; understand its concentration in critical providers; hold a substitutability view for each; and keep tested incident playbooks ready, so that when a shared dependency fails the response is rehearsed and the reporting is in place. The register the 2027 rules require forces a firm to work out, before the outage, which dependencies it could replace and which it would have to operate through. The substitutability register works as a board management tool, not a filed artefact.

How each capability looks at baseline and in a governed programme:

This insight is provided for general informational purposes only and doesn’t constitute legal, investment, or regulatory advice.