ISO 27001 Implementation and associated processes
BY: DESTINY YOUNG
If you are starting to implement ISO 27001, you are probably looking for an easy way to implement it. Let me disappoint you: there is no easy way to do it. However, I’ll try to make your job easier – here is the list of sixteen steps you have to go through if you want to achieve ISO 27001 certification:
1. Obtain management support
This one may seem rather obvious, and it is usually not taken seriously enough. But in my experience, this is the main reason why ISO 27001 projects fail – management is not providing enough people to work on the project or not enough money.
2. Treat it as a project
As already said, ISO 27001 implementation is a complex issue involving various activities, lots of people, lasting several months (or more than a year). If you do not define clearly what is to be done, who is going to do it and in what time frame (i.e. apply project management), you might as well never finish the job.
3. Define the scope
If you are a larger organization, it probably makes sense to implement ISO 27001 only in one part of your organization, thus significantly lowering your project risk. (Problems with defining the scope in ISO 27001)
4. Write an ISMS Policy
ISMS Policy is the highest-level document in your ISMS – it shouldn’t be very detailed, but it should define some basic issues for information security in your organization. But what is its purpose if it is not detailed? The purpose is for management to define what it wants to achieve, and how to control it.
5. Define the Risk Assessment methodology
Risk assessment is the most complex task in the ISO 27001 project – the point is to define the rules for identifying the assets, vulnerabilities, threats, impacts and likelihood, and to define the acceptable level of risk. If those rules were not clearly defined, you might find yourself in a situation where you get unusable results.
6. Perform the risk assessment & risk treatment
Here you have to implement what you defined in the previous step – it might take several months for larger organizations, so you should coordinate such an effort with great care. The point is to get a comprehensive picture of the dangers for your organization’s information.
The purpose of the risk treatment process is to decrease the risks, which are not acceptable – planning to use the controls from Annex A usually does this.
In this step, a Risk Assessment Report has to be written, which documents all the steps taken during risk assessment and risk treatment process. Also, an approval of residual risks must be obtained – either as a separate document or as part of the Statement of Applicability.
7. Write the Statement of Applicability
Once you finished your risk treatment process, you will know exactly which controls from Annex A you need (there are a total of 114 controls but you probably wouldn’t need them all). The purpose of this document (frequently referred to as SoA) is to list all controls and to define which are applicable and which are not, and the reasons for such a decision, the objectives to be achieved with the controls and a description of how they are implemented.
The Statement of Applicability is also the most suitable document to obtain management authorization for the implementation of ISMS.
8. Write the Risk Treatment Plan
Just when you thought you resolved all the risk-related documents, here comes another one – the purpose of the Risk Treatment Plan is to define exactly how the controls from SoA are to be implemented – who is going to do it, when, with what budget etc. This document is actually an implementation plan focused on your controls, without which you wouldn’t be able to coordinate further steps in the project.
9. Define how to measure the effectiveness of controls
Another task that is usually underestimated. The point here is – if you can’t measure what you’ve done, how can you be sure you have fulfilled the purpose? Therefore, be sure to define how you are going to measure the fulfilment of objectives you have set both for the whole ISMS, and for each applicable control in the Statement of Applicability.
10. Implement the controls & mandatory procedures
Easier said than done. This is where you have to implement the four mandatory procedures and the applicable controls from Annex A.
This is usually the most risky task in your project – it usually means the application of new technology, but above all – implementation of new behaviour in your organization. Often new policies and procedures are needed (meaning that change is needed), and people usually resist change – this is why the next task (training and awareness) is crucial for avoiding that risk.
11. Implement training and awareness programs
If you want your personnel to implement all the new policies and procedures, first you have to explain to them why they are necessary and train your people to be able to perform as expected. The absence of these activities is the second most common reason for ISO 27001-project failure.
12. Operate the ISMS
This is the part where ISO 27001 becomes an everyday routine in your organization. The crucial word here is: “records”. Auditors love records – without records you will find it very hard to prove that some activity has really been done. But records should help you in the first place – using them you can monitor what is happening – you will actually know with certainty whether your employees (and suppliers) are performing their tasks as required.
13. Monitor the ISMS
What is happening in your ISMS? How many incidents do you have, of what type? Are all the procedures carried out properly?
This is where the objectives for your controls and measurement methodology come together – you have to check whether the results you obtain are achieving what you have set in your objectives. If not, you know something is wrong – you have to perform corrective and/or preventive actions.
14. Internal audit
Very often people are not aware they are doing something wrong (on the other hand they sometimes are, but they don’t want anyone to find out about it). But being unaware of existing or potential problems can hurt your organization – you have to perform an internal audit in order to find out such things. The point here is not to initiate disciplinary actions, but to take corrective and/or preventive actions.
15. Management review
Management does not have to configure your firewall, but it must know what is going on in the ISMS, i.e. if everyone performed his or her duties, if the ISMS is achieving desired results etc. Based on that, the management must make some crucial decisions.
16. Corrective and preventive actions
The purpose of the management system is to ensure that everything that is wrong (so-called “non-conformities”) is corrected or hopefully prevented. Therefore, ISO 27001 requires that corrective and preventive actions are done systematically, which means that the root cause of non-conformity must be identified, and then resolved and verified.
The basic logic of ISO 27001: How does information security work?
When speaking with someone new to ISO 27001, very often I encounter the same problem: this person thinks the standard will describe in detail everything they need to do – for example, how often they will need to perform backup, how distant their disaster recovery site should be, or even worse, which kind of technology they must use for network protection or how they have to configure the router.
Here’s the bad news: ISO 27001 does not prescribe these things; it works in a completely different way.
Here’s why…
Why is ISO 27001 not prescriptive?
Let’s imagine that the standard prescribes that you need to perform a backup every 24 hours – is this the right measure for you? It might be, but believe me, many companies nowadays will find this insufficient – the rate of change of their data is so quick that they need to do backup if not in real time, then at least every hour. On the other hand, there are still some companies that would find the once-a-day backup too often – their rate of change is still very slow, so performing backup so often would be overkill.
The point is – if this standard is to fit any type of a company, then this prescriptive approach is not possible. So, it is simply impossible not only to define the backup frequency but also which technology to use, how to configure each device, etc.
By the way, this perception that ISO 27001 will prescribe everything is the biggest generator of myths about ISO 27001.
Risk management is the central idea of ISO 27001
So, you might wonder, “Why would I need a standard that doesn’t tell me anything concretely?”
Because ISO 27001 gives you a framework for you to decide on appropriate protection. The same way, e.g., you cannot copy a marketing campaign of another company to your own, this same principle is valid for information security – you need to tailor it to your specific needs.
And the way ISO 27001 tells you to achieve this tailor-made suit is to perform risk assessment and risk treatment. This is nothing but a systematic overview of the bad things that can happen to you (assessing the risks), and then deciding which safeguards to implement to prevent those bad things from happening (treating the risks).
Method of safeguard selection in ISO 27001
The whole idea here is that you should implement only those safeguards (controls) that are required because of the risks, not those that someone thinks are fancy; but, this logic also means that you should implement all the controls that are required because of the risks and that you cannot exclude some simply because you don’t like them.
IT alone is not enough
If you work in the IT department, you are probably aware that most of the incidents are happening not because the computers broke down, but because the users from the business side of the organization are using the information systems in the wrong way.
And such wrongdoings cannot be prevented with technical safeguards only – what is also needed are clear policies and procedures, training and awareness, legal protection, discipline measures, etc. Real-life experience has proved that the more diverse safeguards are applied, the higher level of security is achieved.
And when you take into account that not all the sensitive information is in digital form (you probably still have papers with confidential information on them), the conclusion is that IT safeguards are not enough, and that the IT department, although very important in an information security project, cannot run this kind of project alone.
Again, this fact that IT security is only 50% of information security is recognized in ISO 27001 – this standard tells you how to run the information security implementation as a company-wide project where not only IT, but also the business side of the organization, must take part.
Getting the top management aboard
But, ISO 27001 doesn’t stop with the implementation of various safeguards – its authors understood perfectly well that people from the IT department, or from other lower- or mid-level positions in the organization, cannot achieve much if the executives at the top don’t do something about it.
For instance, you may propose a new policy for the protection of confidential documents, but if your top management does not enforce such policy with all employees (and if they themselves do not comply with it), such a policy will never gain a foothold in your company.
So, ISO 27001 gives you a systematic checklist of what the top management must do:
Ø Set their business expectations (objectives) for information security
Ø Publish a policy on how to control whether those expectations are met
Ø Designate main responsibilities for information security
Ø Provide enough money and human resources
Ø Regularly review whether all the expectations were really met
Not allowing your system to deteriorate
If you work in a company for a couple of years or more, then you probably know how the new initiatives/projects work – at the beginning, they look nice and shiny and everyone (or at least most of the people) are trying to do their best to make everything work. However, in time, the interest and the zeal deteriorate, and with them, everything related to such a project also deteriorates.
For instance, you may have had a classification policy that worked fine initially, but in time the technology changed, the organization changed and people changed, and if no one has cared to update the policy, it will become obsolete. And, as you are well aware, no one will want to comply with an obsolete document, meaning that your security will grow worse.
To prevent this, ISO 27001 has described a couple of methods that prevent such deterioration from taking place; even more, those methods are used to improve the security over time, making it even better than it was at the time when the project was at its highest. These methods include monitoring and measurement, internal audits, corrective actions, etc.
Therefore, you shouldn’t be negative about ISO 27001 – it may seem vague at first reading, but it can prove to be an extremely useful framework for resolving many security problems in your company. What’s more, it can help you do your job more easily, and get more recognition from the top.
Greatest myths about ISO 27001
“The standard requires passwords to be changed every 3 months.” “The standard requires that multiple suppliers must exist.”
“The standard requires the disaster recovery site to be at least 50 km distant from the main site.” Really? The standard doesn’t say anything like that. Unfortunately, this kind of false information I hear rather often – people usually mistake best practice for requirements of the standard, but the problem is that not all security rules are applicable to all types of organizations. And the people who claim this is prescribed by the standard have probably never read the standard.
“We’ll let the IT department handle it”
This is the management’s favourite – “Information security is all about IT, isn’t it?” Well, not really – the most important aspects of information security include not only IT measures, but also organizational issues and human resource management, which are usually out of reach of IT department.
“We’ll implement it in a few months”
You could implement ISO 27001 in 2 or 3 months, but it won’t work – you would only get a bunch of policies and procedures no one cares about. Implementation of information security means you have to implement changes, and it takes time for changes to take place.Not to mention that you must implement only those security controls that are really needed, and the analysis of what is really needed takes time – it is called risk assessment and risk treatment.
“This standard is all about documentation”
Documentation is an important part of ISO 27001 implementation, but the documentation is not an end in itself. The main point is that you perform your activities in a secure way, and the documentation is here to help you do it. Also, the records you produce will help you measure whether you achieve your information security goals and enable you to correct those activities that underperform.
The importance of Statement of Applicability for ISO 27001
The importance of Statement of Applicability (sometimes referred to as SoA) is usually underrated – like the Quality Manual in ISO 9001, it is the central document that defines how you will implement a large part of your information security.
Actually, the Statement of Applicability (ISO 27001 Clause 6.1.3 d) is the main link between the risk assessment & treatment and the implementation of your information security – its purpose is to define which of the suggested 114 controls (security measures) from ISO 27001 Annex A you will apply, and for those that are applicable the way they will be implemented. As Annex A is considered to be comprehensive, but not exhaustive for all situations, nothing prevents you from also considering another source for the controls.
Why it is needed
Now why is such a document necessary when you already produced the Risk Assessment Report (which is also mandatory), and which also defines the necessary controls? Here are the reasons:
· First of all, during risk treatment you identify the controls that are necessary because you identified risks that need to be decreased; however, in SoA you also identify the controls that are required because of other reasons – i.e. because of the law, contractual requirements, because of other processes, etc.
· Second, the Statement of Applicability justifies the inclusion and exclusion of controls from Annex a, and the inclusion of controls from another source.
· Third, the Risk Assessment Report could be quite lengthy – some organizations might identify a few thousand risks (sometimes even more), so such a document is not really useful for everyday operational use; on the other hand, the Statement of Applicability is rather short – it has a row for each control (114 from Annex A, plus the added ones), which makes it possible to present it to management and to keep it up-to-date.
· Fourth, and most important, SoA must document whether each applicable control is already implemented or not. Good practice (and most auditors will be looking for this) is also to describe how each applicable control is implemented – e.g. either by making a reference to a document (policy/procedure/working instruction etc.), or by shortly describing the procedure in use, or equipment that is used.
Actually, if you go for the ISO 27001 certification, the certification auditor will take your Statement of Applicability and walk around your company checking out whether you have implemented your controls in the way you described them in your SoA. It is the central document for doing their on-site audit.
A very small number of companies realize that by writing a good Statement of Applicability you could decrease the number of other documents – for instance, if you want to document a certain control, but if the description of the procedure for that control would be rather short, you can describe it in the SoA. Therefore, you would avoid writing another document.
Why it is useful
In my experience, most companies implementing the information security management system according to ISO 27001 spend much more time writing this document than they anticipated. The reason for this is they have to think about how they will implement their controls: Are they going to buy new equipment? Or change the procedure? Or hire a new employee? These are quite important (and sometimes expensive) decisions, so it is not surprising that it takes quite a lot of time to reach them. The good thing about SoA is that it forces organizations to do this job in a systematic way.
Therefore, you shouldn’t consider this document as just one of those “overhead documents” that have no use in real life – think of it as the main statement where you define what you want to do with your information security. Written properly, SoA is a perfect overview (list, justification and description) of what needs to be done in information security, why it has to be done, and how it is done.
List of mandatory documents required by ISO 27001 (2013 revision)
Mandatory documents and records required by ISO 27001:2013
Here are the documents you need to produce if you want to be compliant with ISO 27001: (Please note that documents from Annex A are mandatory only if there are risks which would require their implementation.)
· Scope of the ISMS (clause 4.3)
· Information security policy and objectives (clauses 5.2 and 6.2)
· Risk assessment and risk treatment methodology (clause 6.1.2)
· Statement of Applicability (clause 6.1.3 d)
· Risk treatment plan (clauses 6.1.3 e and 6.2)
· Risk assessment report (clause 8.2)
· Definition of security roles and responsibilities (clauses A.7.1.2 and A.13.2.4)
· Inventory of assets (clause A.8.1.1)
· Acceptable use of assets (clause A.8.1.3)
· Access control policy (clause A.9.1.1)
· Operating procedures for IT management (clause A.12.1.1)
· Secure system engineering principles (clause A.14.2.5)
· Supplier security policy (clause A.15.1.1)
· Incident management procedure (clause A.16.1.5)
· Business continuity procedures (clause A.17.1.2)
· Statutory, regulatory, and contractual requirements (clause A.18.1.1)
And here are the mandatory records:
· Records of training, skills, experience and qualifications (clause 7.2)
· Monitoring and measurement results (clause 9.1)
· Internal audit program (clause 9.2)
· Results of internal audits (clause 9.2)
· Results of the management review (clause 9.3)
· Results of corrective actions (clause 10.1)
· Logs of user activities, exceptions, and security events (clauses A.12.4.1 and
A.12.4.3)
Non-mandatory documents
There are numerous non-mandatory documents that can be used for ISO 27001 implementation, especially for the security controls from Annex A. However, I find these non-mandatory documents to be most commonly used:
· Procedure for document control (clause 7.5)
· Controls for managing records (clause 7.5)
· Procedure for internal audit (clause 9.2)
· Procedure for corrective action (clause 10.1)
· Bring your own device (BYOD) policy (clause A.6.2.1)
· Mobile device and teleworking policy (clause A.6.2.1)
· Information classification policy (clauses A.8.2.1, A.8.2.2, and A.8.2.3)
· Password policy (clauses A.9.2.1, A.9.2.2, A.9.2.4, A.9.3.1, and A.9.4.3)
· Disposal and destruction policy (clauses A.8.3.2 and A.11.2.7)
· Procedures for working in secure areas (clause A.11.1.5)
· Clear desk and clear screen policy (clause A.11.2.9)
· Change management policy (clauses A.12.1.2 and A.14.2.4)
· Backup policy (clause A.12.3.1)
· Information transfer policy (clauses A.13.2.1, A.13.2.2, and A.13.2.3)
· Business impact analysis (clause A.17.1.1)
· Exercising and testing plan (clause A.17.1.3)
· Maintenance and review plan (clause A.17.1.3)
· Business continuity strategy (clause A.17.2.1)
Risk assessment vs. business impact analysis
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.
ISO 27001 risk assessment & treatment
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.
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.
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.
Very often I see people confuse gap analysis with risk assessment – which is understandable, since the purpose of both is to identify deficiencies in their company’s information security. However, from the perspective of ISO 27001, and from the perspective of a certification auditor, these two are quite different. Here’s why:
What is ISO 27001-gap analysis?
Gap analysis is nothing but reading each clause of ISO 27001 and analyzing if that requirement is already implemented in your company. When you do so, you can either say Yes or No, or you could use a scale similar to this:
0 – requirement not implemented nor planned;
1 – requirement is planned but not implemented;
2 – requirement is implemented only partially, so that full effects cannot be expected;
3 – requirement is implemented, but measurement, review and improvement are not performed; and
4 – requirement is implemented and measurement, review and improvement are performed regularly.
Gap analysis is mandatory in ISO 27001, but only when developing your Statement of Applicability – clause 6.1.3 d) says you need to determine “… whether they [the necessary controls] are implemented or not.”
Therefore, you don’t need to perform the gap analysis for clauses of the main part of the standard – only for the controls from Annex A. Further, gap analysis doesn’t need to be performed before the start of ISO 27001 implementation – you must do it only after the risk assessment and treatment.
What is risk assessment?
Risk assessment is a crucial step in Information Security Management System (ISMS) implementation because it tells you the following: you should implement security controls (safeguards) only if there are risks (potential incidents) that would justify that particular control. In other words, the higher the risk, the more you need to invest in controls; but, on the other hand, if there are no risks that would justify a particular control, then implementing it would be a waste of time and money.
Risk assessment is a key requirement in ISO 27001 that must be performed before you start implementing security controls, and, consequently, it is the one that determines the shape of your information security.
So, the difference is…Gap analysis tells you how far you are from ISO 27001 requirements/controls; it doesn’t tell you which problems can occur or which controls to implement. Risk assessment tells you which incidents can happen and which controls to implement, but it doesn’t give you an overview of which controls are already implemented.
While risk assessment is crucial for ISO 27001 implementation, gap analysis is only required when writing the Statement of Applicability – therefore, one is not a replacement for the other, and both are required, but in different phases of implementation and with different purposes.
Sometimes companies perform gap analysis before the start of ISO 27001 implementation, in order to get a feeling of where they are right now, and to find out which resources they will need to employ in order to implement ISO 27001. However, the usefulness of such approach is doubtful, since only risk assessment will show the real extent of what needs to be implemented and in which form.
What has changed in risk assessment in ISO 27001:2013
Risk assessment has always been a hot topic, and especially now with the changes in the ISO 27001 2013 revision – there are many doubts as to whether the risk assessment you’ve done according to the 2005 revision needs to be changed, and if yes – how big the change is.
The myths
Let’s start with a couple of myths related to risk management that have developed around ISO 27001:2013:
· “We have to use ISO 31000 for risk management.” False – ISO 31000 is only mentioned in ISO 27001:2013, but it is not mandatory. (See also ISO 31000 and ISO 27001 – How are they related?)
· “We have to delete assets, threats and vulnerabilities from our risk assessment.” False again – you can keep your old methodology if you like it, because ISO 27001:2013 leaves you the freedom to identify risks any way you want.
· “We do not have to identify asset owners anymore.” Another false statement – although ISO 27001:2013 does not require you to identify asset owners as part of the risk assessment, it does require you to do it in control A.8.1.2. (See also Risk owners vs. asset owners in ISO 27001:2013)
· “The identification of risks based on confidentiality, integrity and availability (C-I-A) is a new concept.” False – this concept existed in ISO 27001:2005, too; actually, the whole standard is based on the concept of protecting the C-I-A from the very beginning.
What has changed in risk management in ISO 27001:2013?
As you’ll see, the changes are not very significant:
· Top-level Information security policy does not need to establish criteria against which risks will be evaluated – this was the requirement of ISO 27001:2005 4.2.1 b) 4); in ISO 27001:2013, you still need to define the risk assessment criteria, but not as part of the top-level policy.
· As mentioned before, you do not need to use the assets-threats-vulnerabilities methodology to identify risks – for example, you can identify risks based on your processes, based on your departments, using only threats and not vulnerabilities, or any other methodology you like.
· You need to identify risk owners for each risk.
· ISO 27001:2005 required management to approve residual risks, as well as implementation and operation of the ISMS. On the contrary, in ISO 27001:2013 the risk owners must accept the residual risks and approve the Risk treatment plan.
· Treatment options in the 2013 revision are not limited only to applying controls, accepting risks, avoiding risks, and transferring risks as they were in the 2005 revision – basically, you are free to consider any treatment option you find appropriate.
One indirect change that is not visible at first reading of the standard is that risk management has taken the role of preventive actions (preventive actions do not exist in the 2013 revision any more) – only when reading the clause 6.1.1 of ISO 27001:2013 more carefully does this becomes obvious. But this change makes sense – preventive actions are nothing other than concluding what negative things can happen in the future, and taking action to prevent them – and this is exactly what risk assessment and treatment is also about. Therefore, ISO 27001:2013 has only corrected what was not very logical in ISO 27001:2005, and the good thing is you do not have to change your risk assessment process because of it.
So, as you can see, the changes in risk assessment and treatment are relatively minor, and if you’ve done a good job with ISO 27001:2005, then you’ll find the transition to the 2013 revision of ISO 27001 relatively easy. All you need to do is identify risk owners for each risk, and give them the responsibility to make decisions about the risks.
Risk Treatment Plan and risk treatment process – What’s the difference?
Risk Treatment Plan is one of the key documents in ISO 27001, however it is very often confused with the documentation that is produced as the result of a risk treatment process. Here’s the difference:
Risk treatment process
Risk treatment is a step in the risk management process that follows the risk assessment step – in the risk assessment all the risks need to be identified, and risks that are not acceptable must be selected. The main task in the risk treatment step is to select one or more options for treating each unacceptable risk, i.e. decide how to mitigate all these risks. Four risk treatment options exist (for complete risk management process, Apply security controls from Annex A to decrease the risks – see this article ISO 27001 Annex A controls.
1. Transfer the risk to another party – e.g. to an insurance company by buying an insurance policy.
2. Avoid the risk by stopping an activity that is too risky, or by doing it in a completely different fashion.
3. Accept the risk – if, for instance, the cost of mitigating that risk would be higher that the damage itself.
Risk treatment is usually done in a form of a simple sheet, where you link mitigation options and controls with each unacceptable risk; this can also be done with a risk management tool, if you use one. According to ISO 27001, it is required to document the risk treatment results in the Risk assessment report, and those results are the main inputs for writing Statement of Applicability. This means that results of risk treatment are not directly documented in Risk Treatment Plan.
Risk Treatment Plan
So, where is the Risk Treatment Plan in this whole process? The answer is: it can be written only after Statement of Applicability is finished.
Why is this so? To start thinking about Risk Treatment Plan, it would be easier to think of it is an “Action plan” where you need to specify which security controls you need to implement, who is responsible for them, what are the deadlines, and which resources (i.e. financial and human) are required. But in order to write such a document, first you need to decide which controls need to be implemented, and this is done (in a very systematic way) through Statement of Applicability.
The question is – why didn’t ISO 27001 require the results from risk treatment process to be documented directly in the Risk Treatment Plan? Why was this step in between needed, in the form of Statement of Applicability? My opinion is that the authors of ISO 27001 wanted to encourage companies to get a comprehensive picture of information security – when deciding which controls are applicable in Statement of Applicability and which are not, the result of risk treatment is not the only input – other inputs are legal, regulatory and contractual requirements, other business needs, etc. In other words, SoA serves as a kind of a checklist that takes a global view of the organization, and Risk Treatment Plan wouldn’t be complete without such a check.
To conclude – Risk Treatment Plan is the point where theory stops, and real life begins according to ISO 27001. Good risk assessment and risk treatment process, as well as comprehensive Statement of Applicability, will produce very usable action plan for your information security implementation; skip some of these steps and Risk Treatment Plan will only confuse you.
ISO 27001 risk assessment: How to match assets, threats and vulnerabilities
The 2013 revision of ISO 27001 allows you to identify risks using any methodology you like; however, the old methodology (defined by the old 2005 revision of ISO 27001), which requires identification of assets, threats and vulnerabilities, is still dominating. (See also: What has changed in risk assessment in ISO 27001:2013.)
So, how do you combine assets, threats and vulnerabilities in order to identify risks?
How to document the risk identification
Risk identification is the first half of the risk assessment process, after which comes the evaluation part (assessing the impacts and likelihood) – see the details here: How to write ISO 27001-risk assessment methodology.
To make your risk assessment easier, you can use a sheet with assets, threats and vulnerabilities in columns; you should also include some other information like risk ID, risk owners, impact and likelihood, etc.
I found it the easiest to start listing items column by column, not row by row – this means you should list all of your assets first, and only then start finding a couple of threats for each asset, and finally find a couple of vulnerabilities for each threat.
So, let’s see what this matching of the three components could look like – for example:
· Asset: paper document:
o Threat: fire; vulnerability: document is not stored in a fire-proof cabinet (risk related to the loss of availability of the information)
o Threat: fire; vulnerability: there is no backup of the document (potential loss of availability)
o Threat: unauthorized access; vulnerability: document is not locked in a cabinet (potential loss of confidentiality)
· Asset: digital document:
o Threat: disk failure; vulnerability: there is no backup of the document (potential loss of availability)
o Threat: virus; vulnerability: anti-virus program is not properly updated (potential loss of confidentiality, integrity and availability)
o Threat: unauthorized access; vulnerability: access control scheme is not properly defined (potential loss of confidentiality, integrity and availability)
o Threat: unauthorized access; vulnerability: the access was given to too many people (potential loss of confidentiality, integrity and availability)
Asset: system administrator:
o Threat: unavailability of this person; vulnerability: there is no replacement for this position (potential loss of availability)
o Threat: frequent errors; vulnerability: lack of training (potential loss of integrity and availability)
o Etc.
This might seem complicated at first glance, but once you start doing this you’ll see it goes rather quickly. Some people prefer using tools for this kind of work, and I agree this could be a good move for larger companies, but for smaller ones using a tool would only take too much time: When to use tools for ISO 27001/ISO 22301 and when to avoid them.
How much is enough?
Very often people ask me – how many risks should they identify? If they start being really thorough, for each asset they could find 10 threats, and for each threat at least 5 vulnerabilities – this is quite realistic, isn’t it?
Now if you were a small company with 50 assets, this would mean you would end up with 2,500 risks, which would probably be overkill for this size of a company. This is why you should focus only on the most important threats and vulnerabilities while including all the assets; that would mean that per each asset you should identify on average 5 threats, and for each threat on average 2 vulnerabilities. This way you would end up with 500 risks for a smaller company with 50 assets, which is quite manageable.
Why is this methodology still good?
I personally like this assets-threats-vulnerabilities methodology quite a bit – not that I’m nostalgic for the 2005 revision of ISO 27001, but I think this methodology gives a good balance between doing the risk assessment quickly, and at the same time doing it both systematically and detailed enough so that one can pinpoint where the potential security problem is.
And this is what risk assessment is really about: find out about a potential problem before it actually happens. In other words, ISO 27001 tells you: better safe than sorry.
Risk owners vs. asset owners in ISO 27001:2013
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.
Asset-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 that is responsible for implementing the controls.
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.
