Less than two hours later, the affected systems have been isolated, our incident response plan has been activated, and the forensic investigation is already underway. While the attack itself lasted only a short time, dealing with its consequences would occupy us for almost three weeks.

The most important piece of good news was that our production customer systems continued operating throughout the incident. Once the forensic investigation was completed, there was no evidence that customer data, source code, or production databases had been affected. Nevertheless, our company spent nearly three weeks operating in crisis mode, managing technical, organisational, and legal challenges simultaneously.

Today, we have made a conscious decision to share this experience publicly. Not as a flawless success story, but as an honest account of an attack that reminded us that even companies with extensive cybersecurity expertise can have vulnerabilities and make mistakes.

What matters is not being completely free of mistakes, but being prepared when something goes wrong. Proper preparation can limit the spread of an attack, reduce the damage, and help a company remain operational during a crisis. It is equally important to review the incident honestly afterwards and learn from the experience.

The First 120 Minutes

While the attackers are still trying to pressure our employees over the phone, our initial emergency measures are already underway. All relevant employees are brought together in an online conference, the existing incident response plan is activated, and responsibilities are assigned for forensic investigations, technical recovery, legal matters, and communication.

At the same time, our technical teams begin systematically shutting down parts of the infrastructure and disconnecting affected systems from the network. The initial forensic assessment begins while the next steps to contain the attack are coordinated in parallel.

In a situation like this, there is little time for lengthy discussions about fundamental responsibilities. Decisions must be made quickly about which systems need to be shut down, who will document the technical measures taken, and who will communicate with employees, customers, and external parties. At the same time, potential legal notification and reporting obligations must be assessed, and cooperation with forensic and legal specialists needs to be organised.

Many of these questions seem straightforward during normal business operations, until they need to be answered under considerable pressure. Having clearly defined roles and responsibilities in place did not prevent the attack, but it ensured that the technical incident did not escalate into an organisational crisis as well.

Monday: Customer Services Are Running, but Internal Operations Are Disrupted

The greatest relief becomes apparent on the following Monday: our production customer systems are still operating normally. Our SaaS platforms remain available, and based on the information available at that time, there is no indication that the production environment has been compromised.

The fact that customer services remain operational is no coincidence. It is the result of a deliberately designed security architecture. Our production and administrative systems are strictly separated. Internally, we refer to this approach as our "submarine principle", where technical compartments are designed to prevent a security incident in one area from spreading unchecked into other parts of the infrastructure.

This separation proved particularly valuable during the attack. Nevertheless, the impact on our internal operations was considerable. Administrative systems were only partially available, several internal processes had to be reorganised on a temporary basis, and technical investigations, legal assessments, and communication with customers and employees were all taking place simultaneously.

The incident clearly demonstrated that a cyberattack can place a substantial burden on a company even when its customer-facing services continue to function. The availability of production systems does not necessarily mean that the rest of the business can operate without disruption.

Prevention remains the objective. Resilience makes the difference when prevention fails. A well-designed security architecture must therefore focus not only on preventing attacks, but also on containing their consequences as effectively as possible when an incident occurs.

The Hardest Question: Which Systems Can We Still Trust?

Under certain circumstances, an affected system can be restored relatively quickly from an existing backup. The far more difficult question is whether that system can actually be considered safe to use afterwards.

During recovery, we therefore had to determine not only which systems and data had been affected, but also whether user accounts had been compromised, additional access points had been created, or permissions had been changed without our knowledge. Only once these questions have been adequately addressed can responsible decisions be made about which systems may be reconnected to the network and returned to regular operation.

This is one of the most frequently underestimated challenges following a cyberattack. Successfully restoring data does not automatically mean that the original level of infrastructure security has been restored. Achieving that requires a thorough technical assessment and, where necessary, the complete rebuilding of individual systems.

The Entry Point Was an Inconspicuous Peripheral Device

Our forensic investigation revealed that a vulnerability in a peripheral network device had served as the attackers' initial entry point. From there, they managed to move further into the administrative environment and obtain additional privileges.

This finding was particularly important to us because it demonstrated just how extensive a company's actual attack surface can be. When securing IT infrastructure, the focus is often on servers, workstations, and firewalls. It is easy to overlook the fact that less conspicuous network devices also have their own software, user accounts, and network connections.

If these devices are not regularly updated, properly segmented, and consistently monitored, they can become the starting point for a much larger security incident. Our experience made it clear that a comprehensive security architecture must also account for components that may initially appear insignificant.

Data Exfiltration from the Administrative Environment, While Customer Systems Remained Operational

During the attack, data was exfiltrated from our administrative environment. The information involved included internal company and employee data. The incident therefore had real consequences, even though our production customer systems remained available.

Following the completion of the forensic investigation, no evidence was found that the production environment or customer data had been compromised. This distinction was particularly important, both for our internal assessment and for our external communications.

From an outside perspective, a cyberattack is often reduced to a simple statement: a company has been hacked. In reality, however, the technical and business implications can vary enormously. There is a substantial difference between an incident affecting administrative systems and one in which attackers gain access to production customer environments.

We therefore decided to inform customers and employees about the incident at an early stage and to communicate transparently. We explained which areas were affected based on the information available at each stage, which systems showed no evidence of compromise, and what measures had already been initiated to contain and investigate the incident.

This openness was not always comfortable, but it was necessary. Rather than allowing uncertainty to grow through incomplete information, we wanted to provide a factual and understandable basis on which customers and employees could assess the situation.

Why Recovery Took Almost Three Weeks

Our backups worked, and the affected data was stored in encrypted form, with logical and physical separation from the affected systems. Restoring the data itself was therefore not our greatest challenge.

The significantly more demanding task was to thoroughly clean up the affected infrastructure and ensure that the systems could be operated securely again. To achieve this, affected systems were either rebuilt or restored from verified backups, then subjected to additional security hardening before being brought back into operation.

In parallel, we reviewed critical authentication and access structures, some of which had to be rebuilt. As a precaution, all passwords were also reset to reduce potential risks associated with compromised credentials.

This company-wide password reset turned into an organisational challenge that is often underestimated in everyday business operations. To reliably replace all relevant credentials following an attack, an organisation needs to know which accounts exist, who is responsible for them, and which systems depend on one another.

Forgotten administrative accounts and service accounts can make such a clean-up process unnecessarily difficult. Without a complete overview of these credentials, not only does the workload increase, but so does the risk of leaving compromised access permissions unnoticed.

The nearly three-week recovery period demonstrated that functioning backups are an essential foundation for business continuity, but they do not, on their own, guarantee a quick and secure return to normal operations.

Six Decisions That Helped Limit the Damage

Looking back, six decisions and previously established measures were particularly important in helping us contain the impact of the attack and gradually restore normal operations.

1. Consistent Network Segmentation

The strict separation of administrative and production systems limited the spread of the attack and prevented its impact from extending unchecked across our entire infrastructure. The forensic investigation found no evidence of compromise within our production customer systems.

2. Separate and Reliable Backups

Our backups were logically and physically separated from the affected systems, encrypted, and demonstrably recoverable. This gave us a reliable foundation for rebuilding the infrastructure without having to depend on a potential ransom payment.

3. Clearly Defined Responsibilities

Because responsibilities had already been established, technical recovery, forensic investigations, data protection assessments, and communication could all be coordinated in parallel. This preparation saved valuable time and reduced the risk of important decisions being overlooked during the critical first hours.

4. Proactive Communication

Rather than waiting until every aspect of the investigation had been completed, we informed our customers and employees early about the known consequences of the incident. It was important to us to communicate only verified findings and clearly distinguish between confirmed information and questions that remained unanswered.

5. The Ability to Recover Without Paying a Ransom

Our intact backups and the strict separation of the production environment enabled us to pursue recovery independently and without paying the attackers. The decisive factor was our ability to rely on technical and organisational safeguards that were already in place.

6. Support from External Specialists

We engaged external specialists and data protection advisers to assist with forensic analysis and the legal assessment of the incident. Their experience helped us investigate the attack systematically and make important decisions on a sound basis. An active crisis is not the right moment for an organisation to start developing fundamental procedures through trial and error.

What We Underestimated and What We Do Differently Today

The attack revealed not only which security measures had worked, but also where weaknesses remained. In particular, we had underestimated the importance of securing peripheral network devices and monitoring administrative environments.

We have since taken concrete steps to address these findings. Following the incident, we began reviewing our infrastructure segmentation, existing permissions, patch levels, and monitoring processes even more rigorously. We now also use AI-assisted technologies to further develop our security monitoring capabilities.

However, these improvements are not a one-off project that can eventually be considered fully complete. IT infrastructure is constantly evolving, new vulnerabilities emerge, and attackers continuously adapt their methods. Security concepts must therefore be reviewed regularly and adjusted to meet changing requirements.

Above all, the incident reinforced our understanding that security vulnerabilities and human errors can never be eliminated entirely. This makes it all the more important to establish the technical and organisational foundations needed to contain an attack and manage its consequences before an incident occurs.

These foundations include a carefully designed security architecture, clearly defined responsibilities, effective protective measures, and a willingness to critically question established processes. It is equally important to investigate incidents openly afterwards and consistently incorporate the lessons learned into the organisation's long-term security strategy.

Preparation Makes the Difference Before an Incident Occurs

A cyberattack does not automatically end when a compromised server has been shut down or a backup has been successfully restored. The recovery process is only truly complete once affected systems are operating reliably and can be trusted again, critical access credentials have been reviewed and secured, and employees and customers have received clear, dependable answers to their questions.

Our experience demonstrated that cybersecurity extends far beyond the technical protection of systems. It is just as much about business continuity, organisational responsibilities, transparent communication, and the ability of company leadership to make well-founded decisions under considerable pressure.

This raises a crucial question for every business: Would your organisation be able to isolate part of its IT infrastructure at short notice, restore it from secure backups, and keep essential operations running, without first having to determine who is responsible for making decisions and which actions need to be taken?

We had to answer this question under real-world conditions and learned first-hand just how valuable thorough preparation can be.

I hope every company finds its answer before having to face the same question under real pressure.