Introduction
When 8.7 million customer records are exposed online, as happened with Manchester Airports Group, the damage extends beyond the breach itself. Criminals can exploit names, email addresses, phone numbers, IP addresses, geographic locations, vehicle registration plates, parking history, and travel bookings, all linked together. This playbook guides you in implementing Article 5(1)(c)'s data minimization principle before your next system launch. Use it to challenge unnecessary data collection, document your decisions, and build systems that collect only what you can justify under your processing purpose. This template provides a structured way to refuse feature requests that unnecessarily expand your data inventory and offers a paper trail to show supervisory authorities your commitment to minimization.
Prerequisites
Before using this playbook, ensure the following:
- Identify your processing purpose. You need a clear, specific purpose statement to determine what's "necessary." For example, "process airport parking bookings and issue confirmation emails" is specific enough to withstand scrutiny.
- Know your lawful basis. Different bases impose different minimization constraints. Consent allows more flexibility but requires explicit opt-in for each purpose. Legitimate interests require balancing your needs against data subject rights. Contractual necessity is the most restrictive, allowing collection only of what's essential to deliver the service.
- Map your current collection. List every field you collect or plan to collect, including hidden fields like IP addresses, user-agent strings, timestamps, and referrer URLs.
The Template
Copy this table into your documentation system. Complete one row for every data element in your collection form, API endpoint, or system integration.
DATA ELEMENT: [Field name or data point]
PROCESSING PURPOSE: [Specific purpose from [Article 6](/glossary/article-6)]
NECESSITY TEST:
□ Can we fulfill the purpose without this element? [Yes/No]
□ If yes, document why we're collecting it anyway: _______________
□ If no, document how this element is used: _______________
RETENTION TRIGGER:
□ Delete when: [Specific event or timeframe]
□ Rationale for retention period: _______________
BREACH IMPACT:
□ Could this element enable identity theft? [Yes/No]
□ Could this element enable convincing phishing? [Yes/No]
□ Could this element reveal sensitive inferences? [Yes/No]
□ If yes to any, document additional safeguards: _______________
DECISION:
□ Collect as-is
□ Collect but anonymize after [timeframe]
□ Collect but pseudonymize immediately
□ Replace with less identifying alternative: _______________
□ Do not collect
APPROVED BY: [Name] DATE: [Date]
REVIEW DATE: [Date]
Example: Vehicle registration plates
Manchester Airports Group collected vehicle registration plates for parking bookings. When that data was exposed, it enabled criminals to craft phishing messages referencing real vehicles at real locations. Here's how the template would challenge that collection:
DATA ELEMENT: Vehicle registration plate
PROCESSING PURPOSE: Verify vehicle identity for parking enforcement and exit validation
NECESSITY TEST:
□ Can we fulfill the purpose without this element? No
□ If no, document how this element is used:
Parking enforcement staff match plate to booking. Exit barriers verify plate against active bookings.
RETENTION TRIGGER:
□ Delete when: 30 days after parking session ends
□ Rationale: Enforcement claims typically arise within 30 days; no legitimate need beyond that period
BREACH IMPACT:
□ Could this element enable identity theft? No
□ Could this element enable convincing phishing? Yes
(Criminals can reference "your vehicle [REG]" in fake parking fine or booking messages)
□ Could this element reveal sensitive inferences? Potentially
(Repeated airport parking suggests travel patterns; could reveal home address via DVLA lookup)
□ Document additional safeguards:
Hash plates immediately after entry. Store only hashed value. Enforcement staff enter plate at barrier; system compares hash. No plaintext storage.
DECISION:
□ Collect but pseudonymize immediately using one-way hash with parking-session-specific salt
APPROVED BY: [DPO] DATE: [Date]
REVIEW DATE: [Date + 12 months]
Customizing the Template
For high-volume consumer systems: Add a "Data Subject Request Impact" section. If you collect millions of email addresses, you'll receive thousands of DSARs. Can you locate and extract this element efficiently? If not, that's another reason to minimize.
For legitimate interests processing: Add a "legitimate interests assessment" section. Document how you weighed your legitimate interest against the data subject's rights. The Manchester breach shows the consequences when that balance tips: historical locations and planned future travel gave criminals ammunition for targeted scams.
For special category data: Add a "Lawful Basis + Article 9 Condition" section. You need both, and your necessity test becomes even stricter. Document why no less intrusive alternative exists.
For cross-border transfers: Add a "Transfer Necessity" section. If this element leaves the EEA, document your Chapter V mechanism and whether you could avoid the transfer by not collecting the element at all.
Validation Steps
Run a collection audit. Pull your last 1,000 records. For each field that's blank in more than 10% of records, ask why you're collecting it. If users regularly skip it, you probably don't need it.
Test your necessity claims. Disable collection of one "nice-to-have" element in a staging environment. Can your system still deliver the core service? If yes, you've failed the necessity test.
Simulate a breach disclosure. Print your data schema and ask: "If this appeared on Have I Been Pwned tomorrow, which fields would enable the most convincing phishing?" Those fields need either stronger justification or pseudonymization.
Review retention triggers quarterly. Manchester Airports Group stored parking history and lounge bookings. Ask: after the customer leaves the car park or boards the flight, what legitimate purpose remains? If you can't answer in one sentence, you're keeping it too long.
Challenge new collection requests with this template. When a product manager requests "phone numbers for better customer engagement," make them complete the necessity test. "Better engagement" isn't a processing purpose. "Send SMS booking confirmations because email deliverability to our customer segment averages 60%" is.
The Manchester breach exposed 8.7 million records because systems collected more than necessary and kept it longer than needed. Your playbook won't prevent every breach, but it will ensure that when criminals do get in, they find less to steal and less to weaponize. That's data minimization as Article 5(1)(c) intended.
