Skip to main content
ISO 27001 Risk Assessment: Step-by-Step Guide for SaaS Teams
11 min read
November 4, 2024 (1y ago)

ISO 27001 Risk Assessment: Step-by-Step Guide for SaaS Teams

How to conduct an ISO 27001 risk assessment that satisfies auditors: methodology, asset inventory, threat identification, risk scoring, and treatment decisions.

ISO 27001Risk AssessmentISMSAudit

TL;DR

  • The ISO 27001 risk assessment drives control selection, the Statement of Applicability, and your entire ISMS — treat it as foundational, not paperwork.
  • Use a 5×5 likelihood × impact matrix, define the treatment threshold (usually 12–15), and link every above-threshold risk to specific Annex A controls.
  • A typical B2B SaaS company documents 30–60 risks. Review at least annually and after any major change.

The risk assessment is the backbone of your ISO 27001 ISMS. It drives everything: which controls you implement, how you allocate security resources, and what your Statement of Applicability looks like. Get the risk assessment right and the rest of the ISMS follows logically. Get it wrong and you are bolting controls onto a foundation that does not hold.

Why Risk Assessment Matters

ISO 27001 requires a risk-based approach to information security. You do not implement controls because a checklist says so. You implement controls because your risk assessment identified specific threats that those controls mitigate. Auditors trace this chain: risk assessment identifies threat, risk treatment plan specifies response, SoA documents which controls implement the response.

For the SoA side of this process, see our Statement of Applicability guide.

Step 1: Define Your Methodology

Before identifying risks, document how you will assess them. Your methodology must define:

Risk criteria — What constitutes low, medium, high, and critical risk. Use a 5x5 matrix with likelihood (1-5) and impact (1-5). Define what each score level means in concrete terms relevant to your business.

Scope — What assets, processes, and information are covered. This should align with your ISMS scope definition.

Risk appetite — What level of residual risk is acceptable. Typically, risks scoring above a threshold (e.g., 12 on a 25-point scale) require treatment.

Step 2: Build Your Asset Inventory

Identify what you are protecting. For a SaaS company:

  • Information assets — Customer data, intellectual property, employee records, financial data
  • Software assets — Production application, databases, APIs, third-party integrations
  • Infrastructure assets — Cloud accounts (AWS, GCP, Azure), networks, DNS, CDN
  • Physical assets — Laptops, mobile devices, office equipment
  • People — Employees with access to sensitive systems
  • Vendor assets — Third-party services that process your data

Assign an owner to each asset. The owner is responsible for maintaining the asset's security posture.

Step 3: Identify Threats and Vulnerabilities

For each asset, identify what could go wrong:

Common SaaS threats: Unauthorized access to production systems, data breach through compromised credentials, insider threat from departing employees, supply chain compromise through vendor breach, ransomware through phishing, data loss from misconfigured backups, service disruption from infrastructure failure, and regulatory non-compliance from inadequate privacy controls.

Map each threat to specific vulnerabilities in your environment. A threat without a vulnerability is theoretical. A vulnerability without a threat is low priority.

Step 4: Score and Prioritize

Rate each risk on likelihood and impact using your defined criteria. Multiply to get a risk score. Sort by score to prioritize treatment.

Focus treatment efforts on risks above your risk appetite threshold. Document why lower-scored risks are accepted rather than treated.

Step 5: Define Risk Treatment

For each risk requiring treatment, choose an approach:

  • Mitigate — Implement controls to reduce likelihood or impact. Link to specific Annex A controls.
  • Accept — Document the acceptance decision with justification and management sign-off.
  • Transfer — Use insurance or contractual mechanisms to shift the risk.
  • Avoid — Eliminate the activity that creates the risk.

The risk treatment plan becomes the bridge between your risk assessment and your SoA.

Keeping It Practical

The biggest mistake SaaS teams make is over-engineering the risk assessment with complex spreadsheets and hundreds of granular risks. Keep it practical: 30-60 well-defined risks, clear scoring, and treatment decisions that map directly to real controls.

For the broader ISMS context, see our ISO 27001 ISMS guide. For implementation support, explore our ISO 27001 services or schedule a call.

Free SOC 2 Readiness Checklist

A step-by-step checklist covering every control family, evidence requirement, and common audit finding. Used by 50+ SaaS teams preparing for their first SOC 2 audit.