Privacy Engineering

Any data that can identify a specific individual, either directly (name, email, SSN) or in combination with other data. GDPR uses the broader term ‘personal data.’ Engineers must classify, protect, and track PII throughout the data lifecycle.

"Our data classification policy: Tier 1 PII (directly identifying: name, email, phone, SSN) — encrypted at rest, access logged, 90-day retention max. Tier 2 PII (indirect: IP address, user agent, device ID) — pseudonymised. Tier 3 (non-personal: aggregated counts) — standard storage. Every data field in the schema must have a classification tag."

Replacing identifying information with a pseudonym (e.g., replacing user email with a random UUID) such that the original data can be restored with a separate key. Reduces privacy risk but is not anonymisation — GDPR still applies to pseudonymous data.

"Analytics events store user_pseudonym (HMAC of user_id with a rotating key) instead of user_id or email. The analytics database can’t be joined back to PII without the HMAC key, which is stored separately. For GDPR deletion requests, we rotate the key for that user, making all historical events permanently unlinkable. This is pseudonymisation, not anonymisation."

A formal request from an individual to an organisation to access the personal data held about them — a right under GDPR (Article 15). The organisation must respond within 30 days, providing all personal data in a portable format.

"We built a DSAR portal: users click ‘Download my data’ and receive a complete export within 24 hours (under the 30-day legal requirement). The export aggregates data from 12 microservices: profile, orders, support tickets, event logs. Each service exposes a /user-data/{user_id} endpoint queried by the DSAR orchestrator."

GDPR Article 17 right allowing individuals to request deletion of their personal data under specific conditions. Technically challenging: data may be in transactional databases, backups, analytics systems, audit logs, and third-party systems.

"Our erasure implementation: soft-delete user account, anonymise PII in place (name → ‘Deleted User’, email → hashed), hard-delete after 30 days. Backup retention is 90 days — we note in our privacy policy that backups may contain data for up to 90 days post-erasure request. Audit logs keep user_id only (no PII)."

The principle (GDPR Article 5) that only data that is necessary for the specified purpose should be collected and retained. Excess data increases privacy risk, compliance scope, and breach impact.

"When reviewing the user signup form, we removed date of birth (not needed for our service), full address (we only need country for tax), and phone number (we had SMS 2FA but switched to TOTP). Each field removed reduces our data scope, our breach surface, and our GDPR compliance obligations."

A consent signal records that a user gave consent for a specific purpose (marketing, analytics, third-party sharing) with a timestamp, IP, and the exact consent text presented. A consent receipt is the record returned to the user confirming what was agreed.

"Our consent management platform records each consent: user_id, purpose_id, consent_text_version, timestamp, ip_address, opt_in_method. When a user revokes consent for analytics, the signal is propagated to the analytics pipeline within 24 hours and stored events from that user stop being processed. The audit trail demonstrates GDPR compliance."

A process to identify and minimise privacy risks before implementing a high-risk data processing activity. Required under GDPR for large-scale processing of sensitive data, systematic monitoring, or new technology that might impact individuals’ rights.

"Before building the employee location tracking feature, the DPO required a DPIA. The assessment identified risks: excessive data granularity (resolved by coarsening to city-level), undefined retention (resolved by 30-day limit), third-party access (rejected). The DPIA documented the risks, mitigations, and approvals before development started."