Strategy
Part of A privacy first measurement strategy that starts with the decision, then the metric
Test four permission states before a privacy first measurement go-live
Run synthetic tests for granted, refused, withdrawn and unavailable permission states in a privacy first measurement design, then write up the results.
A privacy first measurement design is only as sound as its behaviour when a visitor says no. The test phase in the middle of a ninety day plan for an England operation checks what the report does under each permission state. It promises no delivery time, cost, consent rate or performance gain.
What to take away
- Test four permission states with synthetic casesgranted, refused, withdrawn and unavailable.
- Remove any field with no defined purpose before the test begins.
- Confirm what the report shows when data arrives late, duplicates or cannot be joined.
- Where an exception is claimed, test that the visitor's objection route works.
- If a basic report cannot be reproduced, fix the specification before using it in a campaign decision.
Shrink the design before testing
Start by shrinking the design. Remove fields that have no defined purpose, so every field that remains has a purpose to test against. The permission tests then cover only what the design genuinely needs.
The ICO says data protection by design and by default means integrating data protection into processing activities and business practices from the design stage and throughout the lifecycle.
Bring the privacy reviewer in before a tool or tag is chosen, and keep them in through testing.
The ICO's final storage and access technologies guidance covers cookies, pixels, fingerprinting and related methods under PECR and, where relevant, UK GDPR. A qualified reviewer should assess the actual design, including any claimed exception or consent route. The strategy and planning guide covers the decision-first work that comes before this phase.
Write the four permission cases
Write one synthetic case per permission state and fix the expected result before running it. Use fictional visitors only, so no real person's data is needed. Each case needs a starting state, an action and an expected outcome.
| State | Synthetic case | What the report must show |
|---|---|---|
| Granted | A test visitor accepts, then completes the journey | The journey counted once, within the approved purposes |
| Refused | A test visitor refuses, then completes the journey | Nothing recorded beyond what the design allows without permission |
| Withdrawn | A test visitor accepts, withdraws, then carries on | Collection stops at withdrawal, and earlier records follow the stated retention |
| Unavailable | The permission signal cannot be read | A defined fallback, flagged as such, never a silent default to granted |
Add three data-quality cases next: data that arrives late, duplicate records and records that cannot be joined. Confirm what the report shows in each case, and whether it labels the gap instead of hiding it.
Review the results against the quality checklist, which frames the same checks at release level.
Test the objection route
Where the design relies on the statistical purposes exception, test the objection route too. The ICO's exceptions guidance says the statistical purposes and appearance exceptions require a simple means of objecting, free of charge, to the storage or access.
PECR does not define what a simple means of objecting looks like, and it could run through an existing consent mechanism. If no route is offered, the activity is not in line with the exception. Run the objection as a fifth synthetic case and record what stops.
Which measures fit the exception at all is a separate question, sorted in a guide to the statistical exception.
Collect supplier evidence
For software services, collect current evidence for administrator access, logs, incidents, hosting, transfers, sub-processors, export and deletion. NCSC SaaS security guidance warns that services change rapidly and that its material is not an endorsement, so date every piece of evidence.
Keep the evidence in a purpose register beside the test cases. A supplier answer without a date cannot show that the service still behaves the way it did when the case was run. The contract questions cover data roles and exit if a test exposes a gap.
Write the test report
End the phase with a test report showing expected and actual results for every case. Separate observed values, imported records and model outputs. If a basic report cannot be reproduced, fix the specification before using it in a campaign decision.
For each case the report should record:
- The permission state and the starting condition.
- The expected result, written before the run.
- The actual result.
- Any difference and who owns the fix.
Mark unknown routes found during testing as unknowns on the risk list rather than filling them with assumptions. A test that finds an unknown has done its job.
Before you act
- Remove fields that have no defined purpose.
- Write expected results for granted, refused, withdrawn and unavailable states before the run.
- Add late, duplicate and unjoinable data cases.
- Test the objection route if an exception is claimed.
- Date every piece of supplier evidence.
- Separate observed values, imported records and model outputs in the test report.
Common questions
Which permission states should be tested?
Build synthetic test cases for granted, refused, withdrawn and unavailable permission states. Confirm what the report shows when data arrives late, duplicates or cannot be joined.
What if a basic report cannot be reproduced?
Fix the specification before using it in a campaign decision. End the phase with a test report showing expected and actual results, separating observed values, imported records and model outputs.
Who should assess the design?
A qualified reviewer should assess the actual design, including any claimed exception or consent route. The ICO's guidance covers the technologies, but it does not approve a particular implementation.
