Bramble Retail: splitting responsibility for a managed database and testing what an ISO/IEC 27018 certificate actually proves
Bramble Retail holds profiles of 4.2 million loyalty customers in a public cloud. Two components are involved: self-managed virtual machines running the analytics application, and the provider's managed relational database holding profiles and purchase history. The provider's responsibility matrix marks guest OS patching and host firewalls as the customer's, and database engine patching as its own. Bramble's ISO/IEC 27001 statement of applicability contains no cloud-specific controls, and its privacy impact assessment states that PII processing is covered by the provider's ISO/IEC 27018 certificate. The provider's subprocessor list includes a support centre in a second country with console access to production. Bramble's policy requires all PII to be deleted within 30 days of contract termination; the contract is silent on deletion and allows a 90-day backup retention window.
1. Using the shared-responsibility split, what must Bramble document for the VM layer and for the managed database, and which cloud-specific control addresses this?
Read the worked answer
The split. For the self-managed VMs Bramble owns nearly everything above the hypervisor: guest OS patching, image hardening, host firewalls, local accounts, logging configuration and the application itself. For the managed database the provider patches the engine, but Bramble retains the data classification, the schema and row-level access design, database account and IAM policy, key custody if it uses customer-managed keys, backup retention decisions, restore testing, and monitoring of who read what.
Documentation required. A single control matrix, per service, with three columns: control objective, party responsible (provider, Bramble, or joint), and evidence source. The cloud-specific control is the ISO/IEC 27017 shared roles and responsibilities control, CLD.6.3.1, which requires that the allocation be defined and made available to both parties and to customers. The matrix should be traceable to actual documents - the provider's responsibility page, the contract, and Bramble's own procedures - and signed off by the service owner.
Consequences Bramble must also record. Its statement of applicability currently has no cloud controls at all, so the matrix has nowhere to land. Adding CLD.6.3.1, virtual-environment segregation (CLD.9.5.1), hardened images (CLD.9.5.2) and cloud-service monitoring (CLD.12.4.5) gives the assessment a structure to map onto. Note the edition: the 2015 numbering follows ISO/IEC 27002:2013, while later revisions renumber; cite the edition you actually apply.
2. Is the privacy impact assessment statement - that PII processing is 'covered by the provider's ISO/IEC 27018 certificate' - defensible? Justify your answer and list what Bramble still owes.
Read the worked answer
Not defensible. ISO/IEC 27018 is a code of practice for public cloud providers acting as PII processors. A certificate against it is evidence about the provider's processor-side controls: confidentiality undertakings for staff, restrictions on using customer PII for marketing, disclosure of subcontracted processing, breach notification to customers, and support for return, transfer and deletion. It is not a finding about Bramble's processing.
Bramble is the controller. It decides the purposes, the lawful basis, the retention period and who gets access. No provider certificate can establish those, and the certificate scope may exclude the support centre in the second country - check the scope statement and whether the subprocessor appears on it before crediting anything.
What Bramble still owes
- Article 28-style processor terms: instructions, confidentiality, assistance with data subject rights, deletion on termination, audit rights.
- A record of processing and an assessment that actually analyses the processing, including the console access from another country as a transfer and an access risk.
- Retention and deletion decisions, and the mechanism to enforce them.
- A functioning breach notification route and a decision log.
- Subject-access and erasure workflows that work across the analytics VMs and the managed database, including derived tables.
The PIA sentence should be rewritten to say what the certificate evidences, what it does not, and which Bramble controls close the rest.
3. Reconcile the 30-day deletion policy with the silent contract and 90-day backup window, and address the second-country console access.
Read the worked answer
Deletion. The conflict is real: policy promises 30 days, the contract promises nothing, and backups survive 90. Do not resolve it by quietly editing the policy to 90 days - that makes the documented requirement match the weakness rather than the obligation. Two parallel tracks:
- Negotiate. Add a termination clause with deletion of live data within 30 days, certified in writing, and a defined backup treatment: either accelerated expiry or cryptographic erasure with key destruction, plus a statement of the maximum residual period. This corresponds to the cloud-specific removal-of-assets-on-termination control (CLD.8.1.5 in the 2015 numbering) and to secure disposal expectations in ISO/IEC 27018.
- Interim. Until the clause exists, record a documented exception with a risk owner, a business justification, and the customer-facing exposure stated.
Console access from the second country. Treat it as a live risk, not a footnote. Require named administrators, confidentiality undertakings, background verification, session recording, just-in-time elevation, approval by Bramble before break-glass access, and monthly review of access logs. Confirm the transfer basis if the support centre reaches EU data. If the provider cannot evidence these, that is a control gap that changes the subcontractor risk rating - and it may be the finding that drives the contract renegotiation.