Using cloud services does not change what a company answers for. It changes only who performs which measure. The practical core of cloud security is therefore organisational rather than technical: know exactly where the line between provider and customer responsibility runs, and actually occupy your own side of it.
Shared responsibility
| Area | IaaS | PaaS | SaaS |
|---|---|---|---|
| Data centre, hardware, network | Provider | Provider | Provider |
| Virtualisation | Provider | Provider | Provider |
| Operating system, patching | Customer | Provider | Provider |
| Runtime, middleware | Customer | Provider | Provider |
| Application, configuration | Customer | Customer | Partly customer |
| Identities and permissions | Customer | Customer | Customer |
| Data and its classification | Customer | Customer | Customer |
The bottom two rows belong to the customer in every model. Reading only the upper rows produces the common false conclusion that choosing an established provider has answered the security question.
The most common incident is a misconfiguration
Not a break-in at the provider but your own setting is the usual trigger: publicly reachable storage, access rules drawn too wide, unprotected administrative endpoints, unused accounts with far-reaching rights, open interfaces without authentication. What works against that is a documented target configuration, a regular automated check against it, multi-factor authentication for every administrative path, and evaluation of the provider's logs inside your own operation.
The last of those is the one most often skipped. A provider that offers audit logs and a customer that never reads them together produce a service where nobody would notice a problem for months.
Contractual and data protection side
Where personal data is processed, the provider is normally a processor; a contract under Art. 28 GDPR is required, with binding instructions, arrangements for sub-processors, duties to assist, and deletion or return at the end of the contract. Also to be examined are the processing locations, the set of sub-processors, and whether data is transferred to third countries; such transfers require appropriate safeguards, and how those are structured is a question for legal review. The services in use belong in the records of processing activities and in the asset inventory.
Provider evidence
Audits of your own on site are practically impossible with large providers; evidence takes their place:
- ISO/IEC 27001: a certificate covering an information security management system; what decides is the scope, not the certificate as such.
- BSI C5: the criteria catalogue for cloud services issued by Germany's Federal Office for Information Security, widely used in Germany; the reports set out the customer's own duties to contribute, which are frequently read past.
- ISO/IEC 27017 and 27018: supplementary guidance in the 27000 family on cloud-specific controls and on handling personal data in public cloud services.
Every piece of evidence applies only to the scope it describes and to a particular period. The question to ask is therefore whether the service you use, and the region you use, are actually covered.
Exit and concentration
Two risks are regularly underestimated. First, dependency: without a documented exit plan naming data formats, migration routes, timelines and responsibilities, changing provider during a disruption is not a real option. Second, concentration: where several critical applications sit with the same provider or in the same region, a common point of failure arises that has to be assessed explicitly in the risk analysis.
What stays inside your own management system
Outsourcing shrinks operations, not governance. Cloud services have to be inventoried and their criticality assessed, permissions have to be reviewed, incidents at the provider have to arrive inside your own reporting process, and recovery has to be exercised. A service that belongs to nobody and appears in no exercise is the actual gap.