Risk Assessment Methodology Page 1
Risk Assessment Methodology
Risk Assessment Methodology
ISO 27001:2013, ISO 20000:2018,
Document Revision History
Document Review History
Risk Assessment Methodology Page 2
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.
The scope of this document applies to all information assets across IT department of Information Dynamics. theme of this risk assessment shall be capture information security related risks.
3.1. General Principles
Risk Assessment is a mandatory per multiple standards ISO 27001:2013, ISO 20000:2018
The risk assessment exercise shall identify risks affecting the organization’s information, from an internal and external context .
3.2. Risk Assessment Methodology
The methodology of risk assessment is based on below framework.
following events the triggers for the risk management process:
✓ New system/project initiation
✓ Periodic Assessment/evaluation of existing information systems
✓ The discovery of new threats/vulnerabilities
✓ to Asset inventory (e.g. new hardware/operating system /application updates)
✓ Changes to operational procedures
✓ Changes to the processes and dependencies/inter-relationships
✓ Changes to Organization
✓ Changes to the Technology
✓ Changes to Business objectives and processes
✓ Changes to the of the controls
✓ External events, such as changes to the legal or regulatory environment, changed contractual obligations, and changes in social climate.
Risk Assessment Methodology Page 3
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.
3.4. IDENTIFICATION OF RISKS
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
Risk Assessment Methodology Page 4
identified and the areas of impact shall be calculated. Each risk shall have respective assets mapped to them understand what affected if the risk materializes.
3.5. Determining Risk Type
Risk Type determination is based on 3 factors.
Risks arising based on new external/ internal threats in the environment.
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 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.
1. Technical Assessment
2. Compliance Assessment
3. Audit Management (Internal & External)
4. Information review
5. Security Architecture Review
6. Security Incident Registers
7. Review of Minimum Baseline Security Standards
8. Project Risks
9. OWASP Technical Security
Risk Assessment Methodology Page 5
10. Risks related to human resources
11. Discussion with Service Owners on security risks in their process.
12. Third party Vendor related risks
Risk Events shall be evaluated with the following areas of impact to determine the criticality of the service:
1. Image and Reputation
2. Internal Operations
4. Legal and Compliance
These analyses of risk events and their likelihood of occurrence shall be determined by the respective teams and identified for specific services.
Analysis phase is the where the risks are assessed and calculated based analysis of risk events, their potential impact the likelihood of occurrence.
4.1. Impact/ Consequence:
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 rated against 3 ratings, Minor, Moderate, Major and NA (Not Applicable)
Risk Assessment Methodology Page 6
Potential Impact takes the highest of the areas.
4.2. Likelihood or Likelihood of risk event:
While determining the likelihood, 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 of threat is valued using following scale.
Service likely to have effect on this area or no effect.
Low impact on the services if the risk is materialized
Moderate impact the operations/ business if the service affected. Services are down, but can be manageable upto certain time.
High impact to business operations and organization reputation if the service is affected
Very High impact to the business operations. Highest level and needs immediate attention
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 likelihood of occurrence is very likely, then the risk associated to it is High.
Risk = Potential Consequence X Likelihood of Occurrence
Risk Assessment Methodology Page 8
5. RISK EVALUATION
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 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 such formal acceptance.
Risk Assessment Methodology Page 9
5.2. Justification of Accepting Risks
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 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 shall be considered:
1. 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 accept the risk.
2. 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.
3. 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.
4. 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 plan to ensure security controls are adopted.
The risk shall have the following options for risk treatment
Mitigate (Treat) – Identify controls to reduce the identified risks.
Risk Assessment Methodology Page 10
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 when this is acceptable.
Transfer – Transfer the risk to a third party/ external source for managing services.
6.1. Identification of Controls
After identification of risks, a respective security control to be implemented shall be identified by the Security in coordination 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 likelihood 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.
1. Control is appropriate to identified risk.
2. The control will transfer the risk an insurer or a supplier.
3. 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.
6.3. Residual Risk Calculation
The risk is calculated with 2 factors. These 2 factors decide the strength of the that have been implemented to the risk.
Control State: States what kind control has been implemented. be Automatic or Manual
➢ Automatic Control: Needs to human intervention. This is usually automatically updated by a technology in or using a script.
Assessment Methodology Page 11
➢ Manual Control: Needs human identifying and managing the control
type: 2 types of controls implemented based on its nature:
➢ Detection: Risk can be detected alert might be generated the respective personnel can made aware of the risk.
➢ Preventive: Risk be detected and also be prevented. Uses intervention mostly.
Control strength is a product of State and Control Type. Based on control implemented, the control strength can be calculated as per the below table.
Residual Risk = ( Level New Likelihood After Control Implementation)/ Control Strength
6.4. Priority and Timelines for Risk Treatment
Treatment of Risks are based on effective controls implementation. These controls shall ensure the likelihood of the occurrence shall leading to reduction of risks.
However to ensure this, an estimate timeline have been with each risk level. Risks have be closed within specific timelines .
Risk Assessment Methodology Page 12
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.
7.2. Review of the Risk Assessments:
Risk Assessment results shall be reviewed atleast on an yearly basis.
• Information Steering Committee
o the risk assessment methodology and decide on acceptable level of risk.
o The ISSC shall review the risks once a year .
• Asset owner – Be updated about risk and mitigation point planned.
• Risk Owner – Ensure identified risks are accepted and according treatment plans are implemented.
• Information Security Officer
o Coordinate with the risk owners to assist in mitigating risks related to information security.
o Provide on how to conduct the risk assessment to the teams involved.
Risk Assessment Methodology Page 13
o 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 owners.
Assessment Methodology Page 14
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.