Framework

ISO/IEC 27005
Information security risk management on one operating record

ISO/IEC 27005:2022 (Information security, cybersecurity and privacy protection: Guidance on managing information security risks) is the dedicated ISO standard for information security risk management. It is not a certifiable standard. Instead, it supplies the methodology that satisfies the ISO 27001 clause 6.1.2 and 6.1.3 risk assessment and risk treatment requirements. This page covers the 27005:2022 process (context establishment, risk identification, risk analysis, risk evaluation, risk treatment, risk acceptance, communication and consultation, recording, monitoring and review), the event-based and asset-based identification methods, the risk criteria the standard expects, the audit evidence ISO 27001 certifiers read against, where 27005 sits next to ISO 27001, ISO 31000, NIST SP 800-30, FAIR, and COSO ERM, and how a workspace-driven approach turns 27005 into a defensible operating record rather than a stack of disconnected assessments.

Get Started Free

No credit card required. Free plan available forever.

ISO/IEC 27005:2022 information security risk management explained

ISO/IEC 27005:2022 (Information security, cybersecurity and privacy protection: Guidance on managing information security risks) is the dedicated ISO standard for information security risk management. It is not a certifiable standard. Instead, it supplies the methodology that satisfies the ISO 27001 clause 6.1.2 (risk assessment) and clause 6.1.3 (risk treatment) requirements, and it sits alongside ISO 31000 as the information-security-specific risk standard most ISO 27001-aligned programmes reference. The 2022 revision aligned the structure with the 2018 revision of ISO 31000 and clarified the relationship to ISO 27001:2022, the event-based and asset-based identification approaches, and the risk treatment option taxonomy.

For GRC owners, ISO 27001 lead auditors, ISMS managers, CISOs, vulnerability management teams, AppSec teams, security engineering teams, security architects, and the internal audit functions that examine the ISMS, ISO/IEC 27005 is the methodology the certification audit reads against when clause 6.1 evidence is requested. Programmes operating against ISO 27001 or planning to certify use 27005 as the underlying assessment process the ISMS produces evidence from. Programmes already operating against ISO 31000 read 27005 as the information-security-specific instantiation that sits inside the ISO 31000 umbrella, and programmes operating against NIST SP 800-30 use 27005 as the deliberately compatible ISO-side counterpart with parallel process structure and similar risk factor decomposition. The methodology is not a replacement for FAIR; FAIR is one of the quantitative methods 27005 accommodates as the analytical approach for the analysis step.

The 27005 process: context, identification, analysis, evaluation, treatment, acceptance

ISO/IEC 27005:2022 organises the risk management process into six sequential steps plus three continuous activities. The steps are sequential in dependency, not in calendar time: monitoring and review feeds the next cycle's context establishment, so the methodology operates as a loop rather than a one-off project. Each step is described in detail in the standard's main clauses.

Context establishment

Define the external and internal context, the scope and boundaries of the risk management, the risk criteria (acceptance criteria, impact scale, likelihood scale, evaluation criteria), and the organisation for the risk management. ISO/IEC 27005:2022 aligns this step with the ISO 31000 process and produces the documented context the rest of the assessment reads against. The criteria set here are applied unchanged across the cycle; revisiting them mid-analysis is a documented failure mode.

Risk identification

Identify the risk set in scope using the event-based approach, the asset-based approach, or both. The event-based approach starts from threat-source intelligence, incident history, and strategic context, then traces each risk scenario to the assets it affects. The asset-based approach starts from primary assets (business processes, information) and supporting assets (hardware, software, network, personnel, site, structure), then catalogues the threats, vulnerabilities, and existing controls per asset. Most programmes run both and reconcile.

Risk analysis

Assess the consequence and the likelihood of each identified risk, then determine the level of risk as a combination of the two. ISO/IEC 27005:2022 supports qualitative, semi-quantitative, and quantitative analytical approaches; the context-establishment step names the approach the cycle uses. The decomposition into consequence and likelihood (rather than a single composite score) is what lets decision-makers push back on specific inputs during risk evaluation and risk treatment.

Risk evaluation

Compare the analysed risk level against the evaluation criteria established during context establishment. The output is the prioritised risk set: risks above the evaluation threshold proceed to risk treatment, and risks at or below the threshold proceed to risk acceptance with the rationale recorded. Risk evaluation reads consequence and likelihood separately so the treatment choice in the next step targets the dominant driver rather than the composite.

Risk treatment

Select and implement treatment options for the risks above the evaluation threshold. ISO/IEC 27005:2022 catalogues four options: modify (apply, change, or remove controls), retain (accept by informed decision), avoid (do not start or discontinue the activity), and share (transfer or share with another party). The modify path feeds the ISO 27001 Statement of Applicability with the controls selected from Annex A and the controls excluded with justification. Treatment is iterative; residual risk re-enters analysis until it falls within the acceptance criteria.

Risk acceptance

Document the residual risk acceptance per retained risk. The acceptance record names the risk, the residual level after treatment, the risk owner, the accepting decision-maker, the justification, the conditions of acceptance, the review cadence, and the conditions that trigger reassessment. ISO/IEC 27005:2022 is explicit that acceptance is a documented decision; an absent acceptance record is a missing artefact the certifier reads as evidence the methodology was not applied.

Continuous activities: communication, recording, monitoring

ISO/IEC 27005:2022 names three activities that run continuously alongside every process step rather than as sequential phases. The continuous activities are where the methodology either becomes operating discipline or collapses into a once-a-year document exercise that no decision references.

Communication and consultation

Run continuously alongside every process step. Engages the risk owner, the asset owner, the affected business unit, the legal function, the audit function, the regulator-facing function, and the executive sponsor in the risk dialogue. The activity surfaces inputs the analyst could not have produced alone (operational tacit knowledge, customer context, regulator signals) and produces the per-audience decision evidence the audit reads against. Programmes that compress communication into a single end-of-cycle report lose the methodology value the consultation is meant to add.

Recording and reporting

Produce the documented evidence per cycle: the context-establishment record, the risk identification output, the analysis output, the evaluation output, the treatment plan, the residual risk acceptance, the consultation log, and the monitoring record. Reporting tailors the same evidence per audience: the risk owner reads the operating detail, the executive sponsor reads the residual position, the audit committee reads the per-risk acceptance evidence, the certifier reads the methodology defence and the cross-clause linkage into ISO 27001 clause 6.1.

Monitoring and review

Provide the per-cycle re-read against the changed context, the new threat intelligence, the updated vulnerability state, the residual risk position, and the treatment effectiveness. Reassessment triggers named in ISO/IEC 27005:2022 include scope changes, new or changed assets, new threats or threat actors, new vulnerabilities or control effectiveness changes, incidents, exception additions or expirations, regulatory changes, and the periodic refresh cadence. The monitoring record is the operating audit trail the next certification cycle reads against.

Risk identification: event-based and asset-based approaches

The 2022 revision is explicit about the two identification approaches and the choice between them. The standard is approach-agnostic; the context-establishment step names which approach the cycle will use. Mature programmes typically run both and reconcile so neither approach's blind spot truncates the resulting risk set.

Event-based approach

Identify risk scenarios from threat-source intelligence, incident history, peer-organisation observations, regulator advisories, and strategic context first; trace each scenario to the assets it affects second. The approach scales well to large scopes where an asset-by-asset traversal is impractical, and it surfaces the high-consequence scenarios that cross multiple assets. The trade-off is that supporting-asset coverage can be uneven; pairing the approach with an asset-based pass closes the gap.

Asset-based approach

Identify primary assets (business processes and the information they handle), then identify supporting assets (hardware, software, network, personnel, sites, organisational structure), the threats per asset, the vulnerabilities per asset, and the existing controls. The approach produces complete supporting-asset coverage and is the canonical ISO 27005 method most programmes start with. The trade-off is that aggregate-level and cross-asset risk scenarios can be under-represented; pairing the approach with an event-based pass closes the gap.

Hybrid: event then asset, asset then event

Most mature programmes run both approaches per cycle and reconcile the resulting risk set. The discipline is to keep the two passes parallel rather than sequential so neither approach truncates the other. ISO/IEC 27005:2022 is deliberately approach-agnostic; the standard names the approaches and leaves the selection to the context-establishment criteria. Programmes operating in regulated sectors typically document the hybrid approach as the methodology choice the certifier reads against.

Risk treatment options: modify, retain, avoid, share

ISO/IEC 27005:2022 catalogues four treatment options. The choice per risk is recorded in the risk treatment plan with the per-option rationale, the residual risk after treatment, and the named owner. Programmes that default every treatment to modify miss the methodology value the four-option catalogue is meant to add.

Modify

Apply, change, or remove controls so the risk level falls within the risk acceptance criteria. Modify is the most common treatment path and feeds the ISO 27001 Statement of Applicability with the controls selected from Annex A. The per-control rationale, the implementation evidence, and the residual risk after modification all read on the same evidence the operating record already produces. Modify decisions feed the security programme backlog through the finding remediation lifecycle.

Retain

Accept the risk by informed decision after determining that the residual level falls within the acceptance criteria, or after determining that further treatment is not justified. Retain feeds the residual risk acceptance record with the accepting decision-maker, the justification, the conditions, and the reassessment triggers. Retain is not the absence of action; it is a documented decision with named accountability.

Avoid

Do not start or discontinue the activity that gives rise to the risk. Avoid feeds the architecture decision record, the product decision record, the procurement decision record, or the partnership decision record depending on the activity. Avoid is often the cheapest treatment when the activity is optional and the risk is high; programmes that overlook avoid as an option end up modifying or retaining risks the business could have stepped away from.

Share

Transfer or share the risk with another party through insurance, contractual allocation, joint ventures, or partner arrangements. Share feeds the insurance record, the contract record, and the partner agreement record. Share does not eliminate the underlying risk; it transfers a portion of the consequence to a third party. The residual risk after share enters acceptance with the share-specific conditions recorded.

CVE, CVSS, EPSS, KEV, and SSVC as 27005 inputs

The vulnerability scoring and prioritisation signals modern programmes already use feed directly into the 27005 identification and analysis steps. The discipline is to treat them as inputs to the methodology rather than as the methodology itself; ISO 27005 adds the threat-source characterisation, the asset and predisposing conditions context, the consequence analysis, and the audience-tailored communication that the vulnerability scores alone do not produce.

  • CVSS scores feed the vulnerability factor for technical vulnerabilities the assessment reads against. The Base, Temporal, and Environmental metrics each contribute different signals: Base for the unmitigated severity, Temporal for the current exploit and remediation context, Environmental for the per-system context the ISO 27005 scope is bounded against.
  • EPSS estimates feed the likelihood factor for adversarial risk scenarios tied to specific vulnerabilities. EPSS is not the scenario likelihood; it is the probability the vulnerability is exploited within a defined time window, which is one input the analyst combines with the threat source characterisation to estimate the per-scenario likelihood.
  • CISA KEV catalogue entries elevate the likelihood factor for the specific vulnerabilities the catalogue lists. KEV is the active-exploitation signal; vulnerabilities on KEV warrant the high or very high likelihood reading regardless of the EPSS estimate, because active exploitation in the wild is observed evidence rather than a probability estimate.
  • SSVC decisions feed the risk treatment selection (modify, retain, avoid, share) for the per-vulnerability response. SSVC produces a stakeholder-specific decision (Track, Track*, Attend, Act) for the same input set the ISO 27005 vulnerability factor reads against, and the SSVC output reads as one input into the treatment selection.
  • Internal incident history provides the calibration data for the consequence and likelihood estimates the assessment produces. Programmes with a documented incident record validate per-scenario consequence and likelihood against observed events; programmes without an incident record carry higher uncertainty and must reflect that in the confidence the analysis reports against.
  • Threat catalogues (Annex of ISO/IEC 27005:2022, MITRE ATT&CK, ENISA threat landscape, vendor and sector ISAC sharing) provide the threat-source characterisation data the identification step reads against. The discipline is to source per-cycle data rather than to carry the prior cycle characterisation forward without re-validation.

27005 next to ISO 27001, ISO 31000, NIST SP 800-30, FAIR, and COSO ERM

ISO/IEC 27005 is the information-security-specific methodology, not the broader risk management framework. The standard sits inside a broader ecosystem with named relationships to the adjacent publications. Mature programmes typically operate several of these standards together; 27005 is the methodology the rest of the ecosystem reads against for the information-security risk question.

  • ISO 27001 clauses 6.1.2 and 6.1.3 require a documented information security risk assessment and risk treatment process. ISO/IEC 27005 is the dedicated methodology most ISO 27001 programmes reference to satisfy those clauses, and the per-cycle evidence reads cleanly into the Statement of Applicability and the residual risk acceptance record.
  • ISO/IEC 27002 is the control catalogue the modify treatment selects from. The treatment plan reads against the ISO 27002 control set, and the per-control selection feeds the ISO 27001 Statement of Applicability with the per-control rationale.
  • ISO 31000 is the enterprise risk management umbrella. ISO/IEC 27005 sits inside the ISO 31000 process structure as the information-security-specific instantiation, with the per-scenario evidence feeding the enterprise risk register the ISO 31000 framework operates against.
  • NIST SP 800-30 is the federal-side counterpart to 27005 with parallel process structure and a similar risk factor decomposition. Programmes operating primarily under FISMA, FedRAMP, or CMMC reference 800-30; programmes operating primarily under ISO 27001 reference 27005. The two are deliberately compatible, and the same per-scenario evidence reads cleanly under either methodology with the cross-framework reference recorded once.
  • FAIR is the most common operationalisation of the quantitative path within 27005. Programmes requiring board-readable financial expression reference 27005 for the process and FAIR for the analytical method; the FAIR ontology sits underneath the 27005 consequence and likelihood factors.
  • COSO ERM consumes 27005 outputs into the enterprise risk portfolio Principles 11 (Assesses Severity of Risk) and 14 (Develops Portfolio View) read against. The per-scenario record produced by 27005 reads cleanly into the portfolio view the audit committee and board approve against.
  • NIST AI Risk Management Framework and ISO/IEC 42001 extend the risk question to AI systems with the MEASURE function and the AIMS process reading against 27005-style analytical decomposition for the AI-specific scenarios.
  • ISO/IEC 31010 (Risk assessment techniques) is the companion standard that catalogues the analytical techniques (bow-tie, FMEA, HAZOP, scenario analysis, Bayesian analysis, Monte Carlo) the 27005 analysis step selects from. The context-establishment criteria name the techniques the cycle uses, and the analysis output records the per-technique selection.

Recurring failure modes 27005 programmes hit

Programmes that struggle with ISO 27005 typically hit a small set of recurring failure modes. Naming the failure modes upfront lets the programme design the operating model to avoid them rather than discovering them at the certification audit or the residual-risk acceptance defence.

Treating ISO 27005 as a one-off project. The standard explicitly names monitoring and review as a continuous activity because risk assessments age. Programmes that produce the assessment as a project deliverable, file the report, and revisit it at the next certification cycle carry stale risk determinations into operating decisions. The fix is to hold the assessment as an operating record with the refresh triggers named in the context.

Skipping context establishment. The criteria, scope, and organisation set here are the artefacts the rest of the methodology reads against. Programmes that compress context into a single paragraph rebuild it inconsistently during risk identification and risk analysis, and the certifier discovers the inconsistency at the methodology defence step.

Reporting risk as a single composite score without showing the decomposition. ISO/IEC 27005:2022 decomposes risk into consequence and likelihood for a reason: the decomposition is what lets the decision-maker push back on specific inputs and what lets the per-cycle refresh produce a delta on the changed factors rather than a rebuild.

Running only the asset-based approach or only the event-based approach. The standard supports both because each carries blind spots the other closes. Asset-based passes can miss aggregate-level and cross-asset scenarios; event-based passes can miss supporting-asset detail. Mature programmes run both per cycle and reconcile.

Treating risk acceptance as an absence of evidence. ISO/IEC 27005:2022 is explicit that acceptance is a documented decision: the risk, the residual level, the owner, the accepting decision-maker, the justification, the conditions, the review cadence, and the reassessment triggers. The certifier reads acceptance evidence specifically and treats missing acceptance as a missing methodology step.

Communicating only at the end of the cycle. ISO/IEC 27005:2022 names communication and consultation as a continuous activity because it surfaces inputs the analyst could not have produced alone and produces the per-audience decision record the audit reads against. Programmes that produce one end-of-cycle report miss the methodology value the consultation is meant to add.

Holding the risk record outside the operating record. The 27005 inputs (threat intelligence, vulnerability state, control effectiveness, predisposing conditions, incident history) come from places the security programme already produces evidence. Programmes that hold the assessment in a separate analytical environment that does not reconcile with the operating record discover at refresh time that the inputs have drifted from the source-of-truth state. The fix is to source inputs from the operating record so the per-cycle refresh is a re-read rather than a rebuild.

Treating the Annex catalogues as the assessment. The threat and vulnerability catalogues in the ISO/IEC 27005:2022 Annexes are reference material, not the per-scope assessment. Programmes that copy the catalogues unchanged produce a generic assessment that does not read against the actual environment. The catalogues are the starting point; the per-scope tailoring is the work the methodology expects.

Evidence the methodology expects to see

A defensible 27005 programme produces a stable evidence set per cycle. The same set reads cleanly into ISO 27001 clauses 6.1.2 and 6.1.3, the Statement of Applicability, the residual risk acceptance, and the parallel framework reads (NIST SP 800-30, ISO 31000, COSO ERM, FAIR, SOC 2, PCI DSS, DORA, NIS2, and the regulator-side examinations that consume risk assessment evidence as part of the broader programme review).

  • Context establishment record per cycle: external and internal context, scope and boundaries, risk acceptance criteria, impact scale, likelihood scale, evaluation criteria, and organisation for risk management
  • Risk register per cycle with the per-scenario record: the threat source, threat event, asset (primary and supporting), vulnerability, predisposing condition, consequence, likelihood, level of risk, treatment, residual risk, and acceptance entries
  • Threat catalogue per scope sourced from the ISO/IEC 27005:2022 Annex, MITRE ATT&CK, ENISA threat landscape, sector ISAC sharing, and the internal incident history, with per-cycle refresh evidence
  • Vulnerability catalogue per scope sourced from scanner output, audit findings, threat modelling, code scanning, and the internal exception register, with per-cycle refresh evidence
  • Risk treatment plan per cycle with per-action owner, control selection from ISO 27001 Annex A (and the Statement of Applicability linkage), milestone, effectiveness measure, and residual risk after treatment
  • Residual risk acceptance record per retained risk: the accepting decision-maker, the justification, the conditions of acceptance, the review cadence, and the reassessment triggers
  • Communication and consultation log per cycle with the stakeholder engagement record, the per-audience output, the consultation feedback, and the per-decision rationale arising from the exchange
  • Monitoring and review record per cycle with the per-trigger reassessment evidence, the input deltas against the prior cycle, the analyst sign-off per refresh, and the impact on the prior risk determinations
  • ISO 27001 cross-reference per assessment: the clause 6.1.2 risk assessment evidence, the clause 6.1.3 risk treatment evidence, the Statement of Applicability linkage, the residual risk acceptance evidence the certifier reads against, and the per-control implementation reference

How 27005 reads across enterprise security functions

ISO 27005 is a cross-functional methodology. The same per-scenario record reads differently depending on the function that holds the work. Programmes that run 27005 as a GRC exercise alone lose the engineering depth the inputs require; programmes that run it as an engineering exercise alone lose the governance depth the audience-tailored communication is meant to add. The named functions below own different parts of the same risk record.

GRC and compliance teams

Run ISO/IEC 27005 as the methodology that satisfies the ISO 27001 clause 6.1.2 (risk assessment) and clause 6.1.3 (risk treatment) requirements with the audit evidence the certifier reads against. Hold the per-cycle context, the per-scenario risk register, the treatment plan, the residual risk acceptance, the communication log, and the monitoring record on the workspace so the GRC programme produces one defensible record set the ISO 27001 audit, the SOC 2 examination, the regional regulator read, and the parallel framework reads all consume from. Carry the cross-framework reference so the 27005 determinations feed NIST SP 800-30, ISO 31000, FAIR, and COSO ERM without a parallel reconciliation exercise.

CISOs and security leaders

Read ISO/IEC 27005 as the methodology the European-side procurement reviews, the ISO 27001-aligned customer expectations, and the audit committee briefing rely on as the canonical information security risk methodology. Track the per-cycle refresh cadence, the per-scenario decision register, the residual-risk acceptance record per asset, and the methodology defence pack the certifier reads against. The defensible CISO position is that every operating decision carrying material information security risk has a 27005-aligned assessment behind it, the assessment is current per the refresh trigger schedule, and the decision record reads against the same operating record the rest of the programme produces.

Vulnerability management teams

Supply the vulnerability catalogue, the predisposing conditions sourced from exception register entries, the patch state per asset, the per-finding remediation SLA adherence, and the per-asset criticality scoring into the inputs risk identification and risk analysis read against. The signal 27005 reads against is the operating record, not the snapshot the analyst pulls during the assessment week. Programmes that run vulnerability management on the same workspace the 27005 assessment reads from produce assessments that refresh per cycle rather than per audit.

AppSec and product security teams

Carry the code-scanning state, the dependency vulnerability state, the secure-coding adherence record, the threat modelling output, and the SDLC predisposing conditions into the vulnerability and risk identification records for application-system assessments. The 27005 assessment for an application reads against the development-side evidence as a primary input source, not as a footnote; programmes that supply per-repo finding state, per-build dependency state, and per-release retest evidence produce assessments the audit committee can defend against the live engineering posture.

Security engineering and security architects

Own the predisposing conditions record across architecture decisions, trust boundaries, dependency design, and the operating environment context the assessment reads against. The architecture decisions the engineering team makes show up in the 27005 risk register as predisposing conditions; programmes that hold the architecture evidence on the workspace let the assessment update automatically when the architecture changes, rather than waiting for the next audit cycle to surface the drift.

ISO 27001 ISMS managers and lead auditors

Treat ISO/IEC 27005:2022 as the dedicated methodology that satisfies the clause 6.1.2 risk assessment and clause 6.1.3 risk treatment requirements without leaving the methodological choice undocumented. Pair the per-cycle 27005 record with the ISO 27001 Statement of Applicability so the per-control selection reads against the per-scenario treatment decision, and the residual risk acceptance reads against the named accepting decision-maker. The audit defence rests on the clean linkage from the risk register through the treatment plan to the SoA and back.

Internal audit and audit committees

Read 27005 outputs into the per-risk acceptance pack the audit committee approves, the per-cycle change log, the per-residual-risk reassessment record, and the cross-framework reference per assessment. The audit committee position is that the cyber risk portfolio the board reviews is the 27005 output expressed in the language COSO ERM Principle 11 (Assesses Severity of Risk) and Principle 14 (Develops Portfolio View) consume, with the per-scenario decision record reading against the live operating evidence.

Running 27005 on SecPortal

SecPortal is built around the operating record an ISO 27005 programme reads against: the engagement carries the per-cycle assessment lifecycle from context establishment through monitoring, the findings record carries the vulnerability state feeding identification and analysis, the documents area carries the per-cycle artefact set, and the activity log carries the audit trail the certifier reads against. The platform alignment below maps the verified product capabilities to the 27005 process so the methodology is held on one operating record rather than across a separate analytical environment that drifts from the live posture.

  • Engagement management as the workspace anchor for the assessment lifecycle, with the per-cycle context establishment, identification, analysis, evaluation, treatment, acceptance, communication, and monitoring tracked as a single engagement rather than as parallel projects that drift apart
  • Findings management with CVSS 3.1 calibration so the vulnerability inputs the 27005 assessment reads against carry the same severity vocabulary the scanner intake, the manual finding triage, the exception register, and the remediation SLA record use
  • Compliance tracking across ISO 27001, ISO 27002, ISO 31000, NIST SP 800-30, NIST SP 800-37, NIST CSF 2.0, COSO ERM, FAIR, SOC 2, PCI DSS, and the regional regulator frameworks so the 27005 risk determinations feed the parallel framework reads without rebuilding the underlying input set
  • Authenticated scanning and external scanning so the vulnerability catalogue feeding the risk identification step carries live posture evidence on the assessed scope rather than a snapshot from the assessment week, with the per-asset coverage record archived per refresh
  • Code scanning via Semgrep against connected GitHub, GitLab, and Bitbucket repositories so the AppSec vulnerability inputs feeding application-system risk scenarios read against the live code state rather than against a prior commit
  • Document management for the context-establishment record, the risk register, the threat and vulnerability catalogues per scope, the treatment plan, the residual risk acceptance record, the communication log, and the monitoring record so the 27005 evidence package lives on the operating record rather than across a folder hierarchy that drifts from the assessment reality
  • Activity log with CSV export so every change to a context entry, a risk scenario, an analyst sign-off, a determined risk level, a treatment selection, an acceptance, or a refresh trigger is reproducible from one source, which is the audit trail the ISO 27001 certifier reads against
  • Finding overrides for the per-finding accepted-risk and false-positive entries that feed the risk acceptance record with the per-decision justification, the conditions of acceptance, and the reassessment triggers
  • Multi-factor authentication for workspace access so the analyst sign-off, the reviewer counter-signature, and the disposition approval the monitoring record reads against carry the authentication evidence the audit committee expects
  • Team management with RBAC so the risk owner role, the analyst role, the reviewer role, the accepting decision-maker role, and the asset owner role the 27005 process names are enforced at the workspace layer rather than at the per-document level
  • AI report generation that turns the per-cycle record into the audience-specific outputs the communication step expects: the operating narrative for the risk owner, the residual-position briefing for the executive sponsor, the per-risk acceptance pack for the audit committee, the methodology defence for the certifier, and the cross-clause linkage into the ISO 27001 audit pack
  • Retesting workflows paired to the modify treatment commitments arising from the assessment so the verify-after-fix evidence the next monitoring cycle reads against carries the closure record rather than a status statement that has drifted from the operating reality

What SecPortal does not do

SecPortal is the operating record an ISO 27005 programme is held on, not the analytical engine that produces quantitative outputs or the GRC platform that runs the wider risk register across enterprise risk categories. The workspace does not run a built-in Monte Carlo simulation engine, does not maintain a built-in threat intelligence catalogue, does not federate with asset inventory or CMDB systems, does not provide a packaged enterprise risk register editor with quantitative combination logic spanning operational, financial, and strategic risk categories, does not consume real-time CISA KEV or FIRST EPSS feeds through a packaged API, does not auto-route exception approvals through a workflow engine, and does not integrate with GRC platforms (Archer, ServiceNow GRC, Onspring, Hyperproof, OneTrust), ticketing systems (Jira, ServiceNow ITSM), SIEM, or SOAR platforms through packaged connectors. The discipline SecPortal supports is holding the per-cycle context, the per-scenario risk register, the treatment plan, the residual risk acceptance, the communication log, and the monitoring record as workspace evidence the methodology defence reads against; the analytical engine, the external intelligence feeds, and the wider enterprise risk register tooling belong to other systems the programme operates alongside SecPortal.

Related reading on SecPortal

  • ISO 27001 clauses 6.1.2 and 6.1.3 read against 27005-aligned assessments as the methodological satisfaction of the risk assessment and risk treatment process requirements.
  • ISO/IEC 27002 is the control catalogue the modify treatment selects from and the per-control rationale the Statement of Applicability records.
  • ISO 31000 is the enterprise risk management umbrella 27005 operates inside as the information-security-specific instantiation.
  • NIST SP 800-30 is the federal-side counterpart with deliberately compatible process structure and a similar risk factor decomposition.
  • NIST SP 800-37 (RMF) is the federal operating sequence parallel to ISO 27001 the 800-30 assessment feeds; 27005 plays the same role for the ISO programme.
  • FAIR (Factor Analysis of Information Risk) is the most common operationalisation of the quantitative path within 27005.
  • COSO ERM consumes 27005 outputs into the enterprise risk portfolio Principles 11 and 14 read against.
  • ISO/IEC 42001 extends the information security risk methodology to AI management systems with the AIMS process referencing 27005-style risk decomposition.
  • Cybersecurity risk assessment guide covers the wider risk assessment landscape, the methodology comparison, and the operating model that survives the second cycle.
  • Cyber risk quantification guide covers the quantitative path within 27005 and the FAIR adoption model that produces the board-readable financial output.
  • ISO 27001 audit checklist covers the ISMS audit preparation that consumes the 27005 evidence pack as the clause 6.1 satisfaction.
  • Security risk assessment template covers the working template structure programmes use to capture per-scenario 27005 entries in a way that survives the next refresh cycle.
  • Risk register template provides the workspace register the per-scenario 27005 entries land in for the per-cycle update and the per-residual-risk acceptance record.
  • Risk acceptance form template captures the residual risk acceptance record the 27005 risk acceptance step produces per retained risk.
  • Security leadership reporting workflow carries the audience-tailored communication outputs the recording and reporting activity produces for the executive sponsor, audit committee, and board audiences.
  • Vulnerability acceptance and exception management carries the per-finding accepted-risk record the 27005 risk acceptance step consumes into the residual risk acceptance evidence.
  • Control mapping cross-framework crosswalks carries the per-assessment cross-framework reference that lets 27005 outputs feed parallel framework reads without rebuilding the underlying input set.
  • Audit fieldwork evidence request fulfillment carries the certifier read against the per-cycle artefact set during ISO 27001, SOC 2, and regulator-side examinations.
  • Asset criticality scoring carries the per-asset criticality input feeding the consequence factor 27005 assessments read against.
  • Threat-intelligence-driven prioritisation carries the threat source characterisation input feeding the likelihood factor 27005 assessments read against.
  • SecPortal for GRC and compliance teams covers the GRC workspace that holds the cross-framework reconciliation 27005 outputs consume into.
  • SecPortal for CISOs covers the executive workspace that holds the 27005 programme alongside the operating record the assessments read against.

Key control areas

SecPortal helps you track and manage compliance across these domains.

Context establishment: the scope, criteria, and risk owner record

Context establishment defines the external and internal context, the scope and boundaries of the risk management, the risk criteria (risk acceptance criteria, the impact and likelihood scales, the risk evaluation criteria), and the organisation for the risk management. The output is the documented context the rest of the process reads against. ISO 27005 explicitly aligns the context step with the ISO 31000 process, and the criteria step produces the same artefacts ISO 27001 clause 6.1.2 requires.

Risk identification: event-based and asset-based approaches

ISO/IEC 27005:2022 catalogues two complementary identification approaches. The event-based approach identifies risk scenarios from threat-source intelligence, incident history, and strategic context, then traces each scenario to the assets it affects. The asset-based approach identifies primary assets (business processes, information), supporting assets (hardware, software, network, personnel, site, structure), the threats per asset, the vulnerabilities per asset, and the existing controls. Programmes typically run both approaches against the same scope and reconcile the resulting risk set.

Risk analysis: assessing consequence and likelihood

Risk analysis comprehends the nature of risk and determines the level of risk. The standard supports qualitative, semi-quantitative, and quantitative analytical approaches, with the assessment plan in context establishment naming the approach chosen. Per-risk analysis produces the consequence assessment (the harm if the risk materialises), the likelihood assessment (the probability the risk materialises given existing controls and predisposing conditions), and the level-of-risk determination as a combination of consequence and likelihood. The decomposition lets decision-makers push back on specific inputs rather than on the headline number.

Risk evaluation: comparing against criteria

Risk evaluation compares the analysed risk level against the risk evaluation criteria established during context establishment. The output is the prioritised risk set that feeds risk treatment. Risks above the evaluation threshold proceed to treatment; risks at or below the threshold proceed to acceptance with the rationale recorded. The evaluation reads the consequence and likelihood factors separately so the treatment choice in the next step targets the dominant driver rather than the composite score.

Risk treatment: modify, retain, avoid, share

ISO/IEC 27005:2022 catalogues four treatment options. Modify (apply, change, or remove controls so the risk falls within tolerance) is the most common path and feeds the ISO 27001 Statement of Applicability (the SoA records the controls selected from Annex A and the controls excluded with justification). Retain (accept the risk by informed decision) feeds the residual risk acceptance record. Avoid (do not start or discontinue the activity that gives rise to the risk) feeds the architecture and product decision record. Share (transfer or share with another party) feeds the insurance, contractual, or partnership record. Treatment is iterative: residual risk re-enters analysis until it falls within the acceptance criteria.

Risk acceptance: the residual risk decision record

Risk acceptance produces the named acceptance record per residual risk. The acceptance names the risk, the residual risk level after treatment, the risk owner, the accepting decision-maker, the justification, the conditions under which acceptance applies, the review cadence, and the conditions that trigger reassessment. ISO 27005 is explicit that acceptance is a documented decision, not an absence of evidence. The acceptance record reads cleanly into the ISO 27001 risk treatment plan and is the artefact the certifier reads against during the certification audit.

Communication and consultation: a continuous activity

Communication and consultation runs alongside every process step. The activity engages stakeholders (the risk owner, the asset owner, the affected business unit, the legal function, the audit function, the regulator-facing function, the executive sponsor) in the risk dialogue, gathers their perspective into the analysis, and communicates the per-cycle output. Programmes that compress communication into a single end-of-cycle report miss the methodology value: the consultation surfaces inputs the analyst could not have produced alone, and the communication produces the per-audience decision evidence the audit reads against.

Recording and reporting: the per-cycle artefact set

Recording and reporting produces the documented evidence the standard expects per cycle. The recording covers the context establishment record, the risk identification output, the risk analysis output, the risk evaluation output, the risk treatment plan, the residual risk acceptance, the communication and consultation log, and the monitoring and review record. Reporting tailors the same evidence per audience: the risk owner reads the operating detail, the executive sponsor reads the residual position, the audit committee reads the per-risk acceptance evidence, the certifier reads the methodology defence and the cross-clause linkage.

Monitoring and review: when to reassess

Monitoring and review provides the per-cycle re-read against the changed context, the new threat intelligence, the updated vulnerability state, the residual risk position, and the treatment effectiveness. The standard names the reassessment triggers: scope changes, new or changed assets, new threats or threat actors, new vulnerabilities or control effectiveness changes, incidents, exception additions or expirations, regulatory changes, and the periodic refresh cadence. The monitoring record is the operating audit trail the next certification cycle reads against.

Risk scenario: the central methodological unit

ISO/IEC 27005:2022 organises identification, analysis, evaluation, and treatment around the risk scenario. A scenario describes a sequence of events that combines a threat source, a threat event, the assets affected, the vulnerabilities exploited, the predisposing conditions, the consequence, and the likelihood. The scenario is the unit decision-makers read against; the catalogue of scenarios per scope is the working artefact the methodology builds, refreshes, and reports on. Programmes that report aggregate risk scores without the underlying scenario set lose the explanatory power the standard exists to produce.

Threat and vulnerability catalogues

ISO/IEC 27005:2022 Annexes provide example threat and vulnerability catalogues programmes use as the starting point for the per-scope assessment. The threat catalogue covers human deliberate, human accidental, environmental, technical, and external categories. The vulnerability catalogue covers organisational, process, personnel, physical, technical, communication, and dependence-on-third-party categories. The catalogues are reference material; the per-scope assessment tailors them to the actual environment and adds the scope-specific entries the standard catalogues do not anticipate.

Risk criteria: written before the analysis

The risk acceptance criteria, the impact scale, the likelihood scale, and the evaluation criteria are written during context establishment and applied unchanged across the assessment. Programmes that write criteria after running the analysis tend to fit the criteria to the result. The criteria are revisited per cycle in monitoring and review, but the per-cycle assessment reads against the criteria established at the start of the cycle. The criteria record is one of the artefacts the certifier asks for first.

Audit evidence ISO/IEC 27005 expects

A defensible 27005 programme produces a stable evidence set per cycle: the context establishment record covering scope, internal and external context, risk criteria, and organisation for risk management; the per-scenario risk register with the threat source, threat event, asset, vulnerability, predisposing condition, consequence, likelihood, level of risk, treatment, residual risk, and acceptance entries; the threat catalogue and vulnerability catalogue per scope; the risk treatment plan with per-action owner, control selection, milestone, and effectiveness measure; the residual risk acceptance record per retained risk; the communication and consultation log per cycle; the monitoring and review record per cycle; the per-cycle change log against the prior cycle. The same evidence reads cleanly into ISO 27001 clause 6.1.2 (risk assessment), clause 6.1.3 (risk treatment), the Statement of Applicability, the residual risk acceptance, and the supplier evidence the certifier audits.

Related features

Orchestrate every security engagement from start to finish

Vulnerability management software that tracks every finding

Compliance tracking without a full GRC platform

Test web apps behind the login

Vulnerability scanning tools that map your attack surface

Find vulnerabilities before they ship

Document management for every security engagement

Every action recorded across the workspace

AI-powered reports in seconds, not days

Collaborate across your entire team

Multi-factor authentication on every workspace

Finding overrides that survive every scan cycle

Verify fixes and track reopens on the same finding record

Run a defensible ISO/IEC 27005 programme on one operating record

Hold the context, the per-scenario risk register, the treatment plan, the residual risk acceptance, the communication log, and the monitoring record on one workspace so the 27005 evidence reads cleanly into ISO 27001 clause 6.1.2 and 6.1.3, the Statement of Applicability, and the certification audit without rebuilding the underlying input set. Start free.

Get Started Free

No credit card required. Free plan available forever.