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 & ISO 22301/BS 25999-2: Why is it better to implement them together?

    

Wednesday
May 7, 2014

    Register_now_green
    
 
 
 

Risk owners vs. asset owners in ISO 27001:2013

By Dejan Kosutic on April 21, 2014

The 2013 revision of ISO 27001 introduced a new concept: the risk owner. Since this concept brought quite a lot of confusion with information security practitioners, here’s an explanation of what the risk owner is, and whether the concept of asset owner from the old 2005 revision of ISO 27001 is still valid.

What is the asset owner, according to ISO 27001?

Both the old 2005 and new 2013 revisions of ISO 27001 have the concept of asset owner as a control in Annex A – this is basically nothing but determining who is responsible for each asset in your company. In terms of information security, assets are not only the information in electronic and paper form, but also software, hardware, services, people, facilities, and everything else that provides value to an organization.

Why is this asset ownership important? Because if no one is responsible for an asset then no one will take care of it – only by strictly defining who is responsible for each document, each server, each external service, etc. will you make sure that each of those assets is properly protected and managed; not having owners of the assets would mean anarchy.

Assed-based risk assessment

Where the 2005 and 2013 revisions are different is that 2005 required the identification of asset owners both during the risk assessment process and as control A.7.1.2 in Annex A, whereas the 2013 revision doesn’t have this requirement in the risk assessment process and only as control A.8.1.2 in Annex A.

What’s more, the 2013 revision does not require so-called asset-based risk assessment, which would identify the risks based on assets, threats and vulnerabilities – according to ISO27001:2013, your company can identify risks using some other (less complicated) method.

However, my opinion is that asset-based risk assessment will continue to be a dominant method for risk assessment – especially if you choose to apply controls A.8.1.1 (identification of assets) and A.8.1.2 (assigning the owners to those assets). If you do list those assets, then you have already done a good part of asset-based risk assessment; in such case, even in the 2013 revision it makes sense to list assets (and their owners) during the risk assessment process.

What is the risk owner according to ISO 27001?

So then, what is the risk owner? ISO 27000:2014 defines the risk owner as a “person or entity with the accountability and authority to manage a risk.” Basically, this is a person who is both interested in resolving a risk, and positioned highly enough in the organization to do something about it.

So, for instance, an asset owner of a server might be the IT administrator, and a risk owner for risks related to this server might be his boss, the head of the IT department. The IT administrator will manage the server on a day-to-day basis, while the head of the IT department will take care of, e.g., investing in better protection, providing training to the IT administrator, etc.

In my opinion, the concept of risk ownership was introduced because very often, the asset owners did not have enough authority to resolve potential risks; besides, this concept also exists in ISO 31000, so this way ISO 27001:2013 was made compliant with ISO 31000.

How to choose the risk owners

When choosing risk owners, you should aim for someone who is closely related to processes and operations where the risks have been identified – it must be someone who will feel the “pain” if the risks materialize – that is, someone who is very much interested in preventing such risks from happening. However, this person must be also positioned highly enough so that his or her voice would be heard among the decision makers, because without obtaining the resources this task would be impossible. So, it seems to me that mid-level managers are often the best candidates for risk owners.

Even though the standard allows an entity to be a risk owner (e.g., a department or a business unit), I would not advise it – it is always better to have one individual who is in charge of resolving a problem than to have a group of people. For instance, if the head of the IT department is responsible for resolving the risk, it will be done much more quickly than if you had the whole IT department responsible for the same risk.

When it comes to appointing the risk owners, it is best done through the Risk treatment plan, since this is an action plan on how to resolve the risks – you should simply define for each risk who is responsible for implementing the controls. Read also Risk Treatment Plan and risk treatment process – What’s the difference?

To conclude, companies should determine both risk owners and asset owners when implementing ISO 27001 – the easiest way would be to determine them during the risk assessment process. And, by doing this properly, the implementation and operation of their information security will be a much easier job.

Click here to register for a free webinar The basics of risk assessment and treatment according to ISO 27001.


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!