ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
A privacy review process is the gate that makes sure new products, features and vendors are assessed for privacy risk before they reach customers. Without one, privacy teams learn about a feature from a launch announcement, when changing it is expensive and awkward. With one, the questions are asked while the design can still change cheaply.
This guide explains how to build a privacy review process that fits how product and engineering teams actually work: what should trigger a review, what the intake form should ask, how deep to go, who signs off and what records to keep.
Privacy risk is created by decisions: what data to collect, what to combine, who to share it with and how long to keep it. Those decisions are made early in a project and are hard to reverse. Data protection law reflects this. Article 25 of the GDPR requires data protection by design and by default, and Article 35 requires an impact assessment before high-risk processing begins. A privacy review process is the practical mechanism that puts those duties into the development calendar. Our guide to privacy by design explains the principles behind it.
A review process also produces evidence. When a regulator or customer asks how you assess new processing, a record of reviews, decisions and changes is far more convincing than a policy statement.
Decide what must go through review, and write it down. Common triggers include:
Attach the triggers to existing gates such as product requirement documents, procurement forms and change tickets, so the review starts automatically. Relying on people to remember is the most common reason reviews are missed.
Keep the intake short enough to complete in ten minutes. The point is to give the privacy team enough to decide the depth of review. Useful questions are shown below.
| Question | Why it matters |
|---|---|
| What does the feature do and for whom? | Sets the purpose and the affected people |
| What personal data is used, and where does it come from? | Identifies data types and sources |
| Who receives the data, inside and outside the company? | Finds vendors, transfers and access |
| How long is it kept and how is it deleted? | Tests retention and minimisation |
| Are children, sensitive data or automated decisions involved? | Flags higher-risk processing |
| When is the planned launch? | Sets the review timetable |
Not every change needs a full assessment. Use tiers that match the risk.
For changes that use existing data in an expected way, a short check by the privacy team and a note in the record is enough. The aim is speed: give a response within a few working days.
For new data, new vendors or new uses, complete a structured privacy risk assessment: data flows, lawful basis, risks to individuals, measures and residual risk. Store the results in your privacy risk register.
Free privacy risk assessment
Which privacy risks would hurt the people whose data you hold?
List your personal data and processing, pick from 38 privacy risk scenarios, rate them for the people concerned and for you, and plan treatment with ISO 27701 controls. You get a heat map, a process score and the findings an auditor would raise, free.
Run the free privacy risk assessment → or View premium report sample
For processing likely to result in high risk, such as large-scale profiling or sensitive data, complete a DPIA. Our guide on when a DPIA is required lists the triggers, and the comparison of privacy risk assessment and DPIA shows how the two relate.
For a standard or full review, the assessor should map the data flows, confirm the lawful basis, check transparency and notices, examine vendor arrangements and identify risks to individuals. Focus on what could go wrong for the people concerned: surprise, exposure, unfair treatment, loss of control. The methods described in NIST’s guidance on problematic data actions are a useful way to structure that thinking. For each risk, agree measures with the product team, such as collecting less, shortening retention, pseudonymising, adding a setting or improving a notice.
Make the review collaborative, not adversarial. Product teams cooperate when they see the privacy team as a source of practical options rather than a source of delay. Offer at least two workable alternatives when you object to a design.
Engineers respond well to concrete requirements. Turn common review outcomes into reusable patterns: a standard retention setting, a template for consent screens, a checklist for logging that avoids personal data, an approved list of analytics tools. Publish them where developers already look, and let teams that follow the patterns skip to a light check. This rewards good design and cuts the load on the privacy team.
Embed a privacy champion in each major product group, someone who knows the process, answers first questions and flags features early. Champions shorten reviews because the intake arrives complete and the risks are already partly considered.
Each review should end with a decision: approve, approve with conditions or not approved. Conditions should be specific, with owners and dates, such as “delete raw data after 90 days; verify before launch”. Someone with authority over the feature accepts any residual risk, and the DPO, where you have one, should be consulted on high-risk items and their advice recorded. Track the conditions to closure, because approval with unenforced conditions is a common weakness.
Keep the intake form, the tier decision, the assessment, the measures agreed, the decision, the conditions and the evidence they were met, and the date of the next review. Link the record to the ticket or project so that anyone can find it later. Records also let you measure the process: number of reviews, time to decide, share sent to each tier, and conditions closed on time. If reviews take too long, teams will bypass them, so watch turnaround as closely as quality.
The following is a hypothetical example invented for illustration. A meal-kit company plans a feature that suggests recipes based on dietary preferences and past orders. The product manager submits the intake form. Because dietary preferences can reveal health conditions or religious belief, the privacy lead moves the feature to the standard tier.
The review finds that preferences would be shared with a third-party recommendation vendor, and kept indefinitely. The team agrees to remove free-text fields, send only coded categories to the vendor, cap retention at 24 months and add a plain-language explanation on the settings page. The privacy lead approves with conditions and checks them before launch. The whole review takes six working days and changes the design in three places, at almost no cost, before any customer sees it.
Common failures include weak triggers nobody applies, intake forms that are too long, one depth for every change, reviews that begin after the design is fixed, sign-off with no conditions tracked, records nobody can find, and privacy teams that become bottlenecks. Another is excluding vendor tools bought by business teams with a credit card, which often carry the most surprising data flows. Include procurement and finance in the trigger design to catch them.
Every quarter, look at what the reviews found. If the same problem keeps appearing, such as excessive retention, fix it at the source with a standard, a template or an engineering control. If reviews catch nothing, consider whether the triggers are too narrow. Feed lessons into training for product managers so that they ask the right questions before the form is submitted.
A consistent report helps every review record the data, risks, measures and decision in the same way. The Privacy Risk Assessment Report and Workbook provides a report and workbook for documenting privacy risks and their treatment. Whichever tool you use, keep the same fields across reviews so they can be compared.
For further reading on how regulators view assessment of new processing, the UK Information Commissioner’s Office publishes practical guidance on data protection impact assessments, which shows what to document for higher-risk processing.
No law names it, but data protection by design and by default and the duty to assess high-risk processing require you to consider privacy before processing begins. A review process is the practical way to do it.
A light check can take a few days; a standard review one to two weeks; a full DPIA longer. Publish target turnaround times so teams can plan.
The privacy or data protection team should own it, with product, engineering and procurement as partners who trigger and support reviews.
Treat it as an incident: assess the feature promptly, record the gap, and fix the trigger that failed so it does not recur.
Yes. Any tool that processes personal data should go through the process, whoever bought it. Vendor features often create the least visible risks.
September 30, 2026
