PII & data handling
Purpose: Keep personal data out of the places AEM makes it easy to leak: logs, caches, analytics, repositories and lower environments.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| All engineers | The rules |
| Tech leads | The classification decisions |
The fictional-but-instructive frame
Our running example is a health insurer's plan page — the plan content (premiums, benefits) is public marketing data; a member's details (name, member number, health selections in a quote form) are personal — for a real health insurer, among the most sensitive PII categories there are. The academy example is fictional; the discipline it illustrates is not.
Classify, then place
| Class | Examples (fictional) | Allowed locations |
|---|---|---|
| Public content | Plan pages, premiums | /content, caches, CDN — everywhere |
| Operational data | Sync states, rate tables | /var, logs (values ok, no persons) |
| Personal data | Quote form entries, member identifiers | Purpose-built stores with retention; transient in AEM at most |
| Sensitive personal | Health-related selections | Ideally never rests in AEM — straight through to the system of record |
The leak surfaces, and the rules
| Surface | Rule |
|---|---|
| Logs | No PII, ever (logging); IDs yes, identity no; scrubber at the shipper as backstop |
| Dispatcher/CDN caches | Personalised responses are never cacheable (no-store + excluded paths); a member's quote cached and served to the next visitor is the nightmare scenario (session 8 rules) |
| URLs | No PII in query strings/paths (they land in access logs, referrers, analytics automatically) |
| Analytics/tag dataLayer | Reviewed schema; no free-form fields fed from user input (third-party governance) |
| Repository (/var form dumps) | Form submissions forward to the system of record; any AEM-side buffer has retention + purge + ACLs (service-user scoped) |
| Lower environments | Prod content refreshes scrub/mask personal data (environments) — dev with real member data is a breach with extra steps |
| Backups & exports | Inherit the classification of what they contain; access accordingly (backup) |
Rights & retention plumbing
Deletion/access requests (whatever the applicable regime calls them) need an inventory: where could personal data be in this platform? — the table above is that inventory's skeleton. Keep it current per feature (security checklist data section), and retention automated (archiving & housekeeping), because a policy without a purge job is a liability list.