When the National Association of Insurance Commissioners (NAIC) detected unauthorized access through a zero-day vulnerability in Oracle PeopleSoft on June 11, they faced a scenario that exposes common failures in enterprise security programs. The breach itself wasn't extraordinary. What matters is how predictable the mistakes were.
Zero-day vulnerabilities strip away the illusion of control. You can't patch what you don't know exists. But the real damage in these incidents rarely comes from the initial exploit. It comes from what you failed to do before the vulnerability existed, and what you do wrong in the hours and days after detection.
Here are the mistakes that turn containable incidents into reputation-damaging events.
Why These Mistakes Keep Happening
Zero-day incidents create perfect conditions for organizational failure. You're under time pressure, with incomplete information, facing a threat you couldn't have prevented through normal controls. This environment amplifies existing weaknesses in your program.
Most organizations treat zero-day risk as a vendor problem. When the breach happens, they discover it was actually a governance problem, a communication problem, and an operational resilience problem. The vulnerability was just the entry point.
Mistake 1: Treating Vendor Software as a Black Box
You're running Oracle PeopleSoft, SAP, Workday, or another enterprise platform. It handles sensitive data. You assume the vendor's security team is monitoring for threats and pushing patches. You're not actively tracking what data flows through these systems or mapping their connections to your critical processes.
Why it happens: Enterprise software vendors ship security updates regularly. Your team interprets this as "the vendor has it covered." You focus your threat modeling on custom applications and infrastructure you control directly.
The real consequence: When NAIC's PeopleSoft environment was compromised, the attacker used it as a pivot point to reach data storage areas. The platform wasn't isolated. It had access to credit rating data, financial reporting information, and configuration details. Nobody had mapped these data flows or implemented compensating controls around a system they considered "vendor-managed."
The fix: Run a data flow analysis for every third-party platform that touches regulated or business-critical information. Document what data enters the system, what it connects to, and what would be exposed if the platform were fully compromised. Then implement network segmentation and access controls that assume the platform will be breached. This isn't vendor risk management. This is architecture.
Mistake 2: Confusing Detection Speed with Response Readiness
NAIC detected the breach on June 11 and disclosed it publicly on June 17. Six days sounds reasonable. But detection is only the start of your timeline problem.
Why it happens: Your security team measures success by how fast they detect anomalies. They've invested in EDR, SIEM, and threat hunting. They catch the intrusion quickly and feel competent. Then they realize they don't have clear authority to take systems offline, no pre-approved communication templates, and no documented process for determining what data was accessed.
The real consequence: The six days between detection and disclosure weren't spent investigating. They were spent figuring out who needs to approve what, drafting legal language, and arguing about timing. Meanwhile, the attacker's access was "promptly contained" according to NAIC's statement, but online invoice payment via PeopleSoft remained unavailable weeks later. Fast detection didn't prevent operational disruption.
The fix: Your incident response plan needs decision trees, not just procedures. Document who has authority to disable systems (by name and role, with backups). Pre-write disclosure templates for your three most likely breach scenarios. Run a tabletop exercise where you simulate the six hours after detection and identify every decision point that currently requires a meeting. Then eliminate those meetings by documenting the answers in advance.
Mistake 3: Discovering Your Dependencies During the Incident
NAIC had to suspend assigning designations to insurer investments because credit rating agencies paused their data feeds after the breach. This is a regulatory function. It affects the entire insurance industry. And nobody knew it was at risk until the breach happened.
Why it happens: You document your critical business processes. You even map them to supporting systems. But you don't test what happens when those systems go dark, and you don't inventory the external parties who will cut off access the moment you disclose a breach. Your business continuity plan assumes you control the recovery timeline.
The real consequence: Your operational recovery isn't determined by how fast you rebuild systems. It's determined by how fast third parties trust you again. NAIC had to "meet with credit rating providers and provide third-party assurances that our systems are secure" before resuming normal operations. That's not a technical problem. That's a trust problem, and you can't patch trust.
The fix: Identify every external party that feeds you data or accepts data from you. For each one, document their likely response to a breach disclosure (will they pause the feed? require an audit? demand contractual changes?). Then build response playbooks that include stakeholder communication and trust restoration, not just system recovery. Your RTO isn't real if it doesn't account for third-party decisions you don't control.
Mistake 4: Treating "Not Compromised" as a Win
NAIC's update carefully listed what wasn't compromised: personal information, payment data, producer information, and several regulatory systems. This is good crisis communication. But it reveals a deeper problem.
Why it happens: You're relieved that the worst-case scenario didn't happen. The attacker didn't get customer PII. They didn't access payment systems. You frame this as evidence that your controls worked. You miss the fact that they still got in, moved laterally, and accessed data you didn't expect them to reach.
The real consequence: You declare victory and return to normal operations without understanding why the attacker's access was limited. Was it your segmentation controls? Or did the attacker simply not explore those systems? NAIC confirmed the attacker "did not take" certain information based on outside cybersecurity experts' findings. That's forensic confirmation, not architectural confidence.
The fix: After every incident, document not just what was compromised, but what could have been compromised if the attacker had taken different actions. Map the full blast radius. Then ask: did our controls limit the damage, or did we get lucky? If you can't answer that question with architectural evidence, you haven't learned from the incident.
Mistake 5: Coordinating with the FBI Without Coordinating Internally
NAIC noted that "FBI coordination is underway." This is standard for incidents affecting regulated entities. But FBI coordination often becomes a substitute for internal accountability.
Why it happens: Once law enforcement is involved, your legal team advises caution about internal communication. You limit the circle of people who know details. You wait for the investigation to conclude before doing thorough lessons-learned. The incident becomes something that happened to you, not something you're responsible for preventing next time.
The real consequence: Your security team doesn't get the forensic details they need to improve detections. Your engineering team doesn't understand what architectural changes would have limited the blast radius. Your business leaders don't connect the operational disruption to specific security decisions. The incident becomes a story about an external threat, not a catalyst for program improvement.
The fix: Separate your legal/investigative timeline from your internal learning timeline. You can coordinate with law enforcement while still running an internal post-incident review that focuses on control failures, not attacker attribution. Document what you could have done differently with the information and tools you had. Share those findings with the teams who can act on them, even while the investigation continues.
Prevention Checklist
Before the next zero-day incident, verify you can answer these questions:
- For each enterprise platform handling sensitive data, have you documented what it connects to and what would be exposed if fully compromised?
- Can you disable a critical system without a meeting? Who has that authority, and do they know they have it?
- Have you identified which external parties will pause data feeds or access after a breach disclosure, and do you have communication plans for each?
- Does your incident response plan include stakeholder trust restoration, or only technical recovery?
- Can you map the full blast radius of a breach based on architecture, not just forensic findings?
- Do you run internal post-incident reviews on a different timeline than legal/investigative processes?
Zero-day vulnerabilities will continue to exist. Your program's maturity isn't measured by whether you get exploited. It's measured by whether you've eliminated the predictable mistakes that turn an exploit into an organizational crisis.
