Cloud security: who's responsible for what, and what to ask your provider

"Is the cloud secure?" comes up in every conversation about moving company systems into cloud services. It's the wrong question. Large providers protect their infrastructure better than most businesses manage in their own server room. But cloud security isn't a property of the provider — it's the outcome of how the work is split between the provider and you, and part of that split always stays on your side, no matter what you pay.

This article answers the question worth asking instead: what the provider is responsible for, what you are, and how to check that before you sign. We've worked from what providers say about themselves, the text of the GDPR, and the rules that apply to cloud providers across the EU in 2026 — sources you can check yourself, not "one of our clients" stories.

Cloud security is a question of shared responsibility

Every large provider describes security with the same model — the shared-responsibility model. AWS puts it plainly: "Security and Compliance is a shared responsibility between AWS and the customer" — AWS is responsible for the security of the cloud, meaning the infrastructure, and the customer for security in the cloud, the scope of which depends on which services they use (AWS, shared-responsibility model). Microsoft says the split of tasks changes depending on whether the workload runs as SaaS, PaaS, IaaS or in your own data centre (Microsoft Learn).

Both descriptions point to the same rule, and it organises the rest of this article:

• the provider is responsible for physical data centres, hardware, networking and — higher up the stack — progressively more layers: the operating system, the platform, the application itself;
• the customer is always responsible for its own data, user accounts and who has access to what. On IaaS, that also includes the operating system and everything installed on it.

That last line has consequences that are easy to forget. The best-protected infrastructure won't help if an employee has a weak password with no second factor, a former employee's account still works, or a folder of customer data is shared with "anyone with the link". Those are all customer-side settings — and that's where most small-business problems actually start, not in a provider's data centres. How to lock down mailboxes, accounts and access on your own side is covered in our article on protecting company data.

Outages happen to providers too

The second illusion: a provider this big must always be up. Two well-known incidents in AWS's history show why availability needs to be planned for, not assumed — and why it's worth checking the cause at the source rather than trusting a summary.

The S3 outage, 28 February 2017. For several hours, the S3 storage service was down in one AWS region, and with it many sites and applications that depended on it. Contrary to what some guides still claim, it wasn't an attack. AWS described the cause in its own summary: an authorised employee, removing a small number of servers while debugging an issue, mistyped one of the command's parameters and removed far more servers than intended (AWS, summary of the S3 service disruption).

The DDoS attack on AWS DNS, October 2019. This attack really did happen — more than two and a half years later. AWS's DNS servers spent several hours fending off a denial-of-service attack, and the mitigations that suppressed it also blocked some legitimate customer queries along the way, making many services harder to reach (The Register, 22 October 2019, citing AWS's own statement).

Both incidents point to the same conclusion: even the largest provider can go down, from an attack or an ordinary human mistake. Three questions follow: what uptime does the contract actually guarantee, and what happens if it's missed; how many locations is your data stored in; and does the business have a plan for a few hours without this service.

A GDPR data processing agreement with your cloud provider

If you keep personal data about customers, employees or contractors in a cloud service, the provider is processing it on your behalf. You stay the controller under the GDPR, and the provider becomes a processor. That carries two obligations.

The first is about choice: a controller "shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures" (GDPR, Article 28(1)). The burden of assessing the provider sits with you, not with them.

The second is about form: processing must rest on a contract — a data processing agreement (DPA) — that sets out the subject-matter, duration, nature and purpose of the processing, and the type of data and categories of data subjects involved (Article 28(3)). The Article also lists eight things the contract must require of the processor. In particular, it must state that the processor:

a) processes the personal data only on documented instructions from the controller;

b) ensures that persons authorised to process the personal data have committed themselves to confidentiality;

c) takes all measures required pursuant to Article 32 (security of processing);

d) respects the conditions for engaging another processor;

e) assists the controller in responding to requests from data subjects exercising their rights;

f) assists the controller in complying with its own security, breach-notification and impact-assessment obligations;

g) at the choice of the controller, deletes or returns all the personal data after the end of the service, and deletes existing copies unless Union or Member State law requires storage of the personal data;

h) makes available all information necessary to demonstrate compliance and allows for audits, including inspections.

(GDPR, EUR-Lex, consolidated text)

In practice, large providers don't negotiate individual contracts with small businesses — they publish a standard DPA that you accept along with their terms of service. That doesn't excuse you from reading it. Check at least three things: whether it lists all eight elements, where the list of sub-processors is published and how you'll be told about changes to it, and exactly what happens to your data once the contract ends.

The security measures point (c) refers to are set out in Article 32 GDPR: pseudonymisation and encryption of data, the ability to keep systems confidential, intact and available, the ability to restore access quickly after an incident, and regular testing of those measures. It names no specific technology — only measures "appropriate" to the risk. Those four points are worth turning straight into questions for a cloud provider.

Where your data physically lives — and why it matters

Data in the cloud always sits in some specific data centre, in some specific country. As long as that's an EU or EEA country, the GDPR applies there exactly as it does at home. Transferring data outside the EEA is a different category entirely: Article 44 GDPR only permits it where the controller and processor meet the conditions set out in the chapter on transfers.

The simplest basis is a European Commission decision finding that a given country provides an adequate level of protection. For the United States, that decision is the EU–US Data Privacy Framework — a Commission implementing decision of 10 July 2023, covering US companies that have certified to the framework. Its status in 2026:

• on 3 September 2025, the General Court of the EU dismissed the action seeking to annul it (case T-553/23, Latombe v Commission), confirming that, on the date the decision was adopted, "the United States of America ensured an adequate level of protection for personal data transferred from the European Union to organisations in that country" (CJEU press release 106/25);
• an appeal against that judgment has since been lodged with the Court of Justice (case C-703/25 P), which, according to publicly available information, is still pending.

For now, the decision stands. Worth remembering: the two previous bases for transferring data to the US were both struck down by the Court — Safe Harbour by the judgment of 6 October 2015 (C-362/14), which "declares that the Commission's US Safe Harbour Decision is invalid" (CJEU 117/15), and Privacy Shield by the judgment of 16 July 2020 (C-311/18), which "invalidates Decision 2016/1250 on the adequacy of the protection provided by the EU-US Data Protection Shield" (CJEU 91/20). If you store particularly sensitive data in the cloud, it's sensible to pick an EU region where the provider offers one, so a future change to the framework's status doesn't affect you. Without an adequacy decision, Article 46(1) GDPR only allows transfers with "appropriate safeguards", such as the Commission's standard contractual clauses.

Certifications and rules to ask your cloud provider about

A certification doesn't guarantee security, but it shows the provider has submitted its processes to independent assessment. Two reference points matter most today.

ISO/IEC 27001:2022. This is the international standard for an information security management system. Worth knowing for 2026: certificates issued against the previous, 2013 version of the standard expired on 31 October 2025, at the end of a three-year transition period (IAF MD 26). If a provider cites an "ISO 27001:2013" certificate, it's no longer valid. Two further standards complement it for the cloud: ISO/IEC 27017 — security guidelines for cloud service providers and customers — and ISO/IEC 27018 — protection of personal data processed in the public cloud by processors.

NIS2. The EU's cybersecurity directive (2022/2555) names cloud computing service providers explicitly among the entities covered, under "Digital infrastructure" in Annex I. Member States had to adopt and publish the measures needed to comply by 17 October 2024, applying them from 18 October 2024. Transposition still varies: per the Commission's notice of July 2026, four Member States — Ireland, Spain, France and the Netherlands — had not yet notified full transposition and had been referred to the Court of Justice. So a provider covered by NIS2 carries statutory risk-management and incident-reporting duties, but the exact rules depend on where it operates. Whether your own business falls under NIS2 is a separate question, decided by sector, size and your Member State's law — mainly medium and large businesses in the sectors the directive lists.

Your cloud exit strategy: how you get your data back when you switch provider

The most commonly skipped security question isn't about attacks — it's about leaving. What happens to your data when you end the contract, the provider raises its prices, or it stops trading? A business that can't get its data back in a usable form is just as exposed as one that lost it outright.

The GDPR gives you a starting point here: under Article 28(3)(g), the provider deletes or returns the data after the service ends, at your choice. It doesn't, though, say anything about the format or the timescale. Those details need checking in the contract and in practice: can you export all the data yourself, in an open format (CSV, JSON, a standard database dump), without going through support; how long after termination the data stays accessible; whether export itself carries an extra charge.

Since 12 September 2025, the EU's Data Act (Regulation (EU) 2023/2854) helps here too. Its chapter on switching data-processing service providers covers cloud providers and imposes concrete obligations on them (EUR-Lex, English text):

• providers "shall not impose and shall remove pre-commercial, commercial, technical, contractual and organisational obstacles" to switching (Article 23);
• the contract must allow switching provider or porting all exportable data at the latest within a mandatory maximum transitional period of 30 calendar days, following a notice period that cannot exceed two months (Article 25);
• switching charges are being phased out: until 12 January 2027 they can only be reduced and capped at the provider's actual cost, and from 12 January 2027 the provider cannot charge for switching at all (Article 29).

That significantly strengthens the customer's position, but it doesn't excuse reading the contract: the rules cover data that can be exported, and whether the export format is actually usable is still yours to check.

The best way to check it is before you sign, on a trial account: export sample data and see whether it opens anywhere else. Five minutes will show whether you're choosing a service or a lock-in.

Cloud backup

A third illusion: since the data is in the cloud, it must be backed up. Providers do make sure their infrastructure doesn't lose data when hardware fails, but protection against your own mistake, a malicious deletion or an account taken over by an attacker is often a separate service or setting you have to turn on. If someone deletes a folder and the service keeps deleted files for 30 days, on day 31 the data is gone — even though the provider never had an outage.

For every service holding data that matters to your business, it's worth confirming: how long deleted data and previous versions are kept; whether you can restore the state from a few weeks ago; and whether a copy exists outside that same service — at another provider, or on a medium an attacker who takes over the account can't encrypt. We cover backup and recovery mechanisms for websites separately in our article on website backups.

10 questions to ask a cloud provider before you sign

Everything above boils down to a list of questions. Put them to every provider whose service will hold company data:

1. Where exactly will the data be stored, and can I choose an EU region?
2. Is a data processing agreement available that covers every element required by Article 28(3) GDPR?
3. Who are the sub-processors handling the data, and how will I be told about changes to that list?
4. Is data transferred outside the EEA — and if so, on what legal basis?
5. What security certification do you hold — ISO/IEC 27001:2022, 27017, 27018 — and can I see it?
6. What uptime does the contract guarantee, and what am I entitled to if it isn't met?
7. How are accounts protected — is two-factor authentication available, and can I enforce it for every user?
8. How long are deleted data and previous versions kept, and can I restore the state from a few weeks back?
9. In what format, and within what time, will you hand back my data when I end the contract — and how does the contract meet the switching obligations under the Data Act?
10. How, and within what time, will you notify me of a data breach?

A provider that answers these questions specifically, pointing to documents, is usually a safer choice than one that answers in generalities — whatever the size of its brand.

What's next

What cloud computing actually is, and how the IaaS, PaaS and SaaS models differ, is covered in our cloud computing article. For the SaaS model itself, see our guide to SaaS; for the obligations a website has under the GDPR, see our article on GDPR and privacy policies.