Risk Identification & Assessment Operating Procedure
Defines how risks are identified, assessed, recorded and re-assessed, including the triggers that force an out-of-cycle review.
Available soon
- Format
- Word
- Size
- 60 KB
- Length
- 17 pages
- Version
- 1.1
- Updated
What's inside
- Purpose
- Scope
- Roles
- Triggers and inputs
- Procedure steps
- Decision points
- Outputs and records produced
- Timing targets
- Escalation
- Evidence retained
- Related documents
- Adapting this template
- Framework references
- Definitions
Preview
The document from section 1, as you will receive it. Highlighted [[text]] is for you to replace; shaded guidance boxes are for you to delete before approval. The cover and document control pages are in the file.
Purpose
This procedure sets out how [[Organisation Name]] finds information security risks, assesses them, records them and keeps them current. It is the working routine behind the Risk Assessment Methodology & Scoring Model: the methodology says how a risk is written and scored and what the score decides (rules RM-01 to RM-12); this procedure says who does what, in which order, by when, and what record each step leaves.
It answers three questions for every risk: where it came from, who assessed it and decided what to do, and when it was last looked at, and why.
Scope
This procedure applies to:
- every information security risk to [[Organisation Name]]'s services, information and systems, including those run for it by service providers;
- every risk that reaches the Information Security Risk Register, however it was found: a scheduled assessment, an incident, an audit, a change or a threat report;
- everyone with a role in the table below.
It does not cover how treatment actions are delivered (the Risk Treatment Plan), how an acceptance is approved (the Risk Acceptance Form & Approval Record), or how the board is told (the Board Reporting Narrative Model in the Board Cybersecurity Reporting pack). It hands over to each of them at the step named.
Guidance — delete before approval
Keep the scope the same as the methodology's. If another process finds risks — a project risk log, a supplier assessment, a data protection impact assessment — route its security risks into this procedure rather than keep a second list (RM-11).
Roles
Role | What they do in this procedure |
|---|---|
Risk owner [[the accountable executive for the service or asset]] | Owns the risk: agrees the scenario and ratings, decides the treatment, signs acceptances, and reviews the risk every quarter (RM-02, RM-06, RM-09). |
Assessor [[e.g. Information Security Manager]] | Runs the procedure: collects sources, writes scenarios with the owner, rates impact and likelihood, keeps the register and prepares the quarterly figures. |
Head of Information Security [[e.g. Head of Information Security or CISO]] | Checks High and Critical ratings, settles disputed ratings, co-approves Medium and High acceptances, and reports to executive management. |
Action owner [[whoever delivers a treatment action]] | Delivers a treatment action and reports its progress (RM-07). |
Executive management [[e.g. Executive Committee]] | Receives the quarterly report (RM-12); accepts risks outside appetite; settles disputed ownership. |
Board [[e.g. Board, or its Audit & Risk Committee]] | Accepts risks outside tolerance and any Critical residual risk (RM-08); sets appetite and tolerance. |
Guidance — delete before approval
In a small organisation the assessor and the Head of Information Security may be one person. That is acceptable, but that person must not also own the risks they assess, except risks to the security function's own duties; and their High and Critical ratings are checked by [[a second person, e.g. an external adviser]].
Triggers and inputs
When this procedure runs
Event | What starts | Steps |
|---|---|---|
A source reveals a possible new risk | Identification and assessment | 1 to 17 |
The end of each quarter (RM-09) | Owner review of every risk; the quarterly report | 18 to 21 |
Once a year (RM-09) | Reassessment of the whole register | 22 to 23 |
A trigger (RM-10) | Reassessment of the risks it touches | 24 to 26 |
A risk no longer applies, or duplicates another | Closure or merger | 27 to 29 |
Sources of risk
The assessor keeps each source under watch and looks through it for new scenarios at least [[monthly]] (step 2).
Source | What it shows | Supplied by |
|---|---|---|
Asset and service list | What the organisation depends on and how critical each item is; new and retired services | [[IT and service owners]]; reviewed at least yearly |
Threat intelligence | Threats active against organisations like ours: ransomware groups, fraud methods, exploited weaknesses | [[Threat intelligence feeds, national cyber security centre, sector information sharing, suppliers]] |
Incidents and near misses | What has happened, or nearly happened, here and to peers | Incident log; [[service desk]] |
Audits, tests and assessments | Weaknesses found by internal audit, penetration tests, vulnerability scans and supplier assessments | Internal audit; [[testers]]; the vulnerability programme |
Security exceptions | Known gaps accepted for a limited time | Security Exception Register |
Cyber Risk Scenario Library | Scenarios already written to RM-01, to check against our own services | This pack |
Changes | New systems, suppliers, processes or organisation changes | [[Change management; procurement; projects]] |
Managers and staff | Concerns raised by anyone | [[Risk mailbox or form]] |
Other inputs
Input | Where it comes from | Used for |
|---|---|---|
The method: scales, matrix, bands, positions | Risk Assessment Methodology & Scoring Model | Steps 5 to 13 |
Appetite and tolerance by category | Cyber Risk Appetite Statement Template | Step 12 |
The register | Information Security Risk Register | Duplicates, history, review dates |
Evidence that controls work | Control owners: [[test results, configuration exports, logs]] | Residual ratings (step 9) |
Procedure steps
Every step names who does it and when. "Working days" are Monday to Friday excluding [[public holidays]]; "calendar days" include every day.
Stage 1 — Identify
Step | What happens | Who | When | Output |
|---|---|---|---|---|
1 | Keep the list of sources above current, with a named supplier for each. | Assessor | [[Yearly]], and when a source changes | Source list |
2 | Look through each source for events or conditions that could harm a service, information or a legal duty. Note each as a candidate risk. | Assessor | At least [[monthly]] | Candidate risks |
3 | Check each candidate against the register. If an entry already covers it, update that entry (go to stage 8); do not add a second one (RM-11). | Assessor | Within [[5]] working days of noting it | New candidate, or update to an existing risk |
4 | Acknowledge any candidate raised by someone else and tell them what happens next. | Assessor | Within [[5]] working days of receipt | Acknowledgement |
Stage 2 — Describe as a scenario
Step | What happens | Who | When | Output |
|---|---|---|---|---|
5 | Write the risk as a scenario (RM-01): threat, weakness, asset or service, consequence, and a one-sentence title. Start from the Cyber Risk Scenario Library where a scenario fits. | Assessor, with the proposed owner | Within [[10]] working days of step 3 | Draft scenario |
6 | Agree the owner (RM-02): the executive accountable for the service or asset that would be hurt. If two executives disagree, the Head of Information Security refers it to executive management. | Assessor; Risk owner | Same time as step 5 | Named owner |
7 | Assign the category, which sets the appetite (Cyber Risk Appetite Statement Template). If two could apply, use the one with the lower appetite. | Assessor | Same time as step 5 | Category |
Stage 3 — Assess inherent and residual
Step | What happens | Who | When | Output |
|---|---|---|---|---|
8 | Rate inherent impact and likelihood, each 1 to 4, with the Risk Assessment Methodology & Scoring Model scales. Write one sentence of reason for each rating. Where personal data is involved, judge impact on the worse of the harm to the organisation and to the people. | Assessor, with the owner | Within [[10]] working days of step 3 | Inherent ratings with reasons |
9 | List existing controls and get evidence that each works from its control owner. A control without evidence does not count. | Assessor; control owners | Same time | Control list with evidence references |
10 | Rate residual impact and likelihood with the working controls (RM-03). Record why each rating differs from the inherent one. | Assessor, with the owner | Same time | Residual ratings with reasons |
11 | Check the ratings of any risk whose inherent or residual band is High or Critical before it is recorded. Settle any disagreement between assessor and owner. | Head of Information Security | Within [[5]] working days of step 10 | Checked ratings |
Stage 4 — Compare with appetite
Step | What happens | Who | When | Output |
|---|---|---|---|---|
12 | Read the residual band from the matrix, and the position from the category's appetite and tolerance (RM-04, RM-05): Within appetite; Outside appetite, within tolerance; or Outside tolerance. | Assessor | At step 10 | Band and position |
13 | Tell the people the band requires (table below). A risk outside tolerance, or any Critical residual risk, goes to the board chair out of cycle. | Assessor; Head of Information Security | Within [[2]] working days of step 12 | Notice to the right people |
Who must know, by residual band (RM-04):
Residual band | Score | Who must know |
|---|---|---|
Low | 1–3 | Risk owner; recorded in the register |
Medium | 4–6 | Risk owner and Head of Information Security |
High | 8–9 | Accountable executive and Head of Information Security; named to executive management in the quarterly report |
Critical | 12–16 | Executive management at once; the board chair out of cycle, within [[5]] working days (Critical is always outside tolerance) |
Stage 5 — Record in the register
Step | What happens | Who | When | Output |
|---|---|---|---|---|
14 | Enter the risk in the Information Security Risk Register (RM-11) with a reference in the form R-nn: title, scenario, owner, category, inherent and residual ratings with reasons, controls and evidence, band, position, source, date assessed, the date it was first assessed outside appetite (which starts the RM-06 window) and next review date. Assessments and workshop notes are not kept as separate lists: their result is the register entry. | Assessor | Within [[2]] working days of step 12 | Register entry |
Stage 6 — Decide treatment
Step | What happens | Who | When | Output |
|---|---|---|---|---|
15 | For a risk outside appetite, the owner decides the treatment (RM-06): reduce, avoid, transfer or accept. For a risk within appetite, no new decision is needed; the owner may still reduce it. | Risk owner | Within [[30]] calendar days of the risk first being assessed outside appetite; later reviews do not restart the window | Treatment decision |
16 | For reduce, avoid or transfer: record each action in the Risk Treatment Plan with an action owner, due date, cost and the residual score expected when it is done (RM-07). | Risk owner; Action owner | With step 15 | Treatment actions |
17 | For accept: complete the Risk Acceptance Form & Approval Record and get approval at the level the band and position require (RM-08). The band's approvers always sign. Outside appetite, executive management signs as well, never instead; outside tolerance, the band's approvers recommend and only the board or its equivalent may accept. | Risk owner; approver | With step 15 | Approved acceptance with review date |
Who may accept, and when the acceptance is reviewed, by residual band. The position adds signatures to these, never replaces them (step 17).
Residual band | Who may accept | Acceptance reviewed within |
|---|---|---|
Low | Risk owner | 12 months |
Medium | Risk owner and Head of Information Security | 12 months |
High | Accountable executive and Head of Information Security | 6 months |
Critical | The board, or a board risk committee it has delegated this to; in a two-tier structure, the management board; where there is no board, such as in an owner-managed company, executive management | 3 months |
Guidance — delete before approval
If the owner has not decided within [[30]] calendar days, the Head of Information Security escalates to executive management (see Escalation). A risk outside appetite with no decision is the gap auditors and regulators look for first.
Stage 7 — Quarterly owner review and annual reassessment
Step | What happens | Who | When | Output |
|---|---|---|---|---|
18 | Review each owned risk: is the scenario still right; are the controls still working; are the actions on time; has anything changed the ratings? Confirm or change the ratings with a reason (RM-09). | Risk owner, with the assessor | In the last [[10]] working days of each quarter | Owner review recorded |
19 | Update the register: review date, any new ratings, band and position. A changed position goes back to step 13; a newly outside-appetite risk to step 15. | Assessor | By the last working day of the quarter | Register as at quarter end |
20 | Check acceptances whose review date falls in the next quarter and send them to their approvers (RMM-03). | Assessor | Same time | Acceptance reviews due |
21 | Report to executive management the position against appetite, its movement and treatment progress (RM-12), with RMM-01, RMM-02, RMM-03, RMM-04, using the Risk Reporting Dashboard. The top risks feed the Board Reporting Data Collection Workbook (Board Cybersecurity Reporting pack). | Head of Information Security | Within [[10]] working days of quarter end | Quarterly report |
22 | Reassess the whole register: every scenario, rating and owner, the category of each risk, and the source list. Review the asset and service list at the same time. | Assessor; every risk owner | Once a year, in [[Q4]] | Reassessed register |
23 | Present the reassessed register and any change to the Risk Assessment Methodology & Scoring Model to executive management. | Head of Information Security | With the next quarterly report | Approval of the annual reassessment |
Stage 8 — Triggered reassessment
A trigger forces reassessment of the risks it touches within [[10]] working days. These events are triggers:
Trigger | Usually spotted by |
|---|---|
A major incident, or a near miss that shows a risk was underrated | Incident manager; [[service desk]] |
A major change to systems, processes, suppliers or the organisation | [[Change management; procurement; HR for organisation changes]] |
A new or changed threat relevant to our services (threat intelligence) | Assessor, from threat intelligence |
An audit, test or assessment finding | Internal audit; testers; the vulnerability programme |
A change in law, regulation or a key contract | [[Legal; compliance; contract owners]] |
Step | What happens | Who | When | Output |
|---|---|---|---|---|
24 | Record the trigger and list the register entries it touches, and any new scenario it suggests (stage 1). | Assessor | Within [[2]] working days of hearing of it | Trigger record |
25 | Reassess each touched risk with its owner (steps 8 to 12). For a major change, assess before it goes live where possible. | Assessor; Risk owner | Within [[10]] working days of the trigger | Updated ratings, band and position |
26 | Where the position has changed, apply steps 13 to 17. A risk now outside tolerance goes to the board chair out of cycle. | Assessor; Head of Information Security | At once | Notices; treatment decision |
Stage 9 — Close or merge
Step | What happens | Who | When | Output |
|---|---|---|---|---|
27 | Close a risk when its scenario can no longer happen — the asset is retired or the activity stopped (avoid) — with evidence. Lower likelihood is not closure: a risk that is merely small stays in the register at Low. | Risk owner; Head of Information Security agrees | At any review | Risk closed, with evidence |
28 | Merge entries that describe the same scenario, or a cluster on one service that is really one scenario, into one entry scored at its worst consequence. Record which entries it replaces. | Assessor; the owners | At any review | Merged entry |
29 | Keep closed and merged entries in the register with status Closed or Merged and the date. Never delete them. | Assessor | Same time | Register history |
Decision points
Decision | Who decides | Rule | Recorded in |
|---|---|---|---|
Is it a new risk, or an update to one? | Assessor | One entry per scenario (RM-11) | Register |
Who owns it? | Assessor and owner; executive management if disputed | The executive who would feel the harm (RM-02) | Register |
What are the ratings? | Assessor with owner; Head of Information Security for High and Critical, or if disputed | Scales in the Risk Assessment Methodology & Scoring Model; working controls only (RM-03) | Register, with reasons |
Where is it against appetite? | The rules, not a person | Band and category give the position (RM-04, RM-05) | Register |
What is the treatment? | Risk owner | Outside appetite: within [[30]] calendar days (RM-06) | Risk Treatment Plan |
Who may accept? | The band's approvers; executive management as well outside appetite; only the board outside tolerance | RM-08 | Risk Acceptance Form & Approval Record |
Can it be closed? | Risk owner with Head of Information Security | Only if the scenario can no longer happen (step 27) | Register, with evidence |
Worked example — one risk over one quarter
EXAMPLE, not part of the procedure. The firm is the one used throughout the pack: a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders. Risk R-04: "Ransomware spreads from warehouse office PCs to warehouse systems", owner Head of Logistics. Dates run from last quarter's review to 30 September 2026; replace them with your own.
Date | What happened | Steps |
|---|---|---|
30 June 2026 | Quarter-end owner review. Scenario: ransomware brought in on a warehouse office PC; warehouse office PCs and warehouse systems share one network; warehouse management and dispatch systems at the three warehouses; dispatch stopped for 1 to 2 days while systems are rebuilt; orders taken online but not shipped. Residual 3 Major × 3 Likely = 9, High. Category Service availability is Cautious: Outside appetite, within tolerance. | 18, 19, 12 |
14 July 2026 | The Head of Logistics decides to reduce the risk: separate the warehouse systems' network from the office network at each of the three warehouses. Decision inside the window, which ran to 30 July 2026 ([[30]] calendar days from the risk first being assessed outside appetite). Recorded in the Risk Treatment Plan as TA-04: owner Head of IT, due 11 September 2026, cost €28,000, expected 2 × 2 = 4. | 15, 16 |
12 August 2026 | Ransomware on 14 office PCs at one warehouse; ordering and dispatch not affected. The first warehouse had already been separated, so the ransomware did not reach its warehouse systems. A major incident is a trigger: reassessment due by 26 August 2026 ([[10]] working days). | 24 |
20 August 2026 | Reassessed with the owner. The incident confirms the threat is real; the separation worked where it was in place, but two warehouses remain unseparated, so the residual ratings stay at 3 × 3. The action for the other two sites is brought forward. | 25, 26 |
9 September 2026 | The last warehouse is separated. | 16 |
11 September 2026 | A test from an office PC at each warehouse shows the warehouse systems cannot be reached. The test record is the evidence that the control works; TA-04 is marked done. | 9, 16 |
30 September 2026 | Quarter-end owner review. Residual impact 2 Moderate: ransomware could now reach at most one site's warehouse systems, so the other two keep dispatching. Likelihood 2 Possible: spreading needs to cross a tested boundary. 2 × 2 = 4, Medium → Within appetite. The expected score of TA-04 is now the residual score. | 18, 19, 12 |
Within [[10]] working days of 30 September 2026 | Reported to executive management as movement: risks outside appetite fall from 3 to 2 (RMM-01). The board hears it as "one risk returned within appetite after the warehouse network was separated from the office network". | 21 |
Had the separation not been tested, the review on 30 September 2026 would have kept R-04 at 9, High: a control counts only with evidence that it works (RM-03).
Outputs and records produced
Output | Produced at step | Held in | Maintained by |
|---|---|---|---|
Source list | 1 | [[Location]] | Assessor |
Register entry: scenario, owner, ratings with reasons, band, position, dates | 14, 19, 25, 29 | Information Security Risk Register | Assessor |
Assessment working and control evidence | 8 to 10 | Risk Assessment Workbook; [[evidence location]] | Assessor |
Treatment decisions and actions | 15, 16 | Risk Treatment Plan | Risk owner |
Acceptances | 17 | Risk Acceptance Form & Approval Record | Risk owner |
Owner review record | 18 | Information Security Risk Register | Risk owner |
Trigger record | 24 | [[Location]] | Assessor |
Quarterly report | 21 | Risk Reporting Dashboard | Head of Information Security |
Timing targets
Activity | Target | Basis |
|---|---|---|
Candidate risk checked against the register | Within [[5]] working days of being noted | This procedure |
New risk assessed | Within [[10]] working days of step 3 | This procedure |
High or Critical ratings checked | Within [[5]] working days of the assessment | This procedure |
Treatment decision for a risk outside appetite | Within [[30]] calendar days of the risk first being assessed outside appetite; later reviews do not restart the window | RM-06 |
Triggered reassessment | Within [[10]] working days of the trigger | RM-10 |
Owner review | Every risk, every quarter | RM-09 |
Whole-register reassessment | Once a year | RM-09 |
Quarterly report | Within [[10]] working days of quarter end | RM-12 |
RMM-01 Risks outside appetite and past tolerance | Zero past tolerance; outside appetite each with a treatment decision | RM-12 |
RMM-02 Treatment actions overdue | Zero older than 30 days | RM-12 |
RMM-03 Acceptances past review | Zero | RM-12 |
RMM-04 Risks not reviewed this quarter | Zero | RM-12 |
Guidance — delete before approval
Targets marked "This procedure" are not in the Risk Assessment Methodology & Scoring Model. You may change them; check that a new risk can still be assessed and, if outside appetite, decided within the RM-06 window.
Escalation
When | Escalated to | By | Basis |
|---|---|---|---|
No treatment decision within the RM-06 window | Executive management | Head of Information Security | RM-06 |
Owner disputed or refused | Executive management | Head of Information Security | RM-02 |
Ratings disputed between assessor and owner | Head of Information Security | Assessor | Step 11 |
A risk moves outside tolerance, or a residual risk is Critical | Board chair, out of cycle | Head of Information Security | RM-08; Board Cybersecurity Reporting pack |
Owner review not done by quarter end | The owner's line executive; named in the quarterly report (RMM-04) | Assessor | RM-09 |
Triggered reassessment not done in time | Head of Information Security | Assessor | RM-10 |
A service provider does not supply evidence or information | [[Supplier or contract manager]] | Assessor | Service agreement |
An escalation names the risk, its band and position, the date missed and the decision needed. It asks for a decision, not just attention.
Evidence retained
Evidence | Shows | Minimum retention |
|---|---|---|
Register, with its history | Every risk assessed, owned and reviewed (RM-09, RM-11) | [[Permanently; closed entries included]] |
Assessment working and reasons for ratings | Consistent, comparable results (RM-03) | [[3 years after closure]] |
Control evidence used for residual ratings | Only working controls counted | [[3 years]] |
Treatment decisions and acceptances | Decisions on time and at the right level (RM-06, RM-08) | [[3 years after closure]] |
Trigger records and reassessments | Triggers acted on in time (RM-10) | [[3 years]] |
Quarterly reports and annual reassessment | Reporting and review (RM-09, RM-12) | [[5 years]] |
Guidance — delete before approval
An auditor typically picks a few risks and asks for the source, the scenario, the ratings with reasons, the control evidence, the treatment decision and the last owner review. Test this yourself each quarter on three risks, including one reassessed after a trigger.
Related documents
Document | Relationship |
|---|---|
Risk Assessment Methodology & Scoring Model | The rules this procedure runs (RM-01 to RM-12), the scales, matrix and positions |
Cyber Risk Appetite Statement Template | Appetite and tolerance by category (step 12) |
Information Security Risk Register | Where every risk is recorded (steps 14, 19, 29) |
Risk Assessment Workbook | Working for one assessment (steps 8 to 10) |
Risk Treatment Plan | Treatment actions (step 16) |
Risk Acceptance Form & Approval Record | Acceptances (step 17) |
Cyber Risk Scenario Library | Scenarios to start from (steps 2 and 5) |
Risk Reporting Dashboard | The quarterly report (step 21) |
Security Exception Register | Open exceptions, a source of known weaknesses |
Adapting this template
Guidance — delete before approval
Small organisation: a spreadsheet register and a shared mailbox are enough. Stages 2 to 5 can be one meeting with the owner. Keep the owner review every quarter, the trigger list and the RM-06 window; they are what an auditor tests. Where the assessor and the Head of Information Security are one person, have [[an external adviser]] check High and Critical ratings once a quarter.
Regulated entity (NIS2, DORA): record that this procedure is part of your ICT risk management framework. DORA Article 8 expects ICT-supported functions and assets to be identified and classified and reviewed at least yearly (8(1)), sources of ICT risk to be identified continuously and risk scenarios reviewed at least yearly (8(2)), and a risk assessment on each major change (8(3)): stage 1, step 22 and stage 8 do this. Delegated Regulation (EU) 2024/1774 Article 3(b) expects the assessment procedure to be documented. Under NIS2 Article 21(1), the measures chosen must be proportionate to the risks this procedure finds.
Personal data: where a risk involves personal data, assess it with the data protection lead, and take account of the risks presented by the processing itself (GDPR Article 32(2)). A data protection impact assessment feeds the register rather than keeping its own list.
IT run by a service provider: the provider supplies incidents, test results, control evidence and its own risks that affect your services, and may help assess. The owner, the ratings and the decisions stay with your organisation. Put the provider's duty to report triggers — incidents, major changes, new threats — within [[2]] working days into the service agreement.
Delete this section before approval.
Framework references
These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard. Editions referenced: ISO/IEC 27001:2022 incl. Amd 1:2024; NIST CSF 2.0; Directive (EU) 2022/2555 (NIS2); Regulation (EU) 2022/2554 (DORA); Delegated Regulation (EU) 2024/1774; Regulation (EU) 2016/679 (GDPR).
Framework | Reference | Supported by |
|---|---|---|
ISO/IEC 27001:2022 | Clause 6.1.2 — Information security risk assessment | Stages 1 to 5: identify, analyse and evaluate risks, with owners |
ISO/IEC 27001:2022 | Clause 8.2 — Information security risk assessment | Stages 7 and 8: assessment at planned intervals and on significant change |
ISO/IEC 27001:2022 | Annex A 5.7 — Threat intelligence | Stage 1: threat intelligence as a source |
NIST CSF 2.0 | ID.RA-03 — “Internal and external threats to the organization are identified and recorded” | Stage 1: threats identified and recorded |
NIST CSF 2.0 | ID.RA-05 — “Threats, vulnerabilities, likelihoods, and impacts are used to understand inherent risk and inform risk response prioritization” | Stages 3 and 4: inherent risk and prioritisation |
NIS2 — Directive (EU) 2022/2555 | Article 21(1) — appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems | Whole procedure; regulated-entity tailoring |
DORA — Regulation (EU) 2022/2554 | Article 8(1) — identify, classify and document ICT-supported business functions, information assets and ICT assets, reviewed at least yearly | Step 22: asset and service list reviewed yearly |
DORA — Regulation (EU) 2022/2554 | Article 8(2) — identify all sources of ICT risk on a continuous basis and review the risk scenarios at least yearly | Stage 1 and step 22: continuous identification; yearly review of scenarios |
DORA — Regulation (EU) 2022/2554 | Article 8(3) — perform a risk assessment upon each major change in systems, processes or procedures | Stage 8: assessment on major change |
DORA — Delegated Regulation (EU) 2024/1774 | Article 3(b) — a procedure and methodology for ICT risk assessment, with indicators to measure impact and likelihood | Whole procedure, as the documented assessment procedure |
GDPR — Regulation (EU) 2016/679 | Article 32(2) — in assessing the appropriate level of security, account is taken of the risks presented by processing | Step 8; personal data tailoring |
Definitions
Term | Meaning in this procedure |
|---|---|
Candidate risk | A possible risk noted from a source, not yet assessed. |
Calendar day | Every day, including weekends and public holidays. |
Owner review | The quarterly check by a risk's owner that its scenario, ratings, controls and actions are still right (RM-09). |
Position | Where a risk's residual band sits against its category's appetite and tolerance: Within appetite; Outside appetite, within tolerance; or Outside tolerance. |
Register | The Information Security Risk Register, the single record of assessed risks (RM-11). |
Residual rating | Impact and likelihood with the existing controls that are shown to work. |
Scenario | A risk written as a threat, the weakness it uses, the asset or service affected and the consequence (RM-01). |
Source | Anywhere risks are found: the asset list, threat intelligence, incidents, audits, exceptions, changes. |
Trigger | An event that forces reassessment of the risks it touches before the scheduled review (RM-10). |
Working day | Monday to Friday, excluding [[public holidays where you are]]. |