The board asks for a single number: „what will this cost us if it happens”. The IT director reaches for a report in which somebody calculated the average cost of an attack across a global sample — and brings to the meeting a figure describing companies he does not know, in currencies he does not use, with a cost structure he does not have. The conversation ends where it began: there is a number, only nobody can defend it.
Meanwhile the ransomware bill consists of six line items, and five of them can be calculated from data the company already holds — from the profit and loss account, the process register and the backup schedule. The sixth, the ransom, is the only one supplied by the attacker and the only one you do not control. This text gives a formula for each item, points to the person in the company who holds the required data, and names the boundary beyond which estimation stops working.
How much does a ransomware attack really cost a company in Poland?
It costs the sum of six line items calculated on your own data. The bill covers production downtime, system recovery, the loss of data created after the last backup, handling regulatory duties, communication together with legal support, and hardening the environment after the event.
The scale of the phenomenon in Poland is documented first-hand. CERT Polska, in its annual report for 2025 published on 8 April 2026, recorded 179 ransomware attacks — against 147 in 2024 and 161 in 2023, the previous record. The reports came mostly from private entities (129), with 30 from public bodies and 20 from individuals.
The European context has a direct bearing on how to count. ENISA, in its Threat Landscape 2025 covering the period from 1 July 2024 to 30 June 2025 and nearly 4 900 curated events, points to 82 ransomware families deployed against organisations in the Member States, led by Akira (11.6% of deployments), ahead of SafePay (10.1%) and Qilin (7.5%). A market this fragmented rules out the scenario „let us calculate the cost of an attack by one specific group with known behaviour” — the bill has to be built on your own infrastructure, because that is the only constant.
Why is the ransom the smallest and most visible line item on the bill?
The ransom is visible because the attacker states the amount himself — and the fact that something is stated does not make it the largest item, or an item that belongs on the bill at all. The organisations that produced the #StopRansomware Guide (CISA and the FBI, published in October 2023) do not recommend paying and state plainly that payment will not ensure the data is decrypted, will not guarantee that systems cease to be compromised, and will not prevent disclosure. The guide also recalls the sanctions risk described in the September 2021 memorandum of the U.S. Office of Foreign Assets Control.
On top of that comes the problem of the threat’s credibility. CERT Polska describes, in its report for 2025, the phenomenon of false double extortion: the ransom demand almost always threatens disclosure regardless of whether the attacker carried anything out of the infrastructure. The relationship also runs the other way — a templated demand proves nothing, because exfiltration may have taken place despite leaving no trace in the message.
The conclusion for the bill is straightforward. The ransom amount is the price of information whose truthfulness you cannot verify at the moment the decision has to be taken. The remaining five items concern events that certainly did occur.
How do you calculate the cost of downtime before the downtime happens?
Downtime is counted in contribution margin, not in revenue — and that is the first thing to correct in most in-house estimates. The formula has three terms: contribution margin generated per hour × number of hours of unavailability × share of the process dependent on the encrypted system.
The chief financial officer derives the hourly contribution margin from the profit and loss account: annual contribution margin divided by the number of hours actually worked. The share of the process comes from the register of business processes — if the company has ever run a business impact analysis, that figure already exists. If it has not, this is the first signal that the bill cannot be closed without preparatory work.
The hardest term is the middle one, the number of hours. Do not guess it — measure it in your own environment by restoring one critical system as a test and multiplying the result by the number of systems that would fall together in the attack scenario. This exercise costs the team one working day and turns the most contested figure on the bill into a measured one.
Why does recovery cost more than simply restoring a backup?
Recovery costs many times more than restoring files, because restoration is only one of six tasks. NIST, in publication SP 1800-11 „Data Integrity: Recovering from Ransomware and Other Destructive Events” (final version, September 2020, NCCoE), states that the guide should help organisations „restore data to its last known good configuration”, „identify the correct backup version (free of malicious code and data for data restoration)”, „identify altered data as well as the date and time of alteration”, „determine the identity/identities of those who alter data”, „identify other events that coincide with data alteration” and „determine any impact of the data alteration”. Only the first of those six is what most budgets mean by recovery.
The formula: (number of systems to recover × measured recovery time per system × hourly rate of the team) + cost of external support + cost of verifying the integrity of the recovered data.
Assume the worst about your backups while doing so. CERT Polska describes how attackers deliberately locate backup servers and hypervisors: backups held on NAS devices were usually not encrypted at all, the storage space was reinitialised instead, while on compromised hypervisors the virtual machine files were encrypted and the snapshots deleted. A backup the attacker can reach from the same network is a zero on this bill. How to build a set that survives this is covered in our text on protecting data from ransomware.
What does the gap between the last backup and the attack cost?
This is the only line item you lower by a clean budget decision, which is why it is worth calculating first. The formula: number of transactions created per hour × cost of reconstructing one transaction from source documents × number of hours between the last backup and the attack.
The final term is your RPO expressed in hours. If the backup runs once a day, you enter into the bill up to 24 hours of work by the entire company — orders, corrections, warehouse documents and confirmations that somebody will have to re-enter from paper, mail and memory. The cost of reconstructing a single transaction is known to the head of the department that handles it, not to the IT team.
This item grows linearly with the interval between backups, which makes it the cleanest budget conversation available on this subject: shortening the RPO from 24 hours to four reduces the item sixfold, and the cost of that change is known in advance. This is precisely the moment when a discussion driven by fear turns into arithmetic — and designing such a backup set falls within our backup and disaster recovery services.
Which regulatory duties does ransomware trigger for a company in Poland?
It starts two independent clocks, and most companies are subject to only one of them. The first is the GDPR: the controller notifies a personal data breach to the supervisory authority without undue delay and, where feasible, not later than 72 hours after having become aware of it, and a notification made later must be accompanied by reasons for the delay (Article 33(1) GDPR).
The second clock applies to essential and important entities under the Polish National Cybersecurity System Act. As amended on 23 January 2026 (Journal of Laws 2026 item 252), Article 11(1) requires an early warning about a significant incident within 24 hours, the incident notification within 72 hours, and the final report within one month of that notification (own translation). It is worth noting the difference from Directive (EU) 2022/2555, whose Article 23(4) counts these deadlines from becoming aware of the incident — the Polish act counts them from the moment of its detection.
Here comes the finding that changes most of these bills. Of the 179 attacks registered by CERT Polska in 2025, not one reached the threshold at which the National Cybersecurity System Act requires an event to be treated as a significant incident. That is an observation drawn from reported cases rather than from the whole population of Polish companies, so it relieves nobody of their own classification duty — but it does show where the centre of gravity lies. For a typical mid-sized company the real cost regime after an attack is the GDPR rather than the Polish act, and it is the GDPR that should shape the preparation budget.
Which regime should you use to price the risk of a fine — the GDPR or the Polish act?
The one you are subject to — and if you are subject to both, the legislator has provided that you will not pay twice for the same conduct. The upper limits are comparable. Article 83(4) GDPR provides for a fine of up to EUR 10 000 000 or up to 2% of total worldwide annual turnover, whichever is higher; that ceiling covers the obligations in Articles 25 to 39, and therefore also security of processing and breach notification.
The Polish act sets its ceiling similarly after the amendment, but adds a floor. A fine on an essential entity may not exceed EUR 10 000 000 or 2% of revenue, but may not be lower than PLN 20 000 (Article 73(3)). For an important entity the ceiling is EUR 7 000 000 or 1.4% of revenue, with a floor of PLN 15 000 (paragraph 4). Where the breach causes a direct and serious cyber threat, the authority imposes a fine of up to PLN 100 000 000 (paragraph 5; own translation throughout).
One more item belongs on the bill, and the company does not bear it. A fine may be imposed on the head of an essential or important entity — up to 300% of the remuneration received (Article 73a(4) of the Polish act; own translation). Finally, Article 35(2) of Directive 2022/2555 settles that where a supervisory authority has imposed a fine under the GDPR, the network security authority does not impose another one for the same conduct.
What does it cost to establish whether data actually leaked, and to notify it?
It costs whatever the forensic analysis costs — and its price depends on whether you have logs. CERT Polska points to insufficient log retention, particularly from edge devices and the Active Directory domain controller, as a significant obstacle to analysis: many reporting companies operate no central log collector, so their logs reach back only a few days. Infiltration, meanwhile, is sometimes spread over several weeks.
Without logs you cannot answer the question that governs the most expensive part of this item: whether the data subjects have to be notified. The GDPR requires such communication where the breach is likely to result in a high risk to the rights and freedoms of natural persons (Article 34(1)), but exempts you from it where the controller has applied to the affected data measures rendering it unintelligible to unauthorised persons, in particular encryption (Article 34(3)(a)).
The formula: cost of forensic analysis + (number of people to notify × cost of one notification) + legal support and communication. The first two terms are reduced before an attack, not after it — the first through log retention, the second through encryption of data at rest. Putting the post-event work in order is what our post-incident management service covers.
What does hardening your defences after an attack cost?
Roughly the same as the identical programme delivered as planned, only executed under pressure and with no room to negotiate the deadline. The good news is that it is clear where to start, because the entry vectors repeat year after year.
CERT Polska reports that in 46 ransomware incidents the attacked entity had a publicly exposed remote desktop service, and adds that this figure is probably understated. In two reported cases, less than two weeks passed between exposing RDP to the internet and the password being broken and the infection following. In the overwhelming majority of events where the vector could be established, access was obtained through remote services lacking two-factor authentication.
The formula for this item is unusual, because it does not depend on the attack: cost of the planned hardening programme × urgency multiplier. The multiplier is the only variable you influence, through the decision on timing. A company that calculates this item before the event gets a result that defends itself in a board conversation — because it will spend exactly that amount anyway, only at a higher price.
Why does paying the ransom not remove the cost of recovery?
Because a decryption key is not a backup and answers none of the questions that have to be asked after an attack. Decryption restores the files; it does not say which version of the data is free of malicious code, who altered it and when, or what the scope of the alteration was — so it fulfils five of the six recovery goals listed in NIST SP 1800-11 not at all.
The downtime has also already happened. At the moment the decision on negotiations is taken, items one and three of the bill are closed, and the regulatory clocks are running — Article 33(1) GDPR does not pause for talks with the attacker.
There is a further trap on the other side of that decision. CERT Polska notes that identifying the ransomware family used is often a serious challenge, and that some groups deliberately avoid publicity: they do not sign their notes, run no leak blog, and reuse fragments of other groups’ messages. An entity with no backup is then left waiting for a public decryptor whose release date nobody knows. What exactly distinguishes the variants of this threat is described in our guide to ransomware.
How do you build your own ransomware cost calculation?
Assemble six rows, assign an owner to each figure, and calculate what can be calculated today. The table below is a working sheet — the last column says whether the item can be estimated before the event or only after it.
| Line item | Formula | Who holds the data | Estimable before an attack |
|---|---|---|---|
| Downtime | Margin per hour × hours of unavailability × share of the process | CFO and process owner | Yes |
| Recovery | (Systems × recovery time × rate) + support + verification | Head of infrastructure | Yes, after a restore test |
| Data lost after the last backup | Transactions per hour × cost of reconstructing one × RPO in hours | Heads of operational departments | Yes |
| Regulatory handling | Team and adviser hours spent on notifications within 24 h, 72 h and one month | Data protection officer | Yes |
| Establishing scope and notifications | Forensic analysis + (people × cost per notification) + legal support | Data protection officer and legal team | Partly — depends on log retention |
| Hardening after the event | Cost of the planned programme × urgency multiplier | Head of security | Yes |
The boundary of estimation. Five items you can calculate today, at your desk, from data the company already holds. The sixth — an administrative fine — is not estimable, because it depends on a decision by an authority rather than on your arithmetic. Enter the statutory floor instead (PLN 20 000 for an essential entity, PLN 15 000 for an important one) and mark it as a minimum rather than an expected value. A bill in which one item is openly flagged as incalculable defends itself before a board better than one in which every figure looks certain.
The order of work matters. Start with the third item, because it is the cleanest and shows fastest what your current RPO costs. Then measure the recovery time of a single system, because that is the only way the second item stops being guesswork. Only with those two figures in hand should you return to the budget conversation — now you bring data to it, not somebody else’s averages. At nFlo we run this work as part of a business continuity and disaster recovery plan, where the downtime cost calculation is the starting point rather than a by-product of the implementation.
