What is cloud security?
Cloud security is the protection of data, applications and access in environments a provider operates. It follows the shared responsibility model: the provider secures the platform, and the customer secures its configuration, identities, permissions and data.
For personal data, the customer remains the controller and must demonstrate compliance with the principles under Article 5(2) of Regulation (EU) 2016/679 (GDPR). How cloud services are integrated into an ISMS is covered in the guide on ISMS implementation.
How is responsibility split across IaaS, PaaS and SaaS?
The boundary moves with the service model; only identities, permissions and data always stay with the customer:
| Area | IaaS | PaaS | SaaS |
|---|---|---|---|
| Data centre, hardware, network | provider | provider | provider |
| Virtualisation | provider | provider | provider |
| Operating system, updates | 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 |
Choosing a certified provider therefore answers only the upper rows.
Misconfiguration: the customer side of cloud security
The settings of a cloud service sit with the customer, and so do the errors only the customer can fix:
- publicly accessible storage
- overly broad access rules
- administrative access without multi-factor authentication
- unused accounts with far-reaching rights
- interfaces without authentication
The countermeasures are a documented target configuration and an automated check against it at set intervals. Add multi-factor authentication for all administrative access and the analysis of the provider's logs in your own operations.
Data processing: what the contract under Article 28 GDPR covers
Where a cloud provider processes personal data on the customer's behalf, Article 28(3) GDPR requires a contract that binds the provider. Among other things, it covers:
- processing only on documented instructions, including transfers to third countries (point (a)),
- the conditions for engaging further processors (point (d), paragraphs 2 and 4),
- assistance with data subject rights and with the obligations under Articles 32 to 36 (points (e) and (f)),
- deletion or return of the data at the end of the contract (point (g)),
- information and audits, including inspections (point (h)).
The entry on the data processing agreement covers the contract in detail. The services in use also belong in the record of processing activities and in the asset inventory.
What evidence should a cloud provider supply?
A cloud provider evidences its side with certificates and attestations; Article 28(3)(h) also obliges it to allow audits, including inspections. Each piece of evidence holds only for its scope and its period:
| Evidence | What it shows | What the customer checks |
|---|---|---|
| ISO/IEC 27001 certificate | a certified information security management system | whether the service and region in use are within scope |
| BSI C5 Type 1 attestation | suitability of the controls' design at the time of the audit | audit date and scope |
| BSI C5 Type 2 attestation | additionally, the operating effectiveness of the controls over an audit period | whether the audit period follows on from the previous one |
According to the BSI, there is no certification procedure for C5 and therefore no C5 certificates. An auditor attests under ISAE 3000, and the report describes the service's conditions, such as the subcontractors used and the geographical location of the data centres. The comparison BSI C5 vs. ISO 27001 explains how the two differ.
An attestation always covers a completed period. No evidence covers the time between its end and today; that gap belongs in your own risk assessment.
Dependency and concentration: two provider risks
Dependency on a provider is under control only if an exit strategy with data formats, migration routes, deadlines and responsibilities is documented. Without one, switching provider during a disruption is not an available option.
Concentration arises when several critical applications sit with the same provider or in the same region. This creates a single point of failure; assess it explicitly in the risk analysis.
Cloud services as supporting assets in Rizzqo
Rizzqo models a cloud service as a supporting asset on which both sides of the shared responsibility meet. The provider's C5 attestation or certificate attaches as evidence to the relevant requirement, and so does the evidence of your own configuration.
The requirements of the catalogues held in Rizzqo, such as ISO/IEC 27002, appear on the asset. The named owner answers them and finalises them with name and timestamp. From the primary assets whose data and processes run through the service, the asset inherits the confidentiality rating and the flag for whether personal data is involved.