Defining Privacy Goals and Objectives (CIPT: Privacy by Design)
Overview
Defining privacy goals and objectives is the step in privacy engineering where broad privacy principles, legal obligations and stakeholder expectations are turned into clear targets. Those targets can then be designed, built, tested and measured. In the CIPT Body of Knowledge, this topic sits within Privacy by Design and privacy engineering. It links high-level privacy policy to concrete technical requirements and controls.
Why It Is Important
1. It bridges policy and engineering. Laws and principles such as the GDPR, the FIPPs and the OECD Guidelines are written in abstract language, for example 'data minimisation' or 'fairness'. Engineers cannot build 'fairness'. They can build a system that collects only the fields needed for a stated purpose. Goals and objectives make this translation possible.
2. It makes privacy proactive rather than reactive. This reflects Cavoukian's first Privacy by Design principle. When privacy objectives are set at the requirements stage, they shape the architecture. Without them, fixes get bolted on after a breach or complaint, at much higher cost.
3. It enables risk management. Clear objectives let teams spot when a data action could create a privacy problem for individuals. Teams can then rank risks and choose suitable controls.
4. It supports accountability and demonstrability. Regulators expect organisations to show compliance. Documented goals, mapped requirements and measurable objectives provide that evidence, for example in a DPIA or audit.
5. It aligns stakeholders. Legal, product, security, UX and engineering teams share a common vocabulary and agreed success criteria.
6. It complements security. Security goals (confidentiality, integrity, availability) do not cover every privacy concern. A perfectly secure system can still over-collect, profile, or surprise users. Privacy objectives fill that gap.
What It Is: Key Frameworks You Must Know
1. NIST Privacy Engineering Objectives (NISTIR 8062)
NIST defines three privacy engineering objectives. They are designed to sit alongside the security CIA triad.
- Predictability: individuals, owners and operators can make reliable assumptions about personally identifiable information (PII) and how the system processes it. It relates to transparency, notice and purpose specification. Example: a user can predict that their location is used only for delivery tracking.
- Manageability: PII can be administered in a granular way, including alteration, deletion and selective disclosure. It relates to data subject rights, accuracy and correction. Example: a system lets a user delete one specific record without deleting the whole account.
- Disassociability: PII or events can be processed without being linked to individuals or devices beyond what operations require. It relates to minimisation, de-identification, pseudonymisation and anonymisation. Example: analytics run on aggregated or tokenised data.
NIST also defines privacy risk as a function of likelihood that a problematic data action occurs and the impact on individuals. Its Privacy Risk Assessment Methodology (PRAM) operationalises this.
2. Privacy Protection Goals (Hansen, Jensen and Rost / ULD Schleswig-Holstein)
These are also called the six protection goals. They pair three security goals with three privacy goals.
- Unlinkability: data cannot be linked across domains or purposes. This enforces purpose limitation and minimisation.
- Transparency: processing is understandable and verifiable by data subjects, operators and supervisors.
- Intervenability: data subjects and operators can intervene. Examples are correcting, erasing, objecting and withdrawing consent.
Together with confidentiality, integrity and availability, these goals often pull against one another. For example, transparency and confidentiality, or availability and unlinkability. Designers must balance them.
3. Sources of Privacy Goals
- Legal and regulatory requirements, such as GDPR Article 5 principles, Article 25 data protection by design and default, CCPA/CPRA and HIPAA.
- Principles frameworks: FIPPs, OECD Guidelines, APEC Privacy Framework and the seven Privacy by Design principles.
- Industry standards and contracts: ISO/IEC 27701, ISO/IEC 29100, PCI DSS and client contracts.
- Organisational privacy policy, values and risk appetite.
- User expectations and social norms. Contextual integrity (Nissenbaum) asks whether an information flow matches the norms of its context.
4. Goals vs Objectives vs Requirements vs Controls
- Goal: a broad, high-level aim. Example: minimise collection of personal data.
- Objective: a specific, measurable target that supports the goal. Example: the sign-up flow collects no more than 3 mandatory personal fields by release 2.0.
- Requirement: a testable statement the system must satisfy. Example: the system shall not store date of birth; it shall store only an over-18 flag.
- Control or design pattern: the mechanism that implements the requirement. Example: an age-verification service that returns a boolean.
Good objectives are usually SMART: Specific, Measurable, Achievable, Relevant and Time-bound.
How It Works: The Process
Step 1: Understand the context. Identify the system, its purposes, the data flows, the stakeholders and the data lifecycle: collection, use, retention, disclosure and destruction. Data flow diagrams and data inventories are typical tools.
Step 2: Gather obligations and expectations. Collect the applicable laws, policies, standards, contracts and user expectations for this system.
Step 3: Derive privacy goals. Express the obligations as goals, often grouped by a framework. Examples are the NIST objectives, the protection goals, or the GDPR principles of lawfulness, purpose limitation, minimisation, accuracy, storage limitation, integrity/confidentiality and accountability.
Step 4: Identify privacy risks and threats. Use threat models such as LINDDUN: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance. Use NIST problematic data actions or Solove's taxonomy of privacy harms. Determine which goals each risk threatens.
Step 5: Set measurable objectives and requirements. Convert each goal into SMART objectives and testable functional and non-functional requirements. Assign owners and acceptance criteria.
Step 6: Select strategies and controls. Map objectives to design strategies. A common set is Hoepman's eight privacy design strategies.
- Data-oriented strategies: Minimise, Hide, Separate, Aggregate.
- Process-oriented strategies: Inform, Control, Enforce, Demonstrate.
Then choose specific privacy-enhancing technologies (PETs) and patterns. Examples include encryption, pseudonymisation, differential privacy, consent management, access controls, retention automation and just-in-time notices.
Step 7: Verify, measure and iterate. Test against requirements and track metrics. Examples are number of fields collected, percentage of data pseudonymised, time to fulfil access requests, and retention compliance rate. Revisit objectives when the system, law or context changes. Privacy engineering is continuous across the SDLC.
Worked Example
A fitness app wants to share data with research partners.
- Goal (disassociability/unlinkability): research partners must not be able to identify users.
- Objective: before launch, all shared datasets meet a k-anonymity threshold of k of 10 or more, or use differential privacy with a defined epsilon budget.
- Requirement: the export pipeline shall remove direct identifiers and generalise date of birth to year and location to region.
- Control: an automated de-identification service with re-identification risk testing.
- Goal (predictability/transparency): users understand that data is shared for research.
- Objective: the in-app notice is shown before first sharing, with an opt-in rate tracked.
- Goal (manageability/intervenability): users can withdraw consent.
- Requirement: withdrawal stops future exports within 24 hours.
Common Tensions and Trade-offs
- Transparency vs confidentiality. Example: logging for audit creates more personal data.
- Availability and integrity vs unlinkability. Example: backups and identity verification require linkage.
- Utility vs disassociability. Example: more anonymisation reduces analytical value.
- Personalisation vs minimisation.
Privacy by Design favours positive-sum solutions (full functionality) over false trade-offs. Even so, exam scenarios often ask you to pick the best balanced option.
Exam Tips: Answering Questions on Defining Privacy Goals and Objectives
1. Memorise the NIST trio and their meanings.
- Predictability means reliable assumptions and transparency.
- Manageability means granular administration and data subject rights.
- Disassociability means processing without linking to individuals.
Questions often describe a scenario and ask which objective is involved. Match keywords:
- 'delete, correct, modify, granular' points to manageability.
- 'anonymise, pseudonymise, de-identify, unlink' points to disassociability.
- 'expectations, notice, surprise, trust' points to predictability.
2. Know the six protection goals and their pairs.
- Unlinkability is the privacy counterpart that relates to confidentiality and minimisation.
- Transparency addresses understanding.
- Intervenability addresses user and operator control.
Watch for questions that ask which goal conflicts with another.
3. Distinguish goals, objectives, requirements and controls. If an answer option is measurable and time-bound, it is an objective. If it says 'the system shall', it is a requirement. If it names a technology, it is a control. Questions often test whether you can spot the most specific or measurable option.
4. Remember that privacy is not the same as security. If a question asks what security alone fails to address, look for answers about over-collection, secondary use, lack of transparency, profiling, or user control.
5. Think 'earliest stage'. The best time to define privacy goals is during requirements and design, before coding. Answers suggesting this are usually preferred over post-deployment fixes.
6. Trace goals back to their sources. If asked where privacy requirements originate, the best answer typically combines laws, policies, standards, contracts and user expectations, not just one source.
7. Link objectives to risk. NIST defines privacy risk in terms of problematic data actions, likelihood and impact on individuals, not just on the organisation. Choose answers that focus on harm to individuals.
8. Recognise the threat models. LINDDUN maps threats to privacy goals. For example, Linkability and Identifiability threaten unlinkability or disassociability. Unawareness threatens transparency. Non-compliance threatens accountability.
9. Map to Hoepman strategies when asked how to achieve an objective. Minimisation goals use Minimise or Aggregate. Confidentiality and unlinkability use Hide or Separate. Transparency uses Inform. Intervenability uses Control. Accountability uses Enforce or Demonstrate.
10. Pick positive-sum, balanced answers. In trade-off scenarios, prefer the option that meets the business purpose while satisfying privacy objectives. Avoid options that sacrifice one entirely, unless the question makes clear a legal requirement forces that outcome.
11. Read scenario questions carefully for qualifiers. Words like 'BEST', 'FIRST' and 'MOST effective' matter. The FIRST step is usually understanding context and data flows or identifying requirements. The BEST objective is the most specific and measurable one.
12. Do not confuse disassociability with deletion. Removing linkage while keeping the data is disassociability. Deleting the data on request is manageability.
Quick Recap
- Privacy goals translate abstract principles into engineering targets.
- NIST objectives: Predictability, Manageability, Disassociability.
- Protection goals: Unlinkability, Transparency, Intervenability (plus CIA).
- Process: context, obligations, goals, risks, SMART objectives and requirements, strategies and controls, verify and iterate.
- In the exam, match scenario keywords to the right objective, prefer early and measurable approaches, and remember that privacy extends beyond security.
