The risk register other people trust

One information security risk register · Risk and ISMS owners in a regulated organisation · An approved ISMS scope and a standing management forum · First reviewed register in four weeks

1. Why this exists (the failure mode it prevents)#

Most registers fail in the same place. Not in the tooling and not in the scoring, but in the sentence. A row that reads "lack of multi-factor authentication" names a missing control, not a risk. No one can own a gap, accept a gap, or say what the organisation loses if the gap stays open. The row is coloured red and left alone.

The second failure is the unmade decision. A register of a hundred rows with no acceptance dates is a list of worries with a spreadsheet around it. ISO/IEC 27005:2022 gives the two closing acts their own subclauses, 8.6.2 Approval by risk owners and 8.6.3 Acceptance of the residual information security risks ¹. An assessor who finds a high-level row with neither has a governance finding.

The third failure is currency. A register frozen on the day of certification tells the reader what was true then. ISO/IEC 27001:2022 asks for assessment and treatment to be performed as operational activities, under 8.2 Information security risk assessment and 8.3 Information security risk treatment ². A register with no review dates cannot show that either happened.

This playbook builds the version people outside security will sign: statements they recognise, scales they helped set, and decisions with a name and a date on them.

2. Definitions (only the ones that cause disputes)#

Term	Working definition	Source
Risk source	What can give rise to the risk, alone or combined with something else. The standard sorts sources into human, environmental and technical, and a human source can act deliberately or by accident.	ISO/IEC 27005:2022, 3.1.6 [3](#grcide-source-3)
Event	An occurrence, or a change in a set of circumstances. Something expected that fails to happen counts too.	ISO/IEC 27005:2022, 3.1.11 [3](#grcide-source-3)
Likelihood	The chance of something happening, expressed in words or in numbers. The standard is explicit that the term is broader than the mathematical reading of "probability".	ISO/IEC 27005:2022, 3.1.13 [3](#grcide-source-3)
Level of risk	The significance of a risk, expressed as the combination of its consequences and their likelihood. "Combination" is the operative word: multiplication is not prescribed.	ISO/IEC 27005:2022, 3.1.15 [3](#grcide-source-3)
Risk owner	The person or entity holding both the accountability and the authority to manage the risk. Two tests, not one.	ISO/IEC 27005:2022, 3.1.5 [3](#grcide-source-3)
Risk acceptance	An informed decision to take a particular risk, with or without treatment. Accepted risks stay under monitoring.	ISO/IEC 27005:2022, 3.2.8 [3](#grcide-source-3)

"Inherent risk" is worth naming as a house convention rather than a standard term. The standard defines residual risk, the risk remaining after treatment (3.1.17), but has no matching term for the level before controls ¹. Keep the column if it is useful, and write down what it means. "Gross" and "net" are the same convention under other names.

3. The method — numbered steps, each with: input → activity → output → owner#

3.1 Set the criteria before the first risk#

• Input: the approved ISMS scope, the organisation's objectives, and the obligations that bind it.
• Activity: write the consequence scale, the likelihood scale, the rule that combines them, and the acceptance criteria. Take them to the management forum for approval, as a decision rather than as information.
• Output: Risk criteria statement, versioned, one page.
• Owner: the management forum accountable for the ISMS; drafted by the risk or ISMS manager.

ISO/IEC 27005:2022 puts criteria first for a reason. Clause 6.4 is Establishing and maintaining information security risk criteria. It splits into 6.4.2 Risk acceptance criteria and 6.4.3 Criteria for performing information security risk assessments. The subclauses under 6.4.3 are 6.4.3.2 Consequence criteria, 6.4.3.3 Likelihood criteria and 6.4.3.4 Criteria for determining the level of risk ¹. ISO 31000:2018 says the same in one subclause, 6.3.4 Defining risk criteria ⁴. A register scored against unwritten criteria cannot be defended: the scores mean whatever the last person in the room thought they meant.

3.2 Choose the approach, then the method#

• Input: the criteria statement, the asset inventory or the objective set, and the time available.
• Activity: decide whether this cycle identifies risks from assets or from risk sources and events, and record which. Pick the analysis method and record that too.
• Output: a paragraph on the register's Read first sheet, saying which approach was used and why.
• Owner: the risk or ISMS manager.

ISO/IEC 27005:2022 sets out both routes and contrasts them: A.2.4 is the Event-based approach and A.2.5 the Asset-based approach, and 6.5 is Choosing an appropriate method ¹. The asset-based route finds detail and misses strategy. The event-based route finds the scenarios a board worries about and misses configuration-level exposure. Most organisations need one of each per year, not a permanent choice.

3.3 Write risk statements in one grammar#

• Input: workshop output in whatever form it arrived, usually a wall of half-sentences.
• Activity: rewrite every candidate as source → event → consequence → affected asset or objective. Reject anything that stops at a missing control.
• Output: a candidate list where every line is a sentence a business reader can judge.
• Owner: the facilitator, with the proposed risk owner in the room.

The grammar is not a house style. It follows the standard's own vocabulary, in which a risk scenario is the sequence from initial cause to unwanted consequence (3.1.4). Clause 7.2.1 is Identifying and describing information security risks ¹. "Lack of multi-factor authentication" becomes "an attacker using bought credentials signs in to the customer portal and exports personal data belonging to portal users". The first version has one possible response. The second can be argued about, scored, owned and closed.

Three tests catch most bad statements. Can it happen more than once, in more than one way? Does it name what is lost, in terms the objective owner uses? Would it survive the control being implemented tomorrow? A statement that disappears the moment a control appears was never a statement of risk.

3.4 Name the risk owner while the risk is still on the wall#

• Input: the candidate list, and the organisation chart for the affected objectives.
• Activity: ask, for each row, who has both the accountability for the objective and the authority to spend against it. Write that role in the row. Get the person to read their own row aloud.
• Output: register rows with a named risk owner, and a short list of rows nobody would take.
• Owner: the facilitator; escalation to the management forum for orphaned rows.

ISO/IEC 27005:2022 makes this a step in its own right, 7.2.2 Identifying risk owners ¹. ISO 31000:2018 puts the same obligation at framework level, in 5.4.3 Assigning organizational roles, authorities, responsibilities and accountabilities ⁴.

Three roles get confused, and separating them is most of the value of this step. The risk owner carries the consequence and takes the treatment-or-acceptance decision, and is almost never the security function, which does not own the business objective. The control owner runs the control and reports whether it works. The register keeper maintains the artefact, chases reviews and prepares the reporting. A register where all three columns hold the same name is one the business has not accepted.

3.5 Analyse: consequence, then likelihood, then level#

• Input: approved scales, the statement list, and evidence of what already exists.
• Activity: score consequence against the anchored descriptors first, then likelihood, then read the level off the published combination rule. Record the evidence used for each score in the row.
• Output: scored rows with an inherent level, existing controls, and a residual level.
• Owner: the risk owner, advised by the control owner.

The standard separates the three acts: 7.3.2 Assessing potential consequences, 7.3.3 Assessing likelihood and 7.3.4 Determining the levels of risk ¹. Score consequence before likelihood. Groups that start with likelihood anchor on how often something happens and then inflate the damage to justify the attention.

Anchored descriptors, not adjectives. "Medium" is not a scale point. A scale point is a sentence a non-specialist can test against a real situation. Anchor each consequence level on three axes at once, an information axis, a regulatory and financial axis and an operational axis, and rule that the highest of the three sets the value. Anchor likelihood on observed frequency, here and in the sector, not on how worried the room feels.

Qualitative or semi-quantitative. ISO/IEC 27005:2022 offers both, in A.1.1.2 Qualitative approach and A.1.1.3 Quantitative approach ¹. Qualitative bands are the working default: fast, and honest about the precision available. The useful middle is to require a semi-quantitative estimate only for rows reaching the top two bands, stated as a loss range and a frequency range. That gives a finance function numbers to argue with, at a cost the organisation can afford.

Why the five-by-five heat map misleads. Three problems, all fixable. First, the scores are ranks, so multiplying them asserts arithmetic the scale does not carry. Likelihood 4 with consequence 2 and likelihood 2 with consequence 4 both give eight, and they are not the same decision. Second, the top band compresses two orders of magnitude into one square, so everything severe looks equally severe. Third, colour ties unrelated rows together, and a queue of forty amber items is not a priority order.

The fixes are cheap. Publish the combination as a lookup table rather than a formula, and approve it with the criteria. Add a tie-break rule so that the highest consequence band never falls below the second-highest level, whatever the likelihood. Require the semi-quantitative estimate at the top bands. Then rank the treatment queue by the decision that is due, not by the colour of the cell.

3.6 Evaluate against the criteria and set the queue#

• Input: scored rows and the approved acceptance criteria.
• Activity: compare each level with the criteria, mark each row as inside or outside appetite, and order what falls outside.
• Output: a prioritised treatment queue, dated.
• Owner: the risk or ISMS manager, confirmed by the management forum.

ISO/IEC 27005:2022 splits evaluation into 7.4.1 Comparing the results of risk analysis with the risk criteria and 7.4.2 Prioritizing the analysed risks for risk treatment ¹. ISO 31000:2018 calls it 6.4.4 Risk evaluation ⁴. The queue is the deliverable, not the scoring: a register that ranks nothing has not been evaluated.

3.7 Force the treatment-or-acceptance decision#

• Input: the prioritised queue, the acceptance criteria, and the cost of the options.
• Activity: for every row, record exactly one option of modify, retain, avoid or share. Where the choice is retain, record the acceptor and the acceptance date in the same sitting.
• Output: Risk treatment plan, and acceptance records inside the register rows.
• Owner: the risk owner; acceptance above the delegated level goes to the management forum.

The four options come from the standard's own account of what treatment can involve. That account covers avoiding the activity, removing the risk source, changing likelihood, changing consequences, sharing with another party, and retaining by informed decision (3.2.7) ¹. Selection has its own clause, 8.2 Selecting appropriate information security risk treatment options. The plan has 8.6.1 Formulation of the risk treatment plan, followed by 8.6.2 Approval by risk owners and 8.6.3 Acceptance of the residual information security risks ¹.

Make it a forced choice with three fields and no blanks: option, approver, date. A blank option is an unmade decision, and that is the most common finding on an otherwise healthy register. Give acceptance an expiry: 3.2.8 keeps accepted risks under monitoring and 3.2.10 describes retention as temporary ¹.

3.8 Link every row to controls and to the Statement of Applicability#

• Input: the treatment plan, the control set in use, and the current Statement of Applicability.
• Activity: determine the controls the treatment needs, compare them with the reference control set, and reconcile the Statement of Applicability against what the register now says.
• Output: updated Statement of Applicability, with control references written back into the register rows.
• Owner: the ISMS manager, with each control owner confirming their own entries.

The standard walks this in three steps. First, 8.3 Determining all controls that are necessary to implement the information security risk treatment options. Then 8.4 Comparing the controls determined with those in ISO/IEC 27001:2022, Annex A. Then 8.5 Producing a Statement of Applicability ¹. The reference set itself is Annex A Information security controls reference in ISO/IEC 27001:2022 ². The order matters: controls are determined from the treatment and then compared with the annex, so nothing necessary is missed because the annex did not think of it.

An assessor tests the link in both directions, from a register row out to the Statement of Applicability entry, and from an applicable control back to the risk that justifies it.

3.9 Run the workshop so it converges#

• Input: the criteria statement, a scales one-pager, a pre-filled candidate list, and the register itself on screen.
• Activity: facilitate to a time-box, score live, and close each row before moving on.
• Output: scored rows with owners, and a short list of items parked with a named follow-up.
• Owner: the facilitator; the risk owner attends in person, not by delegate.

Preparation carries the session. Send the scales two working days ahead and ask each participant for three candidate scenarios in the grammar from 3.3. Pre-fill the register with last cycle's rows so the session is a revision rather than a blank page. Book ninety minutes for a first domain and sixty for later ones, and cap the room at eight people.

A script that holds up. Five minutes on scope; ten on last cycle's open decisions; forty-five on scoring, one row at a time, consequence first. Then fifteen on treatment options for anything outside appetite; ten on who accepts what, by when; five on what was parked. Score on screen, so people watch their own words become the record.

Three habits stop the "everything is high" spiral. Fix the shape of the distribution before you start: say out loud that a five is reserved for what the organisation cannot correct. Force a comparison whenever a fourth consequence 5 appears, and rescore the weaker of the two. Keep a parking list, so a concern can be recorded without inflating a score to get attention.

3.10 Set the review rhythm and define what "current" means#

• Input: the register, the change pipeline, and the incident and supplier feeds.
• Activity: give every row a review date, and define the events that pull a review forward. Review by exception between cycles.
• Output: a register where no row is past its review date, and a trigger list.
• Owner: the register keeper; the risk owner performs the review.

ISO/IEC 27005:2022 covers this as 10.5.2 Monitoring and reviewing factors influencing risks, alongside 10.4.3 Documented information about results ¹. ISO 31000:2018 names 6.6 Monitoring and review ⁴.

"Current" needs a written definition or it means nothing. A workable one: every row reviewed within twelve months; every row at the top two levels within six; every acceptance re-confirmed before its expiry date; every row touched by a trigger within twenty working days. Useful triggers are a change of risk owner, a material change to the asset or the service, a relevant incident in the sector, a supplier change, a new obligation, and any change to the scales. Record the evaluations that conclude "no change" too: that is the evidence the rhythm exists.

3.11 Reduce the register to the one-page board picture#

• Input: the current register, the queue, and the acceptance records.
• Activity: report the distribution, the movement since last time, the decisions needed now, and the acceptances about to expire. Keep the row-level detail in an annex.
• Output: One-page risk picture, and the management-review input pack.
• Owner: the ISMS manager, presenting to the management forum.

ISO/IEC 27005:2022 routes the output into 10.6 Management review ¹, which lands in ISO/IEC 27001:2022 as 9.3.2 Management review inputs ². ISO 31000:2018 calls the act 6.7 Recording and reporting ⁴.

Four things belong on the page. How many rows sit at each level, and how that moved; the rows that changed level, and why. Then the decisions the forum has to take today, each with an option and a date, and the acceptances expiring before the next meeting. If the page needs a legend, it is not the page.

4. Deliverables (with template links)#

Deliverable	Format	Template	Retention
Risk criteria statement	markdown	template pending	Live version; superseded versions three years
Risk register	xlsx	/templates/risk-register	Live version; snapshots three years
Risk treatment plan	xlsx (same workbook)	/templates/risk-register	Until every action closes, then three years
Risk acceptance record	register row: acceptor, date, expiry	/templates/risk-register	Three years after expiry
Statement of Applicability	xlsx	template pending	Live version; one prior certification cycle
Workshop pack (agenda, scales, candidate list)	markdown	template pending	One cycle
One-page risk picture	markdown or slide	template pending	Three years, with the forum minutes

Retention periods are a working default. Where the ISMS already sets a rule for documented information, that rule wins.

5. What the auditor / authority will ask [Callout: auditor-asks]#

• "Show the risk criteria and the record of who approved them." — evidence: Risk criteria statement with the approving minute.
• "Take this row. Who is the risk owner, and how do you know they accepted the wording?" — evidence: register row plus the workshop record naming the attendee.
• "Why is this a four and that one a three?" — evidence: the anchored scale points and the evidence field in each row.
• "Where is the decision on this high-level risk, and on what date?" — evidence: treatment option, approver and date in the row.
• "Who accepted the residual risk, and under what delegated authority?" — evidence: acceptance record plus the acceptance criteria table.
• "Pick an applicable control from the Statement of Applicability. Which risk justifies it?" — evidence: control references written back into the rows.
• "When was this row last reviewed, and what would have pulled the review forward?" — evidence: review date, trigger list and logged trigger evaluations.
• "How did this register reach top management, and what did they decide?" — evidence: One-page risk picture and the management review minute.
• "Show a risk whose level changed, and the reason." — evidence: the register's change history for that row.
• "Show a risk you decided to avoid, and what stopped." — evidence: the decision record naming the activity and the approver.

6. Failure modes we see and how they show up in findings [Callout: failure-mode]#

• Control gaps written as risks — surfaces as: "risk descriptions do not identify risk sources, events and consequences, so risk owners cannot be determined". Smallest fix: rewrite the ten worst rows in the source-event-consequence grammar, and reject the shape in the template itself.
• Scores without anchors — surfaces as: "risk criteria for consequence and likelihood are not defined, and scoring is not reproducible". Smallest fix: publish a one-page scale with sentence-level descriptors and re-score one domain against it.
• The security function owns every risk — surfaces as: "risk owners do not hold the authority to accept the risks recorded against them". Smallest fix: split the owner column three ways and reassign at the next forum.
• Decisions left blank — surfaces as: "risks outside the acceptance criteria have no recorded treatment decision or acceptance". Smallest fix: make the option column mandatory, then clear the blanks in one dated sitting.
• Acceptance with no name, no date, no end — surfaces as: "residual risks are recorded as accepted without evidence of who accepted them or when". Smallest fix: add acceptor, date and expiry columns, and re-confirm the open acceptances.
• A register that stops at certification — surfaces as: "the risk assessment has not been performed at planned intervals or when significant changes occurred". Smallest fix: give every row a review date and log the trigger evaluations, including those concluding no change.

7. Mapping to standards (clause table, verified)#

Every clause title below was read on the ISO Online Browsing Platform previews on 2026-09-03, where clause titles are visible without purchase: the previews are iso:std:iso-iec:27005:ed-4:v1:en, iso:std:iso-iec:27001:ed-3:v1:en and iso:std:iso:31000:ed-2:v1:en. Titles are cited; requirement text is paraphrased, never reproduced. Sub-item letters inside a clause are not visible in the previews, so this piece cites clause and subclause numbers only.

Method step	ISO/IEC 27005:2022	ISO/IEC 27001:2022	ISO 31000:2018	Verified
Establish scope and context	6.1 Organizational considerations; 6.2 Identifying basic requirements of interested parties	4.1, 4.2, 4.3 (Context of the organization)	6.3.2 Defining the scope; 6.3.3 External and internal context	[3](#grcide-source-3)
Set risk criteria	6.4.2 Risk acceptance criteria; 6.4.3 Criteria for performing information security risk assessments	6.1.2 Information security risk assessment	6.3.4 Defining risk criteria	[3](#grcide-source-3)
Anchor the scales, publish the combination rule	6.4.3.2 Consequence criteria; 6.4.3.3 Likelihood criteria; 6.4.3.4 Criteria for determining the level of risk	6.1.2 Information security risk assessment	6.3.4 Defining risk criteria	[3](#grcide-source-3)
Choose the method	6.5 Choosing an appropriate method; A.1.1.2 Qualitative approach; A.1.1.3 Quantitative approach	6.1.2 Information security risk assessment	6.4.1 General	[3](#grcide-source-3)
Identify and describe risks	7.2.1 Identifying and describing information security risks; A.2.4 Event-based approach; A.2.5 Asset-based approach	6.1.2 Information security risk assessment	6.4.2 Risk identification	[3](#grcide-source-3)
Identify risk owners	7.2.2 Identifying risk owners	5.3 Organizational roles, responsibilities and authorities	5.4.3 Assigning organizational roles, authorities, responsibilities and accountabilities	[3](#grcide-source-3)
Score and determine the level	7.3.2 Assessing potential consequences; 7.3.3 Assessing likelihood; 7.3.4 Determining the levels of risk	6.1.2 Information security risk assessment	6.4.3 Risk analysis	[3](#grcide-source-3)
Compare with the criteria, then prioritise	7.4.1 Comparing the results of risk analysis with the risk criteria; 7.4.2 Prioritizing the analysed risks for risk treatment	6.1.2 Information security risk assessment	6.4.4 Risk evaluation	[3](#grcide-source-3)
Select the treatment option	8.2 Selecting appropriate information security risk treatment options	6.1.3 Information security risk treatment	6.5.2 Selection of risk treatment options	[3](#grcide-source-3)
Determine necessary controls	8.3 Determining all controls that are necessary to implement the information security risk treatment options	6.1.3 Information security risk treatment	6.5.1 General	[3](#grcide-source-3)
Compare against the reference set	8.4 Comparing the controls determined with those in ISO/IEC 27001:2022, Annex A	Annex A Information security controls reference	not addressed	[3](#grcide-source-3)
Produce the Statement of Applicability	8.5 Producing a Statement of Applicability	6.1.3 Information security risk treatment	6.7 Recording and reporting	[3](#grcide-source-3)
Write the treatment plan	8.6.1 Formulation of the risk treatment plan	6.1.3 Information security risk treatment	6.5.3 Preparing and implementing risk treatment plans	[3](#grcide-source-3)
Get the risk owner's approval	8.6.2 Approval by risk owners	6.1.3 Information security risk treatment	5.4.3 Assigning organizational roles, authorities, responsibilities and accountabilities	[3](#grcide-source-3)
Accept the residual risk	8.6.3 Acceptance of the residual information security risks	6.1.3 Information security risk treatment	6.5.1 General	[3](#grcide-source-3)
Run the assessment in operation	9.1 Performing information security risk assessment process	8.2 Information security risk assessment	6.4.1 General	[3](#grcide-source-3)
Run the treatment in operation	9.2 Performing information security risk treatment process	8.3 Information security risk treatment	6.5.1 General	[3](#grcide-source-3)
Keep the results as records	10.4.3 Documented information about results	7.5 Documented information	6.7 Recording and reporting	[3](#grcide-source-3)
Monitor and review	10.5.2 Monitoring and reviewing factors influencing risks	9.1 Monitoring, measurement, analysis and evaluation	6.6 Monitoring and review	[3](#grcide-source-3)
Report to management	10.6 Management review	9.3.2 Management review inputs	6.7 Recording and reporting	[3](#grcide-source-3)

Two notes on reading the table. The ISO/IEC 27005:2022 subclauses numbered 10.x sit under its clause 10 Leveraging related ISMS processes, which attaches risk work to management-system machinery that already exists ¹. And ISO 31000:2018 is guidance, not a certifiable requirement set: its column shows where the same act lives in a general risk vocabulary, which is what makes a security register legible to enterprise risk.

8. Checklist (interactive)#

• Risk criteria statement exists, is versioned, and carries a dated approval minute.
• Both scales carry sentence-level anchors: consequence on information, regulatory-financial and operational axes; likelihood on observed frequency.
• The rule that combines consequence and likelihood is published as a lookup, with a tie-break for the top consequence band.
• Acceptance criteria state who may accept each level, for how long, and what record is required.
• Every register row names a risk source, an event, a consequence and an affected asset or objective.
• No row's description begins with "lack of", "no", "missing" or "insufficient".
• Risk owner, control owner and register keeper are separate columns holding different names on most rows.
• Every row records the evidence used for its consequence and likelihood scores.
• Every row outside appetite carries exactly one treatment option of modify, retain, avoid or share.
• Every accepted row carries an acceptor's name, an acceptance date and an expiry date.
• Every row at the top two levels carries a semi-quantitative estimate as a loss range and a frequency range.
• Control references reconcile with the Statement of Applicability in both directions.
• Every row has a review date, and no row is past it.
• The trigger list exists, and evaluations that concluded "no change" are recorded.
• The last management forum received the one-page picture, and its minute records the decisions taken.
• A named person can produce the full history of any single row within one working day.

References#

1. ISO/IEC. Information security, cybersecurity and privacy protection — Guidance on managing information security risks. ISO/IEC 27005:2022. https://www.iso.org/obp/ui/en/#iso:std:iso-iec:27005:ed-4:v1:en [3](#grcide-source-3)
2. ISO/IEC. Information security, cybersecurity and privacy protection — Information security management systems — Requirements. ISO/IEC 27001:2022. https://www.iso.org/obp/ui/en/#iso:std:iso-iec:27001:ed-3:v1:en [3](#grcide-source-3)
3. ISO. Risk management — Guidelines. ISO 31000:2018. https://www.iso.org/obp/ui/en/#iso:std:iso:31000:ed-2:v1:en [3](#grcide-source-3)

Claims checked at write time, in the columns the site's source log uses.

Date accessed	Claim	Source title	URL
2026-09-03	Titles of clauses 6.4.2, 6.4.3 and subclauses, 6.5, 7.2.1, 7.2.2, 7.3.2-7.3.4, 7.4.1, 7.4.2, 8.2-8.5, 8.6.1-8.6.3, 9.1, 9.2, 10.4.3, 10.5.2, 10.6, A.1.1.2, A.1.1.3, A.2.4, A.2.5	ISO/IEC 27005:2022(en), Table of contents, ISO Online Browsing Platform	https://www.iso.org/obp/ui/en/#iso:std:iso-iec:27005:ed-4:v1:en
2026-09-03	Definitions of risk owner 3.1.5, risk source 3.1.6, event 3.1.11, likelihood 3.1.13, level of risk 3.1.15, residual risk 3.1.17, risk treatment 3.2.7, risk acceptance 3.2.8, risk retention 3.2.10	ISO/IEC 27005:2022(en), Clause 3 Terms and definitions, ISO Online Browsing Platform	https://www.iso.org/obp/ui/en/#iso:std:iso-iec:27005:ed-4:v1:en
2026-09-03	Fourth edition, aligned with ISO/IEC 27001:2022 and ISO 31000:2018; contrasts the event-based with the asset-based approach to risk identification	ISO/IEC 27005:2022(en), Foreword, ISO Online Browsing Platform	https://www.iso.org/obp/ui/en/#iso:std:iso-iec:27005:ed-4:v1:en
2026-09-03	Titles of clauses 5.3, 6.1.2, 6.1.3, 7.5, 8.2, 8.3, 9.1, 9.3.2 and of Annex A	ISO/IEC 27001:2022(en), Table of contents, ISO Online Browsing Platform	https://www.iso.org/obp/ui/en/#iso:std:iso-iec:27001:ed-3:v1:en
2026-09-03	Titles of clauses 5.4.3, 6.3.2-6.3.4, 6.4.1-6.4.4, 6.5.1-6.5.3, 6.6 and 6.7	ISO 31000:2018(en), Table of contents, ISO Online Browsing Platform	https://www.iso.org/obp/ui/en/#iso:std:iso:31000:ed-2:v1:en

Standards and certification names are the property of their respective owners. GRCIDE is an independent publication and is not affiliated with, authorized, sponsored or endorsed by ISO, IEC, NIST or any other standards body.