Privacy Requirements in the Secure Development Life Cycle

Privacy Requirements in the Secure Development Life Cycle (CDPSE – Privacy Engineering)

Introduction
Privacy Requirements in the Secure Development Life Cycle (SDLC) is a core topic in the ISACA Certified Data Privacy Solutions Engineer (CDPSE) exam, under the Privacy Engineering domain. It covers how privacy obligations are identified, documented, built in, tested and maintained at every stage of building or acquiring a system. This replaces the old approach of adding privacy controls after the system is finished. It is the practical form of Privacy by Design and Privacy by Default.

Why It Is Important
1. Cost of remediation: Fixing a privacy defect in production can cost many times more than fixing it during requirements or design. Retrofitting consent, deletion or minimization into a live system is expensive and disruptive.
2. Regulatory obligation: Several laws require privacy to be built in from the start:
- GDPR Article 25 makes data protection by design and by default a legal requirement.
- Article 35 requires a DPIA for high-risk processing.
- CCPA/CPRA, LGPD, PIPEDA and others set similar expectations.
3. Risk reduction: Early requirements reduce the chance of the following:
- Over-collection of data.
- Unlawful processing.
- Breaches and data subject harm.
- Fines and reputational damage.
4. Accountability: Documented privacy requirements and traceability show regulators, auditors and customers that the organization has done its due diligence.
5. Trust and business enablement: Products that respect privacy gain user trust and face fewer launch delays caused by late compliance findings.
6. Security and privacy are different: A system can be secure and still violate privacy, for example by collecting unnecessary data or using it for an incompatible purpose. Privacy requirements address purpose, minimization, transparency and individual rights, which security controls alone do not cover.

What It Is
Privacy requirements are specific, testable statements of how a system must handle personal information. They are derived from the following sources:
- Laws and regulations (GDPR, HIPAA, CCPA, etc.).
- Contracts and industry standards (e.g., PCI DSS, ISO/IEC 27701, ISO/IEC 29100, NIST Privacy Framework).
- Organizational privacy policies and notices.
- Privacy principles such as the OECD Fair Information Practices, GAPP, and APEC principles.
- Results of privacy risk assessments, PIAs and DPIAs.
- Data subject and stakeholder expectations.

Privacy requirements fall into two types:
- Functional privacy requirements: what the system must do. Examples include capturing and recording consent, providing access and export of personal data, supporting deletion (right to erasure), enforcing retention schedules, and showing just-in-time notices.
- Non-functional privacy requirements: qualities and constraints. Examples include encryption of data at rest and in transit, pseudonymization, access restrictions, logging, data localization and performance of rights-request handling.

The Secure Development Life Cycle (also called Secure SDLC or SSDLC) embeds security activities into each development phase. Privacy engineering extends it, sometimes called a Privacy-Enhanced SDLC or PbD-SDLC, so that privacy tasks run alongside security tasks.

How It Works – Phase by Phase

1. Initiation / Planning / Concept
- Identify whether personal data will be processed. A privacy threshold analysis (PTA) or screening questionnaire is used for this.
- Define purpose(s) of processing and lawful basis.
- Engage the privacy office / DPO and identify stakeholders.
- Decide whether a full PIA/DPIA is needed.
- Include privacy in the business case, budget and project charter.

2. Requirements Analysis
- Translate legal, policy and contractual obligations into specific, measurable, testable privacy requirements.
- Create data inventories and data flow diagrams showing what data is collected, from whom, why, where it goes and how long it is kept.
- Apply data minimization: collect only what is necessary for the stated purpose.
- Define requirements for the following:
- Notice and consent.
- Data subject rights.
- Retention and disposal.
- Cross-border transfers.
- Third-party sharing.
- Record requirements in a requirements traceability matrix linking each requirement to its source and later to design elements and test cases.
- Write privacy user stories in Agile, e.g., As a user, I want to withdraw consent so that my data is no longer used for marketing.

3. Design
- Perform privacy threat modeling, for example with LINDDUN. LINDDUN covers Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness and Non-compliance. Use it alongside STRIDE for security.
- Apply privacy design strategies (Hoepman's eight strategies):
- Minimize, Hide, Separate, Aggregate.
- Inform, Control, Enforce, Demonstrate.
- Select privacy-enhancing technologies (PETs), such as:
- Pseudonymization and anonymization.
- Tokenization and encryption.
- Differential privacy.
- Attribute-based access control.
- Design privacy-protective default settings (Privacy by Default).
- Architecture review by privacy and security teams; complete or update the DPIA.

4. Development / Implementation
- Follow secure and privacy-aware coding standards.
- Use approved privacy libraries and patterns, such as consent management SDKs and masking functions.
- Avoid logging personal data unnecessarily; do not hard-code identifiers or credentials.
- Use static code analysis and peer code review that includes privacy checks.
- Control use of third-party and open-source components that may collect or transmit data.

5. Testing / Verification
- Verify each privacy requirement through test cases traced back to requirements. Typical tests include:
- Consent capture and withdrawal.
- Deletion actually propagates to backups and downstream systems as designed.
- Retention jobs run correctly.
- Access controls restrict data correctly.
- Use synthetic, masked or anonymized test data rather than production personal data. This is a very frequently tested exam point.
- Run dynamic testing, penetration testing and privacy-specific reviews of user interfaces (notices, dark patterns).
- Hold a privacy sign-off and go/no-go gate before release.

6. Deployment / Release
- Confirm privacy notices are published and accurate.
- Ensure configuration matches privacy-by-default settings.
- Update records of processing activities (ROPA) and data inventories.
- Train operations and support staff on handling rights requests and incidents.

7. Operations and Maintenance
- Monitor, log and audit processing for compliance.
- Manage changes through change management that triggers privacy review when processing changes, such as new data elements, new purposes, new vendors or new locations.
- Periodically reassess the PIA/DPIA.
- Handle incidents and breach notifications.

8. Disposal / Decommissioning
- Securely delete or anonymize personal data according to retention schedules.
- Sanitize media using recognized methods, such as NIST SP 800-88.
- Migrate data lawfully if moving to a new system.
- Update inventories and document destruction.

Agile and DevOps Considerations
- Embed privacy acceptance criteria in the Definition of Done.
- Add privacy stories to backlogs.
- Have privacy champions inside scrum teams.
- Run lightweight PIAs per feature or epic.
- In DevSecOps/DevPrivOps pipelines, automate privacy checks with tools such as:
- Scanning for personal data in code or logs.
- Policy-as-code.
- Automated data discovery.

Acquired Systems and Third Parties
When software is purchased or outsourced, privacy requirements must be included in the following:
- RFPs and vendor due diligence.
- Contracts and data processing agreements.
- Acceptance testing.
The organization remains accountable, as the controller, even when development is outsourced.

Key Roles
- Privacy engineer / CDPSE: translates requirements into technical controls.
- DPO / privacy office: provides guidance and oversight.
- Business owner: accountable for the purpose and risk acceptance.
- Architects and developers: implement the controls.
- QA: verifies the controls.
- Security team: provides complementary controls.
- Legal: interprets obligations.

Exam Tips: Answering Questions on Privacy Requirements in the Secure Development Life Cycle

1. Earliest is best. When asked WHEN privacy should be considered, choose the earliest phase: initiation, planning or requirements. Answers like after testing or before deployment are usually wrong when an earlier option exists.

2. Know the FIRST step. The first step in a new project involving personal data is usually one of the following:
- Identify the personal data and the purpose (data inventory / data mapping).
- Perform a privacy threshold assessment or PIA.
Coding controls or selecting encryption come later.

3. Requirements must trace to sources. Privacy requirements derive from laws, regulations, contracts, policies and risk assessments. If asked the BEST source or basis for privacy requirements, look for applicable legal/regulatory obligations and the privacy policy, informed by a PIA/DPIA.

4. Test data questions. The best answer is almost always to use synthetic, anonymized or masked data instead of production personal data. If production data must be used, it requires approval, equivalent protection and deletion after use.

5. Distinguish privacy from security. Encryption protects confidentiality but does not solve over-collection, purpose limitation or lack of consent. If the scenario describes excessive data collection, the answer is data minimization, not stronger security controls.

6. Privacy by Default. Default settings should be the most privacy-protective, such as opt-in and minimal sharing. Look for answers where users do not need to take action to protect their privacy.

7. Change triggers reassessment. Any of the following should trigger an updated PIA/DPIA and privacy review through change management:
- New data elements or new purposes.
- New third parties.
- New jurisdictions.
- Major architectural changes.

8. Traceability matrix. To verify that all privacy requirements were implemented, the best tool is a requirements traceability matrix linked to test cases.

9. Threat modeling. LINDDUN is the privacy-specific threat modeling framework and STRIDE is security-focused. Threat modeling belongs in the design phase.

10. Outsourcing does not transfer accountability. For vendor-developed systems, choose answers that embed privacy requirements in contracts, due diligence and acceptance testing.

11. Choose the most comprehensive, preventive, root-cause answer. ISACA prefers answers that do one or more of the following:
- Address governance and process over one-off fixes.
- Prevent issues rather than detect them later.
- Involve the right stakeholders.
For example, integrating privacy into the SDLC methodology beats reviewing each application after launch.

12. Watch for keywords. Words like FIRST, BEST, MOST important, PRIMARY and GREATEST concern change the answer. Read the scenario for the phase you are in and choose the action appropriate to that phase.

13. Decommissioning matters. Privacy obligations continue to system retirement. Secure disposal, data migration and documentation are valid answers in end-of-life scenarios.

14. Agile scenarios. The right answer integrates privacy into user stories, acceptance criteria and the Definition of Done rather than adding a separate post-sprint review.

Sample Question
A development team is starting a new mobile application that will collect customer location data. What should the privacy engineer do FIRST?
A. Implement encryption for location data
B. Conduct a privacy impact assessment to identify requirements and risks
C. Perform penetration testing
D. Draft the privacy notice

Answer: B. A PIA at the start identifies the purpose, necessity, risks and resulting privacy requirements, which then drive the following:
- Design choices such as encryption (A).
- The notice content (D).
- Testing (C).

Summary
Privacy requirements in the SDLC mean treating privacy as a first-class requirement:
- Identified early.
- Documented as specific, testable statements.
- Designed in through threat modeling and PETs.
- Implemented with safe coding practices.
- Verified with traceable tests and non-production data.
- Maintained through change management.
- Honored through secure disposal.
For the exam, favor early, preventive, governance-driven, traceable and default-protective answers. Always remember that security alone does not equal privacy.