The Point of Risk Assessment in ISO 27001

ISO 27001 is a risk-based standard. Unlike PCI-DSS, which prescribes specific controls you must implement regardless of context, ISO 27001 asks you to identify your own risks first and then choose controls that address them.

The risk assessment is not a compliance checkbox, it is the mechanism that decides which of the 93 Annex A controls you actually need to implement. Get the risk assessment wrong, and the rest of your ISMS is built on shaky ground.

What Clause 6.1.2 Requires

Clause 6.1.2 of ISO/IEC 27001:2022 defines the risk assessment requirements. It sits within Clause 6 (Planning) alongside Clause 6.1.3 (risk treatment) and Clause 6.2 (information security objectives).

The clause requires you to define and apply a risk assessment process that:

  1. Establishes risk acceptance criteria: what risk level is tolerable for your organization
  2. Identifies information security risks: specifically, risks that could cause loss of confidentiality, integrity, or availability
  3. Assigns risk owners: a person with knowledge of and authority over each risk
  4. Analyzes risks: assesses the potential consequences and likelihood of each risk
  5. Evaluates risks: compares the calculated risk level against your acceptance criteria to determine which risks require treatment

The standard does not mandate a specific methodology. You choose how to measure impact and likelihood, what scale to use, and how to calculate a composite risk score, as long as the process is defined, repeatable, and produces comparable results when re-run.

Source: Advisera 27001 Academy (advisera.com/27001academy/iso-27001-risk-assessment)

Risk Assessment vs. Risk Treatment

These are separate clauses that many teams conflate:

Clause 6.1.2, Risk Assessment Analytical. You identify what could go wrong, who owns each risk, how severe the impact would be, and how likely it is. Output: a list of risks with calculated levels.

Clause 6.1.3, Risk Treatment Strategic. For risks above your acceptance threshold, you decide what to do about them. ISO 27001 defines four options:

  • Mitigate: implement controls to reduce the risk
  • Avoid: stop the activity that creates the risk
  • Transfer: shift the risk to a third party (insurance, contracts)
  • Accept: consciously retain the risk because treatment cost exceeds potential harm

Output of risk treatment: a risk treatment plan and the Statement of Applicability (SoA), which documents which Annex A controls you have selected and why.

Source: Advisera 27001 Academy (advisera.com/27001academy/iso-27001-risk-assessment)

What Your Risk Register Must Contain

The standard does not prescribe a template. Based on what Clause 6.1.2 requires, a compliant risk register needs at minimum:

FieldWhy it is required
Asset or activityIdentifies what is at risk
ThreatWhat could cause harm (malware, insider threat, misconfiguration)
VulnerabilityThe weakness the threat exploits
Risk ownerPerson responsible for the risk (required by Clause 6.1.2)
Impact scoreHow severe the consequences would be (scale you define)
Likelihood scoreHow probable the event is (scale you define)
Risk level (score)Calculated from impact × likelihood, or similar
Risk treatment decisionMitigate / avoid / transfer / accept
Applicable controlsWhich Annex A controls address this risk
Residual riskRisk level after controls are applied

A spreadsheet is sufficient for most organizations getting started. The standard does not require purpose-built software.

Choosing a Scoring Approach

The most common approach for organizations running ISO 27001 for the first time is qualitative scoring on a 1–5 scale:

  • 1 = Negligible / Rare
  • 3 = Moderate / Possible
  • 5 = Critical / Almost certain

Risk score = Impact × Likelihood. A score above a threshold you define (for example, 12 out of 25) requires treatment.

Organizations that want more structure can reference ISO/IEC 27005, the companion standard that provides detailed risk management methodology for information security. ISO 27005 describes asset-based, event-based, and hybrid approaches to risk identification and covers how to build a threat catalogue.

Source: Advisera 27001 Academy (advisera.com/27001academy); ISO/IEC 27005 (iso.org/standard/80585.html)

Common Risk Categories to Cover

Based on the Annex A control structure in ISO 27001:2022, most organizations address risks across these areas:

Organizational risks Information security policies, roles and responsibilities, threat intelligence, supplier relationships, incident management procedures.

People risks Insider threats, inadequate security awareness, offboarding failures (accounts not deprovisioned), social engineering.

Physical risks Unauthorized physical access to offices or server rooms, equipment theft or damage, clear desk / screen policy compliance.

Technology risks Misconfigured cloud services, unpatched systems, weak access controls, missing encryption, insufficient logging.

For each risk category, the assessment should identify specific assets and scenarios rather than generic statements like "we might be hacked." Specific risks lead to specific controls; vague risks lead to vague controls that certification auditors will question.

How Often to Re-run the Risk Assessment

The standard requires the risk assessment to be repeated "at planned intervals or when significant changes occur." Changes that typically trigger a re-assessment:

  • New cloud infrastructure deployed
  • New product features handling sensitive data
  • Significant headcount changes (especially in access-privileged roles)
  • A security incident
  • Entering a new market with different regulatory requirements

The annual surveillance audit with your certification body will expect to see an updated risk assessment that reflects current operations, not a three-year-old document.

After the risk assessment identifies which risks need treatment, the risk treatment process (Clause 6.1.3) maps those risks to controls from Annex A. The Statement of Applicability then documents:

  • Which of the 93 controls are applicable to your organization
  • Which are implemented
  • Why any controls are excluded (with justification)

An organization that identifies no risks requiring the Threat Intelligence control (5.7, new in ISO 27001:2022) must still include that control in the SoA and justify why it is excluded. Controls are not simply skipped, they are consciously included or consciously excluded.

Source: ISMS.online, ISO 27001 Annex A (isms.online/iso-27001/annex-a)

How Long Does the First Risk Assessment Take?

The standard sets no duration. For a 30–50 person company with a reasonably defined IT environment, the initial risk assessment, from scoping through to a completed risk register, typically takes a few days using a structured approach. The time expands when scope is unclear (what assets are in scope?), when risk owners are hard to identify, or when the team has not done this before.

Re-assessments on subsequent years take considerably less time because the structure is already in place.

What Auditors Look For

When a certification body audits your risk assessment, they check:

  1. Repeatable methodology: could someone else run this process and get consistent results?
  2. Risk owners identified: each risk has a named person responsible
  3. Treatment decisions justified: "we accepted this risk" needs a reason, not just a tick
  4. SoA consistent with the risk register: the controls you selected should trace back to identified risks
  5. Updated since significant changes: an unchanged risk register from two years ago raises questions

A common finding during initial certification audits is that the risk assessment is too generic. Auditors look for specificity: named assets, plausible threats, and controls that clearly address the risks identified.

References:

Tags:
ISO 27001Risk AssessmentRisk RegisterClause 6.1.2
← Back to Blog