At 7:42 a.m., an office manager at a 30-person accounting firm opens her email to find a message from IT support she doesn’t recognize, sent from an account that looks almost right. By 9:15, half the shared drive is encrypted and a ransom note has replaced the firm’s client intake spreadsheet. Nobody in the building knows who is supposed to make the first call, what systems can be safely disconnected, or whether the backups actually work. That gap, the sixty minutes between discovery and organized response, is where most of the damage in a cyber incident actually gets decided.
This is not a hypothetical reserved for large enterprises. It is the daily reality for small and mid-sized organizations across every industry, and it is why an incident response plan is no longer optional infrastructure. This piece walks through what actually needs to happen in the first hour after an incident is discovered, and why having that sequence written down in advance changes the outcome more than almost any single security tool.
The Clock Doesn’t Start When You Think It Does
Most conversations about incident response focus on the moment a business realizes something is wrong. But that moment rarely lines up with when the actual compromise began. According to IBM’s 2025 Cost of a Data Breach Report, organizations took a mean of 241 days to identify and contain a breach in 2025, the shortest window in nine years of tracking, but still nearly eight months of an attacker having some level of access before the incident was fully resolved.
That dwell time matters because it reframes what “the first sixty minutes” really means. It is not the first sixty minutes of the attack. It is the first sixty minutes after detection, when an organization has its best and often only chance to limit how much worse the situation gets. IBM’s research also found that breaches contained within 200 days cost organizations $1.14 million less on average than those that dragged on longer. Speed of response, not just speed of detection, is what separates a contained incident from a catastrophic one.
Small and Mid-Sized Organizations Are Absorbing the Worst of It
There is a persistent assumption among smaller businesses that they are not attractive enough targets to justify a formal response plan. The data does not support that assumption. Verizon’s 2025 Data Breach Investigations Report found that ransomware was present in 88 percent of breaches involving small and mid-sized businesses, compared with 39 percent of breaches at larger enterprises. Attackers are not choosing SMBs because the payout is bigger. They are choosing them because the defenses, and the response plans, are thinner.
That gap shows up most clearly in the first hour after discovery. Larger organizations often have a security operations team and a documented escalation path. Smaller organizations frequently have neither, which means the first sixty minutes are spent figuring out who is in charge rather than executing a plan.
What Should Actually Happen in the First Sixty Minutes
An incident response plan is only useful if it tells people exactly what to do without requiring them to think it through in real time, while adrenaline and uncertainty are both working against clear judgment. The following sequence reflects the core actions that should occur, in roughly this order, once a potential incident is confirmed.
- Identify and designate an incident lead. One person, named in the plan ahead of time, makes the call on next steps. This prevents the common failure mode of five people independently deciding what to unplug.
- Isolate, don’t shut down, affected systems. Disconnecting a compromised machine from the network preserves evidence that forensic investigators and cyber insurance carriers will need later. Powering it off can destroy that evidence.
- Activate the communication tree. The plan should list who gets notified first: IT or the managed service provider, leadership, legal counsel, and cyber insurance carrier, in that order, with phone numbers that don’t depend on the compromised email system to deliver them.
- Do not attempt to negotiate or communicate with an attacker directly. That role belongs to legal counsel or a professional incident response firm, not to whoever found the ransom note.
- Begin a written timeline. Who found the issue, what time, what systems appear affected, what actions have been taken. This record becomes essential for insurance claims, regulatory notification, and any later legal review.
- Verify backup integrity before assuming recovery is possible. An organization that discovers its backups were also encrypted, or hadn’t run successfully in weeks, is in a far worse position than one that confirms clean, isolated backups exist.
- Determine notification obligations. Depending on the industry and the data involved, there may be legal requirements to notify clients, patients, or regulators within a specific window. This is where legal counsel and a documented compliance framework matter most.
None of these steps require advanced technical expertise to execute. They require a plan that was written before the incident happened, and a team that has actually seen it.
A Plan That Lives in a Binder Is Not a Plan
Many organizations do have some version of an incident response plan, often created for a compliance audit or an insurance application, and then never looked at again. A plan nobody has practiced tends to fail in the same predictable ways: the contact list is outdated, nobody remembers where it’s stored, and the person named as incident lead has since left the company.
A functional incident response plan is a living document that gets tested. Tabletop exercises, structured walkthroughs where the team talks through a simulated incident step by step, surface these gaps before a real event does. IBM’s 2025 report specifically points to regular incident response testing as one of the more effective cost mitigators available to organizations of any size, because it converts a written procedure into muscle memory.
For associations and their member organizations, this is a practical starting point that doesn’t require a large budget. A plan can begin as a single page: who is the incident lead, who gets called first, where are the backups, and who verifies them. That page, reviewed twice a year, does more to limit damage in the first hour than most standalone security tools.
The First Hour Is a Preparedness Problem, Not a Technology Problem
It’s worth being direct about what actually determines whether an incident becomes a controlled event or a business-ending one: preparation done in advance, not tools purchased after the fact. Firewalls, endpoint detection, and email filtering all reduce the odds of an incident occurring. But once one does occur, the outcome is shaped almost entirely by whether the organization already knows what to do in the first sixty minutes.
Organizations that haven’t reviewed their incident response plan recently, or don’t have one at all, don’t need to wait for an audit deadline to fix that. EasyIT, a Columbus-based managed IT and cybersecurity provider, works with businesses across healthcare, legal, manufacturing, and professional services to build and stress-test incident response plans as part of a broader security posture. For organizations unsure where their current plan, or lack of one, actually stands, a complimentary readiness assessment is a reasonable place to start.
