Privacy by Design and by Default

Privacy by Design and by Default (CDPSE – Privacy Governance)

Introduction
Privacy by Design (PbD) and Privacy by Default are two of the most important concepts in the ISACA Certified Data Privacy Solutions Engineer (CDPSE) body of knowledge. They appear across all domains: Privacy Governance, Privacy Architecture and Data Lifecycle. CDPSE is a technical, solutions-focused certification, so you are expected to understand the philosophy behind these principles. You must also know how to put them into systems, processes and organizational practice.

1. Why Privacy by Design and by Default Are Important

a) Proactive rather than reactive protection
Fixing privacy problems after a system is built is costly. It is also disruptive and often incomplete. Retrofitting encryption, consent management or data minimization into a production system can cost many times more than designing it in from the start. PbD moves privacy to the earliest stages of the System Development Life Cycle (SDLC), where changes are cheapest and most effective.

b) Legal and regulatory requirement
Under Article 25 of the EU General Data Protection Regulation (GDPR), data protection by design and by default is a legal obligation. Controllers must apply appropriate technical and organizational measures, both when they determine the means of processing and when they process data. Other laws and frameworks reflect the same idea, including:
- Brazil's LGPD
- The UK GDPR
- Guidance from the US FTC
- Canada's privacy regulators
- ISO/IEC 27701 and ISO 31700 (the standard dedicated to privacy by design for consumer goods and services)

c) Trust, reputation and competitive advantage
Organizations that build privacy into products earn customer trust. They also reduce the likelihood and impact of breaches and show accountability to regulators.

d) Risk reduction
Collecting less data, keeping it for shorter periods and limiting access all shrink the attack surface. Data that is never collected cannot be breached.

e) Accountability and demonstrability
PbD creates documentation such as Privacy Impact Assessments (PIAs), Data Protection Impact Assessments (DPIAs), design decisions and data flow diagrams. These records prove compliance, a central expectation of modern privacy governance.

2. What Privacy by Design and by Default Are

Privacy by Design (PbD)
Dr. Ann Cavoukian, former Information and Privacy Commissioner of Ontario, Canada, developed the concept in the 1990s. It was adopted as an international standard by the International Conference of Data Protection and Privacy Commissioners in 2010. PbD means embedding privacy into:
- Information technologies
- Business practices
- Networked infrastructure
It is a core functional requirement from the outset, not an add-on.

The 7 Foundational Principles of Privacy by Design
1. Proactive not Reactive; Preventative not Remedial. Anticipate and prevent privacy-invasive events before they happen. Do not wait for risks to materialize.
2. Privacy as the Default Setting. Personal data is automatically protected in any IT system or business practice. Individuals do not need to take any action to protect their privacy.
3. Privacy Embedded into Design. Privacy is part of the architecture and the business processes. It is not bolted on afterwards.
4. Full Functionality: Positive-Sum, not Zero-Sum. Accommodate all legitimate interests (privacy and security, privacy and functionality) without false trade-offs.
5. End-to-End Security: Full Lifecycle Protection. Data is securely handled from collection through use, storage, sharing and secure destruction.
6. Visibility and Transparency: Keep it Open. Operations are verifiable by stakeholders and follow stated promises and objectives.
7. Respect for User Privacy: Keep it User-Centric. Offer strong defaults, appropriate notice and user-friendly options. The interests of the individual come first.

Privacy by Default
Privacy by Default is a subset of PbD (principle 2), but GDPR treats it as its own obligation. Article 25(2) requires that, by default, only personal data necessary for each specific purpose is processed. This applies to:
- The amount of personal data collected
- The extent of processing
- The period of storage
- Its accessibility. Data should not be made available to an indefinite number of people without the individual's intervention.

In simple terms, the most privacy-protective setting must be the starting setting. If a user does nothing, their privacy is still protected. Examples:
- Social media profiles set to private by default
- Location tracking turned off until the user opts in
- Marketing checkboxes left unticked
- Optional form fields not made mandatory

Key Distinction
- Privacy by Design = how the system is built. It is about architecture, process and methodology, covering the whole lifecycle.
- Privacy by Default = what state the system is in when delivered or first used. It is about settings and configurations that protect privacy without user action.

3. How Privacy by Design and by Default Work in Practice

a) Governance layer
- Leadership commitment and a privacy policy that requires PbD for all new projects, systems, vendors and changes.
- Clear roles: Data Protection Officer (DPO), privacy engineers, system owners, data owners and data stewards.
- A privacy program that adds privacy checkpoints to project management and change management.
- Metrics and KPIs, such as the percentage of projects with a completed PIA before go-live.

b) Integrating privacy into the SDLC
- Initiation/Requirements:
- Identify personal data and the purposes for processing.
- Run a privacy threshold analysis to decide whether a PIA/DPIA is needed.
- Define privacy requirements alongside functional and security requirements.
- Design:
- Do threat modeling with privacy frameworks such as LINDDUN, which covers Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness and Non-compliance.
- Produce data flow diagrams.
- Choose privacy-enhancing technologies.
- Design consent and preference mechanisms.
- Development:
- Use secure coding.
- Use pseudonymized or synthetic data in test environments, not production personal data.
- Build in data minimization and retention logic.
- Testing:
- Validate privacy controls, default settings, consent capture, access controls and deletion functionality.
- Deployment:
- Confirm privacy-protective default configurations.
- Update the record of processing activities and the privacy notices.
- Operations/Maintenance:
- Monitor and audit.
- Run periodic PIA reviews.
- Manage changes so that new features trigger a privacy review.
- Disposal/Decommissioning:
- Securely destroy or anonymize data.
- Document data sanitization.

c) Privacy Impact Assessments / DPIAs
The PIA/DPIA is the main tool for putting PbD into practice. It identifies:
- What personal data is processed and why
- The risks to individuals
- The controls that will reduce those risks
It should be performed before processing begins and updated when significant changes occur. Under GDPR Article 35, a DPIA is mandatory for processing likely to result in high risk.

d) Privacy engineering strategies
Jaap-Henk Hoepman's privacy design strategies are often referenced and come in two groups.
- Data-oriented strategies:
- Minimize: collect less.
- Hide: encrypt, pseudonymize.
- Separate: process data in a distributed way.
- Abstract: aggregate, generalize.
- Process-oriented strategies:
- Inform: be transparent.
- Control: give users choices.
- Enforce: apply policies.
- Demonstrate: show compliance.

e) Privacy-Enhancing Technologies (PETs)
- Encryption at rest and in transit
- Pseudonymization and tokenization
- Anonymization techniques: k-anonymity, l-diversity, differential privacy
- Data masking and redaction
- Role-based and attribute-based access control (RBAC/ABAC)
- Secure multi-party computation and homomorphic encryption
- Consent management platforms
- Automated retention and deletion tools

f) Implementing Privacy by Default
- Configure the strictest privacy settings out of the box.
- Use opt-in rather than opt-out for non-essential processing.
- Collect only mandatory fields; optional fields must be clearly optional.
- Apply least privilege so access is limited to those with a need to know.
- Set short default retention periods tied to purpose.
- Disable non-essential cookies, tracking and telemetry until consent is given.
- Do not make user data public or shareable by default.

g) Vendor and third-party management
PbD extends to procurement. When acquiring software or services, the organization should:
- Include privacy requirements in RFPs and contracts.
- Assess vendor privacy practices.
- Confirm that products can be configured to protect privacy by default.

4. Common Pitfalls
- Treating privacy as a compliance checkbox at the end of a project.
- Performing a PIA after the system is built. This is a reactive approach, not PbD.
- Assuming security alone equals privacy. Security is necessary but not sufficient, because privacy also covers purpose limitation, transparency, minimization and individual rights.
- Using production personal data in development and test environments.
- Designing consent flows with pre-ticked boxes or dark patterns.
- Ignoring the end of the data lifecycle (retention and disposal).

5. Exam Tips: Answering Questions on Privacy by Design and by Default

Tip 1: Think EARLY. If a question asks when privacy should be considered, the answer is almost always at the earliest stage: requirements, initiation or design. Prefer "during the requirements/design phase" over "before deployment" or "after go-live."

Tip 2: Proactive beats reactive. Prefer answers that prevent privacy issues over answers that detect or correct them afterwards. Preventive controls (minimization, design reviews, PIAs) are usually the best choice in PbD scenarios.

Tip 3: Recognize Privacy by Default keywords. Look for phrases such as:
- "without user intervention"
- "most protective setting"
- "opt-in"
- "only data necessary"
- "out of the box"
- "default configuration"
These point to Privacy by Default. The correct answer will protect privacy automatically, without the user doing anything.

Tip 4: The PIA/DPIA is often the best first step. When a scenario describes a new system, product, vendor or a significant change involving personal data, the BEST or FIRST action is frequently to conduct a PIA/DPIA. If a PIA has already been done, the next step is usually to implement or validate the identified controls.

Tip 5: Data minimization is a strong answer. Some options reduce the amount of personal data collected or retained, for example removing unnecessary fields or using aggregated or anonymized data. These options usually beat options that collect data and then protect it, because not collecting data is the strongest privacy control.

Tip 6: Distinguish privacy from security. CDPSE questions often include an answer that is purely about security, such as "implement a firewall" or "encrypt the database." Encryption is valuable, but if the question is about purpose limitation, transparency, consent or minimization, a security-only answer is probably not the BEST one.

Tip 7: Remember the positive-sum principle. Avoid answers that create false trade-offs, such as "remove the functionality to protect privacy." PbD seeks solutions that achieve both business functionality and privacy.

Tip 8: Think full lifecycle. Check whether the scenario mentions retention, archiving or disposal. PbD covers collection through destruction. Secure deletion, retention schedules and decommissioning procedures are all part of PbD.

Tip 9: Test data questions. If developers need realistic data for testing, the best answer is usually to use synthetic, masked, anonymized or pseudonymized data instead of production personal data.

Tip 10: Governance and accountability. For governance-focused questions, the best answers usually involve:
- Establishing policies that mandate PbD
- Embedding privacy checkpoints in the SDLC and change management
- Assigning accountability
- Documenting decisions to demonstrate compliance

Tip 11: Watch for "BEST," "FIRST," "MOST" qualifiers. Several answers may be technically correct. Choose the one that is most proactive, most comprehensive, earliest in the lifecycle and most aligned with the data subject's interests.

Tip 12: Consent and user-centricity. Pre-ticked boxes, bundled consent and hidden opt-outs violate Privacy by Default. The correct answer offers clear, granular, freely given, opt-in choices.

6. Sample Practice Questions

Question 1: A company is developing a new mobile application that will collect user location data. When should privacy requirements be defined?
A) After user acceptance testing
B) During the requirements and design phase
C) Once the application is in production
D) When the first privacy complaint is received
Answer: B. PbD requires privacy to be embedded from the earliest phase.

Question 2: Which of the following BEST demonstrates Privacy by Default?
A) Encrypting the user database
B) Offering users an option to delete their account
C) Setting new user profiles to private, with sharing enabled only if the user chooses
D) Publishing a detailed privacy notice
Answer: C. The most protective setting applies without user action.

Question 3: A development team requests a copy of the production customer database for testing. What is the BEST response from a privacy perspective?
A) Provide the copy with access restricted to the team lead
B) Provide masked or synthetic data instead
C) Provide the copy after the team signs an NDA
D) Encrypt the copy before providing it
Answer: B. This applies minimization and avoids exposing real personal data.

Question 4: An organization plans to adopt a new cloud-based HR system. What should the privacy engineer do FIRST?
A) Configure access controls
B) Conduct a privacy impact assessment
C) Update the privacy notice
D) Train HR staff
Answer: B. The PIA identifies risks and required controls before implementation.

7. Quick Summary / Memory Aids
- PbD = Build it in, not bolt it on.
- Privacy by Default = Protected even if the user does nothing.
- 7 principles mnemonic, "P-D-E-F-E-V-R":
- Proactive
- Default
- Embedded
- Full functionality
- End-to-end security
- Visibility/transparency
- Respect for users
- GDPR Article 25 = Data protection by design and by default. Article 35 = DPIA.
- Privacy by Default dimensions: amount, extent, period, accessibility.
- Key tool: PIA/DPIA. Key strategy: data minimization. Key timing: as early as possible.

Conclusion
Privacy by Design and by Default turn privacy from an afterthought into a foundational engineering and governance discipline. For the CDPSE exam, approach every scenario by asking four questions:
1. Is privacy being addressed early?
2. Is the solution proactive?
3. Is only the necessary data processed?
4. Is the individual protected without needing to act?
The answer that meets these criteria most completely is usually correct.