Operational resilience
The wealth manager's cyber brief: what the regulator expects, and what actually goes wrong
A plain-English brief for COOs and risk leads at wealth and asset managers: operational resilience and impact tolerances, named accountability under SM&CR, third-party concentration, and the payment fraud that targets client money.
The uncomfortable thing about cyber risk in wealth management is that the two pressures on you come from opposite directions and tend to be managed by different people. The regulator asks a structural question: can this firm keep delivering the services that matter, through disruption, and can you prove it. The attacker asks a much narrower one: who here can move client money, and how do I convince them to move it to me. Firms that answer only the first end up with a well-documented resilience framework and an unprotected payments process. Firms that answer only the second have sharp controls and nothing to show a supervisor.
This brief covers both, in the order a COO or risk lead actually meets them.
The regulator's question: can you stay inside your tolerances?
The FCA's operational resilience regime asks firms to work from the client outward rather than from the technology inward. You identify your important business services, the ones whose failure would cause intolerable harm to clients or to market integrity. For a wealth manager that usually means a short list: client reporting and valuations, the ability to transact and settle, access to client cash, and the processes that keep client instructions moving.
For each one you set an impact tolerance, a stated maximum level of disruption. The number is the part people underestimate, because setting it forces every other piece of work. You cannot sensibly say that client reporting can be unavailable for four hours unless you have mapped the people, processes, systems, data and third parties that service runs on, and you cannot claim you would stay inside four hours unless you have tested it against a scenario severe enough to be interesting. The rules have been in force since 2022 and the transitional period for operating inside tolerances ran to the end of March 2025, so a supervisor asking today is not asking about your plans. They are asking what your testing found and what you did about it.
The common gap we see is not an absent framework. It is a framework assembled once, for the deadline, that nobody has stress-tested since. Mapping that was accurate two platform migrations ago, tolerances set by the people who wanted them comfortable rather than the people who would have to meet them, and a self-assessment that reads like a description of the firm rather than an argument about it.
Accountability has a name on it
Under the Senior Managers and Certification Regime, this does not belong to a department. A named senior manager carries it, and the regime is built so that the question "who was responsible" has an answer before anything goes wrong rather than after.
The practical implication is about fluency, not paperwork. The named individual should be able to describe the important business services, the tolerances and the main dependencies without reading from a pack, and should be able to show how decisions were reached: why this service and not that one, why four hours and not twelve, what the last test showed, what was fixed, what was accepted and by whom. A governance trail that records conclusions but not reasoning is thin evidence when someone is examining a judgement made two years earlier.
It is also where outsourcing gets misunderstood. Handing an operation to a platform, a custodian or an administrator moves the work. It does not move the accountability, and the senior manager named against the service is still the person who has to explain it.
The dependency you cannot see all of
Wealth managers run on other people's infrastructure. Platforms, custodians, fund administrators, order management and portfolio systems, data feeds, the outsourced IT provider. Most of these firms are competently run. That is not the point. The regulator's concern, and the sensible internal concern, is concentration: how many of your important business services stop if one provider has a bad week, and what you actually do that day.
Three questions separate firms that have done this work from firms that have documented it:
- If this provider were unavailable for a week, which of our services stop, and what is the manual alternative? If the answer is that there is no alternative, that is a legitimate position, but it needs to be a decision someone took rather than a gap nobody noticed.
- What are we contractually entitled to? Audit and inspection rights, incident notification within a defined period, exit assistance. These are easy to agree at renewal and impossible to retrofit mid-incident.
- Who else uses them? Concentration is a market-level problem as well as a firm-level one, which is why the UK now has a regime allowing HM Treasury to designate the third parties that matter systemically to the financial system. That is a regulator-to-provider relationship rather than something most firms act on directly, but it is worth knowing whether your critical providers are likely to fall into it.
There is also a date on this now. In March 2026 the FCA published PS26/2, which brings operational incident reporting and material third-party reporting into one regime across the FCA, PRA and Bank of England: a single definition of an incident, a single portal so a firm reports once whoever the report is for, and a single definition of a material third-party arrangement. The rules apply from 18 March 2027, and the thresholds and worked examples sit in the accompanying guidance. The practical implication is that the supplier register stops being an internal document. If it is incomplete or the criticality calls are soft, that shows up in something you file rather than something you keep.
Firms with EU institutional clients meet a sharper version of the same thing from the other side, when those clients push DORA's third-party requirements down the chain by contract. We set out what that actually requires, and the scope misconception that catches people out, in DORA Article 28 in plain English.
The attacker's question: who can move the money?
Now the narrower threat, and the one that empties accounts.
Wealth managers are targeted for payment diversion and business email compromise more reliably than for anything exotic, for the obvious reason: the firm moves significant sums on instructions that often arrive by email, from clients who are frequently travelling, and the transactions are large enough that a single success pays for a long campaign. The attacks that work are rarely technically impressive. They are patient and well-researched.
Two shapes account for most of it. In the first, the client is impersonated: an attacker with access to a client's mailbox, or a convincing lookalike address, sends a payment instruction or a change of bank details, often with a plausible reason for urgency and a request to handle it discreetly. In the second, the firm is impersonated to the client, which damages you even though your systems were never touched.
What stops both is a verification step that does not trust the channel the instruction arrived through:
- Call back on a number already held on file. Never a number in the email, and never only a reply to it. This single control defeats the majority of attempts, including the ones that are otherwise flawless.
- Treat a change of bank details as a high-risk event in its own right, with verification required regardless of who appears to have asked and how routine it looks.
- Require a second authorised person above a threshold the firm sets deliberately.
- Resist urgency and secrecy as a matter of policy. Both are manufactured, and staff need explicit permission to slow a transaction down without feeling they have failed a client.
- Protect the mailbox, with multi-factor authentication on email and remote access, alerting on mailbox rules and forwarding changes, which is how an attacker stays hidden inside a compromised account.
The cultural half matters as much as the procedural half. A verification step holds when everyone is expected to use it every time, and weakens the moment it becomes a judgement call to be weighed against a client’s patience. Judgement calls go differently under time pressure, which is the condition these attacks are designed to create. The fix is to make the callback a courtesy the firm extends to every client, framed as protection rather than suspicion, so that nobody has to decide whether this particular client warrants it.
Client data, and the discretion clients assume
Wealth managers hold an unusually sensitive combination: identity documents, source-of-wealth files, family structures, trust and succession arrangements, property and asset details, and often the personal circumstances behind a mandate. A breach here is not just a regulatory event. For some clients, the information itself carries personal security implications, which is why discretion is part of the service rather than an add-on to it.
The obligations are the ordinary ones, applied to extraordinary data. Personal data sits under UK GDPR and the Data Protection Act 2018, and a qualifying personal data breach has to reach the ICO within 72 hours of the firm becoming aware of it, which is a clock that starts whether or not you yet understand what happened. Run that alongside your regulatory notification rather than after it, and decide in advance who makes each call.
The practical controls are unglamorous and effective: know where client data actually lives, including the spreadsheets and shared mailboxes outside the core systems; limit access by role so a compromised account reaches less; and apply the same scrutiny to the advisers, introducers and service providers you share files with as you would to a platform. We cover the broader governance framing in cyber risk reporting for boards.
The evidence everyone wants, in their own format
Institutional clients, consultants, insurers and prospective investors all ask for assurance, and they rarely ask the same way. A single due diligence questionnaire can run to several hundred questions, and the request usually arrives with a deadline attached to a mandate you want.
Two things make this manageable. First, do the underlying work once and keep the evidence current, rather than assembling it per request. A firm with a live asset inventory, a tested recovery capability, a supplier register with criticality assessed, and an incident response plan that has actually been exercised can answer almost any questionnaire from the same evidence base. Second, recognise what certification does and does not buy. ISO 27001 gives you a recognised management system and shortens a great many questionnaires, Cyber Essentials answers a specific procurement ask and is quick to reach, and both are delivered through certified assessment partners with us as your single point of accountability. Neither is a regulatory requirement, and neither excuses a weak control.
Insurers ask their own version at renewal, with underwriting increasingly driven by specific controls rather than general reassurance. We decode what they are looking for in the renewal questionnaire.
What the board should be asking
Six questions that reliably separate a real position from a described one:
- What are our important business services, and when did we last change that list?
- What are the impact tolerances, who set them, and have we tested against a severe but plausible scenario rather than a convenient one?
- If our main platform or custodian were unavailable for a week, what would clients actually experience?
- How does a payment instruction get verified, and when did we last test that the callback happens under pressure?
- If we were compromised tonight, who makes the regulatory call, who makes the ICO call, and who speaks to clients?
- What did our last test or incident expose, and what changed as a result?
The last one is the most revealing. A firm that cannot name something a test exposed either has not tested seriously or is not being told.
Where to start
If this reads as a long list, the sequence that gets the most ground covered is short.
Start with the dependency map for one important business service, done properly, end to end, including the third parties. It is the piece most firms have in outline and few have in detail, and it makes the tolerance conversation concrete. Then test the payment verification process by actually attempting it, with a scenario rather than a memo, because that is where client money is lost. Then look at the evidence you would hand a consultant or an underwriter tomorrow, and fix the gaps that work exposes.
We do this work with wealth and asset managers as their single point of accountability: independent advice on the programme, managed security watching the estate around the clock, and compliance kept current so the evidence is ready when it is asked for rather than assembled in a hurry. See how we work with financial services firms, or book a call and bring your own version of the list above. You will leave with at least one useful answer, whether or not we are a fit.
Frequently asked
Questions readers ask before getting in touch.
- No. The FCA sets outcomes, not certifications. It expects you to identify your important business services, set impact tolerances, understand the people, processes, technology and third parties each service depends on, and be able to stay inside those tolerances under severe but plausible disruption. ISO 27001 is a useful way to organise and evidence the underlying management system, and institutional clients and consultants increasingly ask for it, but holding a certificate is not the same as meeting the regulator's expectation, and the absence of one is not a breach.
- It is the maximum tolerable disruption to an important business service, expressed as a number rather than an adjective. Not 'we would restore quickly' but 'this service can be unavailable for four hours before the harm becomes unacceptable'. The discipline is in the consequences: once you have set the number, you have to map what the service depends on, test whether you can actually stay inside it under a severe but plausible scenario, and fix what the test exposes. A tolerance nobody has tested against is a statement of intent.
- Only through a relationship, not through geography. DORA binds EU financial entities. A UK firm is reached where it has an EU group entity that is itself in scope, or where it supplies ICT services to an EU financial entity that pushes the requirements down by contract. Clients who happen to live in the EU are irrelevant: an individual is not a financial entity. We cover the distinction in detail in our guide to DORA Article 28.
- It needs a named senior manager rather than a department, which is the point of the regime. In most firms it sits with the senior manager responsible for operations, with technology and information security reporting into that accountability. What matters practically is that the person named can describe the important business services, the tolerances, the dependencies and the testing in their own words, and can show the governance trail behind the decisions. Accountability that exists only in a responsibilities map is the kind that fails under scrutiny.
- A verification step that does not rely on the channel the instruction arrived through. If a payment instruction or a change of bank details comes by email, it is confirmed by a call to a number already held on file, never a number in the email, and ideally by a second authorised person. The control is procedural rather than technical, which is why it survives a convincing impersonation. Technical controls still matter, multi-factor authentication on email and strong filtering remove most of the opportunity, but the callback is what catches the attempt that gets through.
- A material incident, yes. Firms are expected to notify the FCA of anything significant affecting the firm or its clients, and a serious cyber incident falls squarely in that category. This is about to become more defined: PS26/2, published in March 2026, replaces the regulator-by-regulator approach with a single regime across the FCA, PRA and Bank of England, with one incident definition, one portal and aligned timelines, in force from 18 March 2027. Treat it as a separate obligation from the data protection one either way: where personal data is involved, the 72-hour clock to the ICO runs on its own timetable, and the two notifications answer to different regulators with different thresholds. Decide in advance who makes each call, because the first hour of an incident is the wrong time to work out the reporting map.
- Both. Outsourcing the operation does not outsource the accountability: the regulator still expects you to understand the dependency, assess the concentration, and know what you would do if the provider failed. The hard question is not whether your custodian is well run, it almost certainly is, but what your firm does on the day it is unavailable, and whether your impact tolerance for the services that depend on it is honest about that.
Talk to us
Want to talk through how this applies to your company?
A 30-minute call with a senior advisor. No pitch. We will read your situation against what is in this piece and tell you the smallest sensible next step.