In August 2026 the victim lists published by ransomware groups read like an extract from the commercial register: injection moulding, civil engineering, hydraulics, packaging systems, software houses, market research. Almost every day another DACH company appears on a leak site. Anyone reading those lists, however, sees only half the story. Survival is not decided by the attack but by how quickly production resumes afterwards.
This article is an in-depth expert contribution from our content cluster. Discover the complete overview on our main page:IT Security & Compliance →
- The wave is real and broad: Check Point Research recorded a 124 per cent increase in cyberattacks across the DACH region for 2025. The victim lists published in the summer of 2026 consist almost entirely of mid-sized firms from industry, construction and services.
- The damage happens after the attack: A German textile finishing company had to file for insolvency in the summer of 2026 after production stood still for almost six weeks following a cyberattack. It was not the encryption that proved fatal but the downtime.
- Recovery is a leadership task: Immutable backups, a tested restore procedure, a prioritised restart order and a communication chain outside your own systems — four things that must be decided before the incident.
The wrong question is: will they get in?
Given enough attempts, someone eventually gets in. The question that decides between continuity and insolvency is a different one: how many days can your company go without producing before it can no longer be saved — and do you know that number?
1. What the victim lists really show
Specialist outlets now maintain continuously updated lists of German companies that appear on the leak sites of extortion groups or have confirmed an incident themselves. For August 2026 those lists include firms from injection moulding, civil engineering, hydraulics, packaging technology, engine manufacturing and software development — alongside Statista, a well-known data provider that disclosed its own incident publicly. Entries follow one another at intervals of one to two days.
Three observations matter more than the individual names. First, the size of the victims is far below what is conventionally regarded as a worthwhile target. Second, the sector spread is essentially complete; no segment is statistically spared. Third, the same group names recur, which points to industrialised, division-of-labour structures rather than opportunistic actors.
Check Point Research provides the quantitative context: for 2025 it recorded a 124 per cent increase in cyberattacks across the DACH region, with Germany carrying the bulk of registered incidents. That evidence base was one reason the German legislator dispensed with a transition period in the NIS2 implementation act, despite industry associations having asked for one.
2. Why mid-sized firms get hit
The widespread assumption that small firms are of no interest to attackers rests on an outdated picture of the offender side. It dates from a time when an attack required manual work and therefore only paid off at large ransom sums. Ransomware-as-a-Service has fundamentally shifted that calculation.
Division of labour lowers the barrier
One group provides malware, negotiation infrastructure and leak site; affiliates run the attacks and share the proceeds. Attackers no longer need development capability of their own. The result is a volume business in which five-figure ransoms are attractive.
Targets are not selected, they are found
Entry usually happens through broadly exploited vulnerabilities in exposed systems or through stolen credentials. Anyone who is vulnerable gets found — regardless of sector, revenue or public profile.
Small firms pay faster
A mid-sized company without a recovery plan faces a choice between paying and standing still after 48 hours. From the attacker's perspective that willingness to pay is an advantage, not a drawback — a higher conversion rate compensates for the smaller sum.
The detour through the supply chain
A small service provider with remote access to customer systems is a lever, not a marginal target. That is why pressure through security annexes in framework agreements is rising so sharply; we described it in NIS2 in the Supply Chain.
On top of this comes the method of Double Extortion: data is exfiltrated before encryption, so a clean backup rescues operations but does not prevent the breach. For preparation this means recovery and notification duties are two separate work streams that must run in parallel.
3. From incident to insolvency
The case most discussed in the DACH trade press in the summer of 2026 concerns a German textile finishing company: after a cyberattack, production stood still for almost six weeks, and insolvency proceedings followed. The sequence is instructive because it inverts the usual narrative. Neither the encryption, nor the ransom demand, nor even the data exfiltration was the existential event. The downtime was.
Six weeks without production means, in a supplier business: no invoicing while fixed costs continue, contractual penalties or at least lost call-offs from customers, orders migrating to competitors, and a loss of trust that outlasts the restart. Commercially, the attack is the trigger; the insolvency arises from the combination of liquidity headroom and recovery time.
The visible event
Encryption, ransom demand, leak site. It dominates media coverage and internal attention in the first days.
Day 0 to 3This is where it is decided whether a structured process starts at all — or improvisation.
The expensive event
Standstill of production, order processing and invoicing while fixed costs remain unchanged.
Week 1 to 6This is where it is decided whether the company survives the incident commercially.
From this follows an uncomfortable leadership question that can be answered before any incident: how many weeks of standstill can your company absorb before liquidity runs out? That number is the real yardstick for every investment in recovery readiness — and it appears in almost no IT concept.
The calculation can be sketched without specialist financial knowledge. Take monthly fixed costs, add the contribution margins of the orders that will not be processed during downtime, and set that against available liquidity plus committed credit lines. The result is a number in weeks. In the mid-market projects we have supported, it regularly landed between two and five weeks — considerably below what the participants had estimated beforehand.
Comparison: unprepared vs. prepared recovery
- First hours: Debate about responsibilities instead of containment; systems keep getting encrypted.
- Backups: Present but never restored — their actual state becomes known only during the incident.
- Order: Recovery starts with the technically easiest system rather than the revenue-critical one.
- Communication: Customers learn about the incident from the leak site rather than from their supplier.
- First hours: Defined containment steps, named decision-makers, a logged procedure.
- Backups: Immutable copy outside the domain, restore duration known from the last test.
- Order: Numbered restart list with dependencies, agreed with the business units.
- Communication: Prepared message templates and a channel that works without your own mail infrastructure.
What stands out is how little investment the right-hand column contains. Almost all of it is preparatory work in the form of decisions, lists and one test appointment. The only item with meaningful cost is the immutable backup copy — and with most providers even that is a configuration option rather than a new platform.
4. RTO and RPO: the two numbers
The whole of recovery planning condenses into two figures that are set by the business rather than by technology. Management decides; IT builds to the decision.
RTO — how long may it take?
The RTO describes the maximum tolerated time until a process is available again. It is process-related, not system-related: order intake may have an RTO of four hours while the archive tolerates two weeks. Applying one figure to everything means building either too expensively or too slowly.
RPO — how much work may be lost?
The RPO measures tolerated data loss as a period of time. A nightly backup means an RPO of up to 24 hours — too much for an ERP system in many businesses. The answer is rarely “back up more often” but more usually a different backup architecture.
The third variable: immutability
Attackers deliberately locate and delete backups before encrypting. An Immutable Backup cannot be altered for a defined period, not even with administrative rights. Without that property, every RPO is theoretical.
In practice we recommend starting the exercise not with IT but with three to five core processes: order intake, production control, dispatch, invoicing, payroll. Management sets an RTO and RPO for each. Only then is the cost assessed technically — and it usually turns out that the expensive requirements genuinely apply to only one or two processes.
5. The recovery plan
A recovery plan is not a security concept. It answers a single question: in what order does what come back, and who decides? Four components are indispensable.
A numbered list of systems with dependencies. Without it, recovery experience shows, work begins with the technically simplest system rather than the commercially most important one.
Network diagrams, credentials for break-glass accounts, supplier and customer contacts, insurance policy. Printed or on an encrypted medium outside the domain — during the incident the intranet is unreachable.
A second channel for the crisis team, staff and key customers that does not depend on your own mail infrastructure. Private phone numbers in a maintained list suffice, as long as the list can actually be found.
Who may take systems offline, who speaks to authorities, who to customers, who engages external forensics? Settling these questions during the incident consumes the most valuable hours of the entire process.
Expert tip: the restore test beats every concept
Take one afternoon and restore a production system from backup into an isolated environment. Time it, log the result. In almost every project we have supported, at least one unpleasant surprise surfaced: missing licence keys, a database that was never included, an account without a current password. These are surprises you do not want on the day of the incident.
One frequently overlooked factor is insurance. Cyber insurers now routinely ask in their questionnaires for exactly the evidence that also enables recovery: multi-factor authentication for administrative access, segregated backup copies, documented restore tests. Filling in those answers optimistically and being unable to evidence them during a claim risks reduced settlement — a risk that the same documents used for customer audits eliminate.
Equally underestimated is the staffing bottleneck. A multi-day recovery ties up the same two or three people around the clock who also run the systems in normal operation. Without deputisation and without a standing support agreement, the process ends in exhaustion after 72 hours, with a corresponding error rate. A pre-agreed retainer with an incident response provider costs little and materially shortens reaction time when it matters.
6. The first 48 hours
The sequence after discovery is similar in almost every case. Knowing it in advance means losing less time to questions of principle.
Isolate affected segments, cut remote access and site-to-site connections to customers, disconnect the backup infrastructure. The temptation to understand first costs systems at this stage.
Convene the crisis team, inform external forensics and the insurer, secure logs and system images before anything is rebuilt. Without that preservation, neither cause nor scope can be established reliably later.
Report to the competent authorities and — often much sooner under contract — to affected customers. Where personal data is involved, the 72-hour GDPR clock runs in parallel. Regulated customers need your information for their own 24-hour early warning.
Restore along the prioritised order into a clean environment, not the compromised one. In parallel, reset all credentials and check for remaining persistence. Cutting corners here frequently leads to a second encryption.
One point deserves particular mention because it regularly gets lost in the rush: the decision on paying a ransom is not an IT decision. It is a management decision with legal, insurance and reputational dimensions — and it should be prepared before anyone opens a chat with extortionists under time pressure.
7. Seven steps to recovery readiness
-
Step 1: name the core processes
Three to five processes without which no revenue is generated. Management compiles this list, not IT — it is the basis for everything that follows and rarely takes more than an hour.
-
Step 2: set RTO and RPO per process
For each core process, a figure for restored availability and tolerated data loss. Deliberately coarse: hours or days, not minutes. What matters is the decision, not its precision.
-
Step 3: test the backup architecture against the numbers
Does the existing backup meet the agreed values — and is at least one copy immutable and outside the domain? This check usually exposes the single largest gap in the whole exercise.
-
Step 4: run a restore test
One production system, one isolated environment, a stopwatch, a logged result. The test is the transition from concept to capability and should be repeated at least annually.
-
Step 5: build an offline emergency folder
Network diagrams, break-glass accounts, contact lists, insurance documents, restart order. Two copies in separate locations, updated at least every six months.
-
Step 6: write down roles and decision rights
Crisis team with deputies, spokespeople towards customers and authorities, authority to disconnect networks and engage external help. One page is enough, as long as it is approved and known.
-
Step 7: rehearse once a year
A two-hour tabletop exercise with the crisis team on a concrete scenario. The insight almost always lies in the interfaces — who informs whom, and when — rather than in the technology.
An attack is an event. A standstill is a process. Only the second one can be shortened in advance.
Quick check: are you recovery-ready?
Conclusion
Attack numbers across the DACH region cannot be optimised away. A company can reduce its attack surface, harden access and train its staff — the probability falls, but it does not reach zero. Shifting emphasis from prevention to recovery is therefore not capitulation but the more realistic investment decision.
The textile finisher's case shows where the line runs. Six weeks of standstill was not survivable for a manufacturing SME with ordinary liquidity headroom. Two days would have been. Between those two numbers lies no major technical programme but a handful of decisions taken before the incident: immutable backups, a tested restore, a prioritised order and an emergency folder that is available offline.
If you want to start somewhere, start with the restore test. It costs an afternoon and is the only measure that tells you honestly where you stand. Our emergency plan for SMEs complements this on the organisational side.
Do you have questions about your recovery readiness?
Book a free initial consultationOur Regional Expertise
We are your digital partner – regionally anchored and successfully scaling across borders.
Have a vision?
Let's check together how we can make your idea take flight.
Book your free strategy call nowExtended Specialized Glossary
Ransomware-as-a-Service
A division-of-labour business model in which one group supplies the malware and infrastructure while affiliates carry out the actual attacks. It lowers the technical barrier to entry and explains why even very small firms become targets.
Double Extortion
An extortion method in which data is exfiltrated before encryption and its publication threatened in addition. A working backup then saves operations but does not prevent the data breach.
RTO
Recovery Time Objective — the maximum tolerated period before a process or system must be available again after an outage. It is set by the business, not by IT, and determines the architecture of the recovery.
RPO
Recovery Point Objective — the maximum tolerated data loss, measured as the interval between the last usable backup and the incident. An RPO of four hours means up to four hours of work may be lost.
Immutable Backup
A backup that cannot technically be altered or deleted for a defined retention period, not even with administrative rights. It is the single most effective measure against attackers who deliberately destroy backups.
