# How to Perform an ISO/IEC 27001 Risk Analysis: Risk Assessment, Risk Treatment and SoA Preparation Guide

**URL:** https://securesys.com.tr/en/learning/cyber-security-compliance-advisory/how-to-perform-iso-27001-risk-analysis-examples-soa-guide

![How to Perform an ISO/IEC 27001 Risk Analysis: Risk Assessment, Risk Treatment and SoA Preparation Guide](/images/bilgi-merkezi/covers/cover-uyum-04.webp)

### What Is ISO/IEC 27001 Risk Analysis?

**ISO/IEC 27001 risk analysis is the systematic exercise an organisation carries out to identify the risks that could affect information security, assess their likelihood and consequences, prioritise them and select appropriate security measures.**

Risk analysis is one of the core decision-making mechanisms of the Information Security Management System (ISMS).

Which security technologies an organisation invests in, which systems it protects first, which vulnerabilities it remediates urgently and which risks it can accept are all influenced by this process.

ISO/IEC 27001:2022 addresses the requirements for information security risk assessment specifically in clause 6.1.2, and the requirements for risk treatment in clause 6.1.3.

The standard does not impose a single risk scoring formula on every organisation.

It expects the organisation to establish a methodology that suits its own activities and can produce consistent, comparable results.

**Short answer:** ISO 27001 risk analysis is the process of identifying the risks that affect information assets and business processes, determining risk levels, selecting appropriate controls and having the residual risks evaluated by the authorised persons.

### \1. Why Is ISO 27001 Risk Analysis Performed?

In corporate information systems it is not possible to eliminate every threat completely.

Security budgets, human resources and operational capacity are limited.

Organisations therefore need to determine which risks take priority.

For example, an actively exploited vulnerability in an internet-facing VPN system may be more urgent than a low-impact configuration weakness in an isolated test environment.

Similarly, failing to back up critical customer data may have a greater business impact than an unused account in a low-importance application.

Risk analysis makes it possible to assess these differences systematically.

#### Core objectives of risk analysis

- Identifying critical information assets and business processes.
- Assessing potential threats and security weaknesses.
- Prioritising security investments.
- Determining risk owners and responsibilities.
- Selecting appropriate security controls.
- Recording risk acceptance decisions.
- Supporting management's information security decisions.
- Contributing to the continual improvement of the ISMS.

Risk analysis should not be viewed merely as a document prepared ahead of a certification audit.

It should be used regularly in corporate decision-making processes.

### \2. The Difference Between ISO/IEC 27001 Risk Management and Risk Analysis

Risk analysis and risk management are related but distinct concepts.

**Risk management** is the overall process that covers identifying, assessing, treating, monitoring and communicating risks.

**Risk analysis** is the assessment stage that focuses on understanding the nature and level of risks.

**Risk assessment** covers identifying risks, analysing them and evaluating them by comparing them against defined criteria.

**Risk treatment** is the selection and implementation of appropriate options for the identified risks.

#### Example

Let us assume an organisation's remote access system has no MFA.

At the risk identification stage, an unauthorised access scenario is defined.

At the risk analysis stage, the likelihood and the potential business impact are assessed.

At the risk evaluation stage, a decision is made on whether the risk is at an acceptable level.

At the risk treatment stage, the implementation of MFA can be planned.

After implementation, the residual risk is reassessed.

In this way, risk management turns from a one-off spreadsheet exercise into a continuously operating process.

### \3. ISO/IEC 27001:2022 Risk Management Requirements

Under ISO/IEC 27001:2022, risk management is linked to several different clauses.

| Standard clause | Subject | Purpose in practice |
| --- | --- | --- |
| 4.1 | Context of the organisation | Assessing internal and external issues |
| 4.2 | Interested parties | Determining requirements |
| 6.1.2 | Risk assessment | Identifying and assessing information security risks |
| 6.1.3 | Risk treatment | Determining risk treatment options and controls |
| 8.2 | Operational risk assessment | Assessment at planned intervals and upon significant changes |
| 8.3 | Operational risk treatment | Implementing the risk treatment plan |
| 9.1 | Monitoring and measurement | Evaluating performance |
| 9.3 | Management review | Management's review of risks |
| 10 | Improvement | Correcting nonconformities and continual improvement |

An important detail is that ISO/IEC 27001 does not limit risk assessment to an asset inventory alone.

The organisation needs to identify and assess its information security risks in an appropriate manner.

### \4. How Is an ISO 27001 Risk Analysis Methodology Established?

The assessment method must be defined before the risk analysis begins.

Otherwise, different teams may score the same risk against different criteria.

This makes it harder to compare results.

#### Areas that must be defined in the methodology

The scope of the risk assessment.

The risk identification approach.

The designation of risk owners.

Likelihood criteria.

Impact criteria.

The risk calculation method.

Risk acceptance criteria.

The frequency of risk assessment.

The conditions that trigger reassessment upon significant changes.

The risk reporting method.

#### Example methodology

An organisation may use likelihood and impact scales from 1 to 5.

The risk level may be calculated by multiplying the two values.

However, this formula is not mandated by ISO/IEC 27001.

What matters is that the method the organisation selects is justified and applied consistently.

### \5. What Is Asset-Based Risk Analysis?

Asset-based risk analysis is the assessment of risks starting from information assets.

First, the assets are identified.

Then the threats, weaknesses and potential consequences relating to those assets are examined.

#### Example assets

Database servers.

Web applications.

Active Directory.

Firewall devices.

VPN infrastructure.

Backup systems.

Source code repositories.

Cloud storage areas.

Customer information.

Financial records.

#### Example

**Asset:** Customer database.

**Threat:** Unauthorised data access.

**Weakness:** Overly broad access permissions.

**Potential consequence:** Disclosure of sensitive data.

**Recommended control:** Role-based access, privileged account management and monitoring.

This method is useful for the detailed assessment of technical assets.

However, focusing on the asset list alone can cause cross-process or organisational risks to be overlooked.

### \6. What Is Scenario-Based Risk Analysis?

In the scenario-based approach, risks are assessed through specific events and their potential consequences.

This approach can make the relationship between business processes and technical security risks more visible.

#### Example risk scenario

“An attacker accessing the corporate network with compromised VPN credentials and performing unauthorised actions on critical servers.”

The elements to be assessed in this scenario are:

The VPN authentication method.

MFA coverage.

User permissions.

Network segmentation.

Security monitoring.

Access to critical systems.

Potential business interruption.

#### Advantage

The entire attack chain can be assessed instead of a single asset.

#### Key point

Asset-based and scenario-based methods do not have to be alternatives to each other.

Organisations can use both approaches together.

### \7. The Core Components of Information Security Risk

Several elements can be taken into account when assessing a risk.

#### Threat

A potential event or actor that could harm an information asset or business process.

Examples:

Cyber attacker.

Insider threat.

Hardware failure.

Human error.

Natural disaster.

#### Vulnerability

A security weakness that can increase the effect of a threat.

Examples:

Lack of MFA.

Outdated software.

Incorrect firewall rule.

Weak access policy.

#### Likelihood

An assessment of the probability that a particular risk scenario will materialise.

#### Impact

The significance of the consequences that could arise if the risk materialises.

#### Existing controls

Measures already in place that reduce the likelihood or impact of the risk.

#### Risk owner

The person or role with the authority and responsibility for managing the risk.

The risk owner is not always the person who implements the technical control.

For example, while the owner of the risk for a financial system may be the relevant business unit manager, the IAM team may be responsible for implementing MFA.

### \8. How Is Risk Likelihood Scored?

An example five-level likelihood scale can be created.

| Score | Level | Example description |
| --- | --- | --- |
| 1 | Very low | Occurrence is considered highly unlikely |
| 2 | Low | May occur under limited conditions |
| 3 | Medium | There is a reasonable likelihood of occurrence |
| 4 | High | Threat conditions are strong and the likelihood of occurrence is high |
| 5 | Very high | The likelihood of occurrence is very high or indicators of the event are present |

These descriptions should be made more measurable according to the organisational context.

#### Factors that influence likelihood

Internet exposure.

Known exploitation methods.

Threat intelligence.

Exploitability of the vulnerability.

The attacker's access requirements.

Existing protective controls.

Past security incidents.

#### Example

The likelihood of risk for a critical system that is exposed to the internet and has a known, actively exploited vulnerability can be assessed as high.

However, the assessment should be made by taking into account existing protections and actual accessibility.

### \9. How Is Risk Impact Scored?

Risk impact should not be assessed through financial loss alone.

The consequences for the confidentiality, integrity and availability of information should be considered together.

#### Example impact matrix

| Score | Impact level | Example consequence |
| --- | --- | --- |
| 1 | Very low | Limited operational impact |
| 2 | Low | Minor service disruption |
| 3 | Medium | Significant disruption in certain processes |
| 4 | High | Serious impact on critical business processes |
| 5 | Very high | Very severe consequences for corporate operations |

#### Impact categories

Financial loss.

Operational interruption.

Personal data breach.

Legal and contractual consequences.

Reputational damage.

Customer impact.

Loss of information integrity.

#### Example

A short period of unavailability of a test server may cause low impact.

However, the same outage on a critical payment infrastructure may cause high or very high impact.

The impact assessment should be made according to the actual business importance of the asset.

### \10. The 5×5 Risk Matrix for ISO 27001

The 5×5 risk matrix is one of the example methods for prioritising risks visually.

In the model below, the risk score is calculated by multiplying the likelihood and impact values.

| Likelihood / Impact | 1 | 2 | 3 | 4 | 5 |
| --- | --- | --- | --- | --- | --- |
| 5 | 5 | 10 | 15 | 20 | 25 |
| 4 | 4 | 8 | 12 | 16 | 20 |
| 3 | 3 | 6 | 9 | 12 | 15 |
| 2 | 2 | 4 | 6 | 8 | 10 |
| 1 | 1 | 2 | 3 | 4 | 5 |

#### Example risk classification

| Score | Risk level | Example approach |
| --- | --- | --- |
| 1–4 | Low | Monitoring and routine assessment |
| 5–9 | Medium | Planned improvement |
| 10–16 | High | Priority risk treatment |
| 17–25 | Critical | Urgent management review |

These thresholds are given as examples.

They should be adjusted according to the organisation's risk appetite, business impact and assessment methodology.

**Important:** The 5×5 matrix is not an exact probability calculation. Numerical scores should be used as categorical indicators that support expert judgement.

### \11. How Is the Risk Score Calculated?

Let us assume that in an example organisation there is no backup process for a critical database server.

#### Risk scenario

Loss of critical data due to hardware failure or ransomware.

#### Assessment

Likelihood: 4.

Impact: 5.

**Risk score = 4 × 5 = 20**

According to the example risk matrix, the result is at the critical level.

#### Risk treatment recommendation

Establishing a backup policy.

Backing up critical data regularly.

Restricting access to backups.

Evaluating offline or immutable backup options.

Performing restoration tests.

The risk should be reassessed once these activities are completed.

### \12. What Are Inherent Risk, Current Risk and Residual Risk?

Different risk states can be used in risk assessment.

#### Inherent risk

The risk level of the identified risk scenario before the relevant controls are taken into account, under the protection assumptions defined in the assessment methodology.

#### Current risk

The risk level that results when the controls currently in place are taken into account.

#### Residual risk

The risk level that remains after the planned risk treatment activities have been implemented.

#### Example

**Risk:** Compromise of a VPN account.

**Inherent risk:** 20.

**Current risk:** 16.

**Planned controls:** Phishing-resistant MFA, access restriction and monitoring.

**Targeted residual risk:** 6.

The values here are examples.

It cannot be assumed that the residual risk will fall to a level of 6 merely because a control has been purchased.

Once controls are implemented, their effectiveness must be verified and the risk reassessed.

### \13. How Are Risk Acceptance Criteria Determined?

Since organisations cannot reduce all risks to zero, they must define acceptable risk levels.

#### Risk acceptance criteria

Risk level.

Business impact.

Legal obligations.

Contractual requirements.

Existing security controls.

The cost of risk treatment.

Corporate risk appetite.

#### Example policy

Low risks can be accepted with defined authorities.

Medium risks require an assessment by the risk owner.

High risks may require senior management approval or a risk treatment plan.

For critical risks, urgent action and senior management review may apply.

This model is only an example.

The organisation's actual authority matrix and risk acceptance criteria must be clearly defined.

#### Critical point

The violation of a legal requirement cannot be made legitimate merely by signing a risk acceptance form.

Risk acceptance decisions must be consistent with applicable obligations.

### \14. Who Is the Risk Owner?

The risk owner is the person or role with the authority and responsibility for managing a specific risk.

ISO/IEC 27001 requires risk owners to be identified.

#### Example

**Risk:** Unauthorised access to the customer database.

**Risk owner:** The manager responsible for the relevant business process or service.

**Control implementer:** The database and IAM teams.

**Monitoring:** Information Security / SOC.

**Risk acceptance:** The authorised person defined in the corporate authority matrix.

Identifying the risk owner helps prevent findings from sitting solely with IT teams.

### \15. How Is an ISO 27001 Risk Register Prepared?

The risk register is the working space in which the identified risks are recorded centrally.

Excel, GRC software or an enterprise risk management platform can be used.

#### Recommended risk register fields

Risk ID.

Business process.

Asset.

Risk scenario.

Threat.

Vulnerability or risk source.

Potential consequence.

Risk owner.

Existing controls.

Likelihood.

Impact.

Risk level.

Risk treatment decision.

Planned action.

Action owner.

Target date.

Residual risk.

Risk acceptance status.

Date of last assessment.

#### Example risk records

| Risk ID | Risk scenario | Likelihood | Impact | Score |
| --- | --- | --- | --- | --- |
| R-001 | Compromise of a VPN account | 4 | 5 | 20 |
| R-002 | Missing patches on a critical server | 4 | 4 | 16 |
| R-003 | Inability to restore backups | 3 | 5 | 15 |
| R-004 | Unauthorised cloud file sharing | 3 | 4 | 12 |
| R-005 | Secret keys found in source code | 4 | 4 | 16 |
| R-006 | Misuse of a supplier account | 3 | 4 | 12 |

These records are example scenarios.

Actual scores should be determined by taking into account the organisation's systems, threat conditions and existing controls.

### \16. How Is a Risk Treatment Plan Prepared?

The risk treatment plan explains which activities will be used to manage the identified risks.

The plan needs to be actionable and trackable.

#### Core fields

Risk ID.

Risk level.

Risk treatment option.

Planned control.

Responsible person.

Resource requirement.

Target date.

Success criterion.

Verification method.

Residual risk assessment.

#### Example

| Field | Description |
| --- | --- |
| Risk ID | R-001 |
| Risk | Compromise of a VPN account |
| Current risk | Critical |
| Treatment method | Mitigation |
| Control | MFA and access restriction |
| Responsible | IAM / Network Security |
| Target | MFA on all critical accounts |
| Evidence | MFA coverage report and access tests |
| Residual risk | To be assessed after implementation |

In a risk treatment plan, merely stating “MFA will be implemented” may not be sufficient.

On which accounts, when and how it will be verified must be specified.

### \17. What Are the Risk Treatment Options?

Different treatment options can be used for risks.

#### Risk mitigation

Reducing the risk through security controls.

Example: Closing an internet-facing administration interface.

#### Risk avoidance

Ending or changing the activity that creates the risk.

Example: Decommissioning a legacy service that cannot be secured.

#### Risk sharing

Sharing certain risk consequences through contractual, operational or financial mechanisms.

Example: Cyber insurance.

#### Risk acceptance

Accepting the risk with the appropriate authority and in line with the defined criteria.

Example: Accepting a low-impact risk that is monitored appropriately.

The reasons for risk treatment decisions should be recorded.

### \18. What Is the ISO 27001 SoA?

**The Statement of Applicability (SoA) is the ISMS document that shows the controls necessary to treat information security risks, the justification for selecting them, their implementation status, and the justification for excluding any Annex A controls.**

It is an important requirement under clause 6.1.3 of ISO/IEC 27001:2022.

The SoA should be linked to the risk assessment and the risk treatment plan.

#### Questions the SoA should answer

Which controls are necessary?

Why were these controls selected?

Are the controls implemented?

Which Annex A controls have been excluded?

What are the justifications for the exclusions?

#### Important distinction

The SoA should not be viewed merely as a table in which the 93 Annex A controls are ticked.

There may also be controls deemed necessary to treat the risks that fall outside Annex A.

### \19. How Is the SoA Prepared?

The SoA preparation process should be carried out together with the risk assessment and risk treatment decisions.

#### Step 1: Identify the risks

Information security risks are recorded.

#### Step 2: Establish the risk treatment decisions

How the risks will be addressed is determined.

#### Step 3: Select the necessary controls

The appropriate controls for risk treatment are determined.

#### Step 4: Compare against Annex A

A comparison against the Annex A reference controls is made to ensure that no necessary controls have been omitted.

#### Step 5: Establish the justifications for applicability

Why the controls are necessary is explained.

#### Step 6: Determine the implementation status

Whether or not the control has been implemented is recorded.

#### Step 7: Explain the justifications for exclusions

Justifications are given for the controls excluded from Annex A.

#### Step 8: Keep it up to date

The SoA is reviewed when there is a significant change in the risks, the scope or the controls.

### \20. Example ISO 27001 SoA Table

The table below has been prepared to illustrate the implementation approach.

| Control | Control subject | Justification | Status |
| --- | --- | --- | --- |
| A.5.9 | Inventory of information and other associated assets | Asset visibility | Implemented |
| A.5.15 | Access control | Reducing unauthorised access | Implemented |
| A.5.23 | Information security for use of cloud services | Managing cloud risks | Partial |
| A.8.8 | Management of technical vulnerabilities | Reducing known weaknesses | Implemented |
| A.8.12 | Data leakage prevention | Protection of sensitive data | Planned |
| A.8.13 | Information backup | Data recovery | Implemented |
| A.8.15 | Logging | Event traceability | Implemented |
| A.8.28 | Secure coding | Software security | Partial |

The terms “partial” and “planned” here are example internal tracking statuses.

The SoA must clearly satisfy the implementation status information required by the standard.

#### Key point

The fact that a control is necessary but not yet implemented does not automatically mean it can be excluded.

In this case, the implementation gap and the risk treatment plan must be managed appropriately.

### \21. How Are Controls Excluded in the SoA?

It may be assessed that some Annex A controls are not applicable to the scope of a particular organisation.

However, exclusion decisions must be justified.

#### Example scenario

Let us assume that an organisation has no particular physical operating area.

In this case, the applicability of the relevant physical control can be assessed.

However, if the organisation has remote-working personnel, devices, cloud infrastructure or supplier dependencies, it cannot be assumed that physical security risks have disappeared entirely.

#### Incorrect approach

“We use the cloud, so none of the physical security controls apply.”

#### More correct approach

“The applicability of the relevant physical security controls has been assessed individually, taking into account the ISMS scope, assets, working model and supplier responsibilities.”

The justifications for exclusion must be consistent with the risk assessment.

### \22. The Relationship Between the Risk Register and the SoA

The risk register and the SoA are not two independent documents.

The risk register shows which risks exist.

The risk treatment plan determines what will be done about these risks.

The SoA, in turn, shows the justifications for selecting the necessary controls and their implementation status.

#### Example relationship

**Risk:** R-003 – Inability to restore critical data.

**Risk treatment decision:** Mitigation.

**Planned activity:** Backup and restoration tests.

**Related Annex A control:** A.8.13 – Information backup.

**SoA justification:** Reducing the risk of loss and unavailability of critical business data.

**Evidence:** Backup policy and restoration test results.

Thanks to this relationship, it is possible to explain during an audit why a control was selected.

### \23. How Is Technical Vulnerability Data Used in Risk Analysis?

Vulnerability scan results can provide important input to the risk assessment.

However, not every finding in a scan report has to create a separate corporate risk record.

Similar findings can be assessed under appropriate risk scenarios.

#### Data that can be used

CVSS score.

Exploitability of the vulnerability.

Verified exploitation information such as CISA KEV.

Probabilistic prioritisation indicators such as EPSS.

Internet exposure of the asset.

Asset criticality level.

Existing security controls.

#### Example

A vulnerability with a high CVSS score may be found on a system that is closed to external access and protected by strong segmentation.

Another system may have a vulnerability with a lower CVSS score that is exposed to the internet and actively exploited.

Corporate prioritisation should not be based on the CVSS value alone.

Actual threat exposure and business impact should be assessed together.

### \24. How Are Penetration Test Findings Transferred into Risk Analysis?

Penetration tests help assess technical security weaknesses through real attack scenarios.

The test results can be fed into the ISMS risk management process.

#### Example

A penetration test identified a missing authorisation check in a web application.

**Technical finding:** Broken Access Control.

**Risk scenario:** An unauthorised user accessing records that belong to other customers.

**Business impact:** Disclosure of sensitive data and contractual consequences.

**Risk owner:** The application or business process owner.

**Control:** Fixing the authorisation mechanism.

**Verification:** Penetration retest.

#### Critical point

Closing a technical finding and the risk dropping to an acceptable level may not be the same thing.

The relevant risk scenario should be reassessed.

### \25. Cloud Security in ISO 27001 Risk Analysis

Cloud infrastructures can create different risk scenarios.

#### Example risks

Publicly accessible storage areas.

Overly broad IAM permissions.

Unauthorised OAuth applications.

Compromise of cloud administrator accounts.

Incorrect network security configurations.

Insufficient logging.

Uncontrolled data sharing.

#### Example scenario

A cloud storage area being made publicly accessible by mistake.

**Threat:** Unauthorised data access.

**Weakness:** Incorrect access configuration.

**Impact:** Disclosure of sensitive data.

**Control:** Secure default configurations, continuous configuration monitoring and access control.

#### Responsibility model

In cloud security, the responsibilities of the service provider and the customer may vary depending on the service model.

The risk assessment should take this distinction into account.

### \26. Supplier Security in ISO 27001 Risk Analysis

Suppliers can have a direct impact on corporate information security.

Suppliers that access critical systems or process sensitive data, in particular, should be assessed.

#### Example risks

Compromise of a supplier account.

Uncontrolled remote access.

Supplier-originated data breach.

Service interruption.

Insufficient security obligations.

#### Assessment criteria

The types of data the supplier processes.

Access permissions.

The criticality level of the service.

Security controls.

Contractual obligations.

Incident notification processes.

Business continuity capability.

#### Example control

Limiting supplier access to defined periods and protecting it with MFA.

Supplier security is not a process that is complete once a contract has been signed.

### \27. Human-Related Risks in ISO 27001 Risk Analysis

Human-related risks should be assessed together with technical controls.

#### Example risks

Phishing.

Social engineering.

Sending data to the wrong recipient.

Misuse of privileges.

Incorrect system configuration.

Access remaining open for personnel who have left the organisation.

#### Example scenario

An employee entering corporate credentials on a fake login page.

**Potential consequence:** Account compromise.

**Controls:** Phishing-resistant MFA, email security, awareness training and anomalous session monitoring.

#### Important approach

It is not sufficient to classify risks merely as user error.

How system design and security controls limit human error should also be assessed.

### \28. How Are Artificial Intelligence Systems Included in ISO 27001 Risk Analysis?

The use of artificial intelligence systems by organisations can create new information security risks.

#### Example risks

Transfer of sensitive data to unauthorised AI services.

Prompt Injection.

Uncontrolled AI Agent actions.

Leakage of model access keys.

Manipulation of RAG data sources.

Data security issues originating from the AI supplier.

#### Example risk scenario

Employees uploading confidential customer documents to unapproved artificial intelligence services.

**Risk source:** Uncontrolled Shadow AI use.

**Potential consequence:** Transfer of sensitive information to unauthorised third-party systems.

**Control:** Approved AI services, data classification, DLP and AI Gateway policies.

#### Relationship with ISO/IEC 42001

ISO/IEC 42001 can be assessed separately for AI governance and for managing the effects specific to artificial intelligence.

While ISO/IEC 27001 supports the management of information security risks, ISO/IEC 42001 addresses broader AI management requirements.

### \29. How Often Should the Risk Analysis Be Updated?

ISO/IEC 27001 requires risk assessments to be performed at planned intervals and when significant changes occur.

The same fixed assessment frequency is not mandated for all organisations.

#### Situations that may require reassessment

Commissioning a new application.

Migration to cloud infrastructure.

A critical security incident.

Integration of a new supplier.

A significant organisational change.

A new legal obligation.

A critical vulnerability.

Adoption of a new artificial intelligence system.

A change to the business continuity architecture.

#### Example approach

A comprehensive risk assessment can be planned annually.

More frequent assessments can be carried out for critical systems.

Significant changes, in turn, can trigger a risk assessment regardless of the planned period.

This approach should be adapted to the organisation's risk profile.

### \30. What Evidence Can Be Requested in a Risk Analysis Audit?

In an ISO/IEC 27001 audit, not only whether the risk management process is documented but also whether it is implemented is assessed.

#### Example evidence

The risk assessment methodology.

Risk acceptance criteria.

The risk register.

Risk assessment results.

The risk treatment plan.

The SoA.

Risk owner records.

Risk treatment approvals.

Residual risk assessments.

Evidence of control implementation.

Management decisions.

Update records.

#### Example audit questions

How was this risk identified?

Who is the risk owner?

Why was a likelihood of 4 selected?

Which existing controls were taken into account?

Why is this control necessary?

How was it verified that the risk treatment activity was completed?

Who accepted the residual risk?

The risk management process needs to be able to answer these questions consistently.

### \31. The 10 Most Common Mistakes in ISO 27001 Risk Analysis

#### \1. Using another organisation's risk register verbatim

Every organisation has different assets, processes and threat exposure.

#### \2. Giving all risks the same score

Risks should be assessed according to actual conditions.

#### \3. Failing to designate a risk owner

Risks without an accountable owner are harder to manage.

#### \4. Focusing only on technical risks

People, process, physical security and supplier risks are also important.

#### \5. Preparing the risk analysis once a year and never updating it

An assessment should be performed upon significant changes.

#### \6. Failing to create a risk treatment plan

Risk scoring on its own is not risk management.

#### \7. Lowering residual risk automatically

The effectiveness of controls must be verified.

#### \8. Preparing the SoA independently of risk treatment decisions

Control selections must be justified.

#### \9. Having risk acceptance carried out by unauthorised persons

Authorities and responsibilities must be clear.

#### \10. Failing to include the risk analysis in management decisions

Risk assessment should support resource allocation and security priorities.

### \32. The Relationship Between ISO 27001 Risk Analysis and ISO/IEC 27005

ISO/IEC 27005 provides guidance on information security risk management.

While ISO/IEC 27001 sets out the risk management requirements, ISO/IEC 27005 can be used to develop the implementation approach.

#### Areas to which ISO/IEC 27005 can contribute

The risk management context.

Risk identification.

Risk analysis.

Risk evaluation.

Risk treatment.

Risk communication.

Risk monitoring and review.

#### Important distinction

For ISO/IEC 27001 certification, it is not mandatory to apply one particular method of ISO/IEC 27005 verbatim.

The organisation may select an appropriate risk assessment methodology.

### \33. The Relationship Between ISO 27001 Risk Analysis and NIST CSF 2.0

The NIST Cybersecurity Framework 2.0 contains six functions that support the management of cybersecurity risks.

GOVERN.

IDENTIFY.

PROTECT.

DETECT.

RESPOND.

RECOVER.

#### Example mapping

Risk governance is related to GOVERN.

Asset and risk identification can be considered under IDENTIFY.

Risk-reducing controls are related to PROTECT.

Security monitoring supports the DETECT function.

Incident response is addressed under RESPOND.

Recovery plans are related to RECOVER.

ISO/IEC 27001 and NIST CSF 2.0 can be used together.

However, one is not the automatic equivalent of the other.

### \34. The Relationship Between Risk Analysis and Business Continuity

A significant proportion of information security risks can affect the availability of services.

Risk analysis should therefore be linked to business continuity processes.

#### Example scenarios

A data centre outage.

A ransomware attack.

A critical cloud service becoming unavailable.

Failure of the backup system.

A service interruption originating from a supplier.

#### Business Impact Analysis (BIA)

Business Impact Analysis helps assess the consequences that could arise if critical processes are interrupted.

BIA results can provide important input to the risk assessment.

#### Example

A four-hour outage of a critical payment service may create a high business impact, depending on the organisation's operations.

However, this duration and impact are not the same for every organisation.

Business continuity objectives must be determined according to corporate needs.

### \35. How Should Risk Analysis Results Be Presented to the Board?

Senior management reports should not consist merely of technical risk scores.

The business impact of risks and the decisions that need to be taken should be shown clearly.

#### Recommended management report

The total number of risks assessed.

The number of critical risks.

The number of high risks.

The status of risk treatment activities.

Actions that have exceeded their target dates.

Residual risks.

Risk acceptance decisions.

Resource requirements.

Priority investment areas.

#### Example management summary

“Because MFA coverage in the corporate remote access infrastructure is insufficient, the risk of unauthorised access has been assessed as high. It is recommended that MFA be completed on critical accounts and that access logs be monitored centrally.”

This statement provides more decision support than the information “Risk score 20” alone.

### \36. ISO 27001 Risk Management KPIs

The effectiveness of the risk management process can be tracked with measurable indicators.

#### Risk assessment coverage

The ratio of assessed critical business processes to total critical processes.

#### Risk treatment completion rate

The ratio of completed risk treatment activities to planned activities.

#### Risks past their target date

The number of open risk treatment activities whose defined target date has passed.

#### Risk acceptance review rate

The proportion of risk acceptance decisions reassessed in the planned period.

#### Critical risk reduction rate

The proportion of risks that were initially at the critical level and have been reduced to a lower level through verified controls.

#### Key point

A decrease in the number of risks does not always mean that security has improved.

Removing risks from the register or reduced visibility can produce a similar result.

Metrics should therefore be interpreted together with their context.

### \37. Automation in ISO 27001 Risk Management

Large organisations may have hundreds or thousands of risk records.

Manual tracking processes can become inadequate over time.

#### Areas for automation

Asset inventory integration.

Correlation of vulnerability data.

Risk owner assignment.

Action tracking.

Target date alerts.

Collection of control evidence.

Management reporting.

Risk change history.

#### Example

When a critical vulnerability is detected in a vulnerability management platform, the owner of the relevant asset can be identified.

A risk record linked to the finding can be created, or an existing record can be updated.

The action can be assigned to the relevant team.

The verification result after remediation can be added to the record.

#### Points to watch

Automated risk scores should not replace expert judgement.

Data quality, false positives and business context should be taken into account.

### \38. Example Implementation: Risk Analysis in an Organisation with 100 Employees

Let us consider an organisation with 100 employees that uses a hybrid working model.

#### Infrastructure

Active Directory.

Microsoft 365.

VPN.

Firewall.

File servers.

ERP.

Customer database.

Backup infrastructure.

Cloud applications.

#### Initial assessment

Critical systems are identified.

User and administrator accounts are reviewed.

Internet-facing services are assessed.

Backup and restoration processes are reviewed.

Cloud access is checked.

#### Example risks

| Risk | Initial assessment | Recommended control |
| --- | --- | --- |
| No MFA on the administrator account | Critical | MFA and access restriction |
| No backup restoration test | High | Regular recovery testing |
| Unsupported operating system | High | Update or isolation |
| Uncontrolled SaaS sharing | High | Access and data sharing policy |
| Supplier VPN account | Medium/High | Time-limited access and monitoring |

The risk levels are for illustration purposes.

The actual assessment should be made on the basis of existing controls and business impact.

#### Outputs

Risk register.

Risk treatment plan.

SoA.

Prioritised improvement list.

Management report.

These outputs help make the ISMS operational.

### \39. A 30-Day Work Plan for ISO 27001 Risk Analysis

#### Days 1–5: Preparation

Reviewing the ISMS scope.

Establishing the risk methodology.

Defining the risk owners.

#### Days 6–10: Asset and Process Analysis

Identifying critical assets.

Assessing business processes.

Examining supplier dependencies.

#### Days 11–20: Risk Assessment

Creating risk scenarios.

Scoring likelihood and impact.

Assessing existing controls.

Prioritising risks.

#### Days 21–25: Risk Treatment

Control selections.

The risk treatment plan.

Responsibilities.

Target dates.

#### Days 26–30: SoA and Management Review

Preparing the SoA.

Validating with the risk owners.

Management review.

Recording the risk acceptance and treatment decisions.

This timeframe is an example plan.

In complex infrastructures the work may take longer.

### \40. Checklist Before an ISO 27001 Risk Analysis

- Has the ISMS scope been defined?
- Is the risk assessment methodology ready?
- Have the risk acceptance criteria been determined?
- Have the risk owners been defined?
- Have the critical business processes been identified?
- Is the asset inventory up to date?
- Have the threat scenarios been created?
- Have the existing controls been assessed?
- Have the likelihood criteria been defined?
- Have the impact criteria been defined?
- Is the risk scoring method consistent?
- Have the risk treatment options been assessed?
- Has the risk treatment plan been prepared?
- Have the control owners been identified?
- Have the target dates been defined?
- Has the SoA been linked to the risk treatment decisions?
- Has the residual risk assessment been planned?
- Have the risk acceptance authorities been defined?
- Have the conditions for updating risks been determined?
- Is the audit evidence being managed?

This checklist can be used to prepare for ISO/IEC 27001 risk management practices.

### \41. SECURESYS ISO 27001 Risk Analysis and ISMS Consulting

SECURESYS bases its corporate information security work on a risk-based assessment and technical validation approach.

In ISO/IEC 27001 risk analysis and ISMS consulting engagements, the organisation's existing infrastructure, business processes and security requirements can be addressed together.

#### Risk assessment methodology

Support is provided in establishing risk criteria and an assessment method suited to the organisation's activities.

#### Corporate risk register

Information security risks are identified, recorded and prioritised.

#### Risk treatment plan

Actionable technical and administrative control recommendations are developed for the identified risks.

#### SoA preparation

ISO/IEC 27001:2022 Annex A controls are linked to the risk treatment decisions.

#### Technical security assessment

Technical validation work can be carried out in the areas of system, network, application and cloud security.

#### Penetration testing and vulnerability management

Support is provided for incorporating technical security findings into corporate risk management.

#### SOC and security monitoring

We can contribute to the monitoring and assessment of security events and to the updating of the relevant risk scenarios.

#### Management reporting

Risk results are reported together with business impact and priority decision areas, alongside the technical details.

**In the SECURESYS approach, risk analysis is not merely a table prepared for an audit but a management tool that steers corporate security investments and improvement activities.**

#### Frequently Asked Questions (FAQ)

#### \1. What is ISO 27001 risk analysis?

It is the systematic process an organisation carries out to identify, analyse and evaluate its information security risks and to establish appropriate risk treatment decisions.

#### \2. Is ISO 27001 risk analysis mandatory?

Yes. Information security risk assessment is one of the core components of the ISO/IEC 27001 management system requirements.

#### \3. How is an ISO 27001 risk analysis performed?

Risk criteria are established, risks are identified, likelihood and impact are assessed, risks are prioritised and risk treatment decisions are made.

#### \4. How many levels should an ISO 27001 risk matrix have?

The standard does not mandate a single matrix size. The organisation must establish an appropriate and consistent assessment method.

#### \5. What is a 5×5 risk matrix?

It is an example risk assessment tool that uses five levels each for likelihood and impact.

#### \6. How is the risk score calculated?

One of the common example methods is multiplying the likelihood and impact values. However, ISO/IEC 27001 does not mandate this formula.

#### \7. What is inherent risk?

It is the risk level before specific protective controls are taken into account, under the assumptions defined in the assessment methodology.

#### \8. What is residual risk?

It is the risk level that remains after the risk treatment activities.

#### \9. Who is the risk owner?

The person or role with the authority and responsibility for managing a specific risk.

#### \10. Who accepts the risk?

It must be done by a person with the appropriate authority, or by management, within the authority matrix defined by the organisation.

#### \11. What is the SoA?

The Statement of Applicability shows the necessary security controls, the justifications for selecting them, their implementation status and the justifications for Annex A exclusions.

#### \12. Must all 93 controls be included in the SoA?

The applicability of the Annex A reference controls and the justifications for exclusions must be assessed. In addition, other controls deemed necessary for risk treatment must also be taken into account.

#### \13. Should ISO 27001 risk analysis be performed once a year?

The standard does not mandate a single annual frequency for all organisations. Assessment should be performed at planned intervals and upon significant changes.

#### \14. Does a penetration test replace risk analysis?

No. A penetration test assesses technical security weaknesses. Corporate risk analysis, on the other hand, covers broader information security risks.

#### \15. Is a CVSS score the ISO 27001 risk score?

No. CVSS is an indicator of technical vulnerability severity. In corporate risk assessment, business impact and other factors are also taken into account separately.

#### \16. Can ISO 27001 risk analysis be done in Excel?

Yes. Excel can be a suitable recording and assessment tool. However, consistent application of the methodology, keeping records up to date and authorisation are important.

#### \17. Are ISO 27001 risk analysis and ISO 27005 the same thing?

No. ISO/IEC 27001 defines the management system requirements. ISO/IEC 27005 provides guidance on information security risk management.

#### \18. Why should risk analysis be updated continually?

New systems, threats, security incidents and organisational changes can affect risk levels.

#### \19. What should a risk treatment plan contain?

It should contain information such as the risk, the selected treatment method, planned controls, responsible persons, target dates and the verification approach.

#### \20. What does ISO 27001 risk analysis consulting provide?

It provides support in establishing the risk methodology, assessing risks, preparing risk treatment plans and developing the SoA.

### Conclusion: ISO 27001 Risk Analysis Is the Foundation of Corporate Security Decisions

ISO/IEC 27001 risk analysis should not be regarded merely as a table to be presented in information security audits.

When implemented correctly, it becomes an important management mechanism that determines the organisation's security priorities.

Critical information assets and business processes must be identified.

Risk scenarios must be created according to real organisational conditions.

Likelihood and impact criteria must be applied consistently.

Existing security controls must be assessed.

Risk treatment decisions must be clearly defined.

The SoA must be linked to the risk treatment process.

Residual risks must be verified and assessed by the appropriate authority.

Risk management results must be presented to senior management in an understandable way.

Most importantly, risk assessments must be kept up to date.

**A successful ISO/IEC 27001 risk analysis does not merely show which risks exist; it also shows what the organisation needs to do for each risk, who is responsible and how the improvement will be verified.**