14.2 Privacy Goals, Objectives, and Translating High-Level Specifications into Low-Level Specifications
Key Takeaways
Privacy protection goals extend the security triad with unlinkability, transparency, and intervenability, a model used in Germany's Standard Data Protection Model.
NIST's privacy engineering objectives (predictability, manageability, disassociability) can serve as system-level goals alongside confidentiality, integrity, and availability.
Good privacy objectives are specific and measurable, such as 'no precise location stored longer than 30 days' rather than 'respect user privacy.'
Requirements flow from principle to goal to high-level specification to low-level specification to test, and each low-level item should trace back to the principle it implements.
Goals must be communicated where engineers work: design templates, privacy requirement catalogs, definitions of done, dashboards, and privacy champions.
14.2 Privacy Goals, Objectives, and Translating High-Level Specifications into Low-Level Specifications
Quick Summary: The BoK asks technologists to define and communicate privacy goals and objectives that guide privacy by design, and to interpret high-level specifications and align them, through low-level specifications, with the privacy by design principles. In practice that means picking a small set of privacy goals, turning them into measurable objectives, and refining each requirement until engineers can build and test it, while keeping a trace back to the principle it serves.
Cavoukian's seven principles (Section 14.1) say what privacy by design should achieve. Hoepman's strategies (Sections 14.3 and 14.4) give design patterns. This section is the bridge: how an organization states goals clearly enough that teams can make consistent decisions, and how a vague requirement becomes a specification someone can implement and verify.
Choosing Privacy Goals
A privacy goal is a lasting property the organization wants its systems to have. Two widely used goal sets complement each other:
Privacy Protection Goals
Researchers including Marit Hansen proposed extending the security goals of confidentiality, integrity, and availability with three privacy-specific goals. Germany's Standard Data Protection Model (SDM), used by German supervisory authorities, builds on them (together with data minimization):
| Goal | Meaning | Example Measures |
|---|---|---|
| Unlinkability | Data is processed only for its purpose and cannot easily be linked across purposes or domains | Purpose-separated stores, domain-specific pseudonyms |
| Transparency | Individuals, operators, and supervisors can understand the processing | Accurate notices, logs, documentation, data maps |
| Intervenability | Individuals and supervisors can intervene in processing | Consent withdrawal, rights tooling, the ability to stop processing |
These goals pull against each other and against security goals. Strong integrity logging can conflict with unlinkability, and availability through replication can conflict with intervenability (deleting every copy). Naming the goals makes these tensions visible so they can be resolved deliberately.
NIST Privacy Engineering Objectives
NIST's predictability, manageability, and disassociability (Section 16.1) play the same role for systems, and teams often use them as goals in architecture reviews.
Organization-Specific Goals
Many organizations also state goals in plain language, such as "Customers are never surprised by how we use their data," "We collect the least data needed," or "Sensitive data never leaves the region where it was collected." Plain-language goals communicate well; technical goal sets make them precise.
From Goals to Measurable Objectives
Objectives make goals measurable and time-bound. Weak objectives restate the goal; strong ones can be tested.
| Goal | Weak Objective | Strong Objective |
|---|---|---|
| Data minimization | "Collect less data" | "Every new event field is approved against a documented purpose before launch; 0 unapproved fields in production" |
| Intervenability | "Honor deletion requests" | "Verified deletion across all registered stores within 30 days for 99% of requests" |
| Unlinkability | "Limit tracking" | "No shared identifiers between the advertising and health product domains" |
| Transparency | "Be open with users" | "The privacy notice and app store labels are reconciled with observed SDK traffic every release" |
Objectives become KPIs and KRIs (Section 13.1) and appear in team goals, so progress is visible.
From High-Level to Low-Level Specifications
Privacy requirements arrive in high-level form: a law ("data protection by default"), a policy ("delete data when no longer needed"), or a principle ("privacy embedded into design"). Engineers need low-level specifications: schemas, configurations, algorithms, and tests. The refinement usually passes through four levels:
Interpreting a high-level specification means asking what it requires in this particular system: which data, which components, which conditions. Aligning it with the privacy by design principles means checking that each low-level choice actually serves the principle, not just the letter of the requirement. For example, a high-level specification "users can withdraw consent" could be met by a buried email address; aligned with Respect for User Privacy and Visibility and Transparency, the low-level specification becomes a one-click toggle that propagates withdrawal to every downstream system within minutes and confirms it to the user.
A Traceability Matrix
A simple traceability matrix keeps the chain intact and helps auditors:
| Principle | High-Level Specification | Low-Level Specification | Verification |
|---|---|---|---|
| Proactive not reactive | Every feature handling personal data gets a privacy review | Pull-request template requires a data-classification label; CI fails without it | CI logs |
| End-to-end security | Personal data is deleted at end of retention | TTL column on each table; nightly purge job; key destroyed for archived data | Purge job metrics; sampled audit |
| Positive-sum | Fraud detection without exposing identities to analysts | Analysts query tokenized data; re-identification only via audited service | Access logs |
| User-centric | People can see and edit inferred interests | Interests page backed by the profile service; edits apply within one hour | End-to-end test |
Standards that support this work include ISO/IEC 29100 (privacy framework and principles) and ISO/IEC TR 27550:2019, which describes privacy engineering for system life cycle processes, including how privacy requirements are derived and traced.
Communicating Goals and Objectives
Goals only guide design if engineers meet them in their daily work:
- Design templates with a privacy section that lists the goals and asks how the design meets each one.
- A privacy requirements catalog of reusable, pre-approved low-level specifications (for example, "standard retention job," "consent-gated SDK loader").
- Definitions of done that include privacy acceptance criteria (Section 16.3).
- Dashboards that show objective metrics by team.
- Privacy champions in each team who translate goals into local decisions.
- Leadership communication that explains why the goals matter, linking them to customer trust and regulatory duties.
Germany's Standard Data Protection Model extends the security goals of confidentiality, integrity, and availability with which privacy protection goals?
Unlinkability, transparency, and intervenability
Notice, choice, and enforcement
Authentication, authorization, and accounting
Predictability, portability, and profitability
A product requirement says, 'Users must be able to withdraw consent for personalized recommendations.' Which low-level specification best aligns this high-level specification with the privacy by design principles?
Record the withdrawal request but keep using the profile until the next annual data refresh.
Add an email address to the privacy policy where users can request withdrawal, with requests processed manually by the privacy team within 90 days.
Allow withdrawal only through the desktop website, not the mobile app.
Provide a one-click toggle that stops personalization, deletes the profile within an hour, and confirms it.
Which of the following is the best example of a measurable privacy objective?
We value our customers' privacy.
Privacy is everyone's responsibility.
Engineers should try to minimize the personal data they collect whenever it is convenient for the project schedule.
Precise location is deleted or aggregated within 30 days, verified weekly.
Sections you finish are checked off in the contents.