Cloud Compliance: What Businesses in Regulated Industries Must Know

Moving to the cloud does not move your regulatory obligations to your cloud provider.

That is the single most important thing for any business in healthcare, financial services, payments, insurance, legal services or the public sector to understand. Amazon Web Services, Microsoft Azure and Google Cloud can provide infrastructure that meets demanding security standards, but whether your systems, data and processes comply with the rules that apply to you remains your responsibility.

In practice, cloud compliance comes down to five things. You need to know which regulations apply to your data and services. You need to understand exactly which controls your provider handles and which you must handle yourself. You need to know where your data is stored and who can access it. You need technical controls, such as identity management, encryption, logging and secure configuration, that you can prove are working continuously, not just on audit day. And you need contracts and exit plans that satisfy regulators' expectations about outsourcing and resilience.

This guide explains each of these in plain terms, with a focus on the frameworks most relevant to businesses operating in the UK, Europe and the United States. It is a practical overview rather than legal advice. Regulations differ by sector and jurisdiction, and some are changing quickly, so confirm specific requirements with your compliance team, regulator guidance or qualified advisers.

What cloud compliance means, and why the shared responsibility model matters

Cloud compliance is the work of making sure that the way you use cloud services meets the legal, regulatory and contractual requirements that apply to your business. That includes data protection laws, sector regulations, industry standards such as PCI DSS and obligations you have agreed with customers.

It differs from traditional on-premises compliance in one fundamental way: responsibility is split. Every major cloud provider publishes a shared responsibility model. In simple terms, the provider is responsible for the security of the cloud, including physical data centres, hardware, networking and the underlying virtualisation layer. You are responsible for security in the cloud, including how you configure services, who has access, how data is classified and protected, and how your applications behave.

Where the line falls depends on the type of service. With infrastructure as a service, such as virtual machines, you manage the operating system, patching, network rules and everything above them. With platform as a service, such as managed databases, the provider handles more of the stack, but you still own access control, data and configuration. With software as a service, such as Microsoft 365 or Salesforce, the provider runs almost everything, yet you remain responsible for user accounts, permissions, data and how the service is set up.

The practical risk is assuming that because the provider holds strong certifications, your environment is compliant. It is not. A provider's ISO 27001 certificate covers the provider's controls, not your configuration. Industry analyst Gartner predicted in 2019 that through 2025, 99 percent of cloud security failures would be the customer's fault, largely due to misconfiguration. The 2019 Capital One breach is a well-known illustration: a misconfigured web application firewall in the company's AWS environment allowed an attacker to access data on around 100 million people in the US and about 6 million in Canada. The cloud infrastructure itself was not breached. In 2020, the US Office of the Comptroller of the Currency fined Capital One 80 million dollars, citing failures in risk management when moving operations to the cloud.

The regulations that matter, sector by sector

Most regulated businesses are subject to several overlapping frameworks at once: a general data protection law, sector-specific rules and industry standards required by customers or partners. The following overview covers those most often relevant to cloud use. It is not exhaustive, and the details matter, so treat it as a map of where to look.

Data protection: relevant to almost everyone

If you process personal data about people in the UK or EU, the UK GDPR or EU GDPR applies, regardless of sector. For cloud use, the key requirements are a lawful basis for processing, appropriate security measures, a data processing agreement with each provider acting as your processor, rules on transferring data outside the UK or European Economic Area, breach notification within 72 hours where required, and the ability to honour individuals' rights. In the United States there is no single federal privacy law, but a growing number of states have comprehensive privacy laws, and sector laws apply on top.

Healthcare

In the US, the Health Insurance Portability and Accountability Act (HIPAA) governs protected health information. Guidance from the Department of Health and Human Services makes clear that a cloud provider that creates, receives, maintains or transmits electronic protected health information on behalf of a covered entity is a business associate, even if the data is encrypted and the provider does not hold the key. That means you need a business associate agreement (BAA) with the provider, and you must only use services covered by it. The major providers offer BAAs, but not every service they sell is in scope. HHS proposed significant updates to the HIPAA Security Rule in early 2025, so check the current status.

In the UK, health and care organisations using NHS data must meet the Data Security and Protection Toolkit standards, and NHS England publishes guidance on using cloud services for health and care data. Healthcare data breaches are also particularly costly: IBM's annual Cost of a Data Breach research has reported healthcare as the industry with the highest average breach cost for many consecutive years.

Financial services

Financial regulators focus heavily on outsourcing, operational resilience and third-party risk. In the EU, the Digital Operational Resilience Act (DORA) has applied since January 2025. It requires financial entities to manage ICT risk, report major incidents, test resilience and maintain a register of ICT third-party arrangements, with specific contract requirements for services supporting critical or important functions. It also creates an oversight framework for critical ICT third-party providers, under which the European supervisory authorities have begun designating major technology firms, including large cloud providers.

In the UK, the Prudential Regulation Authority's supervisory statement SS2/21 on outsourcing and third-party risk management and the Financial Conduct Authority's guidance on outsourcing to the cloud set out expectations for due diligence, contracts, data security, audit access and exit planning. The UK has also introduced a regime for critical third parties to the financial sector, with rules in force since January 2025. In the US, banking regulators issued joint interagency guidance on third-party risk management in 2023, and the New York Department of Financial Services' cybersecurity regulation (23 NYCRR 500) applies to many firms licensed in New York.

Payments

Any business that stores, processes or transmits cardholder data must comply with the Payment Card Industry Data Security Standard. The current version, PCI DSS v4.0.1, includes requirements that became mandatory in March 2025. Using a cloud provider certified as a PCI DSS service provider helps, but your own environment, applications and processes must also be compliant, and you should obtain your provider's responsibility matrix showing which requirements each party covers.

Government and defence

Cloud services used by US federal agencies generally require FedRAMP authorisation. US defence contractors handling controlled unclassified information face requirements under NIST SP 800-171 and the Cybersecurity Maturity Model Certification (CMMC) programme, which is being phased into contracts. UK public sector organisations follow government guidance such as the National Cyber Security Centre's Cloud Security Principles.

Cross-sector security standards

Even where no specific regulation applies, customers and partners in regulated industries often require evidence such as ISO/IEC 27001 certification or a SOC 2 Type II report. Cloud-specific extensions include ISO/IEC 27017 for cloud security controls and ISO/IEC 27018 for protecting personal data in public clouds. In the EU, the NIS2 Directive has broadened cybersecurity obligations to many more sectors, including healthcare, digital infrastructure and some manufacturing, with national implementation progressing at different speeds.

Data residency, sovereignty and international transfers

Where data lives, and who can reach it, is one of the most frequently misunderstood parts of cloud compliance. Three related ideas are worth separating.

Data residency is the physical location where data is stored and processed. Cloud providers let you choose regions, such as London, Frankfurt or Virginia, and some regulations or contracts require data to stay within a particular country or region.

Data sovereignty concerns which country's laws apply to data and who can compel access to it. Data stored in a European region of a provider headquartered in another country may still be subject to that country's laws in some circumstances. This concern has driven demand for sovereign cloud offerings, such as Microsoft's EU Data Boundary and dedicated European sovereign cloud services announced by several major providers.

International transfers are movements of personal data out of the UK or European Economic Area, including remote access from another country. Under the GDPR, these require a legal mechanism: an adequacy decision, standard contractual clauses or another approved safeguard, often supported by a transfer risk assessment. After the Court of Justice of the European Union invalidated the EU-US Privacy Shield in its 2020 Schrems II ruling, the EU adopted the EU-US Data Privacy Framework in 2023, and the UK followed with its own extension, often called the UK-US data bridge. These frameworks allow transfers to certified US organisations, but they have faced legal challenges, so monitor their status.

A practical point often missed is that choosing a European or UK region does not by itself prevent international transfers. Support staff, logging, backups, managed services and sub-processors may involve other countries. Check your provider's documentation on where each service stores and processes data, including metadata, telemetry and support access, and review the list of sub-processors.

To stay in control, start by classifying your data so you know what is personal, sensitive or subject to specific residency requirements. Use organisation-level policies, such as AWS Service Control Policies, Azure Policy or Google Cloud organisation policy constraints, to restrict which regions resources can be created in. Encrypt sensitive data with keys you manage, and for the most sensitive workloads consider keys held in your own hardware security module or an external key management service, which can limit the provider's ability to access readable data.

Assessing cloud providers and contracts

Regulators expect you to carry out due diligence before relying on a cloud provider and to keep monitoring it afterwards. For the large hyperscale providers, much of the evidence is readily available. For smaller SaaS vendors that hold regulated data, you may need to ask harder questions.

Review independent assurance

Start with the provider's compliance documentation. AWS Artifact, the Microsoft Service Trust Portal and Google Cloud's compliance reports manager give customers access to audit reports and certificates. Look for reports relevant to your obligations, such as SOC 2 Type II, ISO/IEC 27001, 27017 and 27018, PCI DSS attestations, FedRAMP authorisations, and sector-specific attestations where they exist. Check the scope carefully. A certification may cover some services and regions but not others. Read the exceptions in SOC reports, and note any "complementary user entity controls", which are the controls the provider expects you to operate.

Check the contract terms regulators care about

For regulated outsourcing, especially in financial services, contracts typically need to address several specific points. These include a clear description of the services and service levels, data location and processing rights, security obligations, incident notification timelines, rights of access and audit for you and your regulator, sub-outsourcing controls, cooperation with regulators, business continuity commitments, and termination and exit assistance. DORA sets out specific contractual provisions for ICT services, and UK regulators' outsourcing guidance has similar expectations.

Hyperscale providers generally offer standard addenda for regulated customers, such as financial services amendments, data processing agreements and HIPAA business associate agreements, because negotiating bespoke terms with every customer is impractical. Review these carefully against your regulatory requirements rather than assuming they are sufficient.

Do not overlook SaaS

Compliance programmes often concentrate on infrastructure and neglect SaaS tools, yet SaaS applications frequently hold the most sensitive data: customer records in a CRM, financial information in accounting platforms, health records in practice management software, and confidential documents in file-sharing tools. Apply proportionate due diligence to every SaaS provider that processes regulated data, and keep an up-to-date register of them. (Internal link suggestion: a guide to vendor risk management or third-party security assessments.)

The technical controls regulators expect

Regulations rarely specify exact technologies, but they consistently expect appropriate measures in a few core areas. In the cloud, these are the controls that sit on your side of the shared responsibility line.

Identity and access management

Most cloud incidents involve access that should not have existed or credentials that were stolen. Enforce multi-factor authentication for all users, with phishing-resistant methods for administrators where possible. Apply least privilege, giving each person and system only the permissions it needs. Avoid using root or global administrator accounts for daily work. Use single sign-on connected to your central identity provider, so that access is removed promptly when people leave. Review privileged access regularly and use time-limited elevation rather than permanent administrator rights.

Encryption and key management

Encrypt sensitive data at rest and in transit. All major providers encrypt storage by default, but regulated workloads often call for customer-managed keys, which give you control over key rotation, access and revocation, and a clear audit trail of key use. Decide where keys will be held, who can use them and how access is logged. For the highest-sensitivity data, options such as dedicated hardware security modules or external key management can further limit provider access.

Logging, monitoring and incident response

You cannot prove compliance, or investigate an incident, without reliable logs. Enable audit logging across all accounts and subscriptions, such as AWS CloudTrail, Azure Monitor activity logs and Google Cloud Audit Logs. Send logs to a central, tamper-resistant location with retention periods that meet your regulatory requirements. Monitor for suspicious activity, and make sure your incident response plan covers cloud scenarios, including how you will meet notification deadlines such as the GDPR's 72-hour breach notification rule or DORA's incident reporting requirements.

Secure configuration

Misconfiguration remains one of the most common causes of cloud data exposure: publicly accessible storage buckets, open database ports, overly permissive network rules and disabled logging. Define secure baselines using recognised benchmarks, such as the CIS Benchmarks for each cloud platform, and enforce them through policy. Cloud security posture management tools, including native services such as AWS Security Hub, Microsoft Defender for Cloud and Google Security Command Center, can continuously check configurations against these baselines and against compliance frameworks.

Backup, resilience and recovery

Regulators increasingly expect firms to demonstrate that critical services can withstand and recover from disruption. Back up important data, including to a separate account or location protected from deletion by the same credentials, test restores regularly, and design critical systems to tolerate the failure of a single availability zone or region where appropriate. Document recovery time and recovery point objectives and test whether you can actually meet them.

Vulnerability and change management

Keep operating systems, containers and dependencies patched, scan for vulnerabilities and control changes to production. Using infrastructure as code, such as Terraform or the providers' native tools, makes changes reviewable, repeatable and auditable, which helps considerably when an auditor asks how a setting was changed and who approved it.

Continuous compliance: automation and evidence

Traditional compliance worked on an annual cycle: prepare for the audit, gather evidence, pass, and then let things drift until next year. That approach does not suit the cloud, where infrastructure can be created, changed and deleted in minutes by anyone with the right permissions. A configuration that was compliant on Monday can be non-compliant by Tuesday.

Continuous compliance means checking controls automatically and constantly, so problems are found and fixed in hours rather than discovered months later.

Map controls to frameworks once

Many regulations and standards overlap. Requirements for access control, encryption, logging and incident response appear, in slightly different words, in the GDPR, HIPAA, PCI DSS, ISO 27001, SOC 2 and DORA. Rather than managing each framework separately, build a single set of internal controls and map each one to the requirements it satisfies. The Cloud Security Alliance's Cloud Controls Matrix is a useful starting point, because it is designed for cloud environments and already maps to many common frameworks.

Enforce policy as code

Preventive controls stop non-compliant resources from being created in the first place. Organisation-level guardrails, such as AWS Service Control Policies, Azure Policy and Google Cloud organisation policies, can block actions like creating resources in unapproved regions, disabling encryption or making storage public. Checking infrastructure code before deployment, with tools that scan Terraform or similar templates for policy violations, catches issues before they ever reach production.

Detect and remediate drift

Detective controls continuously compare live environments against your baselines. Native services such as AWS Config, Azure Policy compliance reporting and Google Cloud's Security Command Center, along with third-party posture management platforms, can flag drift and in some cases fix it automatically. Route findings to the people who own the affected resources, with clear priorities, so alerts lead to action rather than an ever-growing backlog.

Collect evidence automatically

Auditors and regulators want proof. Automating evidence collection, such as configuration snapshots, access reviews, logs of key use, patch status and training records, reduces audit preparation from weeks of screenshots to a much smaller task. Compliance automation platforms can help smaller teams manage frameworks like SOC 2 and ISO 27001 by connecting to cloud accounts and other systems to gather evidence continuously.

Operational resilience, concentration risk and exit planning

Financial regulators in particular have shifted their attention from "is the data secure?" to "can the business keep operating if something goes wrong?" This is often called operational resilience, and it changes how cloud arrangements are assessed.

The UK's operational resilience rules for banks, insurers and other financial firms require them to identify their important business services, set impact tolerances for the maximum tolerable disruption and show that they can remain within those tolerances in severe but plausible scenarios. DORA introduces similar expectations across the EU financial sector, including resilience testing and management of ICT third-party risk. For firms using the cloud, this means understanding which important services depend on which cloud services and regions, and how they would continue if those services were unavailable.

Regulators are also concerned about concentration risk: the fact that a large share of the financial system, and of many other sectors, depends on a small number of cloud providers. This is the reason for the new oversight regimes for critical third parties in both the UK and EU. For individual firms, it means thinking carefully about dependencies, including indirect ones, where your SaaS providers may themselves run on the same cloud platform you do.

Plan your exit before you need it

Regulated firms are generally expected to have documented exit strategies for material outsourcing arrangements, covering both planned exits, such as moving to another provider, and stressed exits, such as a provider failing or a sudden contractual dispute. A credible exit plan identifies the data, configurations and services you would need to move, how you would extract them, where they would go, how long it would take and who would do the work.

You do not need to be ready to switch providers overnight, and running everything across multiple clouds is expensive and complex. A more practical approach for most businesses is to reduce lock-in where it matters: keep data in exportable formats, use infrastructure as code so environments can be rebuilt, document dependencies on proprietary services and periodically test the ability to restore critical data outside the primary environment. (Internal link suggestion: a guide to cloud disaster recovery or business continuity planning.)

Common cloud compliance mistakes

Assuming the provider's certifications cover you. Provider certifications are necessary but not sufficient. They cover the provider's side of the shared responsibility model. Your configurations, access controls, applications and processes need their own assurance.

Using services outside the compliance scope. Not every service from a provider is covered by its HIPAA business associate agreement, PCI DSS attestation or other certifications, and new services often take time to be added. Check the in-scope service lists before using a new service for regulated data, and consider policies that block unapproved services.

Letting shadow cloud grow. Teams sometimes create cloud accounts or sign up for SaaS tools outside central oversight, often with a company credit card. These environments rarely meet the organisation's controls. Central account management, procurement checks and periodic discovery help bring them into view.

Treating compliance as an annual project. Passing an audit once a year while configurations drift in between leaves you exposed most of the time. Continuous monitoring makes compliance a normal part of operations.

Ignoring data in non-production environments. Copies of production data used for testing or development often have weaker controls. Use masked or synthetic data where possible, and apply equivalent controls where real data is necessary.

Keeping logs that nobody reviews, or not keeping them long enough. Logs are valuable only if they are retained for the required period, protected from tampering and actually monitored.

Writing policies that do not match reality. Auditors compare what your policies say with what actually happens. A policy that promises quarterly access reviews you never carry out creates more risk than having no such policy at all.

A practical roadmap for building a cloud compliance programme

For a business that is early in its cloud journey, or whose cloud estate has grown faster than its controls, the work can seem overwhelming. Breaking it into stages makes it manageable.

Stage 1: Understand your obligations and assets

Identify which regulations, standards and contractual requirements apply to you, and which data and services they cover. Build an inventory of cloud accounts, subscriptions, projects and SaaS tools, and classify the data in each. Without this foundation, every later decision is a guess.

Stage 2: Assess the gaps

Compare your current environment against the controls you need. Use a recognised framework or your provider's own guidance, such as the security pillars of the AWS Well-Architected Framework, the Microsoft Cloud Security Benchmark or Google Cloud's security foundations guidance, alongside your regulatory requirements. Rank gaps by risk, focusing first on issues that could expose regulated data or prevent you from detecting an incident.

Stage 3: Establish a secure foundation

Set up or tidy your account structure, central identity with multi-factor authentication, organisation-wide guardrails, centralised logging and baseline configurations. Many organisations build this as a "landing zone", a standard, secure template for all cloud environments, so that every new workload starts from a compliant base.

Stage 4: Address contracts and third parties

Put the right agreements in place with each provider, such as data processing agreements, business associate agreements and financial services addenda, and complete due diligence on SaaS providers that hold regulated data. Maintain a register of these arrangements, which DORA in particular requires of financial entities.

Stage 5: Automate and operate continuously

Implement continuous monitoring, policy as code and automated evidence collection. Assign ownership for remediating findings, test incident response and recovery regularly and review access periodically.

Stage 6: Prepare for audits and review regularly

With continuous monitoring in place, audits become a matter of presenting evidence rather than scrambling to create it. Review your programme at least annually and whenever regulations, services or business activities change.

For many businesses in regulated industries, the hardest part is not understanding the requirements but finding the time and specialist skills to implement them alongside day-to-day operations. An experienced cloud infrastructure and security partner can help design a compliant landing zone, map controls across frameworks and set up the automation that keeps compliance continuous, while your team retains ownership of the decisions that matter.