An IT emergency is anything where the business can’t operate and every hour of delay costs money or makes recovery harder. A jammed printer is not that. A server that won’t boot, ransomware on a workstation, all email down, or a point-of-sale system offline during business hours — those are.
The distinction matters because treating everything as an emergency burns out whoever you call and drains your budget, while treating a real emergency as a routine ticket is how a contained incident becomes a company-wide one. Ransomware in particular gets dramatically worse in the first hour — encryption spreads across network shares while you’re deciding who to call.
Here’s what qualifies, what to do in the first fifteen minutes of each type, and what to have ready before you’re standing there with your heart rate up trying to remember the firewall password.
What counts and what doesn’t
Two tests. Does it stop the business from operating, right now? And does waiting make it worse? A yes to either means call immediately.
Call right now
- Ransom note on screen, files renamed with an unfamiliar extension, or files suddenly unopenable across a shared drive
- Server or NAS down, or the whole office locked out of shared files
- Email completely down for everyone
- POS or payment processing offline while you’re open
- Total internet outage with no backup connection
- Confirmed or strongly suspected account compromise, especially an admin or finance account
- A wire or payment initiated based on an email you now think was fraudulent
- Physical damage — water on equipment, a fire, a lightning strike
- Any indication customer data has been exposed
Urgent, but tomorrow morning is fine
- One person’s laptop won’t boot and they have another machine to use
- Email delayed or slow but flowing
- The shared printer is offline
- One user locked out of one application
- Wi-Fi weak in one corner of the office
- A machine running slowly
- A failed backup job, one night, on a system with recent good backups
One caveat on that last list: repeated backup failures over several nights are an emergency, because you’re accumulating unprotected days without knowing it. Three consecutive failures should escalate.
The first fifteen minutes
Suspected ransomware
Speed matters more here than anywhere else. Every minute the machine stays on the network, encryption reaches further into your shared drives.
Disconnect it from the network immediately. Pull the Ethernet cable. If it’s on Wi-Fi, turn Wi-Fi off at the machine — or if you can’t get to it fast, power down the access point covering that area. Physical disconnection is the priority and it takes two seconds.
Do not power the machine off. This is counterintuitive and it’s the mistake almost everyone makes. Encryption keys, running process details, and network connection state live in RAM, and shutting down destroys all of it. Sometimes that memory contains the key. Even when it doesn’t, it’s the evidence that tells an incident responder — and your insurer — what happened. Leave it running, disconnected.
Then check the spread. Look at your file server and any other workstation. If shared files elsewhere are also encrypted, disconnect those machines too. If you have a NAS with snapshots, disconnect it before anything else can reach it.
Photograph the ransom note with your phone. It identifies the variant, and some variants have published decryptors.
Call your IT provider, then your cyber insurance carrier. Most policies require notification within a specified window and many require you to use their approved incident response firm. Calling your own contractor first can jeopardize coverage. The carrier’s hotline number should be somewhere you can find it without email access.
Don’t pay anything, and don’t reply to the attackers. Not yet, maybe not ever — that’s a decision to make with your insurer and counsel, and payment triggers legal and sanctions considerations you don’t want to navigate alone at 9 p.m.
Also don’t:
Delete the encrypted files. Run a cleanup tool that wipes traces. Restore from backup before someone confirms the attacker’s access is closed — restoring into a compromised network just gives them a fresh set of files to encrypt. And do not connect a USB backup drive to an infected machine to “grab what’s left.”
All email is down
Check whether it’s you or the provider before doing anything else. Microsoft 365: status.office.com, or the Service Health section of the admin center. Google Workspace: google.com/appsstatus. Check from a phone on cellular data, not office Wi-Fi — if your internet is down, everything will look broken from inside.
If the status page shows an incident, there’s nothing to fix. Tell staff, note the incident ID, and move people to phone and text. Resist the urge to “try things” during a provider outage — that’s how you end up with a broken configuration after service is restored.
If the status page is green, it’s local. Likely causes, in order: your internet connection is down, a domain or DNS problem, an expired subscription, or a compromised tenant with a malicious mail flow rule.
Quick test: can you sign into outlook.office.com from a phone on cellular? If yes, mail is fine and the problem is at your office. If no, it’s the tenant.
Server or NAS failure
Look at the physical device before touching anything. Note the pattern of the status lights, listen for clicking or grinding from the drives, and check whether it’s powered at all.
If you hear repeated clicking, stop. That’s mechanical drive failure, and every additional minute of spinning can make professional recovery harder or impossible. Power it down and call.
Do not pull drives out of a RAID array to “check” them — removing the wrong drive from a degraded array destroys the whole set. Do not accept any prompt to rebuild, initialize, or format. And don’t reboot it repeatedly hoping it’ll come back; each boot cycle is another chance for a dying drive to fail completely.
What you should do: confirm when the last successful backup ran and where it lives. That single fact determines whether this is a bad day or a catastrophe, and it’s the first question anyone you call will ask.
Data deleted or lost
Stop writing to the drive. If a file was deleted from a local disk, the data is usually still physically present until something overwrites it — and continuing to use that computer is what overwrites it. Shut down or at minimum stop saving anything to that drive.
Check the easy places first, because it’s often not really gone. OneDrive and SharePoint keep a recycle bin for 93 days plus a second-stage bin. Google Drive keeps trash for 30 days. Windows File History or Previous Versions may have it. Microsoft 365 and Google Workspace both retain deleted mailboxes and user accounts for 30 days, so a deleted employee’s data usually isn’t gone.
If it’s genuinely gone from every layer and it’s business-critical, don’t run recovery software on the original drive. Have someone image the drive first, then attempt recovery from the image.
Account compromise
Order matters here, and most people get it wrong by only changing the password.
Change the password first. Then revoke active sessions — this is the step people skip, and skipping it means the attacker’s existing session token keeps working after the password change. In Microsoft 365: Admin center > Users > Active users, select the user, then Sign out of all sessions. In Google Workspace: Admin console > Users, select the user, then Security, then Sign out user.
Next, check the mailbox rules. Attackers who compromise a business email account almost always create a forwarding rule or a rule that moves incoming mail from your bank or accounting department to an obscure folder, so their activity stays invisible. Look under mail rules and under forwarding settings, and check both — they’re separate places. Also check whether the mailbox has any new delegate access.
Then check whether MFA methods were changed or an app password was created, look at sign-in logs for unfamiliar locations, and enable MFA if it wasn’t already on. Finally, tell your staff and any customers this account has been emailing — compromised accounts are used to send convincing invoice fraud to your contacts, and they’ll trust the address.
If the account had access to payment systems, call your bank before you finish the technical cleanup.
Triage table
| Incident | Severity | First action | Who to call |
|---|---|---|---|
| Ransomware / ransom note | Critical | Unplug from network. Leave powered on. | IT provider, then cyber insurer |
| Server / NAS won’t boot | Critical | Note lights and sounds. Don’t pull drives or rebuild. | IT provider |
| All email down | Critical | Check provider status page from cellular data | IT provider if status is green |
| POS / payments offline while open | Critical | Switch to backup payment method; check internet | POS vendor and IT provider |
| Suspected account takeover | Critical | Change password, revoke all sessions, check forwarding rules | IT provider; bank if finance access |
| Fraudulent wire already sent | Critical | Call bank to request recall; file with IC3.gov | Bank first, then IT provider |
| Internet down, whole office | High | Power cycle modem; check ISP outage map; hotspot as stopgap | ISP, then IT provider |
| Critical file deleted, no copy | High | Stop using that drive; check cloud recycle bins | IT provider |
| Backups failed 3+ nights running | High | Identify last known good restore point | IT provider, same day |
| One laptop dead, user has an alternative | Normal | Move them to a spare machine | Normal ticket |
| Printer offline | Normal | Power cycle it; print to another device | Normal ticket |
What SLA tiers actually promise
The most common misunderstanding in service agreements: response time is not resolution time. A one-hour response SLA means someone acknowledges your ticket and starts working within an hour. It says nothing about when your server comes back.
Almost no provider will commit to a resolution time, and one who does is either padding heavily or about to disappoint you. Hardware failures depend on parts availability; ransomware recovery depends on how far it spread. What you should look for instead is a commitment to continuous work on critical incidents — someone stays on it until it’s resolved rather than working it into the normal queue.
Typical tiers for small business plans:
- Critical — business stopped. Response in 15-60 minutes, 24/7, continuous work until resolved.
- High — significant impairment or multiple users affected. Response within 2-4 business hours.
- Normal — single user, workaround exists. Same or next business day.
- Low — requests, questions, new user setup. 2-3 business days.
Two things to check in the actual document. First, who decides the severity — if the provider unilaterally classifies your outage as “high” rather than “critical,” their fast SLA never applies. You want either mutual agreement or objective criteria. Second, what “24/7” covers — for many providers it means critical incidents only, with routine tickets still queued for business hours. That’s reasonable, but you should know it before 8 p.m. on a Saturday.
Why emergency support costs what it costs
With a break-fix provider, an after-hours emergency is billed at a premium — commonly 1.5x to 2x the standard rate, sometimes with a two- or four-hour minimum. At a $150 base rate, a Saturday incident starts at $300 an hour with a four-hour minimum, so $1,200 before anyone has diagnosed anything.
That’s not gouging. Someone is leaving their family on a weekend, and a firm that doesn’t price it accordingly won’t have anyone willing to answer. But it produces a genuinely bad dynamic: the moment you most need help is the moment you’re most reluctant to call. Businesses regularly wait until Monday on something that should have been handled Friday night, and the delay makes the recovery longer and more expensive than the after-hours fee would have been.
A flat-rate managed plan removes the decision. Emergency response is inside the monthly fee, so nobody’s doing cost-benefit math while the server is down. The provider is also monitoring your systems continuously, which means a fair share of these incidents get caught before they become incidents — a failing drive flagged by SMART data, a backup job that’s been quietly failing, disk space about to run out.
If you’re on break-fix, at least know your provider’s after-hours rate, minimum, and phone number now. Finding out during an emergency is the worst possible time.
Have this ready before you need it
Emergency calls go dramatically faster when this information exists. Keep it printed and in a fireproof box or safe — not only in a document on the file server that’s currently down, and not only in an email account you may be locked out of.
- Network basics. ISP name, account number, support number, circuit ID. Router and firewall make, model, and where they physically are. Which switch and access point is where.
- Credential locations. Not the passwords themselves on paper — where they live. Which password manager, who holds the master, who the emergency access account belongs to. Router admin, server admin, M365 Global Admin, domain registrar.
- Backup details. What’s backed up, where it goes, how often, when the last successful run was, when a restore was last tested. That last one is the question people can’t answer, and it’s the one that matters.
- Vendor contacts. IT provider (with the after-hours number, which is often different). Cyber insurance carrier and policy number, with their incident hotline. POS vendor. Accounting software support. Your bank’s fraud line. Line-of-business application vendor.
- Systems inventory. A simple list — server names and roles, how many workstations, what critical applications you run, what depends on what. One page is enough.
- An out-of-band contact list. Personal cell numbers for key staff. If email and chat are down, you need another way to reach people.
- A written decision on who can authorize spending during an emergency, and up to what amount. This one saves real hours.
Building this takes an afternoon. Review it every six months, because ISPs change, staff turn over, and the person who set up the firewall leaves.
Common questions
Should I shut down a computer that has ransomware on it?
No. Disconnect it from the network — pull the cable, disable Wi-Fi — but leave it powered on. Encryption keys and process details sometimes live in RAM and are destroyed at shutdown, along with the forensic evidence your insurer and any responder will need. The exception is an active, ongoing encryption process where disconnecting isn’t possible; in that narrow case limiting further damage wins. Otherwise: disconnect, leave running, call.
How fast should an IT provider answer a real emergency?
For a business-stopping incident, expect an initial response within 15 to 60 minutes, at any hour, on a plan that includes 24/7 critical coverage. Anything beyond two hours for a critical outage means the coverage isn’t really there regardless of what the marketing says. Check whether the SLA measures from when you call or from when a ticket is created — those can differ meaningfully if the after-hours number routes to voicemail.
Do we need 24/7 IT support?
Depends on when you operate and what an hour of downtime costs. A professional services firm working 8 to 6 weekdays can reasonably live with business-hours support plus emergency-only after-hours coverage. A restaurant, retailer, or medical practice with weekend and evening operations needs real 24/7. The useful test: if your systems went down at 7 p.m. on a Friday, would you lose money before Monday morning? If yes, buy the coverage.
What does emergency IT support typically cost?
On break-fix, after-hours emergency work generally runs $200-350 per hour, frequently with a two- to four-hour minimum, so a single weekend incident commonly lands between $800 and $2,500 before parts. Major incidents involving data recovery or ransomware response go well past that — data recovery from a failed drive alone runs $700-3,000, and professional incident response for a ransomware event routinely reaches five figures. On a flat-rate managed plan, emergency response is inside the monthly fee, though specialist forensics and recovery services are typically still separate.
Who do we call first — the IT provider or the insurance company?
For a suspected breach or ransomware, call both quickly, and read your policy now so you know the order it requires. Many cyber policies mandate notification within a set window and require you to use their panel of approved incident responders — if you hire your own firm first, that spend may not be covered. The practical sequence for most small businesses: contain it physically, call your IT provider to help assess, and call the carrier’s hotline within the first hour. For a non-security emergency like a hardware failure, insurance isn’t involved and the IT provider is the only call.
