Privacy By Design and By Default

Privacy by design and by default is one of the GDPR’s most important accountability requirements.

Key Messages

  • Privacy should not be an afterthought.
  • Organisations should consider privacy before collecting or using personal data.
  • Privacy by design and privacy by default apply to far more than technology projects.
  • The concept is closely linked to accountability, governance, and risk management.

What is Privacy By Design and By Default?

Article 25 of the GDPR mandates organisations to adopt appropriate technical and organisational measures to abide by the privacy principles and minimise the risk of harm to the people whose data they are processing. Crucially the article requires this to be done at the time organisations decide what data they need to collect and process. This means privacy must be designed by organisations before they start collecting data.

Privacy by design must cover all of the GDPR’s privacy principles and therefore includes limiting the data to be collected and processed, limiting access to it, and limiting how long that data are kept.

Privacy by design is not a one-off exercise but is an ongoing process that must be revisited as an organisation’s systems, services and structure change. A key element of this is the identification and mitigation of privacy risks.

Technical and Organisational Measures

Many people assume privacy by design is an IT requirement. That partly covers the ‘technical’ element of privacy by design, but not the ‘organisational’ side.

Organisational measures are much more about culture and people. This means thinking about things like appropriate training, the right policies and having the right expertise in your organisation.

The Difference Between Privacy by Design and Privacy by Default?

The terms Privacy by design and privacy by default mean slightly different things.

Privacy by Design

Privacy by design means considering privacy and data protection from the earliest stages of an activity. Rather than identifying privacy risks after implementation, organisations should identify and address them during planning and design. They should be building systems – both organisational and technical – that address and mitigate those risks before data collections takes place.

This means understanding exactly what data you need to collect, who you are collecting it from, and what you will use it for.

Privacy by Default

Privacy by default means systems, services, and processes should automatically apply the most privacy-friendly settings and practices. Rather than people should taking action to protect their privacy organisations that process personal data should ensure privacy is protected throughout the information lifecycle. This includes being able to identify issues and when things go wrong in good time to prevent harm.

Comparison

Privacy by Design Privacy by Default
Building privacy into planning and design Making privacy the standard operating position
Proactive Automatic
Focuses on how something is developed Focuses on how something operates

The Benefits of Privacy By Design and By Default

What privacy by default and by design looks like depends on each organisation’s resources – smaller organisations will not have the resources of larger ones, and some organisations process greater volumes of data. However, making the investment in privacy by design has a number of advantages.

Preventing Problems Rather Than Fixing Them

Privacy risks are often easier and cheaper to address during design than after implementation. Retrofitting systems or changing processes can be time consuming and expensive, and there are inherent risks during any transition as uncertainty and complexity increases.

Supporting the Accountability Principle

One core GDPR principles is the principle of accountability. This means 0rganisations must demonstrate GDPR compliance rather than simply claim it. Embedding privacy by design and by default makes accountability much easier.

  • find out more about the principle of accountability here.

Reducing Risk

Embedding privacy by design helps reduce the risk of:

  • data breaches
  • compliance failures
  • reputational damage
  • unnecessary data collection and storage

Building Trust

Customers, employees, and service users are increasingly concerned about how their information is used. Privacy-conscious design improves confidence and trust. This is partly because you can be more open about your data collection and processing and partly because your organisation will act with greater certainty and confidence when interacting with data subjects and complying with their data rights.

 

Privacy by Design in Practice

Privacy by design may feel like a challenge, but it is not very different from designing the financial control systems of an organisation. Any organisation will set spending limits, decide who can issue and authorise invoices, and take payments. Privacy by design is about doing something similar with personal data.

One of the most important things to consider is data across the whole information lifecycle. That means planning from collection, to onboarding and processing, and then to storage and destruction or deletion.

Service Design

Questions to ask when designing services include:

  • Who are the people we are collecting the data from
  • What personal data do we need?
  • What is the lawful basis for processing?
  • Can we achieve the objective another way?
  • What risks could arise?

Project Management

When a project requires to the processing of personal data privacy should be considered during:

  • Project initiation
  • Planning
  • Implementation
  • Testing

Not only at go-live.


Procurement

Before purchasing software or services that may process or store personal data organisations should consider:

  • How is personal data stored?
  • Where is it processed?
  • Who can access it?
  • Are international transfers involved?
  • What security controls exist?
  • Is there a risk the software could become obsolete or unsupported?

Examples of the kind of software and systems you may use in your organisation include:

  • applications
  • databases
  • websites
  • AI systems
  • cloud services

Privacy requirements should form part of system specifications rather than being added later.


Process Design

Personal data will flow between teams, systems and locations as it follows your organisation’s processes. Examples of this include:

  • recruitment processes
  • complaint handling
  • employee management
  • customer onboarding

Privacy should be embedded into operational workflows, where the interaction between teams and departments is considered. For example, HR, line managers, IT and payroll will work together through the recruitment and deployment of new colleagues.


Privacy by Default in Practice

Privacy by default comes after you have identified your data needs and designed your systems and processes.  In practice privacy by default takes a number of forms, and follows naturally on from privacy by design if this is done well.

Data Minimisation

This means collecting only the information genuinely required. For example, a newsletter signup should usually require an email address, not a full postal address and date of birth.


Access Controls

There should be role based restrictions on access. Access should be granted and removed people join your organisation, change roles, and leave. If customers or suppliers are able to log in to your systems they should only see information about themselves and not others.


Retention Controls

Data should not be retained indefinitely in identifiable form. You should know how long you intend to keep data for at the time of collection, and be able to explain this in your privacy information or when complying with people’s data rights.


Sharing Restrictions

Personal data should not be widely shared unless there is a justified need. This means understanding who your partners are  if you receive data from or send it to another organisation, and maintaining strict controls over what data are shared and for what purposes.


User Settings

Organisations should consider and opt-in model for certain types of data collection when people are using their products or services. For example:

  • marketing options switched off by default
  • location tracking disabled unless required
  • optional profiling disabled until enabled

Risk Assessment and Privacy By Design and By Default

Privacy by design and by default requires appropriate technical and organisational measures being put in place by organisations processing personal data. The extent to which those measures go, and the costs of implementation, depend in part on how much data an organisation collects, about how many people, and how sensitive the data are.

For example, collecting medical information, data about children, or data about a large number of people presents greater risks than limited, non-sensitive information about a relatively small number of adults.

The key risks to consider are whether a loss of data, whether through a  cyber attack, a system failure, or human error etc. could cause harm or distress to the individuals affected. You should also consider what steps you and they would need to take to prevent harm.

General risk evaluation is suitable for low-sensitivity data processing but for higher sensitivity data processing the GDPR introduces a tool call the Data Privacy Impact Assessment (DPIA). This is a more systematic data protection risk assessment that should be used for proposed processing of sensitive data, data about vulnerable people, or very large scale data processing.

  • Find out more about DPIAs and get a free DPIA template here.

Examples of Good Privacy by Design

Privacy by Design means embedding data protection into the development of business processes and systems from the very beginning, rather than adding it as an afterthought. Here are practical examples of privacy by design across three key organisational areas:

Recruitment (Human Resources)

Recruitment processes often involve handling highly sensitive personal data. Privacy by design here focuses on data minimisation and access control.

  • Automated Data Deletion: Configure your applicant tracking system to automatically delete or anonymise unsuccessful candidate profiles after a set period (e.g., 6 months), unless you have obtained explicit consent to retain them for future roles, or you have decided it is necessary to retain the personal data by exception for legal or other reasons.

  • Role-Based Access: Restrict access to interview notes and CVs to only those directly involved in the hiring decision. Do not store sensitive documents (like Right to Work checks or health disclosures) in a general folder accessible to the wider team. Once interviews are over there is no need for line managers or other non-HR people to have access to data that they no longer need.

  • Privacy Notices at Source: Integrate a short, clear privacy notice directly into the online application form so candidates understand how their data will be processed before they click submit. Make sure this has got links to wider organisational privacy notices and the contact details of your Data Protection Officer.

Customer Service

In customer service, privacy by design is about protecting the confidentiality and integrity of customer data through the information lifecycle .

  • Data Masking/Redaction: Implement tools in your CRM or support ticketing system that automatically mask sensitive data (such as credit card numbers or government IDs) so that support agents see only the information necessary to resolve the query.

  • Minimise general access: Agents should only be able to view the data relevant to the specific customer they are currently assisting, rather than having full access to a customer’s entire account history or private behavioral data.

  • Verification protocols: Design verification processes that do not rely on sensitive data. Instead of asking for a full date of birth or social security number, use non-sensitive identifiers or secure, multi-factor authentication (MFA) methods.

Website Design

Websites are often one of the main ways data are collected about people. This example centers on transparency and user agency.

  • Granular Consent for Cookies: Move away from “one-click” consent. If your cookies collect more than anonymous analytics data implement a preference center where users can opt-in to specific types of cookies (e.g., analytics vs. marketing) before any non-essential scripts are fired.

  • Privacy-Friendly Default Settings: Set all optional features—such as newsletter subscriptions, data sharing with partners, or personalisation profiles—to “off” by default. Users must take an affirmative action to opt-in if you are relying on consent as your lawful basis.

  • Layered Privacy Notices: Use “just-in-time” notices. For example, if you ask for a customer’s email and send ‘abandoned cart’ emails make that clear at the time the email address is taken. Also, instead of one massive legal document, provide short, plain-language explanations and give access to more detailed documentation, with the contact information of your Data Protection Officer, for people who want to know more or who have particular questions.

Common Mistakes and Misconceptions

When it comes to privacy by default and by design there are a number of assumptions and misconceptions organisations should avoid.

Privacy by Design Only Applies to IT Projects

Privacy by design applies to all personal data processing and all media – including paper records. It should not be limited to the design and implementation of IT systems but instead include human factors and consider things like the payout of physical locations such as offices.

 

Privacy by Design Means Avoiding Data Collection

The GDPR does not seek to prevent data collection or processing, but to make it proportionate and safe. Understanding what data you need and why is core to privacy by design, not avoiding data collection.

 

Privacy by Design Is the DPO’s Responsibility

Your Data Protection Officer has a key role in designing privacy systems and maintaining them but this responsibility is shared with operational subject matter experts and the senior leaders of an organisation remain accountable to effective data protection.

Responsibility sits across the organisation.

Privacy by Default Means Everything Must Be Locked Down

Controls should be proportionate and risk-based, which access being more limited the more sensitive or high risk the data collected or data processing is. There will be circumstances where access is necessary for things like IT operations (help desk etc.) and where this is required contracts, policies and operating procedures should make clear how people should behave.

Organisations should avoid having a “single point of failure” where only one person has access, knows passwords or can perform a particular function.

Privacy be design process

Privacy by Design, Risk Management and Governance

Privacy by design is closely linked to wider governance, risk management, and accountability frameworks. Rather than treating data protection as a standalone compliance activity, organisations should incorporate privacy considerations into their decision-making, project management, procurement, and operational processes from the outset.

By considering privacy early, organisations can identify and address risks before they become costly problems. This helps reduce the likelihood of data breaches, compliance failures, and reputational damage, while ensuring that personal data is collected, used, and retained appropriately. Addressing privacy requirements during the design stage is often significantly less expensive and disruptive than attempting to retrofit controls after a system or process has been implemented.

Privacy by design also supports good information governance by helping organisations understand what personal data they hold, why they process it, and what safeguards are required. This improves transparency, supports accountability, and enables more informed decision-making throughout the organisation.

Effective privacy governance should be supported by ongoing assurance activities such as compliance monitoring, internal audits, management reviews, and risk assessments. These mechanisms help organisations verify that privacy controls are operating as intended and identify opportunities for continuous improvement. As a result, privacy by design not only strengthens GDPR compliance but also contributes to stronger governance, better risk management, and greater organisational resilience.

Practical Privacy by Design Checklist

Before introducing any new process, system, or service ask:

  • Do we need personal data?
  • What personal data is required?
  • Is the information sensitive or about vulnerable people?
  • Which lawful bases apply?
  • What risks exist?
  • Where will the information be held?
  • How will access be controlled?
  • How long will data be retained?
  • Will information be shared?
  • Can we demonstrate our decisions?

 

Conclusion

Privacy by design and by default is neither a simple technical exercise nor a one off activity. Privacy should be a design feature of any new product or process, and embedded in organisational systems and processes. Organisations that embed privacy early reduce risk, improve compliance, and strengthen trust.