Who should be accountable for deciding recovery objectives across critical applications?

Why Recovery Objectives Need Shared Accountability Across Critical Applications

Recovery objectives are not a pure technology setting. They define how much interruption the organisation can tolerate, how much data loss is acceptable, and what level of continuity is needed for a critical application to remain operational. That makes the decision a business resilience issue as much as an infrastructure one. NIST Cybersecurity Framework 2.0 is relevant here because recovery planning must align with organisational outcomes, not just technical recovery mechanics. In practice, many teams discover the real ownership gap only after a disruption exposes that no one had authority to balance service impact, cost, and control capability.

How Recovery Time and Recovery Point Decisions Should Be Set in Practice

Recovery Time Objective and Recovery Point Objective are most effective when they are set through a joint decision process. Business leaders define the tolerance for outage and data loss in terms of customer impact, revenue exposure, regulatory sensitivity, and operational dependency. Technology leaders then translate those expectations into the actual recovery architecture, backup design, replication strategy, failover pattern, and validation approach. Security and risk teams should challenge whether the proposed targets are realistic under attack, corruption, or regional outage conditions, because the shortest target is not automatically the safest or most achievable target.

That process should also distinguish between critical applications that support immediate continuity and those that can recover more slowly without material harm. A single enterprise standard for all systems usually creates bad outcomes: either the targets are too weak for truly critical services or too expensive for services that do not justify them. The accountable decision therefore needs evidence, not preference. Leaders should base the decision on impact analysis, dependency mapping, and tested recovery capability rather than on what a platform vendor claims is possible.

The most defensible operating model is a tiered one. Application owners describe business function and dependency chain, infrastructure teams explain restoration constraints, and risk owners validate whether the target aligns with continuity obligations. The final decision should be explicit, documented, and owned at the point where business interruption and technical feasibility meet. NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful reference because it ties contingency planning and recovery capabilities to control expectations that must be demonstrable, not assumed.

Where this guidance breaks down is in organisations that have not classified application criticality or cannot test failover realistically, because then recovery objectives become aspirational labels rather than operational commitments.

Where Recovery Objective Ownership Usually Fails

Tighter recovery targets often increase cost and operational complexity, so organisations have to balance resilience against what is realistically supportable across the application portfolio.

One common failure is treating the issue as an infrastructure-only decision. That usually produces targets that fit backup tooling but not the business process the application supports. Another common failure is letting each application team set its own objective without central challenge, which creates inconsistent standards and hidden dependency risk. A third is setting objectives once and never revisiting them after architecture, supplier, or business process changes.

There is also a genuine tradeoff between speed and assurance. A very aggressive recovery target may be technically achievable in a lab, yet fail when authentication services, data replication, network routing, or third-party dependencies are also impaired. The practical lesson is that recovery objectives should be reviewed against real recovery paths, not just against design intent. That review matters most for applications whose outage would cascade into identity, finance, customer service, or regulated operations.

Practitioner Guidance

What to prioritise: Assign a single accountable decision owner for each critical application tier, but require joint approval from business, technology, security, and risk stakeholders. The owner should be responsible for the final tradeoff, not for inventing the target in isolation.

What to verify: Verify that the stated recovery objectives match the tested recovery capability, including dependencies outside the application team’s control. If the recovery path depends on shared services, cloud services, or third parties, those constraints must be part of the decision rather than an afterthought.

Decision rule: If an objective has not been exercised in a realistic disruption test, treat it as unproven. If a critical application cannot meet the target under common failure modes, lower the objective, redesign the control set, or formally accept the residual risk at an executive level.

Practitioner takeaway: Accountability should sit where business tolerance and technical reality meet, because recovery objectives are only useful when someone can defend them, test them, and adjust them when the environment changes.

Related resources from NHI Mgmt Group

• Who should be accountable for application onboarding when identity controls are extended across business-critical applications?
• Why is NHI governance critical in the age of AI attacks?
• How should security teams make NHI best practices usable across the business?
• What is the difference between protecting applications and protecting access?