Category: Privacy Governance & Design

Privacy by Design Governance

Also known as: PbD Governance, Data Protection by Design Governance, Data Protection by Design and by Default Governance

Simply put

Privacy by Design Governance refers to the organisational structures, processes, and accountability measures used to make sure privacy and data protection are built into systems, services, products, and processes from the earliest design stage rather than added later. The underlying idea, sometimes described as data protection through technology and organisational design, is that protecting personal data should be a default consideration throughout a project's life cycle. In practice, it means assigning responsibility and embedding controls so that privacy is managed deliberately rather than by chance.

Formal definition

Privacy by Design Governance is the governance dimension of the data protection by design and by default principle, which under the UK GDPR (as reflected in ICO guidance) requires organisations to consider privacy and data protection issues of any system, service, product, or process at the design stage and throughout its life cycle. It typically encompasses the allocation of accountability, integration of technical and organisational measures, and the operationalisation of design-stage controls so that data protection is embedded by default. Note that 'Privacy by Design' as a concept predates and is broader than the specific statutory obligation; practitioners should distinguish the general design philosophy from the enforceable legal requirement and verify the precise obligation and any applicable article against the current official UK GDPR or EU GDPR text, as scope and national implementing detail can vary. This entry addresses governance framing; it does not by itself specify the full technical measures, which are context- and risk-dependent and should be determined through assessment.

Why it matters

Privacy by Design Governance matters because embedding data protection at the design stage is generally far more effective, and less costly, than attempting to retrofit controls once a system, service, product, or process is already built. When privacy considerations are deferred, organisations typically face harder remediation choices, greater risk of processing personal data without adequate safeguards, and weaker demonstrable accountability. Establishing governance structures, rather than relying on individual good intentions, is what turns the general design philosophy into a repeatable, auditable practice.

The governance dimension is significant because data protection by design and by default is treated as a legal requirement under the UK GDPR, as reflected in ICO guidance, and not merely a best-practice aspiration. According to ICO guidance, organisations are expected to consider privacy and data protection issues of any system, service, product, or process at the design stage and throughout its life cycle. Without clear allocation of responsibility and defined processes, an organisation may struggle to show that these considerations were actually made, which is central to the accountability principle. Practitioners should note that the general 'Privacy by Design' concept predates and is broader than the specific statutory obligation, and the two should not be conflated.

Because the precise scope of the obligation, the applicable article, and national implementing detail can vary, organisations should verify the current position against the official UK GDPR or EU GDPR text rather than relying on a fixed snapshot. The specific technical and organisational measures required are context- and risk-dependent and should be determined through assessment; governance provides the framework within which those decisions are made, documented, and reviewed over time.

Who it's relevant to

Data Protection Officers and privacy leads

DPOs and privacy leads generally rely on Privacy by Design Governance to embed data protection considerations into projects from the outset and to demonstrate accountability. It helps them establish who is responsible for design-stage decisions and how those decisions are documented across a project's life cycle. They should determine the specific measures through risk-based assessment rather than applying a fixed checklist.

Engineers, designers, and product teams

Those building systems, services, products, and processes are typically the people who make the intentional design choices through which privacy and data protection are delivered. Clear governance helps them understand what controls to integrate by default and at what stage, so that privacy is managed deliberately rather than by chance. The precise technical measures are context- and risk-dependent.

Compliance and governance functions

Compliance leads use Privacy by Design Governance as part of the broader accountability and governance framework, helping to show that privacy and data protection issues were considered at the design stage and throughout the life cycle. They should verify the specific obligation and any applicable article against the current official UK GDPR or EU GDPR text, as scope and national implementing detail can vary.

Project and procurement owners

Those responsible for new initiatives or for acquiring third-party systems and services benefit from governance that requires privacy considerations to be raised early, when design and configuration choices can still be influenced at lower cost. This supports embedding protection by default rather than attempting to retrofit it later.

Inside PbD Governance

Data Protection by Design

The obligation, expressed in GDPR Article 25(1), to implement appropriate technical and organisational measures at the time of determining the means of processing and at the time of the processing itself, designed to give effect to data protection principles such as data minimisation. This is a legal requirement addressed to the controller rather than a purely optional design philosophy.

Data Protection by Default

The related obligation under GDPR Article 25(2) to ensure that, by default, only personal data necessary for each specific purpose is processed. This applies to the amount of data collected, the extent of processing, the period of storage, and accessibility. It generally means the most privacy-protective settings should apply without requiring individual action.

Governance structures and accountability

The organisational arrangements that embed design-stage privacy considerations into decision-making, aligned with the accountability principle under GDPR Article 5(2). This typically includes defined roles, escalation paths, and documentation demonstrating that privacy considerations were integrated, though the Regulation does not prescribe a single mandatory structure.

Technical and organisational measures (TOMs)

The combination of technical controls (such as pseudonymisation, which is cited as an example in Article 25) and organisational controls (such as policies and training) selected with reference to the state of the art, cost of implementation, and the nature, scope, context and purposes of processing, as well as the risks to individuals.

Risk-based calibration

The requirement that measures be appropriate to the assessed risk, meaning the intensity of measures is proportionate to the likelihood and severity of risks to the rights and freedoms of natural persons. This links privacy by design governance to broader risk assessment processes, and in higher-risk cases may connect to a Data Protection Impact Assessment under Article 35.

Lifecycle integration

The embedding of privacy considerations across the processing lifecycle, from initial planning and procurement through development, deployment, and eventual decommissioning, rather than treating privacy as a one-off review at launch.

Common questions

Answers to the questions practitioners most commonly ask about PbD Governance.

Is 'Privacy by Design' just a best-practice concept, or is it a legal obligation?

It is more than an optional best practice. The concept is generally reflected in the GDPR's requirement for data protection by design and by default, which places obligations on controllers to implement appropriate technical and organisational measures. That said, the way the obligation is met is context and risk dependent rather than a fixed checklist. The precise article reference and its scope should be verified against the current official text, and readers should note that national implementing law and regulator guidance may add detail.

Does Privacy by Design mean you must always obtain consent before processing?

No. Privacy by Design does not make consent a universal requirement. Consent is only one of several distinct legal bases available to a controller, alongside options such as contract, legal obligation, vital interests, public task, and legitimate interests. Embedding privacy into design means selecting and documenting the appropriate lawful basis for each processing activity, not defaulting to consent. Where special category data is involved, an additional condition beyond the ordinary legal basis is generally required.

Who within an organisation is typically responsible for implementing Privacy by Design governance?

Responsibility generally sits with the controller as the party that determines the purposes and means of processing, since the design obligation is directed at that role. In practice, delivery is usually shared across engineering, product, legal, and compliance functions, often coordinated by a data protection officer or privacy lead where one is appointed. Processors may be engaged to implement measures, but the governance accountability typically remains with the controller. The exact allocation should be set out in internal governance documentation.

How does Privacy by Design governance relate to a Data Protection Impact Assessment?

A DPIA is one of the tools that can operationalise Privacy by Design, but the two are distinct. A DPIA is a structured assessment generally required where processing is likely to result in a high risk to individuals, whereas Privacy by Design is the broader ongoing discipline of embedding data protection into systems and processes from the outset. In most cases the DPIA process and design governance are integrated, so that assessment findings feed back into system design decisions. Note that a DPIA under the relevant GDPR provision should not be confused with a Data Processing Agreement between controller and processor, which serves a different purpose.

At what point in a project should Privacy by Design be applied?

It should typically be applied from the earliest stages of planning and design, and maintained throughout the processing lifecycle, rather than retrofitted after a system is built. Early application generally allows measures such as data minimisation, purpose limitation, and appropriate default settings to be built in rather than bolted on. The obligation is generally understood to be continuous, so governance should include review points as processing activities and risks change over time.

How can an organisation demonstrate that its Privacy by Design measures are adequate?

Because the standard is context and risk dependent, adequacy is generally demonstrated through documented decision-making rather than a claim of full compliance, which cannot be guaranteed in the abstract. This typically includes records of the measures considered and adopted, the reasoning for design choices, assessments such as DPIAs where applicable, and evidence of default settings that limit processing to what is necessary. Organisations should align this documentation with current regulator guidance, and be aware that expectations can diverge between supervisory authorities and evolve over time.

Common misconceptions

Privacy by design is a voluntary best practice that organisations may choose to adopt.

In the EU and UK GDPR context, data protection by design and by default is a legal obligation on the controller under Article 25, not merely aspirational guidance. That said, the Regulation leaves the specific measures to be determined by the controller based on the factors listed in the Article, so implementation is context and risk dependent.

Implementing privacy by design means the controller must always obtain consent and collect the minimum data through consent-based settings.

Data protection by default concerns limiting processing to what is necessary for each purpose; it does not make consent the required legal basis. Consent is only one of the Article 6 bases, and the appropriate basis depends on the processing. Privacy by design governance operates alongside, not in place of, correctly identifying a lawful basis, and special category data under Article 9 would need an additional condition.

Once privacy-protective measures are built in at launch, the design obligation is satisfied.

Article 25 refers to measures both at the time of determining the means of processing and at the time of the processing itself, which generally implies an ongoing obligation rather than a single point-in-time exercise. Measures should typically be reviewed as processing, technology, and risks change.

Best practices

Integrate privacy assessment into project planning and procurement decisions from the outset, so that measures are considered when determining the means of processing rather than added after launch.

Document the technical and organisational measures selected and the reasoning that connects them to the risk, state of the art, and cost factors referenced in Article 25, to support the accountability principle.

Configure default settings so that only personal data necessary for each specific purpose is processed, and review defaults covering the amount of data, extent of processing, storage period, and accessibility.

Where processing is likely to result in high risk, coordinate privacy by design work with a Data Protection Impact Assessment under Article 35 rather than treating the two as separate exercises.

Establish clear roles, escalation paths, and periodic review cycles so that measures are revisited as processing activities, technologies, and risks evolve over time.

Confirm the appropriate Article 6 legal basis (and any Article 9 condition for special category data) separately from design measures, and verify positions against the current official text and relevant regulator guidance, noting that member state derogations may vary the outcome.