The PII That Slipped Through
A healthcare-adjacent wellness app uses Amplitude to track onboarding. A new engineer adds a signup_completed event with event_properties.email and event_properties.diagnosis_code to help debug a support ticket. The events flow through the Amplitude SDK directly from the client. Two weeks later, a privacy review flags that diagnosis codes are sensitive health data and the app's consent banner only covers analytics, not health data. Roughly 12,000 events carry the diagnosis code. The team also uses a warehouse export and a downstream BI dashboard. The compliance lead asks you to fix it and prove it is fixed.
1. What is your remediation plan, in order, and what does each step accomplish?
Read the worked answer
- Stop the bleeding first. Remove the
diagnosis_code(andemail) from the event in code and ship a fix. This prevents new sensitive data from arriving. Confirm with a short-window event check that the property no longer appears. - Assess scope. Query events where the property exists to confirm the count, time range, and which users are affected. This defines the blast radius for the privacy team.
- Delete or redact. Use Amplitude's data deletion tooling to remove the property from stored events, or transform it out at ingest if available. Coordinate with the warehouse team to purge the exported copies and the BI dashboard's source table, because deleting in Amplitude does not delete downstream copies.
- Fix the pipeline. Add a tracking-plan rule that blocks or strips sensitive property names at ingest so this class of mistake cannot recur.
- Prove it. Re-run the query showing zero events with the property, and get written confirmation from the warehouse and BI owners that their copies are purged.
Order matters: stop new data, then clean historical, then prevent recurrence, then document.
2. How should the team decide whether client-side SDK tracking is appropriate here at all, and what would you change?
Read the worked answer
Client-side tracking sends data from the device, so anything in the event payload is exposed to the client and leaves the device. For sensitive health data, that is the wrong default.
Decision criteria:
- Sensitivity of the data. Health data should not be collected client-side unless there is a clear, consented purpose.
- Consent coverage. The consent banner covered analytics, not health data, so collecting it was out of policy regardless of transport.
- Necessity. Ask whether the diagnosis code is needed for product analytics at all. Usually it is not; a coarse category or a boolean is enough.
Changes:
- Keep the client SDK for behavioral events (screen views, taps) with no sensitive properties.
- Move any sensitive or identifying attributes to a server-side source (e.g. a warehouse or server-side event API) where access is controlled and auditable.
- Add a tracking-plan allowlist so only approved properties can be sent.
- Update the consent flow so data collection matches what users agreed to.
This separates behavioral analytics (client) from sensitive attributes (server, governed).