High-Level and Low-Level Privacy Specifications

High-Level and Low-Level Privacy Specifications: A Complete CIPT Guide to Turning Privacy Principles into Buildable Requirements

Introduction
Privacy by Design (PbD) says privacy should be built into systems from the start rather than added later. A principle like 'collect only what you need' cannot be coded directly, though. Engineers need precise, testable instructions. High-level and low-level privacy specifications close that gap. They are the layered requirements that turn laws, policies and principles into concrete design and implementation decisions.

For the CIPT exam you should understand three things:

• What each level contains.
• How the levels relate to one another.
• Why the move from abstract to concrete matters for building privacy-respecting technology.

1. Why High-Level and Low-Level Privacy Specifications Are Important

• They bridge legal and technical worlds. Lawyers and privacy officers speak in principles and obligations, such as GDPR Article 5, the FIPPs or the OECD Guidelines. Developers speak in data fields, APIs, retention jobs and encryption algorithms. Specifications translate the first language into the second.
• They make privacy testable. 'Respect user privacy' cannot be verified. 'Delete inactive account data after 24 months via an automated nightly job' can be tested, audited and demonstrated.
• They support accountability. Regulators expect organizations to show compliance (GDPR Article 5(2), Article 25 Data Protection by Design and by Default). If each high-level requirement traces to low-level controls, you have evidence.
• They reduce cost and rework. Privacy flaws found late in the SDLC are far more expensive to fix. Clear specifications early in requirements and design prevent costly redesigns.
• They enable consistency. High-level specifications give a stable reference across many projects. Low-level specifications let each project apply that reference correctly in its own technical context.
• They operationalize PbD. Ann Cavoukian's seven foundational principles, such as Proactive not Reactive and Privacy as the Default, are aspirational. Specifications make them actionable.

2. What They Are

High-Level Privacy Specifications
These are abstract, goal-oriented statements of what the system must achieve for privacy. They are usually technology-neutral and are derived from:

• Laws and regulations (GDPR, CCPA/CPRA, HIPAA, COPPA)
• Privacy frameworks and principles (FIPPs, OECD, ISO/IEC 29100, NIST Privacy Framework)
• Organizational privacy policies, notices and contractual commitments
• Results of Privacy Impact Assessments (PIAs) or DPIAs
• User expectations and ethical considerations

Examples:

• 'The system shall collect only personal data necessary for the stated purpose.' (data minimization)
• 'Users shall be able to access and correct their personal data.' (individual participation)
• 'Personal data shall be protected against unauthorized access.' (security safeguards)
• 'Personal data shall not be retained longer than necessary.' (storage limitation)
• 'Processing shall be transparent to the data subject.' (openness/transparency)

High-level specifications typically sit at the requirements and architecture stage. They often correspond to privacy design strategies, such as Jaap-Henk Hoepman's eight strategies:

• Data-oriented: Minimize, Hide, Separate, Aggregate
• Process-oriented: Inform, Control, Enforce, Demonstrate

They also map to NIST privacy engineering objectives:

• Predictability: reliable assumptions about processing
• Manageability: granular administration of personal data, including alteration, deletion and selective disclosure
• Disassociability: processing without association to individuals beyond operational needs

Low-Level Privacy Specifications
These are concrete, detailed, technology-specific and testable statements of how the high-level goals will be met. They sit at the detailed design, implementation (coding) and configuration stage. They often draw on privacy design patterns and Privacy-Enhancing Technologies (PETs).

Examples (each tied to a high-level goal):

• Minimization: 'The registration form shall request only email and password. The date-of-birth field is removed. Age is verified by a yes/no checkbox for 16+.'
• Access and correction: 'A self-service profile page shall allow users to view and edit name, email and address. Changes are logged with a timestamp.'
• Security: 'Data at rest shall be encrypted with AES-256. Data in transit shall use TLS 1.2 or higher. Access is limited by role-based access control (RBAC) with MFA for administrators.'
• Retention: 'A scheduled job shall purge transaction logs older than 90 days and anonymize analytics records after 13 months.'
• Transparency: 'A just-in-time notice shall be displayed before location permission is requested, linking to the relevant privacy notice section.'
• Disassociability: 'User IDs in the analytics pipeline shall be replaced with salted hashes (pseudonymization). Aggregated reports shall suppress cells with fewer than 10 individuals.'

Key Differences at a Glance

• Abstraction: High-level = abstract, goal-oriented ('what' and 'why'). Low-level = concrete, solution-oriented ('how').
• Technology dependence: High-level = technology-neutral. Low-level = technology-specific (algorithms, fields, settings, code).
• Audience: High-level = privacy officers, legal, architects, product owners. Low-level = developers, engineers, testers, DBAs.
• SDLC stage: High-level = requirements gathering and architecture/high-level design. Low-level = detailed design, coding, configuration and testing.
• Verifiability: High-level is verified indirectly through its children. Low-level is directly testable (pass/fail).
• Stability: High-level changes rarely, only when laws or policies change. Low-level changes as technology, platforms and threats change.
• Related concepts: High-level relates to strategies, principles and objectives. Low-level relates to patterns, PETs and coding practices.

3. How It Works: From Principle to Code

Step 1: Identify sources of privacy requirements. Gather legal obligations, policies, standards, contractual terms, PIA/DPIA findings and stakeholder expectations. Data flow diagrams and data inventories show what personal data is involved.

Step 2: Write high-level privacy requirements. Express goals as clear, technology-neutral statements. Use frameworks such as the FIPPs or ISO/IEC 29100 to make sure coverage is complete:

• Notice, choice and consent
• Purpose specification
• Collection limitation
• Use limitation
• Data quality
• Security
• Access
• Accountability

Step 3: Select privacy design strategies and architecture. Choose architectural approaches that satisfy the goals:

• Client-side processing
• Decentralization
• Separation of identifiers from attributes
• Data minimization by design
• Privacy defaults

This is the high-level design stage.

Step 4: Decompose into low-level specifications. Refine each high-level requirement into detailed, measurable requirements. Apply design patterns and PETs, for example:

• Pseudonymization and anonymization
• Encryption and tokenization
• Differential privacy and k-anonymity
• Consent management platforms and attribute-based credentials

Requirements must be SMART (specific, measurable, achievable, relevant, time-bound) and unambiguous.

Step 5: Use requirements engineering techniques.

• Use cases and user stories: 'As a user, I want to download my data so that I can move it to another service.'
• Misuse and abuse cases: 'As a malicious insider, I try to export the full customer table.' Each generates a control requirement.
• Threat modeling: for example, LINDDUN for privacy threats (Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance) and STRIDE for security threats.
• Acceptance criteria: testable conditions attached to each requirement.

Step 6: Maintain traceability. Build a requirements traceability matrix linking each legal or policy source to its high-level requirement, then to its low-level specifications, then to code or configuration, then to test cases. This shows completeness, because every obligation is addressed. It also prevents gold-plating, because every control has a reason.

Step 7: Implement, test and verify. Developers build to the low-level specs. Testers verify through:

• Unit and integration tests
• Static and dynamic code analysis
• Code reviews and privacy-focused QA
• Penetration tests

Step 8: Monitor and iterate. After release, monitor compliance, handle changes through change management, and update low-level specs when technology or threats change. Update high-level specs when laws or policies change.

A Worked Example
Source: GDPR Article 5(1)(e), storage limitation, plus the company retention policy.

• High-level requirement: 'Customer personal data shall be retained only as long as necessary for the purposes collected.'
• Architectural decision: Tag every data store with a retention category. Centralize deletion in a retention service.
• Low-level specifications:
  • (a) Every customer table includes a 'retention_class' metadata attribute.
  • (b) Class C2 records (marketing leads) are deleted 12 months after last interaction.
  • (c) Backups containing C2 data expire within 35 days.
  • (d) The deletion job writes an audit log entry with record count and timestamp.
• Test case: Seed a lead record dated 13 months ago, run the job and confirm deletion plus a log entry.
• Traceability: Article 5(1)(e) → HL-RET-01 → LL-RET-01 to LL-RET-04 → TC-RET-07.

4. Related Concepts You Should Connect

• Privacy by Default: Low-level specs set the default configuration, such as profiles private by default and optional data sharing off.
• Privacy design patterns: Reusable solutions sitting between strategies (high-level) and PETs or code (low-level). Examples include layered notice, anonymity set and data aggregation.
• Software Development Life Cycle: High-level specs belong to requirements and architecture. Low-level specs belong to design, coding and testing. Both apply in waterfall and agile, where they appear as epics versus user stories with acceptance criteria.
• Value Sensitive Design and contextual integrity: These can shape high-level goals by considering whether information flows match contextual norms.
• Security vs. privacy: Security specifications protect confidentiality, integrity and availability. Privacy specifications go further and address appropriate collection, use, transparency and individual rights. A secure system can still violate privacy.

5. Exam Tips: Answering Questions on High-Level and Low-Level Privacy Specifications

• Classify by abstraction first. If an answer option names a specific technology, algorithm, field, time period or setting, such as AES-256, a 30-day purge or TLS 1.3, it is low-level. If it states a goal or principle without saying how, such as 'protect data from unauthorized disclosure', it is high-level.
• Look for the 'what vs. how' signal. Exam stems often describe a requirement and ask which level it belongs to, or which statement best refines a goal. The best refinement is the most specific, measurable and testable option that still fully addresses the parent goal.
• Map to the SDLC. Questions asking 'at what stage' expect requirements and architecture for high-level work, and detailed design, implementation and testing for low-level work. Remember PbD favors addressing privacy at the earliest stage.
• Remember the source hierarchy. Laws, policies and frameworks lead to high-level requirements, then to low-level specs, then to code and tests. If asked where high-level requirements come from, choose legal, regulatory, policy or PIA sources, not code reviews.
• Traceability is a frequent correct answer. When a question asks how to demonstrate that every legal obligation has been implemented, or how to show accountability, think requirements traceability matrix.
• Know strategies vs. patterns vs. PETs. Hoepman's strategies (Minimize, Hide, Separate, Aggregate, Inform, Control, Enforce, Demonstrate) are high-level. Design patterns are intermediate. PETs and specific techniques (encryption, pseudonymization, differential privacy, k-anonymity) are low-level.
• Prefer testable language. When choosing the 'best' privacy requirement, pick the one that is unambiguous and verifiable. Watch for vague words like 'appropriate', 'reasonable' or 'as needed'. These are acceptable at the high level but are weaknesses in a low-level spec.
• Watch for the security-only trap. If the scenario asks for a privacy specification and one option only addresses security, such as a firewall, while another addresses collection limitation, consent or purpose, the privacy-specific option is usually better.
• Scenario questions: think like an engineer. In a case study, for example a mobile app collecting location data, identify the principle at stake (minimization, consent, transparency). Then choose the control that concretely enforces it, such as requesting 'approximate' rather than 'precise' location, or collecting location only while the app is in use.
• Use the NIST objectives. If a question mentions predictability, manageability or disassociability, recognize these as high-level engineering objectives. Then pick the low-level control that achieves them. For example, pseudonymization and aggregation support disassociability, and granular deletion tools support manageability.
• Eliminate extremes. Options that skip levels, such as jumping from a law straight to code with no design, or that leave privacy until after deployment, contradict PbD and are usually wrong.
• Agile context. In agile settings, high-level specs often appear as epics, privacy principles or a 'definition of done'. Low-level specs appear as user stories with acceptance criteria and privacy tasks in sprints.

6. Practice Questions

Q1. Which of the following is a low-level privacy specification?

• A) Personal data shall be processed fairly.
• B) The system shall minimize data collection.
• C) Session logs containing IP addresses shall be truncated to the first three octets and deleted after 30 days.
• D) Users shall be informed about processing.

Answer: C. It is specific, technical and testable. The others are high-level goals.

Q2. A privacy engineer needs to show auditors that each GDPR obligation has been implemented and tested. What is the most effective tool?
Answer: A requirements traceability matrix linking legal sources to high-level requirements, low-level specifications and test cases.

Q3. Hoepman's 'Hide' strategy is best described as:

• A) A low-level PET
• B) A high-level privacy design strategy
• C) A test case
• D) A legal requirement

Answer: B. Encryption or onion routing would be low-level means of implementing it.

Q4. At which SDLC phase should high-level privacy requirements first be defined?
Answer: During requirements gathering and planning, before design begins. This is consistent with the 'Proactive not Reactive' principle.

7. Common Pitfalls to Avoid (in Practice and on the Exam)

• Writing only high-level statements and assuming developers will 'figure it out'.
• Writing only low-level controls with no link to the underlying obligation. This makes it hard to justify the controls or to update them when laws change.
• Treating security requirements as a complete substitute for privacy requirements.
• Using ambiguous terms in low-level specs that cannot be tested.
• Failing to revisit low-level specs when technology, vendors or threats change.

Summary
High-level privacy specifications state what privacy outcomes a system must achieve. They are derived from laws, principles, policies and assessments, and are technology-neutral. Low-level privacy specifications state how those outcomes are achieved, through specific, measurable, technology-dependent design, code and configuration requirements.

Moving from one to the other relies on four things:

• Privacy strategies
• Design patterns
• PETs
• Requirements engineering techniques

Traceability holds the chain together. On the exam, identify the level of abstraction, link it to the SDLC stage, favor testable and privacy-specific controls, and remember that PbD demands this work begin early.