The snapshot that was never public until it was
CareLoop sells a patient-portal SaaS to 40 hospitals. Its stack is containers on Amazon EKS, documents in S3, patient records in RDS for PostgreSQL Multi-AZ (a managed service), and e-signature handled by an external SaaS vendor. CareLoop's SOC 2 covers the application but not the cloud configuration. On a Friday a developer troubleshooting slow queries takes a manual RDS snapshot and sets it to public so a colleague can restore it into a personal account without ticket delays. Six days later a CSPM scan flags it; the snapshot contains PHI for 12,000 patients. The CTO's first reaction: "RDS is a managed service, so AWS is responsible for who can access that snapshot, and we pay the e-signature vendor to be compliant, so our exposure there is theirs too."
1. Allocate responsibility for the exposure across AWS, CareLoop, and the e-signature vendor. Where exactly does the CTO's reasoning fail?
Read the worked answer
Shared responsibility is partitioned by layer and by activity, not by whether a service is labelled "managed."
AWS owns security of the cloud: physical facilities, hypervisor, the network, and the managed engine itself - including patching PostgreSQL and operating the snapshot-sharing feature. AWS also supplies the guardrails (account-level block-public-access for snapshots, IAM conditions, AWS Config rules, KMS) and, in recent years, blocks public snapshot sharing by default for accounts that have not opted in.
CareLoop owns security in the cloud: identity and permissions, data classification, and configuration of the service it consumes. Modifying a snapshot's restoreAttribute to all is an authenticated API call made with a CareLoop principal against CareLoop's data. That is unambiguously a customer action. "Managed" removes operating-system patching from CareLoop's plate; it never transfers authorisation decisions.
The e-signature vendor is a processor handling a separate data flow under a BAA. Its compliance attestation does not extinguish CareLoop's obligations as covered entity or controller for that flow, and it is irrelevant to the RDS snapshot - a different system entirely. The CTO is using one vendor's SOC 2 to explain away an incident that vendor never touched.
The binding point: regulatory liability for PHI stays with CareLoop regardless of who operates the infrastructure or which processor touches which flow.
2. Which controls failed, and in what order should they be remediated? Separate preventive-technical, detective, and contractual controls.
Read the worked answer
Preventive (highest value, do first).
- Organisational block-public-access for snapshots, plus an SCP denying
rds:ModifyDBSnapshotAttributewhere the attribute value includesall- this removes the capability outright rather than detecting its use. - Enforce AWS Backup plans for all RDS instances and restrict manual snapshot creation to break-glass roles, eliminating the ad-hoc debug workflow that created the snapshot.
- Encrypt snapshots with customer-managed KMS keys whose key policy grants decrypt only to named workload roles. A publicly restorable snapshot is worthless if the copier cannot decrypt it; the key policy is the real boundary, not the sharing flag.
- Least privilege on the developer role: no snapshot or attribute-modification permissions in production.
Detective. A Config rule for public RDS snapshots plus Security Hub aggregation, alerting to on-call within minutes. Six days of exposure is the finding that matters most in the post-incident review - the ability existed, the detection existed on paper, and nobody was paged.
Contractual. Refresh the BAA with the e-signature vendor to confirm breach notification timelines, subprocessor disclosure, and audit rights - but as a separate workstream, because it had no bearing on this event.
Order: stop the capability (block public access, SCP), then shorten detection, then remove the workflow that motivated the misuse. Contract review runs in parallel.
3. The six-day detection gap is the finding the board will focus on. What architecture and process changes close it, and what would you measure?
Read the worked answer
Architecture. Aggregate findings from every account into the security account using Organizations-level Config aggregation and Security Hub, with GuardDuty and Config delegated administration rather than per-account consoles. Then automate the response: an EventBridge rule matching public-exposure findings invokes a remediation function that removes the public attribute and re-shares nothing, with a notification to the data owner. Preventive controls should mean this almost never fires; the automation exists for the config-to-capability drift that always appears in a 240-account estate.
Process. Route only defined high-severity classes to the on-call pager; the rest go to a daily queue. Alert fatigue is the most common reason a six-day gap becomes thirty. Inject canary resources monthly - deliberately create a public snapshot in a sandbox account and measure how long until the pager fires and how long until remediation completes. If the canary is not caught, the pipeline is broken, not the analyst.
Measure.
- Median detection latency for public-exposure finding classes (target under 15 minutes).
- Percentage of those findings auto-remediated without human action.
- Coverage ratio of backup-plan-managed databases versus manually created snapshots.
- Time from finding to attribute removed, tracked separately from time to detection - they fail for different reasons.
Be explicit with the board that detection is the second-best control here: the snapshot should never have been shareable by a developer role in the first place.