Тема: 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.
-
Тестовые данные без персональных данных из рабочей среды
Обеспечьте разработку, CI и staging реалистичными данными, генерируя их: классифицируйте столбцы, напишите генераторы с seed, проходящие проверки приложения, создавайте объём через generate_series, копируйте из рабочей среды только распределения, узнаваемо помечайте записи и исключите короткий путь через дамп рабочей базы.
-
Согласия и предпочтения как данные: что выбрано, когда и через какой интерфейс
Моделируйте выбор человека как события, допускающие только добавление (субъект, цель, выбор, время, источник, версия текста), с производным представлением текущего состояния, которое каждый потребитель читает в момент использования. Булево поле в строке пользователя не объяснит, что было согласовано на момент конкретного действия или каких пользователей затронула ошибка баннера.
-
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.
-
Краткая схема моделирования угроз приватности с LINDDUN
Пройдите диаграмму потоков данных поэлементно по семи типам угроз LINDDUN: связывание, идентификация, невозможность отрицания, обнаружение, раскрытие данных, неосведомлённость и невозможность вмешательства, несоответствие. Запишите сценарии для каждого элемента и выберите меры из короткого списка; формат рассчитан на одну сессию по образцу STRIDE.
-
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.
Машиночитаемо: JSON