Attackers stopped waiting for patches, logins, and permission. Getting ready means deciding things before they do.
On October 17, someone started testing an exploit for a PHP flaw that wouldn’t have a patch for another four days. A couple of weeks later, Binance explained that its $6.3 billion theft started with a recruiter, two friendly rounds of interviews, and a coding “assignment” that took over an engineer’s laptop.
I’ve worked both sides of stories like these, offense and defense, and what stands out to me in both is how little the attackers had to break. One moved before the defenders had anything to install. The other walked in through a job offer. In both cases, the people tasked with responding had very little time between learning something was wrong and needing to act on it.
That shrinking window is the story of incident response in 2026. The technical side of a response still matters, and plenty of teams are good at it. What separates a contained incident from a costly one now is how quickly an organization can make sound decisions under pressure, and the teams that do it well tend to have made those decisions before the incident ever started.
How Has Incident Response Changed in 2026?
For years, incident response ran on a comfortable rhythm. A flaw got announced, a patch came out, someone tested it, and the update rolled out the following week. That rhythm assumed the attacker was waiting for the same announcement you were. PHP2Shell showed how that assumption breaks, with exploit attempts arriving days before the fix.
AI is speeding that up on both sides. PHP2Shell was found by researchers working with AI models, and the same kinds of tools can help attackers find weaknesses and turn them into working attacks faster than a person could. When the attack side starts moving at machine speed, a response that runs on meetings and long email threads falls behind quickly.
Attackers have also gotten better at coming in through things you already trust. Earlier this month, an attacker was signing in to Microsoft 365 as the apps themselves, using stolen app credentials at more than two dozen organizations. Multi-factor authentication never came into play, because MFA protects people, and these sign-ins looked like routine automation. When the way in looks like normal business, the alert that tells you something is wrong tends to arrive late.
Then there’s the attack that outlasts the cleanup. Zyxel shipped a fix for its office switches in June that, as it turns out, never worked. Binance caught a tampered coding tool on a wallet engineer’s machine in June, replaced the device, changed the credentials, and still saw the same team targeted again four months later. The checklist said done in both cases, and the attackers had other plans.
You’ll notice the hoodie-wearing genius doesn’t show up in any of these stories. The way in was a fast exploit, a trusted app, a patch that didn’t get re-checked, or a person having a pleasant conversation with a recruiter. The common thread is time. Each attack worked in the space between an organization learning something and acting on it, and that space keeps getting smaller.
When the window shrinks like that, the slowest part of a response usually stops being the technology, and instead becomes the people trying to figure out who gets to decide what.
Who Needs to Be Part of Incident Response?
A lot of organizations still treat incident response as the security team’s job, right up until the decisions start landing on other desks. Somebody has to decide whether to take a system offline in the middle of a business day and eat the downtime. Somebody decides whether to pay a ransom, when to tell customers, and what to say if a reporter calls. Public companies have four business days after deciding an incident is material to report it to the SEC, and plenty of contracts and insurance policies carry notification deadlines of their own. Those calls belong to leadership, legal, and communications, and they’re much harder to make for the first time at 2 a.m.
The research points the same way. In Sygnia’s 2026 survey of more than 600 senior security leaders, 99% said they have a formal incident response plan, and 73% still said their organization wouldn’t be fully ready for a major attack. When asked why, 89% pointed to limited involvement from executives and the board. Nearly everyone has the plan, and leadership sign-off is often what the plan is still waiting on.
The response reaches further down the org chart, too. The help desk usually takes the first call. Finance gets the convincing request to change a vendor’s bank details. An employee notices a strange login prompt and has to decide whether to mention it. An incident has a way of finding the one person who wasn’t invited to the planning meeting, so the plan works better when everyone knows their part before it does.
Knowing who’s involved gets you halfway there. The other half is giving those people something to work from when the clock starts.
What Does a Ready Team Look Like?
Readiness tends to show up in three stretches of time: before an incident, during it, and after it. Teams that handle incidents well usually have something in place for all three.
Before anything happens, there’s a plan someone has tested, kept somewhere you can reach when your usual systems are down. A plan that lives only in a shared drive tends to vanish right when the shared drive does. Alongside it sit playbooks, the step-by-step guides for specific situations like ransomware, an account takeover, or a fraudulent payment request. A good ransomware incident response playbook answers the questions that start arguments in the moment, such as who can approve shutting systems down, which backups get checked first, and who calls the insurance carrier. Finding the carrier’s hotline at 2 a.m. is a rough way to meet them.
During an incident, roles matter more than heroics. Each person should know whether they’re making decisions, gathering evidence, talking to customers, or staying out of the way, which is a real and underrated job. The team needs a way to talk that the attacker can’t read, since the email and chat accounts you’d normally use may be part of what was compromised. And the plan should say what gets preserved before anyone starts cleaning up, because evidence has a habit of disappearing the moment someone reboots the wrong machine.
After the incident is contained, the work keeps going. Fixes need verifying, since a patch that installed cleanly can still leave the door open, as Zyxel’s customers found out. Someone needs to ask what the attacker could have learned while they were inside and adjust access to match. And the plan needs updating with whatever the incident exposed, so the next response starts from a better place than this one did.
This is ordinary preparation, and it holds up because it’s been worked through before anyone needs it. A written plan is a hypothesis until a team tests it, and that’s where practice comes in.
How Tabletop Exercises Put the Plan to the Test
A cybersecurity tabletop exercise puts the right people in a room, walks them through a realistic scenario one development at a time, and lets them make the decisions out loud. It’s the cheapest incident you’ll ever have. Nothing is broken, no data is going anywhere, and the worst outcome is a bruised ego.
Good tabletop exercise scenarios are plausible enough to make the room shift in their seats, run about an hour, and include the people who’d be in the room for real, not only IT. They tend to surface the same kinds of problems. Two people both think they own the decision to shut down a system. The team can’t say where the offsite backups live. The phone tree still lists someone who left last spring. Each of those is easy to fix on a Tuesday afternoon and painful to discover during an actual incident.
Running a few of these a year, with different scenarios and a rotating cast, builds the kind of muscle memory a plan on paper can’t. It also gives leadership a low-stakes way to practice the calls they’ll be expected to make, which is the same involvement the Sygnia survey found missing.
Where Incident Response Training Fits In
That thinking is behind Galactic’s Incident Response Seminar, which runs tomorrow, November 11, from 10:00 AM to 4:55 PM ET. It’s free and virtual, and it’s built for everyone who’d have a part in a real incident, from the people working the alerts to the people signing off on the hard decisions. The day moves from how attackers are getting in now, through detection, recovery, and leading through an incident, to a live walkthrough of a compromised machine and a session on playbooks and tabletops.
Everyone who attends leaves with tools to keep the practice going afterward. The Galactic IR Playbook Binder covers 49 incident scenarios with step-by-step instructions. The IR Playbook Skill puts that same library into the AI model you already use, so you can ask it questions in the middle of a response. And a set of ready-to-run tabletop exercises gives your team a way to test its own plan in about an hour.
The Decisions You Make Before Anything Breaks
The PHP attackers had four days before anyone could patch, and Binance’s attackers had four months between the cleanup and the theft. In both cases, the attackers had already done their planning. The organizations on the other side were the ones deciding things in real time.
That’s the part any team can change. A day spent working through these decisions before anything is on fire beats a night spent making them up as you go, whether you spend that day with us tomorrow or with your own team next week.
