Fundamentals

Privacy by Default: What It Is and Why Initial Settings Matter

By Daniel Sardá · Published on October 21, 2026

6 min read1,278 words

Privacy by default makes data protection the starting point of a service instead of requiring each person to turn it on afterward.

When opening an account, a service may ask for a name, location, contacts, date of birth, and permission to make a profile public. Some of those options may be useful. The decisive question is different: should they be enabled from the outset, or should the person choose them later?

Privacy by default addresses that problem. Its central idea is straightforward: initial settings should limit the processing and disclosure of personal data to what is necessary for a specific purpose. People should not have to work through menus, untick boxes, or discover hidden settings to reach a basic level of protection.

It does not mean that a service can never request additional information. It means the service should be able to explain why it needs that information, and optional features should not make maximum collection the starting point.

Key idea: A protective default does not eliminate choice. It changes who bears the initial burden: the person who would otherwise have to protect themselves, or the party seeking to collect and disclose more data.

The starting point is a decision too

Initial settings may look neutral, but they distribute costs. Accepting what is already selected takes little effort; reviewing every permission takes time, information, and attention. Nor is it always clear what the consequences of a setting will be months later.

For that reason, privacy by default is not limited to the visible switches in an app. It also reaches technical and organizational choices: which fields count as mandatory, how long information is kept, and which people can access it inside and outside an organization.

Article 25 of the General Data Protection Regulation makes this principle an obligation within its scope of application. It requires appropriate technical and organizational measures so that, by default, only the personal data necessary for each specific purpose are processed. The requirement depends on context, purpose, and risk; it does not establish one settings screen that fits every service.

That European framework is an influential reference, but it should not be presented as universal law. The precise obligations vary by jurisdiction and by the kind of processing involved.

Privacy by default and data protection by design

The two ideas often appear together, but they serve different functions.

Data protection by design incorporates data protection when a product is conceived, its means are chosen, and it is operated throughout its life cycle. It calls for thinking about risks before they materialize and revisiting safeguards over time. Spain’s data protection authority emphasizes precisely this preventive and continuous character.

Privacy by default, by contrast, focuses on the initial state: what happens if the person changes nothing. A system may incorporate strong technical protections during its design and still begin with unnecessarily broad visibility. It may also offer many controls while shifting all responsibility onto someone who may not know they need to use them.

The distinction can be put simply: design accompanies the whole process; default settings determine where the experience begins.

Four questions for recognizing it

Article 25(2) of the GDPR can be translated into four dimensions of the principle. The Catalan Data Protection Authority uses them as well to explain its application:

• Amount: Are only necessary data requested, or is optional information collected from the start as well?
• Scope of processing: Are the data used only for the stated purpose, or are other uses enabled too?
• Retention: Are they kept for the necessary time, or indefinitely without a clear reason?
• Accessibility: Can only those who need the data see them, or are they exposed to a wider, even indeterminate, group?

These questions show why privacy and security are not synonyms. A database may be well protected against intrusions yet still contain excessive information, retain it for too long, or make it available to too many authorized people. Security asks, among other things, how data are protected; privacy also asks which data are collected, for what purpose, and within what limits.

Useful distinction: Data minimization does not mean prohibiting all processing. It permits what is necessary for a legitimate purpose and requires a justification for what goes beyond it.

What it looks like in everyday situations

Consider a new profile. A privacy-respecting setting could keep it out of public search results until its owner decides to make it visible. The alternative does not prevent the profile from being created; it prevents disclosure from being automatic.

In a form, a piece of information useful for an additional feature could be optional and left blank, rather than preselected or presented as a requirement. The person could still provide it when they choose to activate that feature.

Something similar applies to retention. If certain information is needed only to complete an operation, the system could provide for its deletion once it is no longer necessary, unless there is a justified reason to retain it. There is no single period for every case; what matters is that the duration responds to the purpose rather than to the mere inertia of storing data.

These examples are general criteria, not claims about a particular company’s practices. Nor do they imply that the most restrictive imaginable option must always be chosen. A service may need certain data to operate, prevent abuse, or meet an obligation. Privacy by default asks for that need to be specific and explainable.

Consent, autonomy, and responsibility

Checking a box does not by itself settle every question about choice. Consent is more meaningful when information is understandable, alternatives are real, and declining optional features does not require overcoming artificial obstacles. Consent is not the only possible legal basis for processing personal data, so it should not be used as a universal explanation.

From the perspective of individual agency, initial settings matter because autonomy requires more than a formal ability to change preferences. It requires a starting point that does not exploit lack of time, information asymmetry, or inertia to obtain a broader surrender of data.

This is a normative interpretation, not a literal statement of the GDPR: the party setting the defaults should bear the responsibility of justifying initial collection and disclosure. The person, in turn, remains free to enable later a feature they value. Protecting the starting point and preserving later choice are compatible goals.

Practical standard: If an additional feature needs more data, the sensible approach is to explain the tradeoff and let the person enable it on an informed basis, rather than assuming acceptance from the outset.

What this principle does not guarantee

Privacy by default reduces unnecessary exposure, but it does not create anonymity, absolute confidentiality, or zero risk. A prudent setting also cannot on its own correct security failures, vague purposes, or poor organizational practices.

There is, moreover, no identical setting for every context. Data that are essential in one service may be superfluous in another. Appropriate measures depend on the purpose, the kind of information, the technology, and the risks to people. A specific legal assessment requires considering the applicable rule and the circumstances of the processing.

The value of the principle lies in reversing a common presumption. Instead of collecting or publishing first and asking the user to limit it later, it requires beginning with what is necessary. From there, every expansion should have an understandable reason and a real choice. That is the most useful test of a good initial setting: not how much it can extract through inertia, but what it can justify before doing so.