Pre-Approved, Not Pre-Vetted: A UK Buyer’s Field Notes on Cloud Frameworks

Cloud procurement frameworks have a comforting shape. You log in, filter by service, find a supplier that looks sensible, and download something that resembles a contract. The route feels pre-cleared. Someone, somewhere, has already done the checking. That feeling is useful for getting a project moving, and dangerous if you let it replace your own judgement.

A framework is a buying route, not a character reference. It tells you a supplier has met the framework’s entry conditions and agreed to certain standard terms. It does not tell you that the supplier’s support desk will answer at 2am, that their exit process won’t leave you exporting spreadsheets for a fortnight, or that the specific service you want keeps your data in the UK. Those are workload-level questions, and they still belong to you.

What the framework actually certifies

Crown Commercial Service frameworks, including G-Cloud and the digital specialist routes, do a lot of useful legwork. They establish a common set of terms, a route to market, and a baseline of supplier information. Dynamic purchasing systems add another flavour: a live list of suppliers that have met entry criteria, with the ability to run further competition among them.

But the word “framework” covers a wide range of assurance. A supplier can be on the framework for one service and not another. A listing can be accurate on the day it was submitted and quietly stale six months later. The framework’s own terms may set a floor, while the call-off contract sets the ceiling on what you actually get. If you only read the catalogue entry, you’re reading the advert, not the tenancy agreement.

This matters most when the purchase is small enough to feel routine. A team in Leeds buying a backup service, or a Cardiff organisation adding a monitoring tool, may not want a full legal review. Fair enough. But the questions don’t disappear because the contract is short. They just get cheaper to answer early and more expensive to answer later.

Four columns worth reading twice

When you open a framework listing, resist the urge to skim the service description and jump to price. Four things deserve a slower read.

Support tiers. Framework entries often list support as an option rather than a promise. The headline price may assume business-hours cover, while the service you’re replacing had 24/7 cover. Check the response times, the escalation path, and whether support is delivered by the supplier or a third party. A UK business-hours desk is not the same as a UK-based desk, and neither is the same as a desk that knows your sector.

Exit terms. This is where frameworks can feel less generous than they look. Look for the notice period, the data export format, the deletion timeline, and any charges that apply when you leave. A supplier may be perfectly reasonable on entry and remarkably attached to your data on exit. The framework may require an exit plan, but it won’t write yours for you.

Liability. Framework terms often set a baseline, but the call-off contract can adjust it. Check the cap, what it applies to, and whether it covers data protection breaches, service credits or both. A liability cap that looks fine in a framework summary can be less fine when you read the service-specific schedule. If the numbers feel abstract, ask what a bad month would actually cost you.

Data residency. “UK data residency” is a phrase with several meanings. It can mean data at rest in the UK, data processed in the UK, support staff in the UK, or all three. It can apply to the core service but not to backups, analytics or a subprocessor. The framework listing may give you a category. The service documentation gives you the detail. If the detail isn’t there, ask for it in writing before you sign.

Framework versus direct: the trade you’re making

Direct procurement gives you your own terms, your own timetable and your own legal spend. It also gives you the whole job of drafting, negotiating and chasing. Frameworks trade some of that control for speed and standardisation. That’s a reasonable trade for many UK teams, especially when the service is commoditised and the risk is low.

The trade stops being reasonable when the framework is treated as a substitute for scoping. A pre-approved supplier can still be wrong for your workload. A framework can still host a service that doesn’t meet your residency requirements. A call-off can still contain a support tier that doesn’t match your operating hours. The framework reduces the number of unknowns; it doesn’t eliminate them.

A useful habit is to compare the framework route with a direct route on one page. What are you saving in time and legal cost? What are you giving up in negotiating flexibility? If the answer is “we’re saving a fortnight and giving up the exit terms we actually need”, the framework isn’t the shortcut you thought it was.

A small routine before you call off

You don’t need a procurement programme for every purchase. You do need a repeatable pause. Before you call off, ask three questions: what does this service do for the specific workload, what happens when we leave, and who can prove both answers in writing?

Then check the call-off contract, not just the framework entry. Confirm the support tier, the liability cap, the exit assistance and the data residency schedule. Save the evidence alongside the contract. If a supplier can’t answer a question before the sale, that’s information too.

Frameworks are genuinely useful. They make it easier for UK teams to buy cloud services without starting from a blank page. But a catalogue listing is a door, not a survey. The due diligence still happens on your side of the threshold.