This clause is all about the execution of the plans and processes that are the subject of previous clauses. It deals with the execution of the actions determined and the achievement of the information security objectives. In recognition of the increased use of outsourced functions in today’s business world, these processes also need to be identified and controlled. Any changes, whether planned or unintended need to be considered here and the consequences of these on the ISMS. It also deals with the performance of information security risk assessments at planned intervals and the need for documented information to be retained to record the results of these. Finally, there is a section that deals with the implementation of the risk treatment plan, and again, the need for the results of these to be retained in documented information. This clause of the standard defines the requirements necessary to operate an ISMS. They include the following key elements:
- 8.1 Operational planning and control
- 8.2 Information security risk assessment
- 8.3 Information security risk treatment
Clause 8.1 requires a demonstration of processes controlling critical security-related activities. Some mechanisms to assist with conformance to this subsection include:
- The use of documented security plans or security calendars;
- Monitoring and controlling changes to the environment;
- Implementing controls around third-party outsourcing arrangements.
Clause 8.2 requires the risk assessment to be performed when significant changes occur or are proposed. In addition. this clause requires the review of the risk assessments at planned intervals. In a practical sense. this usually is performed annually and is tracked by activity in the security calendar. Evidence of the output of such planned risk reviews must be available. Clause 8.3 requires risk treatments to be implemented and monitored.
8.1 Operational planning and control
The organization shall plan, implement and control the processes needed to meet information security requirements, and to implement the actions determined in 6.1. This is to be done by establishing the criteria for process and implementing controls of the processes in accordance with the criteria. The organization shall also implement plans to achieve information security objectives determined in 6.2. The organization shall keep documented information to the extent necessary to have confidence that the processes have been carried out as planned. The organization shall control planned changes and review the consequences of unintended changes, taking action to mitigate any adverse effects, as necessary. The organization shall ensure that externally provided products, services or processes related to ISMS are controlled.
To ensure that risks and opportunities are treated properly (clause 6.1), security objectives are achieved (clause 6.2), and information security requirements are met, an ISMS must plan, implement, and control its processes, as well as identify and control any relevant Externally processes including product or services, and retain documented information deemed as necessary to provide confidence that the process is being performed and achieving their results as planned. Being focused on keeping the information secure, the ISMS also should consider in its planning and control the monitoring of planned changes, and impact analysis of unexpected changes, to be able to take actions to mitigate adverse effects if necessary. Managing your information security risks and achieving your objectives require the formalization of your activities into a set of clear and coherent processes. Many of these processes are likely to exist already (e.g. induction, training) and will simply need modifying to include elements relevant to information security. Other processes may happen in an ad-hoc fashion (e.g. supplier approvals), while some may not currently exist at all (e.g. internal audit). To implement effective processes the following practices are crucial:
1 Processes are created by adapting or formalizing an organization’s “business as usual” activities.
2 Systematic identification of the information security risks relevant to each process.
3 Clear definition and communication of the set of activities required to manage the associated information security risks when an event occurs (e.g. a new employee joining
the company).
4 Clear assignment of the responsibilities for carrying out related activities.
5 Adequate allocation of resources to ensure that related activities can take place as and when required.
6 Routine assessment of the consistency with which each process is followed and its effectiveness in managing relevant information security risks.
For each process, designate an individual as accountable for ensuring that steps 2-6 happen. This individual is often referred to as the Process Owner.
Relationship between assets, threats, and vulnerabilities
So, let’s see what this matching of the three components could look like – for example:
- Asset: paper document:
threat: fire;
vulnerability: the document is not stored in a fire-proof cabinet (risk related to the loss of availability of the information)
threat: fire;
vulnerability: there is no backup of the document (potential loss of availability)
threat: unauthorized access;
vulnerability: the document is not locked in a cabinet (potential loss of confidentiality) - Asset: digital document:
threat: disk failure;
vulnerability: there is no backup of the document (potential loss of availability)
threat: virus;
vulnerability: anti-virus program is not properly updated (potential loss of confidentiality, integrity, and availability)
threat: unauthorized access;
vulnerability: access control scheme is not properly defined (potential loss of confidentiality, integrity, and availability)
threat: unauthorized access;
vulnerability: the access was given to too many people (potential loss of confidentiality, integrity, and availability) - Asset: system administrator:
threat: unavailability of this person; vulnerability: there is no replacement for this position (potential loss of availability)
threat: frequent errors;
vulnerability: lack of training (potential loss of integrity and availability) etc.
8.2 Information security risk assessment
The organization shall perform information security risk assessments at planned intervals or when significant changes are proposed or occur, taking account of the criteria established in 6.1.2 a). The organization shall retain documented information on the results of the information security risk assessments.
The risk assessment methods and techniques described in Clause 6 must be applied to all processes, assets, information, and activities within the organization’s ISMS scope. Since risks are not static, the results of these assessments must be reviewed at appropriate frequencies. This is usually at least annually, or more frequently if the assessment identifies the presence of one or more significant risks. Risks should also be reviewed whenever:
• any Risk Treatment actions are completed (see below);
• there are changes to the organization’s assets, information, or processes;
• new risks are identified; or
• experience or new information indicates that the likelihood and the consequence of any identified risk have changed.
To ensure your risk assessment process covers the types of events that would require a review, you should also take into consideration the Annex A controls for Technical Vulnerability Management (A.12.6), Security in Development and Support Processes (A.14.2), and Supplier Service Delivery Management (A.15.2).
Given that ISO 27001 is inherently a risk management standard it is no surprise that there are a number of specific clauses addressing this area. The clauses and the expectations outlined in the standard are: – Process must be defined (6.1.2). The standard does not dictate specific methods for risk assessment. It is up to the organization to select a method that aligns with the organizational risk methodology. However, the consequence and likelihood must be considered. ISO 27001 references ISO 31000 as a risk standard.
Management must determine and approve the criteria for accepting the risk. For example, an organization may say “We will accept all risks in the ‘low’ category and treat those rated above this value”. Management must also determine the criteria for performing risk assessments. This may include consideration of risk assessments during projects, significant changes, as a result of incident reviews, or as an outcome of business continuity exercises. Criteria may also be based on the value of the information assets involved. For instance, highly sensitive assets may automatically require a risk assessment around any changes in how those assets are used.
The process of risk assessment should be documented. People undertaking risk assessments must be competent to perform these activities. Training may be required. A general “rule of thumb” regarding “producing consistent, valid and comparable results” should be “if two people of similar competence undertake the same risk assessment the results will be comparable (not necessarily identical)”.Risk assessments should also be performed at planned intervals to address changes in the security requirements and in the risk situation, e.g. in the likelihood or consequences of previously identified risks and also when significant changes occur or are planned.
A question is often posed that if ISO 27001 is about risk management, why do we not do risk assessments against all in-scope assets? This is fundamentally a question of practicality. Few organizations have enough competent resources to undertake such an intensive program. In addition to resources, there is a question of exposure. During the time taken to conduct such risk assessments, the organization is exposed to potentially high risks. The most common approach is to perform detailed risk assessments on “high value” assets and have the risks to those assets of a lower value managed by sets of baseline controls. These controls are the minimum set of controls to provide appropriate protection.
STEPS IN A SAMPLE RISK ASSESSMENT METHOD
1. Identify the critical processes within the scope
2. Identify the information assets required
3. Consider threats (agencies that could cause loss) against the asset
4. Identify vulnerabilities (weaknesses exploited by threat)
5. Assess consequences to the agency if the threat occurs
6. Assess the realistic likelihood of risk eventuating
7. Determine risk rating
8. Compare against acceptance criteria
9. Determine treatment options if required
10. Monitor treatment implementation
11. Repeat from step 1
MEASURES OF LIKELIHOOD
Tables similar to the one below are often seen within risk models. One consideration should be if the timeframes within these types of tables are appropriate for assessing information security risks. One challenge related to the use of a single likelihood table for all types of risk has been the relevance to information security events.
| Level | Descriptor | Description |
| 5 | Near certain | Is expected to occur in most circumstances. Could occur within ‘days to weeks’ |
| 4 | Highly Likely | Will probably occur in most circumstances. Could occur within ‘weeks to months’ |
| 3 | Likely | Could occur ‘within a year or so’ |
| 2 | Unlikely | Could occur but not expected. Could occur ‘after several years’ |
| 1 | Remote | This occurs only in exceptional circumstances. A ‘100-year event’ or greater |
The likelihood should take into account the effectiveness of the current control environment.
MEASURES OF CONSEQUENCE
It is more common to use a single consequence table across the organization. For this to be practical, the consequence (or impact) domains must represent all possible areas of impact across the risk portfolio. The more detailed the information in the consequence table, the more likely it that a comparable value will be selected during risk assessments. There may be consequences in a number of impact areas. The risk assessor should select the highest impact value.
| Rating |
Financial |
Customer service/Business continuity |
Regulatory /Legal |
Reputation Image |
| Catastrophic-5 | Financial loss more than 100000 KWD | Loss of Service capacity for more than 1 week | Significant Legal, Regulatory or internal policy failure | Severe difficulties leading to sustained adverse business press and brand damage |
| Critical-4 | Financial loss between 50000 to 100000 KWD | Loss of Service capacity between 1 day to 1 week | Major Legal, Regulatory or internal policy failure | Sustained difficulties identified in industrial blog |
| Marginal-3 | Financial loss between 10000 to 50000 KWD | Loss of Service capacity between 1hour to 1 day | Limited Legal, Regulatory or internal policy failure | Matter raised in trade press or industry blog |
| Minor-2 | Financial loss between 1000 to 10000 KWD | Loss of Service capacity between 15 min to 1 hour | Minor Legal, Regulatory or internal policy failure | Some press mention-senior management required to resolve |
| Negligible-1 | Financial loss below 1000 KWD | Loss of Service capacity for less than 15 Min | Insignificant Legal, Regulatory or internal policy failure | Resolved through the day to day management |
MEASURES OF RISK
Once the consequence and likelihood have been assessed, generally there is some form of lookup table to determine the risk value. These risk tables may look similar to that above, although sometimes the axes are transposed or the scales on the axes are transposed. The likelihood assessment may include business and control owners and consequence assessment will certainly include the business owner. The risk value obtained from the risk assessment will be used to determine whether further risk treatment is required.
8.3 Information security risk treatment
The organization shall implement the information security risk treatment plan. The organization shall retain documented information on the results of the information security risk treatment.
Once the risk assessment has been concluded and the risk is rated, the rating is compared to the agreed risk acceptance criteria. If the risk rating is greater than the acceptable level of risk treatment options need to be considered.
There are four alternatives for risk treatment. These are:
1. Mitigating the risk by applying additional appropriate controls;
2. Knowingly and objectively accepting the risk, providing this clearly satisfies the organization’s risk management policy in terms of the levels of authorization required to accept risks above the defined risk acceptance criteria;
3. Avoiding the risk by avoiding or terminating the activity that creates the risk; and,
4. Transferring the associated business risks to other parties, e.g. insurers.
Transference of risk is an effective choice when the impact of this risk is financial in nature. For instance, insuring against loss from an environmental event such as a flood reduces the financial impact on the organization. The risk treatment plan you develop cannot simply remain as a statement of intent; it must be implemented. Where changes are needed to take into account new information about risks and changes to your risk assessment criteria, the plan needs to be updated and re-authorized. The impact of the plan must also be assessed and the results of this assessment recorded. This may be done as part of your Management Review or Internal Audit Processes or by using technical assessments such as network penetration tests, supplier audits, or unannounced third-party audits.
Some believe that outsourcing is a form of risk transference. However, the question remains “who suffers the most impact?”. Generally, it is not the outsourcer’s business that is most affected. Outsourcing transfers some of the operational aspects of risk mitigation to the outsourcer but it still remains the organization’s risk to manage. If the treatment choice is “mitigate” with additional controls, what control sets should be considered? As with the existing control environment, the standard does not mandate any specific set.
Possible control sets include:
• ISO 27002 (ISO 27001 Annex A)
• PCI-DSS for credit card security
• Australian Government’s Information Security Manual (ISM)
• NIST frameworks
• Other ISO 27nnn standards
• Unique controls designed by the organization
Remember that after the risk treatment has been determined, you need to reassess the ‘likelihood’ and “consequence” and calculate the measure of residual risk. At the conclusion of the control selection process, the control objectives and controls selected need to be compared to the control objectives and controls from Annex A to ensure that no necessary controls have been omitted. The risk owner MUST approve the risk treatments selected and also must accept any residual risk. This must be documented.
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 a Statement of Applicability. This means that the results of risk treatment are not directly documented in the Risk Treatment Plan. The risk treatment plan can be written only after the Statement of Applicability is finished. This is because the Risk treatment plan can be considered as 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 the Statement of Applicability. The ISO 27001 requires that the results from the risk treatment process should not be documented directly in the Risk Treatment Plan without doing the Statement of Applicability. This may be because 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 checklist that takes a global view of the organization, and the Risk Treatment Plan wouldn’t be complete without such a check.
Back to Home Page
If you need assistance or have any doubt and need to ask any questions contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comment and suggestion are also welcome.