ISO 27005:2022

Clause 6 relates the organisation's context, interested parties and ISMS scope (ISO/IEC 27001:2022 4.1 to 4.3) and the risk criteria and method (6.1.2 a) and b)) to information security risk management; sub-clauses 6.1 to 6.5.

The organisation in ISMS terms is whoever has its own functions, responsibilities, authorities and relationships to reach its objectives; it need not be a company or legal entity and can be part of one, such as an IT department. Risk appetite, the amount of risk the organisation will pursue or accept, differs widely between organisations with factors such as size, complexity and sector, and top management sets it and reviews it regularly. The role of risk owner is defined in terms of managing the identified risks, and risk owners hold fitting accountability and authority for them.

• Top management statement of risk appetite with review date
• Definition of the risk owner role and its authority

• Risk appetite never set by top management
• Risk owners named without authority over the risk

The organisation identifies what its relevant interested parties fundamentally require, together with the organisation's current compliance with them, including every reference document that sets security rules and controls applying within the assessment's scope, for example: the reference control set given in Annex A to ISO/IEC 27001:2022; further ISMS standards; sector standards such as financial or healthcare ones; applicable international or national regulation; internal security rules; security rules and controls in contracts or agreements; and controls put in place by earlier risk treatment. Any shortfall against these requirements is explained and justified, and the requirements with their compliance status feed the likelihood assessment and the risk treatment.

• Register of interested-party requirements and applicable security reference documents
• Compliance status with justification for each gap

• Contractual security obligations missing from the requirements register
• Compliance gaps not fed into likelihood assessment

Risk assessments can sit inside many processes (project, vulnerability, incident or problem management) or be done ad hoc on a particular topic, but taken together they cover every issue relevant to the organisation within the ISMS scope. They support decisions on managing the risks to the organisation's objectives and so focus on the risks and controls whose good management most improves the chance of meeting those objectives; ISO/IEC 27003 says more on the ISMS context.

• Map of where risk assessments are performed across processes against ISMS scope
• Evidence that the combined assessments cover all in-scope issues

• Risk assessments scattered across projects with no view of scope coverage

Grouping clause for the risk criteria that ISO/IEC 27001:2022 6.1.2 a) requires: general considerations (6.4.1), risk acceptance criteria (6.4.2) and the criteria for performing assessments (6.4.3, with consequence, likelihood and level-of-risk criteria).

ISO/IEC 27001 requires risk criteria (the terms against which significance is judged and decisions made), made up of the criteria for accepting risk and the criteria used when carrying out assessments. In setting them the organisation weighs: the nature and kinds of uncertainty, tangible and intangible, that can affect outcomes and objectives; the way consequence and likelihood are defined, forecast and measured; factors to do with time; using measurements consistently; the method for arriving at a level of risk; how combinations and sequences of several risks are handled; and its own capacity. Annex A gives further considerations.

• Documented risk criteria covering acceptance and assessment criteria
• Rationale showing the seven considerations were addressed

• Criteria silent on how combined or sequential risks are treated
• No definition of how consequence and likelihood are measured

Acceptance criteria decide in evaluation whether a risk is acceptable and in treatment whether a proposed treatment is enough or more is needed, and the organisation defines levels of acceptance. In building them it considers: alignment with its general risk acceptance criteria; which management level holds delegated authority to accept; that there can be several thresholds with acceptance authority at different levels; that criteria can rest on likelihood and consequence alone or also weigh the cost of controls against prospective loss; that different classes of risk can have different criteria (risks of legal non-compliance may not be retainable, while contractually required acceptance may be allowed); that criteria can allow future treatment, retaining a risk above threshold for a short time when there is approved commitment to controls within a set period; that criteria derive from r

• Approved risk acceptance criteria with thresholds and delegated acceptance authorities
• Rules for time-limited acceptance pending treatment
• Evidence of review after context change

• Acceptance based on a single risk score with no threshold for extreme consequences
• Acceptance authority not tied to management level
• Criteria not linked to stated risk appetite

Criteria for performing assessments (ISO/IEC 27001:2022 6.1.2 a) 2)): general considerations (6.4.3.1), consequence criteria (6.4.3.2), likelihood criteria (6.4.3.3) and criteria for the level of risk (6.4.3.4). Split into its four titled sub-clauses on 2026-09-25 when the complete text showed them.

Assessment criteria say how a risk's significance is judged through its consequences, likelihood and level, and take account of how appropriate the risk management activities are, considering: the classification level of the information; its quantity and any concentration; how strategically valuable the business processes using it are; the criticality of the information and related assets; the operational and business weight of availability, confidentiality and integrity; what interested parties such as top management expect and perceive; negative consequences such as lost goodwill and reputation; and consistency with organisational risk criteria. The criteria, or a formal footing from which they are defined, are made uniform across all kinds of assessment so risks from different business domains can be communicated, compared and aggregated; they typically cover consequences, likelihood

• Standard risk assessment criteria applied across business domains
• Evidence the eight considerations shaped the criteria

• Each department uses its own scales so risks cannot be compared or aggregated

Consequence criteria express the extent of damage, loss or harm to the organisation or individuals when in-scope information loses its confidentiality, integrity or availability, with particular regard to: loss of life or harm to people or groups; loss of freedom, dignity or privacy; loss of staff and intellectual capital; disrupted internal or third-party operations; effects on plans and deadlines; loss of business or financial value; reduced market share or competitive advantage; harm to reputation or to public trust; failure to meet legal, statutory or regulatory requirements; failure to honour contracts or service levels; adverse effects on interested parties; and harm to the environment or pollution. The organisation settles how many consequence categories there are, how each is defined and what belongs in it, fitted to its context. A monetary scale can be bounded by the largest ann

• Consequence scale with defined categories covering the twelve consequence types
• Mapping of departmental consequence expressions to a common anchor scale

• Consequence scale limited to financial loss, ignoring harm to individuals or legal breach
• Categories undefined so assessors interpret them differently

Likelihood criteria depend on: accidental or natural events; how exposed the information or related asset is to the threat; how far the organisation's vulnerability is exploited; technology failure; and human acts or omissions. Likelihood can be stated as a probability of occurrence within a period or as a frequency (average number of occurrences in a period); frequency is easier to communicate but only probabilities can be aggregated. The criteria cover the range of likelihoods that can realistically be managed; beyond it, noting that a limit has been passed (an extreme case) is usually enough. Scales that are too wide quantise coarsely and cause error, especially at the top of exponential scales where steps are very large, and primary attention goes to risk sources whose likelihoods matter most in the organisation's context and ISMS scope.

• Likelihood scale stating probability or frequency bands and the five influencing aspects
• Treatment rule for likelihoods beyond the manageable range

• Frequency bands aggregated as if they were probabilities
• Scale so wide that most risks fall in one band

Level-of-risk scales help risk owners decide whether to retain or treat risks and in what order, and signal urgency. Depending on the case the inherent level (ignoring controls) or the current level (allowing for controls in place) is considered. A risk ranking is built from: the consequence and likelihood criteria; the effects security events can have at strategic, tactical and operational levels, on a consistent basis such as worst case; legal, regulatory and contractual obligations; and risks whose reach extends past the organisation's own scope, such as unexpected effects on third parties. The criteria can be qualitative (very high to low) or quantitative (expected monetary loss, loss of life or market share over time, such as annual loss expectancy). Either way, scales are anchored to a reference scale all interested parties understand, with analysis and evaluation periodically cali

• Risk level matrix or formula with defined, non-overlapping levels
• Calibration records against the reference scale
• Statement of whether inherent or current risk is rated

• Qualitative levels described subjectively and overlapping
• Inherent and current risk mixed within one register
• No periodic calibration of assessors

The information security risk approach and methods are aligned with those used for the organisation's other risks, and the choice is documented. Because ISO/IEC 27001:2022 6.1.2 b) requires repeated assessments to give consistent, valid and comparable results, the method ensures consistency (the same risks in the same context yield similar results whoever assesses them and whenever), comparability (criteria make equivalent levels of different risks come out comparably) and validity (results match reality as closely as possible). Operational risk management methods are the usual choice; the method may treat residual risk in any suitable way, the common practice being to assess likelihood and consequence on current risk.

• Documented risk assessment method with its alignment to enterprise risk methods
• Test of repeatability, e.g. two assessors on the same scenario

• Method undocumented or differing between assessment rounds
• No evidence results are consistent between assessors

Clause 7 gives the assessment process ISO/IEC 27001:2022 6.1.2 c) to e) requires: general (7.1), identification (7.2), analysis (7.3) and evaluation (7.4), each activity set out as input, action, trigger, output and implementation guidance.

The organisation uses its organisational risk assessment process where one exists, or defines an information security one. Assessment lets risk owners prioritise risks for treatment, mainly on consequence and likelihood or other set criteria. The assessment's context is fixed, with its scope and purpose and the internal and external issues bearing on it. It comprises identification (finding, recognising and describing risks, 7.2), analysis (understanding the kinds of risk and setting the level, considering causes and sources, the likelihood of an event, the likelihood that it has consequences and how severe they are, 7.3) and evaluation (comparing analysis with criteria to judge acceptability and prioritise for treatment, 7.4). The process rests on methods (6.5) and tools detailed enough for consistent, valid and reproducible results whose outcomes can be compared, for example to see whe

• Defined information security risk assessment process with scope, purpose and context
• Evidence of alignment with enterprise risk management

• Assessment context and scope undocumented
• Information security risks held in a separate register never compared with other risks

Identification of risks (7.2.1) and of their owners (7.2.2), for ISO/IEC 27001:2022 6.1.2 c).

Input: events, inside the organisation or beyond it, that could stand in the way of its information security objectives. Action: identify risks tied to loss of confidentiality, integrity and availability. Trigger: risk owners, interested parties or experts detect or seek new or changed events or situations. Output: a list of identified risks. Identification finds risk sources and events and lists the risks that could prevent, affect or delay the objectives. Two common approaches: event-based, building strategic scenarios from risk sources and the ways they exploit or act on interested parties to achieve what they want, drawing on top management's concerns, risk owners and the context of 27001 clause 4, often through interviews that also reveal risk owners, quick to reach critical risks and able to use historical data or, where data are lacking, expert judgement; and asset-based, building

• Risk register listing identified risks with sources, events and the approach used (event or asset based)
• Asset inventory with primary and supporting assets where the asset-based approach is used
• Records of iterative identification for complex scenarios

• Risks aggregated so broadly that controls cannot be tied to them
• Risks from sources outside the organisation's control omitted
• Asset list compiled but not linked to threats and vulnerabilities

Input: the list of identified risks. Action: assign each risk to a risk owner. Trigger: it has not been done, or personnel change in the business area where the risks sit. Output: risk owners with their risks. Owners can be top management, the security committee, process, functional or asset owners, or department managers. The organisational process is used where it exists; otherwise the organisation sets criteria ensuring owners are accountable for and have authority over their risks, with a position that lets them actually use it, and understand the issues well enough to decide, for example on treatment. The level of risk and the asset concerned can guide the choice, and allocation happens within the assessment process.

• Risk register with a named owner per risk
• Criteria used to choose risk owners

• Risk owner defaulted to the security team for every risk
• Owners not updated after organisational change

Analysis of risks to set their level (ISO/IEC 27001:2022 6.1.2 d)): general (7.3.1), consequences (7.3.2), likelihood (7.3.3) and level of risk (7.3.4).

Analysis sets the level of each risk. under ISO/IEC 27001:2022 6.1.2 every identified risk has its consequences and likelihood assessed to arrive at a level, with ISO 31000 as the general model. Techniques are qualitative (attribute scales such as high, medium, low), quantitative (numerical scales such as cost, frequency or probability) or semiquantitative (qualitative scales with assigned values). Analysis concentrates on the risks and controls whose successful management most improves the chance of meeting objectives; because estimating likelihood and consequence can absorb much time, rough initial estimates may be enough for efficient decisions.

• Stated analysis technique (qualitative, quantitative or semiquantitative)
• Level of risk recorded for every identified risk

• Analysis effort spread evenly instead of on the risks that matter
• Technique changed between assessments without explanation

Input: the relevant event or risk scenarios with their risk sources, the business processes and objectives, the consequence criteria, and the controls already in place with how effective, implemented and used they are. Action: identify and assess the consequences of failing to preserve confidentiality, integrity or availability. Trigger: not done before; the identified risk list changes; risk owners or interested parties change the units they want consequences in; or scope or context changes affect consequences. Output: potential consequences per risk scenario, tied to assets or events according to the approach. Losing confidentiality, integrity or availability may cause knock-on effects on the organisation and its objectives, and the analysis can work upward from those losses; typically the risk owner estimates the consequence, taking into account the time or data lost through interrupt

• Consequence assessment per risk scenario with the basis for each rating
• Recovery cost and downtime estimates from risk owners

• Consequences rated without considering existing controls
• Recovery costs ignored in consequence estimates

Input: the scenarios with risk sources, business processes and objectives, likelihood criteria and the existing controls' effectiveness and status. Action: assess the likelihood of possible or actual scenarios on the established criteria. Trigger: not done before; scope or context changes; vulnerabilities found in implemented controls; unexpected control test or audit results; or changes in the threat environment such as new actors. Output: scenarios with their likelihoods. Likelihood reflects how often risk sources arise or how easily weaknesses can be exploited, considering experience and statistics; for deliberate sources, attackers' motivation (such as cost-benefit), changing capability and resources, influences such as organised crime, terrorism or foreign intelligence, and how attractive and vulnerable the information looks; for accidental sources, geography (nearby hazardous sites

• Likelihood rating per scenario with its rationale and sources
• Record of team assessment or external data used
• Identification of dependent and independent events in each scenario

• Likelihood estimated by one person on intuition
• Vague categories such as 'unlikely' with no defined frequency
• Dependent events double-counted

Input: the scenarios with their consequences, tied to assets or events, and their likelihoods. Action: set the level of risk by combining assessed likelihood and consequence for every relevant scenario. Trigger: the risks are to be evaluated. Output: the risks with level values. Combination is the common method, but calculations may also bring in asset value and need not be linear (likelihood squared with consequence, for example); in every case the criteria of 6.4.3.4 apply.

• Risk register with calculated risk levels and the method used

• Risk levels calculated inconsistently with the documented criteria

Evaluation of analysed risks (ISO/IEC 27001:2022 6.1.2 e)): comparison with criteria (7.4.1) and prioritisation for treatment (7.4.2).

Input: the risk criteria and the risks with levels. Action: compare levels with evaluation criteria, especially acceptance criteria. Trigger: risks are to be prioritised for treatment. Output: suggested decisions on further action. Acceptance criteria decide whether each risk can be accepted, and those that cannot are prioritised for treatment, by comparison with the criteria set at context establishment and ideally allowing for confidence in the assessment. For frequent low-consequence events the cumulative effect over a relevant period can give a truer picture than each event alone. Because a single cut-off is not always right, flexibility can be added through parameters such as the cost and effectiveness of possible controls. Levels can be confirmed by agreement between risk owners and specialists from the business and technical sides, and any gap between assessed levels and owners' p

• Evaluation record comparing each risk with acceptance criteria and the resulting decision
• Investigation notes where owners disputed assessed levels

• Acceptance decisions made without reference to documented criteria
• Cumulative effect of frequent minor events ignored

Input: the risks as compared with the criteria. Action: prioritise the risks for treatment by their assessed levels. Trigger: the risks are to be treated. Output: prioritised risks with the scenarios leading to them. Evaluation turns the analysis into proposals on whether treatment is needed and on treatment priority by level; the criteria used take account of the organisation's objectives, contractual, legal and regulatory requirements and relevant interested parties' views, prioritisation resting mainly on the acceptance criteria.

• Prioritised risk list for treatment with linked scenarios

• Treatment order driven by ease of fix rather than risk level

The process of Figure 1 follows the generic ISO 31000 model and can loop through assessment and treatment. Each pass of the assessment can go deeper, which balances the effort of finding controls against assessing risks properly. Context establishment gathers the internal and external context for the risk management or for a given assessment. At the first decision point, if the assessment yields enough to settle how risks can be brought within acceptable bounds, the organisation moves on to treatment; if not it runs another pass, perhaps with a changed scope, more specialist input or other ways of getting the missing information. Treatment itself loops: formulate and choose options, plan and implement, check how effective the treatment was, decide whether what remains is acceptable, and treat further if it is not. If residual risk is still unacceptable (the second decision point), the or

• Documented risk management process showing assessment and treatment iterations and decision points
• Records of reassessment when information was insufficient or residual risk unacceptable

• Single-pass assessment with no mechanism to iterate when treatment fails to reach acceptable risk

Assessment and treatment are refreshed regularly and whenever things change, organised in two cycles. The strategic cycle responds to shifts in the organisation's overall context (its business assets, the threats and sources of risk it faces, the objectives it targets, and what security events would cost it) and can prompt a broad update of assessments and treatments or wholly new assessments; it runs over longer intervals or on major change. The operational cycle uses those elements, or changed criteria, to review and update the scenarios of individual assessments together with their treatment, over shorter intervals set by the detailed risks involved. The strategic cycle concerns the environment in which objectives are pursued, the operational cycle every assessment within the risk management context, and either can contain many assessments with differing context and scope.

• Schedule of strategic and operational risk reviews
• Trigger list for reassessment on major change

• Risk assessment refreshed only annually regardless of change
• No distinction between enterprise-level and system-level review cadence

Clause 8 covers risk treatment (ISO/IEC 27001:2022 6.1.3 a) to f)): general (8.1), options (8.2), necessary controls (8.3), comparison with Annex A (8.4), the Statement of Applicability (8.5) and the treatment plan (8.6).

Treatment starts from the prioritised set of risks the assessment produced against the risk criteria and yields the necessary controls (27001:2022 6.1.3 b)), deployed or strengthened in relation to one another under the risk treatment plan (6.1.3 e)), whose effect is to bring the information security risk the organisation faces within its acceptance criteria.

• Risk treatment process linking prioritised risks to necessary controls and the treatment plan

• Treatment started from a control catalogue instead of the prioritised risks

Input: prioritised risks with the scenarios leading to them. Action: choose treatment options. Trigger: no treatment plan exists or it is incomplete. Output: prioritised risks with their chosen options. Options include avoidance (not starting or stopping the activity that creates the risk, for example closing an office in a flood zone where physical controls cannot suffice, or not collecting certain personal information at all), modification (changing likelihood or the severity of consequences), retention by informed choice, and sharing (splitting responsibility with other parties internally or externally, such as insurance), where at least one control still modifies the risk but another party implements it. Options are chosen on the assessment outcome and the expected costs and benefits, singly and alongside other controls, and prioritised by risk level, time constraints, the sequence i

• Treatment option recorded per risk with cost-benefit rationale

• Retention chosen by default without an informed decision
• Risk sharing assumed to remove the need for any control

Input: prioritised risks with chosen options. Action: determine every control, from control sets chosen from suitable sources, needed to treat the risks under the chosen options (modify, retain, avoid, share). Trigger: ISMS conformity and managing information security risk. Output: all necessary controls. Each control is tested for necessity by asking what it does to the risk's likelihood or consequence and how it holds the risk level, and only controls with more than negligible effect count as necessary; every risk needing treatment gets at least one. Sources include 27001 Annex A, sector codes such as ISO/IEC 27017, other national, regional or industry sets, and custom controls (ISO/IEC 27003), whose wording should give a fair account of the control's nature and its operation, covering as relevant whether it is documented, its owner, monitoring, evidence, exceptions, frequency, toleran

• List of necessary controls traced to each treated risk with their effect on likelihood or consequence
• Custom control descriptions with owner, monitoring, evidence, frequency and tolerance
• For each risk, preventive, detective and corrective controls used together

• Existing controls copied into the risk assessment without a necessity test
• Controls with no traceable risk
• Detective controls with no one acting on their alerts

Input: all necessary controls (8.3). Action: compare them with the controls in 27001:2022 Annex A. Trigger: formulating treatment plans makes finding any missing controls necessary. Output: all controls applicable to treatment. The comparison 27001 6.1.3 c) requires is a safety check that no necessary control from any source was missed, not a hunt for Annex A controls absent from the assessment; missing controls found can be sector, custom or Annex A ones and are added following 8.3, never simply because they already operate. It is done risk by risk on the risk assessment, not on the Statement of Applicability.

• Record of the per-risk comparison against Annex A and any controls added
• Rationale for added controls under the 8.3 necessity test

• Annex A used as a checklist to add controls regardless of risk
• Comparison made against the SoA rather than the risk assessment

Input: all controls applicable to treatment (8.4). Action: produce the Statement of Applicability. Trigger: need to document the necessary controls, their justification and status. Output: the SoA. It contains at least the necessary controls, the justification for including them, whether they are implemented, and the justification for excluding Annex A controls. It is drawn from the risk assessment (necessary controls) and the treatment plan (controls planned); only controls identified in the assessment may appear, none can be added independently of it, and the SoA stays consistent with the controls the chosen options need. A single inclusion justification (found necessary in the risk assessment to reduce at least one risk to an acceptable level) can cover all controls, and status can be implemented, partially implemented or not implemented, per control or as one overall statement such a

• Statement of Applicability with necessary controls, inclusion and exclusion justification and implementation status
• Traceability from SoA entries to the risk assessment

• SoA lists controls not found in the risk assessment
• Exclusions of Annex A controls not justified

The treatment plan (ISO/IEC 27001:2022 6.1.3 e) and f)): its formulation (8.6.1), approval by risk owners (8.6.2) and acceptance of residual risks (8.6.3).

Input: assessment results. Action: formulate the plan. Trigger: the need to treat risks. Output: the risk treatment plan. Plans treat sets of the prioritised risks so they meet the acceptance criteria of 6.4.2, either as a project plan for implementing controls (of historical value once done) or as a design plan showing how controls interact with each other and their environment (lasting value), or both. Every risk needing treatment is covered by some plan, and several plans may be organised by where information resides, by asset class or by event. Planning weighs priority by risk level and urgency, the right balance between preventive, detective and corrective controls, whether one control must settle before another is added on the same asset, and any lag before a control is fully effective. Each treated risk's plan states the rationale for the options and their expected benefits, who a

• Risk treatment plan covering every risk requiring treatment, with owners, actions, resources, indicators, timing and status
• Implementation tracking per risk including testing of the result

• Plan lists controls but no owners, dates or performance indicators
• Some risks requiring treatment appear in no plan

Input: the treatment plans. Action: risk owners approve them. Trigger: the plans need approval. Output: approved plans. Once formulated, each plan is approved by the risk owners, who also decide on accepting the residual risks against the defined acceptance criteria; the assessment results, the plan and the remaining risks are made understandable enough for owners to discharge their accountability.

• Risk owner sign-off of each treatment plan
• Residual risk acceptance decisions referencing the criteria

• Plans approved by the security team instead of the risk owners

Input: approved plans and acceptance criteria. Action: decide whether residual risks are acceptable. Trigger: the organisation must decide on retaining residual risk. Output: accepted residual risks. Plans feed a later reassessment of the likelihood and consequence that remain, weighing how the proposed controls and their effectiveness reduce likelihood, consequence or both, and the owner judges the resulting level; plans describe how assessed risks will meet the criteria. Where criteria do not fit prevailing circumstances (a valuable business opportunity, or modification costing too much) and cannot be revised in time, owners may retain risks outside normal criteria, explicitly commenting and justifying the override. Acceptance may follow a chain of endorsements; owners review and approve plans and resulting residual risk and record any conditions, and some cases need a manager above th

• Residual risk acceptance records with justification for any override of normal criteria
• Conditions attached to acceptance and escalation to higher authority where required

• Residual risk accepted with no reassessment after controls
• Overrides of acceptance criteria without recorded justification

Clause 10 relates information security risk management to the other ISMS processes of ISO/IEC 27001:2022 (clauses 4, 5.1, 7.4, 7.5, 9.1, 9.3, 10.1 and 10.2).

Input: information on the organisation and its internal and external context. Action: consider all relevant data to identify and describe the internal and external issues and interested-party requirements affecting risk management. Trigger: 27001 requires it for setting security objectives. Output: risk-related issues influencing risk management. The organisation needs a strategic grasp of the issues that can help or hinder the ISMS and of the context bearing on its intended outcomes, preservation of confidentiality, integrity and availability through risk management. It gathers enough detail on its context, interested parties and their requirements (27001 4.1 and 4.2) before assessing any risk (6.1.1), considers all internal and external risk sources, including parties opposed to it such as attackers, whose aims it frustrates through effective controls, and covers in assessment the inte

• Context analysis of internal and external issues and interested parties used as input to risk assessment
• Identification of interfaces and dependencies outside the ISMS scope

• Context analysis performed after the risk assessment
• Outsourced functions and shared assets left out of the assessment

Input: assessment or treatment results needing approval or endorsement. Action: the appropriate management level reviews the results and decides on, or endorses, what happens next. Trigger: 27001 requires suitable management involvement in all risk-related activities. Output: risk decisions or endorsements. Accountability for managing risk rests with top management, which leads and drives assessments, including allocating the resources risk management needs, assigning authority, responsibility and accountability for it at the right levels, and communicating with the relevant interested parties.

• Management decisions or endorsements on risk results
• Allocation of risk management resources and responsibilities by top management

• Risk results never presented to top management
• No resources allocated to risk management

Input: what the risk processes found about risks, why they arise, what they would do and how likely they are. Action: communicate information on risks and the controls treating them to, or gather it from, internal and external interested parties. Trigger: 27001 requires such communication (7.4 covers its communication part). Output: interested parties' perceptions and continuing understanding of the process and results. The aim is agreement on managing risks through exchanging information with risk owners and others, covering whether risks exist and their nature, form, likelihood, consequences, significance, treatment and acceptance. Ownership can be deliberately blurred and owners reluctant, so a defined procedure informs people of their ownership; owners approve plans and accept residual risk, so two-way communication between them and ISMS staff matters. Sensitive risk information is s

• Risk communication plan for normal operations and emergencies
• Procedure for notifying risk ownership
• Records of consultation with interested parties on criteria and results

• Sensitive risk details published without need-to-know control
• No crisis communication arrangement with the communications unit

Documented information on the risk processes and results (ISO/IEC 27001:2022 7.5): general (10.4.1), processes (10.4.2) and results (10.4.3).

ISO/IEC 27001 requires documented information to be retained on the assessment process (6.1.2) and its results (8.2) and on the treatment process (6.1.3) and its results (8.3); 10.4.2 and 10.4.3 say what that information contains.

• Index of retained documented information for risk assessment and treatment processes and results

• Risk process documented but results not retained

Input: knowledge of the assessment and treatment processes the organisation defined under clauses 7 and 8. Action: document and retain information on them. Trigger: 27001 requires it. Output: what interested parties such as a certification body need, or what the organisation judges necessary for effective processes. For assessment it covers: the risk criteria (acceptance and assessment criteria); the reasoning for consistent, valid and comparable results; the identification method including how owners are identified; the analysis method (potential consequences, realistic likelihood, resulting level); and the method for comparing with criteria and prioritising for treatment. For treatment it describes how options are selected, how necessary controls are determined, how Annex A is used to check none was overlooked, how treatment plans are produced and how owners' approval is obtained.

• Documented risk assessment methodology covering the five elements
• Documented risk treatment methodology covering the five elements

• Methodology silent on how Annex A is used as a check
• No description of how risk owner approval is obtained

Input: assessment and treatment results. Action: document and retain them. Trigger: 27001 requires it. Output: documented results. Since assessments are due at planned intervals and on significant change, there is at least a schedule with evidence of assessments done to it, and for any proposed or actual change evidence of an assessment or an explanation of why the change is or is not significant. Assessment results record the identified risks with consequence and likelihood, the risk owners, the outcome of applying acceptance criteria and the treatment priority, with the rationale for risk decisions recommended for learning and improvement; treatment results record the necessary controls and, where available, evidence that they modify risk to meet the acceptance criteria.

• Risk assessment schedule and completed assessments
• Results records with risks, owners, acceptance outcome and priority
• Evidence that controls modify risk to meet criteria

• No evidence of assessment after a significant change
• Rationale for risk decisions not recorded

Monitoring and review of risk management (ISO/IEC 27001:2022 9.1): general (10.5.1) and the factors influencing risk (10.5.2).

Monitoring under 27001 9.1 covers every aspect of assessment and treatment in order to: keep treatments effective, efficient and economical in design and operation; gather information to improve later assessments; draw lessons from incidents and near misses, from changes and trends, and from what worked and what did not; detect changes in internal and external context, including in risk criteria and the risks themselves, that may call for revised treatments and priorities; and identify emerging risks. Retained risk scenarios can be turned into monitoring scenarios (Annex A.2.7).

• Monitoring programme covering the five purposes
• Monitoring scenarios derived from retained risks

• Monitoring limited to control status with no lessons from incidents or near misses

Input: all risk information from risk management. Action: keep risks, and the factors behind them, under monitoring and review (asset value, consequences, threats, vulnerabilities, likelihood) to spot contextual change early and keep the whole risk picture in view. Trigger: policy review or any detected change in the operating or threat environment. Output: management of risk kept aligned with business objectives and acceptance criteria. Treatment plans are used as a subject of the performance evaluation 27001 9.1 requires, starting from an information need (what top management wants to know, for example about its ability to defend against threats) and deriving the measurements and how to combine them. Because any of the scenarios, asset values, threats, weaknesses, likelihoods or consequences can shift without warning, monitoring is continual, helped by external threat and vulnerability

• Risk monitoring records covering the eight factor categories
• Performance measures derived from information needs on risk treatment
• Aggregate review of low and retained risks

• Retained risks never re-examined
• Threat intelligence not fed into risk review

Input: assessment results and the status of the treatment plan. Action: review them to confirm residual risks meet the acceptance criteria and that the plan covers every relevant risk with its treatment options. Trigger: the planned review calendar. Output: changes to the acceptance and assessment criteria and an updated treatment plan or Statement of Applicability.

• Management review minutes covering risk results and treatment plan status
• Resulting changes to criteria, treatment plan or SoA

• Management review agenda omits residual risk against acceptance criteria

Input: a treatment plan proving ineffective, residual risk set to stay unacceptable after completion. Action: rework the plan and carry it out so the residual risk becomes acceptable. Trigger: a decision that the plan must be reworked. Output: a revised plan and its implementation. Nonconformities on plan effectiveness can arise from internal or external audit or from monitoring and indicators, and the revision reflects the outcomes of treatment, progressive implementation (a control as specified, designed and built), and difficulties met in implementing controls (technical, financial, or clashes with internal or external considerations such as privacy). Even acceptable residual risk can be undermined where users reject or bypass controls they find awkward, overly complex or slow, and the effectiveness of the revised plan is reviewed.

• Corrective action records revising ineffective treatment plans
• Review of the revised plan's effectiveness

• Ineffective treatment left unchanged until the next annual assessment
• User workarounds of controls not treated as a nonconformity

Input: all risk information from risk management. Action: monitor, review and improve the risk management process as needed. Trigger: the wish to improve and mature from lessons learned. Output: a process that stays relevant to business objectives, or an updated one. Ongoing review keeps context, assessment and treatment outcomes and management plans suited to circumstances; agreed improvements or actions to improve compliance with the process are notified to responsible managers, who are assured no risk is missed or understated and that decisions give a realistic understanding and ability to respond. Change management feeds the risk process continually so changes to information systems that could modify risk are picked up, even altering assessment activities. The criteria used to measure risk are verified regularly against business objectives, strategies, policies and changes in busines

• Improvement actions on the risk process notified to responsible managers
• Periodic verification of risk criteria against business objectives
• Link from change management into risk assessment

• Risk criteria never re-validated after business change
• Changes to information systems bypass risk assessment

Clause 9 corresponds to clause 8.2 and clause 8.3 in ISO/IEC 27001:2022: performing the assessment (9.1) and treatment (9.2) processes in operation.

Input: documents on the assessment process, including assessment and acceptance criteria. Action: perform assessment per clause 7. Trigger: planned intervals or events. Output: evaluated risks. The process defined under 27001 6.1 is embedded in operations and run at intervals suited to the ISMS and when significant change is proposed or occurs, using the 6.1.2 a) criteria; after a significant change to the ISMS, its context or the threat landscape (a new kind of attack), the organisation decides whether an extra assessment is needed. Routine assessments follow business and budget calendars: where funding requests and procurement cycles apply, assessments are scheduled to produce treatment recommendations in time for funding, to be reassessed once budgets are allocated, and to come round again after recommendations are implemented following procurement.

• Risk assessment schedule aligned with budget cycles
• Records of assessments triggered by significant change

• Assessments run on a fixed date regardless of change or funding cycle
• No decision recorded on whether a major change needed reassessment

Input: evaluated risks. Action: perform treatment per clause 8. Trigger: planned intervals or events. Output: residual risks that are accepted or retained. 27001:2022 8.3 requires the treatment plans to be implemented, and the considerations of 8.6 apply here too.

• Evidence of treatment plan implementation and resulting residual risk

• Treatment plans approved but never implemented

Seventeen defined terms, most taken or adapted from ISO 31000:2018 and ISO Guide 73: external and internal context (each with a list of what it can include), risk, meaning the effect that uncertainty has on objectives (for information security usually the negative effect, associated with threats exploiting vulnerabilities of information assets), risk scenario (a chain of events from initial cause to unwanted consequence, from ISO 17666), risk owner, risk source (human, intentional or not, environmental or technical), risk criteria, risk appetite, threat, vulnerability, event, information security incident, likelihood, consequence, level of risk, control and residual risk. Terms, not guidance.

Ten defined terms: risk management process; risk communication and consultation (consultation influences a decision but is not joint decision making); risk assessment and its three steps (identification, analysis and evaluation of risk, each defined separately); risk treatment (its seven forms, noting that taking on risk to pursue an opportunity is outside information security risk treatment), risk acceptance, risk sharing (of which risk transfer is one form) and risk retention (temporary, and including acceptance of residual risk). Terms, not guidance.

ISO/IEC 27005:2022, Information security, cybersecurity and privacy protection: Guidance on managing information security risks (fourth edition, October 2022, ISO/IEC JTC 1/SC 27; replaces the 2018 third edition, itself after 2011 and the 2008 first edition). It guides organisations in meeting the ISO/IEC 27001 requirements on actions to address information security risks and in carrying out risk assessment and treatment, for any organisation whatever its type, size or sector; its one normative reference is ISO/IEC 27000. The fourth edition brought all guidance into line, in terminology and clause layout, with ISO 31000:2018 and ISO/IEC 27001:2022, introduced risk scenarios, contrasted the event-based with the asset-based approach, and folded the annexes into one. Clause 4 explains that each activity in clauses 7 to 10 is set out as input, action, trigger, output and guidance, and most s