After reviewing the Privacy Rights Clearinghouse's 2026 midyear report, I joined a working group of DPOs, incident response leads, and compliance managers. We all noticed a troubling trend: reported breach figures often didn't match across filings, leaving many unsure about handling these discrepancies in their reporting obligations.
What began as a discussion about an education platform's unverified claim of 275 million users turned into a broader conversation about processor management, notification accuracy, and your responsibilities when numbers don't align. Here's what we explored.
Q1: We discovered a breach through our processor. Their initial estimate was 50,000 records, but now they're saying it could be 200,000. What do we report to the supervisory authority?
Report what you can verify at the time of notification, and update as you gather more information.
Article 33 requires you to notify your supervisory authority within 72 hours of becoming aware of a personal data breach. This notification must include "where possible, the approximate number of data subjects concerned." The key phrase is "where possible."
If your processor initially estimates 50,000 records, report that number. Indicate in your notification that the investigation is ongoing and the figure may change. When they revise it to 200,000, submit a supplementary notification with the updated count and explain the reason for the change.
Don't delay your initial notification waiting for perfect numbers. The 72-hour clock starts when you become aware, not when you've completed forensics. Document everything: when you learned about the breach, what information the processor provided, when estimates changed, and why.
The DentaQuest incident illustrates what can go wrong. Their HHS filing reported 15 million affected individuals, while their Indiana filing listed 27.4 million. Neither filing explains the 12.4 million difference. If you're the DPO fielding questions about that discrepancy, you're in a difficult position.
Q2: Our processor got hit with a social engineering attack that compromised customer data. Are we liable even though it was their employee who got tricked?
Yes, as the controller, you're responsible under Article 28 for choosing processors that provide sufficient guarantees.
The AdaptHealth breach started with a social engineering attack on a third-party contractor's user session, affecting over 4.1 million people. The Carnival Corporation incident involved an attacker deceiving an employee, compromising about 6 million customer records.
Your processor's security failures are your compliance problem. Article 28(1) requires you to use only processors that provide "sufficient guarantees to implement appropriate technical and organisational measures." If your processor's employees can be socially engineered into handing over access to your data, that's evidence you didn't adequately assess their security posture.
Review your Article 28(3) processor agreements. Do they specify security awareness training requirements? Do they require multi-factor authentication for access to your data? Do they include audit rights that would let you verify these controls are in place?
After a processor breach, your supervisory authority will ask what due diligence you performed before engaging them and what ongoing oversight you maintained. "We trusted them" isn't an answer that survives scrutiny.
Q3: An attacker claims they breached our system and accessed 10 million records, but our forensics team can only confirm 50,000. What number do we use in notifications?
Use the number your investigation supports, but document why you're disputing the attacker's claim.
The Instructure case demonstrates this scenario. The Privacy Rights Clearinghouse identified a Wisconsin filing that recorded 275 million affected Canvas users, but determined this figure came from an attacker claim that hadn't been independently verified. Their analysis of publicly available filings found approximately 18,400 affected individuals, though this didn't establish the full scope.
Your notification obligations under Article 34 are based on what you know, not what an attacker claims. If your forensic analysis shows 50,000 records were accessed, report that number. Include in your documentation that you're aware of the attacker's claim and explain what evidence contradicts it.
However, continue investigating. If you later discover the attacker was right, you'll need to issue updated notifications. The supervisory authority will be more understanding if you can show a thorough investigation that initially found 50,000, rather than dismissing the attacker's claim without proper forensics.
Q4: We're filing breach notifications with multiple state attorneys general. Do the numbers need to match exactly across all filings?
They should match unless there's a legitimate reason for differences, and you need to document that reason.
Look again at DentaQuest: their HHS filing showed 15 million, their Indiana filing showed 27.4 million, and their Texas filing showed 15 million. These filings were dated one day apart. There's no public explanation for why Indiana's count is nearly double the others.
If you're reporting different figures to different jurisdictions, you need a defensible explanation. Valid reasons might include: different state laws define "affected individuals" differently, your investigation uncovered additional affected residents of one state after filing elsewhere, or specific state requirements led you to include a broader category of exposure.
What's not defensible is sloppy record-keeping that produces inconsistent counts because different people prepared different filings without coordinating. Create a single source of truth for your breach count, ensure everyone filing notifications uses it, and document any jurisdiction-specific adjustments.
Q5: Our breach involved a processor that stores archived patient records. Who's responsible for notifying the patients?
It depends on your contract, but ultimately you're accountable as the controller.
The Aesto Health breach affected approximately 9.54 million individuals. Aesto, as a healthcare data migration and archiving provider, notified affected healthcare-provider clients on June 26, 2026. Those organizations were then responsible for determining and carrying out patient notifications.
Your Article 28 processor agreement should specify notification responsibilities. Typically, the processor notifies you, and you notify the data subjects. But if your processor is holding archived records for patients you no longer actively serve, you need clarity on who maintains the current contact information and who bears the cost of notification.
Review your processor contracts now, before a breach. If the contract is silent on notification responsibilities, that's a gap you need to close. The supervisory authority won't accept "we thought the processor was handling it" as an excuse for missing the Article 34 notification requirement.
Q6: We discovered unauthorized access to systems containing driver's license numbers and insurance information. The attacker was in our network for two weeks. Do we need to notify everyone whose data was in those systems, or just people whose records we can prove were accessed?
Article 34 requires notification when the breach is "likely to result in a high risk" to individuals' rights and freedoms. The assessment depends on what information was exposed and what harm could result.
The AssuranceAmerica breach affected nearly 7 million drivers, exposing names, contact information, driver's license numbers, insurance policy information, vehicle details, and claims records. This combination enables identity fraud and impersonation.
If the attacker had access to systems containing this information for two weeks, and you cannot definitively prove which specific records they accessed, the prudent approach is to notify everyone whose data was in accessible systems. The alternative is to notify only confirmed exposures, but you'll need strong forensic evidence showing exactly what the attacker touched.
Document your risk assessment. Consider: What could someone do with this information? How easy would it be to cause harm? How many people are affected? If you decide not to notify certain individuals, your supervisory authority may challenge that decision, so your reasoning needs to be defensible under Article 34(4)'s high-risk threshold.
Where to go for more
Your supervisory authority's breach notification guidance should be your first reference. Many authorities publish templates and FAQs that clarify what they expect in notifications and how to handle common scenarios like evolving breach counts.
The European Data Protection Board's guidelines on personal data breach notification provide the framework for assessing whether a breach requires notification and what information to include. These guidelines explain the 72-hour requirement, what constitutes "becoming aware," and how to handle situations where you're still investigating.
For processor management, revisit Article 28 and your processor agreements. If your contracts don't specify security requirements, notification procedures, and audit rights, you're operating with significant compliance gaps. Address them before the next breach, not after.
