Finishing the Implementation With Half the Budget
Northline Retail operates in 22 countries with 3.1 million loyalty members, 480 stores and an online shop. Its PIMS implementation is about 60% through a nine-month plan, with EUR 150,000 and roughly five FTE-months remaining. State of play: 40 marketing and analytics vendors receive customer data; 11 have no data processing agreement and 23 have not been risk-assessed since onboarding. A cookie banner was reconfigured in February and now sets analytics cookies before consent for visitors from four EU countries; the vendor calls the default "a technical limitation". Loyalty transaction records are deleted after seven years, but clickstream and app-event data are kept indefinitely "for model training". A March incident at an email vendor exposed 90,000 names and email addresses; it was contained but never assessed for notifiability. The DPO wants a prioritised, defensible work plan rather than a control-by-control checklist.
1. Propose the prioritisation logic and the top actions for the remaining budget, justifying each in terms of risk and the standard's requirements.
Read the worked answer
Prioritise on three filters: ongoing harm or unlawful processing happening today, legal exposure with a hard deadline, and cost-to-fix versus risk reduced. Documentation polish comes last.
- Stop pre-consent analytics cookies in the four countries. This is live, continuing, and visible to any regulator or mystery shopper. Either configure consent-mode properly or switch the tags off pending the fix. Cost is low; the risk of leaving it is high and grows daily.
- Close the eleven missing DPAs, starting with vendors receiving the most or most sensitive data. Processor obligations attach to every transfer; an undocumented transfer is also an unreported risk. Template plus signature can be done in weeks.
- Make and record a notifiability decision on the March incident. The breach register, the assessment and the notification decision (or reasoned non-notification) must exist. This is cheap and exposes the organisation badly if absent.
- Define and enforce a retention schedule for clickstream and app-event data. "Indefinite for model training" is a purpose and retention failure that a DPIA should already have caught. Implement deletion or documented justification per dataset.
- Introduce tiered vendor due diligence so the 23 unreviewed vendors are assessed by data volume and sensitivity rather than all at once.
Defer policy rewrites. Fund the technical cookie fix, external legal advice on notifiability, and deletion automation. Record residual risks with owners and dates.
2. What documented information must exist at the end of implementation, and who should own each item?
Read the worked answer
Group it by the question it answers, then assign owners.
How we decide and govern: privacy policy approved by top management; roles and responsibilities including the DPO's position and independence; PIMS scope statement; risk assessment methodology and criteria; risk treatment records; statement of applicability with Annex controls and justifications; objectives and plans; management review records. Owner: DPO with the PIMS lead.
What we process and why: processing register per role with purposes, lawful basis, recipients, transfers and retention; DPIAs for high-risk processing such as profiling and cookie-based tracking; legal obligations register; contracts and DPAs including sub-processor lists. Owner: DPO for register and DPIAs, procurement for contracts.
How we operate controls: consent configuration evidence and consent/withdrawal records; retention schedule with deletion evidence; access control and minimisation evidence for PII systems; vendor due diligence records; training and competence records; change management and privacy review records. Owners: marketing operations, IT operations, procurement, HR.
How we respond: data subject request procedure and log; breach and incident procedure with a breach register and notification decisions; complaint handling. Owners: customer service lead and the incident manager.
How we check: internal audit programme and reports, monitoring metrics, nonconformity and corrective action records. Owner: the audit lead.
An auditor will ask not only whether each exists but who approves it and when it was last exercised, so pair each artefact with an owner, an approver and a review frequency.
3. The cookie vendor calls the pre-consent setting "a technical limitation". How should the implementation team handle this, and what evidence would satisfy an auditor?
Read the worked answer
Treat it as a supplier problem and a decision to be made, not a fact to be accepted.
Options, in order: switch on the platform's consent-mode or geolocation gating; replace the tags with ones that respect consent signals; use a server-side or first-party implementation; or as an interim, disable analytics for the affected countries. Accepting the limitation is a risk acceptance decision that needs an owner, a rationale, an expiry date and a compensating measure - not a line in a vendor email.
Evidence an auditor will look for:
- A before-and-after tag audit showing which tags fire and when, with timestamps.
- Test results from a clean browser in each of the four countries showing no analytics cookies before interaction.
- Consent records: what was shown, what was accepted or refused, and how withdrawal is handled.
- The vendor contract clause requiring compliance and the change record for the fix.
- If there is an interim risk acceptance: the register entry, the approver, the residual risk and the remediation date.
Why this matters more than the paperwork: consent controls are assessed on operating effectiveness. A policy saying "we obtain consent" alongside a tag that fires on page load is worse than no policy, because it demonstrates that the control is not monitored. Update the DPIA and the risk register as part of the same change.