What to do when your company has been breached

A breach is chaotic. The decisions made in the first few minutes often determine the extent of the damage. This article gives you a clear plan of action for the first critical hours – and what you need to do once the immediate crisis is under control.

Dealing with an active incident? Call +46 10-333 10 33 now.

Do this first – the first 30 minutes

The biggest mistakes that make a breach harder to investigate happen in the first thirty minutes. Keep a clear head and do the following.

‍

• Do not shut down the systems. Memory contains valuable information about what has happened. Isolate instead – disconnect from the network but leave the machines running.
  ‍
• Assemble the incident team. The IT manager, CISO or security officer, and legal counsel need to be informed immediately. This is not the moment for one person to make decisions alone.  
  ‍
• Document everything from the start. Timestamps, screenshots, log extracts. What you are seeing, what you are doing, and when. This material will be needed for the investigation and for any regulatory reporting.
  ‍
• Bring in external expertise. Internal competence rarely goes far enough during an active breach. The earlier you bring in outside help, the more can be salvaged.
  ‍
• Inform leadership. The CEO and board need to know what is happening. They do not need every technical detail, but they need to be prepared to make decisions quickly if required.

The first 24 hours – containment

Now it is about limiting the damage and understanding what you are actually dealing with – without destroying the evidence you need for the investigation.

‍

• Isolate affected systems without shutting them down. Disconnect them from the network to stop the attacker from moving laterally, but preserve the system state for forensic analysis.
  ‍
• Secure logs immediately. Logs are volatile – they can be overwritten or deleted. Export and protect them as soon as possible: firewall, Active Directory, endpoints, and any other systems that may be affected.
  ‍
• Identify patient zero. Where did the chain of events begin? Which system was compromised first, and how did the attacker get in? This is essential for understanding the full scope and making sure you close the right gaps.
  ‍
• Assess how far the breach has spread. Has the attacker escalated privileges? Moved laterally through the network? Exfiltrated data? The answers to those questions drive every prioritization decision going forward. Assume the damage is worse than it appears until you know otherwise.

Reporting obligations – deadlines

A breach triggers reporting obligations – and the deadlines are tight. Missing reporting deadlines means fines and regulatory action on top of everything else you are already dealing with.

‍

• NIS2 requires an initial report to the relevant supervisory authority within 24 hours of becoming aware of the incident. A full report must follow within 72 hours. For essential and important entities, this applies without exception.
  ‍
• GDPR requires the supervisory authority to be notified within 72 hours if personal data is involved, and the breach poses a risk to the individuals affected. Not sure whether personal data is involved? Assume it is and act accordingly.
  ‍
• Your insurer should be contacted within 24 hours. Check the terms of your cyber insurance policy – many have specific requirements around when and how a claim must be reported. Miss the window and your right to compensation may be affected.
  ‍
• The police should be contacted if extortion is ongoing or if the damage is significant. In Sweden, the National Operations Department (NOA) handles reports of cybercrime.

Communication – what do you say, and to whom?

Communication during a breach matters just as much as the technical response. What you choose to say – and not say – has a direct impact on trust, both with customers and internally.

‍

• Internally, leadership should receive daily situation updates for as long as the incident is active. Other employees are informed once you have an accurate and complete message to give – not before. An information vacuum breeds rumors, and rumors during a crisis create unnecessary anxiety and make the situation harder to manage.
  ‍
• Externally, the key is to separate what you know from what you suspect. Customers whose data may have been affected should be informed, but wait until you have the facts. A pattern of rushed communications that keep getting corrected undermines confidence far more than the breach itself.
  ‍
• Media should be handled carefully. Do not make public statements until you have a clear picture of what has happened. Prepare a brief, fact-based statement in consultation with legal and communications.
  ‍
• Suppliers and partners with access to your systems should be notified if there is any risk that they are affected.

Should you pay the ransom in a ransomware attack?

The recommendation is no.  

Paying does not guarantee you will get your data back. A significant proportion of organizations that pay either receive non-functioning decryption keys or face further extortion shortly afterwards. There is also a legal risk: if the attackers are on a sanctions list, paying could expose your organization to regulatory consequences.

If payment is being considered, that decision should never be made without legal counsel and external incident response expertise involved. The consequences are too far-reaching to be decided under time pressure and in a state of panic.

Regardless of whether payment is on the table, always work in parallel on restoring from backup. It gives you leverage and reduces your dependence on the attacker's cooperation.

After the incident – what comes next?

Once the acute phase is over, the next task is understanding what happened and making sure it won't happen again.

‍

• Restoration should be carried out from verified, clean backups. Do not reconnect systems to the network until they have been forensically reviewed and hardened.
  ‍
• Root cause analysis is the most important step – and the one most organizations skip. How did the attacker get in? What made it possible? Without answers to those questions, you risk fixing the symptoms while leaving the underlying problem intact.
  ‍
• Lessons learned should be documented and shared across the organization to ensure that the same vulnerability cannot be exploited again.
  ‍
• Improve your preparedness. An incident is the most concrete input you will ever get for strengthening your security posture going forward. That means updated procedures, technical hardening, and regular testing of your systems.