ISO 27001 & ISO 22301

Why would you need a Policy once you have Business impact analysis, Business continuity strategy and Business continuity plan? This is probably a question many experienced business continuity/disaster recovery practitioners are asking themselves, so here’s why ISO 22301 (a leading business continuity management standard) says it’s mandatory.

Main purpose

The main purpose of Business continuity policy is that the top management defines what it wants to achieve with business continuity. Now why would that be important? Because in many cases the executives have no idea how business continuity can help their organization, which means they won’t be particularly interested in supporting the business continuity effort in their company.

And this lack of interest is the main problem for business continuity practitioners – therefore, by requiring a policy to be written, ISO 22301 is taking a first step toward creating this recognition in the eyes of top management.

The second purpose is to create a document that the executives will find easy to understand, and with which they will be able to control everything that is happening within the BCMS (Business Continuity Management System) – they don’t need to know the details of, say, risk assessment or business impact analysis, but they do need to know who is responsible for BCMS, and what to expect from it.

The content required by ISO 22301

Basically, ISO 22301 doesn’t say too much about the policy, but it does say the following:

• The policy needs to be adapted to the organization – this means you cannot simply copy the policy from a large manufacturing company and use it in a small IT company.
• It needs to define the framework for setting business continuity objectives – basically, the policy needs to define how the objectives are proposed, how they are approved, and how they are reviewed.
• The policy must show the commitment of top management to fulfill the requirements of all interested parties, and to continually improve the BCMS – this is normally done through some kind of a statement.
• It must be communicated within the company, but also – where appropriate – to interested parties; best practice is to define who is responsible for such communication, so that it is done continuously.
• The policy must be regularly reviewed – an owner of a policy should be defined, so that this person can make sure it is kept up to date.

So, as you can see, the policy doesn’t have to be a very long document. However, it is useful to include the following:

• The scope of the BCMS – this way the scope doesn’t have to exist as a separate document.
• Responsibilities for key parts of the BCMS – e.g. who is responsible for the day-to-day operations and coordination, who is responsible on the executive level, etc.
• Measurement – who will measure whether the business continuity objectives have been achieved, to whom the results need to be reported, how often, etc.

The link between the top management and the business continuity

So, Business continuity policy should actually serve as a main link between your top management and your business continuity, especially because ISO 22301 requires the management to ensure that “BCMS is compatible with the strategic direction of the organization” (clause 5.2). I would argue that the policy is probably the best way to do this.

Business continuity policy by itself will not resolve all the problems in business continuity implementation; but, a properly written policy will certainly make the job of a business continuity professional much easier.

Click here to download a free preview of Business Continuity Policy template.

I was quite skeptical when I started to read ISO 22313, the guidance standard on business continuity management, but I was proved to be wrong. It can be quite useful as a supplement to ISO 22301 – here’s what I found:

Similarities and differences

If you are familiar with ISO 27001 and ISO 27002 (see ISO 27001 vs. ISO 27002), a very similar relationship exists between ISO 22301 (published in May 2012) and ISO 22313 (published in December 2012): ISO 22301 is the main standard, which defines the framework for business continuity management, whereas ISO 22313 is an auxiliary standard that helps with the ISO 22301 implementation.

The main difference is that ISO 22301 specifies requirements – in other words, you need to comply fully with everything that is written in this standard if you want to get your company certified. This is why this standard uses words like “shall” and “must.” Learn more here: 17 steps for implementing ISO 22301.

As opposed to that, ISO 22313 gives only the guidance, or best practices, on how the requirements from ISO 22301 could be implemented; however, implementation doesn’t have to be done exactly that way. You’ll notice that terminology here is different – “should” and “may” are used. Consequently, a company can be certified only against ISO 22301, not against ISO 22313.

Where is ISO 22313 particularly useful?

My impression is that ISO 22313 is most helpful in these sections, because this is where ISO 22301 is not very detailed:

• Description of strategy options for resources (clauses 8.3.1 and 8.3.2): suggested strategic options for protecting prioritized activities, suggested strategies for resources/activities, suggestion on what can be excluded from the BCMS scope based on cost of mitigation, options to mitigate the impact and duration of an incident, techniques for evaluating business continuity capabilities of suppliers, types of resources an organization should establish, resources strategies for people, what to take into account for procedures of relocation of staff, explanation on when RPO is used, suggested backup types, strategies for worksites, facilities and supplies strategies, strategies for ICT systems, strategies for transportation, suggestion of finance needed during an incident, etc.
• Content of business continuity procedures/plans (clause 8.4): what to include in incident communication procedures, what to include in business continuity procedures, content of business continuity plans, location for incident management team, content of the communication procedure, elements of safety and welfare procedures, list of resources that may be required for the welfare of employees, content of salvage and security procedures, content of procedures for resuming activities, content of ICT continuity procedures, etc.

Here are also a few clauses where ISO 22313 gives useful guidance for implementation:

• 4.2.1 – Figure 4 – examples of interested parties
• 4.2.2 – list of legislation that should be taken into account
• 5.3 – list of items to write in Business continuity policy
• 5.4 – explanation of BCMS roles and responsibilities
• 6.2 – examples of goals for the  BCMS
• 7.1 – BCMS resources that are required
• 7.2 and 7.3 – competence development program, types of trainings, types of teams, what to include in awareness programs, etc.
• 7.5.1 – list of all documentation required by the standard
• 8.1.4 – examples of metrics that may be used for measuring the effectiveness of BCMS
• 8.2.2 – elements of assessing the impact in BIA
• 8.2.2 – explanation of RTO and what it is used for
• 8.2.3 – typical elements to be included in risk assessment
• 8.4.5 – content of assessment procedure for determining the impact and tasks needed
• 8.5.2 – content of exercise program
• 8.5.3 – suggested objectives for the business continuity exercises
• 9.1.2 – checklist of what evaluation of business continuity procedures should verify
• 9.1.2 – content of post-incident review

In any case, unless you are an experienced BCM consultant and/or implementer, I would recommend getting both of these standards. They may be expensive, but return on investment will be quite quick.

Click here to download a free preview of Business Continuity Plan template.

Implementing business continuity is certainly not an easy task, so I hope this list of 17 steps will help you get an overview of mandatory steps as required by ISO 22301. Please note – these are the steps that are required to implement the standard, while additional steps will be required to maintain the system once it is in place.

1. Management support

It doesn’t make sense to start any kind of project (especially this one) if your management isn’t willing to invest both financial and human resources, and to do this, they have to see clear benefits – this is where your job begins: with diplomacy.

2. Identification of requirements

Before taking any concrete steps you want to make sure you’ll be compliant with everything the stakeholders (at least the ones you consider important) want from you. Remember, it is not only the laws and regulations – it is also the requirements in the agreements with your clients (e.g., SLAs), wishes of the owners of the company and the local community, etc. You have to list all of these requirements and define how to communicate with each of the stakeholders/interested parties.

3. Business continuity policy & objectives

Top management needs to define some of the main responsibilities and rules for business continuity, and this is what a business continuity policy is used for, but top management also needs to define exactly what is expected from business continuity – by setting measurable objectives. This is not easy, but is certainly necessary if you want to measure whether business continuity has fulfilled its purpose.

4. Support documents for management system

Managements systems, whether business continuity, information security, quality management or environmental protection, all have in common a set of procedures upon which such systems rely. These procedures are: documents and records control, internal audit, and corrective actions – once you have these in place, you’ll find it much easier to run your system.

5. Risk assessment & treatment

Would you like to be prepared for disruptive incidents? Perhaps even prevent some of them? First you need to find out which incidents can happen, and then define which controls (i.e., safeguards) you can apply to mitigate them – this is basically what risk assessment and treatment is all about.

To learn more read ISO 27001 risk assessment & treatment – 6 basic steps.

6. Business impact analysis

Your analysis doesn’t finish with risk assessment – you also need to find out two basic things: (1) how quickly you need to recover (before you go bankrupt), and (2) what you need in order to succeed with such recovery. Therefore, the purpose of business impact analysis is to define the recovery time objective (RTO) and required resources.

To learn more, read Five Tips for Successful Business Impact Analysis.

7. Business continuity strategy

Given the inputs (various requirements, RTO, resources, most likely incidents) you need to figure out how to achieve all this with a minimum level of investment. This can be quite demanding, but without this step your business continuity would be simply a house of cards.

Find out how to do it here: Can business continuity strategy save you money?

8. Business continuity plan

Actually there are several types of BC plans – as a minimum there are incident response plans (they define the initial reaction to an incident), and recovery plans (what needs to be done to start the activities running). All of these need to be based on strategy, because otherwise they would lack the resources (information, technology, people, etc.) to enable such plans.

This article will help you write them: How to write business continuity plans.

9. Training & awareness

Having plans in place is not enough – if no one knows how to implement them (or where to find them!), you can rest assure that in case of a real incident they certainly wouldn’t work. Therefore, you need to explain to your employees (and third parties who have a role in your plans) not only how to perform certain steps in your plan, but also why this is important in the first place.

10. Documentation maintenance

Written documents have one nasty habit – they become outdated very quickly. Someone leaves the company, or new hires come in; you change the working processes or a technology, you add new products – all that needs to be reflected in your documentation, especially the plans. Without such changes you wouldn’t be able to implement your plans when they are needed the most.

11. Exercising & testing

However necessary, training is not going to be enough – if you don’t try the plans to discover how they perform in (almost) real situations, you’ll never know where they are deficient. So performing regular exercising and testing is of paramount importance, and such testing shouldn’t be limited to IT only – everyone, including top management and outsourcing partners and suppliers, must be included.

12. Post-incident reviews

No matter how hard you try, you’ll never be able to prevent incidents from happening; what you can do, however, is learn from such incidents. And you can learn quite a lot – how people react, how ready they are, what improvements are needed in the plans, etc., and most importantly – did you achieve your recovery time objective?

13. Communication with interested parties

This is actually not a 13th step (not that I try to avoid this one), because this is a step that should run in parallel to all the other steps. This is because business continuity heavily depends on regulatory bodies, authorities, owners, employee’s families, media, etc., and you need to keep these interested parties informed as early as when you write your policy and set the objectives, all the way to when an incident actually occurs.

14. Measurement and evaluation

The basic idea here is – it doesn’t make sense to do something unless you know whether you’ve achieved what you wanted or not. In the case of business continuity, the objectives are set in step #3, while finding out if you achieved those objectives must be done through some kind of metrics. It could be something sophisticated like Balanced Scorecard, but could also be as basic as measuring the achievement of RTO during exercising & testing.

15. Internal audit

It is impossible to be 100% objective about your own work. Therefore, someone who is less subjective than you should review your work and suggest improvements – that is what an internal audit is all about. Though it is often considered as overhead, an internal audit is actually very useful when it comes to facing reality.

16. Corrective actions

All of us are making daily improvements in the things we are doing, but ISO 22301 wants us to do it systematically – it forces an organization to find out why the problem has happened, and to make sure it never happens again. Or, as the standard says, “ensure that nonconformities do not recur” – it needs to be done systematically, and in a transparent way.

17. Management review

Once all of these steps are performed, top management needs to evaluate them and reach some crucial decisions – like updating the objectives, providing the funding, making larger improvements, etc. After all, it is their ultimate responsibility that the company survives larger incidents.

As mentioned in the introduction, this step is not where your business continuity management stops – you need to maintain and improve your system on an ongoing basis. However, if you need a point where you can say your ISO 22301 project is finished, and that you’re ready for the certification, this last step would be it.

Here you can download free Diagram of ISO 22301 Implementation Process.

—

If this is the first time you have come across the notion of internal auditor, you are probably puzzled – Why would I need another control? Who is going to pay for it? Who should I employ to do it? It is such a waste of time…

Well, it doesn’t have to be so bad – besides complying with ISO 27001 & BS 25999-2 standards, internal audits could be quite useful for your other business affairs (whether related to information security & business continuity or not).

The point with internal audits is that they should discover problems that would otherwise stay hidden and would therefore harm the business. Let’s be realistic – it is human to make mistakes, so it‘s impossible to have a system with no mistakes; it is however possible to have a system which improves itself and learns from its mistakes. Internal audits are a crucial part of such a system.

There are a few ways to perform internal audit:

a) Employ a full time internal auditor – this is suitable only for larger organizations who would have enough work for such a person (some types of organizations – e.g. banks – are obliged by law to employ such functions)

b) Employ part time internal auditors – this is the most common situation – the organizations use their own employees to perform internal audits alongside their regular job functions. One important thing to pay attention to: in order to avoid conflict of interest (the auditors cannot audit their own work), there should be at least two internal auditors so that one could audit the regular job of the other.

c) Employ internal auditor from outside of the organization – although this is not a person employed in the organization, it is still considered internal audit because the audit is performed by the organization itself, according to its own rules. Usually this is done by a person who is knowledgeable in this field (independent consultant etc.).

However, from my experience as an auditor, the sad truth is that most of the organizations perform internal audits just to satisfy the certification body. The result of such internal audits are a few non-conformities which do not get deep into the real problems of information security management system (ISMS) or business continuity management system (BCMS). This is a waste of time – if the companies have invested time of their internal auditors to perform such jobs, they should gain some benefits out of it.

But how then to approach internal audits in the right way – here are some thoughts:

1. The management should view the internal audit as one of the best tools to improve the system, not only as a means to get certified.
2. The internal auditor should be qualified – this means he/she must have experience in information security, information technology and auditing techniques. It does not mean that the auditor must be an expert in those fields.
3. The internal audit should be performed in a positive way – the aim should be to improve your system, not to blame the employees for their mistakes.

On the positive side, as a certification auditor I did see some organizations performing internal audits in a right way. Although their employees did feel a little uncomfortable about someone checking their activities, very soon they saw the benefits of such approach – problems became transparent, and were resolved rather soon.

You can also check out our video tutorial How to Write ISO 27001/ISO 22301 Internal Audit Procedure and Audit Program (commercially sold video).