47 Erasure Requests, a Free-Text Field, and Three Agencies With Admin
A wellness app with health-adjacent content runs CJA on a dataset containing account ID, hashed email, a free-text 'notes' field from customer support, and event-level product usage. Three external agencies have Workspace access; one holds admin rights. Over the last quarter the company received 47 GDPR erasure requests naming account IDs, and legal assumed CJA would remove them automatically. Dataset retention in the data lake is set to 25 months, but no retention setting has been applied at the data view level. A product manager built a shared workspace containing a freeform table with the free-text notes field broken down by account ID, and it is currently shared with all users. A regulator inquiry is due in three weeks.
1. Lay out the erasure response plan. What can CJA actually do, and how do you set legal's expectations without overpromising?
Read the worked answer
Start from what CJA can and cannot do, and put it in writing.
- CJA does not support ad-hoc row-level deletion the way a transactional system does. Erasure for AEP datasets is processed through the Privacy Service against dataset records. Before committing to legal, confirm with Adobe the current scope and processing time, and specifically whether CJA-held copies and historical aggregates are covered identically - do not assume they are.
- Sequence: identify every dataset containing the account ID; submit Privacy Service requests with the correct identity namespace and dataset IDs; check whether account ID is a person identifier or merely an attribute on a person row, because if it is an attribute, deleting the person may not remove the free-text note; retain the request records themselves as evidence.
- Do not promise 'deleted everywhere'. Promise: source dataset deletion via Privacy Service, plus a documented statement of what remains (aggregated, de-identified) and for how long.
- Close the loop in a memo, not a chat message - the regulator will ask for the record.
2. What governance changes would you make to the schema and retention settings so this does not recur?
Read the worked answer
Retention and schema control are the preventive half.
- The free-text support notes should never have entered an analytics dataset. Remove the field from the schema going forward and erase historical values via Privacy Service, or mask it with a derived field that is null for all values.
- Align retention. Set data view retention to match the 25-month data lake setting so analysis cannot reach past the governed window. Document the rationale - product-usage trend analysis needs 24 months, so 25 is defensible - because retention without a stated purpose gets challenged.
- Audit the rest. Any remaining free-text or high-cardinality personal fields need a documented purpose before they stay.
- Introduce a classification gate. New schema fields require a classification (public, internal, sensitive, personal data) before they can be exposed in a data view.
- Build a data map showing where personal data lives across datasets and views, reviewed quarterly.
The 47 requests are a symptom; an unclassified schema is the disease.
3. Design the access model. What do you do about agency admin rights and the over-shared workspace?
Read the worked answer
Three agencies with admin is the finding the regulator will care about most, and it must be fixed this week, not next quarter.
- Least privilege by role. Remove agency admin access immediately. Admin belongs to internal platform owners only.
- Product profiles per agency, scoped to the data views and components each one needs. Use component curation to hide anything sensitive, including account ID at row grain and the free-text notes.
- Separate build from publish. Agencies can create projects but not publish shared ones; ownership of shared workspaces reverts to internal staff.
- Handle the exposed workspace. Unshare it now, review its project history, and record who accessed it and when - legal will need that for the inquiry.
- Make access reviews routine: quarterly, on contract end, and mapped through SSO/IMS groups so leavers lose access automatically rather than by memory.
Report to legal in plain language: what was exposed, to whom, for how long, and what has changed since. Regulators respond better to a clear remediation narrative than to a technically perfect but vague one.