What it means
Privacy threat modeling identifies how data processing can create surveillance, linkability, identification, disclosure, exclusion, loss of control, or other adverse consequences.
Why it matters
Security threat models may protect confidentiality and integrity while overlooking harmful inferences, unexpected observation, manipulative choices, or legitimate-but-invasive processing.
Practical focus
- Map people, data, purposes, actors, trust boundaries, transformations, decisions, and power relationships.
- Use structured privacy-threat categories and misuse cases to analyze collection, linking, inference, access, sharing, retention, and user interaction.
- Convert findings into design requirements, mitigations, validation tests, ownership, and residual-risk decisions.
- Preserve this evidence: Retain the model, diagrams, assumptions, scenarios, affected groups, risk ratings, requirements, decisions, tests, and review history.
- Exercise this failure scenario: A technically authorized feature enables cross-context tracking or sensitive inference because the design review considered attackers but not privacy harms.
Common mistakes
- Using the label Privacy Threat Modeling without defining scope, ownership, decision authority, and the exact data, systems, people, or process affected.
- Treating a policy, contract, diagram, dashboard, or tool demonstration as proof that Privacy Threat Modeling operates consistently in production.
- Closing work without retaining the evidence needed to reconstruct the decision and verify the intended control outcome.
- Testing only the normal path and never rehearsing the failure condition: A technically authorized feature enables cross-context tracking or sensitive inference because the design review considered attackers but not privacy harms.
Certification relevance
This subject appears in or supports the following certification bodies of knowledge: