Privacy-by-Design Review Template (GDPR Art. 25, ISO 31700-1)

Privacy-by-Design Review: [Product or feature name]

Record of how privacy was designed into a product, feature or service through its lifecycle, from concept to retirement. It documents the consumer privacy requirements, the privacy-by-default decisions, data minimisation choices, user controls, notice and consent design, the data lifecycle, third parties and the assurance evidence that shows the measures work. It follows Article 25 of the General Data Protection Regulation (Regulation (EU) 2016/679, data protection by design and by default) and the EDPB Guidelines 4/2019 on Article 25 (version 2.0, adopted 20 October 2020). Its requirement areas are aligned with the clause structure of ISO 31700-1:2023 (privacy by design for consumer goods and services, high-level requirements), cited by name only. It sits upstream of the DPIA and the privacy threat model. Replace every [bracketed] value and every row marked Example. This is a documentation format, not legal advice.

Document control

Approvals

Revision history

Contents

• 1. Scope and lifecycle stage
• 2. Positioning: which privacy document to use
• 3. Roles and responsibilities
• 4. Processing overview and data inventory
• 5. Consumer privacy requirements
• 6. Privacy by default decisions
• 7. Data minimisation
• 8. User controls and data subject rights
• 9. Notice and consent design
• 10. Data lifecycle
• 11. Third parties and recipients
• 12. Privacy risk screening and DPIA trigger
• 13. Assurance evidence
• 14. Lifecycle checkpoints and re-review triggers
• 15. Findings, decisions and actions
• 16. Traceability matrix
• 17. Glossary and references
• Standard and licence note

1. Scope and lifecycle stage

Describe the product or feature in two or three sentences, written so that a reviewer who has never seen it understands what data it needs and why.

Example: Corvid Commerce adds "Saved checkout details" so that returning customers can store a delivery address and a payment token and check out in one step. In scope: the web and mobile checkout, the Checkout service, the customer profile store, the payment service provider integration and the "Checkout" data product in the lakehouse. Out of scope: fraud scoring, which has its own DPIA.

2. Positioning: which privacy document to use

This review is the design record. It shows which privacy decisions were taken, when, by whom and with which evidence. It does not replace the documents below; it feeds them.

How the sections map to the requirement areas of ISO 31700-1:2023 (described in original words; confirm the clause numbering against your licensed copy):

3. Roles and responsibilities

4. Processing overview and data inventory

4.1 Data flow

Draw every hop the personal data takes, including logs and analytics. The same diagram is the starting point for the privacy threat model.

4.2 Data inventory

Lawful basis note: storing card data only to make later purchases easier is not necessary for the sales contract. EDPB Recommendations 02/2021 (adopted 19 May 2021) conclude that consent is the appropriate basis, given separately from the terms of sale and never as a condition of completing the purchase. Corvid stores a PSP token rather than card data, but applies the same reasoning to the saved token and address. Retention values quote the rule IDs and periods of the retention standard; classification values quote the level and criterion ID of the classification policy.

Record special categories (GDPR Art. 9) and data about children separately and flag them for the section 12 screening.

5. Consumer privacy requirements

Write each requirement as a design behaviour with an acceptance test. Group them by the data protection principles in GDPR Article 5, which is also how the EDPB Guidelines 4/2019 organise the key design and default elements. Derive requirements from four inputs: the principles, consumer research (what users expect), the privacy threat model and contractual commitments.

6. Privacy by default decisions

For each configurable behaviour, record the default state and why it is the most privacy-protective option that still delivers the purpose. A default that is not the most protective option needs a recorded justification and the approval of the product owner and the DPO advice.

Record dark-pattern checks here too: no confirm-shaming, no asymmetric buttons, no repeated prompts after a refusal, and an equally easy way to undo a choice.

7. Data minimisation

Run each element in the section 4 inventory through the questions below and record the outcome. Remove, reduce or transform the element when the answer allows it.

1. Is the element necessary for the stated purpose, or only useful?
2. Can a less precise form serve the purpose (postcode district instead of full address, age band instead of birth date)?
3. Can it be derived on demand instead of stored?
4. Can it be processed on the device or at the edge instead of centrally?
5. Can it be pseudonymised, aggregated or anonymised before it reaches analytics or a third party?
6. Can access be limited to a smaller role or a shorter window?

When minimisation relies on pseudonymisation or anonymisation, run the De-identification Assessment (compliance/de-identification-assessment). Pseudonymised data remains personal data under the GDPR; record it as such.

8. User controls and data subject rights

Make sure each control is reachable with a keyboard and a screen reader, and that it works the same way in every channel listed in section 1. Requests made through support must reach the same back-end operations as the self-service controls.

9. Notice and consent design

9.1 Notice layers

Update the Privacy Policy (legal-lite/privacy-policy) and, where the feature sets or reads cookies or similar technologies, the Cookie Policy (legal-lite/cookie-policy).

9.2 Consent records

Use consent only where it is the right lawful basis. Record each consent-based processing activity below.

Honour browser privacy signals such as Global Privacy Control where the applicable law or your policy requires it, and record how the signal is treated.

10. Data lifecycle

Align periods with the Data Retention and Deletion Standard (data/data-retention-deletion-standard) and the records schedule (compliance/iso-15489-records-schedule). State how deletion is verified, not only how it is triggered.

11. Third parties and recipients

Check residency and transfer questions with the Data Residency and Sovereignty Assessment (compliance/data-residency-sovereignty-assessment) and supplier security with the Supplier Security Assessment (compliance/supplier-security-assessment).

12. Privacy risk screening and DPIA trigger

Answer each question. A "yes" to any of the first four (the three cases of Article 35(3) and the supervisory authority list under Article 35(4)) makes a DPIA mandatory. Two or more "yes" answers among the remaining rows, which follow the WP248 rev.01 criteria, mean you should run a full DPIA (compliance/dpia) unless the DPO advises otherwise in writing and the reasons are recorded. Treat the two-indicator rule as an internal policy example; adapt it to the supervisory authority lists that apply to you.

Example: For "Saved checkout details", the first four answers are "No". Two rows need judgement: large scale (2.1 million active customers, of whom 1.2 million are in the EU) is "Yes"; highly personal data is "No", because the card number never reaches Corvid and only a PSP token is stored. One indicator, so the DPO advised that no DPIA is required and the reasoning was recorded; the screening is re-run at the "Change" checkpoint and whenever the token is used for anything beyond repeat checkout.

13. Assurance evidence

The EDPB guidelines stress that measures must be effective, so record evidence of operation, not only of intent. Article 25(3) allows an approved certification under Article 42 to be used as one element of demonstrating compliance; it does not replace this evidence.

Re-test the evidence that depends on configuration at least once a year and after each change that touches the components in section 1.

14. Lifecycle checkpoints and re-review triggers

Re-review when any of these occur: a new purpose, a new data category, a new recipient or country, a change of lawful basis, a new channel or user group (especially children), a significant incident involving the data, a change in law or regulator guidance, or a substantial rise in scale.

15. Findings, decisions and actions

16. Traceability matrix

17. Glossary and references

17.1 Glossary

17.2 References

Standard and licence note

Based on Article 25 of Regulation (EU) 2016/679 (GDPR) as published in the Official Journal of the European Union and on the EDPB Guidelines 4/2019 on Article 25 Data Protection by Design and by Default (version 2.0, adopted 20 October 2020). Structure aligned with ISO 31700-1:2023, which is cited by name only: no ISO text, requirement wording, definition or table is reproduced, and the requirement areas in this template are described in original words. ISO/TR 31700-2:2023 and ISO/IEC 27701:2025 are named for context only. Articles are cited and summarised in original wording; check the consolidated GDPR text, the current EDPB guidance and the national rules that apply before use. The template text is original. This is a documentation format, not legal advice. Template licence: MIT.