ISO 27001/ISO 22301 documents, presentation decks and implementation guidelines


Free_Downloads
 

Have a question on ISO 27001 or ISO 22301?

Ask an Expert
 

Free eBook

Free eBook 9 Steps to Cybersecurity
 
Becoming Resilient: The Definitive Guide to ISO 22301 Implementation
 
Newsletter
 
Sign up for our free Newsletter and as bonus you'll receive my tips on how to launch an information security and business continuity project.
 
 
 
 
 
 

Recent Posts

 
    

UPCOMING FREE WEBINAR

    

 
ISO 27001 benefits: How to obtain management support

    

Wednesday
April 23, 2014

    Register_now_green
    
 
 
 

Has the PDCA Cycle been removed from the new ISO standards?

By Dejan Kosutic on April 13, 2014

Lately I’ve been receiving (too) many questions asking, “Why did the new revision of ISO 27001 cut out the PDCA cycle?” And, on first sight, you might be misled because the standard really doesn’t mention the Plan-Do-Check-Act cycle explicitly; but, you should read the standard a bit more carefully…

Annex SL of ISO/IEC Directives

Let’s start from the beginning – the International Organization for Standardization has issued ISO/IEC Directives where they describe in Annex SL how the management standards should be structured. This is the required structure, by clauses:

0 Introduction

1 Scope

2 Normative references

3 Terms and definitions

4 Context of the organization

5 Leadership

6 Planning

7 Support

8 Operation

9 Performance evaluation

10 Improvement

So, all the newly published standards like ISO 27001:2013 and ISO 22301:2012 have this identical structure. And all the new revisions of ISO 9001, ISO 14001 and others will have the very same structure.

The intention of the ISO with this Annex SL was, of course, to align all the management standards in order to make them more compatible and enable the integration of management systems in an easier and more convenient way.

What is the PDCA cycle?

For those of you who don’t know what this PDCA cycle is, it is basically a concept developed about 60 years ago by a famous consultant and quality management guru called William Edwards Deming. Essentially, it says the following:

  • Before you start implementing anything, you should know exactly what you really need, and exactly what it is you want to achieve (objectives) – this is the Plan phase.
  • Once you know what you want to achieve, you can start implementing your information security, business continuity, quality procedures, or whatever the ISO standard is focused on – this is the Do phase.
  • However, the whole effort does not stop here – you want to make sure you have achieved what you have planned for, so you need to monitor your system and measure if you achieved your objectives – this is the Check phase.
  • Finally, if and when you realize that what you achieved is not what you have planned for, you have to fill the gap – this is called the Act phase.

Or, using an example – when I purchase a car I have an idea on how much it should cost, what color it should be, maximum fuel consumption, etc. (Plan phase); then I start driving it (Do phase), and realize that the fuel consumption is much higher than expected (Check phase) – then, basically, I have 2 options: to drive more easily in order to consume less fuel, or change the targeted consumption (Act phase).

And, although this concept was developed for quality management, very soon it was realized that it can be applied to any type of management, including information security management or business continuity management.

So, today this concept is so dominating in the management thought that it is virtually everywhere – in every ISO management standard, in every management framework, in every theory. It has become so important that it is impossible to avoid it.

So, did the PDCA cycle really disappear from ISO standards?

No it didn’t. It is still very much incorporated into ISO 27001, ISO 22301 and all other standards, only now the cycle is not expressly displayed in the introduction of the standard as was the case in older revisions.

Here is how you can recognize the PDCA cycle in the structure of ISO standards:

  • Clauses 4 Context of the organization, 5 Leadership, 6 Planning, and 7 Support are nothing but the Plan phase
  • Clause 8 Operations speaks about the Do phase
  • Clause 9 Performance evaluation is, of course, the Check phase, and
  • Clause 10 Improvement is the Act phase

As you can see, the PDCA cycle was not deleted from new ISO standards; on the contrary, it is so important that the Annex SL requires all ISO standards to structure its main clauses around the PDCA cycle.

So, don’t worry, the PDCA cycle is going to stay around for a long time.


How to identify interested parties according to ISO 27001 and ISO 22301

By Dejan Kosutic on April 07, 2014

One of the hot questions these days is related to clause 4.2 in both ISO 27001 and ISO 22301 – Understanding the needs and expectations of interested parties. Actually, their identification is not so complicated, and it gives crucial input for developing your information security management system (ISMS) or business continuity management system (BCMS).

Who are interested parties?

Let’s start with understanding what interested parties are – they are nothing else but stakeholders, i.e., persons or organizations that can influence your information security / business continuity, or persons or organizations that can be affected by your information security or business continuity activities.

So, typically, interested parties could include:

  • employees
  • shareholders/owners of the business
  • government agencies/regulators
  • emergency services (e.g., firefighters, police, ambulance, etc.)
  • clients
  • employee families
  • media
  • suppliers and partners

… and, of course, anyone else that you consider important for your business.

How can you identify them? Just ask your top executives, as well as heads of departments about who is important for their business, and then assess whether they could be interested in your information security or business continuity. Also, chances are that your existing documentation (e.g., business plans) already contains such information.

Why are these interested parties important?

The identification of interested parties is not as important as the second step: identification of their requirements. Here’s why it is important: you need to know what all the interested parties want from you, and you need to figure out how to satisfy all these requirements in your ISMS / BCMS.

For example, shareholders want the security of investment and a good return, clients want you to comply with security clauses in the contracts you signed with them, government agencies want you to comply with information security/business continuity laws and regulations, the media want quick and accurate news related to your incidents, etc. However, you have to be more specific than this – you have to specify exactly which laws and regulations, which security or continuity clauses exist in the contracts, and so on.

The best way to collect this information is to study their written requirements (legislation, contracts, etc.) and/or interview their representatives. (Here you’ll find a list of information security and business continuity laws and regulations.)

Once you have all this information, you will need to “configure” your information security or business continuity to be compliant with your stakeholder expectations – this means you’ll have to identify the requirements before you start developing the details of your ISMS or BCMS.

How is this done?

Good practice is to write a procedure that defines who is in charge of identifying all the interested parties and their legal, regulatory, contractual and other requirements and interests; such a procedure also needs to define who is in charge of updating this information and how often this is done.

If you work in a larger organization, such organizations usually have compliance departments or compliance officers – they would be the most natural department/person to do this kind of a job. If not, you can try to negotiate whether your legal department could do this job – if not them, then you, the information security or business continuity coordinator, will have to do it yourself.

Once the requirements are clearly identified, you need to define who is in charge of complying with them – these responsibilities could be very different: IT department would be in charge of complying with technical requirements, human resources department for, e.g., confidentiality statements, information security coordinator with new policies and procedures, etc.

So, the point is – if you didn’t identify all these stakeholders and their requirements, you would be in danger of falling short of their expectations. And not satisfying your shareholders, or a government agency, could be quite dangerous.

See here an example of  Procedure for Identification of Requirements.


ISO 31000 and ISO 27001 – How are they related?

By Dejan Kosutic on March 31, 2014

Contrary to the popular belief that ISO 31000 is now mandatory for ISO 27001 implementation, this is not true. However, ISO 31000 could be quite useful for ISO 27001 implementation – it not only offers a couple of good guidelines, but it also gives a strategic context for managing (information security) risks.

But, let’s go through the basics first…

What is ISO 31000?

ISO 31000 provides guidelines on how to organize risk management in organizations – the standard is not focused solely on information security risks; it can be used for any type of risks including business continuity, market, currency, credit, operational, and others.

It provides a detailed glossary of risk management terms, explains basic principles of risk management, and provides a general framework including a PDCA cycle (planning, implementing, monitoring and improving – Plan/Do/Check/Act) for risk management. However, being applicable to any type of organization and to any type of risk, it does not provide specific methodology for, e.g., information security risk management.

What is ISO 27001?

ISO 27001 is a standard that describes how a company should organize its information security (read this article for details on ISO 27001) – it is based on risk management principles, meaning that a company should select safeguards (security controls) only if there are unacceptable risks that need to be treated.

So, in effect, you can consider information security to be part of managing the risks in your company as displayed below:

Relationships

As you can see, information security overlaps with cybersecurity, it is strongly related to information technology, and it is entirely part of the risk management in your company.

Relationship between ISO 31000 and ISO 27001

The previous revision of ISO 27001 (from 2005) did not mention ISO 31000, but the new 2013 revision does, and this is what has caused confusion – many people think they have to implement something new in ISO 27001 because of ISO 31000, but this is not true.

Let’s see what exactly ISO 27001 says about ISO 31000:

In clause 4.1, ISO 27001 notes that you could consider the external and internal contexts of the organization according to clause 5.3 of ISO 31000. And, indeed, clauses 5.3.2 and 5.3.3 of ISO 31000 are quite useful in that respect because they provide valuable guidelines on internal and external contexts; however, ISO 27001 mentions ISO 31000 only in a note, which means these guidelines are not mandatory.

In clause 6.1.3, ISO 27001 notes that information security management in ISO 27001 is aligned with ISO 31000. Therefore, ISO 27001 does not say you need to implement risk assessment and treatment according to ISO 31000 – it only says that all the requirements from ISO 27001 are already compliant with ISO 31000. Therefore, you can implement risk management in any way you wish, as long as it is compliant with ISO 27001. (Check also this webinar: The basics of risk assessment and treatment according to ISO 27001.)

And this is it – there is nothing else to it.

ISO 31000 vs. ISO 27005

As mentioned before, ISO 31000 does not offer any specific advice about information security risk assessment and risk treatment; for that purpose, ISO 27005 – a standard that gives guidelines for information security risk assessment and treatment – is much better. It gives you the know-how to identify assets, threats and vulnerabilities, to assess consequences and probability, to calculate risk, etc. And, it is completely compliant with ISO 31000.

So, why would you use ISO 31000? Besides those already mentioned guidelines for identifying internal and external contexts, its biggest value is in providing a framework for managing all kinds of risks on a company-wide level – it can help you turn risk management from some obscure, hard-to-understand issue into a mindset that is easily understood by everyone in the company.

Since ISO 31000 describes how to approach risk management strategically and comprehensively, you can consider this standard to be an excellent framework for Enterprise Risk Management (ERM). So, once you master your information security risk management, you can use it as a foundation for building the ERM.

See here an example of  ISO 27001 Risk Assessment Methodology aligned with ISO 31000.


The most popular ISO 27001 & ISO 22301 blog posts

By Dejan Kosutic on March 24, 2014

This is my 100th blog post! When I started this blog four years ago, I never dreamed I would have that many things to write about… And yet, the more I write, the more ideas I have – right now, I have at least 10 new topics in mind.

But this time I won’t write anything new; perhaps this is a good occasion to summarize the most popular articles from this blog. So, here they are:

General articles on information security and business continuity:

ISO 27001 articles:

ISO 22301 articles:

If you’d like to receive new blog posts automatically, subscribe to our ISO 27001 & ISO 22301 Newsletter or RSS feed. And now, let’s go for article number 200!


Risk assessment vs. business impact analysis

By Dejan Kosutic on March 17, 2014

If you are implementing ISO 27001, or especially ISO 22301 for the first time, you are probably puzzled with risk assessment and business impact analysis. What is their purpose? How are they different? Can they be performed at the same time?

In short, risk assessment will show you which kinds of incidents you might face, while business impact analysis will show you how quickly you need to recover your activities from incidents to avoid larger damage.

The purpose of risk assessment (RA)

The purpose of this assessment is to systematically find out which incidents can happen to your organization, and then through the process of risk treatment to prepare in order to minimize the damage of such incidents.

It is very important to understand that risk assessment and treatment (mitigation) need to be performed sequentially – you cannot implement the safeguards/controls unless you know which of them are the most appropriate; you cannot know which safeguards are appropriate before you find out where the potential problems are. See also ISO 27001 risk assessment & treatment – 6 basic steps.

In my experience, the employees (and the organization as a whole) are usually aware of only 25 to 40% of risks – therefore, it is not possible to try to remember all the risks by heart, and this identification needs to be done in a systematic way.

Risk assessment is mandatory for both ISO 27001 and ISO 22301, and in most cases it can be done for both standards at the same time: Can ISO 27001 risk assessment be used for ISO 22301?

The purpose of business impact analysis (BIA)

The purpose of this analysis is primarily to give you an idea (1) about the timing of your recovery, and (2) the timing of your backup, since the timing is crucial – the difference of only a couple of hours could mean life or death for certain companies if hit by a major incident. For example, if you are a financial institution, recovery time of four hours could mean you will probably survive a disruption, whereas recovery time of 12 hours is unacceptable for certain systems/activities in a bank, and disruption of a full day would probably mean such a bank would never be able to open its doors again. And there is no magic standard which would give you the timing for your organization – not only because the timing for every industry is different, but also because the timing for each of your activities could be different. Therefore, you need to perform the business impact analysis to make correct conclusions.

More precisely, business impact analysis will help you determine the Maximum Acceptable Outage/Recovery Time Objective, Maximum Data Loss/Recovery Point Objective, required resources and other important information that will help you develop the business continuity strategy for each of your activities. Learn more here: How to implement business impact analysis (BIA) according to ISO 22301.

As you might have guessed, business impact analysis is mandatory for ISO 22301 implementation, but not for ISO 27001.

The difference between the two

As already concluded, BIA is usually used only in business continuity / ISO 22301 implementation; it could be done for information security, but it wouldn’t make much sense. Risk assessment is mandatory for both.

Secondly, the outputs from RA are a bit different from those of BIA – RA gives you a list of risks together with their values, whereas BIA gives you timing within which you need to recover (RTO) and how much information you can afford to lose (RPO).

So, although these two are related because they have to focus on the organization’s assets and processes, they are used in different contexts.

Which comes first – risk assessment or business impact analysis?

Actually, ISO 22301 allows both approaches, and you might hear many theories on which is better. However, I prefer to do risk assessment first because this way, you will have a better impression of which incidents can happen (which risks you’re exposed to), and therefore be better prepared for doing the business impact analysis (which focuses on consequences of those incidents); further, if you choose the asset-based approach for risk assessment, you will have an easier time identifying all the resources later on in the business impact analysis. What you definitely shouldn’t do is perform risk assessment and business impact analysis at the same time, because each of them separately is already complex enough – combining them normally means trouble.

To learn more about risk assessment, register for this free webinar The basics of risk assessment and treatment according to ISO 27001.