Cyber Risk Scenario Library
Supplies a starting population of realistic, well-formed risk scenarios so a new register does not begin empty or generic.
Available soon
- Format
- Excel
- Size
- 93 KB
- Length
- 12 sheets
- Version
- 1.1
- Updated
What's inside
- Instructions
- Scenario Library
- Threat List
- Pick for My Register
- Library Summary
- Scoring Guide
- Lists
- Definitions
- Framework References
Preview
The workbook's sheets as you will receive them, with its example rows and the values its formulas calculate. Highlighted [[text]] is for you to replace; rows marked EXAMPLE are for you to delete. Wide sheets scroll sideways. The cover, document control and changelog sheets are in the file.
Instructions
How to use this workbook
| Step | What to do |
|---|---|
| 1 | Read the Scenario Library. Each row is one scenario written the way the Risk Assessment Methodology & Scoring Model asks (RM-01): who or what could cause harm (threat), the weakness it would use, the asset or service it would hurt, and what would happen. Filter on Category, Threat type or Applies where to see the scenarios that fit you. |
| 2 | Leave out scenarios that cannot happen to you (Applies where helps), and keep the ones that can, even if you think they are well controlled: the register should show that a risk was considered and is under control, not only that it is high. |
| 3 | Change the wording to fit your organisation — name your own service, system or supplier. A scenario naming a real asset is a risk someone can own; a generic one is not. Add scenarios of your own on the blank rows; the Well-formed check (calc) tells you when one of the four parts is missing. |
| 4 | On Pick for My Register, delete the 12 EXAMPLE rows, then add one row per scenario you are taking: choose its Scenario ID, give it the register ID it will have (R-nn) and name its risk owner — the executive accountable for the service or asset it would hurt, not the security team (RM-02). Clear every Check (calc) that does not say OK. |
| 5 | The starting impact and likelihood are a starting point — assess for yourself. They are typical inherent levels (before your own controls) for a small or mid-sized organisation, judged against the methodology's anchors on the Scoring Guide sheet. Score each picked scenario properly in the Risk Assessment Workbook or directly in the Information Security Risk Register: impact on the worst consequence, likelihood over the next 12 months, before and after existing controls (RM-03). |
| 6 | Copy the picked rows (paste as values) into the Information Security Risk Register. The register is the single record of assessed risks (RM-11): this workbook is a source of scenarios, not a second list to maintain. |
| 7 | Review the library when you reassess the register — at least once a year (RM-09) — and when a trigger arrives, especially new threat intelligence: a new attack method that affects your services is a new scenario or a change of likelihood (RM-10). |
Legend
Yellow cells are inputs. Everything else is calculated or fixed — do not overwrite formulas.
| EXAMPLE | Rows marked EXAMPLE in the first column show how a completed row looks. Delete them before approval. |
Scales (Risk Assessment Methodology & Scoring Model). Impact: 1 Minor, 2 Moderate, 3 Major, 4 Severe. Likelihood: 1 Unlikely, 2 Possible, 3 Likely, 4 Almost certain. Score = impact × likelihood; bands: Low 1–3, Medium 4–6, High 8–9, Critical 12–16.
The library rows are the template's content, not examples: keep, change or remove them as you tailor it. The rows marked 'In the EXAMPLE register as' are the scenarios the example organisation (a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders) took into its register; their starting score is that register's inherent score. Only the rows on Pick for My Register marked EXAMPLE are to be deleted.
Tailoring — small organisation: start with the scenarios marked 'All organisations' and your own top services; 10 to 15 well-owned risks are better than 50 nobody reviews. Several scenarios share a cure (multi-factor authentication, tested backups, patching): one action can reduce many risks.
Tailoring — regulated entity: under NIS2 Article 21(1) and DORA Article 8(2) you are expected to identify sources of risk continuously and review risk scenarios at least yearly. Keep this library, your picks and the date of each review as evidence. Financial entities should add scenarios for each critical or important function and its ICT third-party providers. Where personal data is involved, GDPR Article 32 asks for security appropriate to the risk: the Data scenarios are a starting point for that judgement.
Tailoring — IT run by a service provider: many weaknesses sit with the provider. Keep the scenario and its owner inside your organisation, and ask the provider for the evidence behind the controls you rely on. The Third-party dependency scenarios and SC entries marked 'IT run by a service provider' apply directly.
Scenario Library
The library: 47 scenarios in 6 categories (RM-01). Starting impact and likelihood are a starting point — assess for yourself. Add your own scenarios on the blank rows at the foot.
| Scenario ID | Category ID | Category (calc) | Scenario title | Threat ID | Threat type (calc) | Threat — who or what | Weakness it uses | Asset or service affected | Consequence | Typical impact area | Likelihood drivers | Controls that usually reduce it | Applies where | Sector and size notes | Starting impact (1–4) | Starting likelihood (1–4) | Starting score (calc) | Starting band (calc) | In the EXAMPLE register as | Framework cross-references | Well-formed check (calc) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| SC-01 | RC-01 | Service availability | Ransomware takes online ordering offline for more than 2 days | TH-01 | Ransomware and extortion | Criminal ransomware group | The ordering platform cannot be restored from backup in less than 4 days | The online ordering service (60% of orders) | Loss of about €1.2m of orders per week; customer contracts breached | Service | Internet-facing systems or remote access without multi-factor authentication; backups reachable from the main network; slow or untested recovery; ransomware groups actively targeting the sector. | Backups isolated from the network and tested by a full restore; a recovery time agreed with the business and proven; multi-factor authentication on all remote and administrator access; endpoint detection and response; network separation. | All organisations | Impact is Severe wherever one service carries most of the revenue. The recovery time, not the attack, usually decides the impact. | 4 | 3 | 12 | Critical | R-01 | CSF ID.RA-03, ID.RA-04 | OK |
| SC-02 | RC-01 | Service availability | Ransomware spreads from warehouse office PCs to warehouse systems | TH-01 | Ransomware and extortion | 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 | Service | Office PCs and operational systems on one flat network; staff with local administrator rights; phishing reaching site staff. | Separate the office network from operational systems; remove local administrator rights; endpoint detection and response on both; offline backups of operational systems. | Several sites or warehouses | Also fits manufacturing and logistics sites with production or warehouse systems. Smaller if operational systems are cloud-hosted. | 3 | 3 | 9 | High | R-04 | CSF ID.RA-03, ID.RA-04 | OK |
| SC-03 | RC-01 | Service availability | Critical weaknesses on internet-facing systems exploited before they are fixed | TH-02 | Exploitation of unpatched or exposed systems | Attackers scanning the internet for known weaknesses | Critical security updates on internet-facing systems are applied later than the agreed deadline | Internet-facing systems (websites, ordering or customer portals, remote access) | Attacker gains a foothold for ransomware or data theft; service disrupted while systems are rebuilt | Service | Weaknesses being exploited within days of publication; a patching backlog; staff shortages; no list of what faces the internet. | An up-to-date list of internet-facing systems; patching deadlines by severity, with known-exploited weaknesses first; weekly external scanning; a web application firewall; tracking of on-time patching. | All organisations | Likelihood rises sharply when the on-time patching figure falls. The Vulnerability & Exposure Management pack sets the deadlines. | 3 | 3 | 9 | High | R-05 | CSF ID.RA-03, ID.RA-04 | OK |
| SC-04 | RC-01 | Service availability | Backups cannot restore a critical system | TH-12 | Technical or environmental failure | Any event that needs a system restored (ransomware, hardware failure, deletion) | Backups are taken but a full restore of the system has not been tested, or failed its test | Critical business systems and their data | The system cannot be recovered, or only after days, and some data is lost for good | Service | No restore test in the last year; backups of the data but not the configuration; backup job failures not monitored; the only copy online and reachable. | A restore test of each critical system at least yearly, timed against the agreed recovery time; monitoring of backup failures; one copy offline or immutable. | All organisations | Often rated Unlikely until a test fails. Score it after the last restore test, not before. | 4 | 2 | 8 | High | R-10 | CSF ID.RA-03, ID.RA-04 | OK |
| SC-05 | RC-01 | Service availability | Ransomware through remote desktop exposed to the internet | TH-01 | Ransomware and extortion | Criminal ransomware group | Remote desktop is reachable from the internet with password-only sign-in | Servers and the services they run | Servers encrypted and data stolen; services stopped until rebuilt from backup | Service | Remote desktop open to the internet; weak or reused passwords; no account lockout; seen in many small-organisation ransomware cases. | Close remote desktop to the internet and put it behind a gateway with multi-factor authentication; account lockout; alerting on failed sign-ins; offline backups. | Servers run on own premises | Common where a supplier opened remote access for support and it was never closed. Check with an external scan. | 4 | 3 | 12 | Critical | CSF ID.RA-03, ID.RA-04 | OK | |
| SC-06 | RC-01 | Service availability | Remote access gateway weakness exploited to enter the network | TH-02 | Exploitation of unpatched or exposed systems | Criminal groups and state-sponsored attackers | The VPN or remote access appliance is not patched within days of a critical vendor fix | The internal network behind the gateway | Attacker inside the network with no password needed, leading to ransomware or data theft | Service | Remote access appliances are among the most exploited products; fixes are often released after exploitation has begun; appliances managed by a supplier may be patched late. | Emergency patching of remote access appliances within days; subscribe to vendor security notices; multi-factor authentication; logging from the appliance to central monitoring; replace appliances out of vendor support. | All organisations | Treat a newly published critical weakness in your appliance as a trigger for reassessment. | 4 | 3 | 12 | Critical | CSF ID.RA-03, ID.RA-04 | OK | |
| SC-07 | RC-01 | Service availability | Denial of service makes the website or customer portal unusable | TH-06 | Denial of service | Extortionists or activists flooding the service with traffic | No denial-of-service protection in front of the public website or portal | Public website, customer portal or online ordering | Customers cannot reach the service for hours or days; lost sales and complaints | Service | Online revenue; high-profile events or sales periods; being in a sector targeted by activists; extortion demands seen by peers. | A denial-of-service protection service from the hosting or network provider; a tested plan to switch it on; a static fallback page; contacts with the provider. | Online sales or customer portal | Low impact for a brochure website. Much higher when a large share of orders or service is taken online. | 3 | 2 | 6 | Medium | CSF ID.RA-03, ID.RA-04 | OK | |
| SC-08 | RC-01 | Service availability | A failed change stops a core system | TH-08 | Human error | An administrator or supplier making a change | Changes to core systems are not reviewed, tested or given a way back | A core business system | The system is unavailable for hours while the change is undone; data may be damaged | Service | Changes made directly in live systems; no test environment; changes out of hours without a second person; supplier changes not notified. | A change process with review and a back-out plan; testing before release; changes in agreed windows; the provider's changes notified in advance. | All organisations | Not a cyber attack, but a leading cause of outages; include it where the risk register covers availability. | 3 | 2 | 6 | Medium | CSF ID.RA-03, ID.RA-04 | OK | |
| SC-09 | RC-01 | Service availability | Power or cooling failure in the server room stops on-site systems | TH-12 | Technical or environmental failure | Power cut, equipment failure or overheating | On-site servers without a tested backup power supply or cooling alarm | Systems hosted in the organisation's own server room | On-site systems stop and some hardware is damaged; recovery takes a day or more | Service | Ageing uninterruptible power supply batteries; a single air-conditioning unit; no temperature alert; the server room also used as a store. | Uninterruptible power supply tested yearly; temperature and power alerts to on-call staff; a generator or hosted fallback for critical systems; moving systems to hosted services. | Servers run on own premises | Falls away as systems move to cloud hosting; the equivalent there is a hosting region outage (Third-party dependency). | 3 | 2 | 6 | Medium | CSF ID.RA-03, ID.RA-04 | OK | |
| SC-10 | RC-01 | Service availability | Company domain hijacked or allowed to expire | TH-11 | Misconfiguration | An attacker taking over the domain registrar account, or a missed renewal | The registrar account has no multi-factor authentication and renewal depends on one person | The organisation's website and email domain | Website and email redirected or stopped; customers sent to a fake site; emails intercepted | Service | Registrar account in a former employee's name; renewal reminders going to an unread mailbox; no registry lock. | Registrar account under a shared role address with multi-factor authentication; automatic renewal for several years; registry lock on the main domains; a yearly check. | All organisations | Uncommon, but quick and severe when it happens. Easy to reduce at almost no cost. | 3 | 1 | 3 | Low | CSF ID.RA-03, ID.RA-04 | OK | |
| SC-11 | RC-02 | Customer and personal data | Customer data exposed through the ordering service | TH-02 | Exploitation of unpatched or exposed systems | Attackers targeting the customer database | A weakness in the ordering service's web application or its customer accounts | Customer records in the online ordering service | Customer personal data exposed at scale. Regulatory fine, notification cost and lost trade; about €0.8m | Data | A large customer database behind an internet-facing application; custom code; no recent security test; weak customer passwords. | Security testing of the application at least yearly and after major change; a web application firewall; encryption of the customer database; least access to customer data; monitoring of unusual data access. | Online sales or customer portal | Where personal data is involved GDPR Article 32 asks for security appropriate to the risk; a breach may also have to be notified. | 4 | 2 | 8 | High | R-03 | CSF ID.RA-03, ID.RA-04; GDPR 32(1) | OK |
| SC-12 | RC-02 | Customer and personal data | Cloud storage misconfigured and customer files exposed | TH-11 | Misconfiguration | Anyone who finds an open storage link, including automated scanners | Cloud storage set to public or shared by link, with no check of sharing settings | Customer files held in cloud storage | Customer files exposed to the internet; a notifiable data breach and customer complaints | Data | Storage created by teams outside IT; sharing by link as a habit; no policy blocking public sharing; no inventory of storage. | Block public sharing by default; a regular report of externally shared files; a cloud configuration check tool; an owner for each storage location. | Cloud services in use | One of the most common causes of reported data breaches. Scanners find open storage within hours. | 3 | 2 | 6 | Medium | R-11 | CSF ID.RA-03, ID.RA-04; GDPR 32(1) | OK |
| SC-13 | RC-02 | Customer and personal data | Customer data on an unencrypted laptop at the smaller warehouse site is lost or stolen | TH-09 | Loss or theft of equipment | Theft or loss of a laptop | Six older laptops at the smaller warehouse site are not encrypted: encrypting the old models before their March 2027 refresh would cost more than the risk | Customer delivery lists held on those laptops | Business customers' contact names and delivery addresses exposed; a data incident to assess for notification | Data | Unencrypted laptops; customer lists exported to laptops for convenience; laptops left in vehicles or unlocked offices. | Full-disk encryption on every laptop; device management able to wipe remotely; no customer exports to local drives; a quick way to report a lost device. | Several sites or warehouses | Low impact where only a few records are held; higher for large exports or sensitive data. | 2 | 2 | 4 | Medium | R-12 | CSF ID.RA-03, ID.RA-04; GDPR 32(1) | OK |
| SC-14 | RC-02 | Customer and personal data | Customer accounts taken over by credential stuffing | TH-05 | Password attacks on customer or staff accounts | Criminals trying passwords leaked from other websites | Customer login has no rate limiting, bot detection or optional multi-factor authentication | Customer accounts on the portal or ordering site | Accounts taken over, fraudulent orders placed, and customers' personal data exposed | Data | A large customer base; saved payment methods or credit accounts; login pages without protection against automated attempts. | Rate limiting and bot detection on login; checks against known leaked passwords; multi-factor authentication offered or required for business accounts; alerts on unusual sign-ins. | Online sales or customer portal | Rises with the value held in an account (credit terms, saved cards, loyalty points). | 3 | 3 | 9 | High | CSF ID.RA-03, ID.RA-04; GDPR 32(1) | OK | |
| SC-15 | RC-02 | Customer and personal data | Personal data sent to the wrong recipient by email | TH-08 | Human error | A member of staff making a mistake | Email addresses auto-complete and spreadsheets with personal data are sent as attachments without a check | Customer or employee personal data sent by email | Personal data disclosed to an outside party; a data incident to assess for notification | Data | High email volume; spreadsheet exports used for routine work; external recipients with similar names; no warning for external recipients. | A warning when sending outside the organisation; a short delay before sending; sharing links with access control instead of attachments; data loss prevention rules for bulk personal data. | All organisations | Frequent but usually small. Rate the impact on the largest routine export, not a single record. | 2 | 3 | 6 | Medium | CSF ID.RA-03, ID.RA-04; GDPR 32(1) | OK | |
| SC-16 | RC-02 | Customer and personal data | Lost or stolen phone gives access to work email and files | TH-09 | Loss or theft of equipment | Loss or theft of a phone | Phones used for work email are not managed: no enforced screen lock and no remote wipe | Work email and files on staff phones | Customer and internal information readable by whoever has the phone | Data | Staff use their own phones for work; no device management; long-lived sign-ins on phones. | Device management or app protection policies on phones with work data; enforced screen lock; remote wipe of work data; a quick way to report a lost phone. | All organisations | Usually Minor to Moderate impact; higher for executives and staff who handle sensitive data. | 2 | 3 | 6 | Medium | CSF ID.RA-03, ID.RA-04; GDPR 32(1) | OK | |
| SC-17 | RC-02 | Customer and personal data | Copy of live customer data exposed from a test system | TH-11 | Misconfiguration | Attackers or unauthorised staff reaching a less protected test environment | Test and development systems hold copies of live customer data with weaker security | Customer data copied into test systems | Customer personal data exposed from a system nobody watches | Data | Developers or suppliers refresh test systems from live; test systems open to the internet; test accounts with simple passwords. | Masked or synthetic data in test systems; the same access controls as live where real data must be used; test systems not reachable from the internet; a register of copies. | In-house software development | Also applies where a software supplier takes copies of live data to investigate problems. | 3 | 2 | 6 | Medium | CSF ID.RA-03, ID.RA-04; GDPR 32(1) | OK | |
| SC-18 | RC-02 | Customer and personal data | Card details skimmed by malicious code on the checkout page | TH-13 | Software and web supply-chain attack | Criminals injecting card-skimming code into the website | Third-party scripts on payment pages are not controlled or monitored | The website's checkout or payment page | Customers' card and personal details stolen over weeks; notification, card scheme costs and lost trust | Data | Payment details entered on the organisation's own page; many third-party scripts (analytics, chat, marketing); an e-commerce platform not kept up to date. | Use the payment provider's hosted payment page; an inventory of scripts on payment pages; content security policy; monitoring for changes to payment pages. | Card payments taken online | Largely removed where card details are entered only on the payment provider's own page. | 4 | 2 | 8 | High | CSF ID.RA-03, ID.RA-04; GDPR 32(1) | OK | |
| SC-19 | RC-02 | Customer and personal data | Staff see personal data they should not, through over-broad file shares | TH-11 | Misconfiguration | Curious or careless staff, or an attacker using any staff account | Shared folders holding HR or customer data are open to everyone in the organisation | HR records and customer data on shared drives | Personal data seen or copied by people without a need to know; complaints and a data incident | Data | Permissions granted to 'everyone' for convenience; no owner for each shared folder; no periodic access review. | An owner for each shared location; access by role or group; a yearly access review; a report of folders open to everyone. | All organisations | Also increases the impact of any single compromised account: the attacker sees everything that account sees. | 2 | 3 | 6 | Medium | CSF ID.RA-03, ID.RA-04; GDPR 32(1) | OK | |
| SC-20 | RC-03 | Financial fraud | Payment fraud through a compromised supplier email account | TH-04 | Payment and invoice fraud | A fraudster who has taken over a supplier's email account | Changes to supplier bank details are accepted by email without a call-back | Supplier payments | Single losses of €50k to €400k; not recoverable once paid | Financial | Suppliers with weak email security; changes to bank details accepted by email; urgent payment runs; attacks on the sector reported. | Call-back to a known number for every change of bank details; a payment verification service; two people to approve new or changed payees; staff awareness for the finance team. | All organisations | Losses are rarely recovered once paid. Likelihood is high for any organisation paying many suppliers. | 3 | 4 | 12 | Critical | R-02 | CSF ID.RA-03, ID.RA-04 | OK |
| SC-21 | RC-03 | Financial fraud | Executive impersonated to order an urgent payment | TH-04 | Payment and invoice fraud | A fraudster posing as a senior executive by email, message or cloned voice | Urgent payment requests from senior people are acted on without an independent check | Payments made by the finance team | Money paid to the fraudster; single losses up to the payment limit | Financial | Executives' names and travel visible online; a culture of acting quickly on senior requests; payments approved by one person. | A rule that no payment is made on an email or message alone; call-back to a known number; two-person approval above a threshold; awareness for finance and executive assistants. | All organisations | Voice cloning has made telephone requests less reliable; the check must use a number already on file. | 3 | 3 | 9 | High | CSF ID.RA-03, ID.RA-04 | OK | |
| SC-22 | RC-03 | Financial fraud | Finance mailbox taken over and customers told to pay a new account | TH-03 | Phishing and account takeover | A criminal who has taken over a finance mailbox | Finance mailboxes without multi-factor authentication; no alert on new mail forwarding rules | Customer invoicing and receipts | Customers pay the fraudster; the money is lost to the organisation or disputed with customers | Financial | Phishing aimed at finance staff; invoices sent by email; customers not told how bank details are changed. | Multi-factor authentication on all mailboxes; alerts on new forwarding rules; invoices stating that bank details never change by email; customers asked to confirm by phone. | All organisations | The loss may fall on the customer, but the relationship damage falls on the organisation. | 3 | 2 | 6 | Medium | CSF ID.RA-03, ID.RA-04 | OK | |
| SC-23 | RC-03 | Financial fraud | Salary diverted after a fake request to change bank details | TH-04 | Payment and invoice fraud | A fraudster posing as an employee | Payroll accepts changes of bank details by email | Payroll | An employee's salary paid to the fraudster; repaid by the organisation | Financial | Payroll changes by email; staff names and roles visible on social media; no confirmation to the employee. | Bank details changed only through the HR system after sign-in, or confirmed in person or by call-back; a notice to the employee's known address when details change. | All organisations | Usually small single losses, but frequent. | 2 | 3 | 6 | Medium | CSF ID.RA-03, ID.RA-04 | OK | |
| SC-24 | RC-03 | Financial fraud | Online banking credentials stolen and fraudulent transfers made | TH-03 | Phishing and account takeover | Criminals using malware or a fake banking site | Online banking used from general-purpose PCs, with one person able to create and release payments | The organisation's bank accounts | Large fraudulent transfers before they are noticed | Financial | Finance PCs used for email and browsing; banking tokens left connected; single-person release of payments. | Two-person release of payments in the banking platform; payment limits; banking from a dedicated or locked-down device; bank alerts for new payees. | All organisations | Banks' own controls make this rarer than it was, but the impact of one success is Severe. | 4 | 1 | 4 | Medium | CSF ID.RA-03, ID.RA-04 | OK | |
| SC-25 | RC-03 | Financial fraud | Refunds or credit notes manipulated by an employee | TH-07 | Malicious insider | A dishonest employee | Refunds and credit notes can be raised and approved by the same person | Customer refunds and credits in the ordering or finance system | Money paid out to accounts the employee controls, over months before it is noticed | Financial | Single-person refunds; no report of refunds by user; staff under financial pressure. | Separation of raising and approving refunds above a limit; a monthly report of refunds by user reviewed by a manager; refunds only to the original payment method. | Online sales or customer portal | See the Segregation of Duties Conflict Matrix in the P02 pack for the duties to keep apart. | 2 | 2 | 4 | Medium | CSF ID.RA-03, ID.RA-04 | OK | |
| SC-26 | RC-04 | Regulatory compliance | Significant incident not reported to the authority on time (NIS2) | TH-15 | Failure to meet a legal or regulatory obligation | A significant incident, whatever its cause | No agreed way to decide quickly whether an incident is significant and who reports it | The organisation's reporting obligation to the national authority | Early warning or notification made late; enforcement and loss of trust with the authority | Legal and regulatory | Incidents out of hours; unclear significance criteria; the reporting decision depending on one person; incidents handled by a supplier. | Written significance criteria; an incident procedure that names who decides and who reports; the authority's reporting route tested; the provider's contract requiring prompt notice. | Entities in scope of NIS2 | NIS2 sets short reporting deadlines for significant incidents; check the national law for the exact steps. | 2 | 2 | 4 | Medium | R-08 | CSF ID.RA-03, ID.RA-04; NIS2 21(1) | OK |
| SC-27 | RC-04 | Regulatory compliance | Personal data breach not notified to the data protection authority in time | TH-15 | Failure to meet a legal or regulatory obligation | Any personal data breach | No procedure to assess a breach and decide on notification within the legal deadline | The organisation's notification obligations as a controller | Late or missing notification; a fine and an investigation on top of the breach itself | Legal and regulatory | Breaches found by staff who do not know to report them; no data protection lead; breaches at processors reported late. | A breach procedure with an assessment template; staff told how to report; processors contractually bound to notify promptly; a breach log kept. | All organisations | Applies wherever personal data is processed. The notification deadline runs from when the organisation becomes aware. | 3 | 2 | 6 | Medium | CSF ID.RA-03, ID.RA-04 | OK | |
| SC-28 | RC-04 | Regulatory compliance | Major ICT-related incident not classified and reported on time | TH-15 | Failure to meet a legal or regulatory obligation | A major ICT-related incident | Classification criteria and reporting steps are not built into incident handling | The financial entity's reporting obligation to its supervisor | Initial notification late; supervisory findings and closer oversight | Legal and regulatory | Classification criteria not applied during the incident; outsourced ICT providers slow to share facts; reporting templates unfamiliar. | Classification criteria in the incident procedure; a named reporting owner and deputy; provider contracts requiring timely facts; a yearly reporting exercise. | Financial entities (DORA) | For financial entities under DORA. The reporting deadlines are short; practise them. | 3 | 2 | 6 | Medium | CSF ID.RA-03, ID.RA-04; DORA 8(2) | OK | |
| SC-29 | RC-04 | Regulatory compliance | Card data security requirements not met | TH-15 | Failure to meet a legal or regulatory obligation | A card payment security assessment, or a card breach | The payment environment has drifted from the card industry's security standard (PCI DSS) | The ability to take card payments | Fines or higher fees from the acquiring bank; in the worst case, card acceptance withdrawn | Legal and regulatory | Card details handled on own systems or phone lines; no one owning card security; the annual self-assessment done as a formality. | Reduce scope by using the payment provider's hosted pages and terminals; an owner for card security; the yearly self-assessment done with evidence. | Card payments taken online | Much smaller when card details never touch the organisation's own systems. | 3 | 2 | 6 | Medium | CSF ID.RA-03, ID.RA-04 | OK | |
| SC-30 | RC-04 | Regulatory compliance | Controls cannot be evidenced to a regulator, auditor or customer | TH-15 | Failure to meet a legal or regulatory obligation | An audit, supervisory review or customer assessment | Security activities happen but leave no record: reviews, tests and approvals are not kept | Certification, regulatory standing and customer contracts | Findings, a failed audit or a lost tender; remediation under time pressure | Legal and regulatory | Informal ways of working; evidence held in personal mailboxes; staff turnover; no calendar of recurring controls. | A calendar of recurring control activities with an owner each; evidence kept in one place; a yearly internal check before the external one. | All organisations | Most common in organisations new to certification or regulation. | 2 | 3 | 6 | Medium | CSF ID.RA-03, ID.RA-04 | OK | |
| SC-31 | RC-04 | Regulatory compliance | Personal data transferred abroad without a lawful basis for the transfer | TH-15 | Failure to meet a legal or regulatory obligation | A new supplier or tool processing personal data outside the EEA | Suppliers are chosen without a check of where they process personal data | Personal data processed by suppliers | An unlawful transfer; orders to stop processing and possible fines | Legal and regulatory | Teams buying online tools directly; suppliers using sub-processors abroad; no data protection review in purchasing. | A data protection check in purchasing; a register of processors and where they process; standard transfer clauses where needed. | All organisations | Applies to organisations subject to GDPR that use cloud or software services. | 3 | 2 | 6 | Medium | CSF ID.RA-03, ID.RA-04 | OK | |
| SC-32 | RC-04 | Regulatory compliance | Security commitments in customer contracts are not met | TH-15 | Failure to meet a legal or regulatory obligation | A customer audit, questionnaire or incident | Sales agree security terms without checking them against what the organisation actually does | Customer contracts and renewals | Breach of contract, penalties or termination; loss of a major customer | Legal and regulatory | Large customers imposing their own security schedules; no review of contracts by security; commitments not tracked. | Security review of non-standard security terms before signature; a register of commitments with owners; a standard security schedule to offer instead. | All organisations | Most relevant to suppliers of services to larger or regulated customers. | 3 | 2 | 6 | Medium | CSF ID.RA-03, ID.RA-04 | OK | |
| SC-33 | RC-05 | Third-party dependency | Managed IT provider fails or is compromised | TH-10 | Supplier failure or compromise | An attack on, or failure of, the managed IT provider | The provider holds privileged access to all systems, and there is no plan for its failure | Every system the provider manages | Systems stopped or compromised through the provider; recovery depends on the provider | Service | Provider access with standing administrator rights; attacks on managed service providers to reach their customers; a small provider with few staff. | Provider access through named accounts with multi-factor authentication and logging; security terms and a right to audit in the contract; an exit plan; insurance or contractual liability (transfer). | IT run by a service provider | The treatment is often partly Transfer (contract and insurance), but the risk owner still owns the risk. | 3 | 2 | 6 | Medium | R-06 | CSF ID.RA-03, ID.RA-04 | OK |
| SC-34 | RC-05 | Third-party dependency | Supplier holding our customer data is breached | TH-10 | Supplier failure or compromise | Attackers targeting a supplier | Suppliers receiving personal data are not assessed for security before or during the contract | Customer or employee data held by suppliers | Our customers' data exposed through a supplier; we remain responsible as controller | Data | Many suppliers with copies of personal data; no supplier security assessment; data shared beyond what the supplier needs. | Security assessment of suppliers that receive personal data; data processing terms; share the minimum data; ask for incident notification within a set time. | All organisations | Common with marketing, payroll, delivery and software suppliers. | 3 | 2 | 6 | Medium | CSF ID.RA-03, ID.RA-04; GDPR 32(1) | OK | |
| SC-35 | RC-05 | Third-party dependency | Cloud or software service outage stops a core business activity | TH-12 | Technical or environmental failure | An outage at a cloud or software provider | A core activity depends on one provider or hosting region with no fallback | A core business service hosted by a provider | The activity stops until the provider recovers; hours to days | Service | Single-region hosting; no manual workaround; provider service levels that do not match business needs. | Know each core service's provider and its recovery commitments; a manual workaround for critical activities; multi-region or failover where the impact justifies the cost. | Cloud services in use | Rate impact on your own tolerance for the outage, not the provider's service level. | 3 | 2 | 6 | Medium | CSF ID.RA-03, ID.RA-04 | OK | |
| SC-36 | RC-05 | Third-party dependency | Malware delivered through a compromised software update | TH-13 | Software and web supply-chain attack | Attackers who have compromised a software vendor | Vendor updates are installed automatically on critical systems with no monitoring | Systems running the vendor's software | Attacker access to many systems at once through trusted software | Service | Widely used management or monitoring software with high privileges; automatic updates; no detection on servers. | Endpoint detection and response on servers; least privilege for vendor software; staged updates on critical systems; vendor security notices followed. | All organisations | Uncommon but high impact; the controls that limit it also limit ransomware. | 4 | 1 | 4 | Medium | CSF ID.RA-03, ID.RA-04 | OK | |
| SC-37 | RC-05 | Third-party dependency | Critical supplier stops trading or ends the service | TH-10 | Supplier failure or compromise | A supplier failing or withdrawing a product | No exit plan and no copy of our data in a usable form | A service provided by one supplier | The service lost at short notice; costly emergency replacement; data hard to recover | Service | Small or financially weak suppliers; products near end of life; contracts without exit terms. | An exit plan for each critical supplier; regular export of our data; contract terms for termination assistance; watch for signs of supplier distress. | All organisations | DORA expects exit strategies for ICT services supporting critical or important functions. | 3 | 1 | 3 | Low | CSF ID.RA-03, ID.RA-04 | OK | |
| SC-38 | RC-05 | Third-party dependency | Payment provider outage stops online payments | TH-12 | Technical or environmental failure | An outage at the payment service provider | One payment provider with no alternative way to take payment | Online payments | Orders cannot be completed while the outage lasts; lost sales | Financial | Peak trading periods; one provider; no invoice or account payment option. | An alternative payment route (a second provider, or payment on account for business customers); provider status monitoring; a customer message ready. | Card payments taken online | Mostly a revenue risk; impact depends on the length of outage you can absorb. | 3 | 2 | 6 | Medium | CSF ID.RA-03, ID.RA-04 | OK | |
| SC-39 | RC-05 | Third-party dependency | Supplier's remote access account used to break in | TH-03 | Phishing and account takeover | An attacker who has compromised a supplier or its credentials | Suppliers have always-on remote access with shared accounts and no multi-factor authentication | Systems the supplier supports | Attacker inside the network with the supplier's rights; ransomware or data theft | Service | Many suppliers with remote access; shared supplier accounts; access not removed when the contract ends. | Supplier access switched on only when needed; named accounts with multi-factor authentication; session logging; a quarterly review of supplier accounts. | IT run by a service provider | Also applies to equipment vendors with remote support access to warehouse or building systems. | 3 | 2 | 6 | Medium | CSF ID.RA-03, ID.RA-04 | OK | |
| SC-40 | RC-06 | People and insider | Administrator misuses privileged access | TH-07 | Malicious insider | An administrator acting deliberately against the organisation | Administrators hold standing privileged access and their activity is not reviewed by anyone else | Systems and data under administrator control | Data stolen, changed or destroyed, and the traces removed | Data | Few administrators with full rights; shared administrator accounts; disgruntlement or financial pressure; no independent log review. | Named administrator accounts separate from daily accounts; least privilege; logs sent where administrators cannot change them; a second person reviews privileged activity. | All organisations | See the Segregation of Duties Conflict Matrix in the P02 pack for administration and log review. | 3 | 2 | 6 | Medium | R-07 | CSF ID.RA-03, ID.RA-04; GDPR 32(1) | OK |
| SC-41 | RC-06 | People and insider | Staff account taken over through phishing | TH-03 | Phishing and account takeover | Phishing emails and fake sign-in pages | Staff accounts protected by password only, or by multi-factor methods that can be phished | Staff email and cloud accounts | Attacker reads and sends email as the member of staff, and uses the account to reach data or to launch fraud | Data | High volume of phishing; staff working from phones; no multi-factor authentication; legacy sign-in methods left open. | Multi-factor authentication for every account, phishing-resistant for administrators and finance; block legacy sign-in; phishing awareness; alerts on risky sign-ins. | All organisations | Likelihood stays high for almost everyone; the controls mostly reduce what an attacker can do with the account. | 2 | 4 | 8 | High | R-09 | CSF ID.RA-03, ID.RA-04; GDPR 32(1) | OK |
| SC-42 | RC-06 | People and insider | Departing employee takes customer data | TH-07 | Malicious insider | An employee leaving for a competitor | Staff can export or download customer data in bulk, and exports are not monitored | Customer lists, pricing and contracts | Customers approached by a competitor; a data incident; legal costs | Data | Sales staff with full customer exports; personal cloud storage allowed; long notice periods with full access. | Limit bulk exports to those who need them; block personal cloud storage; review exports and access when notice is given; confidentiality terms enforced. | All organisations | Often discovered only when customers mention being approached. | 3 | 2 | 6 | Medium | CSF ID.RA-03, ID.RA-04; GDPR 32(1) | OK | |
| SC-43 | RC-06 | People and insider | Leaver's account still active and used after they leave | TH-07 | Malicious insider | A former employee, or an attacker using their credentials | Accounts are not disabled on the last working day, and cloud services are missed | Email, cloud services and business systems | Data accessed or changed by someone no longer entitled to it | Data | HR not telling IT promptly; accounts in services outside single sign-on; contractors not tracked. | A leaver process triggered by HR with a same-day deadline; single sign-on for cloud services; a monthly check of active accounts against the staff list. | All organisations | An access review regularly finds these; count them to judge the likelihood. | 2 | 2 | 4 | Medium | CSF ID.RA-03, ID.RA-04; GDPR 32(1) | OK | |
| SC-44 | RC-06 | People and insider | Important data deleted by mistake and not recoverable | TH-08 | Human error | A member of staff or administrator making a mistake | Broad delete rights on shared data, and retention or version history switched off | Shared files, mailboxes or a business database | Data lost for good or restored only in part; work redone | Data | Sync tools that spread deletions; clean-up scripts run in live systems; cloud services assumed to keep backups. | Version history and recycle-bin retention on shared storage; backup of cloud data (the provider may not keep it); least privilege for bulk deletion. | All organisations | Cloud services protect their own availability, not your data from your own mistakes. | 3 | 2 | 6 | Medium | CSF ID.RA-03, ID.RA-04; GDPR 32(1) | OK | |
| SC-45 | RC-06 | People and insider | Only one person can run or recover a critical system | TH-14 | Loss of key people or knowledge | The key person leaving, being ill or unreachable | Knowledge and access for a critical system sit with one person, with no documentation | A critical system | Faults and incidents last longer; changes and patching stall | Service | Small IT team; bespoke systems; knowledge never written down; no deputy. | Named deputies; recovery and operating procedures written down and tested by someone else; emergency access held securely; supplier support as a backstop. | All organisations | Often the real cause behind slipping patching or slow recovery: check the other scenarios for it. | 3 | 2 | 6 | Medium | CSF ID.RA-03, ID.RA-04 | OK | |
| SC-46 | RC-06 | People and insider | Confidential data pasted into unapproved online tools | TH-08 | Human error | Staff using online AI or file-sharing tools to get work done | No approved alternative and no guidance on what may be shared | Customer, employee and commercial information | Confidential or personal data held by a third party outside any contract | Data | Easy-to-use free tools; pressure to work faster; no approved business version; no guidance. | Approved tools with business terms; clear guidance on what may be shared; blocking of unapproved file-sharing where needed; awareness. | All organisations | Usually Moderate impact; higher where staff handle special category or client-confidential data. | 2 | 3 | 6 | Medium | CSF ID.RA-03, ID.RA-04; GDPR 32(1) | OK | |
| SC-47 | RC-06 | People and insider | Service desk tricked into resetting a password or multi-factor authentication | TH-03 | Phishing and account takeover | An attacker phoning the service desk while posing as a member of staff | Callers are verified on information an attacker can find | Staff accounts, including administrators | Attacker controls a staff or administrator account and bypasses multi-factor authentication | Service | Outsourced service desk; pressure to resolve calls quickly; executives' details public. | Strong caller verification (call back on a known number, manager confirmation); extra checks for administrator and executive accounts; alerts to the user on resets. | IT run by a service provider | A method used in several well-known ransomware attacks on large organisations. | 3 | 2 | 6 | Medium | CSF ID.RA-03, ID.RA-04 | OK |
Threat List
What could cause harm. The Risk Assessment Workbook's threat checklist uses the same list. Add your own threats here and on the Lists sheet.
| Threat ID | Threat type | What it looks like | Scenarios in the library (calc) | Starting band High or Critical (calc) |
|---|---|---|---|---|
| TH-01 | Ransomware and extortion | Criminals get in, steal data and encrypt systems, then demand payment to restore them or not to publish what they took. | 3 | 3 |
| TH-02 | Exploitation of unpatched or exposed systems | Attackers use a known weakness in an internet-facing system (remote access gateway, web server, remote desktop) before it is fixed. | 3 | 3 |
| TH-03 | Phishing and account takeover | A member of staff is tricked into giving away a password or approving a sign-in, and the attacker uses their account. | 5 | 1 |
| TH-04 | Payment and invoice fraud | A fraudster impersonates a supplier, an executive or an employee to have money paid to the wrong bank account (business email compromise). | 3 | 2 |
| TH-05 | Password attacks on customer or staff accounts | Attackers try passwords leaked from other websites, or guess common ones, against login pages (credential stuffing). | 1 | 1 |
| TH-06 | Denial of service | A flood of traffic makes a website or online service unusable, sometimes with a demand for payment to stop. | 1 | 0 |
| TH-07 | Malicious insider | Someone with legitimate access — an employee, contractor or administrator — misuses it to steal, change or destroy information or money. | 4 | 0 |
| TH-08 | Human error | A mistake by someone with legitimate access: data sent to the wrong person, files deleted, a change that breaks a system. | 4 | 0 |
| TH-09 | Loss or theft of equipment | A laptop, phone or storage device holding the organisation's information is lost, stolen or not returned. | 2 | 0 |
| TH-10 | Supplier failure or compromise | A supplier the organisation depends on is attacked, has an outage, or stops trading, and its problem becomes the organisation's. | 3 | 0 |
| TH-11 | Misconfiguration | A system or cloud service is set up so that information or access is open to people who should not have it. | 4 | 0 |
| TH-12 | Technical or environmental failure | Hardware, power, cooling, a hosting region or a failed recovery stops a service, with no attacker involved. | 4 | 1 |
| TH-13 | Software and web supply-chain attack | Malicious code arrives through a trusted route: a vendor's software update, a code library, or a script on the organisation's own website. | 2 | 1 |
| TH-14 | Loss of key people or knowledge | The only people who can run, fix or recover a system leave or are unavailable when needed. | 1 | 0 |
| TH-15 | Failure to meet a legal or regulatory obligation | A deadline, notification or requirement under law, regulation or contract is missed, whatever the underlying event. | 7 | 0 |
Pick for My Register
One row per scenario you take into your register. Yellow columns are yours; the rest calculate. Delete the 12 EXAMPLE rows first: they show the example organisation's register starting from the library.
| Example | Register ID | Scenario ID | Scenario title (calc) | Category ID (calc) | Category (calc) | Risk owner | Starting impact (calc) | Starting likelihood (calc) | Starting score (calc) | Starting band (calc) | Check (calc) | Notes |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE | R-01 | SC-01 | Ransomware takes online ordering offline for more than 2 days | RC-01 | Service availability | Chief Operating Officer | 4 | 3 | 12 | Critical | OK | Assessed in the EXAMPLE register: inherent 4 × 3 = 12; residual 4 × 2 = 8 (High), outside appetite, within tolerance. Treatment: Reduce. |
| EXAMPLE | R-02 | SC-20 | Payment fraud through a compromised supplier email account | RC-03 | Financial fraud | Chief Financial Officer | 3 | 4 | 12 | Critical | OK | Assessed in the EXAMPLE register: inherent 3 × 4 = 12; residual 3 × 3 = 9 (High), outside appetite, within tolerance. Treatment: Reduce. |
| EXAMPLE | R-03 | SC-11 | Customer data exposed through the ordering service | RC-02 | Customer and personal data | Chief Operating Officer | 4 | 2 | 8 | High | OK | Assessed in the EXAMPLE register: inherent 4 × 2 = 8; residual 4 × 1 = 4 (Medium), within appetite. Treatment: Reduce. |
| EXAMPLE | R-04 | SC-02 | Ransomware spreads from warehouse office PCs to warehouse systems | RC-01 | Service availability | Head of Logistics | 3 | 3 | 9 | High | OK | Assessed in the EXAMPLE register: inherent 3 × 3 = 9; residual 2 × 2 = 4 (Medium), within appetite. Treatment: Reduce. |
| EXAMPLE | R-05 | SC-03 | Critical weaknesses on internet-facing systems exploited before they are fixed | RC-01 | Service availability | Head of IT | 3 | 3 | 9 | High | OK | Assessed in the EXAMPLE register: inherent 3 × 3 = 9; residual 3 × 2 = 6 (Medium), within appetite. Treatment: Reduce. |
| EXAMPLE | R-06 | SC-33 | Managed IT provider fails or is compromised | RC-05 | Third-party dependency | Head of IT | 3 | 2 | 6 | Medium | OK | Assessed in the EXAMPLE register: inherent 3 × 2 = 6; residual 3 × 1 = 3 (Low), within appetite. Treatment: Transfer. |
| EXAMPLE | R-07 | SC-40 | Administrator misuses privileged access | RC-06 | People and insider | Head of IT | 3 | 2 | 6 | Medium | OK | Assessed in the EXAMPLE register: inherent 3 × 2 = 6; residual 3 × 1 = 3 (Low), within appetite. Treatment: Reduce. |
| EXAMPLE | R-08 | SC-26 | Significant incident not reported to the authority on time (NIS2) | RC-04 | Regulatory compliance | Head of Information Security | 2 | 2 | 4 | Medium | OK | Assessed in the EXAMPLE register: inherent 2 × 2 = 4; residual 2 × 1 = 2 (Low), within appetite. Treatment: Reduce. |
| EXAMPLE | R-09 | SC-41 | Staff account taken over through phishing | RC-06 | People and insider | HR Director | 2 | 4 | 8 | High | OK | Assessed in the EXAMPLE register: inherent 2 × 4 = 8; residual 2 × 3 = 6 (Medium), within appetite. Treatment: Reduce. |
| EXAMPLE | R-10 | SC-04 | Backups cannot restore a critical system | RC-01 | Service availability | Head of IT | 4 | 2 | 8 | High | OK | Assessed in the EXAMPLE register: inherent 4 × 2 = 8; residual 4 × 1 = 4 (Medium), within appetite. Treatment: Reduce. |
| EXAMPLE | R-11 | SC-12 | Cloud storage misconfigured and customer files exposed | RC-02 | Customer and personal data | Head of IT | 3 | 2 | 6 | Medium | OK | Assessed in the EXAMPLE register: inherent 3 × 2 = 6; residual 3 × 1 = 3 (Low), within appetite. Treatment: Reduce. |
| EXAMPLE | R-12 | SC-13 | Customer data on an unencrypted laptop at the smaller warehouse site is lost or stolen | RC-02 | Customer and personal data | Head of Logistics | 2 | 2 | 4 | Medium | OK | Assessed in the EXAMPLE register: inherent 2 × 2 = 4; residual 2 × 2 = 4 (Medium), within appetite. Treatment: Accept. |
Library Summary
Library and picks summary
Calculated from the Scenario Library and Pick for My Register. EXAMPLE picks are counted until you delete them.
Checks
| Check | Result | Target | Status |
|---|---|---|---|
| Library rows with a Well-formed check to resolve | 0 | 0 | OK |
| Picks with a Check to resolve | 0 | 0 | OK |
| Scenarios picked more than once | 0 | 0 | OK |
| Picks with no risk owner | 0 | 0 | OK |
By category
| Category | In the library | Starting Low | Starting Medium | Starting High | Starting Critical | Picked |
|---|---|---|---|---|---|---|
| RC-01 Service availability | 10 | 1 | 3 | 3 | 3 | 4 |
| RC-02 Customer and personal data | 9 | 0 | 6 | 3 | 0 | 3 |
| RC-03 Financial fraud | 6 | 0 | 4 | 1 | 1 | 1 |
| RC-04 Regulatory compliance | 7 | 0 | 7 | 0 | 0 | 1 |
| RC-05 Third-party dependency | 7 | 1 | 6 | 0 | 0 | 1 |
| RC-06 People and insider | 8 | 0 | 7 | 1 | 0 | 2 |
| All categories | 47 | 2 | 33 | 8 | 4 | 12 |
Starting bands are typical inherent levels, not your assessment. A category with nothing picked is worth a second look: is it really not a risk for you?
Scoring Guide
Scoring guide
The Risk Assessment Methodology & Scoring Model's anchors. The library's starting impact and likelihood were judged against them; judge yours the same way.
Impact — the worst consequence decides (RM-03)
| Area | 1 Minor | 2 Moderate | 3 Major | 4 Severe |
|---|---|---|---|---|
| Financial | less than [[€50,000]] | [[€50,000]] to [[€250,000]] | [[€250,000]] to [[€1,000,000]] | more than [[€1,000,000]] |
| Service | an internal service degraded for hours | a customer service degraded, or an internal service stopped, for up to [[1]] day | a core customer service stopped for up to [[2]] days | a core customer service stopped for more than [[2]] days |
| Data | internal, non-personal data | internal confidential data, or personal data of a few people | personal or customer data of [[hundreds]] of people, or commercially sensitive data | personal or customer data at scale |
| Legal and regulatory | no notification or breach | a minor breach of contract or policy, put right without penalty | a formal enquiry by a regulator or customer, or a contract breach with penalties | a notifiable breach, enforcement or contract termination |
| Reputation | not noticed outside the team | noticed by some customers or suppliers | complaints from several major customers, or regional or trade press | national press, or loss of a major customer |
Where personal data is involved, score the Data area on the worse of the harm to the organisation and the harm to the people whose data it is (GDPR Article 32).
Likelihood — the chance over the next 12 months (RM-03)
| Level | Chance | Signs | ||
|---|---|---|---|---|
| 1 Unlikely | less than [[20]]% in the next 12 months | Not seen at organisations like ours in recent years, or only with rare skill or access. | ||
| 2 Possible | [[20]]% to [[50]]% in the next 12 months | Happens regularly to organisations like ours; our controls make it harder but not rare. | ||
| 3 Likely | [[50]]% to [[90]]% in the next 12 months | Happening now to organisations like ours, or has happened to us, and the gap is still open. | ||
| 4 Almost certain | more than [[90]]% in the next 12 months, or already happening | Being attempted against us now, with little in the way. | ||
Score = impact × likelihood. Bands: Low 1–3, Medium 4–6, High 8–9, Critical 12–16.
Lists
| CategoryID | CategoryName | ThreatID | ThreatName | ImpactArea | AppliesWhere | BandName | BandMin |
|---|---|---|---|---|---|---|---|
| RC-01 | Service availability | TH-01 | Ransomware and extortion | Financial | All organisations | Low | 1 |
| RC-02 | Customer and personal data | TH-02 | Exploitation of unpatched or exposed systems | Service | Online sales or customer portal | Medium | 4 |
| RC-03 | Financial fraud | TH-03 | Phishing and account takeover | Data | Card payments taken online | High | 8 |
| RC-04 | Regulatory compliance | TH-04 | Payment and invoice fraud | Legal and regulatory | Servers run on own premises | Critical | 12 |
| RC-05 | Third-party dependency | TH-05 | Password attacks on customer or staff accounts | Reputation | Cloud services in use | ||
| RC-06 | People and insider | TH-06 | Denial of service | IT run by a service provider | |||
| TH-07 | Malicious insider | In-house software development | |||||
| TH-08 | Human error | Several sites or warehouses | |||||
| TH-09 | Loss or theft of equipment | Entities in scope of NIS2 | |||||
| TH-10 | Supplier failure or compromise | Financial entities (DORA) | |||||
| TH-11 | Misconfiguration | ||||||
| TH-12 | Technical or environmental failure | ||||||
| TH-13 | Software and web supply-chain attack | ||||||
| TH-14 | Loss of key people or knowledge | ||||||
| TH-15 | Failure to meet a legal or regulatory obligation |
Definitions
Definitions
| Term | Meaning in this workbook |
|---|---|
| Risk scenario | A short story of how harm could happen: a threat, the weakness it uses, the asset or service it affects, and the consequence (RM-01). A scenario is something an owner can act on; a single word such as 'ransomware' is not. |
| Threat | Who or what could cause harm: an attacker, a mistake, a failure or an event. The Threat List groups threats into types. |
| Weakness | The gap the threat would use: a missing or weak control, an exposed system, a process that relies on trust. |
| Asset or service | What would be hurt: a system, a set of information, or a business service. Name your own. |
| Consequence | What would happen to the organisation: money lost, a service stopped, data exposed, a legal breach, reputation damaged. |
| Impact area | One of the 5 kinds of consequence impact is judged on: Financial, Service, Data, Legal and regulatory, Reputation. Impact is scored on the worst of them (RM-03). |
| Impact 1 — Minor | Affects one system of Standard criticality or non-sensitive data; no customer or regulatory effect. |
| Impact 2 — Moderate | Affects a High criticality system or internal confidential data; limited, recoverable disruption. |
| Impact 3 — Major | Affects a Critical system, personal or customer data, or a regulated service; notifiable if it went wrong. |
| Impact 4 — Severe | Could stop a core business service, expose sensitive data at scale, or breach a legal obligation. |
| Likelihood 1 — Unlikely | Not reachable from the internet or by ordinary users; no known exploitation; strong compensating control in place. |
| Likelihood 2 — Possible | Reachable internally; exploitation needs skill or insider access. |
| Likelihood 3 — Likely | Reachable by many users or from partner networks; exploitation techniques are public. |
| Likelihood 4 — Almost certain | Internet-facing or known to be actively exploited, with no effective compensating control. |
| Starting impact and likelihood | A typical inherent level (before your own controls) for a small or mid-sized organisation. A starting point only — assess for yourself. |
| Inherent and residual | Inherent: the risk before your existing controls are counted. Residual: the risk with the controls you have today. |
| Score and band | Score = impact × likelihood (1 to 16). The band follows from the score: Low 1–3, Medium 4–6, High 8–9, Critical 12–16. |
| Likelihood drivers | What makes the scenario more likely: exposure, missing controls, how often attackers try it. |
| Applies where | The kind of organisation in which the scenario can arise. Filter on it to leave out what cannot happen to you. |
| Risk category | The six categories used across the pack: RC-01 Service availability; RC-02 Customer and personal data; RC-03 Financial fraud; RC-04 Regulatory compliance; RC-05 Third-party dependency; RC-06 People and insider. Each has an appetite set in the Cyber Risk Appetite Statement Template. |
| Risk owner | The executive accountable for the service or asset the risk would hurt, not the security team (RM-02). |
| Register ID | The risk's reference in the Information Security Risk Register (R-nn). |
| Threat intelligence | Information about current attacks and attackers, used to add scenarios and change likelihoods. |
| RM-nn | The rules in the Risk Assessment Methodology & Scoring Model. |
| (calc) | A column or cell the workbook calculates. Do not type or paste over it. |
| EXAMPLE row | A row on Pick for My Register showing the example organisation's register starting from the library. Delete before approval. |
Framework References
Framework references
These references indicate relevance only and do not reproduce the text of any standard.
| Framework | Reference | Supported by |
|---|---|---|
| ISO/IEC 27001:2022 | Clause 6.1.2 — Information security risk assessment | Scenario Library (RM-01 form, typical impact and likelihood); Pick for My Register |
| ISO/IEC 27001:2022 | Annex A 5.7 — Threat intelligence | Threat List; Instructions step 7 (new threat intelligence becomes a scenario or a change of likelihood) |
| NIST CSF 2.0 | ID.RA-03 — “Internal and external threats to the organization are identified and recorded” | Threat List; Scenario Library threat and weakness columns |
| NIST CSF 2.0 | ID.RA-04 — “Potential impacts and likelihoods of threats exploiting vulnerabilities are identified and recorded” | Scenario Library: typical impact area, likelihood drivers, starting impact and likelihood |
| 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 | The library as the set of risk scenarios reviewed at least yearly; Instructions step 7 |
| 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 | Tailoring for regulated entities; scenarios marked 'Entities in scope of NIS2' |
| GDPR — Regulation (EU) 2016/679 | Article 32(1) — appropriate technical and organisational measures to ensure a level of security appropriate to the risk, taking into account the likelihood and severity of risk to people's rights and freedoms | Scenarios whose typical impact is on personal data |
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)