Last year, I sat in on a platform evaluation meeting at a wealth management firm. Twelve people around the table. Three vendors on the shortlist. And a compliance officer who'd been invited - for the first time - at the shortlist stage. Her opening contribution: "We can't use cloud hosting. It's not compliant."
That sentence added about £200,000 to the project. It eliminated two of the three shortlisted platforms. It pushed the firm towards an on-premise deployment that required infrastructure they didn't have. And it was wrong.
Not reckless. Not negligent. Just wrong. The FCA's outsourcing guidance explicitly recognises cloud hosting as a legitimate arrangement. The compliance officer wasn't being obstructive - she was applying maximum caution to a decision she'd been given no context for and no time to properly assess. I felt for her, honestly. She'd been handed a grenade and asked to decide whether to pull the pin.
That's the pattern I keep seeing in regulated financial services. Compliance gets involved too late, with too little context, and the result is predictable: they say no to things that don't need a no, and nobody notices the things that actually do need attention.
And I'll be honest - I've been on the other side of this too. Early in my career I'd sometimes treat compliance sign-off as a box to tick near the end of a project rather than a conversation to have at the start. I thought I was being efficient. I wasn't. I was just deferring the problem.
So. There's a distinction that saves money and accelerates decisions. There are things that financial services regulators actually require from your digital platforms. And there are things that firms assume regulators require but don't. Knowing which is which changes your investment case, your platform shortlist, and - honestly - the speed at which you can make any technology decision at all.
Vague hand-waving about "regulatory requirements" is half the problem, so let me be specific.
If you're running a regulated financial services firm in the UK - wealth management, corporate finance, insurance intermediation, lending - the FCA and PRA have published guidance that creates clear expectations for your digital platforms. Not which vendor you use. Not which hosting model you choose. But specific capabilities your platform needs to provide.
Data residency. The FCA and PRA outsourcing guidance (SS2/21 for PRA-regulated firms, and the FCA's finalised guidance on cloud outsourcing from 2022) requires you to know where your data is processed and stored. This does not mean UK-only hosting. It means you need to be able to evidence data location - to demonstrate that you know where it is, that this is consistent with your outsourcing register, and that you've assessed the risks. A firm that can point to its Azure UK South data centre and explain how it made that decision is in a stronger compliance position than a firm running on-premise servers in a cupboard under the stairs with no documentation.
Audit trails. You need to be able to record who published what content, when, with what approval, and in what form. When the FCA conducts a thematic review or investigates a specific complaint, the ability to demonstrate your content governance process - with evidence - is what separates a conversation from an enforcement action. If your CMS can't tell you who approved that client communication last March, good intentions won't save you.
Access controls. Granular permissions that restrict who can create, approve, and publish content based on their role and authorisation level. This is a content governance requirement under the Consumer Duty (which came into force in July 2023) and broader conduct requirements. The key word is "enforceable." Not "we trust Sarah to check with James before publishing." Actual system-level controls.
Content approval workflows. A documented, enforceable process for reviewing and approving client-facing communications before publication. Required under FCA rules on financial promotions (COBS 4) and communications with clients. If your marketing team can publish a landing page promoting a new investment product without compliance sign-off, and the only thing preventing that is an informal agreement, you're exposed.
Retention policies. The ability to retain content in a retrievable form for the periods the FCA and HMRC specify - typically six years for most financial services firms, with specific longer periods for some regulated content types. "Retrievable" is doing heavy lifting in that sentence. A backup tape in a warehouse doesn't count if nobody can actually find and produce the content when asked.
None of this is controversial. It's published, it's clear, and most compliance officers would nod along reading it. So why do platform decisions keep going sideways?
Because firms consistently over-engineer for requirements that don't exist. This is where the money gets wasted.
No regulator specifies which vendor you use. There is no FCA rule that says you must use Sitecore, or can't use Payload, or should prefer Umbraco over Kentico. The compliance requirement is for the capability - audit trails, access controls, approval workflows - not the brand name on the licence. I've seen firms eliminate platforms from shortlists because "compliance hasn't approved that vendor" when what compliance actually needs to assess is whether the platform meets the five requirements above. A vendor approval process is sensible. A vendor veto based on unfamiliarity is expensive.
Cloud hosting is not non-compliant. I know I've said this already but it bears repeating because I encounter this assumption constantly. AWS, Microsoft Azure, and Google Cloud all hold ISO 27001 and SOC 2 certifications. Azure and AWS both have specific UK financial services compliance documentation, and Azure's UK regions are specifically designed for regulated workloads. The FCA's guidance explicitly acknowledges cloud as a legitimate hosting model. The regulatory concern about cloud is governance and oversight - can you demonstrate adequate control? - not the technology itself.
The firm that avoids cloud "because compliance" and instead spends £150,000 building out on-premise infrastructure is solving a problem the regulator hasn't created. And here's the bit that really stings: they're probably ending up with a less compliant setup, because the major cloud providers have invested hundreds of millions in regulatory compliance capabilities that most mid-sized firms simply can't replicate internally. The cupboard under the stairs doesn't have a dedicated compliance engineering team.
Bespoke approval workflows are usually unnecessary too. Many modern CMS platforms provide built-in editorial approval workflows that can be configured to meet financial promotion review requirements out of the box. I've watched firms spend five or six figures on custom development to create approval processes the platform already supported natively. The development team didn't know, because nobody asked the compliance team what they actually needed until after the architecture was finalised. By which point everyone had too much invested to change course.
One caveat worth flagging: the specific compliance requirements do vary depending on what kind of firm you are. A wealth manager with retail clients faces different content governance expectations under the Consumer Duty than a corporate finance boutique advising institutional clients. An insurance intermediary has specific requirements around product information that don't apply to a commercial lender. The five capabilities above are the baseline, but how each one applies to your firm depends on your permissions, your client base, and your regulatory classification. So please don't treat this as legal advice - it's a way of asking better questions, not a compliance sign-off.
Our compliance team won't approve any new platform without extensive review. We need to keep things simple.
Fair enough. Compliance review is non-negotiable. But "extensive review" doesn't have to mean nine months of analysis paralysis. The problem usually isn't that your compliance team is too thorough. It's that they're asked to review the wrong thing at the wrong time.
What I've found works - and I mean actually works, in rooms with real compliance officers who are understandably cautious - is turning "is this platform compliant?" into five specific, answerable questions. Walk through them together, for each platform on your shortlist.
Can the platform evidence where data is stored and processed? Is this consistent with your outsourcing register? Can you demonstrate oversight to a regulator?
Does it maintain an immutable record of content changes, approvals, and publications - with timestamps and user attribution? Can that record be exported and produced in response to a regulatory enquiry without a three-week archaeology project?
Can it restrict content creation, editing, and publishing rights to specific roles? And is this enforced at the permission level, or does it rely on everyone remembering the rules?
Does it support a defined review and approval workflow for regulated content, with mandatory sign-off steps before publication? Can you configure this without bespoke development?
Can it retain content in a retrievable form for your required retention period and export on regulatory request?
That's it. Five questions. When a compliance officer can see the native approval workflow running in a demo rather than imagining what it might do, the conversation changes. When they can test the audit trail by making a change and checking the log themselves, the abstract concern becomes a concrete assessment. When they can review the data residency documentation from Azure UK South, the cloud hosting question gets answered with evidence rather than assumption.
If you want those five questions as a structured evaluation tool - ready to use in your platform shortlist assessment - download it here. For a facilitated session that works through the compliance requirements with your IT and compliance teams together, book a regulated platform review.
I've been doing this long enough to see the same two mistakes repeat.
The first is over-engineering for phantom requirements. A mid-market wealth management firm - about 150 people - built a custom compliance layer on top of a CMS that already had native approval workflows. Four months. North of £120,000. When I asked why, the answer was: "Compliance required it." When I asked the compliance team what they'd actually specified, the answer was: "We said we needed an approval workflow before anything client-facing gets published."
The platform already did that. Nobody had shown them.
The second failure mode is under-investing in actual requirements. A specialist lender I spoke with last year was running a CMS with no audit trail, no role-based access controls, and a content approval process that consisted of - I'm not making this up - emailing a PDF to the compliance officer, who would reply "approved" from their phone. Six years of client-facing content with no retrievable approval record. No way to evidence who published what, when. If the FCA had conducted a thematic review of that firm's financial promotions, they'd have had nothing to show. And the team genuinely believed they were compliant because "everything gets checked by compliance."
Both firms had compliance teams. Both thought they were meeting their obligations. The difference was whether anyone had mapped the actual regulatory requirements to the actual platform capabilities - or whether they were operating on assumptions and institutional habit.
The irony is that the first firm spent £120,000 they didn't need to spend, and the second firm spent nothing they should have spent. Both were wrong in opposite directions, for the same underlying reason: nobody had asked the right questions at the right time.
There's a meaningful overlap here with the security risks that legacy platforms carry - the audit trail and access control gaps that create compliance exposure are usually the same gaps that create security exposure. Worth keeping in mind if your platform is more than a few years old.
Right. Here's the thing that changes everything: timing.
The compliance team asked to "sign off" on a platform decision that's already been made will almost always apply maximum caution. Why wouldn't they? The consequences of approving something that later turns out to be problematic land on them. The consequences of rejecting it land on someone else. The incentive structure is completely asymmetric - and it's not a character flaw, it's a rational response to a bad process.
A compliance team involved in defining the requirements at the start of the evaluation is a different dynamic entirely. They're not gatekeepers anymore. They're co-authors.
The conversation that works - and I've seen it work at firms ranging from 50-person IFAs to top-20 wealth managers - goes something like this: "Here are the five compliance requirements we've identified for this platform. We want to know if this is the right list. And then we want to assess each shortlisted platform against them together."
That "together" matters. When a compliance officer sits through a platform demo and sees the native approval workflow in action, they don't need to imagine what it might do. When they can test the audit trail themselves, the abstract concern becomes a concrete assessment. When they can review the data residency documentation from Azure UK South or AWS London, the cloud hosting question gets answered with evidence rather than assumption.
We've got a broader governance framework for platform decisions that covers both the operational and regulatory stakeholder perspectives - worth reading if you're early in this process and want to get the structure right from the start. The general CMS decision matrix we've published is also useful here - it gives you the broader evaluation framework that this piece specialises for the financial services regulatory environment.
If you're heading into a platform evaluation - or stuck in one that's stalled - stop asking "is this platform compliant?" and start asking "does this platform meet the specific capabilities our regulator requires, and are we building anything we don't need to?"
That question will almost certainly save you money. It might save you six months. And it'll produce a platform decision your compliance team can stand behind - because they helped make it.