Privacy is not an add-on bolted on once a product is already built: it is a requirement that must be present from the very first blueprint of any information system. That is precisely what Article 25 of the Regulation (EU) 2016/679 (GDPR) demands — a provision that remains one of the least understood among SMEs and mid-sized companies, even though non-compliance can lead to fines under Article 83 of the GDPR.
In this article we analyse exactly what Article 25 of the GDPR requires, which technical and organisational measures are most relevant for compliance, what role pseudonymisation plays, and how the Systems division of Summum Consultoría supports organisations in integrating these principles from the design phase.
What Article 25 of the GDPR establishes
Article 25 of the GDPR regulates two distinct but closely linked principles:
- Privacy by design: obliges the controller to implement, both at the time of determining the means of processing and at the time of the processing itself, appropriate technical and organisational measures — such as pseudonymisation — designed to implement data-protection principles effectively and to integrate the necessary safeguards into the processing (Article 25.1 GDPR).
- Privacy by default: obliges the controller to ensure that, by default, only personal data which are necessary for each specific purpose of the processing are processed. This obligation covers the amount of data collected, the extent of their processing, the period of their storage and their accessibility (Article 25.2 GDPR).
Article 25.3 adds that adherence to a certification mechanism pursuant to Article 42 of the GDPR may be used as an element to demonstrate compliance with the two preceding paragraphs.
The European legislator uses two temporal thresholds for privacy by design: "at the time of determining the means of processing" and "at the time of the processing itself". This means the obligation arises before the system is put into operation, not once it is already running. A company starting to build a CRM, a customer portal or an HR management system is already subject to Article 25 at the functional specification stage.
Regulatory background: the origins of privacy by design
The concept of privacy by design has its roots in the work of Ontario's (Canada) Information and Privacy Commissioner, Ann Cavoukian. The concept, which emerged in the 1990s, was later formalised in seven foundational principles: proactive not reactive; privacy as the default setting; privacy embedded into design; full functionality — positive-sum, not zero-sum; end-to-end security throughout the full data lifecycle; visibility and transparency; and respect for user privacy. The GDPR absorbed this philosophy and turned it into a directly applicable legal obligation across the twenty-seven Member States of the European Union.
In Spain, Organic Law 3/2018 of 5 December on the Protection of Personal Data and guarantee of digital rights (LOPDGDD — Ley Orgánica de Protección de Datos y garantía de los derechos digitales) does not specifically develop Article 25 of the GDPR, but it complements the European framework on procedural and sector-specific matters. The LOPDGDD repealed the former LO 15/1999 and is, together with the GDPR, the current regulatory reference for organisations operating in Spain.
The European Data Protection Board (EDPB) has published specific guidelines on privacy by design and privacy by default that guide the practical application of Article 25, particularly regarding the criteria for assessing technical and organisational measures.
Technical and organisational measures: what the regulation requires
Article 25.1 of the GDPR clarifies that measures must take into account "the state of the art, the costs of implementation, the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for the rights and freedoms of natural persons". There is therefore no exhaustive list of mandatory measures: the regulation requires proportionality and adequacy to the actual risk of each organisation and each specific processing activity.
The most common technical measures that help comply with Article 25 include:
- Pseudonymisation and encryption of databases, files and communications.
- Role-based access control (RBAC): only personnel who need data for their specific function can access it.
- Minimisation in forms and APIs: collecting only the fields strictly necessary for the declared purpose, without requesting additional information "just in case".
- Separation of direct identifiers in development and testing environments, so that developers do not work with real customer or employee data.
- Access audit logs for personal data: traceability of who accessed which data and when.
- Automated deletion of data once the retention period established for each category has elapsed.
- Environment separation (production, development, pre-production) to prevent the use of real data outside the necessary operational environment.
Complementary organisational measures include:
- Privacy review as a mandatory prerequisite before launching any new processing activity or functionality.
- Data protection clauses in contracts with suppliers and processors detailing the required technical and organisational instructions.
- Internal data lifecycle management procedures, from collection to erasure.
- Regular staff training on minimisation principles, confidentiality and incident management.
- Data Protection Impact Assessments (DPIAs) for high-risk processing, in accordance with Article 35 of the GDPR.
Pseudonymisation: a key tool, not a complete solution
The GDPR defines pseudonymisation in Article 4.5 as "the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person".
Pseudonymisation is a powerful tool for reducing processing risk, but it is not equivalent to anonymisation. Pseudonymised data remain personal data under the GDPR, because re-identification is possible if the additional information (the key or correspondence table) is accessed. What pseudonymisation does enable is a significant reduction in exposure risk in the event of a security breach, and it facilitates certain secondary processing activities compatible with the original purpose.
The most relevant use cases in a business context are:
- Development and testing environments: working with real-structure data without exposing actual customer or employee data.
- Internal analytics: measuring user behaviour or compiling statistics without individually identifying each person.
- Data sharing with third parties: sending datasets to suppliers or partners for analysis without revealing the identity of data subjects.
- Research and statistics: reuse of data for secondary purposes with a lower impact on data subjects' rights, under Article 89 of the GDPR.
Privacy by default: minimisation as an operational obligation
The principle of privacy by default requires that the initial configuration of any system, application or service be the most restrictive in terms of personal data processing. If a system has configurable privacy options, the default option must always be the one that involves the least data processing, not the most permissive one.
This has direct and concrete implications for the design of digital products and for the internal procedures of organisations:
- A service registration form must not collect a phone number if it is not strictly necessary for the provision of that service.
- An HR application must not link an employee's medical history to their payroll record if both data do not need to be integrated for any legitimate processing purpose.
- A web analytics dashboard must not store the full IP address if the first three octets are sufficient for the intended geographical analysis.
- A video-surveillance system must not retain recordings beyond the maximum period of one month provided for in Article 22.3 of the LOPDGDD, unless a specifically justified legal ground exists.
- An e-commerce platform must not pre-tick commercial communications subscription boxes by default: the user must actively opt in to receive them.
Comparison: privacy by design versus privacy by default
| Criterion | Privacy by design (art. 25.1 GDPR) | Privacy by default (art. 25.2 GDPR) |
|---|---|---|
| When it applies | From the conception and design of the system | At each configuration and launch of the processing activity |
| Primary audience | Development teams, systems architects, DPO | Product, user experience, systems administration |
| Typical technical measures | Pseudonymisation, encryption, RBAC, environment separation | Optional fields disabled by default, minimum retention, restricted access by default |
| Linked GDPR principle | Minimisation, integrity and confidentiality (art. 5.1.c and 5.1.f GDPR) | Minimisation, purpose limitation, storage limitation |
| Documentary evidence | Design records, prior DPIA, privacy review minutes | Documented configurations, retention policies, access logs |
| Enforcement regime | Art. 83.4 GDPR: up to €10 M or 2 % of total annual worldwide turnover | Art. 83.4 GDPR: up to €10 M or 2 % of total annual worldwide turnover |
The intersection with the Systems division: integration from the architecture layer
Complying with Article 25 of the GDPR is not solely a task for the legal department or the Data Protection Officer: it requires technical teams — systems architects, developers, database administrators, infrastructure managers — to internalise privacy by design principles as an integral part of their standard working methodology.
The Systems division of Summum Consultoría works precisely at this intersection: we support the technical teams of organisations to integrate the requirements of Article 25 into their development workflows, data architectures and deployment procedures. The goal is not to add a compliance layer at the end of the process, but to incorporate technical and organisational measures from the earliest architectural decisions, when the cost of doing it correctly is minimal compared to the cost of fixing issues once the system is in production.
The most common activities in this area include:
- Review of database schemas to identify fields that collect more information than strictly necessary for the processing purpose.
- Implementation of automated retention policies in storage systems, with alerts and scheduled deletion processes.
- Definition and documentation of role-based access profiles in internal management applications.
- Configuration audits of SaaS tools and cloud platforms to verify that the default configuration applied by the provider is the most restrictive available in terms of privacy.
- Advisory on API design to minimise the exposure of personal data in responses, avoiding returning unnecessary fields for the requesting use case.
- Review of development and testing environments to ensure that real production data is not used without prior pseudonymisation.
If your organisation is developing a new information system or reviewing the architecture of an existing one, our GDPR compliance team can support you in integrating the principles of Article 25 from the design phase, before the system goes into production and the cost of corrections multiplies.
How to document compliance with Article 25
The principle of accountability set out in Article 5.2 of the GDPR obliges controllers not only to comply with data protection principles, but to be able to actively demonstrate that compliance to supervisory authorities. In the case of Article 25, this translates into maintaining documentary evidence that privacy by design and by default measures have been effectively applied.
The most relevant documents for evidencing compliance with Article 25 are:
- Record of processing activities (art. 30 GDPR): must reflect, among other matters, the technical and organisational security measures applied to each processing activity.
- Data Protection Impact Assessment (DPIA, art. 35 GDPR): mandatory for high-risk processing activities, it documents the privacy analysis carried out before the processing begins.
- Internal privacy review minutes: records evidencing that each new development or functionality was evaluated from a data protection perspective before its launch.
- Data retention policy: a document establishing the retention periods for each data category and the associated automated deletion mechanisms.
- Processor contracts (art. 28 GDPR): must include specific instructions on the technical and organisational measures that the processor is required to implement.
- Configuration and audit logs: technical records evidencing that the privacy-by-default configurations are active in production systems.
The Spanish Data Protection Authority (AEPD — Agencia Española de Protección de Datos) has published guidance and tools that facilitate the practical application of Article 25, including the risk analysis framework and guidelines on impact assessment. Although these guides are not binding, adherence to them constitutes a relevant indicator of due diligence in the event of an AEPD investigation.
The data protection team at Summum Consultoría works with organisations in Castile and León and the Canary Islands — with offices in Valladolid, Burgos, Palencia, León and Las Palmas — to develop this compliance documentation in a rigorous and proportionate manner to the size, sector and activity of each company. Since 2007, with more than two thousand digitalisation and regulatory compliance projects in our portfolio, our approach combines legal expertise with the technical capabilities of the Systems division.
Frequently asked questions
Does Article 25 of the GDPR only apply to technology companies or to any controller?
Article 25 of the GDPR applies to any controller, regardless of size or sector. A dental clinic, a tax advisory firm, a logistics company or an industrial SME that processes data belonging to customers, employees or suppliers is subject to its obligations. The regulation introduces proportionality by requiring that measures be appropriate to the state of the art, costs and the level of risk of the specific processing activity, but it does not exempt any type of organisation. The difference between a large corporation and a small company lies not in whether they must comply, but in the complexity and cost of the required measures.
What is the difference between privacy by design and a Data Protection Impact Assessment (DPIA)?
They are distinct but complementary instruments. Privacy by design is a general principle that obliges organisations to embed data protection into any system from the outset, applicable to all processing activities. A Data Protection Impact Assessment (DPIA, governed by Article 35 of the GDPR) is a formal and documented process, mandatory only for processing activities that are likely to result in a high risk to the rights and freedoms of data subjects, which systematically analyses the risks and the measures to mitigate them before processing begins. A DPIA is, in a sense, the documented embodiment of privacy by design applied to a specific high-risk processing activity.
What sanctions can the AEPD impose for non-compliance with Article 25 of the GDPR?
Non-compliance with Article 25 of the GDPR can result in sanctions falling under Article 83.4 of the GDPR: administrative fines of up to €10,000,000 or, in the case of a company, up to 2% of its total worldwide annual turnover for the preceding financial year, whichever is higher. The LOPDGDD (LO 3/2018) complements this regime under Spanish law with additional graduation criteria. In addition to financial penalties, the AEPD (Agencia Española de Protección de Datos — Spanish Data Protection Authority) can impose corrective measures such as the temporary suspension of the processing activity, the requirement to adopt specific technical measures within a set timeframe, or an order to bring the system into compliance with Article 25 before resuming it.
Does privacy by default prevent offering users more permissive configurations?
Not necessarily. Privacy by default requires that the initial configuration be the most restrictive in terms of data processing, but it does not prevent a data subject from freely, informedly and unambiguously opting for a configuration that involves greater processing of their personal data. The most common example is privacy preference panels or consent management centres: the default option must be set to the necessary minimum, but users may actively expand their consent to optional processing activities. What Article 25.2 of the GDPR prohibits is setting the default configuration to the most permissive option, forcing users to actively work to protect their privacy.