Proactive Not Reactive and Privacy as the Default Setting

Proactive Not Reactive and Privacy as the Default Setting: A CIPT Guide to the First Two Principles of Privacy by Design

Introduction
Privacy by Design (PbD) is a framework developed by Dr. Ann Cavoukian, then Information and Privacy Commissioner of Ontario, Canada, in the 1990s. In 2010 it was adopted by resolution at the International Conference of Data Protection and Privacy Commissioners. PbD has seven foundational principles. The first two are Proactive not Reactive; Preventative not Remedial and Privacy as the Default Setting. They are central to the IAPP Certified Information Privacy Technologist (CIPT) exam. They also shaped Article 25 of the GDPR, Data Protection by Design and by Default. This guide explains what the two principles are, why they matter, how they work in practice, and how to answer exam questions about them.

The Seven Foundational Principles (for context)
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 Lifecycle Protection
6. Visibility and Transparency: Keep it Open
7. Respect for User Privacy: Keep it User-Centric

Principle 1: Proactive not Reactive; Preventative not Remedial

What it is
Privacy protection should anticipate and prevent privacy-invasive events before they happen. It should not wait for risks to materialize and then offer remedies. In Cavoukian's words, PbD "comes before the fact, not after."

Key characteristics
- A clear commitment from leadership to set and enforce high privacy standards, often higher than the law requires.
- A privacy commitment shared by users, user communities and stakeholders, demonstrated through continuous improvement.
- Established methods to recognize poor privacy designs, anticipate poor practices and outcomes, and correct negative impacts well before they occur.

How it works in practice
- Privacy Impact Assessments (PIAs) and Data Protection Impact Assessments (DPIAs) are run early in the system development lifecycle (SDLC), at requirements and design stages, not after deployment.
- Threat modeling for privacy uses frameworks such as LINDDUN (Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance). These identify privacy threats before code is written.
- Privacy requirements are part of user stories, acceptance criteria and architecture reviews.
- Privacy champions sit within engineering teams.
- Vendor due diligence happens before procurement.
- Data minimization decisions are made at the design stage, settling what data is collected and why.
- Continuous monitoring and metrics allow emerging risks to be found early.

Reactive approaches (what the principle rejects)
- Waiting for a breach, complaint or regulatory fine before acting
- Bolting privacy controls onto a finished product
- Relying only on incident response and breach notification as the privacy strategy
- Treating privacy as a legal checkbox at launch

Why it matters
- Cost: Fixing defects late in the SDLC costs far more than fixing them during design. The same applies to privacy defects.
- Trust and reputation: Preventing harm protects individuals and brand value.
- Regulatory alignment: GDPR Article 25 requires appropriate measures "at the time of the determination of the means for processing." Article 35 requires DPIAs before high-risk processing.
- Harm is often irreversible: Once personal data is exposed, it cannot be un-exposed. Remedies after the fact rarely make individuals whole.

Principle 2: Privacy as the Default Setting

What it is
Personal data should be protected automatically in any IT system or business practice. No action is required by the individual to protect their privacy. If the user does nothing, their privacy stays intact, because protection is built into the system by default.

Key characteristics, aligned with the Fair Information Practice Principles (FIPPs)
- Purpose specification: The purposes for collecting, using, retaining and disclosing personal data are communicated to the individual at or before collection.
- Collection limitation: Collection must be fair, lawful and limited to what is necessary for the specified purposes.
- Data minimization: Collection of identifiable information is kept to a strict minimum. Systems should default to non-identifiable interactions and transactions wherever possible.
- Use, retention and disclosure limitation: Data is used, kept and disclosed only for the purposes consented to, except where law requires otherwise. It is kept only as long as needed and then securely destroyed.

How it works in practice
- Opt-in rather than opt-out for non-essential processing, such as marketing, analytics cookies, location tracking and data sharing
- Most protective settings preselected: social media profiles private by default, location services off by default, microphone and camera off until needed
- No pre-ticked consent boxes (see the CJEU Planet49 decision)
- Short default retention periods with automatic deletion
- Pseudonymization or anonymization by default where identification is not needed
- Least privilege access controls by default for internal users
- Encryption enabled by default for data at rest and in transit
- Telemetry and diagnostics minimized or off by default

GDPR link
GDPR Article 25(2) requires the controller to implement measures ensuring that, by default, only personal data necessary for each specific purpose is processed. This applies to:
- the amount of data collected
- the extent of processing
- the period of storage
- accessibility
In particular, personal data should not be made accessible to an indefinite number of people without the individual's intervention.

Why it matters
- Behavioral reality: Most users never change default settings. This is the status quo bias and the power of defaults studied in behavioral economics. Whatever the default is becomes the de facto outcome for most people.
- Reduces burden on individuals: People should not need technical skill or time to protect themselves.
- Counters dark patterns: Privacy-protective defaults avoid manipulative design that pushes users toward oversharing.
- Reduces organizational risk: Less data collected and retained means less data to breach, manage and defend.

How the Two Principles Work Together
Proactive design is the mindset and the process: anticipating risk early. Privacy as the default is a primary outcome of that process: systems ship in a privacy-protective state. A team that carries out a DPIA during design (proactive) will usually decide that optional data sharing must be opt-in and that retention should be minimal (default). Together they move privacy left in the SDLC and make protection automatic.

Related Concepts You Should Know
- Privacy Engineering: the discipline that puts PbD into practice through requirements, design patterns and testing
- Data Protection by Design and by Default (GDPR Art. 25): the legal codification of PbD
- ISO 31700 (2023): an international standard on privacy by design for consumer goods and services
- NIST Privacy Framework: supports proactive risk management
- Privacy Design Strategies (Hoepman): Minimize, Hide, Separate, Aggregate, Inform, Control, Enforce, Demonstrate. The first four are data-oriented and support defaults.
- Dark patterns: deceptive designs that undermine defaults and consent
- Shift-left: moving security and privacy activities earlier in development

Worked Examples
Example 1: A company is building a fitness app. During the design sprint, the team runs a privacy threat model and finds that continuous GPS tracking could reveal home addresses. They decide to blur start and end points by default and to make public route sharing opt-in. Running the threat model at design time is Proactive. Blurred points and opt-in sharing are Privacy as the Default.

Example 2: A retailer launches a loyalty program and later receives complaints about data being sold to partners. It then adds an opt-out link. This is Reactive and violates both principles. The sharing should have been assessed before launch and made opt-in or avoided entirely.

Example 3: A smart speaker ships with voice recordings retained indefinitely. Users can delete them only through a hidden menu. This fails Privacy as the Default. A compliant design would retain recordings only briefly, or not at all, by default.

Exam Tips: Answering Questions on Proactive Not Reactive and Privacy as the Default Setting

1. Know the exact wording. Memorize "Proactive not Reactive; Preventative not Remedial" and "Privacy as the Default Setting." Questions may ask you to name the principle from a scenario or a quote. Phrases such as "before the fact," "anticipate and prevent" or "before privacy risks materialize" point to Principle 1. Phrases such as "no action required by the individual" or "automatically protected" point to Principle 2.

2. Look for timing cues. If a scenario stresses when privacy was considered (early design, requirements, before launch, before purchase), the answer is usually Proactive. If privacy work happens after a breach, complaint or audit finding, the scenario describes a reactive approach. The question will usually ask you to spot it as the wrong approach or to say what should have happened.

3. Look for user-action cues. If the question centers on whether the user must do something to be protected, it is testing Privacy as the Default. Pre-ticked boxes, opt-out models, public-by-default profiles and broad default sharing are all violations.

4. Pick the most protective, earliest option. When several answers seem plausible, choose the one that prevents the problem rather than fixing it. For example, conducting a PIA at the design stage beats running a post-launch audit. Collecting less data beats encrypting more data. Making a setting opt-in beats sending a notice with an opt-out.

5. Separate defaults from transparency and user control. Giving notice (Visibility and Transparency) or offering granular controls (Respect for User Privacy) is good. Neither one makes something privacy by default. If an answer offers a clear notice plus an opt-out, it is weaker than an answer that makes the protective setting automatic.

6. Connect to data minimization. Data minimization is the heart of Privacy as the Default. Expect questions in which the correct answer limits collection, purpose, retention or access by default.

7. Map to GDPR Article 25. CIPT questions may cite "Data Protection by Design and by Default." Remember the four dimensions of Article 25(2): amount collected, extent of processing, storage period and accessibility. Remember also that by-design measures apply at the time of determining the means of processing and at the time of processing itself.

8. Spot reactive red flags in answer choices. Distractors often include "wait until," "respond to complaints," "rely on breach notification," "add controls in the next release" and "address it if regulators ask." These are almost always wrong for PbD questions.

9. Remember the leadership and culture element. Proactive privacy is not only technical. It includes executive commitment, standards that may exceed legal requirements, and methods for recognizing poor design. An answer about senior management setting high privacy standards early can be correct for Principle 1.

10. Watch for positive-sum framing. If an answer suggests that privacy defaults must sacrifice functionality, be cautious. PbD rejects zero-sum trade-offs (Principle 4). Good answers deliver both privacy and functionality.

11. Use process-of-elimination logic. Ask three questions:
(a) Does this option act before harm occurs?
(b) Does it protect the user without requiring the user to act?
(c) Does it minimize data?
The option that satisfies the most of these is likely correct.

12. Practice scenario translation. Turn each scenario into a short label, such as "early risk assessment = proactive" or "opt-in, private profile, short retention = default." This speeds up recognition under time pressure.

Quick Recap
- Proactive not Reactive: anticipate and prevent privacy harms before they happen, using PIAs/DPIAs, threat modeling, early requirements and leadership commitment.
- Privacy as the Default: systems protect personal data automatically, without user action, through opt-in choices, minimization, limited retention, restricted access and protective preset settings.
- Both principles are codified in GDPR Article 25 and form the foundation of privacy engineering.
- In the exam, favor answers that are earliest, most protective and require the least effort from the individual.