Tema: privacy-engineering
-
Handling a data subject request as an engineering process: export and delete
Treat a person's request for a copy or deletion of their data as a job: verified intake, one exporter per store in the data map producing a manifest, delivery through an expiring authenticated download, deletion through the pipeline, exemptions listed with reason codes, and a synthetic-subject test on a fixed cadence; which requests must be honoured and when is not addressed.
-
Differential privacy in one paragraph, and where it does not fit
Differential privacy bounds how much any one person's record can change the output distribution of a query mechanism, by adding calibrated noise and charging each answer to a budget; it fits repeated aggregate releases over large populations and does not fit record-level data, small groups, exact operations or one-off internal analyses.
-
Privacy review checklist for a feature
Ten questions a reviewer answers before a feature ships: inventory of new personal data, minimisation decisions, retention job, access and access logging, export and deletion coverage, preference purposes, third-party flows, a short LINDDUN pass, test data, and a recorded result; engineering properties only, no legal assessment.
-
Test data without production personal data
Give development, CI and staging realistic data by generating it: classify columns, write seeded generators that pass the application's validators, produce volume with generate_series, copy only distributions from production, mark generated records recognisably, and remove the shortcut of dumping production.
-
Consent and preference records as data: what was chosen, when and through which surface
Model a person's choices as append-only events (subject, purpose, choice, time, source, text version) with a derived current-state view that every consumer reads at the point of use; a boolean on the user row cannot answer what was agreed at the time of a given action or which users a banner bug affected.
-
Access logs for personal data: recording who read which record
An access log for personal data records reads, not only writes: actor, subject, object, reason and time, emitted at the application read path and reconciled with database-level statement logging for paths that bypass it; it must answer subject-centric questions such as who looked at this person's record in the last year.
-
Making reads of personal-data tables visible to the team reduces broad queries against those tables
Hypothesis: once every statement against tables holding personal data is logged (PostgreSQL's log_statement controls which SQL statements are logged) and the log is shown to the team in a weekly digest, the share of broad reads (no predicate on a person identifier, or a wildcard column list) falls, while the number of legitimate narrow reads stays the same; a proposed before-and-after test, with no result claimed.
-
Data minimisation as a schema and logging discipline
Store only the personal data a feature needs, at the coarsest precision that serves it, and keep identifiers out of logs by allowlisting fields; every column, log field and derived store that carries personal data is a design decision with a purpose, an owner and an expiry, not a default.
-
Implementing a retention schedule as deletion jobs
A retention schedule is only real when each data class has a mechanism that deletes on time: partition drops for time-partitioned tables, lifecycle rules for object storage, batched idempotent DELETE jobs elsewhere, each with a metric for the oldest remaining record and an alert when that age exceeds the period.
-
How do teams verify that a deletion removed every copy of a person's data, and what did the verification find?
Open question: a deletion job reporting done is not the same as the data being gone (dead row versions before VACUUM, object versions, caches, indexes, analytics copies, backups, logs, third parties); which teams verify end to end, by which method, and which stores still held data after a completed deletion?
-
Pseudonymisation versus anonymisation as engineering techniques
Pseudonymisation swaps direct identifiers for tokens while keeping a way back (a key or a lookup table) and leaves one record per person; anonymisation aims to remove the association between records and people for everyone. Use keyed HMAC per purpose for pseudonyms, and treat a pseudonymised table as personal data with quasi-identifiers still in it.
-
Privacy threat modelling with LINDDUN in outline
Walk a data flow diagram element by element against the seven LINDDUN threat types (linking, identifying, non-repudiation, detecting, data disclosure, unawareness and unintervenability, non-compliance), record scenarios per element, and pick mitigations from a short menu; a one-session format modelled on a STRIDE session.
-
Deletion pipelines across services, derived stores and backups
Model deletion of one person's data as a job with a state per store in the data map: fan out an event, require each owning service to report done with counts, handle versioned object storage and derived stores explicitly, bound how long backups keep the data or destroy per-subject keys, and keep a suppression list so restores can re-delete.
Legible por máquina: JSON