8.1 Privacy Engineering: Data Purpose, Minimization, and Lifecycle

Information security protects confidentiality, integrity, and availability. Privacy also examines harmful effects of processing that the organization is authorized to perform. A system can be free from data breaches yet still pose privacy risks due to excessive collection, purpose drift, over-retention, or inference of sensitive attributes.

This lesson presents engineering practices and does not replace legal advice for the applicable jurisdiction. Specific legal foundations, rights scopes, notification requirements, and cross-border obligations must be confirmed by legal and privacy officers.

Start with Data Processing Activities Rather Than Database Tables

Personal data can appear outside the main database:

Collection → API/log/queue → Main storage → Analysis/model → Third parties
              └→ Cache/search/backups/customer exports

A data inventory must at least record: field or category, data subject, source, explicit purpose, legal basis for processing, system location, recipient, access roles, retention or deletion rules, cross-border and sensitivity levels, and owner.

IP addresses, device IDs, precise location, behavioral sequences, and stable pseudonyms (even without names) can still identify or link to individuals. Do not skip analysis by stating "we only store anonymous IDs."

Purpose limitation before data modeling

State the purpose before collection and map each field to it. This table uses hypothetical rescue-service requirements; periods such as 24 hours must follow the actual purpose and applicable requirements:

Data	Purpose	Necessary?	Retention trigger
Service area	Scheduling and safety response	Yes; precision can be reduced	Reduce granularity after the service session ends
Precise GPS trajectory	Real-time rescue operations	Only during active task	Delete the original trajectory 24 hours after the task ends
Device ad ID	No clearly defined purpose	No	Not collected

"May be useful for future analysis" is not a valid, testable purpose. New uses require compatibility assessments and risk evaluations. Where necessary, provide renewed notice or establish the appropriate processing basis. Existing storage does not authorize every new use.

Data minimization is more than just reducing the number of columns

Minimization can occur at multiple levels:

• Do not collect: If only an age band is needed, do not collect birth dates;
• Reduce precision: Use region instead of exact coordinates;
• Reduce frequency: Trigger events instead of continuous tracking;
• Process locally: Make decisions on the device and upload only the result;
• Separate identity: Store business records and identity mappings separately, with independent access controls;
• Limit derivations: Do not generate all profiles or insights simply because raw data exists;
• Limit access: Analysts should only see the views necessary to complete their tasks.

Encryption protects collected data, but it cannot prove that the collection itself was necessary. Deleting unnecessary data is typically the most effective way to reduce leakage risks.

Retention is an executable rule

"Retain data based on business needs" cannot be automated. Instead, retention policies must be explicitly defined as:

retention = duration + start event + legal hold override + deletion method

A different reporting system might specify: "Delete precise locations 90 days after report closure; retain aggregated statistics for two years; pause deletion for a lawful investigation hold and record its approver." These are example periods. Give holds a scope, review date, and release condition so they do not become permanent retention switches.

A TTL that covers only the main table is insufficient. Retention rules must propagate to search indexes, object storage versions, caches, message dead-letter queues, data lakes, logs, training datasets, and backups. Backups typically cannot be deleted on a per-record basis. Instead, use short retention periods, key isolation, and replay the deletion ledger before restored data becomes accessible. Verify cleanup in indexes and caches too. The ledger may itself contain personal identifiers, so minimize its fields and restrict retention and access.

A Data Subject Request Is a Sensitive Identity Workflow

The applicability of access, correction, deletion, restriction, and portability requests varies by law and use case. Engineering processes must prevent attackers from exploiting these requests to extract other users' data:

1. Authenticate the requester, and use step-up authentication for sensitive data exports;
2. Identify all systems and processors containing relevant data;
3. Assess third-party and internal security information under applicable rights and exceptions, redacting only on a justified basis; an "internal" label alone is not a blanket exclusion;
4. Deliver or execute actions through secure channels;
5. Log the scope, justification for exceptions, completion time, and downstream confirmation;
6. Never create new full data copies in tickets or emails.

Deleting an account takes more than a DELETE on the users table. It requires handling content ownership, financial or security retention policies, shared objects, audit immutability, and identity mapping. Records that can be anonymized must be assessed for whether they can reasonably be linked back to a person, rather than replacing names with deleted-user alone.

Privacy by Default; Product Default Settings

New accounts should start with the minimal necessary public scope, the shortest reasonable retention period, and the least amount of telemetry. Optional analytics or data sharing should not be enforced through pre-checked boxes or dark patterns. Notifications must describe actual data flows, not obscure them with vague claims like "improving the experience" across ten different use cases.

Access to data and changes in its usage must be audited, but audit logs themselves may contain personal data. Only record fields essential for the investigation, restrict access and retention, and prevent business administrators from deleting records that could be detrimental to their own interests.

Pre-deployment Checklist

• Does each data type have a clear purpose, designated owner, and justification for processing?
• Can the same functionality be achieved without collection, with reduced precision, or through local processing?
• Are data flows into logs, third parties, models, or backups documented in the current inventory?
• Is data retention defined with a clear start date, expiration period, hold period, and a verifiable path for deletion?
• Can user-request workflows cover all applicable copies without exposing sensitive information from other users?
• Could new use cases or fields trigger a re-evaluation of privacy impact?

Rehearse deletion with one synthetic user record. Confirm it reaches the main store, index, and a test backup, then delete it and restore the old backup. Keep the restored environment closed to readers until the deletion ledger has been replayed. Verify queries, exports, and background jobs cannot retrieve the record. The next lesson examines linkage risks in pseudonymous and purportedly anonymous data.

References

• European Commission, Principles of the GDPR
• NIST, Privacy Framework 1.0
• NIST, Privacy Framework 1.1 Project Status