ISO 27001 Risk Assessment: A Practical Guide

An ISO 27001 risk assessment is the process an organization uses to identify, analyze, and evaluate information security risks within its Information Security Management System (ISMS).

It is one of the most important parts of ISO 27001 because risk assessment helps determine what the organization actually needs to protect and which controls are necessary.

This is where ISO 27001 differs from a simple compliance checklist.

The process is not:

Start with 93 Annex A controls → implement them all → declare the organization secure

A better model is:

Understand the organization → identify information security risks → analyze and evaluate those risks → decide how to treat them → determine necessary controls → compare those controls with Annex A

That means the quality of your risk assessment directly affects the quality of the control environment you build around it.

A weak risk assessment can produce vague risks, arbitrary ratings, unnecessary controls, and a risk register that nobody uses.

A useful risk assessment does something much more valuable.

It helps people make information security decisions.

What Is an ISO 27001 Risk Assessment?

An ISO 27001 risk assessment is a structured process for identifying information security risks, analyzing them, and evaluating whether they require treatment.

The organization establishes criteria for performing the assessment consistently and producing results that are valid and comparable.

The process should help answer questions such as:

• What could happen?
• What could cause it?
• What information or business activity could be affected?
• What would the consequences be?
• How likely is the scenario?
• How significant is the resulting risk?
• Is that level of risk acceptable?
• Who owns the risk?
• Does something need to be done about it?

The purpose isn’t to create a spreadsheet.

The spreadsheet, GRC platform, or risk register is simply where the results may be recorded.

The real output is a set of informed decisions about information security risk.

Where Risk Assessment Fits Into ISO 27001

Risk assessment does not operate independently from the rest of the ISMS.

It connects organizational context and requirements to risk treatment and controls.

A practical sequence looks like this:

Business context and requirements → scope → risk criteria → risk identification → risk analysis → risk evaluation → risk treatment → controls → Statement of Applicability → operation and monitoring

Each step informs the next.

If the organization doesn’t understand its context and scope, it becomes difficult to identify meaningful risks.

If risks are poorly described, treatment decisions become difficult.

If treatment decisions are weak, control selection becomes arbitrary.

This is why jumping directly into Annex A can create problems.

For more on the broader management system, see What Is an ISMS? How an Information Security Management System Actually Works.

What Is Information Security Risk?

Information security risk is not simply a list of bad things that might happen.

Entries such as these are common:

Cyberattack

Data breach

Ransomware

Insider threat

Phishing

Those may describe threats or events, but they usually do not provide enough information for useful risk decisions.

A better risk statement describes a scenario.

One practical structure is:

Cause or condition → event → business impact

For example:

Compromised privileged credentials could allow unauthorized access to production systems, resulting in customer data exposure and service disruption.

Now the reader can understand:

• what could contribute to the event;
• what could happen;
• what could be affected;
• why the organization should care.

That provides a much stronger basis for analyzing risk.

Risk Assessment Should Support Decisions

One of the easiest ways to build a useless risk register is to focus more on formatting than decision-making.

A risk assessment should ultimately help the organization decide:

Is this risk acceptable?

If not:

What should we do about it?

Consider these two risk entries.

Weak Risk Entry

Risk: Cyberattack
Likelihood: High
Impact: High
Risk Rating: High

This tells decision-makers very little.

What type of attack?

Against what?

Why is it likely?

What could happen?

Which business process is affected?

Who owns the risk?

What action should be taken?

Better Risk Entry

Risk: Compromised administrator credentials could allow unauthorized access to the production environment, resulting in disclosure of customer information and disruption of customer services.

Risk Owner: Head of Technology

Likelihood: Possible

Impact: Major

Risk Rating: High

Treatment: Reduce

Treatment Actions: Strengthen privileged access restrictions, require multifactor authentication, improve administrative activity monitoring, and perform recurring privileged access reviews.

This risk can actually be managed.

Establish the Risk Assessment Methodology First

Before filling a risk register with risks, define how the organization will assess them.

The risk assessment methodology establishes consistency.

Without it, different people may interpret ratings differently.

One person might consider a “High” likelihood to mean an event could happen once every year.

Another might use “High” only when an event is expected every month.

Neither approach is automatically wrong.

The problem is inconsistency.

A useful methodology should establish how the organization approaches areas such as:

• risk identification;
• likelihood;
• impact;
• risk calculation;
• risk evaluation;
• risk acceptance;
• risk ownership;
• reassessment.

The methodology should be appropriate for the organization.

Complexity does not automatically improve risk analysis.

Step 1: Define Your Risk Criteria

Risk criteria establish how risks will be analyzed and evaluated.

Many organizations use likelihood and impact.

For example:

Likelihood

Rating	Example Meaning
1	Rare
2	Unlikely
3	Possible
4	Likely
5	Almost Certain

Impact

Rating	Example Meaning
1	Insignificant
2	Minor
3	Moderate
4	Major
5	Severe

An organization might calculate a risk score using:

Likelihood × Impact = Risk Score

That can produce a 1 to 25 scale.

The organization then defines what those scores mean.

For example:

Score	Example Classification
1 to 4	Low
5 to 9	Moderate
10 to 16	High
17 to 25	Critical

These numbers are only an example.

ISO 27001 does not require a particular 5×5 matrix, scoring scale, or mathematical formula.

The organization needs a methodology that supports consistent and meaningful decisions.

Step 2: Define Risk Acceptance Criteria

Risk acceptance criteria establish when the organization is willing to retain a risk.

This is where risk assessment becomes connected to governance.

For example, an organization might determine:

• Low risks may be accepted by the risk owner.
• Moderate risks require documented review.
• High risks require treatment unless formally accepted by designated leadership.
• Critical risks require immediate escalation and treatment.

Again, those rules are examples.

The organization should establish criteria appropriate to its own governance structure.

Without clear acceptance criteria, risk ratings can become decorative.

A risk gets labeled “High,” but nobody knows what “High” requires the organization to do.

Step 3: Identify Information Security Risks

Now identify scenarios that could affect the confidentiality, integrity, or availability of information.

Sources of risk might include:

• technology failures;
• human error;
• malicious activity;
• suppliers;
• physical events;
• process failures;
• inadequate access controls;
• software vulnerabilities;
• configuration errors;
• lost equipment;
• insider activity;
• service outages;
• weak development practices;
• environmental conditions.

The goal is not to brainstorm every imaginable disaster.

Focus on risks relevant to the organization’s actual environment and ISMS scope.

Step 4: Write Useful Risk Statements

Risk wording matters because it affects everything that follows.

Try to capture enough information to understand the scenario.

A useful structure is:

Because of [cause or condition], [event] could occur, resulting in [impact].

You don’t have to use that exact sentence structure for every risk.

The important thing is clarity.

For example:

Weak offboarding processes could allow former employees to retain access to business systems, resulting in unauthorized access to sensitive information.

Or:

A critical cloud service provider outage could make the customer platform unavailable, resulting in service disruption and contractual impact.

Or:

Unpatched internet-facing vulnerabilities could be exploited by an attacker, resulting in unauthorized system access and compromise of sensitive information.

Each statement gives the organization something concrete to evaluate.

Step 5: Identify the Risk Owner

Risks need owners.

The risk owner is responsible for ensuring that the risk is appropriately managed.

That does not necessarily mean the risk owner personally performs every control or remediation activity.

For example, the business owner of a customer platform might own the risk associated with prolonged service disruption while IT teams operate many of the controls used to reduce that risk.

Avoid automatically assigning every information security risk to the CISO, security manager, or GRC team.

Information security risks often belong to the business processes affected by them.

Step 6: Analyze Likelihood

Likelihood evaluates the possibility of the risk scenario occurring.

This can be difficult because organizations rarely have perfect data.

Consider information such as:

• previous incidents;
• threat activity;
• exposure;
• vulnerabilities;
• control environment;
• industry experience;
• system architecture;
• frequency of similar events;
• dependency characteristics.

Avoid false precision.

A score of 4 rather than 3 does not mean the organization has scientifically determined the probability of the event.

The rating should reflect the organization’s defined criteria and the information reasonably available.

Step 7: Analyze Impact

Impact considers the consequences if the scenario occurs.

Depending on the organization, impacts might include:

• financial loss;
• customer impact;
• operational disruption;
• regulatory consequences;
• contractual consequences;
• legal exposure;
• reputational damage;
• loss of confidentiality;
• loss of integrity;
• loss of availability.

Impact should connect to actual business consequences where possible.

Saying a security event has a “Major” impact is much more useful when the organization understands what qualifies as major.

Step 8: Determine the Risk Level

Apply the methodology to determine the risk level.

For a simple likelihood and impact model:

Likelihood × Impact = Risk Score

For example:

Likelihood: 4

Impact: 5

Risk Score: 20

If the organization’s methodology defines 17 to 25 as Critical, the resulting risk would be classified accordingly.

But remember what the number represents.

The purpose of the score is to support prioritization and decisions.

It should not create an illusion that information security risk has been measured with mathematical certainty.

Step 9: Evaluate the Risk

Risk evaluation compares the analyzed risk against the organization’s criteria.

This determines whether the risk is acceptable or requires additional action.

Questions might include:

Is the risk within our acceptance criteria?

Does treatment need to occur?

Does the risk require escalation?

Who has authority to accept it?

Are there contractual or regulatory requirements that affect the decision?

This is where risk assessment transitions into risk treatment.

Step 10: Decide How to Treat the Risk

Once the organization determines that action is necessary, it decides how the risk will be treated.

Common treatment approaches include:

Modify the Risk

Implement or change controls to reduce likelihood, impact, or both.

Avoid the Risk

Stop or change the activity creating the risk.

Share the Risk

Transfer or share aspects of the risk through mechanisms such as insurance, contractual arrangements, or third-party services.

Retain the Risk

Accept the risk when it falls within established criteria or is otherwise appropriately approved.

Treatment should reflect a deliberate decision.

“Accept” should not become shorthand for “we don’t want to fix this.”

Step 11: Determine Necessary Controls

When risk treatment requires controls, determine what controls are necessary.

Suppose the organization identifies this risk:

Compromised privileged credentials could result in unauthorized access to sensitive production systems.

Treatment might require controls involving:

• multifactor authentication;
• privileged access restrictions;
• account lifecycle management;
• access reviews;
• logging;
• monitoring;
• authentication practices.

Those controls arise from the risk treatment decision.

The organization then compares its necessary controls with Annex A.

This preserves the intended logic:

Risk → treatment → necessary controls → Annex A comparison

Our ISO 27001 Controls: A Practical Guide to Annex A explains this process in more detail.

Step 12: Create the Risk Treatment Plan

The risk treatment plan turns decisions into accountable actions.

Depending on the organization, it may capture:

Field	Purpose
Risk	Identifies the risk being treated
Treatment decision	Defines how the organization will respond
Action	Describes what needs to happen
Owner	Establishes accountability
Target date	Establishes expected timing
Status	Tracks progress
Control	Identifies relevant controls
Residual risk	Reflects expected or remaining risk
Approval	Records appropriate authorization

The treatment plan should be actionable.

If every treatment action simply says “Implement security controls,” it is not providing much management value.

Step 13: Evaluate Residual Risk

Controls rarely eliminate risk completely.

After treatment, some level of risk generally remains.

This is residual risk.

The organization should consider whether the remaining risk is acceptable according to its criteria.

For example:

Inherent risk: High

Treatment: MFA, privileged access restrictions, recurring reviews, monitoring

Residual risk: Moderate

The organization then determines whether that remaining risk can be accepted.

The exact terminology and scoring approach will depend on the organization’s methodology.

Step 14: Obtain Appropriate Risk Acceptance

Risk acceptance should occur according to established authority.

A security analyst should not necessarily be able to accept a major business risk simply because they maintain the risk register.

Acceptance authority should reflect the significance of the risk.

That might involve:

• risk owners;
• department leaders;
• executives;
• risk committees;
• other designated authorities.

The organization should be able to demonstrate who accepted important residual risks and why they had authority to do so.

Step 15: Keep the Risk Assessment Current

Risk assessment is not a one-time certification project.

The environment changes.

Organizations introduce:

• new systems;
• new suppliers;
• new products;
• new locations;
• new employees;
• new technologies;
• new threats;
• new vulnerabilities;
• new legal requirements;
• new customer requirements.

Controls also change.

Incidents occur.

Business priorities shift.

The ISMS needs a way to recognize those changes and determine whether risks need to be reassessed.

A risk register created during implementation and ignored until the next audit is not serving its purpose.

What Should an ISO 27001 Risk Register Include?

ISO 27001 does not prescribe one mandatory spreadsheet format.

The organization should capture enough information to support its methodology and risk decisions.

A practical risk register might include:

Field	Example
Risk ID	RISK-014
Risk scenario	Compromised privileged credentials could expose production systems
Asset or process	Production environment
Risk owner	Head of Technology
Likelihood	4, Likely
Impact	5, Severe
Risk score	20
Risk level	Critical
Treatment	Modify
Treatment actions	MFA, monitoring, access review
Control references	Relevant control IDs
Residual likelihood	2
Residual impact	5
Residual score	10
Residual level	High
Acceptance	Executive approval required
Review date	Next scheduled review

Additional fields may be useful depending on the organization.

Avoid adding fields simply because another company’s template contains them.

Every field should serve a purpose.

Asset-Based vs. Scenario-Based Risk Assessment

Organizations sometimes begin risk assessment by identifying information assets.

For example:

Asset → threat → vulnerability → impact

This can be a useful approach, particularly when asset inventories are mature.

But it is not the only way to think about information security risk.

A scenario-based approach can start with business processes, systems, services, or realistic events.

For example:

Critical supplier becomes unavailable → customer service cannot operate → prolonged outage and contractual impact

The important issue is not which spreadsheet structure is fashionable.

The organization needs an approach that identifies meaningful information security risks consistently and supports treatment decisions.

Inherent Risk vs. Residual Risk

Many organizations distinguish between inherent risk and residual risk.

Inherent risk generally represents the risk before considering particular controls or treatment.

Residual risk represents the risk remaining after treatment or controls are considered.

This distinction can be useful, but organizations need to define what those terms mean within their methodology.

Otherwise, different assessors may score them differently.

For example:

Does inherent risk assume absolutely no controls?

Does it assume baseline controls that exist everywhere?

Does residual risk reflect current controls or planned controls?

Clear definitions prevent confusion.

Risk Assessment vs. Risk Treatment

These terms are closely connected but different.

Risk assessment identifies, analyzes, and evaluates risk.

Risk treatment determines what the organization will do about the risk.

A simple flow is:

Identify → analyze → evaluate → treat → accept → monitor

Combining everything into one step can make accountability unclear.

Separating assessment from treatment helps show how the organization moved from understanding a risk to making a decision about it.

How Risk Assessment Connects to the Statement of Applicability

Risk assessment and treatment eventually connect to one of the most important ISO 27001 documents: the Statement of Applicability.

The sequence should make sense.

Risk → treatment decision → necessary control → Annex A comparison → Statement of Applicability

This creates traceability.

If an auditor asks why a particular control is necessary, the organization should be able to explain the reasoning.

If an Annex A control is excluded, the organization should be able to justify that decision.

The SoA should therefore reflect the organization’s actual risk treatment process rather than being created separately at the end of implementation.

Our next guide, Statement of Applicability: A Practical ISO 27001 Guide, will walk through that process.

Common ISO 27001 Risk Assessment Mistakes

Writing Risks as One or Two Words

“Ransomware” is not a useful risk statement by itself.

Describe the scenario and potential impact.

Making Every Risk High

If almost every risk receives the same rating, the methodology isn’t helping the organization prioritize.

Creating Artificial Precision

Risk scoring supports decisions.

It does not turn uncertain security events into exact mathematical probabilities.

Assessing Risk Without Risk Owners

Someone needs accountability for important risk decisions.

Assigning Every Risk to Security

Security may facilitate the risk process without owning every business risk.

Choosing Controls Before Understanding the Risk

Controls should respond to risks and requirements.

Don’t reverse the sequence.

Accepting Risk Without Defined Authority

Risk acceptance should follow established governance.

Treating the Risk Register as a Compliance Artifact

If nobody uses the register except before audits, it is probably not functioning as a management tool.

Never Updating the Assessment

Risk changes as the organization changes.

The assessment needs to remain relevant.

ISO 27001 Risk Assessment Frequently Asked Questions

Is a risk assessment required for ISO 27001?

Yes. Information security risk assessment is a core part of the ISO 27001 management system.

Does ISO 27001 require a specific risk methodology?

No. Organizations establish an approach appropriate to their context while meeting the applicable ISO 27001 risk assessment requirements.

Does ISO 27001 require a 5×5 risk matrix?

No. A 5×5 likelihood and impact matrix is common, but ISO 27001 does not require that specific scoring model.

What is an ISO 27001 risk register?

A risk register is a common way to record identified risks, assessment results, ownership, treatment information, and other information used by the organization’s risk management process.

What is the difference between risk assessment and risk treatment?

Risk assessment identifies, analyzes, and evaluates risks. Risk treatment determines how the organization will address those risks.

Do I have to identify an asset for every risk?

Organizations should use a risk identification approach consistent with their methodology and ISO 27001 requirements. A useful assessment needs to make clear what information security consequences are being considered, but that does not mean every organization must use the same asset-threat-vulnerability spreadsheet structure.

Who should own information security risks?

Risk ownership should be assigned to people with appropriate accountability and authority. Depending on the risk, that may be a business, technology, security, or other organizational leader.

How often should an ISO 27001 risk assessment be performed?

The organization should establish appropriate intervals and also reassess when significant changes could affect information security risk. The process should keep the assessment relevant rather than treating it as an annual paperwork exercise.

What is residual risk?

Residual risk is the risk that remains after treatment or controls have been considered according to the organization’s methodology.

How does risk assessment affect Annex A controls?

Risk treatment helps determine which controls are necessary. Those necessary controls are then compared with Annex A to verify that relevant controls have not been omitted.

A Good Risk Assessment Should Tell a Story

Choose one important risk from your register.

Then follow it.

Can you explain:

• What could happen?
• Why could it happen?
• What would the business impact be?
• How was the risk evaluated?
• Who owns it?
• What treatment decision was made?
• Which controls resulted from that decision?
• Are those controls operating?
• What risk remains?
• Who accepted that remaining risk?

If the organization can answer those questions, the risk register is doing more than satisfying an ISO requirement.

It is supporting information security management.

That is the real purpose of the process.

If you’re building your ISMS from the beginning, see our ISO 27001 Implementation Guide: A Practical Roadmap for Building Your ISMS.

You can also use our ISO 27001 Checklist: What You Need Before Certification to track the broader implementation.

And for the controls that follow risk treatment, see ISO 27001 Controls: A Practical Guide to Annex A.