After a serious incident, the cost question arrives from the board, the insurer and the auditors at once, and organisations that did not record costs as they were incurred end up reconstructing them from invoices and memory, which weakens both the claim and the lessons learned. This template gives incident managers and finance teams a cost ledger to open on day one of an incident: cost codes, the fields to capture, who approves spend, how to tie each cost to an insurance policy section, and how to report totals. It follows NCSC advice to keep a careful record of decisions and actions on systems the incident has not affected, and structures costs so they line up with typical cyber policy sections. It is written for incident managers, finance controllers and risk and insurance managers. Adapt the bracketed text before adoption.
How to use this template
- Bracketed timings, durations and thresholds are NHI Mgmt Group recommendations; adjust them to your risk appetite, policies and contracts.
- Replace text in square brackets, such as [Organisation], [Finance Lead] and [Broker], with your own names and values. "Must" is mandatory; "should" is recommended.
- Section 5 is the ledger itself; sections 1 to 4 and 6 to 8 govern how it is run. Keep the ledger outside the affected environment.
- Decision points are marked D1 to D4.
- What policies cover and how claims work is explained in the Cyber Insurance Guide; modelling expected losses before an incident is covered in the Cyber Risk Quantification Guide. This template records actual costs during and after one incident.
1. Purpose
1.1 This ledger records every cost and loss arising from a security incident at [Organisation], from detection to closure, so that [Organisation] can support insurance claims and recoveries, report accurately to leadership and auditors, and feed real figures into risk models and budgets.
1.2 It is part of the incident record. The NCSC advises maintaining a careful record of decisions made, actions taken and data captured, for post-incident review and for evidence to a regulator, and recording decisions offline or on systems not affected by the incident.
2. Scope
2.1 Applies to every incident rated [Severity 2] or above, and to any incident where an insurance notification has been made or may be made.
2.2 Covers external spend, internal effort, revenue and productivity losses, third-party claims, regulatory costs and recoveries. Costs are recorded whether or not they are expected to be insured.
2.3 The ledger stays open until the [Finance Lead] confirms no further costs are expected, typically after legal and regulatory matters close, which may be long after technical recovery.
3. Roles and responsibilities
| Role | Responsibility |
|---|---|
| [Incident Manager] | Opens the ledger at declaration, ensures workstreams log effort and spend daily |
| [Finance Lead] | Owns the ledger, creates the incident cost centre or project code, reconciles to the general ledger, calculates lost revenue |
| [Risk and Insurance Manager] | Notifies the insurer or [Broker], maps costs to policy sections, obtains consents, prepares the claim |
| [Legal Counsel] | Engages breach counsel; advises on privilege over cost records and on third-party claims |
| [Workstream Leads] | Log hours and purchases for their team (IT recovery, forensics, communications, customer support) |
| [Procurement] | Raises emergency purchase orders against the incident code |
4. Opening the ledger
4.1 Within [4] hours of declaration, the [Finance Lead] must create a dedicated cost code so that invoices, overtime and expenses are tagged at source.
4.2 D1: insurer notification. The [Risk and Insurance Manager] decides on notifying the insurer or [Broker] at declaration, using the policy's notification clause. The NCSC advises that organisations with cyber insurance should report the attack to their insurer or broker, and notes insurers often offer an out-of-hours number or app and recommended response companies. Late notice can put cover at risk; when in doubt, notify.
4.3 D2: panel and consent. Before engaging any external firm, check whether the policy requires panel providers or prior written consent. Record the consent reference against each engagement in field 12.
4.4 If breach counsel directs forensic work, agree with [Legal Counsel] how cost records reference privileged reports. See the Legal Privilege in Incident Response Guide.
5. Cost categories and ledger fields
5.1 Every cost must be assigned one category. Categories are grouped to match common cyber policy sections, so the claim can be assembled from the ledger without re-sorting.
| Code | Category | Examples | Typical policy section |
|---|---|---|---|
| R1 | Forensics and investigation | External DFIR firm, tooling licences bought for the incident, evidence storage | Incident response costs |
| R2 | Legal and breach counsel | Breach counsel, regulatory advice, privilege management | Incident response costs |
| R3 | Notification and customer support | Letters, email services, call centre, credit or identity monitoring | Incident response costs |
| R4 | Communications | PR and crisis communications advisers | Incident response costs |
| R5 | Extortion handling | Negotiators, sanctions screening; any payment only where lawful and with insurer consent | Cyber extortion |
| C1 | Credential and identity remediation | Emergency rotation of secrets, keys and certificates, re-issuing tokens, forced password resets, re-enrolling MFA, contractor hours | Incident response or data restoration (check wording) |
| D1 | Data and system restoration | Rebuilds, restore from backup, replacement hardware, cloud capacity, recovery contractors | Data restoration |
| B1 | Business interruption: lost revenue | Lost net profit while systems were down, per section 6 | Business interruption |
| B2 | Increased cost of working | Manual workarounds, temporary staff, expedited shipping, overtime to clear backlog | Business interruption (extra expense) |
| T1 | Third-party claims | Customer and partner claims, defence costs, contractual penalties | Privacy and network security liability |
| G1 | Regulatory | Investigation response costs; fines and penalties where insurable by law | Regulatory defence and penalties |
| F1 | Fraud losses | Funds lost to payment diversion or impersonation | Cyber crime (often sublimited or excluded) |
| I1 | Internal staff effort | Hours of employees diverted to the incident | Often not covered; record for internal reporting |
| P1 | Betterment and improvement | Upgrades beyond like-for-like restoration | Usually excluded; record separately |
5.2 Each ledger line must hold these fields:
| # | Field | Content |
|---|---|---|
| 1 | Line ID | [INC-ref]-[sequence] |
| 2 | Date incurred | Date the work was done or loss occurred, not invoice date |
| 3 | Category code | From 5.1 |
| 4 | Description | What was bought or done, and why it was needed for the incident |
| 5 | Supplier or internal team | Name |
| 6 | Quantity and rate | Hours x rate, units x price |
| 7 | Amount and currency | Excluding tax, with tax recorded separately |
| 8 | Status | Estimated, committed, invoiced, paid |
| 9 | Evidence | Purchase order, invoice, timesheet, contract, calculation |
| 10 | Approver | Per section 7 |
| 11 | Policy section | From 5.1, confirmed by [Risk and Insurance Manager] |
| 12 | Insurer consent reference | Where required |
| 13 | Claimed amount and status | Submitted, agreed, paid, declined, with reason |
| 14 | Recovery from third parties | Supplier credits, contractual indemnities |
6. Business interruption and internal effort
6.1 Lost revenue must be calculated by the [Finance Lead] from accounting records: expected revenue for the outage period (from trend or the same period last year, adjusted for seasonality), minus actual revenue, minus costs saved. Record the method and data sources with the figure.
6.2 Record the exact start and end of each outage and degraded period. Policies often apply a waiting period counted in hours before business interruption cover starts, and an indemnity period that limits how long losses are covered.
6.3 Internal effort is recorded as hours by role at a loaded rate of [salary plus on-costs per hour], agreed with finance in advance. Even when not insured, it shows the true cost to leadership.
6.4 Credential remediation (C1) often needs its own tracking because it runs across many teams: count credentials rotated by type and the hours spent, which also measures how well the organisation knows its machine identities. See the Non-Human Identity (NHI) Guide.
7. Approval and controls
| Single commitment | Approver | Additional requirement |
|---|---|---|
| Up to [10,000] | [Incident Manager] | Logged within [24] hours |
| Up to [100,000] | [Incident Manager] and [Finance Lead] | Insurer consent checked |
| Above [100,000], or any extortion-related spend | [CFO] and [CEO] | Insurer consent and legal sign-off recorded |
7.1 D3: emergency spend. During containment, the [Incident Manager] may commit spend above their limit to protect life, safety or critical services, and must record it and seek approval within [24] hours.
7.2 Separation of duties still applies: the person approving payment must not be the person who requested it. Payment changes requested during an incident must be verified by a call to a known number, because attackers exploit the confusion.
8. Reporting and closure
8.1 The [Finance Lead] must issue a cost summary to the [incident steering group] [weekly] while the incident is active and [monthly] after: totals by category, committed versus paid, insured versus uninsured, and claimed versus recovered.
8.2 D4: claim submission. The [Risk and Insurance Manager] submits the claim in tranches if the policy allows, so early costs are not held back by later ones.
8.3 At closure, record final totals, the claim outcome and the uninsured share, and feed them into the post-incident review and the next risk quantification and budget cycle. See the Post-Incident Review and Root Cause Analysis Template and the Security Budget Template and Cost Model.
Implementation guidance
- Set up before an incident: agree the category codes, loaded staff rates and approval limits with finance, and pre-create a dormant incident project code that can be activated in minutes.
- Map to your policy wording: ask your [Broker] to confirm the section for each category in 5.1, including sublimits, waiting periods and panel rules, and update the table.
- Store it offline-capable: keep a copy of the template and contact numbers outside the main IT environment, consistent with your incident response plan. See the Incident Response Plan Template.
- Test in an exercise: include cost logging in your next tabletop and check that a claim pack could be built from the ledger alone.
- Measure: share of costs logged within [48] hours of being incurred, proportion of lines with evidence attached, time from incident closure to claim submission, and claimed amount recovered.
| Framework | Reference |
|---|---|
| NIST SP 800-61 Rev. 3 | Incident response integrated with risk management under CSF 2.0 |
| NIST CSF 2.0 | RS.AN-03 analysis and root cause; RC.RP-01 recovery executed |
| NIST SP 800-53 Rev. 5 | IR-4 Incident Handling; IR-8 Incident Response Plan |
Common failure patterns: logging costs by invoice date so they fall outside the incident period; engaging non-panel firms without consent; no record of outage start and end times; mixing betterment with restoration; and ignoring internal effort, which hides the true cost from leadership.
Standards and references
- NCSC: Guidance for organisations considering payment in ransomware incidents
- NCSC: Cyber insurance guidance
- NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
Related NHI Mgmt Group resources: Cyber Insurance Guide · Cyber Risk Quantification Guide · IBM Cost of a Data Breach Report · Incident Response Guide