What this checker is designed to catch
Recovery objectives often look reasonable when they are reviewed one field at a time. Problems appear when the values are placed on one timeline. A business owner may approve a twenty-four-hour maximum tolerable disruption, a technology team may accept an eight-hour recovery target, a critical supplier may need twelve hours to restore its service, and the backup configuration may only protect data every four hours even though the business expects a one-hour RPO. Each number can exist in a spreadsheet, but the combined design cannot deliver the stated outcome.
This tool performs a simple consistency check across those dependencies. It is intentionally a planning aid rather than a standards-compliance test. It does not decide what your objectives should be. The business impact analysis, service design, risk appetite, regulatory requirements and technical evidence should determine the values. The checker helps you identify contradictions before the objectives are approved, contracted, engineered or tested.
How to interpret MTPD/MAO and RTO together
MTPD or MAO represents the outer business tolerance for disruption. RTO is the target time to restore the service or capability to an agreed level. A practical design normally requires the RTO to sit inside the maximum tolerable window, not directly on its boundary. If the RTO equals the MTPD, there is effectively no allowance for detection, decision-making, escalation, technical variance, validation, business restart or an unsuccessful first recovery attempt.
The checker therefore calculates the remaining headroom between MTPD/MAO and RTO. It flags a direct conflict when RTO is not below the maximum tolerance and marks a narrow margin for review. The twenty-percent or two-hour buffer used by the tool is only a conservative planning heuristic; it is not presented as an ISO requirement. A very short-duration service may need a different margin, while a complex cross-border recovery may need substantially more contingency. The useful question is whether the remaining time is enough for the real sequence of actions that must happen after the technical restore.
Why dependency timing belongs in the same calculation
An application cannot meet an eight-hour RTO if a mandatory dependency is designed to return in twelve hours. The same logic applies outside technology. A process may depend on a building, a specialist team, a payment provider, a logistics partner, a secure network, a cloud identity service or a source of operational data. Recovery plans become credible only when the objective of the consuming service is reconciled with the recovery capability of the dependency.
Use the “slowest critical dependency” field for the dependency that genuinely gates recovery. If several dependencies can recover in parallel, use the one that creates the longest critical path rather than adding every duration together. If activities are sequential, build the real timeline separately and enter the time at which the final gating dependency becomes usable. A red result should lead to a design decision: accelerate the dependency, create an alternate, change the consuming service’s RTO with business approval, or redesign the recovery sequence.
RPO must be supported by the data-protection mechanism
RPO describes the amount of data loss the business is prepared to accept, expressed as time. It is not automatically achieved because a field in a BIA says “one hour.” The backup, replication, journal or transaction-protection mechanism needs to support that expectation, and the restore procedure must be able to use the protected data. A two-hour backup interval cannot reliably support a one-hour RPO; the protection point could already be nearly two hours old when the incident begins.
The checker compares the stated RPO with the effective backup or replication interval. An interval that is equal to or smaller than the RPO is directionally consistent, but evidence is still required. Consider backup job failures, replication lag, corruption, retention, immutable copies, application-consistent snapshots, restore access, encryption keys and the time required to validate recovered data. A zero RPO is a special case: it normally implies a design intended to avoid committed-data loss, so a non-zero periodic backup interval alone would not be sufficient evidence.
Corrective-action workflow after a warning
Do not “fix” a red result by changing the easiest number. Start with the approved business tolerance and trace the contradiction to its source. Record the current capability, the target, the evidence and the owner of the gap. If the business target is valid but technology cannot meet it, treat the difference as a recovery capability gap with an agreed remediation decision. If the original target was based on an unsupported assumption, return it to the BIA owner for review rather than silently changing it in a technical plan.
- Confirm the business tolerance. Validate that MTPD/MAO reflects the impact timeline and not an arbitrary round number.
- Map the recovery critical path. Identify which teams, systems, suppliers, facilities and data components must be available before the service can operate.
- Compare objective with demonstrated capability. Use test evidence, not only architecture diagrams or contractual statements.
- Resolve the gap explicitly. Improve capability, introduce an alternate, reduce dependency, or obtain an approved change to the target.
- Retest the complete service. A component-level restore can pass while the end-to-end business service still misses its objective.
Worked example
Assume a customer service has a twenty-four-hour MTPD, an eight-hour RTO and a two-hour RPO. Its application can technically restart in four hours, but identity services recover in six hours and the required data replication has an effective one-hour interval. On paper the design is consistent: the gating dependency is inside the eight-hour RTO, the backup interval is inside the two-hour RPO, and sixteen hours remain between the RTO and the maximum tolerable disruption. That does not prove recovery will succeed, but it gives the team a coherent set of objectives to validate through exercises and tests.
Now change one assumption: the identity platform is supported by a third party with a contractual twelve-hour recovery target. The application team can still claim a four-hour technical restore, yet the business service cannot authenticate users until the dependency is available. The correct response is not to keep both numbers and hope the issue is ignored. The service owner should decide whether identity recovery can be accelerated, an emergency authentication path can be designed, or the eight-hour business RTO needs formal reconsideration.
Use the result with related BCM practices
Recovery-objective consistency is one part of a larger continuity design. Use the Business Impact Analysis guide to establish impact-based requirements, the continuity strategy guide to translate objectives into workable capabilities, and the backup versus disaster recovery guide when validating data protection and technical restoration. For program-level capability, use the BCM Readiness Scorecard.
Frequently asked questions
Does RTO always have to be lower than MTPD?
A recovery target should normally sit inside the maximum tolerable disruption so the organization has execution margin. The exact margin is context-dependent. The tool flags equality or inversion because those values leave no practical recovery headroom.
Is backup frequency the same as RPO?
No. Backup or replication frequency is one capability that supports an RPO. RPO is the business requirement for acceptable data loss. Successful restores, replication lag, application consistency and other controls also affect whether that requirement can actually be met.
Can I use this result as audit evidence?
The calculation can support a review discussion, but audit evidence should include the approved objectives, source BIA, architecture or procedure, dependency commitments and recovery-test evidence. The tool is not a certification or compliance determination.