ISO 27701 and GDPR for CTOs: how to design privacy into products and systems?

GDPR Article 25 privacy by design and by default: at which development gate does R&D put it?

In the design phase, continuing after go-live. Article 25(1) requires the controller to implement appropriate technical and organisational measures "both at the time of the determination of the means for processing and at the time of the processing itself", with pseudonymisation given as the example; Article 25(2) requires that by default only personal data necessary for each specific purpose are processed, covering the amount collected, the extent of processing, the storage period and accessibility.

In practice, four items can go into the existing design review checklist:

The European Data Protection Board's Article 25 guidelines (Guidelines 4/2019), final version 2.0 (20 October 2020), can serve as a reference for design review.

When must a new feature have a DPIA, and where does it go in the R&D schedule?

Under Article 35(1) GDPR, where processing (in particular using new technologies) is likely to result in a high risk to the rights and freedoms of natural persons, the controller must carry out a data protection impact assessment (DPIA) prior to the processing. Article 35(3) lists three cases where it is required:

• a systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions with significant effects are based;
• processing on a large scale of special categories of data under Article 9(1) or of criminal conviction data;
• systematic monitoring of a publicly accessible area on a large scale.

Each supervisory authority also publishes a list of processing types requiring a DPIA under Article 35(4), and the EDPB has endorsed the Article 29 Working Party's DPIA guidelines.

In the R&D schedule: add a DPIA trigger check at the requirements or design review gate, rather than patching it in before launch. Whether a DPIA is mandatory is a legal judgement for legal counsel case by case; ISO 27701 does not make that judgement.

Can R&D test with real personal data? Is pseudonymised data no longer personal data?

Pseudonymised data are still personal data. Article 4(5) GDPR defines pseudonymisation as processing such that the data can no longer be attributed to a specific data subject without additional information kept separately; the EDPB's pseudonymisation guidelines (Guidelines 01/2025, public consultation version adopted on 16 January 2025) state that pseudonymised data remain information relating to an identifiable natural person and are therefore personal data (Recital 26 GDPR), and can become anonymous only if the conditions for anonymity are met.

For R&D this means:

• Testing or debugging with real data, including pseudonymised data, is within the GDPR and needs a purpose, access rights and a retention period.
• Pseudonymisation is a risk-reducing measure and the example named in Article 25, but the EDPB notes that pseudonymisation alone will normally not be sufficient.
• The re-identification key should be kept separately from the test environment, with restricted access.

Whether data have become anonymous is a case-by-case legal and technical judgement, to be confirmed by legal counsel.

Product telemetry and system logs contain personal data: how should R&D design them?

Telemetry and logs often contain device identifiers, accounts, IP addresses and other identifying data, and are bound by the same GDPR principles:

• Data minimisation (Article 5(1)(c)): adequate, relevant and limited to what is necessary for the purposes.
• Storage limitation (Article 5(1)(e)): kept in identifiable form no longer than the purposes require.
• Default settings (Article 25(2)): by default only necessary personal data are processed, covering amount, extent of processing, storage period and accessibility.

In engineering terms: label each telemetry field with its purpose; pseudonymise identifiers at the point of collection; set retention periods for logs with automatic deletion; restrict access by role. These processing activities also belong in the record of processing activities (RoPA, Article 30 GDPR), which can be shared with the ISO 27701 processing records.

Sending EU data back to a Taiwan R&D centre, or Taiwan engineers debugging remotely: is that a cross-border transfer?

Under the EDPB guidelines on transfers (Guidelines 05/2021, version 2.0 adopted on 14 February 2023), processing is a "transfer" under Chapter V of the GDPR only when three criteria are all met:

1. The exporter (controller or processor) is subject to the GDPR for the processing;
2. The exporter discloses by transmission or otherwise makes personal data available to another controller, joint controller or processor;
3. The importer is in a third country.

The guidelines state that remote access from a third country (for example for support or troubleshooting) is also a transfer where the three criteria are met; an employee of the same controller accessing company data on a business trip is not, because the employee is not another controller; an EU subsidiary making data available to its parent in a third country is a transfer.

Taiwan currently has no EU adequacy decision, so where there is a transfer, Article 46 safeguards (such as standard contractual clauses) and a transfer impact assessment are needed. Whether a transfer exists and which mechanism to use is for legal counsel to judge case by case.

What does ISO 27701 require of the R&D process, and how long does it take?

ISO/IEC 27701:2025 (published October 2025, edition 2) sets out requirements for establishing, implementing, maintaining and continually improving a privacy information management system (PIMS) for PII controllers and processors; it can be implemented and certified without 27001, and 2019-edition certificates are expected to transition until October 2028. In the R&D process it shares one base with the GDPR:

A 27701 certificate is not GDPR compliance: whether a DPIA is mandatory, the EU representative and the choice of SCC module are legal judgements it does not make. As listed on the service page: basic GDPR set-up usually takes 2–3 months, integration with ISO 27701 certification 5–8 months, or 3–5 months with an ISO 27001 foundation.

How does Winners Consulting help a CTO with ISO 27701 and the GDPR?

Vice-president and director-level consultants personally lead the work end to end, never outsourced. We use 27701 as the backbone, attach each GDPR obligation to the matching control, close the gaps in the project, and go through certification together. The four phases listed on the service page:

1. Applicability and data inventory: determine GDPR applicability and the mechanisms required, map personal data, data flows and cross-border transfers, and produce a draft RoPA.
2. System building: build the PIMS documents to 27701:2025 and attach rights procedures, processor contracts and breach notification.
3. Legal mechanisms: SCCs and TIA, DPIA, DPO and EU representative appointment.
4. Internal audit, management review and certification support.

Named client: Hypercore Fitness Center, ISO 27001 ISMS and ISO 27701 PIMS dual-certification consulting.

Go deeper: ISO 27701 implementation, GDPR consulting, Choosing an ISO 27701 consultant, Choosing a GDPR consultant. Request a free mechanism diagnosis