Prioritizing DPIAs Before a Peak-Season Personalization Launch
You are the privacy risk lead at an online retailer with 18 million customers. Marketing plans to launch a personalization engine in six weeks that combines browsing history, purchase history, and precise location to rank offers and send push notifications. The program uses 34 processors; seven contracts lack audit rights, and one analytics vendor's terms allow it to use data to improve its own models. Your team has four people. The applicable law requires a data protection impact assessment before high-risk processing and requires risk to be managed, not merely documented. The existing risk register has 212 entries with inconsistent scoring, and executives have verbally said they will "accept the risk" if the launch slips. Peak season begins in eight weeks.
1. How should you triage which processing activities require a DPIA first, and what criteria should drive that order?
Read the worked answer
Start with a screening questionnaire tied to DPIA triggers, then rank by likelihood and severity. Triggers include systematic monitoring, large-scale processing, profiling or automated decision-making with significant effects, location tracking, innovative technology, data matching across sources, vulnerable data subjects, and transfers to vendors with weak controls. The personalization engine hits several triggers at once: it profiles customers, uses precise location, combines datasets, and operates at scale across 18 million people. It should be assessed before lower-risk activities such as a routine newsletter change.
Build a triage matrix with two axes: inherent risk and evidence gaps. Inherent risk should consider scale, sensitivity, identifiability, and the power imbalance between the retailer and the customer. Evidence gaps should consider missing contracts, unclear legal basis, and unproven controls. The vendor whose terms permit secondary use is an immediate high priority because purpose limitation is already compromised.
Run a two-week assessment sprint rather than a perfect inventory cleanse. Assign one assessor to the personalization DPIA, one to vendor contracts, and one to data flow mapping. Use a lightweight review for clearly low-risk initiatives so the team is not pulled into unnecessary documentation.
Reasoning: the law requires the DPIA before processing begins, so sequencing must follow launch risk, not register order. A risk-based triage also gives executives a defensible explanation for why some items wait.
2. The analytics vendor's contract allows it to use data to improve its own models. What controls and risk decision should follow?
Read the worked answer
Treat the vendor's secondary use as a purpose-limitation failure, not a commercial term to negotiate later. The retailer remains accountable for the processing, and the vendor's model improvement is a separate purpose with no obvious lawful basis and no transparency to customers.
First, require a contract change that prohibits use of retailer data for the vendor's own purposes, including model training, product improvement, and benchmarking. Add deletion or return obligations, subprocessor notice, audit rights, and a requirement to certify deletion. Second, apply technical controls so the vendor cannot retain raw or linkable data: aggregate or pseudonymize events before transfer, remove direct identifiers and precise location, reduce event granularity, and use a clean-room or on-device processing arrangement where feasible. Third, document a transfer and purpose assessment. If the vendor refuses the restrictions, escalate the decision as an unacceptable residual risk and identify an alternative vendor.
Reasoning: a contract clause alone is weak if the data flow still sends raw identifiers. The combination of contractual prohibition and technical minimization is what makes the risk defensible. Allowing the vendor to proceed on verbal assurances would be difficult to justify to a regulator.
3. Executives want to verbally "accept the risk" so the launch stays on schedule. How should you present residual risk and structure the decision?
Read the worked answer
Present the risk in writing with three elements: inherent risk, planned mitigations, and residual risk. Use a matrix that shows regulatory exposure, customer harm, and financial and reputational impact separately, because a single color can hide the reason for the decision. State which mitigations are prerequisites to launch and which can follow.
Give executives real options, not a binary approve-or-delay choice. For example: launch without precise location and without the secondary-use vendor; launch to a small cohort with enhanced monitoring; or delay the full launch until contract and consent changes are complete. For each option, state the residual risk, the accountable owner, and the trigger for reassessment.
Require the accountable executive to sign the risk acceptance at the correct level, with a rationale and an expiration date. Verbal acceptance should not be recorded as a control. Set conditions such as re-assessment after 30 days or upon any change in data sources. If the residual risk exceeds the organization's stated risk appetite, escalate to the audit or risk committee rather than absorbing it silently.
Reasoning: documented risk acceptance is a governance control; it does not eliminate the obligation to mitigate. The privacy team's job is to make the trade-off visible and force a decision at the right authority level.