ISO 27001 Risk Assessment: Process, Methodology, and Examples

Risk assessment is the engine that drives your entire Information Security Management System. Without it, your ISMS is a collection of policies and controls chosen on instinct rather than evidence. ISO 27001 does not leave this to interpretation — Clause 6.1.2 mandates a formal, repeatable risk assessment process that identifies threats, evaluates their severity, and produces a risk treatment plan linking every significant risk to a concrete response.

For SaaS companies, risk assessment determines which Annex A controls you implement, which ones you exclude (documented in your Statement of Applicability), and how you allocate limited security resources. A risk assessment that mirrors your actual threat landscape — cloud infrastructure misconfigurations, supply chain attacks through open-source dependencies, multi-tenant data isolation failures — produces an ISMS that genuinely protects your business. A generic one copied from a template produces audit findings and, worse, unaddressed vulnerabilities.

This guide walks through the entire ISO 27001 risk assessment process: what the standard requires, how to choose and apply a methodology, how to score and treat risks, and the specific considerations that apply to SaaS organizations.

What Does ISO 27001 Require for Risk Assessment?

ISO 27001 Clause 6.1.2 establishes six explicit requirements for the information security risk assessment process. Understanding each requirement is essential before you start building your methodology.

Requirement 1: Establish and Maintain Risk Assessment Criteria

You must define and document the criteria you will use to evaluate risks. This includes your risk acceptance criteria (what level of residual risk is tolerable) and the criteria for performing the risk assessment itself (how you will measure likelihood and impact). These criteria must be established before the assessment begins — not retrofitted to justify decisions already made.

In practice: Define your risk scoring scales, your risk appetite thresholds, and the rules for when a risk must be treated versus when it can be accepted. Document these in your risk management policy so they are consistent across assessments and auditable.

Requirement 2: Ensure Repeatable and Consistent Results

The risk assessment process must produce consistent, valid, and comparable results when repeated. This means your methodology cannot depend on a single person’s judgment without structure. Two different teams running the same assessment against the same scope should arrive at reasonably similar conclusions.

In practice: Use defined scoring scales, documented criteria for each rating level, and structured workshops rather than ad hoc brainstorming. A 5x5 likelihood-impact matrix with written descriptions for each level produces more consistent results than “discuss and agree on a rating.”

Requirement 3: Identify Information Security Risks

You must identify risks associated with the loss of confidentiality, integrity, and availability of information within the scope of the ISMS. This requires systematic identification — not just listing the obvious threats.

In practice: This means identifying the information assets in scope, the threats to those assets, the vulnerabilities that threats could exploit, and the potential consequences. For SaaS companies, the scope typically covers production infrastructure, customer data, internal systems that support the service, and the people and processes that operate them.

Requirement 4: Analyze the Identified Risks

Each identified risk must be analyzed to determine its likelihood of occurrence and the potential impact if it materializes. This analysis produces the risk level that drives treatment decisions.

In practice: Apply your scoring criteria consistently. For every risk, assess both the probability that the threat will exploit the vulnerability and the business impact if it does. Document the rationale — not just the numbers.

Requirement 5: Evaluate the Identified Risks

You must compare the results of risk analysis against your risk acceptance criteria and prioritize risks for treatment. Evaluation determines which risks require action and in what order.

In practice: Risks above your acceptance threshold require treatment. Risks below it can be accepted — but acceptance must be a documented decision, not a default. Prioritization ensures you address the most critical risks first, which matters when resources are limited (as they always are in growing SaaS companies).

Requirement 6: Document the Results

The results of the risk assessment must be retained as documented information. This is non-negotiable. Your risk register, methodology documentation, scoring rationale, and treatment decisions are all auditable artifacts.

In practice: Maintain a risk register that captures every identified risk, its analysis, its evaluation, and the treatment decision. This register is a living document — it is reviewed and updated throughout the ISMS lifecycle, not just during annual assessments.

Choosing Your Risk Assessment Methodology

ISO 27001 does not prescribe a specific methodology. It requires that your chosen approach meets the six requirements above, but the specific framework is your decision. This flexibility is intentional — different organizations have different risk profiles, resources, and maturity levels.

Qualitative Risk Assessment

Qualitative assessment uses descriptive categories (High, Medium, Low, or numerical scales like 1-5) rather than precise financial values. It is the most common approach for SaaS companies pursuing ISO 27001 for the first time.

How it works: Risks are scored on two dimensions — likelihood and impact — using predefined scales. The scores are multiplied or combined to produce an overall risk rating that determines treatment priority.

Advantages:

• Faster to implement and easier to maintain
• Does not require actuarial data or historical loss figures
• Accessible to non-security stakeholders who participate in risk workshops
• Sufficient for certification — auditors accept qualitative approaches

Disadvantages:

• Subjective — different assessors may assign different scores to the same risk
• Does not produce dollar-value estimates useful for ROI calculations on security investments
• Can lead to clustering (everything rated “Medium”) if scales are not well-defined

Best for: SaaS companies with fewer than 500 employees, organizations pursuing initial certification, teams without dedicated risk analysts.

Quantitative Risk Assessment

Quantitative assessment assigns monetary values to both the probability of occurrence and the potential impact. It uses formulas like Annual Loss Expectancy (ALE) = Single Loss Expectancy (SLE) x Annual Rate of Occurrence (ARO) to produce dollar-value risk estimates.

How it works: For each risk, you estimate the financial cost if the event occurs (SLE) and how often it is expected to occur per year (ARO). The product is the expected annual loss, which can be directly compared against the cost of mitigation to determine whether a control investment is justified.

Advantages:

• Produces financial figures that resonate with executive leadership and boards
• Enables direct cost-benefit analysis of control investments
• Reduces subjectivity when reliable data is available

Disadvantages:

• Requires historical data and actuarial estimates that many SaaS companies lack
• Time-intensive to develop and maintain
• False precision — the numbers can create an illusion of accuracy when the underlying assumptions are rough estimates

Best for: Mature organizations with dedicated risk management functions, companies with extensive incident history data, enterprises where board-level reporting requires financial risk quantification.

Hybrid Approach

Many organizations use qualitative assessment as the primary methodology and supplement it with quantitative analysis for the highest-priority risks or for specific investment decisions. This is a pragmatic approach that satisfies the standard while providing financial context where it matters most.

Example: A SaaS company uses a 5x5 qualitative matrix for its annual risk assessment but performs a quantitative analysis when evaluating whether to invest $200,000 in a new WAF solution versus accepting the risk of application-layer attacks.

Asset-Based vs. Scenario-Based Assessment

Beyond the qualitative/quantitative distinction, you also need to decide on your identification approach.

Asset-based assessment starts with an inventory of information assets (databases, servers, applications, data stores) and identifies threats and vulnerabilities for each asset. This is thorough but can be labor-intensive for organizations with extensive asset inventories.

Scenario-based assessment starts with threat scenarios (e.g., “ransomware encrypts production databases,” “developer laptop stolen with cached credentials”) and traces the impact to affected assets. This is often more efficient for SaaS companies because it focuses on realistic attack paths rather than exhaustively cataloging every asset.

The standard permits both. Most SaaS companies benefit from a scenario-based approach anchored to a high-level asset inventory. You need to know what assets exist, but your risk identification is organized around threat scenarios rather than asset-by-asset enumeration.

Asset Identification and Classification

Regardless of your methodology, you need to know what you are protecting. ISO 27001 requires that information assets within the ISMS scope be identified and classified.

Categories of Information Assets

Data assets: Customer data (PII, business data, usage analytics), employee data, financial records, intellectual property (source code, algorithms, training data), authentication credentials, encryption keys, configuration data, logs.

Technology assets: Production servers, databases, application code repositories, CI/CD pipelines, monitoring systems, backup storage, development and staging environments, SaaS tools used internally (identity providers, project management, communication platforms).

People assets: Employees with access to sensitive systems, contractors, third-party support personnel. People are assets because their knowledge, access, and actions directly affect information security.

Process assets: Incident response procedures, change management workflows, backup processes, onboarding/offboarding procedures. These are assets because their failure or absence creates risk.

Asset Ownership

Each asset must have a designated owner — a person accountable for the asset’s protection. Asset owners are responsible for ensuring that risks to their assets are identified, assessed, and treated. In SaaS companies, asset ownership typically follows the engineering organization structure: the team that builds and operates a system owns the associated assets.

Classification

Classify assets based on the sensitivity and criticality of the information they contain or process. A simple three-tier scheme works for most SaaS companies:

• Confidential — Customer data, credentials, encryption keys, source code. Unauthorized disclosure would cause significant harm.
• Internal — Internal business documents, non-sensitive employee information, project plans. Disclosure would cause moderate impact.
• Public — Marketing materials, published documentation, public API specifications. No impact from disclosure.

Classification drives the level of protection required and influences risk scoring — a threat to a Confidential asset has higher impact than the same threat to a Public asset.

Threat and Vulnerability Analysis

With your assets identified, you can systematically identify what could go wrong and why.

Threat Identification

Threats are potential events or actions that could harm your information assets. For SaaS companies, threats span several categories:

Cyber threats:

• Ransomware and malware targeting production infrastructure
• Credential stuffing attacks against customer authentication
• Supply chain compromise through third-party libraries or build tools
• DDoS attacks disrupting service availability
• API abuse — scraping, injection, rate limit bypass
• Zero-day exploitation of framework or OS vulnerabilities
• Phishing targeting employees with access to production systems

Insider threats:

• Malicious data exfiltration by employees or contractors
• Negligent misconfiguration of cloud resources (public S3 buckets, open security groups)
• Shadow IT — employees using unauthorized tools that process company or customer data
• Privilege abuse — employees accessing data beyond their job requirements

Environmental and operational threats:

• Cloud provider outages affecting availability
• Data center failures (even in the cloud, regional outages occur)
• Capacity exhaustion during traffic spikes
• Deployment failures introducing bugs or security regressions

Third-party threats:

• Security breaches at SaaS vendors processing your data
• Vendor service discontinuation forcing emergency migration
• Compliance failures by sub-processors affecting your regulatory obligations

Vulnerability Identification

Vulnerabilities are weaknesses that threats can exploit. They exist in technology, processes, and people:

Technical vulnerabilities:

• Unpatched software and operating systems
• Insecure default configurations
• Missing encryption for data at rest or in transit
• Inadequate logging and monitoring
• Weak authentication mechanisms (single-factor, shared credentials)
• Insufficient network segmentation between tenants or environments

Process vulnerabilities:

• No formal change management process
• Lack of code review requirements for production deployments
• Missing or untested backup restoration procedures
• Inadequate vendor security assessment processes
• No incident response playbooks

Human vulnerabilities:

• Insufficient security awareness training
• Key person dependencies (one engineer who knows how the system works)
• Inadequate background checks for employees with sensitive access
• Poor password hygiene despite policy requirements

Mapping Threats to Vulnerabilities

Risk exists at the intersection of a threat and a vulnerability. A threat without a corresponding vulnerability is theoretical. A vulnerability without a corresponding threat is a weakness but not an active risk. Your risk register should document the specific threat-vulnerability combinations that produce risk to your assets.

Example:

• Asset: Production PostgreSQL database containing customer data
• Threat: SQL injection attack via public API
• Vulnerability: Input validation not consistently implemented across all API endpoints
• Risk: Unauthorized access to customer data through SQL injection, leading to data breach, regulatory notification, and reputational damage

Likelihood and Impact Scoring

This is where your risk assessment transforms from a list of concerns into a prioritized decision-making tool.

Defining Your Likelihood Scale

Use descriptive definitions that your team can apply consistently. Vague labels like “Low” and “Medium” without definitions lead to inconsistent scoring.

Rating	Label	Definition
1	Rare	Could occur only in exceptional circumstances. No known incidents in similar organizations.
2	Unlikely	Could occur but not expected. Isolated incidents known in the industry.
3	Possible	Might occur at some time. Incidents occur periodically in similar organizations.
4	Likely	Will probably occur in most circumstances. Regular incidents in the industry.
5	Almost Certain	Expected to occur frequently. Continuous or near-continuous occurrence in the industry.

Defining Your Impact Scale

Impact should consider multiple dimensions relevant to your SaaS business:

Rating	Label	Financial	Operational	Reputational	Regulatory
1	Negligible	< $10K	No service disruption	No external awareness	No regulatory interest
2	Minor	$10K - $50K	Brief disruption, < 1 hour	Limited customer complaints	Informal regulatory inquiry
3	Moderate	$50K - $250K	Disruption 1-8 hours	Industry media coverage	Formal investigation
4	Significant	$250K - $1M	Extended outage 8-48 hours	Mainstream media coverage	Enforcement action, fines
5	Severe	> $1M	Prolonged outage > 48 hours	Sustained negative coverage	Major fines, mandatory remediation

The Risk Matrix

Multiply likelihood by impact to produce a risk score. A 5x5 matrix produces scores from 1 to 25:

	Negligible (1)	Minor (2)	Moderate (3)	Significant (4)	Severe (5)
Almost Certain (5)	5	10	15	20	25
Likely (4)	4	8	12	16	20
Possible (3)	3	6	9	12	15
Unlikely (2)	2	4	6	8	10
Rare (1)	1	2	3	4	5

Risk Rating Bands

Define what the scores mean for treatment decisions:

• Critical (20-25): Immediate action required. Risk must be treated before the next management review.
• High (12-19): Treatment plan required within 30 days. Risk owner must present options to management.
• Medium (6-11): Treatment plan required within 90 days. Monitored in regular risk reviews.
• Low (1-5): Accept or treat based on cost-benefit analysis. Reviewed during annual assessment.

Risk Appetite and Acceptance Criteria

Risk appetite is the amount and type of risk your organization is willing to take in pursuit of its objectives. It is defined by top management and documented in your risk management policy.

Setting Risk Appetite

Your risk appetite statement should be specific enough to guide treatment decisions. “We have a low risk appetite” is too vague. Instead:

• “We accept no residual risk rated Critical or High for risks affecting customer data confidentiality.”
• “We accept Medium residual risk for operational availability risks when the cost of further mitigation exceeds three times the annualized loss expectancy.”
• “We accept no risk that would result in regulatory non-compliance with GDPR or other data protection regulations applicable to our customer base.”

Formal Risk Acceptance

When a risk falls within your acceptance criteria — or when management makes a deliberate decision to accept a risk above the normal threshold — that decision must be documented:

• Risk description and current score
• Rationale for acceptance (cost-benefit analysis, low residual risk after existing controls, strategic decision)
• Approver — a named individual with authority to accept the risk (typically CISO, CTO, or risk committee chair)
• Review date — when the acceptance will be reassessed
• Conditions — any conditions that would invalidate the acceptance (e.g., “accepted until customer base exceeds 1,000 tenants”)

Auditors will verify that risk acceptance decisions are made by authorized individuals, documented with rationale, and reviewed periodically. Undocumented risk acceptance is a common nonconformity finding.

Risk Treatment Planning

Once risks are assessed and evaluated against your acceptance criteria, each risk above the threshold requires a treatment plan. ISO 27001 defines four treatment options.

Option 1: Mitigate (Reduce)

Implement controls to reduce either the likelihood or the impact of the risk. This is the most common treatment and creates the direct connection between your risk assessment and your Annex A controls.

Example: Risk of unauthorized access to production databases (score: 16, High).

• Controls: Implement multi-factor authentication for all production access (A.8.5), enforce role-based access control with least privilege (A.5.15), enable database activity logging with alerting (A.8.15), conduct quarterly access reviews (A.5.18).
• Expected residual risk: 6 (Medium) — likelihood reduced from Likely to Unlikely through access controls; impact unchanged.

Option 2: Transfer (Share)

Shift part of the risk to a third party. Common mechanisms include cyber liability insurance and contractual arrangements with vendors.

Example: Risk of financial loss from a data breach (score: 15, High).

• Treatment: Purchase cyber liability insurance covering breach response costs, regulatory fines (where insurable), and business interruption. Negotiate vendor contracts that include liability provisions for breaches caused by vendor negligence.
• Note: Transfer reduces financial exposure but does not eliminate the risk. You still need detective and response controls.

Option 3: Avoid (Terminate)

Eliminate the risk by removing the activity, process, or system that creates it.

Example: Risk of data exposure through a legacy API that uses basic authentication (score: 12, High).

• Treatment: Decommission the legacy API and migrate all consumers to the current API that supports OAuth 2.0 and rate limiting. The risk is eliminated because the vulnerable component no longer exists.

Option 4: Accept (Retain)

Acknowledge the risk and choose not to take additional action. Valid when the risk is within your risk appetite or when the cost of treatment significantly exceeds the potential impact.

Example: Risk of brief service disruption from cloud provider maintenance windows (score: 4, Low).

• Treatment: Accept. Cloud provider scheduled maintenance occurs in low-traffic windows and typically causes less than 5 minutes of degraded performance. The cost of implementing a multi-region active-active architecture to eliminate this risk is disproportionate to the impact.

The Risk Treatment Plan Document

Your risk treatment plan should document for each treated risk:

• Risk reference — linking back to the risk register
• Selected treatment option — mitigate, transfer, avoid, or accept
• Specific actions — what will be done
• Annex A control references — which controls implement the treatment (for mitigation)
• Owner — who is responsible for implementing the treatment
• Target date — when the treatment will be fully implemented
• Resources required — budget, personnel, tools
• Expected residual risk — the anticipated risk level after treatment

This document is a mandatory input to your Statement of Applicability, which maps each Annex A control to the risks it addresses.

Linking Risks to Annex A Controls

The connection between risk assessment and Annex A controls is what gives your ISMS coherence. Every control you implement should trace back to one or more identified risks. Every significant risk should be addressed by one or more controls (or formally accepted).

How the Mapping Works

1. Start with the risk treatment plan. For each risk you are mitigating, identify the specific control actions you will take.
2. Map actions to Annex A controls. Each control action corresponds to one or more of the 93 Annex A controls. For example, “implement multi-factor authentication” maps to A.8.5 (Secure authentication).
3. Document the mapping in your Statement of Applicability. The SoA shows each Annex A control, whether it is included or excluded, and the risk justification for that decision.
4. Include controls not driven by risk assessment. Some Annex A controls address legal, regulatory, or contractual requirements rather than specific risks. These are still included in the SoA with appropriate justification.

Common Mappings for SaaS Companies

Risk	Annex A Controls
Unauthorized access to customer data	A.5.15 (Access control), A.5.16 (Identity management), A.8.5 (Secure authentication), A.8.3 (Information access restriction)
Supply chain attack via third-party code	A.5.19-A.5.22 (Supplier relationship controls), A.8.25 (Secure development lifecycle), A.8.28 (Secure coding)
Data breach through misconfigured cloud resources	A.8.9 (Configuration management), A.8.8 (Management of technical vulnerabilities), A.8.15 (Logging)
Ransomware disrupting operations	A.8.7 (Protection against malware), A.8.13 (Information backup), A.5.24 (Incident management planning)
Key person departure	A.5.2 (Information security roles), A.5.4 (Management responsibilities), A.6.5 (Responsibilities after termination)
GDPR non-compliance	A.5.34 (Privacy and protection of PII), A.5.31 (Legal, statutory, regulatory requirements)

Risk Register Maintenance

Your risk register is not a one-time deliverable. It is a living document that reflects your current threat landscape, control environment, and business context.

Required Fields

Each risk entry should capture:

• Risk ID — Unique identifier (e.g., RISK-2026-001)
• Risk title — Concise name for reference
• Risk description — Detailed description of the threat, vulnerability, and potential impact
• Asset(s) affected — Which information assets are at risk
• Threat source — External attacker, insider, environmental, vendor
• Vulnerability — The weakness the threat exploits
• Inherent likelihood — Score before controls
• Inherent impact — Score before controls
• Inherent risk score — Likelihood x Impact
• Existing controls — Controls currently in place
• Residual likelihood — Score after controls
• Residual impact — Score after controls
• Residual risk score — Likelihood x Impact after controls
• Treatment decision — Mitigate, transfer, avoid, accept
• Treatment plan reference — Link to the treatment plan
• Risk owner — Named individual accountable
• Review date — When the risk was last reviewed
• Status — Open, in treatment, accepted, closed

Review Cadence

• Continuous — Update the register when significant events occur (security incidents, new vulnerabilities, vendor breaches, architectural changes, supplier onboarding)
• Quarterly — Formal review of the top risks, treatment progress, and emerging threats
• Annual — Full reassessment of all risks as part of the ISMS management review
• Triggered — Reassessment when significant changes occur (new product launch, M&A, infrastructure migration, new regulations)

Connecting to Internal Audit

Your internal audit program should verify that the risk assessment process is operating as documented. Auditors will check:

• Was the methodology followed consistently?
• Were new risks identified during the period captured in the register?
• Were treatment plans implemented on schedule?
• Were risk acceptance decisions properly authorized?
• Does the register reflect changes that occurred during the period?

SaaS-Specific Risk Examples

These examples illustrate how real SaaS risks are documented in a risk register. They are not a template to copy — your risks must reflect your specific architecture, data, and business context.

Example 1: Multi-Tenant Data Isolation Failure

Risk ID: RISK-2026-012 Description: A software defect in the tenant isolation layer allows one customer to access another customer’s data. This could result from a missing tenant ID filter in a database query, a caching error that serves another tenant’s data, or a race condition in session management. Asset: Customer data, production application Inherent likelihood: 3 (Possible) — tenant isolation is complex; similar incidents have occurred at major SaaS providers Inherent impact: 5 (Severe) — data breach affecting multiple customers, mandatory notification, severe reputational damage Inherent risk score: 15 (High) Existing controls: Tenant ID enforcement at the ORM layer, integration tests for tenant isolation, code review requirements for data access code Residual likelihood: 2 (Unlikely) Residual impact: 5 (Severe) — impact does not change; only likelihood is reduced Residual risk score: 10 (Medium) Treatment: Mitigate — implement row-level security at the database level as a secondary isolation mechanism, add automated tenant isolation testing to CI/CD pipeline, deploy runtime monitoring for cross-tenant data access patterns Controls: A.8.25 (Secure development lifecycle), A.8.28 (Secure coding), A.8.29 (Security testing), A.8.16 (Monitoring activities)

Example 2: Compromised CI/CD Pipeline

Risk ID: RISK-2026-018 Description: An attacker gains access to the CI/CD pipeline (GitHub Actions, Jenkins, or similar) and injects malicious code into a production deployment. Attack vectors include compromised GitHub tokens, malicious pull requests from forked repositories, or supply chain attacks through compromised GitHub Actions used in workflows. Asset: Source code, production infrastructure, customer data Inherent likelihood: 3 (Possible) — supply chain attacks are increasing in frequency Inherent impact: 5 (Severe) — attacker achieves code execution in production with access to all customer data Inherent risk score: 15 (High) Existing controls: Required code review for all PRs, branch protection on main branch, secret scanning in CI Residual likelihood: 2 (Unlikely) Residual impact: 5 (Severe) Residual risk score: 10 (Medium) Treatment: Mitigate — implement signed commits, pin all GitHub Actions to specific SHA hashes, deploy SLSA Level 2 build provenance, restrict self-hosted runner access, implement build artifact integrity verification Controls: A.8.25 (Secure development lifecycle), A.8.9 (Configuration management), A.5.19 (Information security in supplier relationships), A.8.15 (Logging)

Example 3: Third-Party SaaS Vendor Breach

Risk ID: RISK-2026-024 Description: A SaaS vendor that processes or stores company or customer data suffers a security breach, exposing data entrusted to them. Affected vendors could include identity providers, analytics platforms, customer support tools, or payment processors. Asset: Customer data, employee data, business data Inherent likelihood: 4 (Likely) — vendor breaches are frequent across the industry Inherent impact: 4 (Significant) — depending on the vendor, could expose customer PII, require breach notification, and cause reputational damage Inherent risk score: 16 (High) Existing controls: Vendor security assessment during onboarding, contractual data protection clauses, annual vendor review Residual likelihood: 3 (Possible) — cannot control vendor security posture entirely Residual impact: 3 (Moderate) — impact reduced through data minimization and encryption Residual risk score: 9 (Medium) Treatment: Mitigate — implement continuous vendor monitoring, require SOC 2 Type II or ISO 27001 certification from critical vendors, minimize data shared with vendors to what is operationally necessary, encrypt sensitive data before transmitting to vendors, maintain vendor incident response playbooks Controls: A.5.19-A.5.22 (Supplier management controls), A.5.31 (Legal requirements), A.8.11 (Data masking)

Example 4: Cloud Infrastructure Misconfiguration

Risk ID: RISK-2026-031 Description: A misconfiguration in cloud infrastructure (AWS, GCP, Azure) exposes resources to the public internet. Examples include publicly accessible S3 buckets, security groups allowing unrestricted inbound access, unencrypted database instances with public endpoints, or overly permissive IAM roles. Asset: Production infrastructure, customer data, application data Inherent likelihood: 4 (Likely) — misconfigurations are the most common cause of cloud security incidents Inherent impact: 4 (Significant) — could expose customer data, provide lateral movement for attackers, or enable resource abuse Inherent risk score: 16 (High) Existing controls: Infrastructure-as-code with PR review, AWS Config rules for common misconfigurations Residual likelihood: 2 (Unlikely) — IaC and automated checks significantly reduce likelihood Residual impact: 4 (Significant) — impact unchanged if misconfiguration occurs Residual risk score: 8 (Medium) Treatment: Mitigate — implement Cloud Security Posture Management (CSPM) tool, enforce infrastructure-as-code for all cloud resource changes (no manual console changes), deploy AWS SCPs to prevent creation of public resources, conduct quarterly cloud configuration audits Controls: A.8.9 (Configuration management), A.8.8 (Management of technical vulnerabilities), A.8.15 (Logging), A.8.23 (Web filtering)

Example 5: Insider Data Exfiltration

Risk ID: RISK-2026-037 Description: An employee or contractor with privileged access to production systems intentionally exfiltrates customer data for personal gain, competitive advantage, or malicious intent. This includes database exports, API data extraction, or copying data to personal storage. Asset: Customer data, intellectual property Inherent likelihood: 2 (Unlikely) — insider attacks are less frequent than external attacks but do occur Inherent impact: 5 (Severe) — data breach, regulatory notification obligations, legal liability, severe reputational damage Inherent risk score: 10 (Medium) Existing controls: Role-based access control, background checks for employees with production access, NDA agreements Residual likelihood: 1 (Rare) — controls reduce but cannot eliminate insider risk Residual impact: 5 (Severe) Residual risk score: 5 (Low) Treatment: Mitigate — implement database activity monitoring with alerting for bulk data exports, deploy DLP controls on endpoints and email, enforce just-in-time access for production databases, conduct quarterly access reviews to ensure least privilege, log and monitor all production access Controls: A.5.15 (Access control), A.6.1 (Screening), A.6.2 (Terms and conditions of employment), A.8.15 (Logging), A.8.16 (Monitoring activities), A.8.12 (Data leakage prevention)

Integrating Risk Assessment with the ISMS Lifecycle

Risk assessment is not a standalone exercise. It connects to every other component of your ISMS.

Connection to the Statement of Applicability

Your risk treatment plan is the primary input to the Statement of Applicability. The SoA lists all 93 Annex A controls and states whether each is included or excluded, with justification. For included controls, the justification traces back to the risk(s) the control addresses. For excluded controls, the justification explains why the risk does not apply.

Connection to Policies and Procedures

Your ISMS policies should reference the risk assessment as the basis for control requirements. For example, your access control policy does not just state “multi-factor authentication is required” — it states that MFA is required because the risk assessment identified unauthorized access as a High risk to customer data confidentiality.

Connection to the Certification Process

During your ISO 27001 certification audit, the auditor will examine your risk assessment methodology, risk register, treatment plan, and the connection between risks and controls. Common audit findings related to risk assessment include:

• Risk assessment methodology not documented or not followed
• Risk register not updated to reflect changes during the audit period
• Treatment plans without implementation evidence
• Annex A controls included in the SoA without corresponding risk justification
• Risk acceptance decisions without management approval
• No evidence of periodic risk review

Connection to GDPR and Data Protection

If your SaaS company processes personal data subject to GDPR, your ISO 27001 risk assessment supports — but does not replace — Data Protection Impact Assessments (DPIAs). The two processes are complementary: your ISMS risk assessment covers information security risks broadly, while DPIAs focus specifically on the risks to data subjects’ rights and freedoms from specific processing activities.

Common Mistakes in ISO 27001 Risk Assessment

Treating it as a one-time exercise. Risk assessment done once during certification and forgotten until the surveillance audit is a compliance exercise, not a security practice. Your threat landscape changes continuously. New vulnerabilities are discovered, new vendors are onboarded, infrastructure evolves, and attacker techniques advance. Your risk assessment must keep pace.

Using generic templates without customization. A risk register that lists “fire in the data center” for a 100% cloud-native SaaS company does not reflect reality. Your risks should be specific to your architecture, technology stack, customer base, and business model. Generic templates are a starting point for structure, not content.

Not involving the right people. Engineers know where the technical debt is. Product managers know which features handle the most sensitive data. Customer success teams know what uptime commitments have been made. Security teams alone cannot identify all relevant risks. Cross-functional workshops produce more complete risk registers.

Scoring everything as Medium. If every risk in your register scores between 6 and 12, your scoring criteria are not discriminating effectively. Review your likelihood and impact definitions to ensure they produce meaningful differentiation. A well-calibrated risk register should have risks distributed across the scoring range.

Disconnecting risk assessment from control decisions. If your risk register and your control implementation live in separate documents with no cross-references, auditors will identify the gap immediately. Every control should trace to a risk. Every significant risk should trace to a control or an acceptance decision.

Not documenting the methodology. “We brainstormed risks and wrote them down” is not a methodology. Document your scoring criteria, your assessment process, your review cadence, and the roles involved. The methodology document is itself an auditable artifact.

How GRCTrail Helps

GRCTrail provides SaaS companies with the tools and structure to run an ISO 27001 risk assessment process that satisfies auditors and produces genuine security insights.

• Guided risk assessment workflow that walks your team through Clause 6.1.2 requirements — from methodology definition through risk register completion — ensuring every step meets the standard without needing an external consultant to interpret the clauses
• Pre-populated SaaS risk library with threat scenarios specific to cloud-native SaaS companies, covering multi-tenant isolation, CI/CD pipeline security, cloud misconfiguration, supply chain risks, and vendor dependencies so you start from relevant threats rather than blank templates
• Automatic Annex A control mapping that links identified risks to the 93 Annex A controls and feeds directly into your Statement of Applicability, maintaining traceability from threat to treatment to control

Get started with GRCTrail →

Related Guides

• What Is ISO 27001? A Guide for SaaS Companies
• ISO 27001 Requirements: Understanding Clauses 4-10
• ISO 27001 Annex A Controls: Complete Guide to All 93 Controls
• ISO 27001 Statement of Applicability: How to Create It
• ISO 27001 Supplier Management Guide
• ISO 27001 Certification Checklist
• SOC 2 Risk Assessment Guide
• GDPR DPIA Guide