Code Reviews for Privacy Gaps: A CIPT Guide to Privacy Engineering and Governance
Introduction
Code reviews for privacy gaps are a core technique in the IAPP Certified Information Privacy Technologist (CIPT) body of knowledge. They sit within privacy engineering and privacy governance, where privacy requirements are turned into technical controls and those controls are checked to confirm they work as intended. A privacy-focused code review is a systematic examination of source code, configuration and related artifacts. Its purpose is to find places where software handles personal data in ways that break privacy policy, legal requirements, user expectations or privacy-by-design principles.
Why Code Reviews for Privacy Gaps Are Important
1. Policy does not equal practice. An organization can publish a privacy notice, adopt internal policies and complete a Privacy Impact Assessment (PIA). The code that actually runs may still do something different. Code review closes the gap between what the organization says and what the software does.
2. Privacy by Design and by Default. GDPR Article 25 requires data protection by design and by default. Ann Cavoukian's seven foundational principles call for privacy to be embedded into design rather than bolted on. Code review is one of the most concrete ways to show that privacy has been embedded at the implementation level.
3. Cost of remediation. Defects found during development are far cheaper to fix than defects found after release, after a breach or during a regulator's investigation. Shifting privacy left in the Software Development Life Cycle (SDLC) reduces cost and risk.
4. Accountability and demonstrable compliance. Regulators expect organizations to demonstrate compliance, not just claim it. Documented review records, findings and remediation tickets are evidence of due diligence.
5. Third-party and open-source risk. Modern applications include many SDKs, libraries and APIs. These can silently collect or transmit personal data, such as advertising SDKs harvesting device identifiers or location. Reviews reveal these hidden flows.
6. Preventing privacy harms. Gaps can lead to harms described in privacy taxonomies such as Daniel Solove's taxonomy. Examples include surveillance, aggregation, identification, insecurity, secondary use, exclusion, disclosure and increased accessibility. Code review helps prevent these harms before they reach users.
What Code Reviews for Privacy Gaps Are
A privacy code review is a structured evaluation of software that looks at how the code handles personal data. Reviewers check whether it:
- collects only the data that is necessary (data minimization)
- uses data only for specified, legitimate purposes (purpose limitation)
- protects data with appropriate security controls such as encryption, access control and pseudonymization (integrity and confidentiality)
- respects user choices and consent signals (lawfulness, consent, choice)
- retains data only as long as needed and deletes it properly (storage limitation)
- supports data subject rights such as access, correction, deletion and portability
- logs, transmits and shares data in line with notices and agreements (transparency, onward transfer)
It differs from a general security code review. Security reviews focus on vulnerabilities such as injection, buffer overflows and authentication flaws. Privacy reviews ask whether the system processes personal data appropriately even when it is perfectly secure. A system can be fully secure and still violate privacy, for example by collecting excessive data or using it for undisclosed purposes. The two reviews overlap and complement each other.
Types of Privacy Code Review
Manual peer review: Developers or privacy engineers read code changes, often during pull requests, using a privacy checklist.
Static analysis (SAST): Automated tools scan source code without running it. They can flag patterns such as hard-coded credentials, logging of sensitive fields, use of weak cryptography or calls to known tracking APIs. Some specialized tools perform data-flow or taint analysis, tracing personal data from its source (for example, a form field) to its sink (for example, a log file or third-party endpoint).
Dynamic analysis (DAST): The running application is tested to observe actual behavior, such as network traffic showing data sent to third parties.
Software Composition Analysis (SCA): Third-party libraries and SDKs are inventoried and evaluated for data collection behavior and known vulnerabilities.
Configuration and infrastructure-as-code review: Cloud configurations, database settings, bucket permissions and retention settings are reviewed for exposures.
Data flow and architecture review: Code is compared against data flow diagrams and the data inventory to confirm that documented flows match real ones.
How Code Reviews for Privacy Gaps Work
Step 1: Establish privacy requirements. Reviews need a baseline. Requirements are derived from laws (GDPR, CCPA/CPRA, HIPAA, COPPA), frameworks (FIPPs, OECD Guidelines, NIST Privacy Framework, ISO/IEC 27701, ISO/IEC 29100), internal policies, privacy notices, contracts and the outcomes of PIAs or DPIAs. These are translated into testable technical requirements, for example: The application must not log full payment card numbers or Location data must not be collected unless the user opts in.
Step 2: Identify personal data and data flows. Reviewers use the data inventory, data maps and data flow diagrams to know which variables, fields, database tables and APIs carry personal or sensitive data. Data classification labels help focus attention.
Step 3: Define scope and triggers. Not every change needs a deep privacy review. Common triggers include:
- new collection of personal data
- new uses or purposes
- new third parties or SDKs
- changes to retention or deletion logic
- changes to authentication or authorization
- cross-border transfers
- processing of sensitive or special category data
- features involving children, biometrics, location or profiling
Step 4: Use a checklist or rubric. Typical items reviewers look for:
- Over-collection: fields captured that are not needed for the stated purpose
- Excessive logging: personal data, tokens, passwords or identifiers written to logs, crash reports or analytics
- Hard-coded secrets: API keys, credentials or encryption keys in source code
- Weak or missing encryption: data in transit without TLS, data at rest unencrypted, deprecated algorithms (MD5, SHA-1 for passwords, DES)
- Improper de-identification: reversible hashing of identifiers, quasi-identifiers left intact, pseudonymization keys stored with the data
- Consent and preference handling: code paths that ignore opt-out flags, Global Privacy Control signals, or Do Not Track preferences where honored
- Third-party transmission: SDKs or API calls sending identifiers, device IDs or behavioral data to vendors not disclosed in the notice
- Retention: missing deletion jobs, soft-deletes that never purge, backups that keep data indefinitely
- Access control: missing authorization checks, overly broad roles, Insecure Direct Object References exposing other users' data
- Default settings: features that share data publicly by default instead of privately
- Data subject rights support: whether data can be located, exported, corrected and deleted across all stores
- Error messages and APIs: responses that leak personal information or enable account enumeration
- Client-side exposure: personal data in URLs, query strings, local storage or cookies without proper flags
Step 5: Perform the review. Combine automated scanning with manual inspection. Automated tools give breadth and consistency. Human reviewers give context, such as understanding purpose, user expectations and whether a use is compatible with the original purpose.
Step 6: Document and rate findings. Each gap is recorded with:
- its location
- a description
- the privacy principle or requirement violated
- a risk rating based on likelihood and impact on individuals
- a recommended remediation
Step 7: Remediate and verify. Developers fix issues and reviewers confirm the fixes. Unresolved risks are escalated and formally accepted by an accountable owner, or mitigated.
Step 8: Feed back into governance. Findings update the data inventory, PIAs, training content, secure coding standards and the review checklist itself. Metrics such as number of findings, time to remediate and recurring issue types support continuous improvement and reporting to leadership.
Where Code Review Fits in the SDLC
- Requirements: privacy requirements defined, PIA initiated
- Design: threat modeling (for example LINDDUN for privacy, STRIDE for security), architecture review
- Development: peer code review, IDE plug-ins, pre-commit hooks, SAST in CI/CD pipelines
- Testing: DAST, privacy test cases, traffic inspection, QA with synthetic or masked test data rather than production personal data
- Release: final privacy sign-off
- Operations: monitoring, periodic re-review, audit, incident response
In Agile and DevOps environments, privacy review is embedded in sprints and pipelines rather than done as a single gate at the end. This approach is often called DevPrivOps or shift-left privacy.
Roles and Responsibilities
- Developers: write privacy-respecting code and perform peer reviews
- Privacy engineers / privacy champions: embedded in teams, provide expertise and checklists
- Security team: runs SAST/DAST tools, reviews security controls
- Privacy office / DPO: sets requirements, interprets law, accepts or escalates risk
- Product owners: make sure privacy requirements are in user stories and acceptance criteria
- Internal audit: independently verifies that the review process is followed
Common Challenges
- Developers lacking privacy knowledge, addressed through training and privacy champions
- Volume of code and speed of release, addressed through automation and risk-based triggers
- Third-party code that cannot be inspected, addressed through vendor assessments, contractual controls and dynamic traffic analysis
- False positives from tools, addressed through tuning and human triage
- Keeping data inventories current, addressed through automated data discovery
Exam Tips: Answering Questions on Code Reviews for Privacy Gaps
1. Think early and often. When a question asks when privacy review should occur, the best answer usually points to the earliest feasible point and to continuous review throughout the SDLC. Avoid answers that limit review to just before release or after deployment.
2. Distinguish privacy from security. Expect scenarios where code is secure but still a privacy problem. Examples are collecting date of birth when only age verification is needed, or sending analytics to a third party not mentioned in the notice. The correct answer recognizes the privacy principle violated, such as minimization, purpose limitation or transparency, not just a security flaw.
3. Map gaps to principles. Practice linking each finding to a FIPP or GDPR principle:
- Excessive fields map to data minimization.
- Logs containing personal data map to security and minimization.
- No deletion routine maps to storage limitation.
- Ignored opt-out maps to consent and choice.
- An undisclosed SDK maps to transparency and onward transfer.
Questions often ask which principle is most directly affected.
4. Recognize classic code-level red flags. These include:
- hard-coded credentials
- personal data in URLs or query strings
- plaintext password storage, or fast unsalted hashes instead of bcrypt, scrypt, Argon2 or PBKDF2
- unencrypted transmission
- verbose error messages
- production personal data used in test environments
- unnecessary permissions in mobile apps
- tracking SDKs collecting device identifiers
5. Choose the most effective or best first action. When asked what to do after finding a gap, prefer answers that:
- remediate at the source, for example stop collecting the data rather than encrypting unnecessary data
- follow the hierarchy of minimize first, then protect
- involve the appropriate stakeholder, such as escalating to the privacy office for risk acceptance
- document the finding
6. Automation plus humans. If asked about the best review approach, the strongest answer usually combines automated tools for scale with manual review for context and purpose. Neither alone is complete. Static analysis cannot judge whether a purpose is legitimate.
7. Know the tool terminology. SAST examines source code without execution. DAST tests the running application. SCA inventories third-party components. Taint or data-flow analysis tracks personal data from source to sink. Penetration testing simulates attacks. Match the tool to the scenario described.
8. Connect to governance artifacts. Good answers reference PIAs/DPIAs, data inventories, data flow diagrams, privacy requirements, secure coding standards and documented sign-offs. Code review is not isolated; it validates that PIA mitigations were actually implemented.
9. Watch for default settings. Privacy by default questions often hide the gap in a configuration value, such as a profile visibility default of public or a sharing toggle preset to on. The correct fix is the most privacy-protective default.
10. Third parties are your responsibility. If an embedded SDK leaks data, the organization is still accountable. The correct answers include reviewing and testing SDK behavior, limiting SDK configuration, updating notices and contracts, or removing the SDK.
11. Test data scenarios. Using real customer data in development or QA is a common exam gap. Preferred answers include synthetic data, data masking, tokenization or properly de-identified data.
12. Read the question stem carefully. Look for qualifiers such as BEST, FIRST, MOST likely and PRIMARY. A technically correct but secondary action is often a distractor. For example, encrypting a field is good. But if the field should not be collected at all, removing it is the BEST answer.
13. Eliminate extreme answers. Options suggesting that all code must be reviewed manually line by line, or that automated tools alone are sufficient, are usually wrong. Risk-based, proportionate, layered approaches are typically correct.
14. Remember the developer and culture angle. Questions may ask how to scale privacy review. Correct answers often involve developer training, privacy champions, reusable privacy patterns and libraries, checklists, and integration into CI/CD pipelines.
Sample Question Walkthrough
Scenario: During a code review of a new fitness app, a reviewer notices that the app sends precise GPS coordinates and the device advertising ID to an analytics vendor every minute. The privacy notice states that location is used only to map workouts. What is the BEST action?
Reasoning: This is a purpose limitation and transparency gap, plus potential over-collection, since sending data every minute even outside workouts is excessive. The best action is to:
- stop or restrict the transmission to what is necessary and disclosed
- escalate to the privacy team
- evaluate whether the vendor flow is needed at all
- update notices and consent only if the use is legitimate and necessary
Simply encrypting the transmission does not solve the core problem.
Key Takeaways
- Privacy code reviews verify that implementation matches privacy requirements, policies and notices.
- They complement but differ from security reviews.
- They combine automated (SAST, DAST, SCA, data-flow analysis) and manual methods.
- They should be embedded throughout the SDLC, triggered by risk, and linked to PIAs and data inventories.
- Findings must be documented, rated, remediated, verified and fed back into governance.
- On the exam, map each gap to a privacy principle. Prefer minimization over protection, choose early and continuous review, and pick the answer that addresses root cause with accountability.
