Skip to main content
Privacy Track
Category: Privacy Governance & Design

Default Settings

Also known as: Defaults, Default Configuration, Preset Settings
Simply put

Default settings are the preset configurations, values, or behaviors that a system, software, or device uses automatically when a user has not made a specific choice. They represent the standard state a product ships with before anyone customizes it. In a privacy context, the way defaults are configured can significantly affect how much personal data is collected or shared, since many users never change them.

Formal definition

In information technology, a default is a pre-designed value or setting applied by software, a device, or a system when a specific value or setting has not been explicitly specified by the user. Default settings constitute the standard baseline configuration present at initial installation or provisioning and persist until deliberately overridden; systems can typically be reset to restore these original values. Note: the evidence packet describes 'default' as a general technical concept only and does not address privacy-by-default obligations or any GDPR provision, which should be evaluated separately against the current official text and applicable guidance.

Why it matters

Default settings carry outsized privacy significance because behavioral research and practical experience consistently show that most users never change the configuration a product ships with. When a system's defaults are set toward more data collection or wider sharing, that preset state effectively becomes the operative choice for the majority of a user base, regardless of what individuals might have selected if prompted. This is why the configuration of defaults is often treated as a design decision with direct consequences for how much personal data flows through a product.

The evidence digest describes 'default' purely as a general technical concept, so this entry does not itself establish any legal obligation. That said, readers should note that EU and UK data protection law contain a separate, distinct concept of data protection by default, which is addressed under its own provision and guidance and must be evaluated against the current official text. The technical notion of a default setting and the legal principle of privacy by default are related but not identical, and this definition should not be read as a statement of either the EU or UK obligation.

Because the boundary between a mere technical preset and a legally relevant default configuration depends on context, purpose, and applicable law, organizations should treat default configuration as a matter requiring separate assessment. What a product ships with can materially affect a later analysis of lawfulness, data minimization, and user expectations, so the initial state is generally worth documenting rather than assuming it is neutral.

Who it's relevant to

Engineers and product teams
Those who build and configure software, devices, or systems decide what the shipped baseline looks like. Because most users leave defaults unchanged, engineers effectively set the operative configuration for the majority of a user base and should be able to document what the initial state collects or shares and why.
Data protection officers and compliance leads
DPOs and compliance staff need to distinguish the general technical concept of a default setting from any legal principle of data protection by default, which is governed separately. They should assess how a product's presets bear on data minimization and lawfulness against the current official text and applicable regulatory guidance rather than assuming defaults are neutral.
Privacy and product counsel
Lawyers advising on product design benefit from understanding that the initial configuration a system ships with can be relevant to a later legal analysis. Counsel should flag where the technical default and any applicable privacy-by-default requirement diverge, and note that member state implementation and regulator interpretation may vary.
System administrators
Administrators who provision and maintain systems work directly with defaults and reset behavior. They are typically responsible for whether restored or newly provisioned systems return to a baseline state, and should understand that resetting to defaults reinstates the original shipped configuration.

Inside Default Settings

Data protection by default
The principle, expressed in Article 25 GDPR, that a controller must implement appropriate technical and organisational measures to ensure that, by default, only personal data necessary for each specific purpose of processing is processed. This applies to the amount of data collected, the extent of processing, the period of storage, and accessibility.
Necessity and data minimisation
Default settings should reflect the minimisation principle: absent an active choice by the individual, the least privacy-intrusive configuration applies. Only data genuinely required for the defined purpose should be processed by default, subject to assessment of what is necessary for that purpose.
Accessibility limitation
By default, personal data should not be made accessible to an indefinite number of persons without the individual's intervention. This typically covers restricting who within an organisation and which external parties can access the data absent a deliberate change to the setting.
Relationship to data protection by design
Default settings are one component of the broader Article 25 obligation, which also covers data protection by design. By design generally concerns embedding safeguards throughout the processing lifecycle, while by default concerns the pre-set configuration that applies without user action; the two are related but distinct.
Configuration of storage periods and processing extent
Default settings extend beyond collection to encompass how long data is retained and how extensively it is processed. In most cases the default should favour shorter retention and narrower processing unless the individual actively selects otherwise.

Common questions

Answers to the questions practitioners most commonly ask about Default Settings.

Does data protection by default mean users can never be shown any features or processing beyond the bare minimum?
No. Data protection by default, associated with Article 25 GDPR, generally requires that, by default, only personal data necessary for each specific purpose of the processing is processed. It does not prohibit offering additional features or optional processing; rather, it means such optional processing should typically not be switched on automatically without the individual's engagement. The precise expectation is context and risk dependent, and you should verify the current position against the official text and applicable regulatory guidance.
Is having privacy-friendly default settings the same as obtaining valid consent?
No, these are distinct concepts. Configuring restrictive defaults addresses the data protection by default obligation, whereas consent is one of the separate Article 6 legal bases (alongside contract, legal obligation, vital interests, public task, and legitimate interests). A default setting is not itself a legal basis, and consent is not required for all processing. Where consent is relied upon, it must meet its own validity standards, which pre-ticked or pre-enabled options generally do not satisfy. Special category data under Article 9 additionally requires a separate condition.
How should default settings be documented to demonstrate accountability?
Organisations typically record the default configuration for each processing purpose, the necessity reasoning behind it, and who approved it, so the choices can be evidenced if questioned. This documentation often sits alongside records of processing and, where relevant, a Data Protection Impact Assessment. The appropriate level of detail is risk dependent, and you should confirm expectations against current regulatory guidance, which can evolve.
Who within an organisation should be responsible for setting and reviewing defaults?
Responsibility generally sits with the controller, typically involving product or engineering teams who implement the settings, with input from privacy or data protection functions on necessity and risk. A Data Protection Officer, where appointed, may advise rather than decide. Allocation of roles varies by organisation, so it should be defined internally rather than assumed.
At what points should default settings be reviewed?
Defaults are commonly reviewed when a product or feature is designed, before launch, and again when the purpose, functionality, or data collected changes materially. Periodic review is also typical to check that defaults still reflect the principle of processing only what is necessary. The suitable frequency is context dependent and should be set according to the organisation's risk assessment.
How do default settings relate to a Data Protection Impact Assessment?
Default settings can be one of the design measures considered within a Data Protection Impact Assessment under Article 35, which assesses risks to individuals for certain processing. The two are not the same: a DPIA is a risk assessment process, while defaults are a specific configuration choice that may help mitigate identified risks. Whether a DPIA is required depends on the nature of the processing, so this should be assessed case by case.

Common misconceptions

Data protection by default is the same thing as data protection by design.
Both derive from Article 25 GDPR but address different aspects. By design generally refers to embedding safeguards into processing activities and systems, whereas by default refers specifically to the pre-set configuration that governs the amount, extent, storage period, and accessibility of personal data absent user intervention. They are complementary obligations rather than synonyms.
Setting privacy-protective defaults means the organisation has fully complied with the GDPR.
Default settings are one element of Article 25 and do not, on their own, establish overall compliance. A valid legal basis under Article 6 (and an additional condition under Article 9 for special category data), transparency, security, and other obligations still apply. Compliance is context and risk dependent and requires assessment of the whole processing activity.
Data protection by default always requires consent for any data processing.
Article 25 does not mandate consent. Consent is only one of the Article 6 legal bases, and the appropriate basis depends on the processing. The default principle concerns minimising data processed absent user intervention; it does not convert every default into a consent question.

Best practices

Configure systems so that the least privacy-intrusive option applies by default, requiring an affirmative choice by the individual to broaden the amount, extent, retention period, or accessibility of their personal data.
Assess and document what personal data is genuinely necessary for each specific processing purpose, and align default settings to that assessment rather than to the maximum data the system can collect.
Limit default accessibility so that personal data is not exposed to an indefinite number of internal or external persons without the individual's intervention, and review access controls regularly.
Treat data protection by default alongside, but distinct from, data protection by design, ensuring both aspects of Article 25 are addressed when building or configuring products and services.
Confirm an appropriate legal basis under Article 6 (and an additional condition under Article 9 where special category data is involved) separately, since privacy-protective defaults do not by themselves satisfy those requirements.
Verify configurations against the current official text of the applicable regulation and relevant regulator guidance, noting that positions can vary between member states and between EU and UK GDPR.