Item | Value |
Organization | Information Dynamics |
Document Name | Risk Assessment Methodology |
Classification | Internal |
Compliance Reference | ISO 27001:2013,ISO 20000:2018, ISO 31000:2011 |
Date | Version | Prepared By |
07-March-2020 | 1.0 | First Version |
07-March-2021 | 2.0 | Version Upgrade |
07-March-2022 | 3.0 | Version Upgrade |
07-March-2023 | 4.0 | Annual Review |
Reviewed By | Version | Date | Signature |
Sankar | 1.0 | 07-Mar-2020 | |
Sankar | 2.0 | 07-Mar-2021 | |
Linda | 3.0 | 07-Mar-2022 | |
Linda | 4.0 | 07-Mar-2023 |
Purpose
The purpose of this document is to provide a methodology to conduct Information Security Risk Assessments. This document covers the fields that need to be calculated during risk assessments, Identification of risk owners, treatment plans considerations and Risk Acceptance of the firm. This risk assessment methodology is based on the ISO 31000 standard and can be used for any department in the firm.
Scope
The scope of this document applies to all information assets across IT department of Information Dynamics. The theme of this risk assessment shall be to capture information security related risks.
Methodology
Risk Assessment is a mandatory exercise as per multiple standards like ISO 27001:2013, ISO 20000:2018
The risk assessment exercise shall help identify risks affecting the organization’s information,
process from an internal and external context.
The methodology of risk assessment is based on the below framework. The following events are the triggers for the risk management process:
New system/project initiation
Periodic Assessment/evaluation of existing information systems
The discovery of new threats/vulnerabilities
Changes to Asset inventory (e.g. new hardware/operating system /application updates)
Changes to operational procedures
Changes to the processes and system dependencies/inter-relationships
Changes to the Organization
Changes to the Technology
Changes to Business objectives and processes
Changes to the effectiveness of the controls
External events, such as changes to the legal or regulatory environment, changed contractual obligations, and changes in social climate.
Internal and external context are factors that might affect Information Dynamics. These factors might be inputs from internal or external sources. These shall have an impact on Information Dynamics in terms of financial, image and reputation, social, technological, economical etc. This analysis can be done through a PEST analysis to understand the different aspects which affect Information Dynamics on regular basis. (PEST – Political, Economical, Social and Technological). Information Dynamics shall identify these factors and map to information security controls. Any risks that can be foreseen through these factors shall go through a risk assessment and have a mitigation plan.
Risk Events (Combination of threats and Vulnerabilities) shall be identified by the department which might affect the services provided by Information Dynamics. This shall be a combination of threat and Vulnerability for easier reference by all business units. (This shall be referred as “Risk Event” or “Risk Statement”). The risk assessments shall be conducted for every department, however the inputs to the exercise shall be based on the information assets the department possess. Inline with the department services provided and the assets involved, the sources of these risk events shall be
identified and the areas of impact shall be calculated. Each risk shall have respective assets mapped to them to understand what assets shall be affected if the risk materializes.
Risk Type determination is based on 3 factors.
Risk Type | Description |
New Risks | Risks arising based on new external/ internal threats in the environment. |
Inherent Risks | The risk that an activity would pose if no controls or other mitigating factors were in place (the gross risk or risk before controls) |
Residual Risks | Residual risk is the risk that remains in the system after the security controls have been adopted. |
Risk events are generally from multiple sources; however, the sources are segregated into the following categories.
Technical Assessment
Compliance Assessment
Audit Management (Internal & External)
Information Access Control review
Security Architecture Review
Security Incident Registers
Review of Minimum Baseline Security Standards
Project Risks
OWASP Technical Security
Risks related to human resources
Discussion with the Service Owners on security risks in their process.
Risk Events shall be evaluated with the following areas of impact to determine the criticality of the service:
Image and Reputation
Internal Operations
Financial Loss
Legal and Compliance
Customers
These analyses of risk events and their likelihood of occurrence shall be determined by the respective teams and identified for specific services.
Risk Analysis phase is the where the risks are assessed and calculated based on analysis of risk events, their potential impact and the likelihood of occurrence.
The potential impact is the overall impact that the service might have on organization if any risks are not mitigated and lead to a successful breach. Each area shall be rated against 3 ratings, Minor, Moderate, Major and NA (Not Applicable)
RATING | DECISION FACTORS - LEVELS |
Very Low | Service likely to have minimal effect on this area or no effect. |
Low | Low impact on the services if the risk is materialized |
Medium | Moderate impact to the operations/ business if the service is affected. Services are down, but can be manageable upto certain time. |
High | High impact to business operations and organization reputation if the service is affected |
Very High | Very High impact to the business operations. Highest level and needs immediate attention |
Potential Impact takes the highest of the impact areas.
While determining the probability, the threat frequency in terms of how often it might occur, based on past experience and statistics shall be considered. Geographical factors such as proximity to natural disaster, the possibility of extreme weather conditions, and factors that could influence human errors and equipment malfunction.
The likelihood of threat occurrence is valued using the following scale.
Likelihood Of Occurrence | Values |
Very Unlikely | 1 |
Unlikely | 2 |
Could Happen | 3 |
Likely | 4 |
Very Likely | 5 |
Risk Calculation is the product of the Potential Impact and the Likelihood of Occurrence. Eg: If the impact of the service is High and the probability of occurrence is very likely, then the risk associated to it is High.
Risk = Potential Consequence X Likelihood of Occurrence
Likelihood | ||||||
Impact | 1 | 2 | 3 | 4 | 5 | |
1 | 1 | 2 | 3 | 4 | 5 | |
2 | 2 | 4 | 6 | 8 | 10 | |
3 | 3 | 6 | 9 | 12 | 15 | |
4 | 4 | 8 | 12 | 16 | 20 | |
5 | 5 | 10 | 15 | 20 | 25 | |
Risk | Value |
Very Low | 1 to 5 |
Low | 6 to 10 |
Medium | 11 to 15 |
High | 16 to 20 |
Very High | 21 to 25 |
In the Risk Evaluation phase, the identified risks values are compared to acceptable risk level agreed by the ISSC. In case of risk value being greater than the acceptable level, a mitigation plan shall be made to adopt security controls.
Risk Treatment requires a baseline for prioritizing and treating risks. The baseline level indicates the acceptable values of risk. Risk values above the acceptable level require treatment at a higher priority. Risk values within the baseline level may be accepted.
The Information Security Steering Committee has accepted Very Low and Low risks All Medium, High and Very High risks shall be treated. (Risk Score of 11 and above)
Some risk values may remain above this baseline level because they cannot be immediately treated due to various factors such as lack of resources, high mitigation costs etc. These need to be separately accepted at their higher risk values and signed off by the Information Security Steering Committee. Risk values within the baseline level do not require any such formal acceptance.
Any risk value above the acceptable value defined by the management shall have a treatment plan. However, in certain cases, risks above the acceptable level which cannot be treated can be accepted based on certain factors and management approvals.
Management shall accept the risks based on multiple criteria that can be assessed or might be subjective to the business. However the following shall be considered:
Return on Investment - This is based on the cost involved in implementing the control and the risk that it addresses. If the cost involved in implementing the control is more than the actual risk reduction, then the management might take a decision to accept the risk.
Information that the control might safeguard –If the control that is going to be implemented safeguards the information which is not critical to the organization, then the decision might be taken by the committee to accept the risk.
Resources Not Available for the project/ Control Implementation – If the adoption of controls requires additional resources in terms of employees, technology and other areas which is not feasible, then the management can decide to accept the risk. However, if the same is a critical risk, then it shall need to be monitored on regular basis with alternative compensating controls.
Incompatibility or Technically not feasible –If the controls are not technically feasible with information systems, especially legacy systems and incompatible systems, then the management might decide to accept the risks. However since the information is present in the legacy systems, the same shall be monitored on a regular basis.
Risk Owner: Risk Owner might be the service owner or head of the department who shall own a risk which has been rated above acceptable level. His responsibility shall be to own, plan to mitigate and follow-up on the mitigation plan to ensure security controls are adopted.
The risk owner shall have the following options for risk treatment
Mitigate (Treat) – Identify controls to reduce the identified risks.
Accept – Accept the Risk as it is. This shall require a Risk acceptance being signed off by the ISSC committee. Also requires an estimated timeline till when this is acceptable.
Transfer – Transfer the risk to a third party/ external source for managing services.
After identification of risks, a respective security control to be implemented shall be identified by the Security team in coordination with the service owners.
It is seldom possible and impractical to completely eliminate risks to information in terms of confidentiality, integrity or availability. Information Dynamics needs to operate efficiently and economically, and therefore management decisions are made which balance cost and time implications for security measures against the probability of an incident that could affect delivery of product/service, or jeopardize the organizations security. Hence identification of the appropriate security controls as per the ISO 27001 is necessary before implementation; these controls will be evaluated/selected on the following criteria for implementation at Information Dynamics.
Control is appropriate to the identified risk.
The control will avoid the risk.
The control will transfer the risk to an insurer or a supplier.
Information Dynamics might knowingly and objectively accept a risk due to the cost/benefit factor but such acceptance will be in line with Information Dynamics policies and acceptance criteria.
Note: All identified risks and treatment plans shall have to be approved by IT department head.
The residual risk is calculated with additional 2 factors. These 2 factors decide the strength of the controls that have been implemented to address the risk.
Control strength is a product of Control State and Control Type. Based on the control implemented, the control strength can be calculated as per the below table.
CONTROL STRENGTH | Control Type | ||
Control State | Detection (2) | Preventive (3) | |
Manual (1) | 2 | 3 | |
Automatic (2) | 4 | 6 | |
Treatment of Risks are based on effective controls implementation. These controls shall ensure the likelihood of the occurrence shall reduce leading to reduction of risks.
However to ensure this, an estimate timeline have been associated with each risk level. Risks have to be closed within this specific timelines.
Risk | Timelines to treat Risks |
Medium | Within 8 Months |
High | Within 5 months |
Very High | Within 3 Months |
Though the risks have a specific timeline associated for closure, if there is any mandate or a requirement from any other source that the risk needs to be mitigated earlier (than the timelines given in the above table), then that particular timeline will override this table.
Critical identified controls shall be measured on a regular basis. These shall be aligned to the objectives, measurement of specific controls implemented and KPIs.
Risk Assessment results shall be reviewed atleast on an yearly basis.
Information Security Steering Committee
Review the risk assessment methodology and decide on the acceptable level of risk.
The ISSC shall review the risks atleast once a year.
Asset owner – Be updated about the risk and the mitigation point planned.
Risk Owner – Ensure identified risks are accepted and according treatment plans are implemented.
Information Security Officer
Coordinate with the risk owners to assist in mitigating risks related to information security.
Provide awareness on how to conduct the risk assessment to all the teams involved.
Discuss the Risk Assessment methodology with the ISSC and collect inputs. The ISO can approve the methodology on behalf of the committee only after discussion with ISSC.
Information Technology Department – Assist in implementing technical controls to close risks in coordination with the risk owners.
Risk Assessment is a mandatory exercise for the departments. Any risk that is above the acceptable level approved by the steering committee shall be treated. However, if there are any risks that are above the acceptable level, but still cannot be treated, shall be approved as an exception by the Information Security Steering Committee. A Risk Acceptance/ Mitigation Exception form shall be filled to document any exception.