Third-Party Vendor Compliance Guide for Cloud Migration

If I move to the cloud without fixing vendor compliance first, I keep the risk and add new gaps.

Here’s the short answer: I need to classify the service, check the vendor properly, put the right contract terms in place, set clear control ownership, and keep records up to date after go-live. For UK firms, that usually means lining up cloud migration with FCA and PRA outsourcing rules, UK GDPR, and the NCSC cloud security principles.

Before I sign anything, I want to be able to answer five plain questions:

• Is this service critical to the business?
• What data is involved, and where will it go?
• Can the vendor prove its security and recovery claims?
• Does the contract give me audit, regulator access, breach notice, and exit rights?
• Who does what once the service is live?

A few points stand out from the article:

• Cloud risk changes shape, not size. Shared responsibility, sub-outsourcing, transfer risk, and supplier concentration all need direct checks.
• Timing matters. A breach may need ICO reporting within 72 hours, so vendor notice periods must be tight.
• Recovery claims need proof. If a vendor cannot show test results for RTOs and RPOs, I should treat that as a warning sign.
• Exit planning starts before migration. If data export, deletion, support periods, and fees are vague, I may face lock-in later.
• Board evidence matters. Registers, reviews, incident logs, and version-controlled records are what auditors and regulators will ask for.

What this means in practice is simple: cloud migration is not just an IT project. If a supplier handles my systems or data, I still need control, proof, and a clear route out.

The article below breaks that into due diligence, contract checks, live controls, and governance for UK organisations.

Pre-migration due diligence: how to assess a cloud vendor

Due diligence is an evidence-led check on whether a vendor is fit for your workloads, data and continuity needs before you sign.

Classify the service, data and business criticality

Start here. The way you classify the service, the data and the business impact sets the depth of the review, the rules that apply and the contract terms you'll need.

First, map the cloud service to your business operations. If the vendor will support payments processing, customer account access, regulatory reporting or trading execution, the deal is likely to count as a material outsourcing of a critical or important function under FCA and PRA expectations.[1][7] That can mean extra scrutiny, Board approval and, in some cases, notice to your regulator. At the other end of the scale, a generic collaboration tool with no regulated data still needs checks, but the review can be lighter.

Next, identify the data involved. Personal data, special category data, payment card data, financial data, confidential business information, and log or telemetry data can each call for different handling under UK GDPR and sector rules.[2][12]

Then test business criticality in plain terms: if this vendor went offline for 24 hours, what stops working, who gets hurt, and could you still meet your regulatory duties? Write the answer up as a formal materiality assessment.

Review security, resilience and financial standing

Once you know what you're checking, ask for proof. Not promises. Not polished sales decks.

For security, request current ISO 27001 certification, plus ISO 27017 or ISO 27018 where cloud-focused controls matter. Ask for SOC 2 or ISAE 3402 reports, including management responses to any findings, and get a clear explanation of identity and access management, encryption at rest and in transit, patching, and vulnerability management.[2][9][11] The NCSC's 14 Cloud Security Principles are the yardstick for this review.[8][6]

For resilience, ask for recovery time objectives (RTOs) and recovery point objectives (RPOs), disaster recovery test results, backup architecture, and a summary of major outages over the past 12 to 24 months. The Bank of England's expectations for material cloud outsourcing specifically include looking at RTOs and RPOs when judging resilience options.[14][15] If there is no fallback provider or other backup arrangement, get the continuity and disaster recovery plan nailed down before migration.

For financial standing, review audited accounts, ownership structure and client references. PRA SS2/21 says firms should understand a provider's business model, financial position and scale.[4][9] Warning signs include steady losses with no clear route to profit, heavy dependence on a small client base, or no enterprise references from regulated UK firms.

The table below pulls the main checks into one place:

Use what you find here to shape the contract terms that come next.

Check privacy, data residency and international transfer risks

Map where the data will sit, who can get to it and which safeguards apply.

Start with the controller/processor split. In most cloud deals, your organisation stays the controller and the vendor acts as a processor following your documented instructions. But some vendors go further. If they offer analytics, AI-based decisioning or fraud detection, they may set their own purposes for part of the processing. If that happens, treat that part as joint or independent controllership and adjust your obligations to match.[2][9][12]

Then map data centre locations and sub-processors. Ask the vendor for a full list of every jurisdiction where your data may be stored or processed, including through subcontractors. The ICO is clear that organisations using cloud services should assess whether a restricted transfer of personal information is taking place and what safeguards apply.[13] If data moves outside the UK, you'll need a valid transfer tool, such as the UK's International Data Transfer Agreement (IDTA) or adequacy regulations, plus proof that the vendor can support that route.

Finally, pin down retention and deletion. A compliant vendor should be able to say exactly how long data is kept, how deletion works, including in backups and archives, and provide written confirmation once deletion is done. Vague lines like best effort deletion or proprietary data formats that make extraction expensive should set off alarm bells before signature.[2][12]

These findings should feed straight into the contract clauses on location, retention and deletion. They should also carry into audit rights and exit terms.

Contract review: the clauses that make cloud outsourcing compliant

Due diligence shows you where the risk sits. The contract is where you deal with it. If the contract doesn’t match what due diligence found, you’re leaving a gap that can turn into a compliance problem.

Data handling and processing terms

Your contract needs to spell out how data will be handled in practice. That includes encryption, key management, tenant isolation, backup and restore, and logging with enough retention to support incident investigation. Vague promises about “industry-standard security” won’t do much when something goes wrong. Put measurable controls and service levels in writing.

Sub-processors need their own clause too. The vendor should have to notify you before adding new sub-processors, give you a right to object where that makes sense, and confirm that the same data protection duties apply all the way down the supply chain.[22] If the vendor’s standard terms give them blanket consent to swap sub-processors whenever they like, push back.

Breach notification also needs to be tight. Require notice within 24 hours of discovering a suspected breach. On termination, the vendor should return your data in a standard format and confirm secure deletion from backups and replicated copies. Ask for certified deletion. “Best effort” is too loose.

These duties shouldn’t sit on their own. They need to feed straight into your access, audit, and exit clauses.

Access controls, audit rights and regulator access

Once the processing terms are set, the next job is to lock down access and make sure you can get enough assurance. In plain terms, that means role-based access, least privilege, strong authentication, segregation of duties, and documented approval workflows for any privileged or emergency access to your production environment. Logging of all administrative activity - with retention periods long enough to support investigations - should be a contract term, not a nice-to-have add-on.

On-site audit rights are often off the table with hyperscalers. So firms usually have to rely on pooled audits and independent assurance instead. PRA SS2/21 says this directly: major cloud providers may not accept unrestricted on-site audit rights for every customer, and risk-based alternatives such as pooled audits, shared penetration testing results, and independent assurance reports can be used instead.[18][20] That means the contract still has to preserve your right to enough assurance, whether through SOC 2 Type II reports, ISAE 3402 reports, ISO 27001 certificates, or targeted audits where the risk justifies them.

Regulator access is not up for debate for UK-regulated firms. The FCA, PRA, and Bank of England must be able to access data, systems, premises, and relevant personnel where needed for supervision, audit, investigation, or enforcement.[17][4] The contract should say that in clear terms. Standard confidentiality wording must not override it. If a vendor tries to restrict regulator access, or says you need their consent before replying to a regulatory request, that clause should be removed or expressly overridden.[16]

Exit, termination and portability clauses

The last big contract check is simple enough: can you leave without causing disruption? An exit clause that looks fine on paper but falls apart on cost, timing, or support isn’t much use. The contract should set out notice periods, transition assistance, parallel running support, and pre-agreed, itemised exit costs. If exit fees are excessive or left undefined, a migration may be technically possible but commercially unrealistic.[2][5]

PRA SS2/21 expects firms to keep documented exit strategies for both planned and stressed exits, backed by the contract.[17][19][21] The vendor should commit to a defined transition support period - for example, 30 to 90 days - continued service during handover, and pre-agreed, itemised exit costs. FCA guidance also says firms must be able to exit without undue disruption to services or regulatory compliance.[2][3][5]

The table below links the main exit and data-handling clauses to the regulatory expectations behind them:

The practical test is blunt: can you exit without losing data or breaching regulatory duties? If that answer feels uncertain, the clause needs work before you sign.

Operational controls after contract signature: shared responsibility in practice

::: @figure {Cloud Vendor Shared Responsibility Matrix: Customer vs Provider Controls} :::

Signing the contract isn’t the finish line. What happens day to day is what shows whether a cloud migration is compliant in the real world: access, monitoring, incident response and recovery. These controls turn contract terms into evidence that regulators can check.

Identity, privileged access and least-privilege design

Misconfigured access is one of the most common cloud failure points. The fix starts with role-based access control (RBAC). Each user and service account should get only the permissions their role needs. Production systems, and any system that holds personal data, should be limited to a small, named group of approved staff. There also needs to be a clear split between people who make changes and people who approve them.

Multi-factor authentication (MFA) should be required for all administrative and high-risk access, including third-party vendor accounts. Where possible, use phishing-resistant methods such as FIDO2/WebAuthn for privileged accounts instead of SMS-based MFA. Vendor support staff should access your environment through time-limited, logged sessions, with customer-approved temporary elevation rather than permanent admin rights.

Joiner-mover-leaver (JML) processes should be automated and linked to HR systems. That should cover vendor personnel as well as internal staff. If someone leaves or changes role, access should be removed or updated the same business day. Quarterly access reviews for standard systems, and monthly reviews for highly sensitive systems, should compare live access lists with approved role definitions. Any orphaned or excessive permissions should then be fixed and recorded.

Monitoring, incident response and resilience testing

Good contracts set logging rules. Good operations make sure those rules are in place. All administrative actions, configuration changes, API calls and access to sensitive data should feed into a central SIEM, with retention matched to UK regulatory and business needs. Alerts should be set up to spot clear risk signals, including:

• bursts of failed logins
• privilege escalation events
• creation of new administrator accounts
• changes to firewall or security group rules

Incident response has to be a joint effort, not something one side handles alone. Runbooks should name vendor roles directly: who detects, contains, notifies and preserves evidence. Under UK GDPR, the ICO’s 72-hour reporting window means your vendor must tell you about a suspected breach fast enough for you to meet that deadline. For UK financial services firms, incident timelines also need to match FCA and PRA operational resilience expectations, including defined impact tolerances for important business services.

Resilience testing is where many firms slip up. Backup restoration tests should run on a regular basis in non-production environments, so you can confirm that data can in fact be recovered within agreed Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs). Failover exercises, including simulated regional outages, should take place at least once a year for critical services. Those exercises should be done jointly with the vendor, with results written down and follow-up actions tracked until they are closed.

Documenting control ownership under the shared responsibility model

Control ownership should be set out in a written shared responsibility matrix. This helps stop controls falling into the gap between your team and the vendor. The control boundary changes by service model. The table below gives a working baseline:

Keep this matrix in your cloud governance documents and make sure engineering, internal audit and senior management can access it. Review it whenever there is a service change, audit or renewal.

Governance and conclusion: ongoing oversight for UK firms

Build a repeatable vendor compliance framework

Use the shared responsibility matrix to run day-to-day governance, not just the initial rollout. On paper, the matrix looks neat. In practice, it only matters if someone keeps it current. That’s what turns earlier contract and control work into a live evidence trail that regulators, internal audit and the board can actually use.

Start with clear ownership. A named executive - usually the CRO, CIO or COO - should be accountable for the third-party lifecycle. A RACI matrix should spell out who is responsible for the outsourcing register, contract management, control testing, vendor performance monitoring and regulatory reporting. If that isn’t clear, work slips through the cracks.

Your outsourcing register sits at the centre of the framework. For each material cloud vendor, record the service model, data categories, storage jurisdictions, sub-outsourcing, contract dates and owner. UK regulators expect firms to keep this register accurate. For some firms, the Bank of England requires an updated register submitted through the RegData platform at least once a year.[5] Upcoming FCA notification rules make accurate records even more important.[3][23][14]

Once the register is active, use it to support monitoring and board reporting. Review critical services monthly or quarterly for SLA performance, incidents and capacity. Check that certifications are still current, and review access and continuity controls each year. Reassess straight away after a new jurisdiction, special category data, a major architecture change or a serious incident.[4][24][26][27] Those reviews should flow straight into the board pack.

Report material cloud arrangements in RAG status, with SLA breaches, incident trends, audit findings, concentration risk and resilience test results - including recovery time objectives and identified vulnerabilities - so non-technical board members can grasp the position fast and decide what needs attention.[4][24][27]

Key takeaways for a compliant cloud migration

Classify early. Work out whether the service supports a critical or important function, what data it processes and which regulatory duties apply. That decision shapes the depth of due diligence, the contract terms you need and how closely the service should be watched.

Verify, don’t assume. Security certifications and resilience commitments need proof. Check audit reports, backup and recovery test records, and business continuity test outcomes.

Negotiate clear rights. Data handling terms, audit and regulator access, sub-outsourcing controls, and exit and portability clauses are how you keep control of a regulated activity when a third party delivers it.[2][4][10]

Assign controls explicitly. Every control needs a named owner on each side. Record that in your shared responsibility matrix and tie it to your risk register and internal audit cycle.

Keep due diligence, board papers, risk assessments, monitoring reports and remediation logs current and version-controlled. They are the evidence regulators, internal audit and investors will ask to see.[4][25][26][27]

FAQs