top of page
Search

ISO 27001 Risk Assessment Methods for Growing Businesses

Writer: AKRUP
AKRUP
5 days ago
9 min read

Growing businesses often face the same challenge: customer expectations and regulatory obligations increase before a dedicated security team is in place. A practical ISO 27001 risk assessment helps your information security management system (ISMS) prioritise time, budget and controls around the risks that could cause real harm.

 

It is not a one-off compliance exercise or a lengthy spreadsheet that nobody reviews. It is a repeatable process for protecting information, supporting operational continuity and demonstrating sound governance to customers and stakeholders.

 

The right method should fit your organisation, its systems, its suppliers and the information it handles.

 

What ISO 27001 requires from your risk assessment

 

ISO/IEC 27001:2022 requires organisations to establish, implement and maintain an information security risk assessment process. The organisation should document its risk assessment methodology, including how risks are identified, analysed, evaluated and accepted. Clause 6.1.2 expects the process to be consistent and repeatable, rather than based on assumptions made differently by each person.

 

The assessment should identify risks to confidentiality, integrity, and availability, analyse their likelihood and impact, and evaluate them against agreed acceptance criteria. It should also produce sufficient records for an internal audit. This is more than a gap analysis against ISO 27001 requirements. The NCSC risk management guidance is a useful reference for businesses building a proportionate process.

 

Set clear risk criteria first

 

Risk criteria explain how decisions will be made. They should cover the scope of the ISMS, scoring scale, risk appetite, acceptance thresholds and who can accept a risk.

 

For example, a business may decide that any risk rated "high" needs treatment before acceptance, while a "medium" risk may be accepted by a senior manager if a documented rationale exists. This avoids a risk register filled with subjective scores.

 

Risk appetite is the broad level of risk leadership is prepared to tolerate. Risk acceptance criteria are the practical rules used to make individual decisions.

 

Link assessment, treatment and the SoA

 

Clause 6.1.3 moves the process into risk treatment. Once a risk is evaluated, the organisation can reduce it, avoid it, share it through insurance or contractual arrangements, or accept it where this is justified.

 

The Statement of Applicability, often called the SoA, records which Annex A controls apply and why. Annex A contains 93 controls across organisational, people, physical and technological themes. It is not a checklist where every control must be implemented.

 

  A control is selected because it addresses a recognised risk, not because it happens to appear in a template.  

 

The SoA should clearly connect control choices to the risk treatment plan and explain exclusions. Guidance on Annex A and SoA justification supports this approach.

 

Choosing an ISO 27001 risk assessment method

 

ISO 27001 does not prescribe one scoring matrix or assessment model. Growing businesses should compare methods that are understandable, repeatable and appropriate to their risk profile.

 

In many cases, the strongest approach combines an asset-based risk assessment with scenario-based thinking. The first shows what matters most. The second tests whether safeguards would hold up during a realistic event.

 

Use an asset-based assessment for core information

 

An asset-based approach starts with what the organisation needs to protect. These information assets can include customer data, source code, laptops, cloud platforms, production systems, paper records, intellectual property and critical supplier relationships.

 

For each asset, identify its owner, classification, location and dependencies as part of risk identification, then assess threats and vulnerabilities. A customer database might face phishing, weak access permissions, accidental deletion or a cloud supplier outage.

 

This approach is especially useful when defining a new ISMS scope or organising an asset register.

 

Test realistic business scenarios

 

Scenario-based assessment asks what could happen across several connected assets. Consider ransomware affecting a file platform, a departing employee retaining access, a compromised supplier account or an outage at a cloud-hosting provider.

 

A growing SaaS business, for instance, may rely on Microsoft 365, AWS, a payroll provider and a customer-support platform. A scenario involving a compromised administrator account could affect data confidentiality, the integrity of records and service availability at the same time.

 

Scenario workshops are useful because business, IT, finance and operations teams can identify dependencies that do not appear in a technical asset list.

 

Combine both methods for hybrid environments

 

Start with assets so nothing important is missed. Then use scenarios to assess how an incident could spread through cloud services, remote working arrangements and third parties.

 

 

This combined method is well suited to organisations without enterprise-sized compliance teams. It creates a manageable assessment while still addressing risks that cross systems and suppliers.

 

A practical ISO 27001 risk assessment workflow

 

A risk assessment needs a consistent sequence. This makes it easier to explain, repeat and evidence during internal audit.

 

The NCSC cyber security risk management framework also sets out a clear cycle of identifying, assessing, treating and monitoring risk.

 

Define scope and identify dependencies

 

Start with the ISMS scope. Record the business units, locations, processes, systems and information types included. Be clear about interfaces outside the scope, because these can still create risk.

 

Document the scope and method to support the risk assessment required by Clause 6.1.2. This standardises how risks are assessed without requiring a particular scoring model.

 

Map critical dependencies next. These may include cloud providers, managed service providers, software suppliers, outsourced HR, payment processors and logistics partners. A supplier that processes customer data or connects to your network belongs in the assessment.

 

When reviewing vendors, look beyond a certificate. Supplier security certification guidance can help teams check certification scope, assurance evidence and relevant corrective actions.

 

Score likelihood and impact consistently

 

A simple five-point risk matrix is often enough for a growing business. This scale is illustrative, not an ISO 27001 requirement. Score likelihood based on the chance of the event occurring, considering current controls. Score impact according to the expected effect on confidentiality, integrity and availability.

 

Score

Likelihood description

Impact description

1

Rare, with strong controls in place

Minimal disruption or limited internal impact

2

Unlikely, but credible

Short disruption with manageable recovery

3

Possible under current conditions

Material operational, customer or compliance impact

4

Likely without further action

Serious disruption, data exposure or contractual concern

5

Expected or already occurring

Severe and sustained business impact

 

Multiply likelihood by impact if that suits your methodology. This risk analysis produces a result for risk evaluation against your acceptance criteria. A score of 15, for example, could trigger mandatory treatment, while scores below 6 may be accepted with owner approval. Thresholds and escalation rules should reflect management's risk appetite.

 

Move decisions into treatment

 

Each unacceptable risk needs a documented risk treatment plan, an accountable owner with authority to act, a target date and evidence that the action has been completed. Assign risk owners who can secure resources and make decisions. Treatment could include multi-factor authentication, supplier due diligence, offline backups, staff training, encryption or improved incident response arrangements.

 

After treatment, reassess the risk. The remaining exposure is residual risk. If it remains above the acceptance threshold, further action or formal management acceptance is required.

 

Qualitative and quantitative assessment methods

 

Most growing businesses use a qualitative risk assessment because it is practical and clear. It uses defined descriptions such as low, medium and high, with a consistent scoring scale.

 

The important point is not the number of columns in the matrix. It is that people apply the criteria consistently and document the assumptions behind each score.

 

When a qualitative matrix is enough

 

A qualitative model works well when data is limited, the environment changes regularly or the organisation needs decisions quickly. It gives management a sensible priority order without pretending that every cyber event can be forecast to the pound.

 

For example, the risk of an unpatched internet-facing system might be rated high. The treatment priority is clear even if the precise financial loss is unknown.

 

When financial estimates add value

 

A quantitative risk assessment can help where credible financial data exists. Measures such as Single Loss Expectancy and Annualised Loss Expectancy may support investment decisions for major outages, fraud exposure or specialist insurance.

 

Impact estimates may draw on a business impact analysis, including known downtime, customer, legal, recovery and operational consequences. However, a business impact analysis doesn't make uncertain financial figures precise.

 

A calculated estimate is only as reliable as its assumptions. For many organisations, a clear qualitative method supported by business context is more useful than complex calculations.

 

Management should review high risks in terms they understand, including customer commitments, downtime, legal exposure and recovery costs. The NCSC board risk guidance reinforces the value of informed cyber security decisions at leadership level.

 

Build a risk register that leads to action

 

A risk register is more than a list of concerns. It should give management enough information to understand the risk, approve a decision and check whether treatment is working.

 

Keep it simple enough to maintain. A spreadsheet may work at first. As the business grows, platforms such as ISMS.online, Vanta, Conformio or SureCloud can help centralise tasks, evidence and reviews.

 

Include the fields that matter

 

Each record should include:

 

  • A clear risk statement describing the event and business consequence.

  • The affected assets, processes, suppliers and information types.

  • Threats, vulnerabilities and existing controls.

  • Inherent likelihood and impact before further treatment.

  • A named owner and relevant risk owners with authority to act.

  • Treatment actions, deadlines and evidence requirements.

  • Residual risk, acceptance decision and review date.

 

A useful risk statement is precise: "A compromised administrator account could allow unauthorised access to customer records, causing a personal data breach and service disruption."

 

Avoid orphaned treatments

 

An orphaned treatment happens when an action appears in a plan but has no linked risk, owner, deadline or evidence. It is a common reason that an otherwise good register fails to demonstrate control in practice.

 

Every action in the risk treatment plan should link to a recognised risk, owner, deadline and evidence. If the treatment is "implement multi-factor authentication", record which risk it reduces, who owns implementation, what systems are covered and how completion will be verified. The SoA should also identify relevant Annex A controls and their justification.

 

Where internal ownership is limited, ongoing cyber risk management support can provide security leadership without recruiting a full-time CISO.

 

Keep the risk assessment current as the business changes

 

An annual review alone is rarely enough, so use continuous monitoring alongside event-driven reviews. Revisit the assessment when the organisation adopts a new cloud platform, enters a new market, changes office location, acquires a business, launches a product or appoints a critical supplier.

 

Security incidents, vulnerability alerts and internal audit findings should also trigger review. Gap analysis results can do the same, but a gap analysis doesn't replace the risk assessment.

 

Review supplier and cloud-service risks

 

Third-party risk needs active attention. A supplier's certification may provide assurance, but it doesn't remove your responsibility for assessing the service, data flows, access rights and contractual commitments.

 

Review supplier risks when the provider changes its service, suffers an incident, accesses more information or becomes more important to your operations. Check whether exit plans, backups and alternative suppliers remain realistic.

 

Use management review as a decision point

 

Management review should consider risk trends, overdue treatments, accepted risks, audit results and changes in the business context. This gives leaders a chance to allocate resources before risks become incidents.

 

 

Keep evidence of reviews, decisions and completed actions. Auditors need to see that the process operates in day-to-day business, not only before a certification assessment.

 

Key takeaways

 

  • Define a repeatable risk assessment methodology, including scope, scoring rules and acceptance criteria.

  • Combine asset-based assessment with realistic scenarios to cover cloud, people and supplier dependencies.

  • Use a simple qualitative matrix where it supports consistent decisions.

  • Link every treatment action to a risk, owner, deadline, evidence and residual-risk decision.

  • Use the Statement of Applicability to justify Annex A control selection.

  • Review the ISO 27001 risk assessment when the business, technology or threat environment changes.

 

Frequently asked questions

 

Is a five-point risk matrix required by ISO 27001?

 

No. ISO/IEC 27001:2022 requires defined and repeatable risk criteria, but it doesn’t mandate a particular matrix size. A three-point or five-point scale can both work if the criteria are clear and consistently applied.

 

What is the difference between a risk assessment and a gap analysis?

 

A risk assessment identifies threats, vulnerabilities and business consequences, then prioritises treatment. A gap analysis compares existing arrangements against ISO 27001 requirements and identifies what’s missing. Both are useful, but they answer different questions.

 

Who can accept residual risk?

 

Your methodology should define this. Low residual risks may be accepted by the risk owner, while high risks often need senior management approval. Authority and escalation should reflect the organisation’s documented risk appetite. Acceptance should be documented, time-bound and reviewed when conditions change.

 

For certification decisions or complex regulated environments, validate your interpretation of the standard with qualified ISO 27001 advice. An internal audit can support preparation, but it doesn’t replace a certification audit.

 

A proportionate route to stronger security

 

A well-managed ISO 27001 risk assessment turns broad security concerns into decisions that people can own and complete. It gives growing businesses a clear view of what matters most, where control gaps exist and which actions deserve investment.

 

The strongest assessments are practical, current and connected to real business operations. That is how risk management supports customer confidence, reduces disruption and keeps an ISMS useful long after certification.


If you would like more information or require any ISO 27001 services, please Contact Us

 
 
 

Comments

Rated 0 out of 5 stars.
No ratings yet

Add a rating
bottom of page