People ask us for war stories. We are careful with them, because a story with a company name, a dollar figure, and a date attached is usually one of two things: a breach of somebody’s trust, or marketing fiction. Neither is worth your time.
So here are two composites instead. Neither is a specific client. Each is a pattern we see over and over, assembled from the shape these events take rather than from any single company’s bad week. The details are generalized on purpose. The lesson underneath is not, and it comes down to one habit almost nobody thinks of as a security control.
Why These Are Patterns and Not Case Studies
Worth saying plainly: everything below is a composite. No client is being described. No figures, names, or dates are real, because we did not invent any.
Here is some contrarian advice for reading any IT company’s blog. When you see a line like “a local manufacturer lost a specific sum on a Tuesday in a specific month,” ask how they got permission to publish that. Businesses that go through a serious incident rarely want it described in a vendor’s marketing, and the ones who sign off usually approve something vaguer than what gets printed. The specificity is often the tell that the story is invented. We would rather be useful than dramatic, so we will be general about circumstances and concrete about the lesson.
The Pattern Where Recovery Goes Fine
Picture a professional services firm of roughly thirty people. Nothing exotic in the server room, a modest budget, the same software everybody else uses. In this pattern, here is what was in place before anything happened.
- Two kinds of copies. A local one for speed and a cloud one that could not be altered, so a stolen password could not erase the history.
- Retention measured in months, not days. Daily copies for a couple of weeks, weekly copies going back considerably further.
- One page of instructions. Which systems come back in what order, who to call, where the credentials live. Not a binder. One page.
- Somebody who had done it before. A person on staff had personally restored a real system in a test and remembered how it went.
The recovery day in this pattern is boring, which is the point. Someone notices in the morning. Machines get disconnected within the hour, because the runbook says to do that first and nobody has to debate it. A restore point is chosen from well before the earliest sign of trouble rather than from last night. The systems people actually need come back first, in a decided order, and by the next business day most of the company is working. A long tail of smaller things gets sorted over the following week.
Nothing heroic happened. Nobody learned a new tool under pressure. The decisions were already made on a calm afternoon months earlier, which is why the day felt like work instead of panic.
The Pattern Where It Does Not
Now picture a similar business. Same size, comparable budget, arguably nicer equipment. This is not a story about careless people. This pattern is what a completely reasonable company looks like when nobody ever asked the second question.
- A backup that ran every night and reported success. Green emails, filed automatically, unread for a long time.
- Retention at the software default. About a week, because nobody changed it and nobody knew it was a decision.
- A backup reachable from the network it protected. Convenient, fast, visible to anything with administrator rights.
- One person who handled backups. Not documented anywhere, and never actually asked to restore anything.
The recovery day goes sideways in stages, each small on its own. The local backup is gone with everything else. There is an older cloud copy, but nobody has ever restored from that console, so the first hours go to reading documentation. The credentials for it are stored in a file on a server that is currently encrypted. When a copy finally comes back, it is from inside the window when the intruder was already present, so the work has to be redone from further back.
What turns a bad day into a bad fortnight is rarely one catastrophic failure. It is four small unknowns discovered in sequence, each costing hours, while people who need to be working stand around waiting.
The Single Habit That Separated Them
It was not budget. It was not the brand of backup software, the company size, or whether they had a security consultant on retainer.
In the pattern that goes well, someone had actually performed a test restore and knew the steps. That is the whole difference. A test restore is not a formality. It converts assumptions into known facts on a day when being wrong costs nothing.
The standards bodies say the same thing without the storytelling. In its 2010 publication NIST SP 800-34 Revision 1, the National Institute of Standards and Technology notes that testing validates recovery capabilities, whereas exercising the plan identifies planning gaps. In its 2022 publication NIST IR 8374, NIST is blunter: back up data, secure backups, and test restoration, and make an incident recovery plan that you develop, implement, and regularly exercise with defined roles and strategies for decision making.
A single test restore typically surfaces three or four surprises. A system that was never in the backup job. An expired license key. A restore far slower than anyone guessed. A password nobody can find. Each is cheap to fix on a quiet Thursday and expensive to discover during an outage. It is also the clearest thing to ask about when you are evaluating an IT partner: when did you last restore something for a client, and how long did it take.
What to Go Check Tomorrow
None of this needs a project or a budget line. It needs about an hour and a willingness to hear an uncomfortable answer.
- Ask who has personally restored something in the past year. You want a name, not a job title. A shrug is your gap.
- Find your retention number in days. CISA advises small businesses to ensure they can roll back data at least seven days if needed. If yours is exactly seven, treat that as a floor you have not raised yet.
- Ask whether any copy is beyond an attacker’s reach. If every copy can be deleted by whoever holds the admin password, you have one copy in several places.
- Find out where the backup credentials live. If the answer is a document on a server, move it today. That takes ten minutes.
- Write the one page. Order of systems, who to call, where the keys are. It does not need to be good. It needs to exist.
- Put a test restore on the calendar with a real date. Ninety minutes, one meaningful system, restored somewhere isolated. CISA recommends testing that your team can restore data both fully and partially.
The Bottom Line
These two patterns are not separated by money or sophistication. They are separated by whether one person had ever practiced. That is uncomfortable to hear if you have been spending on tools, and genuinely hopeful if you have not, because practice is the cheapest item on the menu.
It is also not a rare scenario worth ignoring. Citing Verizon’s 2025 Data Breach Investigations Report, CISA notes that ransomware figured into 44% of the breaches investigated. Recovery is a normal business capability now, more like knowing where the fire exits are than insuring against a meteor. And if your plan depends on one provider staying online, it is worth understanding what happens when the cloud has a bad day.
If you cannot name the last person who restored something at your company, we would be glad to run one honest test with you and tell you what we find, good or bad. No scare tactics and no invented horror stories, just a real number and a short list of what would improve it. We work with small and mid-sized businesses across Denton County. Contact us today.
Sources:
Comments are closed