Privacy by Design in France: GDPR Best Practices

Privacy problems are usually harder, slower, and more expensive to correct once a system, product, or business process is already operating. Design decisions made early can determine how much personal data is collected, who can access it, how long it is retained and whether individuals can exercise their rights effectively.

Privacy by design in France requires organizations to integrate data protection into systems, products, and business processes from the earliest design stage rather than adding privacy controls shortly before launch.

Article 25 of the GDPR establishes the legal obligation of data protection by design and by default, making privacy an ongoing design and governance requirement rather than a final compliance check.

The principle can apply to customer platforms, recruitment systems, mobile applications, analytics, AI systems, employee tools, connected products, and internal workflows.

This guide explains Article 25, privacy by default, core design principles, DPIAs, development processes, AI and mobile applications, supplier controls, DPO involvement, documentation, and practical implementation.

What Is Privacy by Design Under GDPR?

Privacy by design means systematically integrating data protection principles and safeguards into the architecture and operation of personal data processing from the outset.

Under Article 25 of the GDPR, controllers must take account of factors including the state of the art, implementation costs, the nature, scope, context, and purposes of processing, and the risks to individuals’ rights and freedoms when deciding which technical and organizational measures to implement.

The objective is to make privacy part of how processing is designed and operated, not an issue addressed only after a system has been built.

It Applies Before and During Processing

Organizations should consider privacy when requirements are defined, architecture is designed, providers are selected, controls are configured, and systems are later modified.

This means privacy review should continue when new features, integrations, data uses or suppliers materially change the processing.

Privacy by Design Is Not a Single Security Feature

Privacy by design is broader than encryption, access control or any other individual technical safeguard.

It combines technical architecture, organisational controls, governance and evidence.

For example, a compliant design may require data minimisation in forms, role-based access, automated retention rules, documented approval decisions and practical mechanisms for exercising GDPR rights.

The strongest implementation therefore treats privacy as a design constraint that influences both technical choices and business decisions throughout the processing lifecycle.

Privacy by Design vs Privacy by Default

Data protection by design and data protection by default are closely related, but they address different parts of Article 25 GDPR compliance.

Data Protection by Design

Data protection by design concerns how privacy principles are built into the processing itself.

Practical measures can include pseudonymisation, limiting unnecessary data flows, granular access controls, purpose-based permissions and automated retention rules.

The focus is on shaping the architecture and operation of the system so that privacy requirements are technically and organisationally enforceable.

Data Protection by Default

Data protection by default concerns what happens automatically when the individual or administrator takes no additional action.

By default, processing should be limited to the personal data necessary for each specific purpose. This includes the amount collected, the extent of processing, how long data is retained, and who can access it.

The EDPB Guidelines 4/2019 on Data Protection by Design and by Default provide the principal EU-level interpretative guidance on how Article 25 should be applied.

Practical Example

Consider a customer portal that offers granular privacy settings.

Privacy by design would mean building the system so those settings can genuinely restrict data use and access.

Privacy by default would mean that optional collection is initially disabled, profiles are not automatically public, and unnecessary retention is not enabled unless a justified choice is made.

The distinction is practical: design determines what the system is capable of doing, while default settings determine what happens automatically.

Core Privacy by Design Controls

Effective privacy by design depends on translating GDPR principles into controls that shape how personal data is collected, used, stored, shared and deleted.

Data Minimisation

Minimisation should operate at multiple levels.

At the field level, forms should avoid collecting unnecessary information. At the dataset level, teams should question whether entire categories of data are needed. At the workflow level, personal data should not move through systems, teams or integrations unless that movement supports a defined purpose.

Pseudonymisation

Pseudonymisation can reduce exposure by separating directly identifying information from the data used for processing.

However, pseudonymised data does not automatically become anonymous. If individuals can still be re-identified using additional information, GDPR requirements continue to apply.

Retention by Design

Retention should be built into system behaviour.

Instead of relying on annual manual clean-ups, systems should support retention triggers, restricted archival states and deletion once the justified retention period ends.

Rights by Design

Privacy controls should also make GDPR rights operational.

If the organisation cannot reliably locate, export, correct, restrict or delete personal data when required, the architecture itself may create compliance difficulty.

The strongest designs therefore treat privacy requirements as functional specifications, not simply policy statements.

What Does the CNIL Expect During Development?

The CNIL recommends placing privacy at the centre of development methodology rather than treating GDPR compliance as a final legal check. Its GDPR Developer’s Guide explicitly encourages teams to adopt a Privacy by Design approach throughout the development process.

Convert Legal Principles Into Requirements

Project specifications should avoid vague instructions such as “must comply with GDPR.”

Instead, teams should define concrete privacy requirements, including which personal data may be collected, who may access it, how long it remains available, which uses are prohibited and how individuals will exercise their rights.

This turns legal principles into design constraints that developers and product teams can actually implement and test.

Add Privacy Checkpoints

Privacy review should be integrated into the project lifecycle.

Relevant checkpoints can include requirements definition, architecture, development, testing, release and change management. This helps identify privacy issues before they become embedded in technical decisions that are costly to reverse.

Use Risk to Determine Depth

Not every project requires the same level of scrutiny.

A low-impact internal tool processing limited personal data does not need the same review process as a platform involving sensitive information, large-scale profiling or systematic monitoring.

The depth of assessment should therefore reflect the nature of the data, the processing context and the potential impact on individuals.

This risk-based approach makes privacy review more proportionate while ensuring that higher-risk systems receive stronger governance and technical scrutiny.

Privacy by Design Across the Data Lifecycle

Privacy controls should follow personal data throughout its entire lifecycle. Limiting attention to the collection stage creates gaps later when information is reused, shared, retained or deleted.

Collection

Every category of personal data should have a defined purpose before collection begins.

Forms, interfaces and integrations should avoid gathering information that is not necessary for that purpose.

Use

Once collected, personal data should not automatically become available for unrelated secondary uses.

Access should be limited to people and systems that genuinely need the information, and new uses should be reviewed before they are introduced.

Storage

Stored data should be protected through appropriate security, separation, retention and backup controls.

Higher-risk datasets may require stronger access restrictions or technical separation from lower-risk information.

Sharing

Organisations should control who receives personal data and why.

This includes processors, business partners, APIs, connected systems and international data flows. New integrations should not create uncontrolled disclosure simply because the technical connection is easy to implement.

Retention

Retention rules should distinguish between active use, restricted archival storage and deletion.

Where possible, these rules should be automated rather than dependent on manual intervention.

End of Service

Privacy planning should also cover what happens when a relationship ends.

Account closure, supplier termination, data export and final deletion should be addressed before the system or service is launched.

The practical principle is simple: privacy controls should move with the data. A system may collect information appropriately and still create GDPR risk later if use, sharing, retention or deletion are poorly designed.

When Is a DPIA Required?

A Data Protection Impact Assessment (DPIA), referred to by the CNIL as an AIPD, is required where a planned processing activity is likely to result in a high risk to individuals’ rights and freedoms.

The CNIL describes the AIPD as both a risk-management tool and an accountability mechanism. Its purpose is to help organisations identify significant privacy risks early, assess whether safeguards are sufficient and document the reasoning behind important decisions.

Privacy by Design and DPIA Are Not the Same Requirement

Privacy by design applies broadly. A DPIA is triggered by high-risk processing.

This distinction matters because organisations should apply privacy-conscious design to ordinary processing even where a formal DPIA is not required.

Processing That Deserves Closer Assessment

Examples that may warrant closer assessment include systematic monitoring, certain biometric technologies, large-scale processing of sensitive data and innovative systems capable of significantly affecting individuals.

The decision should be based on the characteristics and risks of the actual processing rather than on the technology label alone.

Complete the DPIA Before Launch

A DPIA should be completed early enough to influence the project.

If the assessment is conducted only after architecture, data flows, vendor choices and access models are effectively fixed, it loses much of its preventive value.

The findings should be able to change the design, reduce data collection, restrict permissions or introduce additional safeguards before processing begins.

Review After Material Change

A DPIA should not be treated as a permanent one-time record.

Reassessment may be needed when the purpose, scale, personal data, technology, recipients or overall risk profile changes materially.

How a DPIA Should Influence System Design

A DPIA should lead to concrete design changes when significant privacy risks are identified.

For example, an assessment may reveal excessive data collection, unnecessarily broad permissions, overly long retention periods or insufficient separation between datasets. In each case, the project team should respond by changing the architecture, workflow or configuration rather than simply documenting the concern.

Move From Risk to Control

Each material privacy risk should be linked to a specific mitigation measure.

A practical record should capture the identified risk, the proposed control, the responsible owner, the implementation date, and the residual risk that remains after mitigation.

This creates accountability and makes it easier to verify that agreed safeguards were actually implemented.

Do Not Treat the DPIA as the Final Deliverable

The DPIA report is evidence of the assessment process, but it is not the ultimate objective.

The real goal is to reduce privacy risk before processing begins.

If the assessment identifies weak access controls, excessive retention or unnecessary data collection, those issues should be resolved through technical or organisational changes before launch wherever possible.

Escalate Unresolved High Risk

Some risks may remain high even after reasonable safeguards have been considered.

Where residual high risk cannot be sufficiently reduced, the organisation should assess whether prior consultation with the supervisory authority is required under the GDPR before proceeding.

This is why DPIA findings should feed directly into project governance, technical design and approval decisions rather than remain isolated in compliance documentation.

Privacy by Design in Software and Product Development

Privacy by design is most effective when it is embedded into the development lifecycle rather than added as a final compliance review.

Requirements Stage

Define the processing purpose, personal data categories, lawful basis, retention requirements, individual rights and relevant risk constraints before development begins.

This gives product and engineering teams clear boundaries for what the system should and should not do.

Architecture Stage

Map how personal data will move through the system.

Document data flows, permissions, integrations, encryption, storage locations and connections with external services. Architecture decisions should make unnecessary access and unsupported secondary use difficult by design.

Development Stage

Avoid uncontrolled use of production personal data in development and testing environments.

Where realistic alternatives exist, teams should use synthetic, anonymised or appropriately protected data and maintain clear controls over any production data that must be used.

Testing Stage

Test privacy requirements alongside functional and security requirements.

For example, confirm whether the system can actually delete a user’s data without leaving unnecessary copies in connected databases, logs or downstream systems. Also test access restrictions, retention triggers and rights-handling workflows.

Release Stage

Before launch, confirm that privacy information, permissions, retention settings, access rules and mechanisms for exercising GDPR rights operate as intended.

Outstanding privacy risks should be documented and escalated before approval.

Change Management

Privacy review should continue after release.

New features should trigger reassessment where they materially change the purpose, data use, recipients, automated decision-making or exposure of individuals.

This lifecycle approach helps prevent privacy controls from becoming outdated as products evolve.

Privacy by Design for AI Systems

AI systems can create distinctive GDPR design challenges because personal data may appear in training datasets, evaluation data, prompts, outputs or monitoring processes. The CNIL’s AI and GDPR recommendations emphasise that data protection principles should be considered from the design stage and reflected in how AI datasets and systems are built.

Start With Data Necessity

Before collecting or reusing personal data for AI training or evaluation, teams should ask whether personal data is genuinely necessary to achieve the intended purpose.

If the objective can be met with anonymised, synthetic or less identifying data, that option may reduce privacy exposure.

Review Training and Evaluation Datasets

Assess where the data came from, whether it is relevant, how much is required, how accuracy is managed, how long it is retained and who can access it.

Datasets should not expand simply because more data is technically available.

Consider Model Outputs

Privacy analysis should extend beyond input data.

Teams should evaluate whether model outputs could reveal, reproduce or infer information about identifiable individuals, particularly where sensitive or confidential information may be involved.

Revisit the DPIA Threshold

AI systems involving sensitive data, systematic monitoring, extensive profiling or consequential decisions may require closer assessment of whether high-risk processing is involved.

The key GDPR question is not whether a system uses AI, but whether its data use, scale, purpose and potential impact create material risks that need stronger safeguards or a formal DPIA.

Privacy by Design for Mobile Apps and Digital Services

Mobile apps provide a practical example of how privacy by design should influence real product decisions. Applications can collect detailed information through device permissions, embedded software components and background processing, often beyond what users immediately see.

The CNIL published its final Mobile Application Privacy Recommendations in May 2025 and indicated that these recommendations would inform its enforcement activity.

Control Permissions

Apps should not request access to location, microphone, contacts, photos or other device data unless that access is genuinely necessary for a defined purpose.

Permissions should be assessed individually rather than requested broadly during installation simply because the operating system makes them available.

Review SDKs

Third-party software development kits can introduce additional processing through analytics, advertising, crash reporting or telemetry.

Product teams should understand what data each SDK collects, where it sends that information and whether the processing remains consistent with the application’s stated purposes.

Use Privacy-Friendly Defaults

Optional tracking, public profile visibility and unnecessary data collection should not be enabled automatically.

Default configurations should limit processing unless the user makes an informed choice to activate additional functionality.

For digital services, privacy by design therefore requires attention not only to the main application code, but also to permissions, embedded third-party components and the settings that determine what happens before a user changes anything.

Privacy by Design in Procurement

Privacy problems can become difficult to fix once a supplier has been selected and a system is already being implemented. Procurement should therefore assess privacy capabilities before contract signature, not after technical limitations have been discovered.

Evaluate Functionality Before Signing

Determine whether the proposed system can support the organisation’s privacy requirements in practice.

Relevant capabilities may include retention controls, deletion, data export, role-based access, logging and configurable privacy settings.

If the system cannot enforce these requirements, the limitation should be identified before procurement decisions become difficult to reverse.

Review the Data Architecture

Understand how the provider processes personal data.

Review hosting arrangements, subprocessors, integrations, remote support access and international data flows. The analysis should focus on actual processing rather than relying only on the vendor’s headline hosting location or marketing claims.

Put Privacy Into Requirements

Procurement documentation should specify required privacy capabilities from the outset.

This helps prevent situations where a vendor is selected first and the organisation later discovers that essential controls such as deletion, restricted access or audit logging are unavailable or costly to add.

Reassess Significant Changes

Supplier review should continue after onboarding.

New analytics features, AI capabilities, subprocessors, integrations or processing purposes may materially change the privacy risk profile.

Significant changes should therefore trigger renewed privacy assessment rather than being treated as routine product updates.

The DPO’s Role in Privacy by Design

The Data Protection Officer should support privacy by design through advice, oversight and challenge, but should not become the project’s sole compliance owner.

Privacy works best when responsibility is shared across business, technical, security and privacy functions from the beginning of a project.

Involve the DPO Early

The DPO can advise on GDPR requirements, privacy risk, whether a DPIA is necessary and which safeguards may be appropriate.

Early involvement is more valuable than asking the DPO for approval after architecture, suppliers and data flows have already been fixed.

Keep Business Ownership Clear

The project owner should remain responsible for explaining why the processing exists, how it operates and which outcomes the organisation needs.

This business context is essential because privacy decisions depend on the actual purpose, users, data and operational constraints of the project.

Technical Ownership Also Matters

Developers, architects and security specialists need to translate privacy requirements into architecture, code and configuration.

They may be responsible for implementing access restrictions, retention logic, encryption, logging, deletion workflows or privacy-friendly defaults.

The strongest governance model is therefore cross-functional. The DPO advises and monitors, the business owns the processing purpose, and technical teams implement the controls.

Privacy by design should not become a final DPO approval gate. It should be a shared project discipline supported by clear accountability.

Documenting Privacy by Design

GDPR accountability requires organisations to demonstrate how privacy principles influenced real design and operational decisions. For Article 25, this means keeping evidence that shows privacy was considered during planning, development, approval and subsequent change.

Useful evidence can include architecture reviews, data-flow diagrams, documented requirements, DPIAs, retention rules, privacy test results, risk decisions and project approvals.

Record Important Decisions, Not Every Conversation

Documentation should focus on material decisions rather than creating an excessive administrative record.

For significant issues, record what privacy risk was identified, which alternatives were considered, which control was selected, who approved the decision and what residual risk remained after mitigation.

This creates a practical audit trail showing how privacy considerations affected the final design.

Document Exceptions

Where the organisation rejects a more privacy-protective option, the reason should be recorded.

For example, a project may determine that a particular data field, retention period or integration remains necessary despite a privacy concern. The rationale, safeguards and residual risk should be documented rather than left implicit.

Keep Documentation Current

Privacy by design evidence should evolve as the processing changes.

Changes in purpose, functionality, suppliers, data flows or risk may make earlier assumptions outdated. Project records should therefore be reviewed when material changes occur.

The objective is not to create paperwork for its own sake. Good documentation should make it possible to reconstruct why important privacy decisions were made and demonstrate that those decisions were proportionate, informed and actively governed.

Privacy by Design Implementation Flow

A practical privacy by design process should move from purpose and data mapping through risk assessment, control design, testing and ongoing review.

   Define purpose

               ↓

  Map Personal data

               ↓

  Minimise collection

               ↓

Assess privacy risk

              ↓

 Is high risk likely?

    ↙               ↘

  Yes                No

   ↓                    ↓

Conduct DPIA Standard review

         ↘              ↙

    Design safeguards

                ↓

    Test privacy controls

              ↓

 Approve and document

              ↓

         Launch

              ↓

Monitor changes and risk

The sequence starts by defining why the processing is needed and identifying the personal data involved. Teams should then minimise collection before assessing the remaining privacy risks.

Where high risk is likely, the project should move into a formal DPIA process. Lower-risk projects may follow a proportionate standard privacy review. Both routes should ultimately lead to appropriate safeguards, testing, documented approval and ongoing monitoring.

The Purpose of the Flow

The main value of this process is timing.

It forces privacy questions to be addressed before technical architecture, supplier choices or commercial commitments become difficult or expensive to reverse.

It also creates clear decision points where unnecessary data collection, weak defaults or excessive access can be challenged before launch.

Scale the Process

Not every project requires the same level of documentation or review.

The depth of assessment should reflect factors such as data sensitivity, processing scale, technology, affected individuals and potential impact on their rights and freedoms.

A proportionate approach keeps lower-risk projects efficient while ensuring that higher-risk processing receives stronger scrutiny, evidence and governance.

Privacy by Design Compliance Checklist

A useful privacy by design checklist should test whether privacy requirements are genuinely embedded into the project, not simply documented in policy.

Purpose: Can the organisation explain why every material category of personal data is necessary for the stated processing purpose?

Defaults: Does the system begin with settings that limit unnecessary collection, disclosure, accessibility, and retention without requiring the individual to opt out?

Architecture: Can access restrictions, deletion rules, retention controls, and purpose limitations be technically enforced?

Risk: Has the project team assessed the privacy impact and determined whether a DPIA is required before launch or material change?

Suppliers: Can third-party systems support required deletion, access controls, export functions and privacy configuration?

Rights: Can the organisation reliably locate, retrieve, correct, restrict or delete personal data when an individual exercises a GDPR right?

Evidence: Can the controller demonstrate how privacy considerations influenced architecture, supplier selection, configuration and approval decisions?

Any significant gap should lead to a documented action, owner and follow-up date so that privacy by design remains an operational control rather than a one-time review.

Common Privacy by Design Mistakes

Several recurring mistakes weaken privacy by design because they treat privacy as documentation rather than as part of system and process design.

Reviewing Privacy Only Before Launch

Better approach: Define privacy requirements before architecture, integrations and supplier choices are fixed. Late review often limits the available options.

Treating Privacy by Design and DPIA as the Same Thing

Better approach: Apply privacy by design broadly across processing activities and use a DPIA where high-risk processing triggers Article 35 requirements.

Collecting First and Minimising Later

Better approach: Define the minimum personal data needed before building forms, databases and workflows. Removing unnecessary data later is usually harder.

Assuming Vendor Defaults Are Compliant

Better approach: Review, test and configure vendor settings rather than relying on default privacy or retention configurations.

Creating Privacy Policies Without Technical Enforcement

Better approach: Convert policy requirements into system behaviour through access rules, retention logic, permissions and deletion controls.

Making the DPO Responsible for Every Project Decision

Better approach: Keep clear business and technical ownership. The DPO should advise and monitor, while project owners and technical teams remain accountable for implementation.

Avoiding these mistakes makes privacy by design more practical, measurable and easier to demonstrate during audits or regulatory review.

Strengthen Privacy Impact Assessment Skills

Turn Privacy Risk Assessment Into Better Design Decisions

Privacy by design works best when teams identify risks before personal data processing is launched or materially changed.

The French Compliance Institute’s Privacy Impact Assessment Training helps professionals understand how to assess privacy risks, structure impact assessments and connect identified risks with appropriate safeguards.

These skills can support DPOs, compliance professionals and project teams responsible for higher-risk GDPR processing, design reviews and documentation of privacy decisions.

The training can strengthen practical DPIA capability within a broader privacy governance programme, but completing the course does not by itself demonstrate GDPR compliance.

Conclusion

Privacy by design requires organizations to make privacy part of product, system, and process architecture rather than treating it as a final legal review before launch.

Article 25 establishes an ongoing obligation to implement data protection by design and by default, while DPIAs provide a structured way to assess processing that is likely to create high risks for individuals.

Effective implementation depends on early planning, proportionate data collection, privacy-friendly defaults, enforceable technical controls, and evidence showing how material design decisions were assessed and approved.

The objective is not simply to document compliance but to reduce privacy risk through the way systems and processes are actually built and changed.

Organizations that integrate privacy requirements into project design, technical architecture, and change management will be better positioned to demonstrate effective GDPR compliance in France.