You have just found an attack: what to do in the first 24 hours

In the first 24 hours after you discover an attack, three things have to happen at once: confirm the incident is real, cut off the attacker's access without destroying the evidence, and accept that the legal notification clock has already started running. Companies improvising all three at 2am tend to make the same mistakes. Someone shuts the server down, someone reimages a disk, logs rotate, and a few days later nobody can answer the only question that matters: what exactly happened, and what data left the building? The good news is that the first day is largely standard work that fits on one page. The bad news is that without that page, everybody does whatever they personally think is right.

The numbers explain why this goes badly so often. IBM's 2025 Cost of a Data Breach report puts the mean time to identify and contain a breach at 241 days: 181 to detect, 60 to contain. Verizon's 2026 DBIR found ransomware in 48% of breaches, and vulnerability exploitation has become the most common way in at 31%. In other words, the response team usually sits down months after the attack began, often with systems already encrypted.

Hour one: verify first, then isolate

Not every alert is an incident. The first job is a fast check on whether what you are looking at is genuinely an attack: an EDR alert, a user report, a warning from a customer, a ransom note. This is triage, not an investigation, and it answers one question in about fifteen minutes. Is there unauthorised access on this machine?

If the answer is yes, isolation starts. Pull the suspect machine off the network, detach the interface if it is a VM, kill VPN sessions and revoke tokens for the accounts involved. Reset credentials for anything that might be compromised, and remember that "anything" includes service accounts and API keys, not just human logins. The goal at this stage is not to fix the problem. It is to stop the spread.

Contain without destroying the evidence

The most common technical mistake is powering off or rebuilding an infected machine. Everything living in memory (running processes, network connections, unencrypted credentials, the attacker's tooling) disappears the moment the box goes down. The right order is: isolate the machine while it is still running, capture a memory image and a disk copy if you can, and only then start cleaning.

Logs are just as fragile. In plenty of companies, firewall, mail gateway and application logs roll over every seven or thirty days. If the intrusion started three months ago, the interesting period is already gone. One of the first administrative tasks on day one is to stop rotation on the relevant sources and copy what exists somewhere separate. If you run in the cloud, this is exactly the moment when keeping audit trails (CloudTrail, Azure activity logs) in a separate write-protected account pays for itself.

Do not discuss the incident on a channel the attacker is reading

Writing "I think we've been hacked" in corporate email or Teams tells an attacker who is still inside exactly what you know and what you plan to do next. Ransomware crews do read those threads. They use them to accelerate encryption or to delete backups before you get there.

Response communication belongs on a separate channel: a dedicated messaging group, accounts outside the corporate directory, phone calls when needed. A printed copy of the key phone numbers sounds old-fashioned right up to the morning when every laptop in the company is encrypted.

Decision rights have to be written down in advance

The biggest time sink on day one is not technical. It is the question of who is allowed to take production offline. Shutting an e-commerce site down for several hours is a commercial decision, and if nobody knows who can make it at 3am, the team waits. The attacker does not.

What the plan needs to state is short: who runs the incident (one named incident lead), who does what on the technical side, at which severity executives get pulled in, who owns legal and communications, and which external firm you call for help. If you hold an incident response retainer, put the number on page one. If you do not, arrange one now, because negotiating a contract mid-crisis is the worst possible timing. If you carry cyber insurance, read the notification deadline and the approved-responder clause before an incident, not during one.

The legal clock starts before you are ready

For any breach involving personal data in Turkey, the KVKK framework is specific. Under Board decision 2019/10 of 24 January 2019, the data controller must notify the Board without undue delay and within 72 hours of becoming aware of the breach, explaining the reason if that deadline slips. Affected individuals must be notified as soon as reasonably possible once they have been identified, and the Board has repeatedly made one point clear: publishing a notice on your website does not count as notifying people you have already identified. You also have to keep a record of the breach, its effects and the measures taken.

There is now a second layer. Cyber Security Law No. 7545, in force since 19 March 2025, requires organisations within its scope to report detected cyber incidents and vulnerabilities to the Cyber Security Directorate, with the procedural detail set by secondary regulation. Public bodies and critical infrastructure operators already report through USOM's SİP platform. Regulated sectors such as banking, energy and healthcare often carry separate deadlines to their own authority. None of this should be researched on the night of the incident. Work out today which obligations apply to you and write them into the plan.

Eradication and recovery: rushing is the expensive option

Once containment holds, the instinct is to get back online fast, and this is where the second breach is born. Restoring without knowing how the attacker got in usually means restoring into a system with the same hole still open. Do not return to production before you have the root cause, have removed persistence (freshly created admin accounts, scheduled tasks, planted RMM agents) and have rotated every credential in scope.

Decide the restore order in advance too. Which system comes back first, from which backup, and does that backup predate the intrusion? The 3-2-1 rule and regular recovery drills exist for precisely this night. In a ransomware scenario, assume the attacker went looking for your backups first. For two weeks after recovery, raise your monitoring level. The same group coming back is a normal outcome, not an unlucky one.

A plan is one page, not a binder

Most corporate incident response documents run to forty pages and nobody opens them in a crisis. The version that works fits on a single sheet: who you call, in what order, who decides what, and which notification is due within how long. Detailed procedures can live in the appendix.

The frameworks themselves have shifted in the same direction. In April 2025 NIST published SP 800-61 Revision 3, dropping the old four-phase lifecycle and rebuilding incident response around the CSF 2.0 functions (Govern, Identify, Protect, Detect, Respond, Recover). The message is that incident response is not a few days of activity around a breach; it is part of continuous cyber risk management. In practice that means the unglamorous work decides how your worst night goes: patch management, endpoint visibility and backups you have actually restored from.

An untested plan is not a plan

The cheapest way to find out whether your plan works is a tabletop exercise. Block two hours, hand the team a concrete scenario ("Friday 5:30pm, the finance file server is encrypted, there is a ransom note") and make them take decisions in real time. Invite more than IT: legal, HR, communications and the executive who will have to make the call.

The findings tend to rhyme across companies. The contact list is out of date, nobody has access to the logs, no one is authorised to call in outside help, and the restore takes three times longer than anyone estimated. Learning that in a drill is free. Learning it during a real incident is not.

At Wedevit we build the incident response plan around how your company actually operates, run the tabletop exercise, and turn the gaps it exposes into a prioritised roadmap. If you also want to see how your environment looks from the outside before the plan is written, a penetration test is the natural starting point.