Cloud exit strategy is the piece of cloud governance that everybody agrees is sensible and almost nobody actually holds. Ask an IT director whether they could leave their primary provider inside twelve months and the honest answer is usually a pause, then a qualified maybe, then a list of reasons why the question is unfair. The question is not unfair. It is the same question you would ask about any supplier holding your entire operating platform.
Lock-in is not a moral failing and it is not something you avoid by refusing to use good managed services. It is an accumulation. Every proprietary queue, every petabyte parked in object storage, every three-year committed-spend discount and every engineer who only knows one console adds a little more weight to the anchor. None of those decisions is wrong on its own. Together they quietly convert a commercial relationship into a dependency, and the conversion happens without anybody signing anything that says so. A cloud exit strategy is simply the discipline of keeping that accumulation visible and reversible.
This guide sets out how to build a cloud exit strategy that is worth the paper it is on: where lock-in genuinely comes from, what the four realistic exit routes cost, how egress charges and the new switching rules actually work, which architecture choices keep the door open cheaply, what to put in the contract, and how to test the plan so it is a capability rather than a filing-cabinet artefact. If you are earlier in the journey, our cloud migration business case guide covers getting the money approved, and the AWS vs Azure for UK SMEs comparison covers choosing where to land in the first place.
One framing note before the detail. The purpose of a cloud exit strategy is almost never to leave. It is to be credibly able to leave, because that is what keeps a renewal negotiation honest, satisfies a regulator, and turns a provider outage or a strategic pivot from an existential problem into a costed project with a timeline.
Table of contents
- What a cloud exit strategy actually is
- Where cloud lock-in actually comes from
- The four exit routes and what each one costs
- Data egress: the bill nobody models
- What regulators and contracts now require
- Architecture choices that keep exit cheap
- Writing exit rights into the contract
- Building the cloud exit strategy document
- Testing the cloud exit strategy
- What a cloud exit strategy costs
- Common cloud exit strategy mistakes
- Cloud exit strategy FAQ
- References
What a cloud exit strategy actually is
The term cloud exit strategy is used loosely enough that two people in the same meeting can mean entirely different things by it, which is where most of the disagreement in an exit workshop comes from.
It is a capability, not a document
A cloud exit strategy is the organisational ability to move a workload off a provider within a known time and at a known cost. The document is evidence of the capability, not the capability itself. A forty-page plan nobody has ever tested proves only that somebody could write forty pages. The useful test is whether an engineer who joined last month could pick it up and know what to do first. A cloud exit strategy that fails that test is documentation, not readiness.
Exit is not the same as disaster recovery
Disaster recovery answers what happens when the platform breaks. A cloud exit strategy answers what happens when the relationship stops working: the price rises beyond tolerance, the vendor is acquired, a service is deprecated, a regulator objects, or the strategy changes. The timescales are different too. Recovery is measured in minutes and hours; exit is measured in months and quarters. Plans written for one rarely serve the other.
The three questions it has to answer
Strip away the formatting and any credible cloud exit strategy answers three things. Where would each workload go instead? How would the data get there, in what format, and how long would that take? What would it cost, in cash, effort and elapsed time, including the parallel-running period where you pay for both? Everything else in the document exists to support one of those three answers.
Who it is really written for
There are four readers and they want different things. The board wants a number and a timeline. The regulator wants evidence that the plan is current and tested. The procurement team wants leverage at renewal. The engineers want a runbook that is accurate. Writing for only one of those produces the document the others quietly ignore, which is how a cloud exit strategy ends up unread.
Where cloud lock-in actually comes from
Lock-in is not one thing. It arrives in at least five distinct forms, each with its own cost of removal, and treating them as a single problem is why so many plans stall at the first workshop. A useful cloud exit strategy prices each form separately.
Data gravity is the heaviest anchor
Data is the hardest thing to move because it is large, it is live, and everything else points at it. A hundred terabytes in object storage is not just a transfer cost; it is a consistency problem, because the data keeps changing while you copy it. Data gravity is also self-reinforcing: analytics, machine learning and reporting all cluster around wherever the data already sits, and each new consumer makes the eventual move more expensive. Any cloud exit strategy that does not begin with the data map is starting in the wrong place.
Proprietary managed services are convenience with a bill attached
Managed services are the reason cloud is worth using. They are also the tightest binding. A managed relational database with an open engine is broadly portable; a serverless function bound to a proprietary event bus, a vendor-specific workflow orchestrator or a bespoke identity service is not. The distinction that matters is not managed versus self-hosted, it is whether the interface you code against exists anywhere else. That single question settles most cloud exit strategy arguments about a given service.
Identity, networking and the control plane
The unglamorous layer is often the stickiest. Identity models, role definitions, network topology, policy assignments and the whole cloud architecture baseline are usually expressed in vendor-specific terms. Rebuilding them elsewhere is rarely difficult in isolation, but it is slow, it touches every workload, and it is the part of an exit that consistently gets underestimated because no single item on the list looks hard.
Commercial gravity: discounts that buy your future
Committed-spend agreements, reserved capacity and enterprise discount programmes trade flexibility for a lower unit price. That is often a good trade. It becomes a lock-in mechanism when the commitment period is long, the penalty for shortfall is real, and the renewal lands before your exit could realistically complete. A cloud exit strategy that ignores the commercial calendar is arithmetic without a deadline.
Skills and organisational lock-in
The least visible form. When every engineer, every runbook, every monitoring dashboard and every hiring profile assumes one provider, moving is not a technical project but a retraining programme. This is the type of lock-in that never appears in an architecture diagram and always appears in the actual timeline. It is also the one that a sensible managed IT services arrangement can partly offset, because the provider carries breadth you do not have to hire. Cross-training is the cheapest cloud exit strategy investment most teams never make.
| Type of lock-in | Typical removal effort | Cheapest mitigation |
|---|---|---|
| Data gravity | Months | Open storage formats plus a tested extract |
| Proprietary managed services | Weeks per service | Prefer open engines at the interface |
| Identity and control plane | Weeks, touches everything | Document the model outside the console |
| Networking topology | Weeks | Keep address plans provider-neutral |
| Committed-spend discounts | Bounded by contract term | Align commitments to review dates |
| Skills and tooling | Quarters | Portable toolchain, cross-trained team |
| Licensing and marketplace terms | Variable | Buy licences outside the marketplace |
The four exit routes and what each one costs
A cloud exit strategy is only real when it names a destination. “We would move somewhere else” is not a plan; it is a hope with a budget line. In practice there are four routes, and most organisations end up using more than one.
Route one: repatriate to owned or leased infrastructure
Moving workloads back to your own kit, in a data centre or colocation facility, is the route that makes financial sense for large, steady, predictable workloads with modest growth. It swaps a variable bill for capital expenditure and a hardware refresh cycle. It is slow to execute and hard to reverse, and it needs operational skills many teams have deliberately let lapse. Name that skills gap in the cloud exit strategy rather than discovering it mid-project. Our cloud repatriation guide covers when the numbers actually work.
Route two: move to another hyperscaler
Lifting to a competing public cloud is the fastest route on paper and the one most plans assume. It works well for containerised and virtual-machine workloads and badly for anything built on proprietary managed services. The trap is that a like-for-like rebuild on a second provider reproduces the same dependency shape somewhere else, so you have exercised the exit without improving the position. A cloud exit strategy should say what will be different this time.
Route three: move to a managed provider or specialist platform
For many mid-sized organisations the practical destination is neither self-hosting nor another hyperscaler but a managed hosting provider, a specialist platform or a UK-based sovereign option. It trades some flexibility for a smaller operational burden, and it often suits organisations whose real problem was never the cloud but the fact that nobody internally had time to run it. It is the destination a mid-market cloud exit strategy most often lands on. This sits naturally alongside broader IT outsourcing decisions.
Route four: replace the capability with software as a service
Sometimes the right exit is not to move the workload at all but to stop running it. A bespoke application maintained by two people is frequently a candidate for replacement by a mature product. This is the slowest route because it is a business change project rather than a technical one, but it is the only route that removes the workload from your estate permanently.
| Exit route | Typical elapsed time | Best suited to | Main risk |
|---|---|---|---|
| Repatriate to owned kit | 9 to 18 months | Steady, predictable workloads | Lost operational skills |
| Another hyperscaler | 6 to 12 months | Containers and virtual machines | Recreating the same dependency |
| Managed or specialist provider | 4 to 9 months | Small platform teams | Less architectural freedom |
| Replace with a SaaS product | 12 to 24 months | Ageing bespoke applications | Process change and adoption |
| Hybrid of the above | Varies by workload | Mixed estates | Coordination overhead |
Most credible plans are a hybrid, because estates are not homogeneous. The hybrid cloud vs multi-cloud comparison is useful here, as long as you resist the idea that running in two places is itself a cloud exit strategy.
Data egress: the bill nobody models
Egress is where exit plans meet arithmetic and lose. It is worth pricing properly and, more importantly, worth timing properly, because the transfer window is usually the binding constraint rather than the money. Most cloud exit strategy timelines are set by throughput, not by budget.
What egress actually costs at list price
Standard internet egress on the major providers sits in the region of five to nine US cents per gigabyte, tiering down with volume, with the first small allowance free each month. That is comfortably ignorable at a few hundred gigabytes a month and becomes a board-level number at petabyte scale. The figures below are illustrative list-price arithmetic rather than a quote, but they show why the shape of the curve matters more than the exact rate.
Free-exit egress exists, with conditions
Since 2024 the major providers have offered free data transfer out when a customer is genuinely leaving. AWS, Google Cloud and Microsoft all publish a version of this, driven by the EU Data Act and sustained regulatory attention. The conditions matter: it generally applies to a full exit rather than a partial one, requires you to request it through support, runs to a defined window, and expects the account to close afterwards. Useful, but not something to assume without checking your own agreement, and worth recording in the cloud exit strategy rather than relying on a press release.
Rehearse the transfer, do not just price it
The number that breaks plans is not cost but throughput. Moving 500 TB over a link that sustains 1 Gbps takes roughly seven weeks of continuous transfer, and that assumes nothing changes underneath. Physical transfer appliances, staged cutovers and change-freeze windows are all normal parts of a real cloud exit strategy. Measure your actual sustained throughput once, early, and let it size the plan.
Model the parallel-running period honestly
For the weeks or months when both environments run, you pay twice. This is the single most commonly omitted line in an exit budget and often exceeds the egress charge outright. Include it explicitly, alongside the cost of the people doing the work. A cloud exit strategy without a parallel-running line has understated its own cost. Good cost optimisation discipline during the overlap is worth real money.
What regulators and contracts now require
Exit planning has moved from good practice to obligation for a growing share of organisations. Even outside regulated sectors, the direction of travel is clear enough to plan around, and a documented cloud exit strategy is fast becoming a baseline expectation rather than a differentiator.
UK financial services: exit plans are expected
The FCA’s guidance for firms outsourcing to the cloud expects firms to have documented exit plans covering both orderly and stressed exits, and the Bank of England’s supervisory statement on outsourcing and third-party risk management sets out similar expectations for banks and insurers. In both cases the emphasis is on the plan being specific, tested and owned, rather than merely existing. A generic cloud exit strategy will not survive a supervisory conversation.
DORA and the European position
The Digital Operational Resilience Act requires financial entities to maintain exit strategies for information and communication technology services supporting critical or important functions, including the transition plan and the resources needed to execute it. For UK organisations serving EU clients, this often arrives indirectly through contractual flow-down rather than direct supervision.
The EU Data Act and switching charges
The Data Act obliges cloud providers to remove obstacles to switching, including a phased withdrawal of switching and egress charges and an obligation to support customers moving to another provider. Its practical effect is already visible in the free-exit egress offers, and it is the main reason the commercial picture has improved for customers over the last two years. It materially lowers the cost side of any cloud exit strategy.
The CMA cloud services market investigation
In the UK, the Competition and Markets Authority examined the cloud services market with specific attention to egress fees, committed-spend discounts and technical barriers to switching. Whatever the eventual remedies, the investigation established the vocabulary regulators now use about lock-in, and it is a useful reference when negotiating exit terms with a large provider.
Data protection obligations do not pause for a migration
Moving a live estate does not suspend your duties as a controller. The processor contract requirements under UK GDPR still apply during transition, deletion at the end of the relationship must be evidenced, and any change of hosting location needs a transfer assessment. Build the security and data protection workstream into the cloud exit strategy rather than bolting it on at the end.
Architecture choices that keep exit cheap
The cheapest cloud exit strategy is the one you never have to retrofit. A handful of decisions made early cost almost nothing and cut the eventual switching bill dramatically. Treat them as cloud exit strategy work done in advance.
Portable compute: containers as the default unit
Packaging workloads as containers built to open specifications means the runtime contract is the same everywhere. Kubernetes is not a magic portability layer, because managed distributions differ at the edges, but a containerised workload with its configuration externalised will run on a competing platform far more readily than one bound to a proprietary function runtime. That difference is worth several months in a cloud exit strategy.
Keep state in portable formats
Choose open database engines and open file formats where the workload allows. A relational store on a standard engine, or analytics data in an open columnar format inside object storage, can be lifted with effort. The same data inside a proprietary warehouse with vendor-specific extensions cannot. Format choice decides more of the cloud exit strategy than almost any other technical call, and it is a data management and analytics decision far more than an infrastructure one.
Infrastructure as code with a portable toolchain
Estates defined in code can be rebuilt; estates defined by console clicks must be rediscovered. A provider-neutral toolchain does not make the code portable, because the resource definitions remain vendor-specific, but it does make the estate legible, reviewable and reproducible, which is most of the work. Good DevOps practice is cloud exit strategy insurance you were buying anyway.
Abstract the seams, not everything
The failed version of this advice is the abstraction layer that wraps every provider service in a house interface, so the team writes twice the code and gets the least capable version of each platform. The workable version is narrower: isolate provider calls behind a thin internal interface at a small number of seams, typically storage, messaging and identity, and use each platform natively elsewhere. Three seams handled well beat a whole-estate abstraction nobody maintains, and they cost the cloud exit strategy almost nothing.
Know when lock-in is the right trade
Sometimes the proprietary service is so much better that accepting the dependency is correct. The discipline is to make that an explicit, recorded decision with an estimated switching cost attached, rather than a default. A cloud exit strategy that says “we accept a six-week rebuild on this component and here is why” is stronger than one that pretends the dependency does not exist.
| Capability | Higher lock-in choice | More portable choice | Portability premium |
|---|---|---|---|
| Compute | Proprietary function runtime | Containers on a standard orchestrator | Moderate |
| Relational data | Vendor-only engine with extensions | Managed open engine | Low |
| Analytics | Closed warehouse, proprietary format | Open columnar files on object storage | Low to moderate |
| Messaging | Provider-specific event bus | Open protocol broker | Moderate |
| Identity | Deep native directory coupling | Standards-based federation | Low |
| Observability | Native-only agents and dashboards | Open instrumentation standard | Low |
| Provisioning | Console-driven changes | Declarative infrastructure as code | Negative, it saves time |
Writing exit rights into the contract
Architecture determines what an exit costs. The contract determines whether you are allowed to run it on your own timetable, which is arguably the more important of the two. A cloud exit strategy with no contractual footing is a plan you may not be permitted to execute.
Notice, transition assistance and the exit period
The clauses that matter are unglamorous: how much notice each side must give, what assistance the provider must supply during transition, for how long, and at what rate. A right to terminate with thirty days’ notice is worthless if a realistic migration takes nine months. Align the notice period and any assistance window with the elapsed time your cloud exit strategy actually assumes.
Data return format and deletion certificates
“We will return your data” is not a commitment until it names a format, a mechanism and a timescale. Specify the format, insist that schema and metadata come with it, and require written certification of deletion afterwards. This is also where your obligations as a data controller and the provider’s obligations as a processor need to line up on paper. Put the agreed format in the cloud exit strategy so the rehearsal can use it.
Price protection during the transition period
An exit that triggers a price rise is not an exit you can afford to execute. Fix the commercial terms for the assistance period at the pre-termination rate, and be specific about whether committed-spend discounts survive. This is the clause providers most often want to leave vague, and the one that most directly determines whether your cloud exit strategy is executable under pressure.
Step-in and continuity of service
For services underpinning something critical, consider step-in rights, source code or configuration escrow where relevant, and a defined continuity obligation if the provider enters insolvency. These are proportionate for a core platform and overkill for a marginal tool, so apply them by criticality rather than uniformly. Treat this as part of ongoing vendor management rather than a one-off negotiation.
Negotiate before you sign, not at renewal
Exit terms are cheapest at the point where the provider is still competing for the business. Once the workload is live, the leverage has moved. Put the exit clauses into the first contract, review them at every renewal, and record any that were refused so the risk is visible in your IT governance reporting rather than buried in a signed document nobody rereads.
Building the cloud exit strategy document
Once the analysis exists, writing it down is mostly a structuring exercise. Six sections cover it, and anything beyond them is usually padding that makes the plan less likely to be maintained. A cloud exit strategy nobody maintains is worse than none, because it creates false assurance.
Section one: scope and trigger events
State which workloads are in scope and, importantly, which are not. Then name the events that would start the process: a price increase beyond a threshold, a service deprecation, a material security or resilience failure, an acquisition of the provider, a regulatory direction, or a strategic change. Triggers turn the cloud exit strategy from a hypothetical into something with a defined starting gun.
Section two: the target state
For each in-scope workload, name the destination and the shape it would take there. Vagueness here is the most common weakness in the cloud exit strategy documents we review. “Move to an alternative provider” is not a target state; “containerised on a managed Kubernetes service at provider B, with the relational store on the managed open engine” is.
Section three: the sequenced plan
Order matters more than detail. Identity and networking usually go first, then the least-coupled workloads, then the data-heavy ones, with the crown jewels last once the route is proven. Include the parallel-running period, the cutover approach, and the rollback position for each phase. A migration sequence that has never been ordered on paper will be ordered badly under pressure. Sequencing is the part of the cloud exit strategy that pays for itself first.
Section four: dependencies and the data map
List what each workload depends on, in both directions, and where the data actually lives, including the copies nobody mentions: backups, analytics extracts, logs and the reporting environment. The data map is the section that dates fastest and matters most, which is why it should be generated from the estate rather than typed by hand where possible.
Section five: cost and funding
Egress, parallel running, professional services, internal effort, licensing changes and contract break costs. Give a range rather than a false point estimate, and say who would fund it. A cloud exit strategy with no identified budget line is a plan the organisation has not really agreed to.
Section six: roles and decision rights
Name the person who can declare a trigger met, the person who owns execution, and the forum that approves it. Roles, not individuals, so the plan survives turnover. This is the shortest section and the one whose absence most reliably turns a live decision into a fortnight of meetings. Every cloud exit strategy needs a named decision-maker before it needs more detail.
| Section | Typical owner | Review cadence |
|---|---|---|
| Scope and trigger events | IT leadership | Annual |
| Target state per workload | Architecture | Twice yearly |
| Sequenced migration plan | Platform team | Twice yearly |
| Dependencies and data map | Platform and data teams | Quarterly |
| Cost model and funding | Finance with IT | Annual |
| Roles and decision rights | IT leadership | Annual |
| Contract and clause register | Procurement and legal | At each renewal |
Testing the cloud exit strategy
An untested plan is a hypothesis. Testing is what converts it into the capability described at the top of this guide, and it does not have to be expensive. A tested cloud exit strategy is worth more than a thorough untested one.
Start with a tabletop
Put the people who would actually run it in a room, present a trigger scenario, and walk the first thirty days decision by decision. Two hours of this finds more gaps than a month of document review: the missing data map, the contract nobody has read, the dependency nobody owns. Run it before you invest in anything more elaborate; most cloud exit strategy gaps surface in the first hour.
Then extract something real
The next step is a genuine extract of one representative dataset into an open format, restored somewhere else and verified. Not the whole estate, just enough to prove the export path works, the format is usable and the throughput is what you assumed. Almost every organisation that does this discovers at least one surprise, which is precisely the point. Fold the surprise back into the cloud exit strategy the same week.
Then stand a workload up elsewhere
The strongest evidence is a non-critical workload actually running on the alternative platform, ideally kept alive rather than torn down. It keeps the skills current, validates the toolchain and gives you a real, rather than theoretical, answer to how long a rebuild takes. That number is the single most valuable line in the cloud exit strategy.
Measure recovery, not just transfer
Success is not “the bytes arrived”. It is the service working to an agreed standard, with monitoring, backups, access control and support in place. Define what “operational” means before the test, or you will declare victory at the point the data landed and discover the gap later.
What a cloud exit strategy costs
Exit planning has three cost components, and only one of them is a one-off. Being honest about all three is what makes the budget survive contact with a finance director. A cloud exit strategy costed on the build alone will be challenged the first time it is invoked.
The build cost
For a mid-sized estate, producing a genuinely useful first version is typically a few weeks of concentrated effort across architecture, platform, finance and procurement, plus external help if the internal team has never done it. The dependency mapping and the data map absorb most of that time. Reusing an existing configuration management database, if you have a current one, cuts it considerably.
The rehearsal cost
A tabletop is essentially free beyond the calendar time. A proven data extract costs egress on the sample plus the engineering days to restore and verify it. Standing a workload up on an alternative platform is the expensive tier, and it is the one that most reliably repays itself, because it converts every estimate in the plan into a measured number. Nothing else improves a cloud exit strategy as much per pound spent.
The standing cost of portability
Some portability choices cost nothing and some cost real money in forgone convenience. Running an open engine where a proprietary one would be faster to operate, or maintaining a second set of pipelines, is a recurring premium. Quantify it, and accept it only where the switching cost it avoids is genuinely larger.
Common cloud exit strategy mistakes
These repeat across organisations of very different sizes, and every one of them is avoidable at the planning stage.
Writing the plan for the auditor
A document produced to satisfy an assessment, filed, and never opened again is the most common outcome. It passes the audit and fails the event. Write it so an engineer can execute from it, and the audit takes care of itself. A cloud exit strategy written for execution passes assessments as a side effect.
Treating multi-cloud as the answer
Running in two providers is a resilience choice and a cost, not automatically a cloud exit strategy. Unless workloads can genuinely run in either place with tested data flows, a second provider is a second estate to maintain rather than an escape route. Deliberate portability in one place beats accidental duplication across two.
Ignoring the people
Timelines built purely from technical effort ignore that the same engineers are running the current platform while building the next one. Every cloud exit strategy timeline should be built from available attention rather than ideal effort. Exit projects are constrained by attention far more often than by technology, and this is where an outside pair of hands or a technology consulting engagement usually earns its fee.
Leaving it until renewal
Starting exit analysis eight weeks before a contract expires guarantees you will renew, because there is no time to do anything else. Begin at least two full quarters ahead of a material renewal, so the option to leave is real rather than rhetorical when the conversation starts. That is the minimum lead time a cloud exit strategy needs to create leverage.
Confusing portability with parity
A workload can be portable without being equivalent. Rebuilding on another platform often means accepting different performance characteristics, different operational tooling and different costs. Say so explicitly in the target state, or the first test will produce a disappointment that stalls the whole programme.
Letting the plan go stale
An estate changes constantly and a plan written two years ago describes a system that no longer exists. Tie the review to the cloud strategy cycle and to each contract renewal, and regenerate the data map from the live estate rather than editing last year’s spreadsheet. A stale cloud exit strategy fails at exactly the moment it is needed.
Cloud exit strategy FAQ
Do we need one if we are happy with our provider?
Yes, and being happy is the ideal time to write it. The purpose is to preserve the option, and options are cheapest to buy when you do not urgently need them. A current cloud exit strategy also gives procurement something real to point at during the next renewal.
How long does a full exit actually take?
For a mid-sized estate, six to eighteen months is the honest range depending on route and data volume, with the data-heavy workloads dominating the tail. Anything promising a few weeks is describing a single workload rather than a platform move. Size the cloud exit strategy against the largest dataset, not the average one.
Is multi-cloud a cloud exit strategy?
Not by itself. Running workloads across two providers can reduce concentration risk, but unless each workload has a tested home on both, the second provider is additional operating cost rather than an exit route. Portability is the property that matters, not plurality.
How often should we review it?
Annually as a minimum, at every material contract renewal, and after any significant architecture change. The data map deserves a quarterly refresh because it decays fastest. Reviewing the cloud exit strategy less often than yearly effectively means not having one.
Does the same thinking apply to SaaS and AI vendors?
Yes, and often more urgently, because the data is further from your control. The same questions about data return format, notice periods and destination apply, and the cloud exit strategy template transfers almost unchanged. Our AI vendor lock-in exit plan and AI model exit strategy guides cover the model-specific version of this problem.
What does a good cloud exit strategy look like in practice?
Short, current, specific about destinations, honest about cost, and tested at least at tabletop level within the last twelve months. If it names a trigger, a destination, a sequence and an owner, and somebody has actually rehearsed it, it is already better than most.
References
Cloud services market investigation — Competition and Markets Authority
Data Act — European Commission
Cloud computing policy — European Commission
Digital Operational Resilience Act (DORA) — EIOPA
FG16/5: Guidance for firms outsourcing to the cloud and other third-party IT services — FCA
SS2/21: Outsourcing and third party risk management — Bank of England
Free data transfer out to internet when moving out of AWS
Eliminating data transfer fees when migrating off Google Cloud
NIST SP 800-145: The NIST Definition of Cloud Computing
NIST SP 800-161r1: Cybersecurity Supply Chain Risk Management Practices
Cloud security guidance — NCSC
Using cloud services securely — NCSC
Supply chain security guidance — NCSC
AWS Well-Architected Framework
Azure Well-Architected Framework — Microsoft Learn
Microsoft Cloud Adoption Framework for Azure
Google Cloud Well-Architected Framework
Cloud Native Computing Foundation
Open Source Initiative licences
What is FinOps? — FinOps Foundation
DORA: DevOps Research and Assessment
Controllers and processors — Information Commissioner’s Office
The Technology Code of Practice — GOV.UK
