Managing Privacy Risk in the Development Life Cycle (CIPT Guide)
Managing Privacy Risk in the Development Life Cycle: A Complete CIPT Guide
This guide covers why privacy risk management in the development life cycle matters, what it is, how it works phase by phase, and how to answer exam questions on it.
1. Why It Is Important
Privacy problems are far cheaper and easier to fix when they are caught early. A design flaw found during requirements gathering may cost very little to correct. The same flaw found after deployment can be very expensive, for several reasons:
• Breach notification costs
• Regulatory fines
• Litigation
• Re-engineering the system
• Reputational damage
Managing privacy risk throughout the development life cycle matters for four main reasons.
• Legal and regulatory compliance: Laws now require proactive privacy. GDPR Article 25 mandates Data Protection by Design and by Default. GDPR Article 35 requires Data Protection Impact Assessments (DPIAs) for high-risk processing. The US FTC has also repeatedly called on companies to adopt Privacy by Design.
• Trust and brand protection: Users and customers increasingly choose products based on how their data is handled.
• Efficiency: Privacy built in from the start avoids bolt-on fixes, technical debt and costly rework.
• Accountability: Documented risk management shows regulators and auditors that the organisation took reasonable, demonstrable steps.
For a privacy technologist, this topic sits at the heart of the role. The CIPT exists to bridge the gap between legal and policy requirements and the engineers who build systems.
2. What It Is
Managing privacy risk in the development life cycle means systematically identifying, assessing, mitigating and monitoring privacy risks at every stage of building a product, service or system. Development life cycles may be called SDLC, SDL or PLC.
It operationalises Privacy by Design (PbD), the framework created by Dr. Ann Cavoukian. Its seven foundational principles are:
1. Proactive not reactive; preventative not remedial
2. Privacy as the default setting
3. Privacy embedded into design
4. Full functionality: positive-sum, not zero-sum
5. End-to-end security: full life cycle protection
6. Visibility and transparency: keep it open
7. Respect for user privacy: keep it user-centric
Several key concepts sit inside this topic:
• Privacy risk: The likelihood and impact of a problem for individuals arising from data processing. The NIST Privacy Framework calls these "problematic data actions". Note that privacy risk focuses on harm to the individual, not only on organisational risk.
• Privacy Impact Assessment (PIA) / DPIA: A structured process to identify and reduce privacy risks of a project.
• Privacy requirements: Functional and non-functional requirements derived from law, policy, standards and user expectations.
• Privacy engineering: The discipline of applying engineering methods to achieve privacy outcomes. NIST defines its objectives as predictability, manageability and disassociability.
• Privacy governance: The roles, policies, committees and accountability structures that ensure privacy risk management actually happens.
3. How It Works: Privacy Across the Life Cycle
Life cycle models vary: waterfall, agile, DevOps and spiral. However, the privacy activities map onto common phases.
a) Planning / Initiation
• Conduct a privacy threshold analysis (PTA) or initial screening to decide whether a full PIA/DPIA is needed.
• Identify stakeholders: privacy office, legal, security, product owner and engineering.
• Define the purpose of processing and the legal basis.
• Assign accountability, for example a privacy champion embedded in the team.
b) Requirements
• Translate legal and policy obligations into concrete privacy requirements. Examples include consent capture, retention limits, data subject access, deletion, and opt-out of sale or sharing.
• Apply Fair Information Practice Principles (FIPPs), OECD guidelines and GDPR principles. These include data minimisation, purpose limitation, accuracy, storage limitation and integrity/confidentiality.
• Create data inventories and data flow diagrams showing what personal data is collected, where it goes and who accesses it.
• Write user stories and abuse cases, for example "As an attacker/curious insider I want to…".
c) Design
• Perform privacy threat modelling, using techniques such as LINDDUN or STRIDE. LINDDUN covers Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness and Non-compliance. STRIDE is supplemented by privacy considerations.
• Apply privacy design strategies, for example Hoepman's eight strategies: Minimise, Hide, Separate, Aggregate, Inform, Control, Enforce, Demonstrate.
• Select privacy-enhancing technologies (PETs), such as:
- Encryption
- Pseudonymisation
- Tokenisation
- Anonymisation
- Differential privacy
- k-anonymity
- Secure multi-party computation
- Homomorphic encryption
• Design privacy-protective defaults: settings off by default, minimal data fields, short retention.
• Design user interfaces for transparency and control: just-in-time notices, layered notices, privacy dashboards, and avoiding dark patterns.
• Complete or update the PIA/DPIA. Design is the ideal point because enough is known to assess risk, yet changes are still cheap.
d) Development / Implementation
• Follow secure and privacy-aware coding standards.
• Use code reviews, static analysis and checks for personal data in logs.
• Avoid hard-coded secrets and excessive telemetry.
• Manage third-party libraries and SDKs, which may secretly collect data.
• Use synthetic or masked test data rather than production personal data.
e) Testing / Verification
• Verify that privacy requirements are met through functional tests, for example: does deletion actually delete?
• Run penetration testing and vulnerability scanning.
• Perform privacy-specific testing: re-identification testing, data leakage tests and UI review for dark patterns.
• Validate against the PIA mitigation plan.
f) Deployment / Release
• Obtain a privacy sign-off or release gate.
• Update privacy notices and records of processing activities (GDPR Article 30).
• Confirm contracts with vendors and processors (data processing agreements).
• Configure access controls and monitoring.
g) Operations / Maintenance
• Monitor continuously, audit, and manage logs.
• Run incident response and breach notification processes.
• Handle data subject requests.
• Use change management: any new feature, new data type or new purpose triggers a reassessment of the PIA. A PIA is a living document.
h) Retirement / Decommissioning
• Securely dispose of or archive data according to retention schedules.
• Use sanitisation methods such as those in NIST SP 800-88: clear, purge, destroy.
• Update inventories and notices.
Agile and DevOps considerations
• Privacy activities must be iterative. Add privacy acceptance criteria to user stories and include privacy in the "definition of done".
• Run lightweight PIAs per sprint or epic.
• Automate privacy checks in CI/CD pipelines.
• Embed privacy champions in scrum teams.
Governance elements that support the process
• Privacy policies and engineering standards
• Defined roles: DPO, CPO, privacy engineers, privacy champions, data owners and data stewards
• Training and awareness for developers
• Metrics and KPIs, for example the percentage of projects with a completed PIA
• Risk registers and risk acceptance procedures; residual risk must be formally accepted by an accountable owner
• Under GDPR, prior consultation with the supervisory authority when a DPIA shows high residual risk that cannot be mitigated (Article 36)
Risk management approach
A typical cycle runs: Identify → Assess (likelihood × impact) → Treat → Monitor → Review. There are four risk treatment options:
• Mitigate/reduce: apply controls.
• Avoid: do not collect the data or do not build the feature.
• Transfer/share: for example insurance or contracts. Accountability for privacy obligations generally stays with the controller.
• Accept: documented acceptance by an authorised owner.
Relevant frameworks include:
• NIST Privacy Framework (Identify-P, Govern-P, Control-P, Communicate-P, Protect-P)
• NIST SP 800-53 privacy controls
• ISO/IEC 27701
• ISO/IEC 29100 (privacy framework)
• ISO/IEC 29134 (PIA guidelines)
• ISO/IEC 31700 (privacy by design for consumer products)
• OWASP resources
• Microsoft SDL
4. How to Answer Exam Questions on This Topic
CIPT questions are usually scenario-based. A company is building an app, feature or system, and you must choose the best next step, the most appropriate control, or the phase in which an activity should occur.
Common question types:
• "When should a PIA be conducted?" Answer: as early as possible, ideally during planning or design, and updated throughout the life cycle.
• "What is the BEST way to reduce risk of X?" Look for the control that addresses the root cause. Data minimisation or avoidance usually beats downstream controls.
• "Which privacy threat category does this describe?" Map to LINDDUN or to Solove's taxonomy (collection, processing, dissemination, invasion).
• "Who is responsible…?" Know the governance roles.
• "What should happen when a new feature changes data use?" Reassess or update the PIA, update notices, and consider whether new consent is needed.
• "Which technique allows analytics while protecting identity?" Pseudonymisation, aggregation or differential privacy, depending on context.
5. Exam Tips: Answering Questions on Managing Privacy Risk in the Development Life Cycle
Tip 1: Earlier is almost always better. If an answer option involves addressing privacy at the beginning, such as requirements or design, it is usually preferable to one that addresses it at testing or after launch. "Proactive not reactive" is a recurring theme.
Tip 2: Minimisation beats protection. Not collecting data is the strongest control. If one option says "encrypt the data" and another says "don't collect the data because it isn't needed for the purpose", choose minimisation, provided it still meets business needs.
Tip 3: Think positive-sum. PbD rejects false trade-offs between privacy and functionality. Prefer answers that achieve business goals AND protect privacy over answers that abandon the project or ignore privacy.
Tip 4: The PIA is a living document. Changes in purpose, data types, technology, vendors or jurisdiction trigger reassessment. A one-and-done PIA is a red flag answer.
Tip 5: Distinguish privacy risk from security risk. Security protects confidentiality, integrity and availability. Privacy also covers appropriate collection, use, transparency, choice and harms to individuals, even when processing is fully "secure". A perfectly secure system can still violate privacy, for example through over-collection or secondary use without notice.
Tip 6: Know the terminology precisely.
• Anonymisation is irreversible, so the data falls outside GDPR.
• Pseudonymisation is reversible with additional information, so the data is still personal data.
• Data Protection by Default means the most privacy-protective settings apply automatically.
• Residual risk is the risk remaining after controls are applied.
Tip 7: Look for the "most" or "best" qualifier. Several options may be technically correct. Choose the one that is most comprehensive, addresses root cause, aligns with law, and fits the phase described in the scenario.
Tip 8: Identify the life cycle phase in the scenario. If the scenario says "the team is gathering requirements", the answer should be a requirements-phase activity, such as defining privacy requirements or data mapping, not a deployment activity.
Tip 9: Remember vendors and third parties. SDKs, cloud providers and APIs introduce risk. Due diligence, contracts and ongoing monitoring are part of life cycle risk management.
Tip 10: Test data matters. Using real production personal data in development or test environments is a classic wrong practice. Prefer synthetic, masked or de-identified data.
Tip 11: Agile does not mean skipping privacy. In agile scenarios, the correct answer typically integrates privacy into user stories, backlog, sprint reviews and the definition of done, rather than a single big upfront review.
Tip 12: Governance needs accountability. Risk acceptance must be documented by someone with authority. Engineers should not silently accept high privacy risk. Escalation paths and sign-off gates are good answers.
Tip 13: User-centric UI answers win. For notice and consent questions, prefer clear, contextual, just-in-time and layered notices and granular choices. Avoid pre-ticked boxes, bundled consent and dark patterns.
Tip 14: Eliminate extreme answers. Options like "abandon the project", "collect everything in case it's useful later" or "rely solely on the privacy policy" are rarely correct.
Tip 15: Map to frameworks when unsure. Ask which FIPP or PbD principle the scenario violates. Naming the principle often reveals the correct control.
6. Quick Recap
• Embed privacy from inception to retirement.
• Screen early (PTA), assess thoroughly (PIA/DPIA), and reassess on change.
• Translate law into requirements, model threats (LINDDUN), and apply design strategies and PETs.
• Test privacy controls, gate releases, monitor operations, and dispose of data securely.
• Support everything with governance: roles, policies, training, metrics and documented risk acceptance.
• In the exam, favour early, root-cause, minimisation-first, positive-sum, user-centric and documented answers.
