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.

Did you think that the frequency of backup is based on the IT manager’s whims? Or, perhaps, based on the least expensive solution? Well, you are wrong.

Backup policy, or to be precise – the most important part of this policy – how often the backup is to be performed, must be based on analysis. And such analysis must be based on the business value of the data in question.

Recovery Point Objective (RPO) / Maximum Data Loss

This analysis is emphasized in ISO 22301, the leading business continuity standard. It specifies that Recovery Point Objective and Maximum Data Loss have the same meaning: “Point to which information used by an activity must be restored to enable the activity to operate on resumption.” This is basically the answer to the question How much data can you afford to lose?

The easiest way to perform this kind of analysis is during the business impact analysis (BIA), because that is when you have to complete all these interviews/questionnaires, so a couple more questions won’t disturb anyone. (Read also: Five Tips for Successful Business Impact Analysis.)

Best practice for BIA

When performing the BIA, you have to ask your respondents to list all their databases, applications and files, but also all services (e.g. email), etc., and for each of them separately to state the acceptable limit up to which you can afford to lose the data. Usually, this limit is displayed in number of hours, but sometimes it can also be in number of transactions or records.

The main criteria while doing the analysis must be the damage of any potential data loss to the company – in terms of money or other impacts like legal, reputation, etc. Also, while doing such analysis it is important not to be distracted by the fact that you already have the backup. The question is – if your existing backup fails, how much data can you really afford to lose?

The result is RPO/Maximum Data Loss – in some cases it will be 24 hours (the data you created in the last 24 hours), in others, perhaps 2 hours, but sometimes you won’t be able to afford the loss of a single bit of information – this is where RPO is zero.

Implications for backup frequency

Let’s take two examples from a bank – in the first example, in the loan application process, the bank can probably afford to lose 24 hours of data, because it won’t be very difficult to recreate the data by asking potential clients to send that information again. However, in the case of payment processing, the banks typically cannot afford to lose a single transaction – this is because of the huge volume of transactions and the inability to track back who has given which payment order if all the data is lost.

The conclusions here are actually very simple – if the analysis shows that the RPO/Maximum Data Loss is 24 hours, then you have to perform backup at least once a day; if the RPO is 2 hours, then backup has to be done at least every two hours; if RPO is zero, then you need to have a mirrored site with replication of data in real time.

But, as always, there is also the question of price – someone may say that doing the backup every 2 hours is too expensive. While this may really be so, the real question is what would be the damage to the whole business if you really lose all this data.

Click here to download a free preview of Business Impact Analysis Questionnaire template.

If you’re implementing ISO 27001 or ISO 22301 for the first time, you’re probably considering hiring a consultant to help you. But, which consultant should you hire, what are the potential problems, and how much should you pay?

The purpose of an ISO 22301/ISO 27001 consultant

A consultant should shorten your implementation time – he should provide you all the know-how for the implementation, and help you avoid numerous pitfalls during the project. He should lead you step by step throughout your project, and give you a precise idea of what the certification auditors will be looking for.

If your arrangement includes on-site consulting, a consultant can make all the necessary analysis, recommend the best solutions, write the documentation, train your employees, etc. In other words, he can take part of the workload off of your staff.

Potential problems with consultants

However, hiring a consultant carries some risks, too:

• The consultant will be able to see your most critical information, including the areas where you are most vulnerable.
• If a consultant is selling some software or some other solutions, you can expect he will use knowledge of your company to convince that his solution is just what you need. (He might even offer you lower consulting price with this goal in mind.)
• If a consultant is doing all the analysis and documentation writing by himself (with no interference of your employees), two things will probably happen: (1) the documentation will not reflect the real needs of your company, and (2) once the consultant is gone, your employees won’t know how to maintain the documentation – both of these have the same result: the documentation won’t really be useful in daily operations, and employees will probably reject it.
• There are many people claiming to be consultants, but in fact they know very little about this job. In most countries, there is no license needed for doing this job, so practically anyone can declare he or she is a consultant.

Thinking about it, a question arises whether you need a consultant at all – read more about it here: Do you really need a consultant for ISO 27001 / BS 25999 implementation?

If you do decide to hire a consultant, make sure you address all the above-mentioned issues in the project plan, and address them specifically (and in writing) within your contract agreement.

Criteria for choosing a consultant

So, based on all these issues, which criteria should you use?

1) Experience & skills. Do your research, not only about the consulting company, but also about the person who would do the consulting job – does she have certificates like ISO 27001 Lead Auditor Course, or ISO 27001 Lead Implementer Course (same for ISO 22301)? How many jobs has she performed; how long has she been in this business? Which kind of companies did she work for? E.g. if she did only banks, she is hardly the right choice for an IT company.

2) Reputation. By far, the best thing is to call the clients the consultant claims she has worked with – very often you’ll be surprised that the job she was working on was far smaller in scope than you were led to believe, and sometimes the customers won’t speak favorably about the service they received. Also, if a consultant has published some books or articles on a subject, or if she is a frequent speaker at conferences, chances are you’ll make a good choice.

3) Customized service. Avoid the “copy-paste” consultants – they will bring you finished templates and contribute nothing to them. (You would be better off doing the implementation by yourself with our Documentation Toolkit.) Actually, you’ll learn quite a lot about the willingness of a consultant to tailor the service for your specific needs during the negotiation period. If you feel she is not adaptable enough, or you don’t like her communication style, walk away from this deal.

4) Language. Choosing a consultant that doesn’t speak your local language (or speaks it poorly) probably leads to disaster. Don’t expect that a translator will help you with this problem – the job of a consultant is to understand all the nuances of your operations, and that cannot be done via a third person.

5) Conflict of interest. Hire a consultant who sells only this – consulting services. Avoid those who offer other security or IT solutions, unless you want to be an upsell target.

Pricing

There is a good reason why I didn’t write that price should be one of your criteria – many times I’ve seen companies choose the least expensive consultant, only to find out later that was actually the most expensive option. The cheapest consultants usually don’t have enough work to do, so this is why they offer the lowest prices – they want to survive in the market. But, the important question here is – why don’t they have enough work? Because they’re new to this market, and don’t have enough experience? Or because they have a not-so-good reputation, so many clients are avoiding them? Think about this when you’re making your decision.

Of course price is important, but you have to calculate the total price of the project – and usually the price premium of a good consultant will be far less than the savings such consultant will bring you.

This being said, although a consulting price is usually based on man/days, it is far better to agree on a total price for the whole project – this way the risk is on the consultant, not you. If a consultant claims he cannot anticipate the amount of work needed, let him do a pre-agreement analysis – if he cannot estimate the amount of work, maybe he doesn’t have enough experience.

And remember – the ultimate purpose of a consultant is to save your time.

Click here to see a description of ISO 27001 & ISO 22301 Premium Documentation Toolkit.

A few days ago I received the following question from one of our clients: “What is the difference between ISMS Risk Assessment and BCM Risk Assessment?” And, although the answer to this question might seem easy, in actuality it is not.

Here’s the rest of his question: “… Because on your blog I found that if I’ve done ISMS it should be fine for BCM. On the other hand, ISO 22301 recommends to use ISO 31000 standard.”

Why ISO 27001 risk management framework is a good solution

It is true that ISO 22301 refers to ISO 31000 regarding risk assessment, but ISO 31000 is written very generally since it covers all kinds of risks (not only business continuity, but information security, financial, market, credit, and other risks).

On the other hand, risk assessment framework is described much better in ISO 27001, and even more precisely in ISO 27005; the focus of information security risk assessment is on preserving confidentiality, integrity and availability. And availability is the key link between information security and business continuity – when performing ISMS risk assessment, all the business continuity risks will be taken into account.

And the good thing is, risk assessment as it is described in ISO 27001 and ISO 27005 is perfectly aligned with ISO 31000.

Possible differences in approach

But this is where it might get complicated – my client had another question because he wanted everything to be cleared out: “I think that another difference between those two Risk Assessment approaches is – with ISMS we deal with assets (both primary and supportive); however, with BCM we deal with critical activities and processes.”

And he was basically right – business continuity risk assessment does not have to be so detailed; it can be made high-level for activities and processes. But, although this approach is fine from the point of view of the standard itself, in my view the problem is in the implementation – how would you mitigate the risks if you don’t know exactly where the problems are?

This is where I think ISO 27001 risk assessment framework is better – it forces you to pinpoint where the weaknesses are, which assets should be protected better, etc. If you kept the risk assessment on the process level you probably wouldn’t get all this valuable information.

Risk mitigation compatibility

It is worth mentioning here – ISO 27001 risk treatment options are completely aligned with risk mitigation requirements in ISO 22301 and ISO 31000. Basically, business continuity mitigation comes down to 4 options described in ISO 27001: (1) applying appropriate controls, (2) accepting risks, (3) avoiding risks, and (4) transferring risks. There are no options listed in ISO 22301, while in ISO 31000 they are named a bit differently and organized a bit differently, but they are essentially the same:  changing the likelihood and the consequence, retaining the risk, avoiding the risk, and sharing the risk.

Further, ISO 22301 requires you to “plan actions to address these risks and opportunities,” while ISO 27001 asks for developing the Risk Treatment Plan – again, very similar requirement­ with a slightly different name.

And to finish with this: there is another good thing about ISO 27001 – in Annex A it gives you a catalogue of possible safeguards to choose from; this is something that neither ISO 22301 nor ISO 31000 has.

Hope I managed to persuade him. What do you think?

Click here to see a Risk Assessment and Treatment Methodology template.