Information Security Risk Treatment

ISO 27001 Clause 6.1.3 Information security risk treatment

Required activity

The organization defines and applies a risk treatment process for information security.

Guidelines for Implementation

The information security risk treatment process involves selecting appropriate risk treatment options, selecting appropriate controls to implement such options, forming a risk treatment plan, and securing approval of the Risk treatment plan by the Risk owner(s). The process for treating knowledge security risks is documented at all stages, as are the results of its application for future reference.

Risk treatment options related to information security

These are the risk treatment options:

1. Avoiding the Risk by deciding not to engage in the activity that may pose the Risk or removing the risk-producing activity (for example, by closing an e-commerce portal);
2. Taking on more risk or increased risk in pursuit of a business opportunity (e.g., setting up an e-commerce website);
3. Adapting the Risk by changing the probability (such as reducing vulnerability) or results (such as diversifying assets);
4. Sharing the Risk with other entities through insurance, subcontracting, or risk financing;
5. Keep the Risk accepted by the Risk acceptance criteria or by informed decision (such as maintaining the existing e-commerce portal).

Each risk should be evaluated against the information security objectives using one or more of these options, to meet risk acceptance criteria.

Determining the controls that need to be in place:

The determination of the required information security controls should receive special attention. An information security risk assessment should be used to determine which controls to implement. It may be a poor foundation for a company’s choice of data security controls if the company has a poor information security risk assessment.

A proper control determination ensures:

1. There are no unnecessary controls chosen, and all necessary controls are included;
2. Control measures are planned according to an appropriate depth and breadth.

Poor control selection can lead to the following information security risk treatment:

1. It is ineffective;
2. Inefficient and therefore expensive.

Therefore, it’s imperative to show the connection between the required controls and the risk treatment results if you want to ensure that information security risk treatment is effective and efficient. The solution to a knowledge security risk is often a combination of multiple controls. For example, if the choice is made to manipulate the results of a specific event, then it is possible to employ controls for prompt detection, as well as controls for responding to and recovering from the event.

In determining controls, the organization should also take into account controls necessary for services provided by third-party service providers, such as applications, processes, and functions. As part of these controls, information security requirements are typically included in the contracts with suppliers, including a way to determine the extent to which these requirements are met (such as a right of audit). An organization might also wish to define detailed controls as a part of its ISMS, despite outside providers administering the controls. No matter what approach is taken, the organization should always consider the controls needed by the suppliers when determining the controls for its ISMS.

Comparison of controls with those found in ISO/IEC 27001:2013

The control objectives and controls in Annex A of ISO/IEC 27001:2013 are extensive. This document directs users to the generic representation of controls in ISO/IEC 27001:2013, Annex A to make sure that no crucial controls are ignored. In comparison with ISO/IEC 27001:2013, Annex A can also identify alternatives to those that were determined by which may be simpler to implement in terms of modifying information security risk. Control objectives are implicitly incorporated into the choice of controls. ISO/IEC 27001:2013, Annex A doesn’t list all the control objectives and controls that should be used and more still should be added if necessary.

It is not mandatory to include every control in Annex A, ISO/IEC 27001:2013. If a control is not contributing to lowering risk, it is best to exclude it and to justify the exclusion. ISO/IEC 27001:2013, Annex A provides several good examples.

Creating a Statement of Applicability (SoA)

In the SoA, you will find:

1. The inclusion of an impact is partially based on the result of the control in modifying an information security risk. By implementing necessary controls, the assessment results and the treatment plan on information security risk should be sufficient, along with the knowledge security risk modification that is expected.
2. The following reasons can be used to exclude an impact that appears in ISO/IEC 27001:2013, Annex A:
– The control is not required to implement the chosen option(s) for information security risk treatment;
– The control is irrelevant because it falls outside the scope of the ISMS (e.g. ISO/IEC 27001:2013,
For a company that performs all of its system development internally, outsourcing does not make sense)
– The level of control (e.g., ISO/IEC 27001:2013 manages removable media as a service, but this service may be excluded if a custom control prevents the use of removable media).

Note: A custom control may not be included in ISO/IEC 27001:2013, Annex A.

Often, a useful SOA can be generated as a table containing all 114 controls of ISO/IEC 27001:2013, Annex A, along with any additional controls that aren’t listed there. In the table, a column can indicate whether an impact is important for implementing the Risk treatment option(s), or if it is often excluded. Following that column will be the justifications for including or excluding impacts; a final column can indicate the status of the current implementation of the control. Additional columns are often used, including details not required by ISO/IEC 27001, which are often useful for subsequent reviews; such details may include a more detailed description of the control’s implementation, a cross-reference to an even more detailed description, or documented information or policies relevant to implementation.

It’s not mandatory in ISO/IEC 27001, but organizations may find it useful to express responsibility for the operation of all controls within a SOA.

Developing an information security risk treatment plan

The ISO/IEC 27001 does not specify a structure or content for the knowledge security risk treatment plan.

As a result, every risk treated must be documented as follows:

1. Choice of treatment option(s);
2. Necessary control(s); and
3. Status of implementation.
4. The risk owner(s);
5. The residual risk that will remain after taking action.

Risk treatment plans may call for some sort of action, which would include responsibilities and deadlines. A list of actions is often included in such action plans.

Risk treatment plans are usually arranged in a table according to the identified risks during risk assessment, showing the controls that have been identified. For instance, the names of those responsible for controlling are often listed in columns of this table. There can also be columns listing the date of implementation, the purpose of the control (or a process), as well as the implementation status of the control.

For example, consider how the Risk treatment process would be applied in the case of mobile phone theft.

Consequently, data is no longer available and is at risk of being disclosed in an undesirable manner. If the extent of risk is beyond what the organization can accept, the organization can plan to modify the probability, or modify the results of the risk. The organization can determine that a good way to reduce the likelihood of loss or theft of mobile devices is to require employees to take care of them and check for loss periodically through a policy for mobile devices.

Controls such as these can modify the consequence of theft or loss of a mobile device:

– The ability to report a loss via an event management process;
– If the phone is lost, a Mobile Device Management (MDM) solution can be used to delete its content;
– A backup plan for mobile devices that can be used to restore the data on the device.

As part of its SOA, the organization can include its chosen controls (mobile device policy and MDM), justifying their inclusion based on the changes in likelihood and consequences of loss or theft of mobile devices, resulting in reduced residual risk.

It is frequently seen that these controls align with those listed in ISO/IEC 27001:2013, Annex A, except that the Mobile Device Management control doesn’t directly align and will be considered as a further custom control. Those controls that are determined to be necessary (i.e. MDM in support of SOA and other controls) in an organization’s information security risk treatment strategy, should be included within the SoA (see “Guidance on producing an SoA”)

To reduce the risk further, the organization can consider ISO/IEC 27001:2013(access control policy) by modifying the mobile device policy to require PINs with all mobile devices. Adding another control could then vary the outcome of a loss or theft of a mobile phone.

During the development of its information security risk treatment plan, the organization should include actions to implement mobile device policy and MDM along with the assigned responsibilities and timelines.

Obtaining permission from risk owners

The knowledge security risk treatment plan must be approved by the Risk owners when it is formulated. Authorizations of this nature should be accompanied by risk acceptance criteria or justified concessions if they differ from them. Organizations should record in their management processes the Risk owner’s acceptance of residual risk and the management’s approval of the plan.

In the Risk treatment plan described under guidance, these approvals are often documented by adding columns that indicate whether the controls successfully mitigate the risk and whether a residual risk exists, and therefore confirming the approval from the risk owner.

ISO 27001

Lifestyle

Travel

Food

Fashion

Advertisment

Instagtam

Newsletter