Building a Recovery Program With a Team of Five
How to build a cyber recovery program with five people: shared RTO and RPO, clear roles, immutable backups, decision-tree runbooks and board metrics.
Loading...
How to build a cyber recovery program with five people: shared RTO and RPO, clear roles, immutable backups, decision-tree runbooks and board metrics.
What AI-driven security solutions really do: alert triage, behavior-based detection, risk ranking and automated response, and how to test the AI claims.
If you run security with five people, your recovery program starts with one agreement with the business: what "recovered" means, written down as a recovery time objective and a recovery point objective. Once you have that, you give each person a recovery role and a backup role, keep one immutable backup copy that ransomware can't reach, write your runbooks as decision trees and test them every quarter. What the board gets from all of this is one tested number.
A lot of security leaders work with a team this size, a tight budget and a board that wants to hear you can survive a ransomware hit without paying. The NIST Cybersecurity Framework's Recover function and NIST SP 800-61 are good foundations, but they were written as if you had people for every role they describe. With five people, you end up being the incident commander, the communications lead and the post-incident reviewer, sometimes on the same day.
So I want to walk through a program that fits that size. It should still hold up the day a storage admin deletes a production database by accident, it should get you back faster than the business loses money, and it should give your board a number they understand.
See every Backup and Recovery solution we list
The full Backup and Recovery market, filtered by company size, deployment and NIST coverage.
What I see most teams do is buy a backup product, write a runbook and call it a recovery program. Then an incident happens and nobody agrees on what "recovered" means. Is it when the systems are back online, when someone has confirmed the data is intact, or when the business says it is back to normal?
That definition has to come from the business owners. Recovery means the business can run at an acceptable level within an agreed time window, and only the people who run those units can tell you what acceptable is.
So get the two numbers, RTO and RPO, in writing from the business unit owners rather than from IT. A 4-hour RTO for your ERP system means something very different to the CFO than to the sysadmin who has to deliver it, and you want both of them looking at the same number before you spend a dollar on products.
During an incident the org chart stops mattering. What matters is who picks up which job when the phone rings at 2 a.m., so each person gets a primary function and a backup function. A mapping that works for five people looks like this:
Each person also needs to know their backup role. If your Technical Lead can't be reached, somebody else runs recovery, and that name should be written down and tested in an exercise before you need it.
Most backup setups were built for convenience, and recovery speed came second. Nightly full backups to a NAS on the same network segment as production is a common example, and ransomware that reaches production will usually reach that NAS too.
With a small team, you want a backup design that takes the thinking out of the incident. That means immutable backups, offsite or cloud-isolated copies, and restores that anyone on the team can run without tribal knowledge.
The 3-2-1-1 rule is a practical starting point: three copies of your data, on two different media types, one offsite and one air-gapped or immutable. That last copy is the one ransomware can't touch, so if you don't have it yet, it's your first budget ask.
Veeam, Cohesity and Rubrik all offer immutable backups, and you can compare more vendors in backup as a service. For a small team, the feature list matters less than how fast your least experienced person can restore from a clean copy without calling the vendor. Ask every vendor to show you that in the demo.
A runbook that just says "restore from backup" is a placeholder. A useful one answers the questions your team will ask during the incident: which backup, from what point in time, how do you check integrity before you reconnect to the network, and who approves the reconnection?
So write runbooks as decision trees. Each step gets a clear action, a success condition and a branch for what to do when that condition isn't met. If a step needs judgment, name the person who makes the call.
For a five-person team, cover at least these scenarios:
Keep the runbooks somewhere you can reach when your main systems are down. A SharePoint folder behind SSO is gone during an identity compromise, so print them and also store them in a cloud tenant that is isolated from production.
Compare Backup and Recovery solutions side by side
Features, integrations, NIST coverage and deployment for every Backup and Recovery solution we list, in one table.
Most tabletop exercise guidance assumes a dedicated incident response team, lawyers in the room and a communications function that isn't also your security analyst. With five people, the exercise is smaller and faster, and it should focus on the quality of decisions rather than on following process.
Run one every quarter and test a different failure mode each time, rotating through your runbook scenarios instead of running the same ransomware story four times a year. You are not trying to pass the exercise. You are trying to find the gaps before an attacker does.
Bring one business stakeholder to each tabletop, and over a year rotate through the CFO, the General Counsel and a business unit head. It forces your team to speak in business terms, and it shows the people who sponsor you at board level what recovery really takes. That first-hand view does more for you than any board presentation.
Track one metric from each tabletop: how long the team takes to decide at a critical branch point. If it takes 45 minutes to decide between paying a ransom and restoring from backup, that's a gap. I'd aim to get that decision under 15 minutes with pre-approved authority and written decision criteria.
Boards want to know two things about recovery: can you survive an attack, and how long will it take. They don't want to hear about backup architecture or NIST alignment. They want a number and how confident you are in it.
A board-ready recovery line looks like this: "Based on our last tested restore, we can recover our five most critical systems within [X] hours of a ransomware event, losing no more than [Y] hours of data. We test this every quarter." That is the whole slide.
If you can't say that with confidence, don't fake it. Boards remember security leaders who overpromised and then struggled during an incident. Tell them where you are, what the gap is and what you need to close it, which is a far more credible conversation than a green dashboard that falls apart under questions.
A recovery program for a mid-market company (100 to 999 employees) with five security people doesn't need a seven-figure budget. It needs strict priorities and the discipline to say no to anything that doesn't shorten recovery time or the data loss window.
A lean program has five budget lines. Get a current quote for each one before you size the total:
The incident response retainer is the line most small teams skip, and I wouldn't. When ransomware hits on a Friday night and you are five people, you need a phone number that reaches a team that has done this before. It also shows your board that you've planned for the case where your own people are overwhelmed. You can compare providers in DFIR.
Recovery programs rarely fail because nobody built them. They fail because they were built once and never maintained: runbooks go stale, backup jobs fail without anyone noticing, the engineer who knew the restore procedure leaves, and someone shortens the immutable copy's retention to save storage costs.
So put the checks in the calendar instead of relying on good intentions. A monthly 30-minute review of backup job success, a runbook review after any infrastructure change and at least every quarter, and a full recovery test once a year are the minimum that keeps the program working.
Give each check a named owner. One person owns backup integrity and one owns runbook currency, because when everyone owns it, nobody does.
Check a vendor before you sign
Mandos tracks funding, acquisitions, hiring and news for security companies. Look up any vendor on your shortlist before the renewal.
A recovery program built by five people can work better than one built by fifty if it is designed for the people who actually have to run it. What makes the difference is clear roles, clear runbooks, clear metrics and a board conversation that needs no translator.
So start with your RTO and RPO commitments, map your five people to recovery functions, and build the checks that stop the program from decaying. It won't be perfect, and it doesn't need to be, as long as it works on the worst day your company has ever had.
Translate recovery into the cost of downtime. If your company loses $50,000 for every hour the ERP system is down, a 12-hour recovery gap is $600,000 of exposure. Frame the budget ask as the cost of cutting that exposure to 2 hours, because CFOs follow expected-loss math better than security frameworks.
Realistically, no. A major ransomware event will overwhelm five people within the first 24 hours, so budget for an incident response retainer with named-account support. Agree the scope of the engagement in advance so you aren't negotiating contract terms during an active incident. Your team handles the first hour and the retainer firm carries the days after.
Backup job success tells you data was written. It says nothing about whether you can restore it in the time the business needs. Run a full recovery test on your most critical system at least once a year and a partial restore test every quarter. Record how long it really took and compare it with your RTO, because the gap between the documented RTO and the tested time is your real exposure.
Three metrics cover most board conversations: tested recovery time for critical systems against the committed RTO, backup integrity rate over the last quarter, and the number of recovery scenarios tested in the last 12 months. Keep it to one slide. If the numbers are improving, say so, and if there is a gap, name it and say what you need to close it.
That's a runbook problem more than a staffing problem. Every critical recovery procedure should be written so your second most experienced person can run it without the first. Test it in a tabletop by taking your Technical Lead out of the scenario, and the gaps you find there are the ones that would hurt you in a real incident.
For five people, the answer is almost always a mix. Keep the strategy, the runbooks and the decision authority in-house, and buy the capacity you can't hold yourself, mainly incident response surge capacity and specialist forensics. Some managed detection and response providers bundle recovery support into their service tiers, so ask about it when you compare them.
Written by Nika (Nikoloz) Kokhreidze, from my own work running security programs and buying security products. Category and glossary links point to the CybersecTools catalog of 9,168 security products. Read the methodology for how we review products.