# How to run a risk assessment Set criteria, find and score risks, choose treatments and get owners to accept what remains, for ISO 27001, ISO 9001, ISO 13485, ISO 42001 and UK GDPR. Source: https://sted.digital/docs/guides/risk-assessment · Last reviewed 17 October 2026 · Strand Guides A good risk assessment gives the same answer whoever runs it. Write down your scoring scale and acceptance threshold first, list risks as concrete scenarios with a named owner, score likelihood and impact, compare each score with the threshold, choose a treatment for every risk above it, and have each owner approve the plan and accept what remains. ## When you need this ISO 27001:2022 6.1.2 requires a defined assessment process, 6.1.3 the treatment that follows, 8.2 that you repeat the assessment at planned intervals and on significant change, and 8.3 that you carry out the plan, keeping the results of both. ISO 9001:2015 6.1 asks for risks and opportunities without prescribing a method. ISO 13485:2016 7.1 requires documented risk management in product realisation. ISO 42001:2023 6.1.2 sets the AI risk assessment, and 6.1.4 adds an impact assessment for each AI system. UK GDPR Article 32(1) asks for security appropriate to the risk to individuals. The triggers are a certification project, the annual review, a new product, supplier or hosting provider, and any incident that exposed an unrecorded risk. The security or quality lead usually runs it; the risk owners decide what to do. This is guidance to help you understand the requirement, not legal advice. ## Before you start Have your scope, your list of [interested parties](/docs/glossary/interested-parties) and their requirements, an asset or system inventory, and the incidents and audit findings since the last assessment. Book one workshop with a person from each part of the business, not only IT: finance, support and operations see risks engineering never meets. Expect two to three days for a first assessment in a firm of 20 to 50 people: half a day to agree the method, a day of workshops, a day to score and draft treatments. An annual refresh takes a day. ## Steps 1. Write the method. Define likelihood and impact scales with a one-line description per score, the acceptance threshold, and the events that trigger a reassessment. Done when a newcomer could score a risk from the document alone. 2. Identify risks as scenarios. Write each as cause, event and consequence ("a support laptop is stolen with customer exports on it, exposing 4,000 records"). Done when every system and process in scope has been considered. 3. Name an owner for each risk. Choose the person with the authority to fund and change the thing at risk. Done when no row is owned by "IT" or left blank. 4. Score likelihood and impact before controls. Record both numbers and the reason for each. Done when every row has an inherent score. 5. Evaluate each risk against the threshold. Mark it accept or treat, and rank the risks to treat. Done when the ranked list exists. 6. Choose a treatment option for each risk above the threshold: reduce, avoid, transfer or accept. Done when every risk to treat has an option and a reason. 7. Select the controls each treatment needs, and compare them with the [Annex A](/docs/glossary/annex-a) list so none is missed. Done when each control traces to at least one risk. 8. Write the [risk treatment plan](/docs/glossary/risk-treatment-plan). Give every action an owner, a due date and the resources it needs. Done when no action is undated. 9. Score the [residual risk](/docs/glossary/residual-risk). Repeat step 4 as if the planned controls were working. Done when every treated row has a residual score. 10. Obtain each owner's approval of the plan and acceptance of the residual risk. Record names and dates. Done when every row carries a sign-off. 11. Set the next review date, and record which events will trigger an earlier one. Done when the date is in the calendar and the trigger list is in the method. The Risks and opportunities register holds each risk's likelihood and impact before and after controls, the controls in place, whether it is above your risk appetite, its treatment plan, an owner and a last-reviewed date, and lists its inherent and residual levels. Risk levels are computed from likelihood and impact. ## Scoring likelihood and impact Multiply a likelihood score by an impact score, each from 1 (very low) to 5 (very high), and band the product. A common banding is 1 to 4 low, 5 to 9 medium, 10 to 16 high and 20 to 25 critical. | Likelihood | Impact 1 | Impact 2 | Impact 3 | Impact 4 | Impact 5 | |---|---|---|---|---|---| | 5 | 5 | 10 | 15 | 20 | 25 | | 4 | 4 | 8 | 12 | 16 | 20 | | 3 | 3 | 6 | 9 | 12 | 15 | | 2 | 2 | 4 | 6 | 8 | 10 | | 1 | 1 | 2 | 3 | 4 | 5 | The grid matters less than the words behind each number. ISO 27001:2022 6.1.2 asks for consistent, valid and comparable results, which only definitions deliver: "likely: expected at least once a year", not "likely". Test the method by having two people score the same five risks. ### Where scoring goes wrong Everything lands on 3, because nobody wants to argue. A 5 × 1 and a 1 × 5 both score 5, though a near-certain nuisance and a rare disaster need different answers: let any impact of 5 trigger treatment whatever the product. And teams score after controls without saying so, hiding the controls the score depends on. ## Risk ownership A risk owner is the person accountable for a risk and able to act on it: the head of support for the stolen laptop, the finance director for payment fraud. ISO 27001:2022 6.1.3 f) has owners approve the treatment plan and accept the residual risk, so their names and dates are evidence. ### Owning up to residual risk The usual failure is a security lead who owns every row and signs the whole plan. An auditor will ask an owner about a risk they accepted; if they have never seen it, that is a finding. Walk each owner through their rows in 20 minutes and record the decision. ## Worked examples ### ISO 27001, a 25-person software firm's first register Northgate Data writes its method on 3 March 2026: the 5 × 5 grid above, accept at 9 or below. Of 31 risks, three show the pattern. A stolen support laptop with customer exports scores 3 × 4 = 12; the head of support chooses reduce: encryption and device management (Annex A 8.1) and no local exports, residual 1 × 4 = 4. A single-zone database outage scores 2 × 5 = 10; the CTO adds a standby in a second zone (Annex A 8.14), residual 2 × 3 = 6. A spoofed supplier email diverting a payment scores 4 × 3 = 12; the finance director adds a call-back check on any change of bank details, residual 2 × 3 = 6. All three owners sign the plan on 17 March, actions due by 30 June. When Northgate changes hosting provider in September, clause 8.2 triggers a reassessment and the outage risk is re-scored. ### ISO 13485, hazard analysis for a wound dressing Lindale Medical's method comes from [ISO 14971](/docs/standards/iso-14971), which ISO 13485:2016 7.1 points to. The team lists hazards, the hazardous situations each leads to and the resulting harm: residue from a new adhesive, a dressing on an open wound, skin irritation. Scored on the risk management plan's probability and severity scales, the risk is above its acceptability line. Control: a supplier specification limit and a biocompatibility test on each new adhesive lot, both verified before release. Residual risk is re-estimated per hazard, then judged overall against the clinical benefit. The risk management report closes the file before the dressing ships. ### ISO 9001, risks and opportunities to conformity ISO 9001:2015 6.1 follows the ISO 27001 example with a lighter method: risks and opportunities to conformity and customer satisfaction, acted on in proportion to their effect. ### ISO 42001, risks from an AI system ISO 42001:2023 6.1.2 follows the ISO 27001 shape with the AI system as the subject and harm to individuals and society among the consequences; 6.1.4 adds the system impact assessment. ### UK GDPR, risk to the people in the data UK GDPR Article 32(1) reuses the ISO 27001 register, but impact is scored for the people the data is about. Where processing is likely to result in high risk to them, Article 35 requires a [DPIA](/docs/guides/dpia). ### SOC 2, fraud and change The payment-diversion risk in the ISO 27001 example is the fraud scenario SOC 2 CC3.3 asks for; CC3.2 maps onto steps 2 to 5, and CC3.4 onto the September reassessment. ## Checklist - [ ] The method defines every likelihood and impact score in words. - [ ] The acceptance threshold is written down and approved. - [ ] Every risk is a scenario with a cause, an event and a consequence. - [ ] Every risk has a named owner from the business. - [ ] Inherent and residual scores are both recorded. - [ ] Every risk above the threshold has a treatment option and a reason. - [ ] Every control traces to a risk, and Annex A was checked for gaps. - [ ] Every action in the treatment plan has an owner and a due date. - [ ] Owners approved the plan and accepted residual risk, with dates. - [ ] Fraud and personal data risks to individuals are in the register. - [ ] The next review date and the reassessment triggers are recorded. ## How Sted helps For ISO 27001 risk work Sted's knowledge base carries the Risk Management Procedure (PRC-RMP) with its Operating Risk Assessment Record (REC-ORAR) and Operating Opportunity Assessment Record (REC-OORA), and for planned changes the Change Management Policy (POL-CHG) with its Change Record (REC-CR). Records are part of the Full Management System plan. Under the same Risk Management Procedure (PRC-RMP) Sted's knowledge base carries an AI Risk Assessment Record (REC-ARA) for each AI system, with a suggested annual frequency, and for medical devices a Medical Device Risk Management Plan (REC-MDRMP), Medical Device Risk Management File (REC-MDRM) and Risk Management Report (REC-RMR). Records are part of the Full Management System plan. Records follow templates with sections and, where useful, structured fields you can report on. Records are part of the Full Management System plan. Sted records the register and computes risk levels. It does not identify your risks, set your acceptance threshold or accept residual risk; your risk owners do. ## Related standards - [ISO 27001 risk assessment and treatment](/docs/standards/iso-27001/risk-assessment-and-treatment): what clauses 6.1.2, 6.1.3 and 8.2 require. - [SOC 2 security common criteria](/docs/standards/soc-2/security-common-criteria): the CC3 risk criteria, fraud included. - [How to write a Statement of Applicability](/docs/guides/statement-of-applicability): the next step after treatment. - [Risk register](/docs/glossary/risk-register): what the register holds and who reads it. - [Management-system registers](/docs/product/management-system-registers): where the risk register lives in Sted. ## Frequently asked questions Q: Should I use a 5x5 or a 3x3 risk matrix? A: Either works if every score has a written definition. A 3x3 matrix is quicker and suits a register of 20 or so risks; a 5x5 gives more room to show that a control moved a risk. What auditors test is whether two people reach the same score, not how many boxes the grid has. Q: What goes in an information security risk register? A: One row per risk, written as a scenario: what could happen, to which information, and with what consequence. Each row carries an owner, likelihood and impact before and after treatment, the treatment option, the controls chosen and the date of the last review. A register of 20 to 60 rows is normal for a small firm. Q: Is a GDPR risk assessment the same as an ISO 27001 one? A: No. ISO 27001 scores consequences for your organisation; UK GDPR Article 32(1) asks about the risk to the people the data is about. You can keep both in one register, but score the impact on individuals separately, and run a DPIA when processing is likely to result in a high risk to them.