An insurer scoring privacy risk for the company instead of for people
An insurer has 300 documented PII processing activities. Its privacy risk assessment scores each one as likelihood (1-5) multiplied by financial impact on the company (1-5), with anything at 12 or above treated as high. Forty-six activities land in the high band, but only four of them involve sensitive data, and the top-scoring item is a mailing-list error risk worth perhaps EUR 40,000. The 27001 risk register is maintained separately by the security team and contains no privacy entries. Internal audit has raised the same retention finding for three years: customer quotes and call recordings kept indefinitely 'because storage is cheap'. Privacy impact assessments are written by the project manager after go-live and stored in a shared drive with no index. Management review minutes mention privacy once, in 2022.
1. Critique the risk methodology and redesign it, explaining each design choice.
Read the worked answer
The methodology measures the wrong harm. Financial impact on the insurer is one dimension; the harm to the individuals whose data it is - the whole point of a PIMS - is missing entirely. A small fine with severe distress to a vulnerable customer should outrank a larger internal cost with no individual impact.
Redesign:
- Two impact lenses, scored separately, then combined by taking the higher: impact on individuals (physical, material, non-material - discrimination, distress, reputational or financial harm) and impact on the organisation (regulatory, financial, reputational, operational). Taking the maximum rather than the sum stops big-company costs from swamping individual harm.
- Likelihood informed by threat and exposure factors: number of PII principals, sensitivity (health, financial, criminal), vulnerability of the population, number of recipients and transfers, retention duration, and how many people can access the data.
- Score inherent and residual separately, so treatment effect is visible instead of being assumed.
- One framework, two registers or one tagged register shared with the 27001 process, so a security weakness with privacy consequences appears in both views.
- Thresholds reviewed against criteria, not a fixed number: any sensitive-data processing, any large-scale or systematic monitoring, and any new technology automatically get a PIA regardless of score.
Without the individual-harm axis, the register systematically under-ranks exactly the processing a privacy regulator cares most about.
2. With four FTE and 46 high risks, how do you sequence treatment? Give a defensible ordering logic rather than a number.
Read the worked answer
Sequencing logic, applied in order, with the first three filters doing most of the work:
- Ongoing versus contained exposure. Anything currently leaking, sharing or retaining data unlawfully outranks a risk that materialises only if something goes wrong. The indefinite retention of quotes and call recordings is a live, three-year-old, known exposure - it goes first on duration and volume alone.
- Severity of individual harm if it occurs. Sensitive data (health, financial hardship, claims details) and vulnerable populations (claimants in distress, elderly customers) come next, even at a lower financial score.
- Reversibility and cost to fix. Retention automation is cheap and permanent; a re-architecture is not. Cheap, durable fixes get done early because they remove risk from the register permanently.
- Then residual score. Only now use the numbers.
Practically: run a two-week retention purge and deletion job for the call recordings and quotes with legal review of what must be kept; fix the four sensitive-data activities; then work down the remaining high band by residual score with a rolling quarterly review.
Two governance points: the 46 'high' items should be re-scored under the new methodology before any budget argument, because the current band is inflated by the wrong axis; and each treatment needs an owner and a due date, or it will reappear as the same audit finding in year four.
3. What should the PIMS measure and review to show continual improvement, and how would you verify that treatment actually worked?
Read the worked answer
Continual improvement needs evidence that the system learns, not a dashboard of activity.
Measure - a small set that maps to real controls:
- Retention: percentage of processing activities with an enforced, tested retention rule; count of records past their retention date found in a sample.
- Rights requests: volume, percentage answered within the statutory period, percentage requiring an extension, and reason codes.
- PIAs: how many completed before go-live versus after, and how many changed the design - a PIA that never changes anything is theatre.
- Breaches and near misses: detection-to-notification time, split controller-side and processor-side.
- Vendor: percentage of processors with current agreements and a complete sub-processor list.
Review - the PIMS performance-evaluation and improvement requirements should put these in front of management review with a decision log, not just an update. Management review that has not discussed privacy since 2022 is a finding in its own right.
Verify treatment effectiveness by testing, not by asking: sample records after the retention job to confirm deletion; re-run a rights request as a mystery test; audit one PIA trail from ticket to sign-off; and check that internal audit's repeat finding is closed with evidence. Then use internal audit to re-test the fix in the next cycle - a closed action that reopens is a signal that the root cause was governance, not technology.