When a Cyberattack Forces a Shutdown, Can Your Business Keep Running?
The Vanderbilt University incident raises a question every business leader should be able to answer before the next emergency.
Most conversations about cybersecurity start with prevention. How do we keep attackers out? Are our firewalls configured correctly? Do we have good endpoint protection? Are employees recognizing suspicious emails?
Those are worthwhile questions. But there’s another one that tends to get less attention: What happens to the business when the security team needs to shut something down?
On November 9, 2026, Vanderbilt University instructed students, faculty, and staff to turn off university devices and disconnect from campus Wi-Fi while it investigated a cybersecurity incident. Some services returned quickly, but the university warned that restoring normal operations across its systems could take weeks. By November 11, it was prioritizing functions such as payroll, payment services, admissions, course registration, and public safety.
I covered the incident and the ransomware group’s claims in this week’s episode of The SOC Brief. What interests me here is the business decision hiding inside the technical response: How do you protect an organization without bringing the organization to a standstill?
The Cost of Containing an Attack
In security operations, containment means limiting a threat’s ability to cause more damage. That might involve isolating a laptop, disabling an account, blocking access to an application, or disconnecting part of a network.
None of those actions are free from consequences. Disconnect the wrong system at the wrong time and you may interrupt production, customer service, or critical administrative work. Wait too long, though, and the attacker may reach systems that were previously unaffected.
This is why incident response cannot be treated as an IT-only problem. A security team can explain the risk of leaving a system online. Someone from operations needs to explain what happens if that system goes offline. Leadership has to understand both.
The answer won’t always be “shut everything down.” Sometimes isolating individual devices is the better option, and sometimes preserving a running system helps investigators collect evidence. The point is to have a process for making the decision quickly, with the right people involved.
Know What Actually Keeps the Business Running
If every department says its systems are mission-critical, your recovery plan isn’t going to be very useful.
A business impact analysis helps sort that out. It identifies essential processes, the technology and people they rely on, and how long each process can be unavailable before the damage becomes serious.
Take a manufacturing company. Losing access to email is inconvenient, but the production floor may still operate. Losing access to the system that schedules equipment or controls inventory could stop shipments entirely. For a professional services firm, the priorities might be client records, project files, and billing. A healthcare provider would have a very different list.
It’s also important to look at dependencies. A billing application might be available, but can employees use it if the identity system that handles logins is offline? Can a team restore a server if the backup administrator’s account has been locked out? Can customer support answer questions without access to its ticketing platform?
These are questions to work through with department leaders, not guesses the IT team should have to make during an emergency.
The result should be a short, agreed-upon list of the functions your organization must protect and restore first.
Decide Who Can Make the Hard Calls
Imagine a SOC analyst identifies suspicious activity on several systems. The incident-response team recommends immediately disconnecting a business application that hundreds of employees rely on.
Who approves that decision?
If the answer involves finding three executives, scheduling a meeting, and waiting for someone to come back from lunch, you’ve already lost valuable time.
Organizations need clear containment authority. Define which actions the security team can take immediately, which require approval, and who serves as the backup decision-maker when the usual contact isn’t available.
That authority should come with agreed-upon escalation rules. For example, an endpoint showing active malicious behavior may be isolated automatically, while taking an entire business unit offline requires a designated leader’s approval.
Not every incident will fit neatly into a procedure. But a plan that establishes responsibilities before an emergency is much better than a debate over responsibilities during one.
Plan for a Day Without Your Usual Tools
Here’s an uncomfortable exercise: Pretend your company email, Teams, VPN, and employee laptops are unavailable tomorrow morning.
How does management contact employees? How do employees report suspicious behavior? How does the response team share instructions without using potentially compromised accounts?
These are out-of-band communication problems. In plain English, you need a way to reach people that doesn’t depend on the systems you’re investigating.
That might be an emergency text service, a verified phone list, or a separate communications platform. Whatever you choose, keep contact information current and make sure employees know which instructions are legitimate. During a real incident, confusion creates opportunities for both mistakes and phishing.
The same principle applies to everyday work. If customer service normally relies on a cloud ticketing system, is there an approved temporary way to track urgent requests? If payroll is unavailable near payday, who makes the call on the next steps? Which tasks can pause, and which cannot?
A manual workaround doesn’t have to be elegant. It does have to be usable, documented, and secure enough that employees aren’t forced to improvise with personal email accounts or unapproved file-sharing tools.
Recovery Is More Than Switching Things Back On
Once the immediate threat appears contained, pressure builds to restore service. I understand that. Every hour offline can mean missed deadlines, unhappy customers, and real financial losses.
But restoring too quickly can create another round of problems.
Suppose an attacker gained access through a compromised employee account. You could clean a laptop and restore its files, but if those credentials are still valid, you may be opening the door again. Or you might restore a server only to find that the backup contains the same vulnerability that allowed the intrusion in the first place.
A sound recovery process checks that affected systems can be trusted, compromised access has been addressed, and the organization can monitor for renewed suspicious activity. It also prioritizes restoration based on business need, not simply which system is easiest to bring online.
That can be frustrating when everyone wants things back to normal. It’s still better than recovering twice.
Test Your Plan Before Someone Else Tests It for You
One of the most useful things a business can do is run a tabletop exercise. You don’t need an elaborate simulation or a room full of cybersecurity specialists. Bring together security, IT, a few department leaders, and whoever would make the big operational decisions.
Start with a simple scenario: Your team has discovered activity consistent with ransomware. Several systems need to be isolated, and the initial estimate for recovery is three days.
Then ask:
Don’t stop at the first set of answers. Assume the primary decision-maker is unavailable, or the backup system can’t be reached, or the outage lasts longer than expected. See where the plan starts to break.
The goal isn’t to prove your team can recite a policy. It’s to find the assumptions that don’t survive contact with a realistic incident. I’d much rather discover a missing phone list or an unclear approval process during a tabletop exercise than at 7:30 on a Monday morning.
A Question Worth Asking This Week
Vanderbilt’s incident is still being investigated, and the full technical story may take time to emerge. But its operational challenge is already familiar: contain the threat, keep essential services functioning where possible, and restore the rest carefully.
That challenge isn’t limited to universities or large enterprises. A small business can feel the loss of one critical system just as sharply as a large institution feels the loss of many.
You don’t need to know every technical detail of a ransomware attack to prepare for one. You do need to know what your business depends on, who makes decisions under pressure, and whether your team can carry them out.
If you’re not confident in those answers, start with a conversation between leadership and your IT or security team. And if you’d like a second set of eyes, our team can help evaluate your readiness and identify gaps before they become expensive surprises.
If your security team had to take critical systems offline tomorrow, would your business know what happens next?
For a closer look at the Vanderbilt incident, the BYOD ransomware claims, and the technical response, listen to this week’s episode of The SOC Brief: “Shut It Down — Inside the Vanderbilt Cyberattack.“
Incident details reflect publicly available reporting as of November 12, 2026. See Vanderbilt University’s official incident updates.
An IT controls audit can put people in an uncomfortable position. Someone is asking how they do their job, requesting evidence, and evaluating whether the processes they manage are working. ...
