CHAPTER 3: RISK MANAGEMENT OBJECTIVES

We identified, in Chapter 1, the probability that most organisations already have in place a range of risk assessment approaches, driven perhaps by regulation as much as by the board’s desire to meet its fiduciary duties to shareholders and other stakeholders in the organisation.

Risk acceptance or tolerance

An organisation’s risk acceptance criteria (which we discussed in Chapter 1) are defined in its overall approach to risk management and are contained in its information security policy.

ISO27001 says that the ISMS policy must ‘align with the organization’s strategic risk management context’ (clause 4.2.1 – b3) or its ERM framework, if it already has one in place. What this means is that the organisation, in order to focus effectively on managing risk, should not have a number of different levels of risk tolerance, or risk acceptance. When an organisation approaches risk management on a piecemeal basis, with different individuals or departments leading different risk management efforts without any common direction or guidance, it can easily find itself in a situation where it has, by default, a number of different levels of risk acceptance. These are illustrated in the example overleaf:

Not all these different levels of risk acceptance, or of risk tolerance, are necessarily acceptable to the board. Organisations should, rather, set risk tolerance levels that are consistently applied through all their operations, irrespective of whether they are IT, financial or operational in nature. The ISO27001 requirement that the risk assessment methodology should take the organisational context into account is designed exactly to ensure this level of coordination.

Information security risk management objectives

NIST’s SP 800-30, Risk Management Guide for Information Technology Systems, is consistent with the ERM frameworks we have been discussing and is also reflected, as we shall see, in ISO27001. It defines the risk management objectives as follows:

To enable the organisation to accomplish its missions(s) by:

 

In essence, one might say that an organisation’s risk management objective is to ensure that there is a proper balance of safeguards against the risks of failing to meet business objectives: neither too much nor too little²³. By extension, the risk management objective for an ISMS is to limit risk to an acceptable level across all information assets for all information security risks.

Information security controls and return on investment (ROI)

In all too many organisations, the information security controls historically adopted were selected on the basis of informed opinion, rather than as a result of a systematic and reproducible business-oriented risk assessment. There is, in fact, a direct relationship between the level of investment and the return on that investment: those organisations that under-invest in information security have as negative a return on their investment as do those organisations that over-invest in it.

Optimum ROI in information security control investment is driven by selecting and implementing those controls which will mitigate specific, identified risks to specific, identified assets, and whose total cost of implementation is lower than the potential cost of impact of the identified risk. Above all, those controls whose design is predicated on a proper understanding of the required balance between the confidentiality, integrity and availability (particularly to business users) of information are the most cost-effective and useful of controls.

The above graph indicates clearly that too much investment in information security controls can be as bad as too little. However:

The practical approach, for organisations who wish to maximise the return on their investment in information security controls, is to select controls, having first analysed the likelihood of a compromise occurring, on the basis of their economic value to the organisation. This means selecting controls with specific reference to the value – and the potential impact on the business of losing – specific information assets.

High value assets – faced with high risks – should be protected by more extensive controls than low value ones. The information security risk assessment must, therefore, be carried out at individual asset level, and controls should only be selected and applied to those assets where management has determined that the potential loss to the organisation is such that investment in controls is appropriate.

This is an obviously sensible approach: it ensures that limited financial and human resources are prioritised and allocated to counter the biggest risks to the organisation, rather than applied indiscriminately across all assets of the organisation. An information security risk assessment quite often enables organisations to identify areas in which their controls are in excess of their real requirements and it, therefore, enables resources to be freed-up for re-investment in more critical areas.

In principle, therefore, the risk assessment must be conducted at a detailed, individual asset level. By ‘individual asset level’, we mean individual laptops, servers, databases, folders, e-mails, records and so on. Typically, however, organisations attempt to simplify the risk assessment process by aggregating information assets and then identifying generic threats to that aggregation. This over-simplification usually leads to dissimilar assets being treated in the same manner, typically as if they all had the attributes of the most valuable, and/or most vulnerable, within the group and, as a result, the controls that are selected are not actually required for a number of items within the group.

Risk management and PDCA

ISO27001 is very clear about the risk management approach that it requires and where risk management sits in the project plan.

ISO27001 adopts the Plan-Do-Check-Act (PDCA) model that anyone familiar with other management system standards and various change tools will recognise. That is to say that, to implement an ISO27001-compliant ISMS, an organisation needs to ‘plan’ what it is going to do, carry out those plans, i.e. ‘do’ it, ‘check’ that what they have done has achieved the desired objective, and then ‘act’ on any shortfall.

The ISO27001 specification puts the following tasks in each of the PDCA stages:

Once the ‘act’ stage is completed the organisation then starts over again, planning what to do to improve the ISMS. It is, therefore, correct to say that an organisation which has embarked on an ISO27001 project is in a PDCA continuum, and that the aim of this cyclic experience is to identify and manage risks, and drive continual improvement to the ISMS.

Risk assessment, in other words, initially takes place during the planning stage of the ISO27001 ISMS project. Control selection and implementation cannot start until after the risk assessment process is completed. Put another way, the risk assessment informs the management of risk and is thus critical to the creation of the risk treatment plan. The relationship between risk assessment and risk treatment, and their position on the PDCA continuum, is clear and is as shown in the diagram below:

More accurately, we should say that risk assessment always falls totally within the ‘plan’ stage of the ISMS project cycle, and that some of the risk management, in fact the majority of the decision-making around control objectives and controls, is also within this stage, as that is what informs the risk treatment plan and the organisation’s Statement of Applicability.²⁴ These, in turn, inform further the operational structure and content of the ISMS, which implements and manages the controls that bring the identified risks within an acceptable level.

Table 1 of ISO27005 identifies how the PDCA cycle is aligned with the information security risk management process:

 

Plan	Establish the context
	Risk assessment
	Develop risk treatment plan
	Risk acceptance
Do	Implementation of risk treatment plan
Check	Continual monitoring and reviewing of risks
Act	maintain and improve the information security risk management process

The risk assessment, of course, also provides the organisation with a baseline for improvement. The extent to which this baseline is useful depends on whether you have conducted the risk assessment in light of the controls that are already in place, or on the basis that no controls are applied. Both approaches have benefits, and we will return to their pros and cons later.

Risk assessment is, in conclusion, the key activity required during the planning stage of the ISMS project. Every single control that is to be implemented will be selected on the basis of the risk assessment, and the risk assessment must be completed before any controls are implemented. Risk assessment is also an ongoing activity of the ISMS; whenever there is a change in the risk environment, or of business requirements, or to the asset – indeed, whenever there is any change that might affect the risk profile of the asset – a new risk assessment will be required.

In fact, risk assessment is so central to information security management that we see it as the core competence of the ISMS.

PDCA and the risk acceptance criteria

Whilst ISO27001 expects the board to finalise its risk acceptance criteria and risk assessment methodology before the risk acceptance process itself is started, experience teaches that most organisations need to apply the PDCA principle to this aspect of their ISMS as well.

In other words, senior management and the board should determine, initially, what the acceptance criteria and methodology should be. It is not unusual for either excessive caution or unexpected bravado to underpin this initial phase of development work – not least because the total value or full nature of the organisation’s information assets is not always fully appreciated at this early stage.

The initial methodology and risk acceptance criteria should then be applied in a test environment (the ‘do’ phase of the risk acceptance criteria PDCA process), with a reasonably wide range of information assets. These tests will lead to potential risk treatment decisions which management and the board can assess (the ‘check’ phase) for reasonableness and acceptability in light of the broader risk management and investment context. The methodology and criteria can then be revised to produce results that are more acceptable to management and this then becomes the ‘release’ version.

It is worth retaining this perspective throughout the risk assessment process, so that, if results are generated which seem out of line with common sense, the risk assessor can revert to the risk assessment criteria and methodology and, if necessary, propose improvements to it. Of course, improvements – and the reasons for them – should be documented and will form part of the ISMS documentation.