What is data protection by design and by default?

Data protection by design and by default is the requirement to embed privacy, data protection principles and safeguards into systems, services, products and processes from the earliest planning stage and throughout their lifecycle. By default, organisations must limit personal information to what is necessary for each specific purpose, including collection, use, retention and access.

Under Article 25 of the UK GDPR, controllers must implement appropriate technical and organisational measures that make the data protection principles effective and protect people's rights. The obligation is not satisfied by adding a privacy notice or security control shortly before launch. Privacy must influence requirements, architecture, configuration, procurement, testing, deployment, operation, change and decommissioning.

The Information Commissioner's Office (ICO) describes this as considering privacy at the start of everything an organisation does and integrating it throughout the processing lifecycle. The ICO updated its guidance in February 2026 to reflect changes introduced by the Data (Use and Access) Act 2025, including a specific duty concerning online services likely to be accessed by children.

What is the difference between data protection by design and data protection by default?

Data protection by design: means considering privacy and data protection issues when a system, service, product or process is conceived, and continuing to review those issues throughout its lifecycle.

Data protection by default: means configuring the service or process so that only the personal information necessary for each specified purpose is collected, used, retained and made accessible without requiring the individual to change settings.

A service may be designed with privacy controls but still fail the default requirement if optional tracking is enabled automatically, access is broader than necessary, retention is indefinite or users must actively reduce unnecessary data use. Both elements must operate together.

Who is responsible for data protection by design?

The controller is responsible because it determines why and how personal information is used. Senior management remains accountable for ensuring that governance, resources and decision rights make compliance possible. Practical responsibilities are usually distributed across:

  • Board and executive sponsors - set risk appetite, approve investment and receive assurance.
  • Product, programme and service owners - ensure privacy requirements are built into delivery decisions.
  • Data protection officer or privacy team - advise, challenge, monitor and support DPIAs while preserving independence.
  • Information security and technology teams - implement security, identity, access, resilience and engineering controls.
  • Procurement and supplier-management teams - test privacy capability before contracting and throughout the supplier lifecycle.
  • Legal, compliance and risk teams - interpret obligations and integrate privacy into governance and assurance.
  • Design, research and customer-experience teams - ensure interfaces, choices and explanations are fair, clear and usable.

Processors must also support the controller, comply with contractual obligations and implement appropriate security. Controllers should select processors that provide sufficient guarantees and should not assume that buying a compliant product transfers accountability to the supplier.

What must organisations consider under Article 25?

When deciding which measures are appropriate, Article 25 requires controllers to consider:

  • the state of the art;
  • the cost of implementation;
  • the nature, scope, context and purposes of the processing;
  • the likelihood and severity of risks to people's rights and freedoms.

This is a risk-based and proportionate duty, not permission to avoid meaningful safeguards because they carry a cost. The organisation should be able to show how it assessed relevant risks, considered available options and selected measures capable of implementing the principles effectively.

What does data protection by default require?

By default, only personal information necessary for each specific purpose should be processed. The requirement applies to:

  • Amount collected - do not request fields or data points that are not needed.
  • Extent of processing - restrict secondary use, matching, profiling and sharing unless justified.
  • Storage period - apply defined retention periods and reliable deletion or anonymisation.
  • Accessibility - limit access to authorised people, systems and recipients with a genuine need.

Default settings matter. Optional uses should not be pre-enabled merely because they are commercially convenient. Access should not be public or organisation-wide unless that is necessary for the stated purpose. Retention should not be indefinite because deletion rules have not been designed.

What are the core principles to build into design?

  • Lawfulness, fairness and transparency: Define the purpose, lawful basis and impact on people; communicate use clearly and avoid unexpected or manipulative practices.
  • Purpose limitation: Specify legitimate purposes before collection and govern any later reuse or compatibility assessment.
  • Data minimisation: Collect and expose only the data needed to achieve the defined outcome.
  • Accuracy: Provide controls for verification, correction, provenance and quality monitoring.
  • Storage limitation: Set retention and deletion requirements during design, including backups, archives and derived data.
  • Integrity and confidentiality: Apply proportionate security, access control, logging, resilience and testing.
  • Accountability: Record decisions, approvals, risk assessments, controls, testing and review evidence.

How do you apply data protection by design across the lifecycle?

1. Strategy and initiation

Identify the business outcome, affected people, categories of information, legal context, risk appetite and accountable owner before delivery begins.

2. Discovery and requirements

Map information flows, define purposes and lawful bases, challenge unnecessary data collection and translate privacy obligations into testable requirements.

3. Design and architecture

Apply minimisation, separation, pseudonymisation, role-based access, retention, secure defaults, transparency and rights-handling to the target design.

4. Procurement and contracting

Assess supplier controls, international transfers, sub-processors, deletion, audit rights, incident support, change control and exit arrangements before commitment.

5. Build and configuration

Implement approved requirements in code, workflows, permissions, integrations, data models and administrative settings.

6. Testing and approval

Test privacy requirements, misuse cases, access, deletion, transparency, consent where relevant, rights workflows and residual risk before go-live.

7. Operation and monitoring

Monitor performance, incidents, complaints, rights requests, access, supplier changes, data drift and emerging risks.

8. Change and decommissioning

Reassess privacy when purposes, datasets, models, suppliers or functionality change; securely migrate, return, delete or anonymise information at end of life.

When is a Data Protection Impact Assessment required?

A DPIA is required before processing that is likely to result in a high risk to people's rights and freedoms. It is a key mechanism for applying data protection by design, but it is not the whole discipline. Privacy design should start before the DPIA and continue after it has been approved.

A DPIA should describe the processing, assess necessity and proportionality, identify risks to people, specify mitigating measures, record consultation and document residual risk. Where high residual risk cannot be reduced, the controller may need to consult the ICO before proceeding.

What technical and organisational measures can support privacy by design?

Appropriate measures depend on the processing and risk. Common examples include:

  • data minimisation and field-level collection controls;
  • pseudonymisation, tokenisation or anonymisation where appropriate;
  • encryption in transit and at rest;
  • role-based and attribute-based access control;
  • segregation of duties and privileged-access management;
  • privacy-preserving defaults and granular user choices;
  • automated retention, deletion and archival controls;
  • logging, monitoring and audit trails;
  • secure development, threat modelling and privacy testing;
  • data-quality, provenance and correction controls;
  • supplier due diligence and contractual controls;
  • training, approval gates, standards and design checklists.

Measures should be selected because they mitigate identified risks and implement the principles effectively, not merely because they appear on a generic checklist.

How does data protection by design apply to AI and automated decision-making?

AI systems often combine large datasets, infer new information, reuse data for training and influence consequential decisions. Privacy by design should therefore address data provenance, lawful basis, purpose compatibility, minimisation, explainability, bias, security, human oversight, retention, model monitoring and individual rights from the outset.

For generative AI and third-party AI services, organisations should also assess whether prompts, outputs or uploaded documents are retained, used for provider training, transferred internationally or exposed to other users. AI governance, cybersecurity, information governance and DPIA processes should operate as one joined-up control environment.

What is the children's higher protection matters duty?

Following changes made by the Data (Use and Access) Act 2025, organisations providing information-society services likely to be accessed by children must consider children's higher protection matters when deciding which technical and organisational measures are appropriate. In practice, this strengthens the need for age-appropriate design, high-privacy defaults, clear explanations and safeguards that reflect children's vulnerability and developmental needs.

The duty should be considered alongside the ICO's Children's Code where applicable. Organisations should document how children's interests influenced design decisions rather than relying solely on age declarations or terms and conditions.

How can procurement embed data protection by design?

  • Include privacy, security, retention, deletion, rights, transfer and audit requirements in specifications.
  • Assess suppliers before selection rather than after contract signature.
  • Require evidence of technical and organisational measures, not unsupported assurances.
  • Identify processor, controller and joint-controller roles clearly.
  • Review sub-processors, hosting locations and international transfer mechanisms.
  • Ensure exit, migration, return and deletion arrangements are workable.
  • Build material privacy changes into contract change-control and assurance processes.

A supplier questionnaire alone is not privacy by design. Requirements must affect selection, architecture, configuration, contract terms, acceptance testing and ongoing oversight.

What evidence demonstrates compliance?

Useful evidence may include:

  • approved privacy requirements and acceptance criteria;
  • information-flow maps and ROPA entries;
  • DPIAs and screening decisions;
  • design decisions and architecture records;
  • records of data-minimisation challenges;
  • threat models, security testing and privacy test results;
  • access-control matrices and approval records;
  • retention schedules and deletion test evidence;
  • supplier due diligence and contract clauses;
  • go-live approval and residual-risk acceptance;
  • post-launch monitoring, audits, complaints and improvement actions.

The strongest evidence shows that privacy considerations changed a decision, design or control. A completed checklist with no link to delivery decisions provides limited assurance.

What are common data protection by design failures?

  • Starting the privacy review shortly before launch.
  • Treating a DPIA as a retrospective form-filling exercise.
  • Collecting data because it might become useful later.
  • Using broad default access or public settings.
  • Leaving retention and deletion until after implementation.
  • Relying on supplier claims without technical or contractual verification.
  • Failing to revisit assessments after material change.
  • Designing consent or privacy choices that steer people towards more intrusive options.
  • Keeping decision records that describe activity but do not evidence challenge or approval.

How should boards and senior leaders oversee privacy by design?

Boards should receive proportionate assurance that high-risk change is subject to privacy governance before commitment and launch. Reporting should focus on material decisions and outcomes, including:

  • high-risk initiatives and unresolved residual risk;
  • DPIA completion, quality and overdue actions;
  • privacy requirements passing or failing go-live gates;
  • material supplier and transfer dependencies;
  • access, retention and deletion control effectiveness;
  • complaints, rights requests, incidents and recurring design weaknesses;
  • investment, capability and accountability gaps.

The objective is not to make the board approve every DPIA. It is to ensure accountable executives understand systemic risk, resource requirements and whether governance is working as intended.

Frequently asked questions

Is data protection by design mandatory?

Yes. Article 25 UK GDPR requires controllers to implement appropriate technical and organisational measures to apply the principles effectively and safeguard rights. The measures are risk-based and proportionate, but the duty itself is not optional.

Is privacy by design the same as a DPIA?

No. A DPIA is an important assessment tool, particularly for likely high-risk processing. Privacy by design is broader and applies from initial planning through operation, change and decommissioning.

Does data protection by design apply only to technology projects?

No. It applies to systems, services, products, policies and business processes involving personal information, including manual processes, organisational restructures, data sharing and procurement.

Can a processor be responsible for privacy by design?

The controller retains responsibility for Article 25 decisions, but processors have their own obligations and must support the controller. Controllers must choose processors that provide sufficient guarantees and govern them contractually.

Does cost determine whether a safeguard is required?

Cost is one factor, alongside the state of the art, processing context and risks to people. Organisations should document proportionate choices and cannot rely on cost alone to justify ineffective protection.

How often should privacy design decisions be reviewed?

At material change points and periodically throughout the lifecycle. Reviews should be triggered by new purposes, datasets, users, suppliers, integrations, technologies, incidents, complaints, regulatory developments or risk evidence.

What is a privacy design authority?

It is a governance mechanism that reviews material design decisions and ensures privacy, security, legal, risk and business requirements are resolved before approval. The name and form may differ by organisation.

Can certification prove compliance with Article 25?

Approved certification may provide evidence that certain measures are in place, but it does not remove the controller's responsibility to assess its own processing, risks and effectiveness.

How IG-Smart can help

This guide is written by Michael Abtar, who authored NHS England's data protection and privacy by design framework.

IG-Smart helps regulated and data-intensive organisations embed privacy into programmes, products, procurement and operating models. Support can include:

  • privacy-by-design framework and standards;
  • DPIA screening, facilitation and independent assurance;
  • product, AI and digital-service privacy reviews;
  • privacy requirements and stage-gate design;
  • supplier and international-transfer assurance;
  • governance operating models and accountability matrices;
  • training for product, technology, procurement and leadership teams;
  • board reporting, maturity assessments and improvement roadmaps.

Build privacy into the decision, not around it

Data protection by design is most effective when it shapes choices before cost, architecture and delivery commitments become difficult to reverse. IG-Smart provides practical, independent support to help organisations turn Article 25 from a policy statement into a repeatable governance and delivery capability.

Sources