Privacy Threat Modeling

Privacy Threat Modeling (CDPSE): Privacy Risk Management and Compliance

Privacy Threat Modeling: A Complete Guide for the CDPSE Exam

1. What Is Privacy Threat Modeling?
Privacy threat modeling is a structured, repeatable way to find, analyze and rank threats to the privacy of individuals. These threats come from the way a system, process or product collects, uses, stores, shares and disposes of personal data.

Traditional security threat modeling focuses on protecting the organization's assets. Privacy threat modeling differs in two ways:
• It focuses on harm to the data subject.
• It looks beyond attacks to privacy-specific problems, such as excessive collection, unexpected secondary use, linkability, re-identification, lack of transparency and loss of individual control.

Put simply, it asks: "What could go wrong for the people whose data we process, and what are we going to do about it?"

2. Why Is It Important?
• Privacy by Design and by Default: Regulations such as GDPR (Article 25) require privacy to be built in from the start. Threat modeling is one of the main techniques that puts this principle into practice during design.
• Cost of remediation: Fixing a privacy flaw during requirements or design is far cheaper than fixing it after deployment, a breach or a regulatory finding.
• Supports DPIAs/PIAs: Threat modeling feeds the risk identification part of a Data Protection Impact Assessment or Privacy Impact Assessment.
• Beyond security: A system can be perfectly secure and still violate privacy, for example by collecting too much data or profiling users without consent. Threat modeling exposes these non-breach harms.
• Accountability and evidence: Documented threat models show regulators, auditors and customers that the organization took a risk-based approach.
• Common language: It brings privacy, legal, engineering, security and business stakeholders together around one view of data flows and risks.
• Prioritization: It helps direct limited resources toward the highest-impact privacy risks.

3. Key Concepts and Frameworks

a) LINDDUN
LINDDUN is the best-known privacy threat modeling framework, developed at KU Leuven. Its seven threat categories are:
• Linkability: connecting two or more items of interest (actions, data, identities) to the same person, even without knowing who that person is.
• Identifiability: being able to identify a data subject from data or actions.
• Non-repudiation: the individual cannot deny an action, which can be harmful in privacy contexts such as whistleblowing or anonymous voting.
• Detectability: being able to tell whether an item of interest exists, even without seeing its content.
• Disclosure of information: unauthorized exposure of personal data (overlaps with confidentiality).
• Unawareness / Unintervenability: data subjects are not informed about, or cannot control, the processing of their data.
• Non-compliance: processing that does not follow legislation, regulation, policy or consent.

The LINDDUN process:
1. Model the system, usually with a Data Flow Diagram (DFD).
2. Map each DFD element to the threat categories that apply to it.
3. Identify specific threat scenarios using threat trees.
4. Prioritize threats by risk.
5. Choose mitigation strategies and privacy-enhancing technologies (PETs).

Variants include LINDDUN GO (a lightweight card-based version) and LINDDUN PRO (a systematic version).

b) STRIDE and why it is not enough on its own
STRIDE stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Elevation of Privilege. It is a security threat model and covers mainly the Disclosure aspect of privacy. Note that LINDDUN treats Non-repudiation as a privacy threat, while STRIDE treats Repudiation as a security threat. This shows how privacy and security goals can conflict.

c) Other relevant models and references
• Solove's Taxonomy of Privacy: four groups of harm: information collection, information processing, information dissemination and invasion.
• NIST Privacy Framework and the NIST Privacy Risk Assessment Methodology (PRAM): PRAM introduces problematic data actions and privacy engineering objectives:
  - Predictability: reliable assumptions about how data is processed.
  - Manageability: granular administration of data, such as alteration, deletion and selective disclosure.
  - Disassociability: processing without association to individuals.
• Contextual Integrity (Nissenbaum): privacy is violated when information flows breach the norms of the context in which the data was shared.
• PASTA, Attack Trees and the OWASP approach: general threat modeling methods that can be adapted to privacy.
• ISO/IEC 29134 (PIA guidelines) and ISO/IEC 27701 (privacy information management).

4. How It Works: Step by Step

Step 1: Define scope and context
• Identify the system, project or process and its business purpose.
• Identify the legal basis, applicable laws and contractual obligations.
• Identify stakeholders: data subjects, controllers, processors and third parties.

Step 2: Inventory and map personal data
• Use the data inventory or Record of Processing Activities (RoPA).
• Classify data, especially sensitive or special categories.
• Build a Data Flow Diagram with:
  - external entities (users, third parties)
  - processes
  - data stores
  - data flows
  - trust boundaries
• Cover the full data lifecycle: collection, use, storage, sharing, retention and destruction.

Step 3: Identify threats
• Apply a framework such as LINDDUN to each element.
• Ask questions such as: Can records be linked across datasets? Can pseudonymized data be re-identified? Do users know about this processing? Can they object or delete? Is the data used beyond its original purpose? Is data transferred across borders without safeguards?
• Consider both malicious actors and well-meaning insiders, as well as system design flaws.

Step 4: Analyze and prioritize risk
• Estimate likelihood and impact, with impact measured on the individual: financial, reputational, physical, psychological or discriminatory harm.
• Also consider organizational impact: fines, litigation and loss of trust.
• Rank threats using a risk matrix or scoring method.

Step 5: Select mitigations
• Avoid: do not collect the data at all (data minimization), or redesign the feature.
• Reduce: apply privacy-enhancing technologies and controls, including:
  - pseudonymization and anonymization
  - encryption and tokenization
  - differential privacy and aggregation
  - access controls and purpose-based access
  - consent management and just-in-time notices
  - data subject rights tooling
  - retention limits
• Transfer: use contractual controls with processors, or insurance (accountability remains with the controller).
• Accept: formally document residual risk, with sign-off by the appropriate risk owner.
• Hoepman's privacy design strategies are a useful guide: Minimize, Hide, Separate, Aggregate, Inform, Control, Enforce, Demonstrate.

Step 6: Validate, document and communicate
• Verify that controls are implemented and effective through testing, code review and audit.
• Record decisions, residual risks and owners in a privacy risk register.
• Feed results into DPIAs and report to governance bodies.

Step 7: Review continuously
Update the threat model when any of these change:
• the architecture
• the data elements
• vendors
• purposes
• the regulatory landscape

Integrate threat modeling into the SDLC or DevOps pipeline, for example at design reviews and major releases.

5. Where It Fits in CDPSE
The topic appears mainly in the Privacy Governance domain (risk management, DPIAs) and the Privacy Architecture domain (privacy by design, technical controls, the SDLC). The CDPSE perspective is that of a practitioner who implements privacy into technology. Expect questions about:
• when to perform threat modeling
• who should be involved
• what inputs it needs
• which framework fits
• how outputs drive control selection

6. Exam Tips: Answering Questions on Privacy Threat Modeling
• Timing: If asked WHEN threat modeling should be done, the best answer is almost always early, during requirements or design, and repeated when significant changes occur. Avoid answers like "after go-live" or "after an incident" unless the question is about the next step after a change.
• First step: If asked what to do FIRST, choose understanding the system and its data flows: a data inventory, data mapping or DFD. You cannot identify threats to data you have not mapped.
• Data subject perspective: Privacy threat modeling measures harm to individuals. If one option focuses on impact to data subjects and another on IT assets only, prefer the data subject option.
• LINDDUN vs STRIDE: If a question asks for a framework built specifically for privacy threats, the answer is LINDDUN. STRIDE is security-focused. Know all seven categories and be able to classify a scenario, for example:
  - users not told about tracking = Unawareness
  - combining datasets to profile someone = Linkability
  - re-identifying pseudonymized records = Identifiability
  - processing without a lawful basis = Non-compliance
• Privacy is not just security: Watch for scenarios where data is encrypted and secure but still over-collected or used for an incompatible purpose. The right answer addresses minimization, purpose limitation or transparency, not more encryption.
• Best mitigation: The strongest control is usually to eliminate or minimize the data (avoidance), then de-identification, then other controls. If not collecting the data meets the business need, that is generally the BEST answer.
• Relationship to DPIA: Threat modeling is an input to, or component of, a DPIA/PIA. It does not replace the legal assessment. If a question asks what is required by regulation for high-risk processing, the answer is a DPIA, with threat modeling supporting it.
• Stakeholders: The best answers involve cross-functional participation: privacy, security, legal, architects, developers and business owners. Avoid options where IT or security alone completes it.
• Living document: Answers stating the model is updated with system changes, new vendors, new purposes or new laws beat answers treating it as a one-time exercise.
• Residual risk: Risk acceptance must be documented and approved by the appropriate business or risk owner, not by the engineer or the privacy analyst alone.
• Third parties and transfers: Trust boundaries in the DFD often reveal data leaving the organization. Expect questions where the right answer is to assess vendors, apply contractual clauses, or evaluate cross-border transfer mechanisms.
• Key ISACA words: Watch for FIRST, BEST, MOST, PRIMARY and GREATEST. Eliminate technically true but reactive options, and choose the proactive, risk-based, governance-aligned one.
• Scenario method:
  1. Identify the personal data involved.
  2. Identify where it flows.
  3. Name the privacy threat category.
  4. Consider the harm to individuals.
  5. Pick the control that addresses the root cause, preferably at the design level.
• PETs vocabulary: Know the difference between anonymization (irreversible, may take data out of regulatory scope) and pseudonymization (reversible with additional information, still personal data). Questions often test this when discussing mitigation of identifiability threats.

7. Quick Practice Examples
Q: A development team is designing a new mobile app that collects location data. When should a privacy threat model be performed?
A: During the design phase, before development begins, and revisited when features change.

Q: Analysts can combine anonymized purchase records with public social media data to identify customers. Which LINDDUN category applies?
A: Linkability, leading to Identifiability.

Q: What is the BEST way to mitigate a threat that a feature collects date of birth when only age verification is needed?
A: Minimize collection by verifying age (for example, a yes/no over-18 flag) without storing the full date of birth.

8. Summary
Privacy threat modeling is a proactive, design-stage, data-subject-centric discipline. It works by:
• mapping personal data flows
• systematically identifying privacy-specific threats (with LINDDUN as the reference framework)
• ranking them by harm and likelihood
• selecting proportionate controls, with minimization first
• keeping the model current throughout the lifecycle

For the CDPSE exam, remember: early, mapped, cross-functional, privacy-specific, minimization-first, documented and continuously updated.