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 applicable laws, and the rules that apply to cloud providers in Switzerland 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.

The data processing agreement with your cloud provider

If you keep personal data about customers, employees or contractors in a cloud service, the provider processes it on your behalf and becomes a processor.

Switzerland's Federal Act on Data Protection (nFADP) governs this in Article 9: a contract or legal basis suffices, provided the processor does only what the controller could lawfully do itself and no confidentiality duty stands in the way; the controller must satisfy itself the processor can guarantee data security (nFADP, Article 9 — unofficial translation, English not being an official language of the Confederation). Unlike the GDPR, it sets no mandatory content list.

The GDPR applies in addition if you offer goods or services to people in the EU, or monitor their behaviour there (Article 3(2)). Where it does, Article 28(3) requires a contract stipulating in particular 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.

Where the GDPR doesn't apply, those eight points are still a solid checklist (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. Switzerland's nFADP governs transfers abroad in Articles 16 and 17: "Personal data may be disclosed abroad if the Federal Council has decided that the legislation of the State concerned or the international body guarantees an adequate level of protection" (nFADP, Article 16(1) — unofficial translation). Otherwise, other safeguards apply — contractual clauses or standard clauses recognised by the FDPIC, binding corporate rules — or a narrow, case-by-case derogation (Article 17).

Annex 1 of the Data Protection Ordinance (DPO) lists the countries recognised as adequate: every EU and EEA state, the UK, Canada — and the United States, but only for organisations certified under the Swiss-U.S. Data Privacy Framework. The path there took years:

• 11 January 2017 — the Federal Council takes note of the Swiss-US Privacy Shield;
• 8 September 2020 — the Federal Data Protection and Information Commissioner (FDPIC) finds that the regime no longer ensures an adequate level of protection — the Commissioner's own assessment, not a court ruling: Switzerland has never had its own "Schrems" judgment;
• 14 August 2024 — the Federal Council adopts the Swiss-U.S. Data Privacy Framework;
• 15 September 2024 — it takes effect: the United States is added to Annex 1 of the DPO, for certified organisations only.

This Swiss framework rests on its own Federal Council decision, though it relies on the same US safeguards (Executive Order 14086). An appeal against the EU's equivalent decision is pending before the Court of Justice (case C-703/25 P) — concerning the EU's decision, not Swiss law.

If you store particularly sensitive data in the cloud, it's still sensible to choose an EU or Swiss region where the provider offers one, so a future change to the transatlantic framework's status doesn't affect you directly.

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.

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.

Switzerland's Information Security Act (ISA). NIS2 doesn't apply in Switzerland, but since 1 April 2025 the ISA has required cyberattack reporting, with fines possible from 1 October 2025: a report within 24 hours of detection (Article 74e — no English translation on fedlex; paraphrased from the French and German text), to the National Cyber Security Centre (NCSC). Obliged entities include cloud and data-centre providers and operators with a Swiss seat, (ISA, Article 74b(1)(t)), unless they provide no paid services to third parties (Cybersecurity Ordinance, Article 12(1)(e)). Maximum fine: CHF 100,000, for wilful non-compliance with an NCSC order, not per missed report.

This is a narrower regime than NIS2: a reporting duty and NCSC support, not the EU's full risk-management framework. NIS2 still matters to a Swiss business indirectly, though — through EU customers or suppliers who may contractually require NIS2-equivalent guarantees.

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.

Where the GDPR applies, Article 28(3)(g) gives you a starting point: the provider deletes or returns the data after the service ends, at your choice. It doesn't say anything about format or timescale, and Switzerland's nFADP sets no equivalent rule at all. 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) also helps: its chapter on switching data-processing service providers imposes concrete obligations on cloud providers (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: capped at the provider's actual cost until 12 January 2027, then free of charge (Article 29).

It protects only a "customer in the Union", though (Article 1(3)(f)): a Swiss business has no statutory rights under it unless its own contract grants them. The obligations still show what's worth asking a provider that also serves the EU.

That strengthens an EU customer's position, but doesn't excuse reading the contract: what counts as "exportable" says nothing about how usable the format actually is.

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 or Swiss 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 Switzerland and the EU/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?
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.