Category: Privacy Governance & Design

Minimisation by Design

Also known as: Data Minimisation by Design, Data Minimisation by Design and by Default

Simply put

Minimisation by design means building products, systems, and services so that they collect and keep only the personal data genuinely needed for a specific purpose, rather than gathering data by default and deciding later how to limit it. In practice this can include avoiding the processing of personal data altogether where the purpose can still be achieved. It combines the idea of data minimisation with the practice of embedding privacy protections into how a service is developed and configured.

Formal definition

Minimisation by design refers to the operationalisation of the data minimisation principle through the design and default configuration of processing systems, consistent with the concept of data protection by design and by default. Under the GDPR, the data minimisation principle requires that personal data be adequate, relevant and limited to what is necessary in relation to the purposes for which it is processed; regulator guidance frames the design dimension as selecting and configuring processing so that, by default, only the minimum personal data necessary for each specific purpose is collected, used, and retained. Recognised design and default elements may include data avoidance (not processing personal data where the purpose can be achieved otherwise), limiting collection to individual service elements, and constraining retention. The term is not itself a defined phrase in the Regulation text but is derived from the data minimisation principle read together with the data protection by design and by default obligation; practitioners should verify the precise article references and current wording against the official text of the applicable EU GDPR or UK GDPR, as national implementing law and regulator guidance may vary the detailed expectations.

Why it matters

Minimisation by design matters because it shifts data protection from a compliance step applied after a system is built to a discipline embedded in how products and services are conceived and configured. Under the GDPR, the data minimisation principle requires that personal data be adequate, relevant and limited to what is necessary for the purposes of processing. When minimisation is only considered late, organisations often find that systems have already been designed to collect data by default, making it harder and costlier to unwind. Building minimisation in from the outset reduces the volume of personal data held, which in turn typically reduces the scope of harm if a breach occurs and narrows the surface area subject to individual rights requests and retention obligations.

The concept sits at the intersection of the data minimisation principle and the data protection by design and by default obligation, and regulators have set expectations for both. The EDPB's guidance on data protection by design and by default identifies design and default elements such as data avoidance, and the ICO's guidance frames minimisation as collecting only the data needed to deliver an individual element of a service. Treating minimisation as a design property, rather than a downstream control, aligns an organisation's practices with these expectations and supports its wider accountability posture.

Because the detailed expectations can vary between the EU GDPR and the UK GDPR, and may be further shaped by national implementing law and evolving regulator guidance, organisations should treat minimisation by design as a context-dependent assessment rather than a fixed checklist. What counts as necessary depends on the specific purpose, and readers should verify the precise requirements and article references against the current official text applicable to them.

Who it's relevant to

Product managers and designers

Those shaping what a product or service does are generally best placed to decide which data fields are genuinely necessary for each feature. Minimisation by design asks them to justify each element of collection against a specific purpose, to consider whether the purpose can be achieved without personal data at all, and to set defaults so that the minimum data is gathered unless a user actively chooses otherwise.

Engineers and system architects

Engineers translate minimisation choices into configuration and code, for example by limiting default data capture, avoiding processing of personal data where a purpose can be met otherwise, and building retention limits into how data is stored and deleted. Because default settings drive real-world behaviour, architectural decisions typically have a lasting effect on how much personal data a system holds.

Data protection officers and privacy leads

DPOs and privacy teams advise on whether design decisions are consistent with the data minimisation principle and the data protection by design and by default obligation, and help document the reasoning as part of accountability. They also flag where expectations may differ between the EU GDPR and UK GDPR, or where evolving regulator guidance should be reviewed before finalising an approach.

Compliance and legal teams

Legal and compliance functions assess whether minimisation by design has been adequately embedded, including within any data protection impact assessment where high-risk processing is involved. They typically verify that necessity has been assessed against the specific purpose and that article references and detailed requirements are confirmed against the current official text applicable to the organisation.

Inside Minimisation by Design

Data Minimisation Principle

The underlying principle, expressed in Article 5(1)(c) GDPR, that personal data must be adequate, relevant and limited to what is necessary in relation to the purposes for which it is processed. Minimisation by Design applies this principle at the point of system and process design.

Data Protection by Design and by Default

The obligation under Article 25 GDPR to implement appropriate technical and organisational measures designed to give effect to data protection principles (including minimisation) and to ensure that, by default, only personal data necessary for each specific purpose is processed. Minimisation by Design is generally understood as a component of this broader obligation.

Purpose Specification

A clearly defined, specified purpose against which the necessity of each data element is assessed. Minimisation cannot generally be evaluated without a settled processing purpose, which links to the purpose limitation principle in Article 5(1)(b) GDPR.

Necessity Assessment

A documented judgement about whether each category or field of personal data is genuinely required to achieve the stated purpose, and whether a less data-intensive means would suffice. This is typically a context-dependent and risk-based assessment.

Technical Measures

Design-level controls such as collecting fewer fields, shortening retention, pseudonymisation, aggregation, or (where feasible) anonymisation. Note that anonymous data generally falls outside the material scope of the GDPR, whereas pseudonymised data remains personal data.

Organisational Measures

Governance elements such as data inventories, default configuration standards, access limitation, and retention schedules that operationalise minimisation across the data lifecycle rather than at collection alone.

Common questions

Answers to the questions practitioners most commonly ask about Minimisation by Design.

Is data minimisation the same as deleting data as quickly as possible?

No. Minimisation concerns limiting personal data to what is adequate, relevant, and necessary for the specified purpose, which is a distinct principle from storage limitation (retention duration). While the two often work together, minimisation focuses on the scope and volume of data collected and processed rather than solely on how long it is kept. In most cases you should assess both principles separately when designing a system.

Does minimisation by design mean collecting the least data technically possible regardless of purpose?

Not quite. The standard is necessity relative to a defined purpose, not the absolute minimum in the abstract. Data that is genuinely required to achieve a legitimate, specified purpose can be collected; the assessment is whether each data element is adequate and relevant to that purpose. Collecting too little to serve the stated purpose is a separate problem from over-collection, so the design goal is proportionality to purpose rather than minimisation for its own sake.

How can minimisation be built into a system at the design stage?

Typically this involves defining the processing purpose first, then mapping which data fields are strictly necessary to that purpose, and configuring collection interfaces, forms, and default settings to capture only those fields. Techniques such as pseudonymisation, aggregation, and restricting field granularity can support minimisation. The appropriate measures depend on the context, the nature of the processing, and a risk assessment, so approaches should be documented and revisited.

How does minimisation interact with the legal basis relied upon under Article 6?

The chosen legal basis frames the purpose against which necessity is assessed, but minimisation applies regardless of which Article 6 basis is used. For example, where processing relies on necessity for a contract or on legitimate interests, only data necessary for that purpose should be processed. Where special category data is involved, an additional Article 9 condition is required, and minimisation of such data warrants particular care. You should verify the specific requirements against the current official text.

How can an organisation demonstrate that it has applied minimisation by design?

Accountability generally requires documentation showing the reasoning behind data collection decisions. This can include records mapping data fields to purposes, design decision logs, data protection impact assessments where required, and periodic reviews confirming that collected data remains necessary. Retaining evidence of these assessments helps demonstrate compliance, though the sufficiency of any given approach is context-dependent and subject to assessment.

How often should minimisation decisions be reviewed after a system goes live?

Minimisation is generally treated as an ongoing obligation rather than a one-time exercise. Reviews are typically warranted when purposes change, new features are added, or additional data begins to be collected, and periodic reassessment helps ensure previously justified data remains necessary. There is no single prescribed interval in the Regulation text, so the frequency should reflect the risk and nature of the processing.

Common misconceptions

Minimisation by Design means collecting the smallest possible amount of data in all cases.

The standard is necessity and proportionality relative to a specified purpose, not the absolute minimum. Data that is genuinely required for a legitimate, specified purpose can generally be processed; minimisation limits data to what is adequate, relevant and necessary, subject to assessment.

Minimisation by Design is a separate, standalone GDPR obligation distinct from data protection by design.

It is more accurately understood as the application of the Article 5(1)(c) minimisation principle within the Article 25 obligation of data protection by design and by default, rather than an independent requirement with its own article.

Once data is minimised or pseudonymised at collection, the obligation is satisfied.

Minimisation typically applies across the full data lifecycle, including retention and deletion, and pseudonymised data remains personal data within scope of the GDPR. Only data that meets the threshold for anonymisation generally falls outside that scope, and whether that threshold is met is itself a matter for assessment.

Best practices

Define and document the specific processing purpose before deciding which personal data fields to collect, so necessity can be assessed against a settled purpose.

Conduct and record a field-by-field necessity assessment, retaining the rationale for each data element collected to support accountability.

Configure systems so that, by default, only the personal data necessary for each purpose is processed, in line with the default aspect of the data protection by design obligation.

Apply lifecycle controls such as defined retention periods and deletion or aggregation routines, rather than treating minimisation as a one-off decision at collection.

Where full data is not required, consider less data-intensive alternatives such as pseudonymisation or aggregation, bearing in mind that pseudonymised data remains personal data.

Revisit minimisation decisions when purposes, systems, or applicable guidance change, and verify current requirements against the official regulatory text, as interpretation can evolve.