When the National Association of Insurance Commissioners (NAIC) disclosed a breach in June, the industry's first reaction wasn't panic, it was surprise. Not because a breach happened, but because many practitioners hadn't considered regulatory infrastructure as part of their systemic risk model. This gap reveals a broader problem: mental models around cyber resilience often don't account for dependencies beyond our control.
Here are six myths that persist in risk management circles, each one tested by what happened when a zero-day vulnerability in Oracle PeopleSoft disrupted the system insurers use for statutory financial reporting.
Myth 1: "Our third-party risk program covers regulatory dependencies"
Reality: Your vendor risk assessments likely don't include the NAIC, state insurance departments, or other regulatory bodies your compliance obligations depend on. These aren't vendors, you don't have contracts with them, you can't audit them, and you definitely can't demand SOC 2 reports from them.
The NAIC breach affected the Securities Valuation Office, which assigns NAIC designations that carriers use in statutory financial reporting. When the system went down on June 17, insurers couldn't file for new designations. Some credit rating providers paused their data feeds to the NAIC entirely. The organization suspended assigning new designations beginning June 18.
Your business continuity plan needs a category for "systemic dependencies we don't control." That includes regulatory filing systems, industry utilities, and shared infrastructure. For each dependency, document: what happens if it's unavailable for a week? A month? What's your fallback process? Do you have manual workarounds? The NAIC extended private-rating filing deadlines equal to the outage duration, a practical accommodation, but one you can't assume will happen every time.
Myth 2: "Zero-day vulnerabilities are rare enough that we can treat them as edge cases"
Reality: CVE-2026-35273, the Oracle PeopleSoft vulnerability exploited in this incident, carried a severity score of 9.8 out of 10 and was remotely exploitable without authentication. Oracle didn't publish a security advisory until June 10, meaning the vulnerability had already been actively exploited for at least two weeks before any official mitigation existed.
The NAIC was one of more than 100 organizations worldwide affected by the same campaign, which Mandiant linked to the extortion group ShinyHunters. Roughly two-thirds of the organizations hit were educational institutions, not insurance-sector entities. This wasn't a targeted attack on insurance regulatory infrastructure, it was opportunistic exploitation of a widely deployed enterprise system.
Zero-day vulnerabilities in common enterprise platforms create systemic risk because they affect multiple organizations simultaneously, often across sectors. Your incident response plan should include scenarios where your organization isn't breached, but a system you depend on is, and you have no advance warning, no patch timeline, and no control over the recovery process.
Myth 3: "If regulators get breached, they'll tell us immediately"
Reality: The NAIC detected unauthorized access on June 11 and publicly disclosed it on June 23. That's a twelve-day gap. Industry trade groups, including the National Association of Mutual Insurance Companies, criticized the delay between detection and disclosure.
The timeline matters because insurers were making decisions during that window without full information. Some credit rating providers paused their data feeds to the NAIC shortly after the incident became known, a reasonable precaution, but one that compounded the disruption.
Don't assume timely notification from any entity, including regulators. Build monitoring into your own processes: if a regulatory system you depend on goes offline or behaves abnormally, escalate it internally even if you haven't received official communication. Track your own filing deadlines and system dependencies so you can identify disruptions independently.
Myth 4: "Breach scope claims from threat actors are reliable intelligence"
Reality: ShinyHunters claimed to have obtained 3.1 terabytes of data across more than 105,000 files from NAIC systems. The NAIC's investigation, conducted with outside cybersecurity experts and the FBI, concluded the group didn't gain the scope of access it claimed. ShinyHunters itself later acknowledged an earlier summary of the stolen data had been exaggerated due to AI-generated errors in its own review process.
Threat actors have incentives to overstate their access, it increases leverage in extortion attempts and boosts their reputation in criminal forums. Treat initial breach claims as unverified until you have evidence otherwise. If you're responding to an incident where a threat actor is making claims about data exfiltration, don't anchor your response plan to their statements. Conduct your own forensic analysis.
The NAIC stated the data accessed was limited to statutory financial reporting information already publicly available through state insurance department websites and resellers, along with credit rating agency data covering rating determinations. No personally identifiable information, banking data, policyholder information, or confidential insurer-specific investment portfolio details were accessed. That's a much narrower scope than the initial claims suggested.
Myth 5: "Once systems come back online, the disruption is over"
Reality: Recovery proceeded system by system rather than all at once. As of August 17, the NAIC resumed publishing designations for carriers on its Automated Valuation Service platform (AVS+), which provides details including NAIC designation, review date, pricing, and market indicator information. But status updates for the VISION and STS systems, which insurers use to file security investments for credit-quality review, were still being finalized as of that date.
If your organization was waiting on a designation that depended on VISION or STS, the fact that AVS+ came back online didn't resolve your problem. The extended private-rating deadline approved by the Investment Designation Analysis Working Group is a practical accommodation, but it doesn't mean full restoration.
When a systemic dependency experiences an outage, track which specific functions you need, not just whether "the system" is back up. Different components may recover on different timelines, and your specific workflow might depend on the last piece to be restored.
Myth 6: "Regulatory infrastructure is more secure than commercial systems because it handles sensitive data"
Reality: Regulatory bodies face the same vulnerabilities as any other organization running enterprise software. The NAIC breach stemmed from a vulnerability in Oracle PeopleSoft, a widely deployed platform that many organizations use for HR and financial management. The fact that the NAIC uses it for investment designation assignments doesn't make it immune to the same zero-day exploits that affect educational institutions or corporations.
Regulatory infrastructure often runs on the same commercial platforms, managed by the same types of IT teams, facing the same patch cycles and resource constraints as any other organization. Don't assume it's hardened beyond commercial standards just because it serves a regulatory function.
What to do instead
Start by mapping your regulatory dependencies as you would vendor dependencies. For each system your compliance obligations rely on, filing platforms, designation services, license renewals, document what happens if it's unavailable and what your manual fallback process looks like.
Build incident response scenarios around disruptions you don't control. Practice the communication plan: who needs to know if a regulatory system goes down? How do you confirm the scope of the outage? What decisions can you defer, and which ones require immediate action even without complete information?
Track your own filing deadlines and system dependencies independently. Don't rely on regulatory notifications as your only signal that something's wrong. If a system you use regularly becomes unavailable, escalate it internally and start documenting the impact immediately, you may need that timeline if deadlines need to be extended later.
Finally, treat threat actor claims as unverified intelligence until you have evidence otherwise. Base your response on forensic findings, not on what an extortion group posts in a criminal forum.
