Cyber insurance: what is it good for?

Red flags to look for when buying, and how to deal with them.

Note: to be crystal clear, this is not a breach / incident notification. It is a debrief of my experience setting up a response plan with my cyber insurance carrier. StackAware publishes incident response notifications on our trust and security center. And as always, this is not legal advice.

TL;DR

• I am skeptical about the value of cyber insurance. I recently purchased it due to new contractual obligations. Now I am even more skeptical of its value.

• Because of this, I advise clients not to weight it too much when vetting vendors.

Here is the timeline of my interaction with the insurance carrier and incident responder:

• July 19 - Insurance policy start date.

• July 30 - Based on this excellent article by Rob Black, I contact my carrier about getting an non-disclosure agreement (NDA) in place with the panel incident response provider. There was only one option allowed by my policy, which looks like a subsidiary or company related to the carrier (thus it was frequently unclear to me whether I was communicating with the carrier or the incident responder). I also asked for their standard operating procedures (SOPs) so I can best prepare for an incident.

• July 31 - The carrier asks to set up a call without providing any information about the NDA or SOPs. I tell them I will talk to them live as long as they can confirm I can get both. I also request whatever they have “off-the-shelf” in terms of onboarding processes, etc.

• August 5 - Carrier tells me panel provider only signs NDAs during an incident. Carrier sends me an M365 email hardening guide despite my primary email provider being Gmail. They also inform me they have an app to request support during an incident.

• August 6 - I tell them that I still want an NDA, as well as a business associate agreement (BAA) because StackAware recently became a business associate under the Health Insurance Portability and Accountability Act (HIPAA).

• August 14 - Carrier sends me their “incident response client journey.” I install the incident responder’s app and turn on the following services:

  • Dark web monitoring

  • Phishing simulations

  • Exterior vulnerability scanning

  I send them a proposed NDA and BAA, at their request.

• August 20 - Carrier sends me another NDA the incident response provider is willing to sign. They say a BAA is not necessary. They reschedule the call we had set up with the incident responder to discuss their SOPs.

Major red flags throughout the process

1. No onboarding process for carrier or incident responder

I had to pull information the entire time. Making sure I:

• Am onboarded on the carrier’s app

• Have all preventative services active

• Generally know what to do in an emergency

all seem like they should be key priorities for the carrier and panel incident response provider. But they showed very little interest in proactively preparing me.

It would make sense for the carrier to offer financial incentives to do all of these things, but at a minimum they should be ruthlessly bugging me until I do them.

2. Initial refusal to sign NDA except during incident

This strikes me as especially nuts because the back-and-forth on the NDA took a week just to get something both parties were willing to sign. This would be an eternity during the middle of a cyber incident.

The only thing I will note here is that a (very) senior cyber insurance expert told me such NDAs are not standard. That’s because some carriers set you up with a law firm to run the incident response process. And the law firm could operate under attorney-client privilege and American Bar Association confidentiality rules instead of a formal NDA (with the incident response firm under NDA with the law firm).

But I also talked to a lawyer who specializes in cyber incident response.

He told me to definitely get an NDA in place.

As for the BAA, because forensics would be a big part of any incident response process, I view it as absolutely vital to safeguard protected health information (PHI). Without it, I would need to withhold access to any systems with PHI on them, which could hamper the investigation after an incident.

3. Step one of the incident response client journey is “onboarding,” which can take 1-5 days!

The documentation I received also mentioned I would need to execute a statement of work (SOW) to move to the next stage. This means that during an incident I would need to review and execute a contract, for which I would have very little leverage to negotiate either price (Update 23 August 2024: the SOW fees would be paid by the carrier after you pay your deductible) or terms.

Imagine being squeezed by both a ransomware gang and your cyber incident responder at the same time!

4. Incident response app requires manual offboarding process for departed employees

According to the frequently asked questions (FAQ) and answers document I received:

An employee who had the app has left – now what do we do?

Get in touch with our internal support team at appsupport@[REDACTED].com, and they’ll be able to assist you with these access changes.

So removing former employees from the incident response communication flow requires manual intervention and tracking. And it can’t be synced with any sort of identity provider to allow for automated removal.

That is by itself a security risk.

Things to do when buying cyber insurance

For a small company like StackAware, it’s unlikely we would have had the leverage to get these issues resolved ahead of time. With that said, it never hurts to ask. So in hindsight I recommend you:

1. Get an NDA in place as part of the underwriting process

Although I personally didn’t think the information requested in my application was all that sensitive (or useful), you could certainly make the case that it needs protection under NDA. So you could use that - plus the desire of the broker and carrier to get the deal done - as your lever to get one in place.

2. Ask all of the above questions before buying the policy

In retrospect, it seems silly that I didn’t do this ahead of time. But you don’t know what you don’t know. For some reason I expected this process to be a well-oiled machine.

It wasn’t.

And you shouldn’t expect it to be.

3. Consider self-insurance

This isn’t an option for a lot of companies (including StackAware) due to contractual or regulatory requirements.

But there is evidence cyber insurance incumbents are struggling to deliver value cost-effectively, such as:

• Companies only getting 80 cents on the dollar in claims payouts.

• An insurance CEO saying he can’t quantify cyber risk.

• Players like Google entering the space.

It’s conceivable some organizations might be better served spending what would go to a premium on improved controls reducing the likelihood and severity of an incident.

Obviously you’ll need to do your own calculations, but I’m open to the argument that the risk-adjusted cost of cyber insurance may not be worth it.