Delaware Just Raised Your Cyber Risk (981)

A new Delaware Supreme Court ruling in Travelers vs. Blackbaud dramatically increases cyber liability exposure for SaaS providers and MSPs after a breach, especially when they host or manage sensitive data for many customers. Hello friends, Uncle Marv here, and this is the IT Business Podcast, where IT professionals and managed service providers come to cut through the noise, fix what's not working, and build a business that actually runs the way it should.

Well, hello everyone. Today we're talking about a Delaware Supreme Court decision that quietly rewrites the cyber liability playbook for SaaS platforms and MSPs like you and me. The case is Travelers vs. 

Blackbaud and comes out of a ransomware attack against Blackbaud that hosted sensitive donor and financial data for nonprofits and educational institutions. Now, what this means for us, if you host data, manage backups, secure remote access, or provide any kind of managed service, this ruling effectively raises the legal stakes every time you have a security incident. Now, this started in Delaware, but, you know, believe you me, this is going to start spreading throughout.

So here's what happened. Blackbaud was hit by ransomware that exposed their sensitive personal and financial information belonging to customers. Those customers ran their own investigations.

They hired their own forensics, paid lawyers, and handled notifications, then turned around and made claims on their cyber policies. So the insurers paid out millions, then sued Blackbaud to recover those costs, arguing that breach of contract, because the platform security controls were not up to par. Now, a lower court had tossed the case twice, but this went all the way to the Delaware Supreme Court.

They reversed the decision and said, nope, these claims can go forward, and that's the pivot point that every MSP needs to pay attention to. So some big legal shifts are coming. The first big shift is that aggregated claims are now fair game, and the court is allowing insurers.

Now, this is, again, the insurers, not even the customers themselves. This ruling allows the court, or allows the insurers, to bring claims on behalf of 97 customers using common allegations. They don't have to break out individual pleadings at the start of the case.

For you as a provider, for us as a provider, that means one bad incident can turn into consolidated litigation across dozens or even hundreds of clients. So, of course, that means larger potential damages and a lot more settlement pressure. Now, the second shift is something I don't quite understand.

It's called proximate cause, and I'm hoping that the legal attorneys in our space will help me explain that at some point or explain it to me. But proximate cause is a link between a specific contract clause and a specific dollar of damage. So that is no longer a stopping point at the motion-to-dismiss stage.

So the court basically said causation is a fact question. As long as the complaint makes a reasonable connection between your security failures and their response costs, the case moves forward into discovery. So translation, your chances of getting a cyber case thrown out just went down, and your chances of slogging through expensive discovery just went up.

So one of the terms that they are redefining is a term that actually I just started using this, but not in this form, but commercially reasonable. I use this for response times, but in this case, apparently the term commercially reasonable security was a phrase that was in a contract. So courts are no longer letting you hide behind fuzzy terms without looking at what you actually do.

So in this decision, the court zeroed in on specific alleged failures that sound a lot more like a minimum security baseline, and they listed all of the things here. So here we go. Let's see.

Obsolete and unpatched servers. No MFA, especially on remote or admin access. Lack of encryption for sensitive data.

Ignored internal security warnings. Weak access controls. Excessive data retention.

Delayed patching and poor incident response planning. Now, that sounds like a long list, and that all falls under what we've historically called best practices. You know, MFA, encryption at rest and in transit, patch management, blah, blah, blah.

So those are now being treated as the legal standard of care. So if you're not doing these things and documenting them, you're not just behind on security. You're potentially below what a court will view as a baseline, quote, reasonable security for a modern MSP or SAS provider.

So on the cost side now and the insurance implications, because of the ruling, more cyber cases will survive early dismissal, meaning we're going to hear a lot more. They're going to move into discovery, and they're going to require forensic analysis, expert witnesses, and contract-by-contract review. So for SMSPs, that means higher defense costs, even if a case is weak.

It means higher cyber insurance premiums, and it's going to be more aggressive attempts by carriers who want their money back. I work with insurance defense firms, and insurance companies do not play. So for our clients, this gives them stronger legal footing to pursue recovery, more leverage in vendor disputes, and more negotiating power on settlements.

So the practical result is a world where if you experience a breach, you should expect to litigate. It is going to be long. It is going to be expensive, and all of this is going to be unless you've done a good job on both your security and your contracts.

So there was another key theme that I saw here. The court did not like Blackbaud's attempt to push most of the incident response work onto its customers. So Blackbaud had provided a generic incident response toolkit, and that's in quotations.

They told customers to investigate and notify on their own and largely left them to handle remediation. So the court viewed that approach negatively and signaled that providers can't simply say, here's a PDF, good luck, especially when their platform is the root cause of the incident. So if you're storing data, if you're doing all of this stuff, you can't just let them go it on their own.

So if your contracts or practices delay disclosure, provide incomplete information, or offload response tasks to clients without providing them real support, you may actually be strengthening the argument that your conduct caused their cost. So what do we need to be fixing in our contracts? And all of these are going to be hopefully practical steps. Again, I'm going to ask for some of the legal people in our industry to help, but obviously we're going to, as a first thing, revisit our security commitments in our MSAs and SOWs.

We need to start replacing vague terms like industry standard and commercially reasonable with specific controls. And where it's appropriate, we need to reference frameworks like NIST, ISO 27001, or CIS controls. Next, we need to look at our limitation of liability clauses, make sure that they are clear, make sure they are enforceable caps, and consider cyber-specific carve-outs and think about how to handle consequential and indirect damages for security incidents.

Third, tighten the incident response obligations. So it can't be a cookie-cutter template anymore. We've got to spell out who does what.

And that pertains to investigation, who does the notifications, who does the remediation, who does all of the communications, along with timelines and how costs will be allocated. And my gut tells me that a lot of this is going to fall more on us than it is the customers. The fourth thing in here I saw was we've got to define data retention.

One of the things that was noted earlier is that they said extended data retention. So apparently when you're not supposed to have old documents, you're supposed to get rid of them. So limit how long you keep sensitive data.

That comes with proper retention schedules. And if this can be automated, great, but make sure you're not sitting on any unnecessary liability. And last, make sure your insurance lines up with this new landscape.

Check your limits. Understand your carrier's rights. It's a term called subrogation, which, again, is, you know, how aggressively they're going to come after us or deny claims.

And then, of course, coordinate with legal counsel who understands MSP risk. Now, on the technical side, that's just on the organization side, but on the technical side, all of this should be a checklist of what the courts expect. I'm going to have the full PDF as a download.

I'm going to put a link in the show notes, and then I'm going to make this a permanent link on the downloads page on the IT Business Podcast website so that you can go look at it. But here's the stuff that I took out of it just to give you an idea. The checklist should include things like locking in MFA everywhere that it matters.

Of course, we all know about remote access, but MFA on admin accounts and any portal or RMM that can touch a customer's environments. Another thing on there, encrypt sensitive data at rest. A lot of us will do it in transit, but we've got to do it at rest wherever it is stored or transmitted, including backups and third-party services that we depend on.

Next, strengthen your patch management, vulnerability scanning, and change management processes. We've got to be able to document timely remediation. When something like this happens, let's see, implement network segmentation and access controls that limit lateral movement across environments.

Something we know we've got to do, but it's not just for the customers. It's also for our own management tools. Let's see here.

Invest in logging, monitoring, and detection. That means we might need to do SEM, SOC as a Service, or a better configured stack, and make sure logs are retained long enough to support investigations. The big thing here, build and test a formal incident response plan that includes clear customer communication, forensic partners, legal coordination, and a very clear playbook for different types of incidents.

And practice data minimization. So only collect and keep what is truly needed for the business, because as Delaware just showed, you are legally responsible for the data you chose to hold. There's a lot more in there.

Again, I'm going to have the full PDF available as a download both in the show notes and on the webpage. But here's the bottom line. The Delaware Supreme Court has made it easier for customers and insurers to pursue MSPs and SAS providers after a breach and made it harder for providers to hide behind vague contracts and minimalist security.

So the new reality is, if you experience a breach, expect to litigate. Again, it's going to be long, it's going to be expensive, unless you've already done the hard work on security contracts and documentation. For customers, the message is also clear.

Customers now have a stronger legal footing to recover incident response costs from the providers and the vendors. And that means our vendors. So they can now go after our vendors.

We may try to push the response up, but that's going to probably affect us just as much. So we need to use that leverage to demand better security and clearer contracts. So my challenge to everyone is, of course, let me know what you think about this.

Pick one area, contracts, security controls, or incident response planning. Schedule a working session with your team to tighten it up before a court or an insurer forces the issue for you. That is going to do it for today.

I want to thank you for listening to the IT Business Podcast. Hopefully this will be the show that helps you run a smarter, stronger MSP without the fluff. If you got value from today's episode, be sure to subscribe, share it with another IT pro, and check out the show notes for links and resources to help you level up your business.

So until next time, keep your tickets short, your margins high, and your clients happy. We'll see you soon. Holla! ♪♪♪♪