Cybercrime Statistics on Reported Losses

Cybercrime statistics are most useful when the word “reported” stays attached. A complaint system records information submitted under its own categories and definitions. Its totals are important evidence, but they are not a complete measurement of every incident, victim, or economic consequence.

The FBI’s 2025 Internet Crime Complaint Center report illustrates the distinction. Its categories show very different relationships between complaint volume and reported loss. A high complaint count does not necessarily produce the largest loss total, and a loss total does not establish the full cost of recovery.

For business planning, the practical task is to identify the relevant category, understand its limits, and connect it to a process the organization can improve. The figures below support that work without turning complaint data into an unsupported forecast of individual risk.

Key Statistics and Data

• All complaints: IC3 records 1,008,597 complaints and a rounded total of $20.877 billion in reported losses.
• Phishing/spoofing: The category records 191,561 complaints and $215,843,126 in reported losses.
• Business email compromise: The category records 24,768 complaints and $3,046,598,558 in reported losses.
• Investment: The category records 72,984 complaints and $8,648,617,756 in reported losses.
• Ransomware: The category records 3,611 complaints and $32,320,105 in reported losses, excluding costs such as downtime and remediation from that loss measure.

Read Complaint Volume and Loss Together

The FBI’s reported complaints and losses show that volume and financial loss describe different dimensions. Phishing/spoofing has more complaints than investment in the selected categories, while investment has a much larger reported loss total.

Phishing/spoofing

191,561 2025 Complaints$215,843,126 Reported Losses

Business email compromise

24,768 2025 Complaints$3,046,598,558 Reported Losses

Investment

72,984 2025 Complaints$8,648,617,756 Reported Losses

Ransomware

3,611 2025 Complaints$32,320,105 Reported Losses

This table contains selected categories, not a complete breakdown of the report’s total. Its purpose is to show how the two measures differ, not to create a new aggregate by adding a convenient subset.

The figures also do not establish the number of unique affected organizations. A complaint is the reporting unit. The relationship between complaints, people, businesses, and underlying events should not be assumed without the source’s relevant methodology.

For an executive audience, keep the column labels specific. “Reported losses” is more accurate than “total economic damage.” “Complaints” is more accurate than “successful attacks.” The short labels preserve the meaning when the table is reused outside the article.

Do Not Turn Reported Loss Into Total Harm

Different losses can sit outside the amount recorded by a complaint system. Operational interruption, internal labor, restoration work, and other consequences may be excluded or represented differently depending on the category and reporting method.

The ransomware category makes this limitation especially clear. Its reported-loss figure excludes downtime and remediation. A comparison with ransomware recovery costs therefore needs to preserve the separate definitions rather than treating the two figures as rival estimates of the same cost.

The same principle applies more broadly. A reported financial loss is not automatically the full business cost of an event. It is also not automatically an insurance payment, a finalized accounting loss, or an estimate of every indirect consequence. Each of those measures requires its own definition.

Useful cybercrime statistics make these boundaries visible before the reader starts comparing categories. A narrow measure can still be valuable when accurately labeled. It becomes misleading when the label expands beyond what the source collected.

For internal planning, create explicit cost categories. Distinguish transferred funds, recovery expenses, interruption estimates, professional support, and unresolved amounts. Avoid assuming that a single external total already includes the same combination.

Keep Crime Categories Separate From Descriptors

Some report dimensions describe the type of crime, while others describe a technology, payment method, or other characteristic associated with an event. Those dimensions can overlap. They should not be added as if they were mutually exclusive categories.

In the IC3 report, descriptors involving cryptocurrency or AI can overlap with crime categories. An investment-related complaint may also involve cryptocurrency. Adding both totals without reconciliation can count the same reported loss more than once.

Before constructing a chart, identify whether each row is a category, a descriptor, a population, or a subset. If the report does not establish that rows are mutually exclusive, do not create a combined total from them. A stacked chart can be particularly misleading when its visual form implies that all segments add cleanly to one whole.

The distinction also helps internal incident reporting. Record the business process affected, the event type, and relevant techniques or technologies in separate fields. That allows several descriptions of one event without inflating the unique-event count.

Cybercrime statistics are easier to use when the analysis preserves the source’s structure. Simplifying the presentation should not erase relationships between categories or turn overlapping descriptors into additional losses.

Avoid a Misleading Average Loss per Victim

Dividing a reported loss total by a complaint count produces a mathematical quotient. It does not necessarily produce a meaningful average loss per victim. The denominator is complaints, not verified unique victims, and the distribution of losses may be uneven.

The quotient also says little about the outcome for a particular business. A large total can include a small number of very large reported losses and many smaller or zero-loss complaints. Without the relevant distribution and population detail, the average can create a false sense of precision.

If an internal analysis uses a derived measure, label it exactly and explain the calculation. Do not rename “reported losses divided by complaints” as “typical victim loss.” For the figures in this article, the counts and totals are more useful presented separately.

Broader sector and company-size comparisons raise a similar issue. A contributed incident count does not establish a company’s annual attack probability, while an insured-loss median describes a selected loss population. Neither can be inserted into a complaint-based calculation without a defensible model.

The practical alternative is to build a scenario around the process at risk. Identify how money, information, or operational capacity could be affected, then use organization-specific assumptions that can be reviewed and tested.

Connect the Categories to Business Processes

A category table becomes useful when it points to an accountable process owner. Business email compromise, for example, raises questions about payment instructions, supplier changes, approval, and independent verification. Those are operating-process questions as well as technical ones.

The following review framework is an editorial recommendation. It does not claim that the cited report measured the effectiveness of these controls.

Choose a review that fits the organization’s actual activity. A company handling frequent supplier payments may prioritize verification of changed bank details. A service business with critical customer systems may prioritize restoration dependencies. The external category totals explain context, but the organization’s processes determine where work is needed.

Keep the acceptance evidence concrete. A policy document alone does not establish that the process works. Review a representative sample, test the exception route, and confirm that staff know who owns the decision when normal conditions do not apply.

Compare Reporting Systems Carefully

The ICO’s reported data security incidents illustrate a different reporting system with a different remit and methodology. Its notes identify a methodological change from the second quarter of 2019. That matters when interpreting trends across the change.

An IC3 complaint and an ICO incident report are not interchangeable units. They arise under different reporting structures and describe different populations and categories. Combining their totals would not produce a global cybercrime count.

The same caution applies to confirmed breaches and exposed records. A breach event, an affected record, a victim notice, and a complaint may all concern related activity while measuring different things. A large record total should not be compared directly with a complaint total as if both counted victims.

Build a source note for each figure before presenting a cross-report comparison. Include geography, reporting period, counting unit, inclusion rules, revision method, and relevant exclusions. If those fields cannot be reconciled, use the sources for separate questions.

This article uses the ICO source as a methodological comparison rather than quoting an unextracted dashboard total. The point is to preserve the reporting boundary, not to enlarge the headline by adding another dataset.

Build a Loss Record That Finance Can Use

An internal loss record should distinguish known amounts from estimates and potential future costs. Record the source of each amount, the period it covers, and whether it overlaps another line item. Assign an owner to unresolved estimates.

Separate cash movement from operational impact. Money transferred, an invoice for external support, internal time, and an estimate of interrupted business are different kinds of evidence. Keeping them separate makes later reconciliation more reliable and helps explain why an early estimate changes.

Preserve the event identifier across departments where appropriate. Finance, security, operations, and customer support may each track part of the same event. Without a common reference, a consolidated report can duplicate costs or miss them entirely.

Use the resulting record to improve future planning. Identify which assumptions were wrong, which dependencies created unexpected work, and which control changes would address the specific failure. That produces an organization-specific evidence base rather than repeated reliance on a broad industry total.

Use Reported Losses to Set a Focused Priority

The strongest use of cybercrime statistics is to connect a clearly defined external observation to a business process that someone can improve. The IC3 figures show reported complaint volume and losses under distinct categories. They do not establish every event, every unique victim, or the full cost of harm.

Select one relevant process and review its normal and exception paths. Confirm ownership, test the evidence required for consequential actions, and document how failures are escalated. Use the external data to explain the importance of the review, then judge the work by its operational result.

That approach supports a decision the business can act on. It also avoids turning a large national total into a false prediction about one organization’s next year.

A payment-process review can be deliberately narrow. Select a representative supplier change and trace who received the request, how the new instruction was verified, who approved it, and what evidence was retained. Include the exception route for an urgent or unusual request. The purpose is to establish whether the intended control works in practice, not to infer a loss probability from the national complaint total. A specific weakness can then be assigned to an owner and retested after the process changes.

Frequently Asked Questions

Resources

The FBI’s 2025 IC3 Annual Report supplies the complaint and reported-loss figures, with category and methodology material in the report and appendices. The ICO’s incident-trends source supplies the regulatory-method comparison. Both are linked at the relevant discussion.