Don't Panic: Privacy Engineering

Privacy engineering is the craft of making privacy decisions behave like system properties instead of polite suggestions. It starts where the interesting trouble starts: with what a service actually does to people and their data. A database is only one stop on the tour, and it tends to acquire companions.

The useful unit is a data action, meaning collection, transformation, analysis, retention, disclosure, or disposal. Before this approach, teams often had policies describing good intentions and systems describing something else with considerable confidence. Mapping each action gives the conversation somewhere to stand: purpose, people, data, components, recipients, identity boundaries, retention, and controls.

The surprise is that privacy risk does not need an attacker. A feature can work as designed and still create a problem by exposing an inference, making an unexpected reuse, or turning deletion into ceremonial button pressing. The course's risk scenario links the action, its context, the people affected, the problem, and the consequence. That is far more useful than staring sternly at a category called "sensitive" and hoping it explains itself.

Three privacy engineering objectives keep the design work from becoming a grab bag. Predictability asks whether people and operators can make reliable assumptions about processing. Manageability asks whether authorized actors can alter, delete, or selectively disclose data. Disassociability asks where the system can avoid linking data to a person or device. They are lenses, not a magic three-item checklist. Most magic checklists have a troubling habit of disappearing during the first vendor integration.

Controls follow the risk. Collect fewer fields, reduce precision, separate identifiers, limit access, restrict recipients, set protective defaults, and enforce retention. Encryption matters, but it does not make unnecessary collection necessary. Pseudonymization helps, but a protected lookup can still reconnect a record. The architecture must say what changes, and the test must show that it changed.

Read the Course tabs when you need the full map from goal to evidence. Use Slides for the chain of decisions, Cheatsheet for the design moves and review triggers, and Reference for the NIST and regulator material behind them. Field Notes focuses on the awkward operational edges, where indexes, backups, preference propagation, and exceptions attempt to become somebody else's problem.