When the MOVEit vulnerability exposed almost 96 million individuals globally, the response from affected organizations revealed a troubling pattern: most believed they'd done enough. The resulting litigation, including GRIPA's $2.15 million settlement, tells a different story. These myths persist because they're comforting. They let you believe that compliance checkboxes and vendor contracts shield you from liability. They don't.
Myth 1: "Our vendor contract protects us from breach liability"
Reality: Your indemnification clause won't stop class action lawsuits naming your organization.
GRIPA faced four separate class actions despite using Progress Software's MOVEit solution. The plaintiffs didn't care about contractual relationships between GRIPA and Progress. They sued both. While GRIPA's claims against Progress Software continue, the organization still established a $2.15 million settlement fund to resolve claims against itself.
Your contract might eventually recover costs from your vendor, but that happens years later, after you've already paid legal fees, settlement funds, and notification costs. Meanwhile, your patients or customers are filing Data Subject Access Requests, your board is demanding answers, and your incident response budget is depleted.
The NIST Cybersecurity Framework (CSF) 2.0 addresses this in the Supply Chain Risk Management function, but here's what it doesn't tell you: even perfect vendor contracts won't prevent you from being named as a defendant. You're still the data controller. You're still responsible for choosing that vendor.
Myth 2: "If we follow industry-standard security, we're legally protected"
Reality: Courts define "industry-standard" more strictly than you think, and plaintiffs will argue you failed to meet it.
The MOVEit plaintiffs alleged that affected organizations should have implemented "industry-standard cybersecurity measures and protocols" including software to detect suspicious activity, regular platform audits, IP address restrictions, and file type limitations. Notice what's missing from that list: nothing exotic. These are controls you'd find in ISO/IEC 27001 Annex A or the CIS Critical Security Controls.
The court largely denied Progress Software's motions to dismiss in July 2025, and denied parts of GRIPA's motion in December 2024. Translation: the plaintiffs made a credible case that basic security measures were absent.
You can't claim you met industry standards by implementing some controls. Courts expect defense-in-depth. If you're running a file transfer solution without IP restrictions, without file type validation, and without anomaly detection, you're below the standard, regardless of what your last SOC 2 Type II report said.
Myth 3: "We can rely on our vendor's security certifications"
Reality: Your vendor's SOC 2 report doesn't cover zero-day vulnerabilities or the controls you should layer on top.
Progress Software presumably had security certifications. It didn't matter. The vulnerability was a zero-day, exploited by CL0p before patches existed. Your vendor risk management program should assume this will happen.
What matters is what you did with that third-party solution. Did you segment it? Did you monitor file transfer volumes and patterns? Did you restrict which systems could access it? Did you maintain offline backups that ransomware couldn't encrypt?
NIST SP 800-53 control SA-9 (External Information System Services) requires you to define and document oversight and user roles. That's not about trusting your vendor's security. It's about assuming their security will fail and building compensating controls.
Your vendor risk assessment shouldn't end with "they have SOC 2 Type II." It should end with "here's what we're doing because their controls might not be enough."
Myth 4: "Breach notification is the main legal risk"
Reality: The Health Insurance Portability and Accountability Act notification requirements are just the beginning. Class actions focus on what you failed to prevent.
GRIPA patients had names, dates of birth, Social Security numbers, health information, insurance details, and prescription records compromised. Under the HIPAA Breach Notification Rule and the Health Information Technology for Economic and Clinical Health Act, GRIPA had to notify affected individuals. That's table stakes.
The class actions alleged negligence, negligence per se, breach of contract, and unjust enrichment. These claims don't care whether you sent timely notifications. They care whether you implemented reasonable security before the breach happened.
Class members in this settlement can claim up to $2,500 in ordinary losses and up to $10,000 in extraordinary losses. Compare that to the cost of implementing IP restrictions or file upload validation. The math is brutal.
Myth 5: "Our cyber insurance will cover settlement costs"
Reality: Cyber policies have exclusions, sub-limits, and retention requirements that leave you exposed.
Even if GRIPA had cyber insurance that covered the $2.15 million settlement fund, that policy didn't cover the legal fees to defend four separate class actions, the cost of mediation, the settlement administration and notification costs, or the service awards for class representatives. It didn't cover the reputational damage or the staff time spent responding to the Computer Security Incident Response Team investigation.
Cyber insurance is a risk transfer mechanism, not a risk management strategy. It pays out after you've already failed. Your policy might cover the settlement, but it won't cover the board's loss of confidence in your security program.
And here's what your broker won't emphasize: if the court finds you were grossly negligent, your policy might not pay at all.
Myth 6: "We can address third-party risks during annual vendor reviews"
Reality: Annual reviews don't detect zero-day exploits or active compromises.
By the time CL0p exploited the MOVEit vulnerability in May 2023, your annual vendor review was irrelevant. The attack happened in days. Your contract's requirement for annual SOC 2 reports didn't help. Your vendor's quarterly business reviews didn't mention the vulnerability because they didn't know about it yet.
Continuous monitoring isn't optional anymore. You need real-time alerting on authentication patterns, data exfiltration volumes, and configuration changes. You need to know within hours if your file transfer solution starts behaving abnormally, not during next year's vendor assessment.
ISO/IEC 27001 control 5.19 (Information Security in Supplier Relationships) requires ongoing monitoring of supplier service delivery. That means instrumentation, logging, and alerting, not annual questionnaires.
What to do instead
Stop treating vendor risk management as a compliance exercise. Treat it as an assumption that your vendors will be compromised.
Implement network segmentation that isolates third-party solutions from your core data environment. Configure IP allowlists and file type restrictions on every file transfer solution. Deploy anomaly detection that alerts on unusual transfer volumes or destinations. Maintain offline backups that can't be encrypted by ransomware.
Review your vendor contracts not for indemnification language but for your right to audit, your right to terminate, and your access to security logs. Require vendors to notify you of vulnerabilities within 24 hours, not when they're ready to patch.
Build an Incident Response Plan that assumes your vendor won't tell you they've been breached. Practice scenarios where you discover the compromise through your own monitoring, not through a vendor notification.
And recognize that "industry-standard security" is defined by courts, not by your last audit. If you can't explain why you didn't implement a basic control, you're exposed.
The MOVEit settlements aren't outliers. They're the new baseline for what happens when you trust vendor security without layering your own controls on top.
NIST Cybersecurity Framework
HIPAA Breach Notification Rule
