Your backup vendor may be doing exactly what you configured it to do. Your business may now need something different.
A service becomes customer-facing. Its acceptable data-loss window shrinks. A recovery plan adds a second region. An application starts depending on a service that was outside the original protection scope.
The resulting gap needs a diagnosis. You might need to enable an existing feature, adjust a policy, repair an operational process, or introduce a complementary capability.
The decision starts with a specific question: what must this workload recover from, and can the available protection deliver that outcome?
Forttic brings recovery evidence and operational context into that discussion. Its role is to help teams govern protection across their backup ecosystem and follow through on the changes they authorize.
Start with the recovery requirement
A useful backup strategy specifies what the business needs to recover, under which conditions, and within what limits.
The recovery point objective, or RPO, defines acceptable data loss expressed in time. The recovery time objective, or RTO, defines the target time to restore the required service. Those objectives need a defined scope: a database restored in isolation and an application ready for customers are different outcomes.
Document the recovery scenario as well. Recovering from an accidental deletion may use a different path from recovering when a production account or region is unavailable.
Before comparing products, record the workload, business owner, required functionality, RPO, RTO, recovery destination, and dependencies. Include the identity and keys the team expects to use. That gives everyone a common basis for assessing protection fit.
Classify the gap before recommending a fix
“Backup protection gap” covers several different problems. Each calls for different evidence and a different response.
| Gap type | Illustrative situation | Appropriate next step |
|---|---|---|
| Configuration | A supported copy policy was never enabled for an in-scope workload. | Review the policy, authorize the change, and confirm the resulting copy. |
| Operational | A configured copy process is repeatedly failing or delayed. | Investigate the cause, restore normal operation, and check recovery-point adequacy. |
| Evidence | The recovery path exists, but relevant test evidence is missing. | Run a check or exercise that resolves the uncertainty. |
| Architecture | Copies depend on a shared identity or key that may be unavailable in the planned scenario. | Evaluate dependency separation and test access under that scenario. |
| Capability | The required recovery operation is unsupported for this resource or destination. | Confirm the restriction and evaluate another supported approach or complementary tool. |
These categories can overlap. A finding may begin as an evidence gap and reveal an architectural problem during testing. Keep the diagnosis open until the relevant facts are established.
A missing result also needs careful treatment. If an integration cannot observe a recovery copy, record the visibility limit. Obtain evidence from the owner or protection system before concluding that the copy does not exist.
Use history to understand how the protection behaves
Historical information is useful when it helps explain the current decision. Relevant inputs can include recurring copy delays, restore experience, prior exceptions, and the reasons a retention policy was chosen.
Ask whether those observations apply to the workload and scenario under review. A restore performed with a different dataset, identity, or environment may support only part of today’s requirement.
Also separate observation from projection. Repeated delays are observed behavior. The possibility that those delays will compromise a tighter future RPO is a planning concern that needs evaluation. A numerical probability of that outcome would require a defined and validated predictive model.
This distinction lets a team anticipate risk without presenting every warning as a forecast. For a broader assessment approach, start with the companion article, Backup Risk Assessment: Choose Protection Before Risk Grows.
Evaluate backup vendor limitations in context
A vendor’s capability needs to be assessed at the level of the resource, operation, configuration, region, and applicable service tier. A broad support statement may not answer the recovery question you have.
For example, AWS Backup’s feature documentation explains that cross-Region or cross-account copies of continuous backups become periodic snapshots, without point-in-time restore for those copies. A recovery design depending on a copied point must account for that behavior.
This is a design constraint to evaluate against the requirement. It does not establish that the product is unsuitable for other workloads or that another vendor is automatically a better fit.
When reviewing a constraint, ask the provider or implementation partner to confirm the supported configuration. Check whether a native alternative, an available feature, or a change to the recovery procedure can satisfy the requirement. Document any remaining limitation and the evidence behind it.
That makes vendor conversations more productive: both teams can work toward a defined recovery outcome.
What a useful protection recommendation should contain
A recommendation should connect the gap to an achievable outcome. “Improve backup resilience” is too vague to implement or verify.
Use this structure when evaluating advice from a platform, a vendor, or your own team:
- Requirement: The workload, recovery scenario, RPO, RTO, and required service outcome.
- Evidence: The observed condition, source, observation window, and visibility limits.
- Diagnosis: The type of gap and what remains uncertain.
- Options: Feasible changes, including capabilities already available in the stack.
- Trade-offs: Cost, complexity, dependency changes, and operational impact.
- Action: The proposed response, owner, approval, and implementation plan.
- Verification: The result that will show the response met its purpose.
Where evidence is incomplete, the appropriate recommendation may be a targeted test. Where a capability cannot meet the requirement, the recommendation may be an additional protection mechanism. Both are useful outcomes when the reasoning is explicit.
This is an evaluation checklist for recommendation quality, not a claim that Forttic automatically produces every field or ranks every available backup product.
An example: a copy exists, but the requirement has changed
Consider an illustrative service with a new requirement: recover from an unavailable production region with no more than one hour of data loss.
The team has a secondary-region copy process. Its current schedule provides copies every four hours, and recent observations show it operating as configured. That does not demonstrate the new one-hour target.
The next question is whether the existing protection system supports an arrangement that can meet the target for this workload. If it does, the team can assess the required configuration, cost, permissions, and expected copy behavior. It should then test the recovery path using the secondary-region copy.
If the required operation is unsupported, the team can evaluate a complementary approach with the provider. That evaluation should include failure independence, recovery procedures, operational burden, and validation.
Increasing the schedule alone is insufficient evidence of success. The team needs to establish whether usable recovery points meet the data-loss requirement and whether the service can be restored within its time target under the intended conditions.
The decision follows the requirement and evidence, with vendor selection considered when the diagnosis calls for it.
How Forttic supports the decision and the follow-through
Forttic’s decision architecture describes operational memory for restore patterns, approval workflows, and retention rationale. Carrying that context forward helps teams understand why protection was configured a certain way and what deserves review as requirements change.
Ask Forttic describes regional-failure scenario analysis and recovery shortfalls. These capabilities can help focus investigation on the workloads and dependencies that matter under a stated scenario. A simulation remains an input to verification rather than evidence that a restore has completed.
The CRE framework connects assessment to remediation within guardrails, approval for high-impact actions, recovery verification, and reporting. That gives the decision an operational follow-through: authorize the response, apply supported changes, and retain evidence of the result.
Coverage depends on the connected systems, supported operations, and permissions in the environment. The protection systems continue to perform their backup and recovery functions; Forttic provides the cross-system governance around them.
Revisit protection fit as requirements evolve
Choose a critical service and its next material change. Establish the recovery requirement, classify any gap, and identify the most useful next action.
Sometimes that action will use a feature you already own. Sometimes it will repair a process or resolve uncertainty through testing. Sometimes the evidence will justify an additional capability.
Keep the requirement and verification criteria visible through the decision. That makes it easier for your team, your backup providers, and your implementation partners to work toward the same outcome.
Read the free 2026 CRE report for Forttic’s perspective on backup governance and continuous resilience enforcement.
Diagnose the gap, then choose the response
A feature you already own, a repaired process, or a complementary capability can each be the right answer once the requirement and the evidence are specific.
Frequently asked questions
How do you know when your backup strategy needs to change?
Review it when recovery objectives, workload scope, dependencies, locations, or operating conditions change. Compare relevant recovery evidence with the new requirement and investigate any mismatch before committing to the target.
Does a protection gap mean the backup vendor should be replaced?
No. The cause may be configuration, operations, missing evidence, architecture, or a capability limit. Diagnose the gap first. An available feature or procedural change may address it; other cases may justify a complementary protection option.
How should teams evaluate backup vendor limitations?
Check current documentation for the exact resource, operation, region, and configuration. Confirm the supported approach with the provider and test it against the workload’s recovery requirement. Record unresolved restrictions and their operational implications.
Can Forttic help teams evaluate backup choices?
Forttic’s operational context, assessment, and recovery evidence can inform that evaluation across supported, connected systems. This article does not describe an automatic vendor-ranking or migration service. Teams still need to validate fit and authorize the appropriate response.
How does Forttic work with existing backup platforms?
Forttic provides a governance process around connected protection systems: assess requirements and gaps, coordinate supported actions within guardrails, verify outcomes, and retain evidence. The backup platforms continue to provide their protection capabilities.