The organization defines and applies an information security risk treatment process.
Information security risk treatment is that the overall process of choosing risk treatment options, determining appropriate controls to implement such options, formulating a risk treatment plan and obtaining approval of the Risk treatment plan by the Risk owner(s).All steps of the knowledge security risk treatment process also because the results of its application are retained by the organization as documented information.
Information security risk treatment options
Risk treatment options are:
- Avoiding the Risk by deciding to not start or continue with the activity that provides rise to the Risk or by removing the Risk source (e.g. closing an e-commerce portal);
- Taking additional risk or increasing risk so as to pursue a business opportunity (e.g. opening an e-commerce portal);
- Modifying the Risk by changing the likelihood (e.g. reducing vulnerabilities) or the results (e.g. diversifying assets) or both;
- Sharing the Risk with other parties by insurance, sub-contracting or risk financing; and
- Retaining the Risk supported the Risk acceptance criteria or by informed decision (e.g. maintaining the prevailing e-commerce portal because it is).
Each individual risk should be treated in line with information security objectives by one or more of those options, so as to satisfy risk acceptance criteria.
Determining necessary controls
Special attention should tend to the determination of the required information security controls. Any control should be determined supported information security risks previously assessed. If a corporation features a poor information security risk assessment, it’s a poor foundation for its choice of data security controls.
Appropriate control determination ensures:
- All necessary controls are included, and no unnecessary controls are chosen; and
- The planning of necessary controls satisfies an appropriate breadth and depth.
As a consequence of a poor choice of controls, the proposed information security risk treatment can be:
- Inefficient and thus inappropriately expensive.
To ensure that information security risk treatment is effective and efficient, it’s therefore important to be ready to demonstrate the connection from the required controls back to the results of the Risk assessment and risk treatment processes. It is often necessary to use multiple controls to realize the specified treatment of the knowledge security risk for instance , if the choice to vary the results of a specific event is chosen, it may require controls to effect prompt detection of the event also as controls to reply to and recover from the event.
When determining controls, the organization should also take under consideration controls needed for services from outside suppliers of e.g. applications, processes and functions. Typically, these controls are mandated by entering information security requirements within the agreements with these suppliers, including ways to urge information close to which extent these requirements are met (e.g. right of audit). There could also be situations where the organization wishes to work out and describe detailed controls as being a part of its own ISMS albeit the controls are administered by outside suppliers. Independently of the approach taken, the organization always should consider controls needed at their suppliers when determining controls for its ISMS.
Comparing controls with those in ISO/IEC 27001:2013,
Annex A ISO/IEC 27001:2013, Annex A contains a comprehensive list of control objectives and controls. Users of this document are directed to the generic representation of controls in ISO/IEC 27001:2013, Annex A to make sure that no necessary controls are overlooked. Comparison with ISO/IEC 27001:2013, Annex A also can identify alternative controls to those determined in which may be simpler at modifying information security risk. Control objectives are implicitly included within the controls chosen. The control objectives and controls listed in ISO/IEC 27001:2013, Annex A aren’t exhaustive and extra control objectives and controls should be added as required.
Not every control within ISO/IEC 27001:2013, Annex A must be included. Any control within ISO/IEC 27001:2013, Annex A that doesn’t contribute to modifying risk should be excluded and justification for the exclusion should tend.
Producing a Statement of Applicability (SoA)
The SoA contains:
- Justification for including an impact partially relies on the effect of the control in modifying an information security risk. A regard to information security risk assessment results and therefore the information security risk treatment plan should be sufficient, alongside the knowledge security risk modification expected by the implementation of necessary controls.
- Justification for excluding an impact contained within ISO/IEC 27001:2013, Annex A can include the following:
- It’s been determined that the control isn’t necessary to implement the chosen information security risk treatment option(s);
- The control isn’t applicable because it’s outside the scope of the ISMS (e.g. ISO/IEC 27001:2013,
- Outsourced development isn’t applicable if all the organization’s system development is performed in-house)
- It’s obviated by a custom control (e.g. in ISO/IEC 27001:2013 management of removable media might be excluded if a custom control prevents the utilization of removable media).
NOTE A custom control may be a control not included in ISO/IEC 27001:2013, Annex A.
A useful SoA are often produced as a table containing all 114 controls of ISO/IEC 27001:2013, Annex A along the rows plus rows with the extra controls that aren’t mentioned in ISO/IEC 27001:2013, Annex A, if needed. One column of the table can indicate whether an impact is important to implement the Risk treatment option(s) or are often excluded. A next column can contain the justification for inclusion or exclusion of an impact. a final column of the table can indicate the present implementation status of the control. Further columns are often used, like for details not required by ISO/IEC 27001 but usually useful for subsequent reviews; these details are often a more detailed description of how the control is implemented or a cross-reference to a more detailed description and documented information or policies relevant for implementing the control.
Although it’s not a selected requirement of ISO/IEC 27001, organizations can find it useful to incorporate responsibilities for the operation of every control included within the SoA.
Formulating an information security risk treatment plan
ISO/IEC 27001 doesn’t specify a structure or content for the knowledge security risk treatment plan.
Thus the plan should document for every treated risk:
- Selected treatment option(s);
- Necessary control(s); and
- Implementation status.
- Risk owner(s);
- Expected residual risk after the implementation of actions.
If any action is required by the Risk treatment plan, then it should be planned indicating responsibilities and deadlines such an action plans are often represented by an inventory of those actions.
A useful information security risk treatment plans are often designed as a table sorted by risks identified during the Risk assessment, showing all the determined controls. As an example, there are often columns during this table which indicate the names of the persons liable for providing the controls. Further columns can indicate the date of implementation of the control, information about how the control (or a process) is meant to work and a column about the target implementation status.
As an example for a part of the Risk treatment process, consider the theft of a mobile.
The results are loss of availability and potential undesirable disclosure of data. If the assessment of the Risk showed that the extent of risk is out of acceptance, the organization can plan to change the likelihood, or change the results of the Risk .To change the likelihood of loss or theft of a mobile , the organization can determine that a suitable control is to oblige employees through a mobile device policy to require care of mobile phones and periodically check for loss.
To change the consequence of loss or theft of a mobile, the organization can determine controls such as:
- An event management process so users can report the loss;
- A Mobile Device Management (MDM) solution to delete the content of the phone if lost; and
- A backup plan of mobile devices for recovering the phone’s content.
When preparing its SoA, the organization can include its chosen controls (mobile device policy and MDM), justifying their inclusion supported their effects of changing the likelihood and consequences of mobile loss or theft, leading to reduced residual risk.
Comparing these controls with those listed in ISO/IEC 27001:2013, Annex A, it is often seen that the mobile device policy is aligned with ISO/IEC 27001:2013, A.6.2.1, but the MDM control doesn’t directly align and will be considered as a further custom control. If MDM and other controls are determined as necessary control(s) in an organization’s information security risk treatment plan, they ought to be included within the SoA (see “Guidance on producing an SoA .
If the organization wants to further reduce the Risk, it can consider from ISO/IEC 27001:2013(access control policy) that it lacked control of access to mobile phones and modify its mobile device policy to mandate the utilization of PINs on all mobile phones. this could then be an extra control to vary the results of loss or theft of mobile phones.
When formulating its information security risk treatment plan, the organization should then include actions to implement mobile device policy and MDM and assign responsibilities and time frames.
Obtaining risk owners’ approval
When the knowledge security risk treatment plan is formulated, the organization should obtain the authorization from the Risk owners. Such authorization should be supported defined risk acceptance criteria or justified concession if there’s any deviance from them. Through its management processes the organization should record the Risk owner’s acceptance of the residual risk and management approval of the plan.
As an example, this risk owner’s approvals are often documented by amending the Risk treatment plan described under guidance on by columns indicating the effectiveness of the control, the residual risk, and therefore the risk owner’s approval.
Questions related to this topic
- How would you implement ISO 27001 in an organization?
- What are the ISO 27001 controls?
- How many controls are there in ISO 27001?
- What are the 14 domains of ISO 27001?
ISO 27001 Requirements
Clause 4.4 Information security management system
Clause 4.3 Determining the scope of the information security management system
Clause 5.1 Leadership and commitment
Clause 5.2 Policy
Clause 5.3 Organizational roles, responsibilities and authorities
Clause 6.1 Actions to address risks and opportunities
Clause 6.1.2 Information security risk assessment process
Clause 6.2 Information security objectives & planning
Clause 7.1 Resources
Clause 7.2 Competence
Clause 7.3 Awareness
Clause 7.4 Communication
Clause 7.5 Documented information Implementation Guideline
Clause 8.1 Operational planning & control
Clause 8.2 Information security risk assessment
Clause 8.3 Information security risk treatment
Clause 9.1 Performance evaluation Monitoring, measurement, analysis & evaluation
Clause 9.2 Internal audit
Clause 9.3 Management review
Clause 10.1 Non conformity and corrective action
Clause 10.2 Continual Improvement
ISO 27001 Annex A Controls
Annex A.5 Information Security Policies
Annex A.6 Organization of Information Security
Annex A.6.2 Mobile Devices and Teleworking
Annex A.7 Human Resource Security
Annex A.7.2 During Employment
Annex A.7.3 Termination and Change of Employment
Annex A.8 Asset Management
Annex A.8.1.3 Acceptable Use of Assets & A.8.1.4 Return of Assets
Annex A.8.2 Information Classification
Annex A.8.2.2 Labeling of Information & A.8.2.3 Handling of Assets
Annex A.8.3 Media Handling
Annex A.9 Access Control
Annex A.9.1.2 Access to Networks and Network Services
Annex A.9.2 User Access Management
Annex A.9.2.3 Management of Privileged Access Rights
Annex A.9.2.4 Management of Secret Authentication Information of Users
Annex A.9.2.5 Review of User Access Rights
Annex A.9.2.6 Removal or Adjustment of Access Rights
Annex A.9.3 User Responsibilities
Annex A.9.4 System and Application Access Control
Annex A.9.4.4 Use of Privileged Utility Programs
Annex A.9.4.5 Access Control to Program Source Code
Annex A.10 Cryptography
Annex A.11 Physical and Environmental Security
Annex A.11.2 Equipment
Annex A.11.1.3 Securing Offices, Rooms and Facilities
Annex A.11.1.4 Protecting Against External and Environmental Threats
Annex A.11.1.5 Working in Secure Areas
Annex A.11.1.6 Delivery and Loading Areas
Annex A.11.2.4 Equipment Maintenance
Annex A.11.2.5 Removal of Assets
Annex A.11.2.6 Security of Kit and Assets Off-Premises
Annex A.11.2.7 Secure Disposal or Re-use of Equipment
Annex A.11.2.8 Unattended User Equipment
Annex A.11.2.9 Clear Desk and Clear Screen Policy
Annex A.12 Operations Security
Annex A.12.2 Protection from Malware
Annex A.12.3 Backup
Annex A.12.4 Logging and Monitoring
Annex A.12.5 Control of Operational Software
Annex A.12.6 Technical Vulnerability Management
Annex A.12.7 Information Systems Audit Considerations
Annex A.13 Communications Security
Annex A.13.2 Information Transfer
Annex A.13.2.3 Electronic Messaging
Annex A.13.2.4 Confidentiality or Non-Disclosure Agreements
Annex 14 System Acquisition, Development and Maintenance
Annex A.14.1.2 Securing Application Services on Public Networks
Annex A.14.1.3 Protecting Application Services Transactions
Annex A.14.2 Security in Development and Support Processes
Annex A.14.2.3 Technical Review of Applications after Operating Platform Changes
Annex A.14.2.4 Restrictions on Changes to Software Packages
Annex A.14.2.5 Secure System Engineering Principles
Annex A.14.2.6 Secure Development Environment
Annex A.14.2.7 Outsourced Development
Annex A.14.2.8 System Security Testing
Annex A.14.2.9 System Acceptance Testing
Annex A.14.3 Test data
Annex A.15 Supplier Relationships
Annex A.15.1.2 Addressing Security Within Supplier Agreements
Annex A.15.1.3 Information and Communication Technology Supply Chain
Annex A.15.2 Supplier Service Delivery Management
Annex A.16 Information Security Incident Management
Annex A.16.1.2 Reporting Information Security Events
Annex A.16.1.3 Reporting Information Security Weaknesses
Annex A.16.1.4 Assessment of and Decision on Information Security Events
Annex A.16.1.5 Response to Information Security Incidents
Annex A.16.1.6 Learning from Information Security Incidents
Annex A.16.1.7 Collection of Evidence
Annex A.17 Information Security Aspects of Business Continuity Management
Annex A.17.1.3 Verify, Review and Evaluate Information Security Continuity
Annex A.18 Compliance
Annex A.18.1.3 Protection of Records
Annex A.18.1.4 Privacy and Protection of Personally Identifiable Information
Annex A.18.1.5 Regulation of Cryptographic Controls
Annex 18.2 Information Security Reviews
About ISO 27002
- ISO 27002 – INTRODUCTION
- ISO 27002 Information technology Security techniques Code of practice for information security controls
This Blog Article is posted by
Infosavvy, 2nd Floor, Sai Niketan, Chandavalkar Road Opp. Gora Gandhi Hotel, Above Jumbo King, beside Speakwell Institute, Borivali West, Mumbai, Maharashtra 400092
Contact us – www.info-savvy.com