On this page
- Why the reported loss is much smaller than the business impact can be
- Contain the incident while preserving the facts
- Encryption, stolen data and restored operations are different questions
- Build a loss schedule that can survive scrutiny
- Assess a payment demand without confusing possibility with assurance
- Sources and scope
A ransom note creates several urgent problems at once: an attacker may still have access, business systems may be unavailable, evidence may disappear and stolen data may create a separate exposure. Start a coordinated incident response through trusted communications. Containment and preservation need to be planned together; immediately wiping every affected device can destroy information needed to understand the attack.
The FBI’s 2025 IC3 Annual Report, pages 7–8, records 3,611 ransomware complaints and $32,320,105 in reported losses. That figure is not the total economic cost of ransomware. Understanding what it excludes matters both when reading the statistics and when building a claim after an incident.
Why the reported loss is much smaller than the business impact can be
The report explains on page 14 and in Appendix C that ransomware adjusted losses exclude estimates of lost business, time, wages, files, equipment and third-party remediation services. Some complainants report no monetary loss. Incidents reported only to FBI field offices rather than through IC3 are also outside this statistic.
It is therefore wrong to describe $32.3 million as the cost of all US ransomware attacks, or to divide it by the complaint count and present the result as a typical business’s exposure. A modest ransom demand can accompany a much larger interruption. Conversely, a demand is not proof that its stated amount has actually been paid.
Our overview of the 2025 IC3 statistics explains the distinction between complaint data and population-wide risk.
Contain the incident while preserving the facts
The joint CISA, FBI, NSA and MS-ISAC StopRansomware Guide recommends coordinated isolation, separate communications and preservation of short-lived evidence. Trained responders should determine the affected systems and how to disconnect them. The guide treats powering devices down as a fallback when disconnection is unavailable, because shutdown can destroy evidence held in memory.
Tell the response team which records are business-critical and who can authorize containment. Record actions and timestamps. An urgent operational decision may be reasonable even before the full picture is known; documenting what was known at the time helps distinguish that decision from a later reconstruction.
| Record | Preserve | Question it helps answer |
|---|---|---|
| Ransom demand | Original note, contact details, deadlines and demanded payment address. | What was demanded and through which channel? |
| Technical evidence | Relevant logs, forensic images, memory where appropriate and cloud snapshots. | Which systems and accounts were affected? |
| Response chronology | Detection, isolation, resets, restoration and the person recording each action. | What happened before and after containment? |
| Business impact | Outage records, invoices, cancelled work and recovery milestones. | Which consequences are supported by records? |
Keep originals and controlled working copies. Restrict access to sensitive material rather than circulating a broad evidence bundle by ordinary email. Record who collected each item and from which system. This register is an organizational framework; it does not replace forensic acquisition or the evidential requirements of a particular proceeding.
Encryption, stolen data and restored operations are different questions
A business may restore working files and still need to investigate whether data was copied before encryption. A working decryption key does not establish that the intruder has left. Nor does an attacker’s promise to delete material provide independent verification of deletion. The joint advisory on Play ransomware, revised June 4, 2025, describes a model combining data theft, encryption and threats of publication.
When the demand concerns stolen files and systems remain usable, see our guide to law firm data theft and extortion without encryption. The absence of encrypted files does not settle whether sensitive information was taken.
Maintain separate findings for availability, confidentiality and continuing access. For example, “file server restored” is an operational milestone; “no evidence of data theft identified within the logs reviewed” is a qualified investigative statement. Neither should be rewritten as “all data safe” without supporting evidence.
If the initial access involved a false support request, stolen password or authentication code, preserve that entry point alongside the ransom note. Our phishing and account takeover guide explains the importance of the original request and authentication timeline.
Build a loss schedule that can survive scrutiny
Separate amounts demanded, amounts paid, costs incurred and future estimates. Each requires a different evidential basis. A useful working schedule includes the category, date, currency, supporting record, calculation and any uncertainty.
| Category | Evidence | Common overstatement to avoid |
|---|---|---|
| Payment, if made | Bank or exchange record, asset, network, transaction hash, recipient and valuation basis. | Counting both the purchase of cryptocurrency and transfer of that same asset as separate losses. |
| Response and restoration | Provider invoices, work descriptions and proof of payment. | Combining estimates and final invoices for the same work. |
| Interruption | Outage dates, affected services, deferred or cancelled orders and the calculation method. | Treating all turnover during an outage as proven lost profit. |
| Internal work and equipment | Time records, replacement decisions and supporting costs. | Claiming the same staff hours under several categories or assuming every replacement was caused by the attack. |
Also distinguish insurance payments or other recoveries from the original expenditure. The resulting schedule documents a factual position. Whether an item is recoverable from an insurer, supplier, attacker or another party depends on the applicable terms, law, causation and evidence.
Assess a payment demand without confusing possibility with assurance
The FBI does not support paying a ransom: payment does not guarantee that data will be returned and can encourage further attacks. Reporting remains important whether or not a payment has already occurred.
Before any decision, the responsible team needs a documented assessment of available backups, restoration time, continuing compromise, threatened data exposure, payment restrictions and the reliability of any technical claim. An attacker’s asserted affiliation or an automated wallet label is not enough to settle those issues.
Where US sanctions rules may apply, OFAC warns of sanctions risks in making or facilitating ransomware payments. That warning should not be turned into a claim that every ransom payment everywhere is automatically unlawful. The parties, jurisdictional connections and current restrictions need specific review. Insurance involvement does not remove the need for that assessment.
Sources and scope
FBI, 2025 IC3 Annual Report, pages 7–8, 14–16 and 62; the joint StopRansomware Guide; Play ransomware advisory; FBI ransomware guidance; and OFAC’s updated ransomware advisory notice. The registers and loss schedule are editorial tools for organizing records, rather than statistical findings or a substitute for an incident-specific response.
