When a system goes down, the clock starts fast. The real question is not how quickly IT can restore it. The real question is how long your business can afford to be down.
That answer is not technical. It depends on revenue, customer promises, compliance, and what you can defend in front of your board later. If you leave recovery time targets to IT alone, you often get tidy numbers that miss the cost of being wrong.
This is where leaders get burned. A number that looks efficient on paper can be expensive in the real world.
Key takeaways for setting recovery time targets
- Recovery targets are business decisions, not just recovery settings.
- The right number depends on downtime cost, data loss tolerance, and customer impact.
- IT can estimate the options, but leadership has to set the threshold.
- If the targets are not tied to business priorities, you are planning for the wrong failure.
IT-only targets sound precise, but they can miss the point
You can ask IT, vendors, or even an outsourced CTO for a recovery number. They will usually give you a technically possible answer. That does not mean it is the right one.
The better question is this: what breaks if this system is down for one hour, four hours, or a full day? That is a business question. It touches sales, operations, support, cash flow, and risk. If you do not answer it first, the target is guesswork dressed up as control.
AWS says the same thing in practical terms. Its guidance on business impact analysis and risk assessment ties recovery objectives to business impact, not technical preference. That is the point. A recovery target should reflect what failure costs you.
Here is the difference in plain language:
| Question | IT-only answer | Business-informed answer |
|---|---|---|
| How long can this system be down? | “Four hours is feasible.” | “Two hours is the limit before orders, support, or trust start slipping.” |
| How much data loss is acceptable? | “We can restore from last night.” | “Anything beyond 15 minutes creates billing and customer issues.” |
| Who decides? | “Infrastructure team.” | “Business owner, technology leader, and risk owner together.” |
When the business is not part of the decision, you get a technically neat target that may still be commercially wrong.
What business input should cover
You do not need a ten-page workshop to get this right. You do need honest answers from the people who carry the consequences.
Revenue exposure matters first. If a system affects orders, billing, renewals, or customer access, every extra hour of downtime has a price. Some systems can wait. Others cannot.
Customer trust comes next. A delay that is tolerable inside your company may look like failure to a customer. If you are in retail, healthcare, finance, or any service business with a short memory and long competition, the bar is lower than you think.
Compliance and legal exposure also matter. A recovery target that ignores audit obligations, privacy rules, or contract terms is not a real target. It is a wish.
Operational dependency is the last piece people miss. A system may not make money by itself, but it may support payroll, dispatch, manufacturing, or service delivery. If it stops, other teams stop too.
This is where business-aligned technology strategy matters. You are not trying to make every system perfect. You are trying to match recovery effort to business value. That is also why a solid technology strategy is more than a planning exercise. It tells you what matters most when time is short.
Why business input changes the ownership conversation
If you have a fractional CTO, interim CTO, virtual CTO, or part-time CTO, that person should bring the recovery options and the tradeoffs. They should not decide the business tolerance alone. The same goes for a fractional CIO, fractional CISO, virtual CISO, or interim CISO. They bring judgment. You bring the business context.
That is especially important when your company has a technology leadership gap. In that gap, people tend to default to the loudest voice, the most technical voice, or the vendor with the cleanest deck. None of those is the same as clear ownership.
The right room includes the people who know the business impact, the people who know the systems, and the person who can translate between them. That is what executive technology leadership is supposed to do. It keeps the decision grounded, not theatrical.
If you need help sorting that out, fractional CTO and interim CTO services can give you a cleaner read on who should own the numbers and what should be protected first. If you are staring at a messy situation and need a better first conversation, Get an Executive Technology Clarity Check is the fastest way to separate the real problem from the noise.
A practical way to set the numbers
You do not need a perfect framework. You need a usable one. This is a simple path.
- Start with the business process, not the server. Name the customer promise, financial process, or internal operation that matters most.
- Ask what happens at one hour, four hours, and one day. Use plain language. If the answer gets fuzzy, the target is probably too vague.
- Tie each target to a cost, risk, or service consequence. That is how you get to a real tech spending ROI conversation instead of a guess.
- Write the decision down in a short 12-month technology roadmap or one-page technology strategy so the target stays connected to priorities, not memory.
- Test it. If the target has never been exercised, it is a theory.
That last step matters more than people admit. A target that has never been tested belongs in the same category as a backup you have never restored. It might work. You do not know yet.
This is also where strategic technology planning helps. A good recovery plan is not a one-off document. It sits inside your IT strategy and roadmap, your operating rhythm, and your technology governance. If those pieces are weak, the recovery target will drift with them.
The board needs the business version
Boards do not need the system diagram. They need the business version of the risk.
That means board-ready reporting that shows which systems matter most, what downtime costs, what data loss is acceptable, and where the business is making a tradeoff. It also means board cybersecurity reporting that speaks in business terms, not just technical controls. A board should be able to see the connection between recovery targets, cyber risk appetite, and the company’s exposure if an incident lands on the wrong system.
If you want a useful reference point, board-level technology risk oversight is a better place to start than a stack of technical status reports. That is because recovery targets sit inside a larger set of decisions, including technology risk oversight, third-party risk management, vendor risk management, and whether your vendors can actually meet the commitments you are making to customers.
This is where technology governance for CEOs and technology governance for boards stops being abstract. You are deciding how much downtime, data loss, and operational pain the company can absorb. You are also deciding whether your vendor management and vendor due diligence are good enough to support the target you chose.
If you have not reviewed recovery assumptions since a major vendor change, a system swap, or a growth spurt, the old number may already be stale.
FAQ
Who should set recovery time targets?
Business leadership should set them with technology leadership in the room. If you have a technology leader for growing companies, that person should translate the options into business terms. If not, a fractional CTO or interim CTO can help you do it before you hire full-time.
Are recovery time targets the same for every system?
No. Your payroll system, customer portal, and internal reporting tools do not carry the same weight. A good target reflects technology priorities for growing companies, not a blanket rule. If everything is treated as equally urgent, nothing is really prioritized.
How often should you revisit them?
At least once a year, and sooner if you have a major incident, a new vendor, a leadership change, or a shift in revenue dependence. That is where technology leadership before hiring can matter too. You do not need to wait for a permanent executive hire to get the numbers reviewed.
Conclusion
Recovery time targets look technical on the surface, but they are really business promises. If you set them without business input, you are guessing about the cost of failure.
When leadership, technology, and risk owners agree on the real impact of downtime, the number gets sharper. The plan gets cleaner. And the company stops confusing technical possibility with business readiness.
That is the work. Not a prettier document, a better decision.