When Oracle Health reported that its Cerner breach affected 20 million people, many data governance teams dismissed it as a processor issue. But if you're managing an acquisition, a cloud migration, or inherited systems from a merger, you're facing the same risk. The myths around legacy system security and third-party oversight have real consequences, and this breach exposes several of them.
These myths persist because they're comforting. It's easier to believe that modern cloud infrastructure automatically solves security problems, or that breach notification timelines are flexible, or that processor contracts shift all the risk. But the Cerner incident shows how dangerous these assumptions become when you're responsible for millions of personal data records.
Myth 1: Cloud Migration Deadlines Are Flexible
Reality: Every day legacy systems remain active, you're extending your attack surface.
The Cerner breach involved legacy servers that hadn't been migrated to Oracle Cloud when threat actors used stolen credentials to access them. The intrusion began in January 2025 but wasn't detected until February 2025. That detection delay matters, but the real vulnerability was the decision to leave patient data on systems awaiting migration.
You can't treat migration timelines as aspirational. If you've acquired a company or inherited systems through a merger, create a hard cutover date and resource it properly. Legacy systems don't just carry technical debt; they carry compliance risk under Article 32 of the GDPR, which requires appropriate technical and organizational measures. A system you know is outdated and plan to replace doesn't get a pass on appropriate technical and organisational measures until you actually replace it.
Map every data flow involving legacy infrastructure. Identify which systems hold personal data, what lawful basis applies to that processing, and whether you can justify the security posture of those systems during the transition period. If you can't, you need to either accelerate the migration or implement compensating controls immediately.
Myth 2: Breach Detection Speed Doesn't Affect Notification Obligations
Reality: The 72-hour clock under Article 33 starts when you become aware of the breach, but "awareness" has a specific meaning.
Oracle detected the Cerner intrusion in February 2025, roughly a month after it began. The breach was reported to HHS on June 17, 2025, initially with a placeholder estimate of 501 patients. The actual figure disclosed to state regulators reached 20 million people, including nearly 3 million Texans.
That gap between detection and accurate reporting reflects a common problem: you discover an incident, but you don't yet know its scope. Under GDPR, you must notify your supervisory authority within 72 hours of becoming aware of a personal data breach likely to result in a risk to rights and freedoms. The notification can be phased if you don't have complete information, but you can't delay the initial report while you investigate scope.
Build your incident response plan around partial information. Your first notification will include what you know: the nature of the breach, approximate number of affected data subjects (even if it's a range), and the likely consequences. You can supplement that notification as you learn more. What you can't do is wait until you have perfect information before you report anything.
Myth 3: processor Contracts Transfer Data Breach Risk
Reality: You remain the controller, and Article 82 liability doesn't disappear because you outsourced the processing.
Oracle acquired Cerner in 2022 for $28.3 billion. Healthcare systems using Cerner's EHR became Oracle's customers, but those healthcare systems remained controllers for their patients' data. When the breach occurred, it was the hospitals and health systems that had to issue breach notices to their patients.
If you're using a processor, Article 28 requires a written contract that specifies the subject matter, duration, nature and purpose of the processing, the type of personal data, and the obligations and rights of the controller. That contract should address security measures, sub-processor authorization, and breach notification procedures. But the contract doesn't make the processor liable for your Article 33 notification obligations or your Article 34 duty to communicate breaches to data subjects when there's a high risk.
Review your processor agreements specifically for breach scenarios. Who detects? Who investigates? Who notifies regulators? How quickly does the processor inform you? If your processor takes a month to tell you about an intrusion, you've still violated Article 33 if you then take another week to notify your supervisory authority.
Myth 4: One Breach Notification Covers All Jurisdictions
Reality: Different supervisory authorities and state regulators have different requirements, and you need to track them separately.
Oracle updated breach reports to several state attorneys general, including Texas, South Carolina, and Oregon. Dozens of healthcare systems issued their own breach notices. The HHS HIPAA Breach Reporting Tool still listed the incident with the placeholder figure of 501 patients as of the article's publication date, even as state regulators were reporting 20 million affected individuals.
If you operate across multiple jurisdictions, you're managing multiple notification regimes. GDPR Article 33 applies to your lead supervisory authority and any other concerned supervisory authorities. State breach notification laws in the U.S. each have their own triggers, timelines, and content requirements. HIPAA has its own notification framework.
Create a notification matrix before you have a breach. Map which regulators you'd need to notify for different breach scenarios, what information each requires, and what the deadlines are. Don't assume that notifying one authority satisfies your obligations to others.
Myth 5: Modern Authentication Prevents Credential Theft
Reality: Stolen credentials remain one of the most common attack vectors, even with multi-factor authentication.
The Cerner breach involved threat actors using stolen credentials to access legacy servers. This wasn't a sophisticated zero-day exploit; it was credential compromise, the same vector that's been driving breaches for years.
Article 32 requires you to implement appropriate technical and organizational measures, including pseudonymization and encryption, the ability to ensure ongoing confidentiality, integrity, availability, and resilience of processing systems, and the ability to restore availability and access to personal data in a timely manner. "As appropriate" means you assess the risks and implement controls proportionate to those risks.
Credential-based access to systems holding 20 million patient records isn't appropriate. You need multi-factor authentication, privileged access management, continuous monitoring for unusual access patterns, and regular credential rotation. If you've acquired legacy systems that don't support these controls, that's your signal to accelerate migration or implement network segmentation and additional monitoring until you can.
What to Do Instead
Stop treating legacy systems as someone else's problem. If personal data sits on those systems and you're the controller, you own the risk.
Build a migration plan with fixed deadlines and executive sponsorship. Resource it properly. If you can't migrate immediately, implement compensating controls: network segmentation, enhanced monitoring, stricter access controls, and regular security assessments.
Review your processor agreements for breach notification procedures. Require your processors to notify you within 24 hours of discovering a breach. Make sure the contract specifies what information they'll provide and how they'll support your Article 33 and Article 34 obligations.
Create your breach notification matrix now. Identify every supervisory authority and state supervisory authority you'd need to notify, document their requirements, and build templates that you can populate quickly when an incident occurs.
Test your incident response plan with scenarios involving partial information. Practice making that initial Article 33 notification when you know there's been unauthorized access but you don't yet know how many data subjects are affected.
The Cerner breach wasn't inevitable. It was the predictable result of treating legacy system migration as a technical project rather than a compliance imperative. Your inherited systems won't wait for a convenient migration window to become a breach.
