ISMS Risk Methodology
1. Purpose, Scope and User
This policy defines how VSHN does information security risk assessment and information security risk treatment within the organization to ensure compliance with ISO/IEC 27001.
This risk methodology is designed to be applicable in future information security risk assessments within VSHN. The objective is ensuring a continuous improvement of the information security risk management process. Furthermore, it should be kept short and simple and an approach should be defined which is effective for VSHN.
The approach relies largely on the documented methods from the book Secure & Simple: A Small-Business Guide to Implementing ISO 27001 On Your Own from Dejan Kosutic.
The aim is that the process should run regularly and be easily modifiable, allowing for continuous improvement over time. Risk management in general has the potential to get out of hand if attempting to thoroughly examine every possible aspect. It is important to be close to the teams or roles and listen what they daily use and where they see the biggest threats regarding information security risks in regards of confidentiality, availability, and integrity.
The main purpose of this document is that the CISO and the ISM Governance Role have a reference for addressing information security risks in VSHN. The CISO is responsible to educate VSHNeers where needed about this policy.
2. Actual Risk Methodology
The process for identifying risks concentrates on the teams and roles; it focuses on data and system-based risks, with an asset-based approach. To conduct an asset-based risk assessment, the person overseeing the risk assessment (for example the CISO) conducts one-on-one interviews with knowledgeable people, namely risk owners. During these interviews, the CISO asks about which assets such as hardware, software, and services, they use in their daily operations.
The risk owner must be familiar with the concept of an asset, which can be anything which is of value to the organization or anything that it want to protect. The assets of an organization may include people asset, infrastructure, information processing, transmitting and storage systems, outsourced services etc. And these assets affect the C-I-A triad (confidentiality, integrity, availability) of the information in the organization. This understanding should be given by the CISO during the interview, who further explains the risk assessment methodology and the asset-based approach before assisting the risk owner in identifying the most important assets of their team or role, and addressing potential threats and vulnerabilities.
2.1. Risk Owners
Risk owners are not individuals, but actually the teams and roles . The CISO ensures that go-to persons for each team or role are defined and documented (as of now in the wiki page "Kommunikation").
2.2. Identifying Risks
The CISO leads the risk identification process and invites the representative of the assessed team or role. There should be a separate interview with each representative. This may change in later iterations of this process in subsequent years. But especially in the beginning the experience and know-how of the CISO is crucial to support the representative in finding all assets and possible risks in their area.
During the interview, the CISO offers an overview of the risk assessment process and explains the concept of risk, referring to C-I-A triad, and emphasizing the significance of data and systems. The interview with the risk owner should involve two iterations. Firstly, the definition of all assets, with a walk-through of a typical workday, can be performed, and all assets are documented. Potential questions to identify assets include:
-
Which systems do you daily use?
-
Which systems does your team or role provide for customers?
-
What data do you touch in your daily work?
During the walk-through the risk owner tends to verbalize thoughts about the asset and its associated risks. These thoughts should be documented in the comment column of the risk assessment table in the wiki, as they are valuable for the second step: discussing and documenting the risks regarding those assets. The CISO’s role is to record these inputs and then document an initial working draft of the risk assessment table, which can be refined in later phases.
2.3. Mark Information Security Risks
In the context of the ISMS Risk Management the scope are information security risks. The CISO is responsible to ensure that information security risks are marked in the list as such.
Other risks like business risks, operational IT risks, etc. are not handled within this risk management process. But the identified risks could remain in the "Risk Backlog" of each domain and could be used as a base for other risk assessments in VSHN.
2.4. Assessing Consequences and Likelihood
Assessing consequences and likelihood is done using a qualitative approach. A scale from 1 to 4 for consequences and likelihood is used; because humans tend to drift towards the middle, requiring a decision for either the lower or higher part. This approach is chosen because it is lightweight and employees usually can identify the given risks or the most important systems by intuition. The criticality of an asset can be reflected in the consequences. For example, if a system is down for an extended period of time, but the data it contains is only needed within a week, the consequences of a risk "system not available" can be marked with a low criticality score.
The assessment of consequences and likelihood of the risks is conducted after the identification process. In the identification phase the number of possible risk rise quickly over two dozen each domain. It is advised to keep the number of risks to assess small as assessing up to fifty risks per domain with a meaningful score is too time-consuming. To be most effective the risk owner needs to point out five to ten most important risks for their team or role. Only these risks should be thoroughly assessed. Adding more elements will make the risk assessment difficult to use, potentially turning it into an assessment done primarily for audit purposes rather than providing tangible benefits for the daily business.
2.5. Risk Calculation
Risk calculation is done with addition of likelihood and consequences generating a risk matrix as represented in following picture:
The numbers are added to the risk assessment table. An example of a representation of such a table can be found in the picture below:
2.6. Criteria for Accepting the Risk
Risk acceptance should be done individually for each risk.
However, if the addition of likelihood and consequences equals 7 or 8 then the risk need a mitigation plan or has to be formally accepted by the top management (represented by the ISM Governance role). Risks with a lower score are examined individually. Not acceptable risks have to be tracked. The CISO establishes a risk mitigation plan together with the risk owner, which could be taken as a general annual plan. The CISO should incorporate a process to have regular reviews of the risks with the risk owners.
2.7. Documentation of Risks
Risks are documented in VSHN’s wiki in a page called VSHN Risk Management in the VSHN ISMS wiki space. There are sub pages for each type of domain and each team or role has an own page with a table. The table has these column headers:
-
Asset
-
Threat
-
Vulnerability
-
Risk Owner
-
Consequence
-
Likelihood
-
Risk Calculated
-
Comment — important in asset brainstorming to document the thoughts of the team representative
-
Optional: Treatment / ISO Control
-
Optional: Risk Calculated After Treatment
-
Last Assessed Date — for history
-
Added Date — supports to assess the 'why'
All identified risks are documented in the table, the ones classified as top five to ten risks during the assessment by the risk owner are documented as "Top Risks". Other found risks remain in a "Risk Backlog" on the same page for a possible later review. The risk assessment is continued with the top risks.
The top risks of each domain should be assigned a risk number for later reference. The risks in the backlog do not need a risk number until used in in a later risk assessments. The tables should be sorted according to the asset. This means grouping together all risks associated with Asset 1, followed by those related to Asset 2, and so forth. Responsible for creating and updating that tables is the CISO.
2.8. Risk Treatment Options
The possible risk treatment options include:
-
decreasing the risk
-
avoiding the risk
-
sharing the risk
-
retaining the risk
In most cases, the approach of reducing the risk is the right way to go. A risk is mitigated through corresponding controls. Therefore, for each assessed risk, a suitable control from the ISO/IEC 27001:2022 annex is selected, establishing a connection to the SOA. The chosen controls are added into risk table. Decisions regarding which risks need to be reduced or avoided through specific controls, or which can be shared or retained, are made collaboratively by the CISO and the respective risk owner. During the regular management review, the Management is informed about the defined risk treatment and has to take the final decision on the risk treatment. Besides the controls, a risk mitigation ticket can also be added to the risk table to link to an actual work packages for a team or role.
With these risk tables in hand, the CISO can provide a status update on risk treatment without much effort to every interested party. This will be particularly valuable during the annual management review as well as in internal and external audits. Also in an ISAE report an excerpt can be added.
3. Summary of Risk Methodology
This methodology fulfills all requirements by ISO/IEC 27001. This documented process focuses on the process and could be documented in any tool. It should serve as the main resource for the CISO to plan and work out the risk assessment and run the risk management.
4. Reference Documents
-
ISO/IEC 27001:2022 Standard sections:
-
6.1 — Actions to address risks and opportunities (especially 6.1.2 and 6.1.3)
-
8.2 — Information security risk assessment
-
8.3 — Information security risk treatment
-