Privacy by Design in Software Development

Personal data protection is most effective when it is built into a system from the design stage. Retrofitting compliance into a finished product is considerably more time-consuming and costly. Article 25 GDPR elevates the principle of privacy by design to a legal obligation. In addition, large-scale systems or systems involving a high risk to personal data may also require a Data Protection Impact Assessment (DPIA) under Article 35 GDPR.

For organisations developing software, this is not merely a formal obligation but an integral part of engineering. The way the data model, default settings and data deletion mechanisms are designed may determine whether a product complies with the GDPR or requires costly modifications after deployment.

In this article, I explain how privacy by design and privacy by default translate into software development practice, how these principles can be incorporated into the Software Development Life Cycle (SDLC), what role DPIA plays in this process, and which common mistakes should be avoided.

Privacy by Design and Privacy by Default — Key Principles

Article 25 GDPR imposes two key obligations on the controller.

Privacy by design (data protection by design). From the outset, the controller should anticipate and implement appropriate technical and organisational measures, such as pseudonymisation and data minimisation, both when determining the means of processing and later, throughout the processing itself. In practice, this means that data protection should form part of the system design from the very beginning rather than being treated as an optional feature added after the system has been developed.

Privacy by default (data protection by default). A system should be configured so that, without any additional action by the user, only personal data that are genuinely necessary for the controller’s specific purpose are processed. This applies to the amount of data collected, the way they are used, the period for which they are retained and the number of people who have access to them. Privacy should therefore be the default setting.

Practical guidance on applying both principles is provided by the European Data Protection Board (EDPB) in its Guidelines 4/2019 on Article 25 GDPR. Their underlying message is that a formal declaration of compliance is not enough. The measures implemented must genuinely and effectively protect personal data within the particular system.

The Controller’s Obligation, the Whole Team’s Responsibility

Formally, the obligation under Article 25 GDPR rests with the controller. In practice, however, its implementation depends to a large extent on the team designing and developing the software. It is this team that translates legal requirements into concrete technical solutions — system architecture, the data model, access permissions and default settings.

This is also relevant where the software provider acts as a processor rather than a controller. The way a product is designed may either enable the controller to comply with the GDPR or, conversely, make compliance significantly more difficult. Article 28 GDPR also requires processors to assist controllers in fulfilling certain obligations, including those relating to processing security and data protection impact assessments.

For software providers, privacy by design also has a clear business dimension. Software that incorporates GDPR requirements from the outset is easier to offer to customers, can move through implementation more smoothly and may reduce risks arising during regulatory inspections or contract negotiations.

How to Incorporate Data Protection into the Software Development Life Cycle (SDLC)

The most effective approach is to treat data protection as a requirement throughout the entire product development cycle rather than as a separate legal or compliance step carried out shortly before deployment.

Requirements. At the outset, determine what personal data will be processed, for what purposes and on what legal basis. Data flows and recipients should also be identified. Without this foundation, it is difficult to apply the principle of data minimisation effectively.

Design and architecture. At the design stage, data protection requirements should be translated into concrete technical solutions. The data model should therefore contain only the information necessary for specified purposes. Depending on the risks involved, the architecture should incorporate measures such as pseudonymisation, encryption, an appropriate access-control model, access logging and mechanisms enabling the exercise of data subject rights. Retention periods and automatic deletion of personal data after those periods expire should also be addressed at this stage.

Risk assessment and DPIA. At the same time, the risks that the planned processing may pose to the rights and freedoms of individuals should be assessed. Where the processing is likely to result in a high risk to those rights and freedoms, a Data Protection Impact Assessment (DPIA) must be carried out before the processing begins.

Development and testing. Personal data protection should also be reflected in system configuration. In accordance with the privacy by default principle, default settings should provide a high level of privacy. Development and testing environments require particular care. The use of real production data in such environments should be limited to situations where it is genuinely necessary and appropriately secured.

Deployment and maintenance. GDPR compliance does not end when the product goes live. The system should be updated, monitored and periodically reviewed from both a security and data protection perspective. Any significant change to functionality, the scope of personal data or the way those data are used may affect the previous risk assessment.

It is also important to document key decisions concerning personal data protection. This not only helps structure the design process but also supports compliance with the accountability principle under Article 5(2) GDPR.

Privacy by Default in Practice

The privacy by default principle is easiest to understand through specific examples of settings that a system should apply from the moment it is launched:

• collecting only personal data genuinely necessary for a specified purpose, without creating additional fields “just in case” they may be useful in the future,
• obtaining consent through an affirmative action by the user (opt-in), rather than through pre-ticked checkboxes,
• no automatic public disclosure of a user’s profile, activity or other personal data,
• applying the shortest justified retention period by default,
• restricting access to and visibility of personal data to those who genuinely need them to perform their duties.

If users have to change the settings themselves in order to limit unnecessary processing of their personal data, it is difficult to regard the system as genuinely implementing privacy by default under Article 25 GDPR.

Privacy by Design and DPIA

A Data Protection Impact Assessment (DPIA) is a natural complement to the privacy by design principle. A DPIA is a formalised risk assessment process that must be carried out where planned processing is likely to result in a high risk to the rights and freedoms of individuals.

Under Article 35(3) GDPR, a DPIA is required in particular in the case of:

• a systematic and extensive evaluation of personal aspects relating to individuals based on automated processing, including profiling, where decisions based on that evaluation produce legal effects or similarly significantly affect the individual,
• large-scale processing of special categories of personal data referred to in Article 9 GDPR or data relating to criminal convictions and offences referred to in Article 10 GDPR,
• systematic monitoring of publicly accessible areas on a large scale.

When determining whether a DPIA is required, it is also worth consulting the guidance issued by data protection authorities and the list of types of processing operations subject to the DPIA requirement published by the President of the Polish Personal Data Protection Office (UODO).

Two points are particularly important. First, a DPIA must be carried out before the processing begins, ideally while the solution is still being designed. Second, if the residual risk remains high despite the safeguards and measures planned, the controller must consult the supervisory authority before commencing the processing, in accordance with Article 36 GDPR.

A DPIA should therefore not be treated as a mere compliance formality. A properly conducted assessment should have a genuine impact on the system design, its architecture, the scope of the personal data processed and the safeguards implemented.

Production Data in Test Environments — an Easily Overlooked Risk

Another common mistake in software development is the use of real personal data taken from production environments for testing, development or training purposes. This may significantly increase the risk of a personal data breach because non-production environments often have weaker security controls and may be accessible to a wider group of users.

Wherever possible, synthetic or effectively anonymised data should therefore be used. If this is not feasible, pseudonymisation may be considered, although it is important to remember that pseudonymised data remain personal data and continue to be subject to the GDPR.

An appropriate approach to test data is one of the practical manifestations of privacy by design and, at the same time, forms part of compliance with the security requirements under Article 32 GDPR.

Common Mistakes When Implementing Privacy by Design

“GDPR at the end.” Attempting to adapt finished software to data protection requirements is more expensive and less effective than incorporating those requirements at the design stage.

Overly permissive default settings. If a system collects, shares or retains more personal data than necessary by default, it is difficult to regard it as complying with privacy by default.

Production data in test environments. Using real personal data in development and test environments unnecessarily increases the risk of a personal data breach, particularly where those environments have weaker safeguards or are accessible to a larger number of people.

No DPIA, or a DPIA carried out too late. A data protection impact assessment cannot fulfil its purpose if it is performed only after the system has been deployed. Where processing is likely to result in a high risk to the rights and freedoms of individuals, the DPIA should influence the product before processing begins.

Collecting data “just in case.” Adding data fields simply because the information may be useful at some point in the future conflicts with the principle of data minimisation. Every category of personal data should have a specific and justified purpose.

No properly designed retention policy. A common problem is designing mechanisms for collecting personal data without simultaneously determining when and how those data will be deleted. Retention should be addressed as part of the product design itself.

Excessive access permissions. Granting entire teams access to personal data increases the risk of unauthorised access. Permissions should correspond to genuine needs arising from an individual’s role.

Treating pseudonymisation as anonymisation. Pseudonymisation is an important risk-reduction measure, but it does not mean that the information ceases to constitute personal data. Pseudonymised data remain subject to the GDPR.

Failure to reassess risks following system changes. A new feature, an additional data source or a change in the way personal data are used may significantly alter the risk profile. Privacy by design is therefore not a one-off exercise carried out before the first release of a product.

Failure to document design decisions. Even well-designed solutions may be difficult to demonstrate later if there is no record of why they were adopted. Documenting key decisions concerning the scope of personal data, retention, access permissions and security measures is an essential part of the accountability principle.

Privacy by Design in an IT Project — Practical Checklist

• Map the personal data, purposes and legal bases already at the requirements stage.
• Limit the scope of personal data to what is strictly necessary — every data field should have a specific purpose and justification.
• Design appropriate safeguards, including pseudonymisation, encryption and access controls based on the need-to-know principle.
• Make privacy the default — use opt-in mechanisms, restricted data visibility and the shortest justified retention periods.
• Plan how data subject rights will be exercised, including access, rectification, erasure, restriction of processing and data portability, where applicable.
• Design retention and deletion mechanisms — preferably automated and verifiable.
• Carry out a risk assessment, and where processing is likely to result in a high risk, conduct a DPIA before the processing begins.
• Do not use production data for testing where the same objective can be achieved using synthetic or effectively anonymised data.
• Address the security of non-production environments, particularly access permissions, activity logging and data storage.
• Review external providers and components — libraries, cloud services, APIs and subcontractors may also affect the scope and risks of processing.
• Involve the Data Protection Officer (DPO) at an early stage, where one has been appointed, particularly in more complex or high-risk projects.
• Document key design decisions concerning personal data, retention, access, safeguards and risk assessments, in accordance with the accountability principle.
• Test not only functionality but also data protection mechanisms, such as permissions, data deletion, retention and default settings.
• Reassess risks following significant changes to functionality, architecture or the way personal data are used.
• Ensure monitoring, updates and periodic reviews after deployment, because privacy by design is an ongoing process rather than a one-off task completed before the system goes live.

Do You Need Support with Privacy by Design or DPIA?

Incorporating data protection into software from the design stage helps reduce risk, avoid costly changes after deployment and build GDPR-compliant solutions from the outset.

At Dr Joanna Maniszewska-Ejsmont Law Firm, we support organisations developing and implementing IT solutions in the practical application of privacy by design and privacy by default, conducting Data Protection Impact Assessments (DPIAs), defining the roles of the parties and preparing appropriate agreements governing the processing of personal data.

If you are developing a new system, expanding an existing product or want to verify whether your current solutions meet GDPR requirements, explore our GDPR implementation and audit services or contact us.