The Italian Data Protection Authority's EUR 180,000 fine against Emirates highlights a common compliance gap: you're collecting data lawfully, but you can't explain why in plain language. Although Emirates' health data collection was legal, penalties were issued for unclear processing notices and excessive retention periods. Your privacy notices likely have similar issues.
This playbook guides you in addressing transparency and retention issues before they lead to enforcement actions.
Why This Matters Now
You're violating Article 13 of the General Data Protection Regulation if your data subjects can't easily determine whether they need to provide specific information, what you'll do with it, or how long you'll keep it. The Emirates case shows regulators distinguish between lawful collection and transparent collection. You can have legal grounds under Article 6(1) or Article 9 and still face fines if your processing notices fail Article 5(1)(a) transparency requirements.
Supervisory authorities now scrutinize whether your privacy information is "clear, complete and transparent" enough for data subjects to make informed decisions before providing data. If passengers couldn't determine in advance whether their medical condition required completing a form, your customers probably can't figure out your processing requirements either.
What You Need Before Starting
Before you rebuild your transparency documentation, gather:
- Current privacy notices and data collection forms across all channels (web, mobile, paper, API)
- Data inventory with retention periods for each processing activity
- Legal basis documentation showing why you process each data category under Article 6(1) or Article 9
- Cross-functional team access: legal counsel, product owners who control collection points, records management lead, and someone from customer service who fields data subject questions
- Processing register (Article 30 records of processing activities)
You'll need edit access to every system that collects personal data and displays privacy information. If you can't modify notice text without a three-month development cycle, start that conversation now.
Step-by-Step Implementation
Phase 1: Audit Current Transparency Gaps
Start where data subjects start. Open your website as if you're a customer.
Map every collection point: Create a spreadsheet listing each form, checkout flow, account creation page, and API endpoint that collects personal data. For each entry, document:
- What categories of data you collect
- What the current privacy notice says (copy exact text)
- Where the notice appears (inline, footer link, modal)
- Whether it's shown before or after collection
Test the clarity standard: For each notice, answer these questions as if you're the data subject:
- Can I determine in advance whether I must provide this data?
- Do I know exactly what you'll use it for?
- Can I identify how long you'll keep it?
- Is the legal basis stated in plain language?
If you answered "no" to any question, flag that notice for revision. The Emirates decision shows supervisory authorities expect data subjects to make these determinations "easily" and "in advance."
Phase 2: Fix Transparency in Privacy Notices
Rewrite flagged notices using this structure for each processing activity:
Purpose statement (Article 13(1)(c)): Replace vague terms with specific purposes. Write: "We collect your medical information to assess whether you can safely fly and to arrange appropriate assistance during your journey."
Legal basis identification (Article 13(1)(c)): State the specific Article 6(1) or Article 9 condition. Write: "We process this health data because it's necessary to protect your vital interests during air transport (Article 9(2)(c) General Data Protection Regulation)."
Retention period (Article 13(2)(a)): Replace "as long as necessary" with specific timeframes tied to purpose. Write: "We retain medical fitness assessments for 90 days after your flight to address any post-travel medical inquiries, then delete them."
Criteria for determining retention (Article 13(2)(a)): If you can't specify exact periods, explain the criteria. Write: "We keep assistance requests until your return flight plus 30 days to handle any service issues, unless regulatory requirements mandate longer retention for specific incident types."
Conditional requirements: If only certain data subjects must provide information, state the criteria upfront. Write: "You must complete this medical form if you: require oxygen during flight, have a communicable disease, recently had surgery affecting mobility, or need a stretcher."
Phase 3: Align Retention Periods with Purpose
The Emirates case found seven years excessive for fitness-to-fly assessments. Apply this test to your retention schedule:
For each data category, document:
- Primary processing purpose
- Minimum retention needed to fulfill that purpose
- Any legal obligation requiring longer retention (cite specific regulation and provision)
- Current retention period
Identify excessive retention: Where current retention exceeds purpose-based minimum and you can't cite a legal obligation, you're violating Article 5(1)(e). The gap between "we might need this someday" and "we must keep this to comply with [specific regulation]" is where fines happen.
Set defensible periods: Retention must be "no longer than necessary" for the stated purposes. For passenger assistance data, consider: flight duration plus time to resolve immediate post-flight issues. For transaction records, check whether financial regulations impose minimums. For marketing consent, retain only while consent is active.
Update your Article 30 register: Add the new retention periods and deletion criteria to your records of processing activities.
Phase 4: Implement Deletion Workflows
Transparency means nothing if you don't actually delete data when the period expires.
Create deletion triggers: For each retention period, set up automated deletion or manual review prompts. If you retain medical forms for 90 days post-flight, configure your system to flag records on day 91.
Document exceptions: When legal hold, litigation, or regulatory investigation requires keeping data past normal retention, document the exception with: reason, legal basis, review date, and who authorized the hold.
Test deletion: Before going live, verify deletion actually removes data from backups, logs, and downstream systems. Many organizations "delete" from production databases while retaining copies in backup archives indefinitely.
Validation: How to Verify It Works
User Testing
Ask five people outside your privacy team to review your revised notices and answer:
- What will we use your data for?
- How long will we keep it?
- Do you have to provide this information?
If they can't answer correctly, your notice isn't clear enough yet.
Technical Verification
- Spot-check deletion: Three months after implementing new retention periods, query your database for records that should've been deleted. If they're still there, your deletion workflow failed.
- Audit notice deployment: Verify every collection point displays the updated privacy information. Check web forms, mobile apps, paper forms, and API documentation.
- Review Article 30 register: Confirm retention periods in your processing register match what's published in privacy notices and configured in deletion workflows.
Regulatory Perspective Test
Read your revised notices as if you're responding to a Data Subject Access Request. Can you explain, for each data element:
- Why you collected it (specific purpose)?
- What legal basis permitted collection?
- When you'll delete it?
If you'd struggle to answer a subject access request about any field you're collecting, your transparency documentation still has gaps.
Maintenance / Ongoing Tasks
Quarterly notice review: Every 90 days, verify privacy notices still match actual processing. When product teams add new data fields or change retention logic, notices must update simultaneously.
Annual retention audit: Once per year, review whether your retention periods still align with processing purposes. Business needs change; retention schedules must adapt.
Monitor enforcement trends: Subscribe to your supervisory authority's decision summaries. When regulators issue guidance on transparency or retention in your sector, assess whether it affects your practices.
Train product and engineering teams: Developers who build data collection forms must understand Article 13 notice requirements. Make "privacy notice updated" a required step in your feature launch checklist.
The EUR 180,000 Emirates fine came from gaps you can fix in weeks, not from fundamental compliance failures. Your data collection might be lawful, but if data subjects can't easily understand what you're doing with their information, you're one complaint away from the same enforcement action.
