Tabletop Testing: Is Your Business Prepared for a Cybersecurity Disaster?

When is the last time you really tested your network infrastructure? More than just sending out a fake phishing email to your staff for employee training; serious disaster training, with simulated failed backups and even outages?

If the answer is "never" or even "a while," how can you know if you're really prepared?

Let's take a look at how tabletop testing can give you peace of mind!

This blog is an excerpt of a recent webinar.
Don't want to read the article? Watch the full recording below.

Be sure to register here for the "Cybersecurity for Business Leaders" Lunch & Learn series!

Table of Contents:

What is Tabletop Testing?

What Cyber Threats Are You Testing Against?

Is Tabletop Testing Required for My Cyber Insurance Policy?

How to Build A Tabletop Policy

Tabletop Testing Takeaways: Discuss the Lessons Learned

Providing Evidence for Auditors

What is Tabletop Testing?

Tabletop testing is not a complex topic, nor is difficult to implement, but depending on your industry or size of your business, the exact methods of execution can differ.

In the simplest terms, tabletop testing is a simulated disaster or outage exercise used to assess the readiness of your network infrastructure.

For each person reading this, tabletop testing will involve different steps and different methods, because no two businesses are exactly the same. This is also generally more than just a test, involving multiple people in your organization facilitating the test, managing the library of scenarios, and providing reporting. Tabletop testing can involve your entire organization!

In most cases, tabletop testing is an extension of your business continuity and/or disaster recovery plan. The idea is, tabletop testing will help you determine what's a critical asset and how it is mapped. From there, you can assess how to get it back up and running as quickly as possible. Run your tabletop tests, see what happens, and determine how to recover.

What Cyber Threats Are You Testing Against?

Tabletop testing can help you simulate how your network would hold up against natural disasters, manmade cybersecurity threats like DDOS cyber attacks, or even internal breaches from rogue employees. Your imagination is the limit with tabletop testing.

These tests also need to involve different teams, employees, and scenarios to make sure you're not just checking a box year after year. Getting good at running the same simulation over and over doesn't do your business any good.

Is Tabletop Testing Required for My Cyber Insurance Policy?

In the last three to five years, we've seen tabletop testing become a requirement for most cyber insurance providers. Even if it's not a requirement, all will ask "Do you conduct tabletop exercises?" This is also true with government contractors, requiring proof of testing.

Depending on the industry, proof of tabletop testing may be the key to winning another organization's business. Tabletop testing acts as real evidence that you're secure and ready to take on any potential disasters that may arise.

How to Build Out A Tabletop Testing Program

While it can feel overwhelming, building out a tabletop testing program is really just a series of small steps. Let's dive in.

Create a policy

Step one is to create your high level policy. This is going to tell you what the organization wants to do and the expected outcomes. Your policy also determines who the stakeholders are, the scope of the testing, and success criteria for the tabletop programs.

Without a strong policy and executive buy-in, implementing a tabletop testing program becomes almost impossible.

Create your policy that includes the goals you want to achieve. From there, develop your processes and procedures to meet the goal.

Create a scenario library

Gather all of the scenarios your company needs to be able to address, document them properly (more on that in a minute), and keep them in an accessible location like your company's SharePoint repository.

As for documentation, one of the nice things about tabletop testing in general is the low cost of the whole initiative. You don't need proprietary software; most only use Excel, Word, and SharePoint to handle all of the documentation process!

Categorize the tests in your library based on type

Building your scenario library is one thing, categorizing it is another. I've seen this categorization lead to a lot of really useful conversations about individual responsibilities and ownership of certain necesseties, that lead to clearer and more informed organizations.

How you categorize your scenarios is up to you. Some are by disaster type, some are by the departments involved, others are simply alphabetical. I wouldn't recommend this method unless you only have a few scenarios!

Assign difficulty levels for the tests

Difficulty levels are my favorite way of categorizing tests. When considering the levels, think of the ratings as simple to complex. The last thing you want to do is start the entire process with an overly complex scenario. You need to know the difficulty levels so you can know where to begin tabletop testing.

Maybe your easy tests involve phishing schemes and how you'll react to an attempted emailing scheme. From there, move up to natural disaster scenario or maybe a ransomware attack and/or data breach. Start small, and work your way up.

Determine testing frequency

I know the default for everyone is going to be once a year. I don't believe that is enough. In a best case scenario, you would be running tabletop tests quarterly. Depending on the size of the company, you may have different departments tackle different scenarios. Mixing and matching tests, such as web-based network security, physical endpoint security, and cybersecurity is always recommended as well.

Decide how and with what tools you will document everything

Documentation needs to be standardized company-wide. This needs to be done up front. Decide how you're going to document results, and make sure everyone sticks to those standards. Ideally, everyone would work out of the same document in a shared location.

Bonus tip: Have a backup plan! What if one of those scenarios becomes a reality and you don't have access to the tools you use to document your processes?

Consider the real-world results against expected and desired results

In the beginning, don't be surprised if your performance is flat-out abysmal. It's common for the initial results to be poor. Frame your initial rounds as a learning opportunity for everyone, and set real-world expectations for everyone.

I like to frame the desired results in a "good, better, best" fashion. It's nice to have a perfect ideal result, but achieving it may be near impossible. Can you get 80 or 90 percent of the way there? In most cases, this is good enough to keep your operations running.

Determine who the participants will be

Assigning roles and responsibilities to your employees is crucial. This allows everyone to come in to the first meetings knowing what they need to do. These first meetings can be a bit awkward and uncomfortable, exposing some gaps in knowledge and/or staffing, but they can lead to greatness if the issues are addressed properly.

Tabletop Testing Takeaways: Discuss the Lessons Learned

The single most important piece of this whole process is the "Lessons Learned" follow-up meeting. This is where things are addressed, corrected, and improved upon.

Here are the steps for a great takeaway meeting.

Determine Documentation Location

As I said earlier, Office 365 can handle the entire tabletop process, including offering a shared location to save your files. Choose on agreed-upon location for all of your documentation.

Decide if Results Need to Be Rolled Up to Executive Leadership

Do you have a board, committee, or executive group to report to? If so, what formats are needed for the presentation? Work through these problems in advance so that when the time comes, you're ready to go from day one!

Most of the details of your results won't need to be passed on to executive leadership. Be sure to document everything properly, but for an executive summary, you really just need to cover large gaps.

Create a Process for Assigning Risk Severity, Likelihood, and Cost

Create some way of assigning risk severity and likelihood along with the cost to remediate. Keep it simple: Critical, High, Medium, Low for severity. Maybe a percentage total for likelihood of impact. Estimated dollar figures for cost.

Establish a Cadence for Open Action Items

The worst thing you can do is write down a discovered issue and then forget about it. I've seen this more times than I can count!

Everyone does a great job holding a lessons learned meeting. I've found that people are quick to tell you everything that went wrong, but then three months later, you're holding another scenario and find the EXACT same results. This is because no one did anything coming out of the first meeting!

Nothing gets a group of professionals more upset than seeing the same issues pop up at a follow-up tabletop testing session. Make sure you have an established cadence for everyone to discuss, escalate, and update open items.

Providing Evidence for Auditors

To be clear, tabletop testing shouldn't be done to simply check a box for an auditor, it should be done to improve your security posture. That being said, if you're already doing this, why not meet the compliance side and check that box as well? At a minimum, you'll need...

• Program Policy
• Established Processes and Procedures
• Library of Scenarios
• Risk Register
• Meeting Agendas
• Lessons Learned Documentation

All of these items should be easily accessible, assuming you've properly documented during the entirety of the tabletop testing process.

For organizations of any size with a digital footprint or maintaining digital records of client data, tabletop testing should be an annual requirement. Working through multiple scenarios with the right people can be a challenge. If you need help putting your organization to the test, reach out to us and learn how Ntiva can help mitigate your security risks!