This article analyzes what has changed in the ISO 27002 series of standards regarding business continuity.
Introduction
This article discusses the possible overlap between two disciplines that are quite related to each other, although each one has its own specific area: information security and business continuity. In particular, it analyzes how the two reference standards (ISO 27001 and ISO 22301) are overlapped or not.
In a separate article I will discuss where the two worlds come together and how the implementation of both standards can be carried out without falling into unnecessary redundancies.
The reason for writing this article is because, on many occasions, I have been told things like:
- “If I have a certified ISMS, then I already have business continuity.”
- “For an organization to comply with the controls of Chapter 17 of ISO 27002, it is enough that it has a BIA and a DRP.”
The above statements are, in my opinion, incorrect and are based on a number of reasons, including, principally, the following:
- Misunderstanding or limited understanding of what business continuity really is.
- The modification of the ISO 27001/27002 standards in this aspect.
The first of these reasons is quite common, since, unlike other countries in which business continuity is very widespread, in Spain there are very few sectors, basically the financial sector, that require its implementation. I do not intend, nor could I, to solve this lack in a single article, although I do encourage you to consult the excellent publications on the subject found in this forum.
Turning to the second reason, let us first analyze how business continuity has been handled by the different versions of the ISO 27001 and ISO 27002 standards, and how what is expressed there continues to drag on to date, although what is now requested has changed considerably.
First, we will move back a few years.
Background information
The current ISO 27002 dates from 2013 in its English version, but comes from a long line of standards, some already ISO, but others were the venerable BS7799, the first of 1999.
Well, in all of them, up to ISO 27002 in 2005, there was a set of business continuity controls through which the organization was required to implement something similar to a business continuity management. For example, it was requested that:
- The organization should have a complete continuity management framework
- That impact and risk analyses should be carried out.
- That continuity plans should be written.
- That these should be tested regularly.
So auditors, when verifying whether these controls were applied, requested, for example, the BIAs, a Contingency Plan and evidence that it had ever been tested.
However, and this is a personal opinion, the business continuity requirements set out in ISO 27002 were slightly confusing and incomplete.
These shortcomings were replaced by other standards, then in “British Standard” format (BS 25999-1/2), which provided much of the background for a new international business continuity standard, ISO 22301 in 2012.
Consequently, when it was time to review ISO 27002, it no longer made sense to come and request what was already requested in another standard, so its 2013 version introduced relevant changes.
Current situation
And what has changed? After all, many will say, there is still a demand for business continuity, or that’s what it seems, isn’t it? The truth is that things have taken an interesting twist.
Moving on to the requirement of the standard itself: Section 17.1 states as an objective that “information security continuity should be part of the organization’s business continuity management systems”.
To be specific, control 17.1.1 states that “the organization should determine its information security and continuity needs for information security management in adverse situations, for example, during a crisis or disaster”.
Imagine, for example, a bank that decides to address business continuity, starting by identifying important a priori business functions and then carrying out the corresponding BIAs. Suppose that these functions include the areas of Investments, Customer Service, Mortgage Management, Anti-Fraud, etc.
Moreover, the bank has a well-defined contingency strategy and, in the case of unavailability of its headquarters, has alternative offices to which to move the critical staff of those business functions, with the infrastructure, communications and systems necessary to recover the operation in a few hours.
However, this bank has deployed a SIEM that constantly monitors its infrastructure and operations, and a team of people who handle internal and external security incidents on a 24×7 basis, as well as managing and operating the security infrastructure (firewall, AV, IPS, etc.). These personnel do not have an alternative location assigned in the contingency offices, not to mention that some of the security elements are not redundant either.
As sometimes happens, these “ICT” tasks have not been considered important and therefore have not been analyzed. However, had they been carried out, they would have shown as critical; for operational and compliance reasons, the bank cannot operate without SIEM or the incident management and security management service, as the fraud levels could rise, among other undesirable consequences.
So this organization would not be following ISO 27002, because the basic question has not been asked: “What impact would it have if the tasks in the area of information security were interrupted?”.
We are not saying that, necessarily, information security must be placed at the same level as the most critical of the organization’s activities. Information security must be included in the analysis, strategies must be defined in line with the RTO and RPO, there should be plans for recovery, and it should be part of the contingency testing program.
So, the situation is quite simple: to see if a company complies with the controls in section 17.1 of ISO 27002:2013, we should look whether the information security aspect is included in the list of organizational areas to which business continuity applies, if only to conclude that, in the event of a contingency, the organization can continue functioning without the infosec function (what I find rather strange).
