Cyber Incident Cost: Build a Business Impact Model

There is no universal “true cost” of a cyber incident. Cost depends on the organization, affected services and information, duration, obligations, response choices, insurance, and recovery. A decision-ready model uses ranges and named assumptions instead of a single industry average.

Evidence boundary: This article provides general operational guidance. It does not claim that ITECS completed a pilot, measured outcomes, approved or signed off on a design, made a legal or compliance determination, or verified any vendor’s configured capability.

Define the scenario and boundary

Specify event type, entry path, systems, information, locations, suppliers, detection delay, operational duration, and recovery assumptions. Distinguish suspected, confirmed, and worst-reasonable scope. The model should state its currency, time horizon, tax treatment, and excluded effects.

Map cost categories

• Investigation, containment, specialist support, forensics, and communications.
• Downtime, reduced capacity, manual work, overtime, and backlog recovery.
• Restoration, replacement, validation, monitoring, and security improvement.
• Fraud, theft, contractual credits, customer support, and revenue effects.
• Legal, privacy, notification, regulatory, and litigation costs as advised by qualified owners.
• Insurance retention, exclusions, limits, premium effects, and recovery timing.

Build ranges and dependencies

Model conservative, expected, and severe cases for affected users, transaction loss, time to contain, time to restore, information scope, specialist hours, notification population, and customer behavior. Avoid counting downtime and lost revenue twice. Record which assumptions depend on law, contract, insurer, provider, or untested recovery.

Use the model to improve readiness

Compare estimated exposure with investment in identity, segmentation, monitoring, protected backups, response retainers, exercises, and continuity. Use tabletop results to update duration and capability assumptions. After an event, preserve actual cost and recovery evidence without exposing sensitive incident details unnecessarily.

Next step for your environment

Model one ransomware or account-compromise scenario for a critical service using three ranges and explicit response and recovery assumptions.

Record the accountable owner, baseline, source date, decision, exceptions, acceptance evidence, and review trigger. Test consequential changes in a bounded environment, maintain a rollback path, and verify the real result before closing the work. Product names, availability, pricing, legal requirements, and security guidance can change; recheck the primary sources whenever the decision is renewed or the environment changes.

If you need an independent baseline before changing production systems, start with an ITECS technology and security assessment and keep the resulting evidence with the decision record.

Sources and update trigger

• FBI — 2025 Internet Crime Report
• NIST — SP 800-61 Rev. 3 Incident Response
• NIST — Cybersecurity Framework 2.0

Review trigger: Review after incident, exercise, service, information, revenue, supplier, insurance, legal, recovery, or cost-assumption changes.