Risk Assessment in ISO 27001 — How It Works Step by Step

Why Risk Assessment Matters

Without a risk assessment, your security programme is guesswork. You are implementing controls because they seem important or because a vendor sold them to you — not because they address your actual risks. The risk assessment gives your ISMS its direction: it tells you where to invest, what to prioritise, and what you can reasonably accept.

Auditors will check three things about your risk assessment: Is the methodology documented? Are the results consistent and reproducible? Do your controls actually trace back to identified risks? If any of these fail, the risk assessment is a finding — and without a valid risk assessment, the entire ISMS foundation is questionable.

The Risk Assessment Methodology

ISO 27001 does not prescribe a specific methodology — it requires that you define one, document it, and apply it consistently. The most common approach for startups is a qualitative asset-based methodology with a likelihood-impact scoring matrix. Here are the four steps:

Step 1 — Asset Identification

List every information asset within your ISMS scope. An information asset is anything that has value to the organisation and could be compromised. Categories include:

• Data assets: Customer databases, source code repositories, employee records, financial data, API keys, credentials
• Software assets: Production applications, internal tools, SaaS subscriptions, development environments
• Hardware assets: Servers (cloud instances count), laptops, mobile devices, network equipment
• People assets: Key personnel with critical knowledge or access — the bus factor
• Service assets: Cloud infrastructure (AWS, Azure, GCP), third-party APIs, email platforms, CRM

For each asset, assign an owner — the person accountable for its security. Asset ownership drives accountability throughout the ISMS.

Step 2 — Threat and Vulnerability Analysis

For each asset, identify the threats it faces and the vulnerabilities that could be exploited. A threat is something that could go wrong; a vulnerability is the weakness that allows it.

Step 3 — Likelihood and Impact Scoring

For each risk scenario (asset + threat + vulnerability), score the likelihood of the threat materialising and the impact if it does. Multiply to get a risk score.

Risk Score = Likelihood × Impact. Scores of 1-8 are typically low risk (accept or monitor). Scores of 9-16 are medium (implement controls). Scores of 17-25 are high or critical (immediate action required). Define your risk appetite — the threshold above which risks must be treated — and document it as part of your methodology.

Step 4 — Risk Treatment

For each risk above your risk appetite threshold, choose a treatment option:

• Mitigate: Implement controls to reduce likelihood, impact, or both. This is the most common treatment. Link each mitigation to a specific Annex A control.
• Accept: Acknowledge the risk and document the decision, including the business rationale. Requires sign-off from the risk owner or management.
• Transfer: Shift the risk to a third party — typically through insurance or contractual arrangements with vendors.
• Avoid: Eliminate the activity that creates the risk entirely. Sometimes the right answer is to stop doing the risky thing.

The output is a Risk Treatment Plan — a documented plan showing which risks are being treated, how, by whom, and by when.

The Risk Register — Your Central Risk Document

The risk register captures every identified risk with its assessment and treatment decision. For each entry, document:

• Risk ID and description
• Asset affected and asset owner
• Threat and vulnerability
• Likelihood score, impact score, and risk score
• Treatment decision (mitigate/accept/transfer/avoid)
• Controls implemented (linked to Annex A)
• Residual risk score (after treatment)
• Risk owner and review date

Common Risks for Startups

Based on SecComply implementation data, the most commonly identified risks for SaaS startups include:

• Unauthorised access to production systems due to insufficient access controls or missing MFA
• Data breach through compromised vendor or third-party integration
• Service disruption from single points of failure in cloud infrastructure
• Credential exposure through secrets committed to source code repositories
• Insider threat from overly permissive access rights or lack of access reviews
• Phishing attacks targeting employees with access to sensitive systems
• Data loss from inadequate backup procedures or untested restoration
• Compliance violation from untracked regulatory requirements (DPDP, GDPR)

Keeping It Alive — Not a One-Time Exercise

The risk assessment is not a document you write once for certification and then file away. It must be reviewed and updated:

• At least annually as part of the ISMS management review cycle
• When significant changes occur — new product launch, new market, new vendor, organisational restructuring, major incident
• When the threat landscape changes — new vulnerability classes, new attack techniques, new regulatory requirements
• After security incidents — each incident is a data point that may change likelihood or impact scores

The risk register should be a living document with a named owner and a defined review cadence. For the full picture on what an ISMS encompasses, see our What Is an ISMS guide.