This post is the third in a six-part series based on an interview with Jason Smolanoff, Senior Managing Director, Global Cyber Risk Practice Leader, and Andrew Beckett, Managing Director and EMEA Leader for Kroll’s Cyber Risk practice. The 30-minute interview was conducted by Legal Week’s Dominic Carman.
In our previous posts, we outlined how an assumption of breach theory can help general counsel craft a proactive information strategy and how a security framework like NIST helps mature your strategy. In this segment, Andrew talks about how to help ensure an organization’s incident response plan will actually work as intended. Andrew stresses that testing the plan is crucial. He particularly recommends retaining an outside cyber forensics firm to run tabletop exercises and develop scenarios to identify gaps that may not be apparent from the policies as written.
Quite often, Andrew explains, companies seem to have nice-looking response plans that show external technical advisors in place and everything covered. But, Andrew warns, it’s important to get clarification on these key questions:
Do they actually know they are your technical advisors?
Do you have an executed retainer and contract with them?
Do you know that the log information you're supposed to get is actually in place?
Is your incident response team empowered with delegated authority from the board to act?
The answer heard frequently? No. Then the breach occurs, and you need to get the proper approvals. It’s 5:30 on a Friday afternoon and nobody is available to approve.
Andrew adds that working through all these steps is imperative, but for GCs, one of the crucial areas they need to tackle pre-breach is understanding the language of IT. One of the common failings is when a breach happens, reports are coming in from the IT security team and counsel has to keep stopping them every second or third sentence for an explanation.
Read the full Q&A transcript
Dominic: One of the key components in risk management obviously from a GC's viewpoint is having an effective incident response plan. From the research that we've done, the findings reveal, I suppose, there's again an enormous spectrum of sophistication and different levels of significance and importance put upon it by different GCs in different parts of the world. What should GCs be doing to make sure that their incident response plan covers all bases?
Andrew: I'd start with actually testing it. Run a tabletop exercise. Get somebody to develop scenarios and then test them for you so that the gaps that may not be apparent from the policies as written can be identified. Quite often we've found companies with, on the face of it, nice-looking incident response plans that say yes, these people will be our external technical advisors. These people will be our crisis company. Do they know that? Do you have a retainer in place? Is the contract already there? No.
Do you know that the log information that you're going to get is actually in place? Do the people who comprise your incident response team, are they actually empowered with delegated authority from the board to act? Because if this kicks off, as they almost inevitably seem to do at half past five on a Friday, and you have to go back to the board for approval to act, you can't wait for Monday because they're all off on their yachts or at their villas somewhere. You need to be able to act and make the decisions. And it's working through those steps that are imperative, but for the GC themselves, of course, one of the crucial areas that they need to work on pre-breach is understanding the language of breach, and then understanding the language of IT. Again, one of the common failings that we find is that when a breach happens, reports are coming in from the IT security team, from their IT suppliers, and counsel has to keep stopping them every second or third sentence...
Dominic: …for explanation
Andrew: …for an explanation.