Building a Recover Program With a Team of 5

Most recovery programs get built by teams of 20 with a dedicated IR retainer, a tabletop budget, and a CISO who has the board's ear. You have five people, a shared on-call rotation, and a board that thinks "recovery" means restoring from backup. That gap between the textbook program and your actual situation is where most small security teams fail quietly.

The failure mode is not dramatic. It is slow. You patch the obvious gaps, you run one tabletop a year, you document a recovery plan that lives in a SharePoint folder nobody has opened since the last audit. Then an incident happens and you discover that your plan assumed resources you do not have, vendors who are not under contract, and a communication chain that breaks at the third link. The auditors loved your documentation. The incident exposed it.

Building a recovery program with five people is a forcing function. It makes you prioritize ruthlessly, automate aggressively, and accept that you cannot own every control. Done right, a lean team builds a more honest program than a bloated one, because you cannot afford ceremony. Every hour your team spends on a control has to produce measurable risk reduction. This article is about how to make those hours count.

Most teams skip this step. They jump straight to runbooks and retainers without agreeing on what recovery actually means for their organization. Recovery is not a technical state. It is a business state. Your board does not care that your SIEM is back online. They care that revenue-generating systems are processing transactions and that customer data is intact.

Start by mapping your critical business processes to their underlying systems. For each one, define two numbers: your Recovery Time Objective (RTO) and your Recovery Point Objective (RPO). These are not IT metrics. They are business commitments. Your CFO should sign off on them, because they determine how much you spend on backup infrastructure, replication, and failover capacity.

With five people, you cannot protect everything equally. Tiering your assets by business criticality is not optional. It is the only way to allocate a small team's time without burning everyone out on systems that do not matter.

The rule of thirds applies even at this scale. You need someone who can translate risk into business language for leadership. You need someone who can execute technical recovery procedures under pressure. And you need someone who can manage vendor relationships and external resources when your internal capacity runs out. One person can cover two of these, but no single person covers all three well.

The most common mistake in small teams is hiring five technical specialists. They are excellent at detection and response. They are terrible at explaining to a CFO why the recovery will take 72 hours instead of 4. That communication gap costs you budget, credibility, and sometimes your job.

Map your current five people against these three functions honestly. If you have a gap, fill it with a part-time contractor or a managed service before your next incident. Finding out you have no business translator during a live incident is the wrong time to discover the gap.

An IR retainer is not insurance. It is a pre-negotiated relationship with a firm that will answer the phone at 2 AM and show up with people who have done this before. The difference between a retainer and a break-glass engagement is 48 hours of response time and a team that already knows your environment.

For a five-person team, a retainer is not a luxury. It is a force multiplier. Your team handles the first 4 to 6 hours of triage. The retainer firm handles the forensic depth, the legal coordination, and the surge capacity you cannot staff internally. Budget $75K to $125K annually for a mid-tier firm with documented SLAs. That vendor's TCO calculator will not show you the cost of a 48-hour delay in containment. Your cyber insurance carrier will.

Negotiate hard on two things: guaranteed response time in writing, and pre-engagement scoping that includes your environment documentation. A retainer where the firm has never seen your architecture is worth significantly less than one where they have done a pre-engagement assessment.

Humans under stress skip steps. This is not a character flaw. It is how cognitive load works during an incident. Your recovery playbooks need to account for this by automating the steps that are easy to skip but catastrophic to miss: evidence preservation, stakeholder notification triggers, system isolation sequences, and backup integrity verification.

SOAR platforms are the obvious answer, but most are priced for teams three times your size. Look at lighter-weight options that integrate with your existing SIEM and ticketing system. The goal is not a full SOAR deployment. The goal is automating the first 30 minutes of your response so your team is not making decisions from memory at 3 AM.

Prioritize automation in this order: evidence preservation first, isolation second, notification third. If you preserve nothing else, preserve your logs. Everything else can be rebuilt. Forensic evidence cannot.

Your backup strategy is your recovery strategy. If your backups are on the same network segment as your production systems, your recovery plan has a single point of failure that ransomware will find before you do. Immutable, air-gapped backups are not a nice-to-have for a five-person team. They are the difference between a 4-hour recovery and a 4-week negotiation.

The 3-2-1-1 rule is the current baseline: three copies of data, on two different media types, with one offsite, and one offline or immutable. For most organizations running on cloud infrastructure, this translates to a combination of native cloud snapshots, a secondary cloud region, and an immutable object storage tier. The cost is typically $15K to $40K annually depending on data volume. The alternative cost is your ransom demand.

Test your backups on a schedule your team actually keeps. Quarterly restoration tests for Tier 1 systems. Semi-annual for Tier 2. A backup you have never restored is a hypothesis, not a control.

The annual tabletop exercise that satisfies your auditor is not the same as the tabletop exercise that improves your recovery capability. Most compliance-driven tabletops test whether your team knows the plan. The exercises that matter test whether the plan survives contact with reality.

Run two types of exercises. The first is a structured walkthrough for compliance and documentation purposes. Run it annually, invite your auditor, check the box. The second is an unannounced or semi-announced functional exercise where you actually execute recovery steps against a non-production environment. Run this twice a year. The gaps you find in the second type are the ones that would have cost you during a real incident.

With five people, your tabletop scenarios should focus on your most likely threat vectors, not your most dramatic ones. Ransomware hitting your backup infrastructure is more likely than a nation-state APT. Build your muscle memory around probability, not headlines.

Your board does not understand mean time to recover. They understand revenue at risk per hour of downtime. Convert your metrics before you walk into that room. If your e-commerce platform generates $200K per hour and your current RTO for that system is 8 hours, your board is looking at $1.6M in potential revenue exposure per incident. That number gets attention. MTTR does not.

Report three things to your board on a quarterly basis: your current RTO and RPO commitments versus your tested capability, the gap between the two, and what it would cost to close that gap. This framing positions you as a business risk manager, not a technical operator. It also makes your budget requests land differently.

If you have not tested your recovery capability recently, do not report your theoretical RTO as your actual capability. Boards that discover the gap during an incident lose confidence in their security leadership. Boards that are told about the gap in advance, with a remediation plan, generally fund it.

Entropy is real in small teams. The controls most likely to degrade are the ones that require regular human attention without automated enforcement: access reviews, backup verification, runbook currency, and vendor contract renewals. These are not glamorous. They are also the controls that fail first during an incident.

Build a quarterly entropy audit into your program calendar. Spend two hours reviewing whether your top ten recovery controls are still functioning as designed. Check backup job success rates. Verify that your IR retainer contact information is current. Confirm that your communication tree has not changed since the last update. This is not exciting work. It is the work that keeps your program honest.

Assign ownership explicitly. In a five-person team, 'everyone is responsible' means nobody is responsible. Each critical control should have a named owner and a named backup. When someone leaves the team, control ownership transfer should be part of the offboarding checklist, not an afterthought.

A five-person recovery program is not a smaller version of a large program. It is a different kind of program, one built on ruthless prioritization, honest capability assessment, and external partnerships that extend your reach without expanding your headcount. The teams that build this well are not the ones with the most tools or the most documentation. They are the ones who know exactly what they can do, what they cannot do, and who they are calling when the gap becomes real. Build the program that matches your actual resources, test it against reality, and report it honestly to your board. That is the program that holds up when it matters.