ISO 27001:2022 – 5.30 ICT Readiness for Business Continuity

One of ISO/IEC 27001:2022’s new controls focuses on addressing ICT readiness for business continuity. If you are familiar with the 2013 version of 27001, you may be thinking ‘But we already had business continuity in Annex A 17!’. We did, but this is a little bit different and provides a more defined link between information security and the wider business. I’ll explain what I mean by this and delve further into this concept throughout the article.

Different people’s opinions may differ, but this is another one of those changes that should really have been in place, and if you are following the standard, and especially if you are already certified, it’s unlikely that you don’t already have this in place. The 2022 changes really just cement its requirement and formalise it.

What is ISO 27001 Annex A 5.30’s expectation?

Like the other control updates we have looked at so far, we have a single sentence defining the control listed in Annex A of the standard, and it states:

“ICT readiness shall be planned, implemented, maintained and tested based on business continuity objectives and ICT continuity requirements.”

Once more, the control is very broad, intentionally so, to allow organisations to take a business continuity approach that fits their specific business. Each business is very different. This is why at Morrisec we are always harping on about there not being a one-size-fits-all approach to security, but this is also true in many other business functions. Business continuity is a fantastic example of this. You can’t take one company’s business continuity plan (BCP), rebrand it, and reuse it. Internal business processes, technology, how personnel use that technology, the data they need access to, and how they use that data, are all critical components that need to be assessed to develop an effective and fit-for-purpose BCP.

A business impact analysis (BIA) is a critical component of this, and something often neglected in organisations, especially SMBs. I will talk about BIAs and their requirement within this control, but first, let’s take a look at ISO/IEC 27002:2022 to get an idea of what A.5.30 ICT readiness for business continuity is expected to address.

ISO 27002 ICT readiness implementation advice

First up, 27002 provides us with an additional ‘Purpose’ for the control, stating:

“To ensure the availability of the organization’s information and other associated assets during disruption.”

This control is pretty straightforward in its purpose, keeping information and assets available, even during disruptions. The purpose of each control being added to the 2022 version of ISO/IEC 27002 was a great addition as it provides us valuable insight into what the intent of each Annex A control is. This is critical in satisfying the control, especially when using other frameworks other than ISO 27002, like NIST.

There are two key components discussed in 27002’s control guidance section, a BIA and a risk assessment. These two components are essential in providing inputs and guidance into developing ICT continuity strategies that are aligned with your business and your continuity requirements.

Risk assessments, which are already an integral part of your ISMS processes, will identify risks and the likelihood of them occurring. Cross-referencing these risks with your BIAs, which help you understand what’s critical within your business, allows you to ensure you have adequate recovery capabilities. For example, a critical business process with a high availability risk attached to it means you probably need to prioritise your continuity plans for that process.

I will discuss performing the BIA in the next section, but for now, 5.30 addresses a couple of outputs that should result from the BIA.

Recovery Time Objective (RTO)

An RTO defines the maximum acceptable downtime for a business process or system following a disruptive event. It represents the targeted duration within which operations must be restored after an incident or disaster. So think of your email system going offline and you suddenly have no access to email. How long is it acceptable to be in this state? For some organisations, it could be days or weeks, for some roles that live in email, it could be tools down until it’s back up. Understanding your RTO is critical to ensuring you have everything in place to get back up and running so your business has as little impact as possible. As you can imagine, the faster you need to be back up usually means more financial investment, in people, processes and/or technology. This is why you perform BIAs to assess the impact on your business and work out these times across the entire business as requirements will be different for different business units.

Resourcing

As mentioned above, different RTOs will require different resourcing, so 27002 states:

“The BIA should then determine which resources are needed to support prioritized activities. An RTO should also be specified for these resources. A subset of these resources should include ICT services.”

Therefore, in any ICT continuity planning to address this requirement, make sure you address resourcing needs.

Recovery Point Objective (RPO)

Personally, I love the fact 27002 actually draws attention to RPOs, even if it does say “can be expanded to define“. If you are discussing business continuity, you cannot neglect RPOs. A lot of people seem to struggle with the difference between RTOs and RPOs, or they often only define RTOs.

An RPO defines the maximum acceptable amount of data loss an organisation can tolerate following a disruptive event. To put this in context, imagine you are a sole trader that just works on their laptop. Everything you do, every file, your whole business life is on that laptop. You back it up once a week to be safe. If that laptop suddenly stopped working, was stolen, burst into flames and you lost everything, how much data can you afford to lose? This is tied to how frequently you backup your data. If you backup at 5 pm every Friday and your data is lost at 4:59 pm on a Friday, you just lost 1 full week of data as it’s been 1 week since you backed up your laptop. Everything you did in the last week is gone. Is this acceptable? If it isn’t, what is? 5 days, 1 day, 1 hour? This is your RPO, the point at which you can afford to lose data. If you backup every hour, you lose 1 hour of data at the most, making your RPO 1 hour. None of us wants to lose any data, but the shorter the RPO, the more costly (in general) for the business, so it’s a trade-off of what you can lose versus the cost of having a shorter RPO.

Simplified, RPO is how much data you can afford to lose, and RTO is how much time you can be without access to that data. This is why BIAs are critical to resilience. If performed properly, your BIAs will define your RTOs along with your RPOs.

The final guidance from 27002 outlines critical components that should be addressed in your continuity plans. These include:

• Have the right organisational structure in place to prepare for, mitigate and respond to a disruption. This means having enough resources to address your needs. It also means ensuring people know what their responsibilities are, they have been granted authority to do what needs to be done during a disruption, and they have the skills to actually do it.
• Make sure all plans are tested! I can’t express this enough. You do not want to be testing your plans for the first time during a crisis event. Testing lets you identify issues and fix them before you need to actually use that plan in a real scenario. That way you know (hopefully) it will run smoothly if/when an event happens.
• Ensure all plans have been approved by management. Trying to  get approval to do something like engage a third party, or some other requirement that needs management approval during a disruptive event isn’t ideal. Murphy’s law is you’ll struggle to get hold of that one person you need.
• Make sure outputs from the BIA have been addressed, such as the RTOs and RPOs

It’s not stated in the requirements for this control but RTOs and RPOs should be in your asset register. A BIA is a perfect time to be developing and populating that asset register with all the information you need to make informed business and security decisions about each asset.

Business Impact Analysis and Security

One thing to be aware of when complying with this control is that nowhere in A.5.30 nor anywhere in ISO/IEC 27001, does it say you must perform a BIA as part of your ISMS. Yes, you need to leverage your BIA therefore it needs to exist, but the actual performance of any BIA is outside the scope of your ISMS. The reason for this is pretty simple.

In the same way I am always saying information security or cybersecurity is not an IT function, it’s a business function, so to BIAs are a business function, not an information security or cybersecurity function. It’s not the responsibility of the security team to perform BIAs on behalf of the business. Many times in my career I have had clients ask me or my teams to write their Business Continuity Plan because ISO/IEC 27001:2013 A.17 addresses business continuity management. But as the title states in A.17. it is for ‘Information security aspects of business continuity management‘. It ensures that security functions are addressed and resilient to business interruptions. This doesn’t include the whole business and all its business-critical processes. Just security.

A.17 from ISO/IEC 27001:2013 has been replaced with A.5.29 in the 2022 version and has been retitled ‘Information security during disruption‘. This combines the four 2013 controls into one, with ISO 27001:2022 stating:

“The organization shall plan how to maintain information security at an appropriate level during disruption”.

So the intent remains to ensure security functions are resilient.

The intent of the new A.5.30 control is to ensure ICT, not just security functions, are resilient to cyber or information security threats. This is a far greater concern since the 2013 version due to the escalation in breaches and the resulting impact on affected organisations. But ICT can be impacted by many things that aren’t security related, or even technology related (COVID is a perfect example), hence why the BIAs are performed outside this function and why the full BCP and its responsibility doesn’t reside within ISO/IEC 27001 or with your security team. Any BIA and its associated BCP need to address non-security threats and risks as well. A.5.30 then uses this information to ensure the company is resilient if business continuity is affected by a security threat.

So if BIA’s haven’t been performed by the business before, they are going to need to now. It is a critical business function that all organisations should have in place to ensure business resilience, not just cyber resilience.

How do I comply with ISO 27001:2022 Annex A 5.30?

As I mentioned in the introduction to this article, if you are already certified to ISO/IEC 27001, you should already comply with 5.30, or may only need very minor tweaks. The reason I said this is based on our external audit experience. Making sure a BCP is in place is generally reviewed when checking compliance with the old A.17 controls. While I discussed how A.17 is there to address the continuity of security functions, most auditors look at business continuity as a whole and look for an organisational BCP, not just a cut-down continuity plan addressing security alone.

At Morrisec, our consultants are all ISO/IEC 27001 Lead Auditors and while we don’t provide external certification auditing services for ISO/IEC 27001, we do work as auditors for external certification companies from time to time. The reasoning for this is so we have ongoing experience on what is expected by those auditors for attaining certification. This ensures clients we are supporting on their certification journey address everything expected of them. It’s from this experience and also from sitting through external audits for our own client certifications that we have seen this approach. I’m sure some auditors may only address the security functions for continuity, but this is what we have personally experienced.

If you are still on your certification journey, looking at certifying, or haven’t yet addressed continuity as part of your existing certification, the key takeaways to address this control are:

• Ensure BIAs have been performed and documented for business processes and assets.
• Ensure BIAs include RTOs, RPOs and resource requirements.
• Ensure risk assessments are completed and cross-referenced with BIAs to prioritise and define continuity requirements.
• Develop continuity plans to address continuity requirements.
• Ensure the organisational structure to support the plans is in place, with personnel that have the requisite skills and authority to perform the tasks assigned to them.
• Ensure plans are approved by management.
• Ensure plans are regularly tested.

And like everything ISO, make sure you have artifacts from all of this so you can prove you actually do what you say, especially for tasks like testing. The auditors will insist on seeing them.

If you need help or just advice in this area, please reach out as we are happy to help or provide advice. It’s a critical area that all businesses should be addressing, irrespective of any relationship you have with ISO/ IEC 27001.