Most cyber risk models run on estimates because the organisation never recorded what its own incidents and near misses actually cost. Quantified risk analysis, insurance limit decisions and key risk indicators all improve when they can draw on an internal loss event database: a consistent record of every cyber event that caused, or nearly caused, a loss. This guide explains how to build one: the taxonomy, the capture fields, thresholds, how to treat near misses, recoveries and grouped losses, how to map events to the Basel operational risk categories used in banking and to the DORA cost criteria, and how to feed the results into FAIR-style models. It is written for risk managers, CRQ analysts, incident managers and operational risk teams. For the modelling itself see the Cyber Risk Quantification Guide; this page covers the data underneath it.
Key takeaways
- Record events, not just breaches. A useful database holds losses, near misses and low-cost incidents, because frequency estimates depend on the small events as much as the large ones.
- Borrow proven structures. The Basel operational risk loss data standard (OPE25) and DORA's cost criteria already define gross loss, recoveries, dates and exclusions; cyber teams do not need to invent them.
- Three dates and two amounts are the core. Date of occurrence, discovery and accounting, plus gross loss and recoveries, make the data usable for frequency and severity models.
- Use a cause taxonomy you can map. Tag each event with a cyber cause (for example VERIS actions or ATT&CK tactics) and a Basel Level 1 or enterprise risk category, so one record serves security and operational risk.
- Completeness beats precision. An event with a ranged estimate and a named owner is worth more than a perfect figure for a quarter of incidents.
Why internal loss data matters
FAIR-based analysis needs Loss Event Frequency and Loss Magnitude for each scenario. Without internal data, both come from calibrated expert estimates and external studies whose populations rarely match yours. Internal loss data does three things that external data cannot: it shows your own frequency of minor events (phishing compromises, misdirected emails, short outages), it gives real costs in your currency and cost structure, and it reveals which controls failed. Over time it lets analysts back-test estimates: if the model said two credential compromise events a year and the database shows nine, the model is wrong. See the FAIR Model and Open FAIR Standard Guide for the factor definitions.
| Use of the data | What it needs from the database | Typical consumer |
|---|---|---|
| CRQ scenario inputs | Event counts per scenario type per year; cost ranges per loss form | CRQ analyst |
| Insurance limits and retentions | Severity distribution, especially the tail; costs net of recoveries | Risk manager, insurance buyer |
| Key risk indicators | Trends in near misses and low-cost events by cause | Risk committee |
| Control investment cases | Failed or missing control per event | CISO, architecture |
| Regulatory reporting | Gross costs, dates, classification against criteria such as DORA | Compliance, operational risk |
| Operational risk capital (banks) | Basel-compliant fields, thresholds and history | Operational risk function |
What counts as a loss event
- Loss event: a cyber event that produced a measurable financial impact, direct or indirect.
- Near miss: an event that could have caused a loss but did not, because a control worked late, the attacker failed, or luck intervened. Examples: credentials phished but blocked by MFA, ransomware staged but stopped before encryption, a misconfigured storage bucket found before anyone accessed it.
- Gain or zero-cost event: an event with no net cost, recorded so frequency counts stay complete.
- Timing event: a loss that shifts between accounting periods, such as a billing error corrected later. OPE25 includes material timing losses that span periods and give rise to legal risk.
- Grouped or recurring event: several events with one root cause. OPE25 paragraph 25.29 allocates losses from a common event posted over several years to the corresponding years, and DORA's classification regulation treats recurring incidents with the same apparent root cause, occurring at least twice within six months, as one major incident where together they meet the criteria (Delegated Regulation (EU) 2024/1772, Article 8(2)).
Near misses are where cyber data adds most value. They are far more frequent than losses, they show which controls are carrying the load, and they give the Vulnerability factor in FAIR (the probability that a threat event becomes a loss event) an evidence base. Record them with the same cause taxonomy as losses, with the loss field set to zero and a "potential loss" range estimated by the owner.
The capture fields
The fields below combine the OPE25 requirements, DORA's cost categories and the VERIS impact section. Keep mandatory fields short so incident handlers actually complete them.
| Field | Mandatory | Notes and source |
|---|---|---|
| Event ID, title, short description | Yes | Link to the incident ticket and post-incident review |
| Date of occurrence | Where known | OPE25 25.28 asks for occurrence where available; for cyber this is the earliest attacker activity found |
| Date of discovery | Yes | Gap between occurrence and discovery is itself a useful dwell-time metric |
| Date of accounting | Yes, when costs post | OPE25 25.28; for legal events no later than when a reserve is set up |
| Event type (cyber cause) | Yes | VERIS action (malware, hacking, social, misuse, physical, error, environmental) or your own list mapped to ATT&CK tactics |
| Basel Level 1 or ERM category | Yes for banks | OPE25 25.17 lets supervisors request mapping to Level 1 event types; document the allocation criteria |
| Asset and business service affected | Yes | Use the same service names as the business impact analysis |
| Identity involved | Recommended | Human, service account, API key, OAuth grant, AI agent; supports identity KRIs |
| Control that failed or worked | Yes | Name the control; for near misses, the control that stopped the loss |
| Gross loss by loss form | Yes (may be ranged) | Productivity, response, replacement, fines and judgements, competitive advantage, reputation (FAIR forms); see cost table below |
| Minimum, most likely, maximum estimate | Where final cost unknown | VERIS impact fields amount, min_amount and max_amount form a triangular distribution |
| Recoveries (insurance, third party) | When received | OPE25 25.24 to 25.25: record only once payment is received; receivables do not count |
| Currency | Yes | VERIS uses iso_currency_code; convert at a documented rate |
| Overall impact rating | Yes | Map your severity matrix; VERIS uses Insignificant, Distracting, Painful, Damaging, Catastrophic, Unknown |
| Root cause group | Recommended | Links grouped and recurring events |
| Status and owner | Yes | Open, estimated, final; named owner for updates |
For the cost ledger kept during an incident, see the Incident Cost Tracking Template; the loss database stores the summarised, classified result.
What to include in gross loss
| Cost category | OPE25 (Basel) | DORA (Reg. 2024/1772 Art. 7) | FAIR loss form |
|---|---|---|---|
| Stolen or expropriated funds and assets | Direct charges and write-downs | Expropriated funds or assets, including theft | Replacement |
| Forensics, legal, remediation advisers | Event-related external costs | Advisory costs (legal, forensic, remediation) | Response |
| Replacing hardware, software, infrastructure | Repair or replacement costs | Replacement or relocation costs | Replacement |
| Staff costs and overtime | Not listed separately in 25.26 | Staff costs | Productivity, response |
| Lost revenue | Not listed in 25.26 | Forgone revenues | Productivity |
| Customer redress and contract penalties | Direct charges, provisions | Customer redress; fees for contract non-compliance | Fines and judgements |
| Communication and notification | External costs | Communication costs | Response |
| Provisions and pending losses | Included (pending when material) | Estimated where actuals unknown | Any form |
| Excluded | Maintenance contracts, post-event enhancements, insurance premiums | Day-to-day maintenance, skills upkeep, post-incident enhancements and risk assessments, insurance premiums | Do not include upgrades as losses |
Two differences matter. DORA counts costs "without accounting for financial recoveries", while OPE25 records losses net of received recoveries for capital purposes. Store gross loss and recoveries separately and you can produce both views. DORA's economic impact threshold for a major incident is costs and losses that exceed or are likely to exceed EUR 100,000 (Article 9(6)); OPE25 sets a EUR 20,000 minimum for loss data used in capital calculations, which supervisors may raise to EUR 100,000 for larger banks. See the DORA Major ICT Incident Reporting Guide.
Choosing a taxonomy and thresholds
- Security-led organisations: use VERIS actions and assets for cause, which keeps the data comparable with the VERIS Community Database, an open repository of publicly reported incidents. Add an ATT&CK tactic field only if analysts will fill it consistently.
- Banks and insurers: use the Basel Level 1 event types as the parent, with a cyber flag and a cyber cause sub-field. Cyber events commonly fall under external fraud, business disruption and system failures, or execution, delivery and process management; document the allocation rules as OPE25 25.17 requires.
- Enterprise risk alignment: map each event to the cybersecurity risk register entry it realised. NIST IR 8286C describes how cybersecurity risk registers feed an enterprise risk register and risk profile; the loss database is the evidence that tests those entries. See the Risk Register Template.
- Thresholds: record every event for frequency, but only require full cost capture above a threshold (for example the cost of a day of one analyst's time for near misses, and a fixed currency amount for losses). Banks follow the OPE25 threshold for capital data and can keep a lower internal threshold for cyber analysis.
Implementing the database
- Agree definitions: write a one-page standard defining loss event, near miss, gross loss, recovery and the three dates, approved by risk, finance and security.
- Choose the home: a table in the GRC platform or operational risk system is better than a separate spreadsheet, because it can link to risks, controls and incidents. Small organisations can start with a controlled spreadsheet.
- Wire it to incident closure: make loss record creation a step in the incident process, so the post-incident review cannot close without a loss record. See the Post-Incident Review and Root Cause Analysis Template.
- Pilot on one quarter: back-fill the last 12 months from incident tickets, finance journals and insurance claims; measure how many fields could be completed.
- Reconcile with finance: each quarter, match recorded losses to the general ledger and to insurance recoveries received.
- Feed the models: extract annual counts by scenario type and cost distributions by loss form into the CRQ worksheet. See the Cyber Risk Quantification Worksheet Template.
- Review independently: OPE25 requires documented procedures validated before use and regular independent review of loss data completeness and accuracy (25.16, 25.22); internal audit is the natural reviewer outside banking too.
Rollback is simple: the database adds a record, it does not change incident handling. If the capture step slows incident closure, reduce mandatory fields to dates, cause, service and a ranged estimate, then complete the rest at the monthly review.
Where identity fits
A large share of cyber loss events start with a compromised identity: a phished user, a leaked API key, a stale service account or an over-scoped OAuth grant. Recording the identity type involved lets analysts calculate how often each kind of credential leads to loss, and gives evidence for investment in secrets management, privileged access and NHI governance. See the Leaked secret breaches lessons guide for patterns worth tagging.
Measuring the database
- Coverage: share of closed incidents with a loss or near-miss record (target close to 100 percent).
- Timeliness: median days from incident closure to a final cost figure.
- Completeness: share of mandatory fields filled for events above threshold.
- Reconciliation gap: difference between database totals and finance ledger for cyber cost centres.
- Near-miss ratio: near misses recorded per loss event; a falling ratio usually means under-reporting, not better security.
- Model back-test: modelled versus observed annual event counts for top scenarios.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.RA-04 | Potential impacts and likelihoods are identified and recorded |
| NIST CSF 2.0 | RS.AN-03 | Analysis establishes what took place and the root cause |
| NIST CSF 2.0 | ID.IM-03 | Improvements identified from operational activities |
| NIST CSF 2.0 | GV.RM-03 | Cybersecurity risk activities included in enterprise risk management |
| NIST SP 800-53 Rev. 5 | IR-5, IR-6 | Incident monitoring (tracking and documenting incidents) and incident reporting |
| NIST SP 800-53 Rev. 5 | RA-3, PM-9 | Risk assessment and risk management strategy that consume the data |
| Basel Framework | OPE25.16 to OPE25.29 | Loss data identification, collection and treatment |
| DORA | Delegated Regulation (EU) 2024/1772 Articles 7, 8(2), 9(6) | Economic impact costs, recurring incidents, threshold |
NIST SP 800-61 Rev. 3 (April 2025), the incident response profile of CSF 2.0, places incident response inside cybersecurity risk management, which is where loss data belongs.
Common failure patterns
- Only recording headline breaches: frequency estimates then rest on two or three events and models overstate severity relative to frequency.
- Netting recoveries too early: recording insurance proceeds before payment, against OPE25 25.24, makes losses look smaller and breaks DORA gross reporting.
- Counting upgrades as losses: post-incident enhancements are excluded by both OPE25 and DORA and inflate severity.
- No owner after closure: costs that arrive months later (legal, regulatory, customer claims) never reach the record.
- Free-text causes: without a controlled taxonomy events cannot be counted by scenario.
- Splitting one root cause into many small events: hides recurring weaknesses; link them with a root cause group.
Practitioner checklist
- Publish a one-page loss event standard with definitions and the three dates.
- Choose a cause taxonomy (VERIS, ATT&CK tactic or Basel Level 1 with cyber flag) and document mapping rules.
- Make a loss or near-miss record a closure condition for every incident.
- Store gross loss and recoveries separately; record recoveries only when received.
- Use ranged estimates where final cost is unknown and update them monthly.
- Tag the identity type and the control that failed or worked.
- Reconcile with finance and insurance claims quarterly.
- Feed annual counts and cost ranges into CRQ models and back-test once a year.
- Arrange independent review of completeness and accuracy.
Standards and references
- Basel Committee on Banking Supervision: Basel Framework OPE25, Standardised approach (loss data)
- EUR-Lex: Commission Delegated Regulation (EU) 2024/1772, classification of ICT-related incidents
- NIST: IR 8286C, Staging Cybersecurity Risks for Enterprise Risk Management and Governance Oversight
- NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- NIST: Cybersecurity Framework 2.0
- VERIS: Impact Assessment
- VERIS: Enumerations
- VERIS: schema repository on GitHub
Related NHI Mgmt Group resources: Cyber Risk Quantification Guide, FAIR Model and Open FAIR Standard Guide, Key Risk Indicators for Cyber Risk Guide, Incident Cost Tracking Template.