Opens in a new tab

NEW ARTICLE: Racing Zero: The Successful Phishing Response Read Now

Supporting organizations across the entire U.S.

Racing Zero: The Successful Phishing Response

Cybersecurity

Written by

David McBride

Published on

An employee opens an email that looks like it came from a vendor the business uses every week. The link goes to a login page that looks exactly like the real one. They type in their username and password, or, on a system protected by multifactor authentication, they approve a push notification that arrived a few seconds after they logged in somewhere else that morning. Nothing looks wrong in the moment. The page redirects, the notification clears, and the employee moves on to the next task.

That moment, not the weeks of prevention that came before it, is where most cybersecurity readiness is actually tested. Verizon’s 2026 Data Breach Investigations Report found that the human element was present in 62% of breaches, up slightly from 60% the year before, and that phishing remained the initial access vector in 16% of breaches, unchanged from the previous year. Those figures describe a steady, predictable pattern rather than a rare event. Somewhere in a given organization, on a given week, someone is going to click.

Racing the Zero-Day Clock, our five-part series for Cybersecurity Awareness Month, has so far looked at how quickly attackers move once a vulnerability is disclosed and which foundational gaps most businesses still need to close. This fourth piece moves from prevention into what happens after prevention has already failed once, in one specific, ordinary way: an employee made the mistake attackers are counting on. What a business does in the minutes that follow determines whether that click stays a contained event or turns into a breach with a price tag attached.

For a small or midsize business without a dedicated security team, that response is rarely designed on purpose. It is often improvised the first time it is needed, which is precisely the wrong moment to be figuring it out. The rest of this article looks at why the minutes immediately after a click carry so much of the cost, what a business needs in place before that moment arrives, and what that kind of readiness actually requires from both employees and IT.

The Minutes That Decide the Outcome

Attackers do not wait to find out whether a stolen credential works. Mandiant’s M-Trends 2026 report found that the handoff between the group that gains initial access to a network and the secondary group that monetizes it, often a ransomware operator, has compressed from a median of more than eight hours in 2022 to just 22 seconds in 2025, with initial access groups pre-staging the next group’s tools before the intrusion even completes. A compromised credential or an approved MFA request is not a problem a business can plan to notice and address at its own pace. In a growing number of cases, the handoff to the group that causes the real damage happens before anyone on the business side has a reason to look.

Set against that pace, the average business is moving far slower. IBM’s 2026 Cost of a Data Breach Report put the global average cost of a breach at $4.99 million. eSecurity Planet, reporting on that same IBM study, found that organizations took an average of 247 days to identify and contain a breach, and that breaches resolved in under 200 days cost $4.32 million on average, compared to $5.65 million for those that dragged on past that point. The gap between a 22-second attacker handoff and a 247-day average business response is not a gap a business closes by asking employees to be more careful. It closes by shortening the distance between the moment something looks wrong and the moment the right person finds out about it.

Preparation Means Assuming Someone Will Click

The instinct in a lot of small businesses is to treat a successful phishing email as a training failure: someone should have known better, and the fix is another round of awareness sessions. Training has a real role to play, but treating it as the whole plan misreads what the data actually shows. A credential given up to a fraudulent login page or an MFA request approved out of habit is not a rare lapse in judgment. It is one of the most common and well-practiced tactics in an attacker’s playbook, aimed at a workforce that has dozens of logins and hundreds of emails to get through in a day.

NIST’s SP 800-61 Revision 3, the federal government’s current guidance on cybersecurity incident response, reflects that same shift in framing. The document states that incident response “is now considered a critical part of cybersecurity risk management that should be integrated across organizational operations,” rather than a technical function IT handles in isolation after something breaks. That distinction matters for a business owner deciding where to invest. A cybersecurity incident response plan is not a document that lives exclusively with the IT team, pulled out only once something has already gone wrong. It is a set of decisions made in advance about who does what, made by people across the business who are likely to be the first to notice that something is off, not only the people equipped to fix it.

Building the Reporting Path Before an Incident Happens

The specific decision most businesses have not made in advance is the simplest one: what does an employee actually do in the moment they suspect they clicked the wrong link, entered credentials somewhere they shouldn’t have, or approved an authentication request they did not initiate?

The CISA Cross-Sector Cybersecurity Performance Goals treat this as a specific, checkable control rather than a general aspiration. Goal 4.A calls for organizations to “maintain codified policy and procedures on to whom and how to report all confirmed cybersecurity incidents,” and Goal 2.S calls for incident response plans that are drilled at least annually, not written once and filed away. Put together, those two goals describe exactly what most SMBs are missing: a plan that names a specific person or channel to contact, states plainly what information that person needs (what happened, when, on which device or account), and has actually been rehearsed rather than assumed to work.

What an employee should not do matters just as much as what they should. The FTC’s small business guidance on phishing recommends immediately changing any compromised password and disconnecting the affected computer or device from the network, rather than continuing to use it while deciding what to do next. An employee who quietly keeps working on a possibly compromised account, hoping nothing comes of it, or who spends the next hour trying to undo the mistake alone rather than reporting it, is the scenario a well-built phishing incident response plan is specifically designed to prevent. The goal of preparation is not to expect employees to never make this kind of mistake. It is to make sure the mistake gets reported in minutes rather than discovered days later, by someone other than the employee involved.

Giving IT the Access to Move Fast

A reporting path only closes half the gap. Once IT knows something happened, the same speed problem shows up on their side of the process. Investigating a suspected compromise means answering a specific set of questions quickly: which account was used, from where, to access what, and whether the activity has already spread beyond the original point of entry. IT can only answer those questions as fast as its visibility and access allow.

That is why NIST’s incident response guidance treats preparation as infrastructure, not paperwork. The framework calls for documented playbooks that give people “actionable steps or tasks for people to perform during various scenarios,” built before an incident rather than improvised during one, and for clearly assigned authority over decisions such as who can disconnect or shut down a system once something is confirmed. A business that has never mapped out which accounts have administrative access, where its logs actually live, or who has the authority to isolate a compromised device is adding hours or days to a response that the data above shows it cannot afford to lose. Whether that response is ultimately handled by in-house staff or by a technology partner matters less than whether the access and the authority to act are already in place before the incident starts the clock. A partner who only gets called in once a breach is already suspected is starting from the same blank slate an unprepared internal team would. Closing that gap in advance, rather than deciding who handles the response after the fact, is what can make the difference.

The Regulatory Clock Is Starting Too

The pressure to formalize this process is not only coming from attackers. CISA’s rule implementing the Cyber Incident Reporting for Critical Infrastructure Act will require covered critical infrastructure entities to report a substantial cyber incident within 72 hours of reasonably believing it occurred, and to report a ransom payment within 24 hours of making it. The rule itself has faced repeated delays and was not yet final as of this writing, with CISA’s own target for publishing it falling later this year. Most small and midsize businesses will not be directly covered by it.

The direction it points in still matters for every business, covered or not. Reporting a cybersecurity incident within 72 hours is only possible for an organization that already knows, internally, within minutes or hours, that something happened. A business that has never practiced its own internal reporting path is not ready to meet a 72-hour external deadline even if one never technically applies to it, because the internal gap comes first. Building that habit now, while it is a matter of writing down a plan and rehearsing it, costs far less than building it for the first time under the pressure of an actual deadline.

The First Few Minutes Decide the Rest

The scenario at the center of this article, an employee clicking a link, entering credentials, or approving a request they should not have, is not a hypothetical. It happens across some share of businesses every week, and no amount of training brings that share to zero. What separates a contained incident from a costly breach is not whether the click happened. It is whether the organization already knew who to tell, what to do, and how to move before an attacker’s own clock ran out first.

Treating incident response as a plan to write once things settle down carries a real cost in the meantime, measured in the widening gap between how fast attackers act and how slowly most businesses currently notice and respond. Closing that gap now, while it is still a matter of writing a plan and rehearsing it rather than living through the consequences of not having one, is the more strategic choice available today.

Most SMBs do not have the internal bandwidth to build a plan like this, test it, and keep it current alongside running the rest of the business. A technology partner that already does this work can help design the reporting path, put the right access and visibility in IT’s hands before it is needed, and make sure the plan has actually been rehearsed rather than simply written down.

Cybersecurity: Builds the monitoring and access controls that let your team spot and contain a compromise before it spreads. 

Managed IT Services: Gives your business a team already positioned to investigate and respond the moment an incident is reported. 

IT Consulting & Strategy: Turns incident response from an assumption into a documented, rehearsed plan built for your organization.

👉 If your organization is ready to know exactly what happens in the minutes after an employee clicks, our team is ready to help you take the next step.