When Manchester Airports Group discovered unauthorized access to customer data from three UK airports, they followed the standard protocol: contain the risk, notify authorities, and contact affected customers. The breach affected approximately 8.7 million customers, exposing email addresses, phone numbers, vehicle registrations, and postcodes. No payment data was compromised, and operations continued without disruption.
If you're thinking, "we'd handle it the same way," you're likely relying on myths that render most incident response plans ineffective when they're truly needed. The gap between your breach response documentation and what actually happens during an incident is where regulatory penalties and reputational damage occur.
These myths persist because they seem reasonable in conference rooms but fall apart at 3 a.m. when your security team is scrambling for answers.
Myth 1: "We have 72 hours to notify the supervisory authority"
Reality: Article 33 requires notification "without undue delay and, where feasible, not later than 72 hours after having become aware of it." This clock starts when you're aware of the breach, not when you've completed your investigation. The 72-hour window is a ceiling, not a target.
You're "aware" when you have reasonable certainty that a personal data breach has occurred. It's not when you know the full scope or when legal has approved the wording. It's when you know something has compromised the confidentiality, availability, or integrity of personal data.
If you wait 72 hours to start drafting your notification because "we have time," you've already violated the "without undue delay" requirement. The ICO and other supervisory authorities expect notification within 24-48 hours in most cases, using the 72-hour mark only when genuine complexity requires it. You can submit an initial notification with incomplete information and follow up with details later, which is almost always preferable to a delayed complete notification.
Your incident response plan should trigger notification drafting immediately upon awareness, not 48 hours into the investigation.
Myth 2: "If we didn't lose payment card data, we don't need to notify customers"
Reality: Article 34 requires direct communication to data subjects when a breach is "likely to result in a high risk to the rights and freedoms of natural persons." Payment card data is one type of high-risk exposure, but it's not the only one.
Email addresses combined with phone numbers and postcodes create substantial phishing and social engineering risk. Vehicle registrations linked to personal contact details enable targeted physical security threats. The combination matters more than any single data point.
The MAG breach exposed exactly this type of combined data, which is why they contacted affected customers directly. Your assessment can't be a checklist of "sensitive" data categories. You need to evaluate: Can this data be used for identity theft? Does it enable convincing impersonation? Could it lead to physical harm, discrimination, or financial loss?
If your breach response plan says "notify customers only if payment/health/biometric data involved," rewrite it. The threshold is risk to rights and freedoms, which supervisory authorities interpret broadly. When in doubt, notify. The reputational cost of a supervisory authority ordering you to notify after you decided not to is far higher than proactive communication.
Myth 3: "Our incident response plan is the IT security team's document"
Reality: Your data protection officer (DPO) needs to own the personal data breach response plan, with IT security as a critical partner. Article 33 notifications go to the supervisory authority from the controller, not from IT. The DPO must be involved immediately, per Article 38's requirement that the DPO be involved in all issues related to personal data protection.
Consider what happened at MAG: they contained the technical risk, informed authorities, contacted customers, and took the Manage My Booking portal offline as a precaution. That's not just an IT response. That's cross-functional coordination between security, legal, customer service, communications, and data protection.
Your plan needs to specify: Who calls the DPO? At what threshold? Who has authority to take customer-facing systems offline? Who drafts the Article 33 notification versus the customer communication versus the public statement? These are different documents with different audiences and different legal requirements.
If your current plan is a network security incident response document with a "notify DPO" step added at the end, you don't have a personal data breach response plan. You have a security plan with a compliance footnote.
Myth 4: "We can investigate fully before notifying anyone"
Reality: The notification obligation and the investigation run in parallel, not sequentially. You report what you know when you know it, then update as you learn more.
Article 33(4) allows you to provide information "in phases" when you can't immediately provide complete information. This means your initial notification might say "unauthorized access detected, scope under investigation, estimated 50,000-100,000 records potentially affected." You then follow up with specifics as your investigation progresses.
Waiting for complete information before notifying is how organizations blow past the 72-hour window. It also delays the supervisory authority's ability to provide guidance or coordinate with other affected authorities if the breach crosses borders.
Your response plan should include notification templates with bracketed sections for "under investigation" information. Draft the structure in advance so you're filling in details, not writing from scratch while managing the incident.
Myth 5: "Turning off affected systems shows we're taking it seriously"
Reality: Taking systems offline is a containment measure, not a communication strategy. MAG disabled their Manage My Booking portal as a precaution, but they clearly explained the impact and provided an alternative (phone-based booking changes) while warning of longer wait times.
The supervisory authority doesn't give you credit for disrupting customer service if it wasn't necessary for containment. Worse, if you take systems offline without communicating clearly, you create confusion that undermines the trust you're trying to preserve.
Your response plan needs decision criteria: Under what circumstances do we take a system offline? Who makes that call? How do we communicate it internally and externally? What's the fallback process?
"Shut everything down" isn't a plan. It's panic. The appropriate technical and organizational measures you're required to maintain under Article 32 should allow you to isolate compromised systems while maintaining service where safe to do so.
What to do instead
Rebuild your personal data breach response plan around three phases: immediate (0-4 hours), acute (4-72 hours), and recovery (72 hours onward).
Immediate phase: Your plan should specify who gets called, in what order, at what time of day. Not "notify the DPO" but "call [name] at [number], if no answer within 15 minutes call [backup]." Include decision trees: If the breach involves [X type of data] affecting [Y number of people], we must notify the supervisory authority. If it involves [Z risk factors], we must notify data subjects.
Acute phase: Draft your Article 33 notification in the first 12 hours, even if incomplete. Prepare customer communication in parallel. These are different documents: the supervisory authority needs technical details and risk assessment; customers need clear explanation and specific steps to protect themselves. Run a single coordination call every 8 hours with DPO, IT security, legal, and communications until the situation stabilizes.
Recovery phase: After notification, you're not done. Document lessons learned. Update your Article 30 records of processing activities if the breach revealed gaps in your data inventory. Review whether your Article 32 security measures were appropriate or need strengthening. Consider whether you need to update privacy notices if the breach revealed processing you hadn't disclosed.
Test this plan annually with a tabletop exercise. Not "what would we do if..." but actually draft the notification, identify who's unavailable, discover which systems you can't access after hours. The goal isn't to have a perfect plan. It's to have a plan you've already broken once in practice, so you know where the gaps are before they matter.
