Your security team just confirmed unauthorized access to customer data. You don't yet know how many records, which fields, or whether the attacker is still in your environment. The clock on your 72-hour notification obligation under GDPR Article 33 is already ticking. Do you report now with incomplete information, or wait until your forensics team finishes their analysis?
This isn't a hypothetical exercise. Booking.com reported a breach to the Dutch privacy regulator 22 days late and paid €475,000 for that delay. The breach itself exposed booking details, names, emails, addresses, and phone numbers. The late reporting, not the breach itself, triggered the penalty.
The Case for Immediate Reporting
The regulatory position is clear: Article 33(1) requires notification "without undue delay and, where feasible, not later than 72 hours after having become aware of it." The language "where feasible" doesn't mean "when convenient" or "when we've finished investigating." It means you report what you know, when you know it.
Practitioners who favor immediate reporting point to three practical advantages. First, you're compliant. The 72-hour window starts when you become aware of the breach, not when you've quantified it. Missing that window means you're explaining your delay to a Supervisory Authority who's already skeptical.
Second, early reporting gives you credibility. If you notify within 72 hours and submit updates as your investigation progresses, you're demonstrating good faith. You're treating the regulator as a partner, not an adversary you hide from until forced to engage.
Third, you control the narrative. If affected individuals learn about the breach from a third party before you've notified them or the regulator, you've lost the ability to frame the incident. Your delayed notification looks like concealment, even if it was just caution.
Modern breach response doesn't require complete forensics before notification. You can report under Article 33(4) that you're providing information "in phases" as it becomes available. Your initial notification describes the nature of the breach, approximate number of affected individuals, and your immediate containment measures. You don't need final counts or root cause analysis.
The Case for Thorough Investigation First
The counter-argument isn't about ignoring the 72-hour requirement. It's about what "becoming aware" actually means in a complex technical environment.
Consider a scenario where your monitoring system flags anomalous database queries. Is that awareness of a personal data breach? Or is it awareness of suspicious activity that requires investigation? If you report immediately and then discover the queries were from an authorized penetration test, you've filed a false breach notification. If you wait to confirm and miss 72 hours, you're non-compliant.
Practitioners who favor investigation-first point to the reputational risk of premature notification. Once you've told your Supervisory Authority that customer data was accessed, that information enters official records. It may become public. If your subsequent investigation reveals the access was contained or the data was encrypted and unusable, the damage to customer trust is already done.
There's also a practical communication challenge. If you notify affected individuals before you understand the scope, you can't answer their basic questions. "What data was accessed?" becomes "We're still investigating." "Should I cancel my credit card?" becomes "We don't know yet." That uncertainty often causes more harm than a slightly delayed but complete notification would have.
The forensics timeline matters here. Booking.com's 22-day delay suggests they prioritized understanding the full scope over speed. That choice cost them €475,000, but it also meant their customer notification could specify that financial information wasn't accessed. That's valuable reassurance you can't provide if you report on day one.
Where Practitioners Actually Land
Most privacy officers adopt a hybrid approach: report within 72 hours with whatever information you have, but front-load your investigation to gather the essential facts first.
This means your incident response plan needs to answer three questions within the first 24 hours: What categories of personal data were accessed? Approximately how many individuals? What immediate containment measures did you take? You don't need exact counts or root cause. You need enough information to meet Article 33's minimum notification requirements.
The key is distinguishing between "we're still investigating" and "we don't know anything." The former is acceptable if you can describe what you do know. The latter suggests you haven't started investigating, which is itself a compliance failure.
Your breach register becomes critical here. You're documenting when you first detected the anomaly, when you confirmed unauthorized access, when you determined personal data was involved, and when you reported. That timeline proves you acted without undue delay, even if you didn't report within the first hour.
Our Take
Report within 72 hours, but treat the first 48 hours as your investigation sprint. The regulatory framework anticipates phased reporting. Article 33(4) explicitly allows you to provide information "without undue further delay" as you learn it. Use that provision.
The Booking.com penalty demonstrates what happens when you confuse "thorough investigation" with "delayed reporting." Twenty-two days isn't investigation time. It's avoidance. But reporting on day one with zero information isn't compliance either. It's panic.
Your incident response plan should specify decision points: By hour 12, confirm whether personal data was accessed. By hour 24, estimate the number of affected individuals. By hour 48, determine whether notification to individuals is required under Article 34. By hour 72, submit your initial notification to the Supervisory Authority with a commitment to provide updates.
This approach protects you legally while giving your forensics team the time they need to work. You're not choosing between speed and thoroughness. You're recognizing that the first 72 hours require speed, and the weeks that follow allow for thoroughness. Booking.com's mistake was reversing that priority.
