How to Test Your ISO 27001 Business Continuity Plan

What happens when there’s an unexpected interruption to your business?

Certainly, it depends on the kind of interruption. The way your business handles something like a power outage can be quite different from how you handle a wildfire, which will be different from how you handle a cyberattack.

The core principles are the same. You want to have ways to defend your business, to restore services, and to ensure continuity as much as possible. Building resilience against damage and loss is part of a robust business plan.

ISO 27001, while it’s largely focused on information security, includes controls relevant to maintaining business continuity. This is because disruptions in business continuity can include disruptions to your security measures, whether it’s physical or digital access to sensitive data.

Just having a business continuity plan is one thing, but making sure it works is quite another. Auditors want to know that it’s tested and effective, which means you need to validate your plans ahead of time, and routinely thereafter.

The question is, how?

Understand Why and How BCP Testing Works

The first thing to do is understand the purpose of testing your business continuity plan.

This isn’t just filing a checkbox. One of the biggest mistakes companies make is taking a templated business continuity plan from some ISO 27001 resource online, using it as-is, and testing that it works as-is.

While that’s fine, it’s not necessarily relevant or comprehensive for your business.

For example, imagine if you take a business continuity template and it includes instructions on how to harden your company against a tsunami. This is fine if you’re a coastal business, but a landlocked business in Iowa doesn’t need to know or care how to recover from a tsunami. After all, if such a thing hit Iowa, you have much larger things to worry about.

One critical detail of the BCP is that it is comprehensive. It needs to understand all of the various sorts of risks your business could face, and how you can recover from them and maintain business continuity through and after they occur.

The risk of templated BCPs is not just that they can include coverage for risks that you won’t face. It’s the opposite: you might face risks that your BCP doesn’t cover.

Testing your BCP allows you to identify weaknesses in the plan, figure out how to fix them, and make sure any roll-over, fail-safe, and other mechanisms are all functional. It also serves as a way to validate employee training, since your team needs to know how to handle these risks as well.

If you approach business continuity testing as if it’s just filling out a set of checkboxes, it’s likely that auditors will find holes that you haven’t noticed, and that’s a problem for your certification.

Gather Stakeholder Organization and Buy-In

One key to effective continuity plan testing is involvement from stakeholders and key personnel. Regardless of which risk is being tested on which systems and which methodology, the right people need to be involved.

This can include executives in leadership, IT teams and leaders, heads of affected departments, front-line staff affected by the risk being tested, and even external vendors, suppliers, and partners who would be affected.

Gathering and involving the appropriate people can sometimes be a challenge, but without their involvement, you don’t know whether or not a real incident will be handled appropriately.

Pick the Risk to Test

Different risks present different challenges and, critically, different procedures for maintaining continuity and recovering business operations. You can’t test them all at once, because they may have mutually exclusive conditions.

Consider the kinds of risks that you face and have documented in your continuity plan. These can include natural disasters, power outages, cyber attacks, health emergencies, supply chain disruptions, insider threats, system intrusions, and much more.

Depending on the kind of testing you’re doing, you might run through the whole list over the course of a few weeks or months. Or, you might be spot-checking certain elements of the recovery plan to validate that they still work after however long since the last time they were tested.

Generally, you will want to have each of your recovery and continuity plans tested and validated on a regular basis. Some may need to be tested more often, while others might only need a routine annual assessment, depending on how much changes over time.

Part of picking the risk is to then develop a realistic scenario in which the risk would happen. It might seem like this goes without saying, but now and then you run into a company that tests “alien invasion drills,” “giant meteor warnings,” and other such nonsense. These don’t really help and make testing your business continuity feel more like a joke, so it’s taken less seriously.

Define Testing Objectives

When you’re ready to start testing elements of your business continuity plan, it’s important to consider how you want to test them and what the goal of the test will be.

The most obvious goal of any test is simply to make sure that business continuity is either maintained or recovered using the plan. If that bar isn’t cleared, nothing else really matters, right?

Other specific testing objectives can measure how effective, reliable, and durable your recovery and continuity processes are.

• Testing and validating RTOs, or Recovery Time Objectives, helps you evaluate how long it should take to recover in various scenarios, and make sure you’re coming in at or under those benchmarks.
• Testing communications protocols helps validate that the individuals in positions of responsibility (from facilities and IT workers to C-levels and managers with decision-making powers) are kept in the loop and know what to do.
• Testing employee behavior and training helps you ensure that your staff knows what to do in the event of an incident, and can identify gaps in training.
• Testing backup systems helps ensure that anything from power generators to in-house servers to data connections to physical security mechanisms all function in the event of an incident, and identifies gaps that need to be rectified. Data backup systems in particular need to be verified, not just for their functionality, but for the reliability and utility of the data they back up.

While you can consider an incident from multiple angles, it’s important to go into your testing knowing which ones you want to focus on and how you want to evaluate them. It can also require different kinds of tests to evaluate different objectives.

Pick an Effective Testing Method

Broadly, business continuity and disaster recovery testing can take a few main forms. Picking the most appropriate format for your test and your objective will allow for effective evaluation without excess expense or disruption.

The higher the stakes for the test, the more time and resources it will take to implement, but the better the data will be. Usually, the lower-stakes tests can take place as often as on a monthly basis, while higher-stakes testing can occur annually or as needed.

The first and lowest-stakes form of testing is a simple plan review. This is basically just a meeting of key personnel involved in business continuity. During this meeting, the plan is discussed, the procedures are reviewed, and any lack of clarity is addressed. If people aren’t sure what they should be doing, that could be a fault with documentation, training, or procedures, and should be addressed.

Plan reviews are critical for ensuring that your plans are well understood by stakeholders and key personnel. They’re also critical for updating your business continuity plan if elements of your business, the threat itself, or even industry regulations change.

A step up from a plan review is a tabletop walkthrough. This is a sort of tabletop role-playing simulation, where your team imagines that the incident is occurring and walks through the steps, how long they would take, what needs to be done, and what hypothetical issues could come up, alongside potential solutions.

More intensive versions of the walkthrough involve physically walking through your facilities while performing this discussion. This helps contextualize the work that needs to be done to maintain continuity according to the plan.

The step beyond tabletop discussions is a simulation or rehearsal. These are controlled, narrow tests wherein specific processes and aspects of the BCP are tested. Unlike other forms of tests, the rehearsal simulation actually “pulls the trigger” on the processes.

For example, you might temporarily cut the power to a critical server to make sure your backup generators carry over and your uninterruptible power supplies function. Or, you might access digital systems as if an account was compromised and delete files or account access, to simulate restoring from backup data.

The key here is that these tests are kept controlled and limited to a narrow field of evaluation. You’re testing one system, one process, with one objective in mind to validate. You don’t want these tests to spiral into cascading problems, or repetition with increased downtime and service disruption.

Finally, you have the top-level total incident simulation. These simulate what would occur if an incident actually takes place, whether it’s a serious cyberattack, a failure in your IT systems, a failure of public utilities, a wide-scale natural disaster, or something else. These are drills that can result in evacuations of your build, a temporary work-from-home order, and more.

Obviously, drills of this nature carry some risk. If your business continuity plan isn’t comprehensive enough or effective enough to maintain services, you can do tangible harm to your own business. Likewise, forcing a restore-from-backup is the worst time to learn your data hasn’t been backing up properly.

Ideally, drills are only performed after previous tests have validated that these elements of your business continuity plan are effective and in place, so such damage is unlikely. But it’s still a risk.

In some cases, you may hire a firm to “red team” your business for these tests. A red team is a group that plays the role of an aggressor, trying to breach your systems or trigger your recovery plans without it being an internal simulation. The idea, of course, is to make it as realistic as possible.

Obviously, a red team isn’t going to start a wildfire or simulate a terror attack, but with the access you give them, they may breach systems, or they may use social engineering to access your facilities and exfiltrate or damage data.

Document, Analyze, and Report Results

The final step of testing your business continuity plan is to document the outcomes of the test, positive and negative. Determine if resources were properly allocated, if contacts are appropriately reachable, if timing is rapid enough, and if backup systems function effectively.

Issues you find along the way can be fixed, and the plan can be iterated upon. You may need to update training, update software, implement validation of various systems, and more.

From there, you draw up reports of the results of the testing. These reports serve as artifacts and proof that your ISO auditors can examine before they perform any particular tests they want to perform.

As you iterate on tests, you can use this information to determine further procedures.

• Determine how frequently certain systems need to be tested, and on what magnitude.
• Determine if changes need to be made to training, procedures, or systems.
• Determine if there are gaps or flaws that could be solved by implementing new technology.

Over time, you will build a comprehensive library of test results and ensure that every element of your business continuity plan is effective.

One challenge many businesses face when they’re trying to test their business continuity plan is maintaining all of the logs, records, results, and artifacts of proof in a way that is effective for passing an ISO audit. Fortunately, we’re here to help. The Ignyte Assurance Platform is an excellent tool to help you maintain this documentation and awareness, and where you can easily store results, pull reports, and provide data to auditors all throughout the process.

To see what our platform can do to help you succeed with ISO 27001, simply click here to get started. We’ll schedule a demo to show you exactly how our platform can be most relevant to you, and answer any questions you may have.