Public Reporting Bucket: Is It a Breach, and What Do You Encrypt?
You are the privacy and security lead for a patient-scheduling SaaS used by 300 clinics, holding records for about 1.1 million patients in AWS us-east-1. Data at rest uses provider-managed SSE-S3. TLS terminates at the load balancer and traffic is plaintext between services inside the VPC.
An external researcher reported that a "reporting" bucket containing 8,400 CSV exports was public-read. S3 access logs show 11 GET requests from two external IPs over the three days before you closed it. The CSVs contain appointment dates, clinic names, and patient names; the patient ID column is a pseudonymous internal identifier whose mapping table lives in the production database.
Separately, a new DLP tool produces 3,800 alerts a day, roughly 90% of them from the customer-support mailbox and a claims-integration feed. Your three analysts have stopped reviewing the queue. The privacy officer wants to know by end of day whether this is a notifiable breach, and legal wants a cryptography remediation plan for the next budget cycle.
1. Is this a notifiable breach? What facts do you need, and what do you do with the answer?
Read the worked answer
You cannot answer on the evidence in front of you, and you should say so rather than guess in either direction - but the default posture is to prepare to notify while you investigate.
Facts that change the answer.
- Was the data actually retrieved or only listed? Eleven GETs suggest real object retrieval, not just enumeration. Pull the object keys requested, the response codes, and bytes sent. A GET that returned 403 is not a download.
- Is it identifiable? Name plus clinic plus appointment date is generally enough to infer that a person received care somewhere. The pseudonymous ID does not save you if the mapping table is reachable - pseudonymous is not anonymous under most privacy regimes.
- Were any of the CSVs test or synthetic data? Sort the 8,400 objects by creation date and origin job. This is the single largest factor that could reduce scope.
- Who were the two IPs? Researcher infrastructure, a scanner, or a competitor changes the risk narrative, not the legal classification.
Process. Preserve logs before anything else, brief counsel, apply your jurisdiction's definition and its clock (some require notice within 30 or 60 days of discovery, not of confirmation). If the platform handles protected health information for US clinics, the HIPAA breach assessment and business-associate obligations sit on top of state law. Record the decision and its reasoning either way.
Fix the premise. Encryption at rest would not have prevented this - the bucket was public. Access control is the control that failed.
2. Legal wants a cryptography remediation plan. What do you prioritize and why?
Read the worked answer
Prioritize by what reduces the impact of the next exposure, not by what is easiest to buy.
1. De-identify what does not need to be identifiable. The reporting bucket should never have held names. Replace direct identifiers with tokens, keep the mapping in a separate store with its own access control, and have reporting consume tokenized views. This is the highest-value change because it converts every future leak of analytics data into a low-impact event. Field-level encryption on the identifier columns achieves a similar result for data in use, at the cost of query complexity - worth it for the most sensitive fields, not for everything.
2. Fix key management, not just the algorithm. Move from SSE-S3 to SSE-KMS with customer-managed keys, key policies separated by data classification, and rotation. One key for the whole estate means one policy mistake unlocks everything; separate keys per data class bound the blast radius. Put S3 Block Public Access at the account and organization level so a future bucket policy cannot override it.
3. Encrypt inside the VPC. Plaintext between services means any compromised pod or misconfigured security group reads everything. Enable TLS with service mesh or mTLS, or at minimum TLS to the database tier, starting with the services that touch patient data.
4. Backups and exports. The restore path is where encryption is most often missing. Encrypt snapshots and any extract that leaves the environment with a key you control.
Sequencing rationale: tokenization first (weeks, high impact), key management and public-access guardrails next (weeks), internal TLS last (months, largest engineering lift). Say explicitly in the plan that encryption is a control against disclosure of stored media, not against an application that is authorized to read the data.
3. How do you turn a 3,800-alert-per-day DLP queue into something three analysts can actually run?
Read the worked answer
An unread queue is worse than no queue: it creates documented knowledge of risk that nobody acted on, and it trains the team to ignore the tool.
Find the concentration. 90% of volume comes from two sources. The claims-integration feed is probably supposed to carry that data - that is a data-flow that needs an explicit policy exception, not an alert. Suppress it with a documented rule and a quarterly review. The support mailbox is a legitimate business process too, but a riskier one; handle it with sampling and threshold alerting rather than per-message alerts.
Tune before you hire. Validate regexes and document fingerprints against a week of real alerts. Most DLP noise is a rule matching a format broadly - a national ID pattern matching order numbers, for example. Precision first, then recall.
Tier by consequence, not by match count. Tier 1: large volumes of high-sensitivity data leaving to an unapproved external destination. Tier 2: sensitive data to an approved destination or an unusual internal one. Tier 3: single-record matches, sampled weekly. Only Tier 1 should page anyone.
Add an enforcement step where you can. Quarantine or block rather than merely alert on the highest-risk channel (personal webmail, public file-sharing). Blocking generates far fewer items to review, because the user either fixes it or asks for help.
Measure what matters: alerts per day, percentage triaged within SLA, confirmed incidents per quarter. Report those, not raw alert volume.