Privacy by default is the principle that a product or service must, without any action by the user, apply the most privacy-protective settings available, so that only the personal data necessary for each specific purpose is collected, processed, stored and made accessible. In privacy engineering it turns data minimization from a policy statement into a concrete configuration state that ships with the system.
The principle is a legal obligation in the European Union under Article 25(2) of the GDPR, which names four dimensions that defaults must limit: the amount of data, the extent of processing, the storage period and accessibility. It is the narrower, measurable companion of privacy by design, which governs the whole development process.
The four dimensions privacy by default controls
Privacy by default is easiest to apply when each default is checked against the four dimensions of Article 25(2). A setting passes only if all four are limited to what the declared purpose requires, not to what might be useful later.
| Dimension | Question to ask | Protective default |
|---|---|---|
| Amount of data | Which fields are truly required? | Optional fields empty and clearly optional |
| Extent of processing | Which operations run automatically? | Analytics, profiling and sharing switched off |
| Storage period | How long is the data kept? | Automatic deletion after a defined period |
| Accessibility | Who can see the data? | Private visibility, not public or indefinite |
The accessibility dimension carries a specific warning in the regulation: personal data must not be made available to an indefinite number of people without the individual’s intervention. A social profile that is public on creation is the textbook violation of privacy by default.
How privacy by default differs from privacy by design
The two principles are often quoted together, but they answer different engineering questions. Privacy by design asks how the system is built; privacy by default asks what state the system is in when a new user starts using it.
| Principle | Focus | Typical evidence |
|---|---|---|
| Privacy by default | Initial settings and configuration | Default values, toggle states, retention timers |
| Privacy by design | Architecture and the development process | Threat models, design reviews, PETs in use |
| Data minimization | General limit on collected data | Data inventory linked to purposes |
| Storage limitation | Retention of identifiable data | Retention schedule and deletion jobs |
| Consent | Legal basis chosen by the user | Records of affirmative choices |
Privacy by default does not forbid features. It forbids turning them on silently. A user may enable location history, public sharing or personalized advertising, but the system must start in the protective position and require a deliberate choice to move away from it.
Implementing privacy by default in products
In practice, privacy by default is implemented through configuration, data models and retention mechanisms, and it is verified by inspecting a fresh account or installation. Engineering teams usually translate the principle into concrete checks.
- Every toggle that increases processing starts in the off position, including analytics, ad personalization and data sharing with partners.
- Forms mark the minimum required fields, and optional fields are never pre-filled from other sources.
- Retention timers are set at creation, for example deleting raw logs after 30 to 90 days, depending on the purpose.
- Visibility defaults for posts, profiles and files are private or limited to chosen contacts.
- Telemetry is aggregated or pseudonymized before storage when individual records are not needed.
- Internal access follows least privilege, so staff cannot browse personal data by default.
The table below shows typical decisions and the reasoning behind a protective default.
| Feature | Protective default | Reason |
|---|---|---|
| Location services in an app | Off, or approximate location only | Precise location is rarely needed for the core function |
| Crash reports | Ask on first crash, strip identifiers | Diagnostic value does not require identity |
| Contact list upload | Not uploaded | Contacts include data about third parties |
| Search history | Auto-delete after a fixed period | Long histories enable profiling |
| Profile discoverability | Not findable by phone number or email | Prevents enumeration and unwanted contact |
Pitfalls and dark patterns that undermine defaults
Privacy by default is frequently defeated not by the initial setting but by design pressure afterward. Regulators treat these patterns as evidence that the default was protective only on paper.
| Failure | How it appears | Correction |
|---|---|---|
| Pre-ticked boxes | Sharing options already selected | Leave every optional box unticked |
| Onboarding nudges | Repeated prompts to enable tracking | Ask once with a neutral choice |
| Silent resets | Updates switch settings back on | Preserve user choices across versions |
| Bundled settings | One switch covers several purposes | Separate controls for each purpose |
| Endless retention | No deletion until the account closes | Purpose-based retention periods |
Another pitfall is treating legacy users differently. When a protective default is introduced, existing accounts often keep the old permissive settings. A rigorous rollout reviews whether those settings were ever validly chosen by the user or were simply inherited.
Verifying and documenting compliance
Because privacy by default concerns observable states, it can be tested like any other requirement. Teams create a new account or a clean installation and record every setting, every network request and every stored record before the user changes anything.
The findings feed the data protection impact assessment and the record of processing. Mature organizations add automated tests that fail the build if a default changes from protective to permissive without a documented decision, which turns the principle into a regression-proof control rather than a one-time review.
Put simply
Privacy by default means a new app or service should protect you before you touch a single setting. You should not have to search through menus to stop sharing your location, your contacts or your posts with strangers.
Think of a new apartment where every door and window is already locked when you get the keys. You can open any window you like, but nobody opened it for you. If you want more sharing, you choose it yourself.
In practice
A fitness app team prepares a new release that records running routes. The first draft makes every activity public by default and keeps raw GPS traces forever. During the privacy review, the team applies the four dimensions of privacy by default.
The release changes three things. New activities are now visible only to the user, the first and last 200 meters of each route are hidden automatically to protect home addresses, and raw GPS traces are deleted after 12 months while summary statistics remain. Sharing with followers is one clear tap away.
Testing a fresh account confirms that no route leaves the device publicly until the runner chooses to share it, and the team records the decision in its impact assessment.