ISO 27001 controls for security and business continuity

Disruptions in IT and business operations are not a question of “if” but “when”, as shown last year during the CrowdStrike massive outage. Disruptions include infrastructure failure, cyberattacks such as ransomware, even natural disasters but, more often, human error. For these reasons, the ISO 27001 2022 standard includes two important controls related to information security during disruption (5.29) and ICT readiness for business continuity requirements (5.30). Virtually all organizations face the risks that the controls are meant to cover, therefore, companies that we help with ISO 27001 must implement these controls in a way that works well for the company’s unique context. Read more about our approach below.

The purpose

Control 5.29 requires organizations to plan how they will maintain an appropriate level of information security during disruptions. This includes maintaining integrity and confidentiality of information, so under this control you should ensure that information security controls (e.g. electronic locks) still work in case of a disruption. Organisations should make sure controls also work in times of crisis, or have alternative controls in place to compensate in times of crisis.

Control 5.30 requires organizations their information and communication systems (ICT systems) work in times of disruption. The main purpose of this control is the availability of systems and assets. This controls requires organisations  to plan (outline how), implement (put the plan into effect), maintain (continuously enable its effectiveness) and test (verify its effectiveness) the readiness of their ICT systems.

The focus of these controls is different, but most organisation should implement these together. They should make one business continuity plan that meets the requirements of control 5.30, since availability of ICT systems is often the biggest risk in times of crisis. Once organisations have a business continuity plan, they should then check if information integrity and confidentiality is still sufficiently protected.

Implementing 5.29 and 5.30 with our template

How to best implement the two controls is, of course, up to the organization. It is possible to make two separate plans, one focusing on preserving security controls, and the other on restoring ICT services. However, a dual approach can lead to misaligned priorities (the classic “security as an afterthought”) or lack of testing coverage (lack of tests on one can impact the other). It is more effective and more efficient to treat the two controls combined. You can implement both controls using a Business Continuity and Disaster Recovery document. You can download this template also from our templates page.

Using the Business Continuity and Disaster Recovery playbook

The template is based on the recommendation from the ISO 2702 document and contains the following elements:

• Definitions and business objectives
• Business Impact Analysis (BIA): an overview of your processes, their importance and suitable objectives
• Disaster scenarios: about 4 different possible disasters, such as ransomware, power failure, office closure or pandemic
• verification, review and evaluation: For each scenario how you will evaluate/test whether the plan works. This can range from a restore test to a tabletop exercise or evaluation exercise.

You should fill in each section of the document and then communicate the document internally, and add the evaluations to your ISMS calendar.

Definitions and business objectives

The first step for planning business continuity is to set business objectives for all your processes. This is often done based on metrics. Useful metrics are:

• Maximum Tolerable Downtime (MTD) –duration of system downtime before irrecoverable damage (e.g., 2 days before breaking SLAs); Possible values range from 60 minutes to 2 weeks.
• Recovery Time Objective (RTO) – maximum duration to recover a system or process (e.g., <= 24 h); Typically you want this to be less than 60 minutes. Whether this is feasible depends on how complex the system is or how much data you need to restore.
• Recovery Point Objective (RPO) – maximum the latest up-to-date, operational state of a system or process (e.g., last daily backup). This value depends on how much data you collect per hour or day and how difficult it is to re-enter the data or get it from other sources. Typically values range from 60 minutes to 24 hours.

Business impact analysis

The next step is to make a table containing your main processes, and then set objectives for each process. This is shown in the table below. In this example four processes have been defined, that roughly correspond to the main departments of a company. Sales is one of the processes and example values have been filled in. In this example sales is not that important so the objectives are not very ambitious.

Note that there could be contractual obligations related to business continuity: you might be required to have a certain RTO and RPO. It is important to list such requirements in the plan with the appropriate objectives.

The next step is to make a list of all IT systems, such as the external website, internal website, production servers, GitHub, Sharepoint, Pipedrive. You then indicate whether the system is needed for each main process. Systems that are needed for important processes are important, and systems that are only used for less important activities are less important. The MTD, RTO, RPO for each systems is the minimum of all processes for which the system is needed.

Disaster Scenarios

The next step of the Business continuity plan  is planning for disasters. You should list potential disaster scenarios that can affect business continuity. This should include both physical (facilities unavailable due to natural disaster or fire) and technical disasters (production database crash, ransomware attack).

In our template, a mapping between disaster scenarios and affected processes provides a practical link between potential events and their operational impact.

After outlining a number of disaster scenarios with the affected processes, you should define actionable plans to respond to each of the possible disaster scenarios (“getting back online”). Recall our previous example of facilities unavailable due to fire, then a disaster response would include personnel evacuation, contact with authorities and coordination of employees. This is a disaster recovery step that, however, does not account for business continuity. Therefore, it is useful to include a business continuity plan (that is, “staying in business”). For our running examples, this means to shift work to remote, start a relocation procedure and replacing lost hardware.

Traditionally, power outage was a main concern and obtaining a backup generator was a common way to prepare for scenarios. Organisations would have a diesel powered generator on site, and the generator would either power all equipment on site, allowing the shop to be open, or just power critical equipment such as emergency lights. Backup power is suitable in some regions or some applications. It is however also a significant investment since the generator also needs maintenance, testing, and checking fuel level and quality.

Verification, review and evaluation

Finally, it is required that ICT recovery plans are regularly tested. The organization should decide how to perform the tests for each scenario and when to execute tests on the scenarios. Having an instruction and schedule for tests like remote work drills, backup restores, and simulated failovers, ensures that controls are not just theoretical but actively validated. See the table for an example from our template.

Added redundancy with control 8.14

An (intended) positive side-effect of implementing 5.29 and 5.30 in this way, is that the Business Continuity Plan  naturally links to the technical control 8.14 (which requires the implementation of information processing facilities with sufficient redundancy to meet availability requirements). Specifically, the critical processes and recovery objectives cover the 8.14 suggestion to identify the requirements for availability. Similarly, implementing the disaster recovery plans goes hand-in-hand with control 8.14’s demand for availability-focused redundancy, such as failover environments, replicated databases, or geographically distributed backups. The same applies for planning for information security during disruption (5.29) where, for example, duplicating systems without equivalent access control or monitoring could lead to security risks.

Practical considerations

In a large organization, such as a financial services company, it is important to ensure that critical systems like transaction systems, customer portals and internal tooling are back online within formalized thresholds (RPOs/RTOs), without which they risking huge financial losses or regulatory violations. Similarly, ensuring information security during a disruption (5.29) is critical, essentially, because the attack surface is vaster and the stakes are higher. For example, the multinational financial company stores and uses large amounts of sensitive data like legal contracts, financial models or entire databases of private data. Even a minor violation or the uncertainty around potential compromise can have significant consequences.

In a small organization, like a remote-first SaaS startup, business continuity (5.30) is equally important. For it, developers and administrators should ensure that cloud backups are regularly tested, production environments are redundant and services can recover quickly after a crash. These are simple steps that protect the business. For example, you can ensure a high level of availability in a region on AWS (e.g., central Europe) by activating multiple Availability Zones which enable you to withstand a complete failure of an entire data center in a zone. A similar concept applies to the Microsoft Azure cloud services whereby each region hosts three physically separate availability zones.

Conclusion

To comply with ISO 27001 controls, your organization must document all the relevant processes described thus far. One way to achieve this efficiently is to describe you plans and procedures relevant for the control 5.29 and 5.30 in one document. Our template applies this philosophy with the necessary rigor and flexibility to meet your organizations needs and to align with the other controls of the ISO 27001 standard.

Featured images by Fahim Junaid, Jackery Power Station on Unsplash, and Amazon AWS cloud services.