A resilience review finds that an important service cannot demonstrate the recovery outcome its owner expects.
The next conversation turns to products. Would another backup system provide better protection? Should the team add a second vendor? Is the current platform the limitation?
Those may be reasonable questions. First, establish what is missing.
A supported capability may be configured incorrectly. A recovery path may exist without relevant test evidence. The evidence may be available to another team but absent from the review. Or the current design may genuinely lack a required capability.
These situations can look similar in a findings list. They require different decisions.
Define the requirement before evaluating the product
“Improve resilience” is too broad to guide a purchase or configuration change.
Start with a service and a requirement that can be evaluated. State the tolerated data loss, target recovery time, scenario, retained-history requirement and authority boundaries. Identify who accepts the outcome.
For example, a service owner may require a recovery option that remains usable after compromise of the primary backup administration identity. That requirement is different from needing a copy in another region. A design can satisfy the location requirement while leaving authority shared. Review the recovery topology before treating a separate region as an independent path.
Write down what would count as sufficient evidence. A product feature list, a configured setting and a measured service outcome answer different questions.
Four gaps that need different responses
Use this matrix before recommending a new system:
| Gap type | Question to resolve | Appropriate next step | Closure evidence |
|---|---|---|---|
| Configuration | Is the required capability supported but incorrectly applied? | Approve and implement the relevant change | Observed required state and validation appropriate to the claim |
| Evidence | Does the design look suitable but lack a relevant test or record? | Obtain existing evidence or perform the scoped check | Dated result with conditions, scope and outcome |
| Visibility or access | Is the review unable to observe the necessary resource or evidence? | Resolve scope, permissions or ownership | Reconciled records and explicit remaining blind spots |
| Capability or design | Can the supported design meet the requirement at all? | Compare architectural changes and additional capabilities | A demonstrated option meeting agreed acceptance criteria |
A service can have more than one type of gap. Missing access can hide configuration drift. A completed configuration change can still need verification. Keep those distinctions visible instead of forcing one label to represent the entire service.
Compare vendors against the same service outcome
Different platforms may use different terminology, policy models and integration boundaries. Comparing their default dashboards can produce an inconsistent assessment.
Build a service-level matrix with one row per requirement. For each provider or protection mechanism, record the observed state, evidence source, observation time, limitation and owner.
For retention, distinguish the approved duration from the duration currently applied. For separation, inspect geography and administrative authority. For verification, distinguish a configuration inspection from resource restoration and application validation.
Do not assume that a second vendor automatically supplies an independent recovery option. Inspect whether it shares the same privileged identity, account access or other critical dependency.
Equally, do not assume that an existing platform lacks a capability because the team has not enabled it. AWS Backup, for example, offers scheduled restore testing and a separate optional validation step. Those existing capabilities may help address an evidence gap, depending on the resource and required outcome.
Worked example: three findings, three decisions
Imagine a service review produces the following observations. This is an illustrative scenario, not a customer case study.
| Observation | Initial interpretation | Better next decision |
|---|---|---|
| Approved retention is 35 days; a policy now applies 7 days | The backup platform is inadequate | Check support and change history; correct the policy within approval boundaries and verify the result |
| A recovery copy exists, but no relevant restore result is recorded | The copy cannot restore | Check for existing evidence, then define a scoped test if needed; keep recoverability marked unverified |
| All available paths depend on the compromised administrative route | Add another copy | Assess a path with suitable authority separation and prove responders can use it under the scenario |
Correcting retention does not necessarily recover historical points that have already expired. Mark that residual gap separately.
Similarly, a missing test is an uncertainty rather than proof of failure. It becomes actionable when the team specifies which claim needs validation and what result would support it.
The third finding may justify a different configuration, architecture or capability. The decision should follow evidence about the available options.
Lineage belongs in the evaluation
Storage growth can trigger another premature conclusion: more retained copies must mean stronger protection, or old copies must be waste.
Before counting a snapshot as useful protection or approving its removal, trace its source, creating tool, owner, retention rationale and downstream references. Distinguish confirmed active use, approved retention and unresolved lineage.
Suppose a snapshot’s source workload has been removed. The review still needs to establish whether an image or recovery workflow references the copy, or whether a separate retention obligation applies. If the source account is outside the review’s visibility, record that limitation.
This matters to product evaluation as well as cleanup. An additional system can increase storage and operating complexity without closing the original service requirement. Include lifecycle ownership and evidence collection in the proposed design, not just its ability to create another copy.
When another capability is justified
Additional capability is appropriate when the requirement is clear and the current supported options cannot meet it within acceptable constraints.
Ask each candidate to demonstrate the specific gap. A useful evaluation might require the team to show:
- Recovery access under the assumed identity or account disruption.
- Compatibility with the workload and destination environment.
- Measured performance against the approved recovery targets.
- Retention and control behavior under the intended policy.
- Evidence that the operating team can retrieve and interpret.
- Ownership, permissions, cost and lifecycle requirements.
Evaluate existing native capabilities alongside third-party options. For example, AWS documents logically air-gapped vaults with compliance-mode Vault Lock and mechanisms for access from other accounts. Applicability depends on supported resources and configuration; the feature name alone is not an acceptance test.
Give the incumbent provider the same requirement and a chance to demonstrate a suitable design. The result may be an improved use of the current platform, an additional capability, or a documented limitation requiring another approach.
Forttic’s role: connect the requirement to the decision
Forttic positions CRE as a layer across existing protection systems. Its vendor coverage model includes coordinating approved changes through connected platforms, allowing the review to focus on the service outcome across the stack.
Use Discover, Assess, Enforce, Verify and Report to structure the decision: establish the observed state, classify the gap, authorize the response, check the outcome and preserve the record. Confirm integration and execution boundaries for the actual deployment. The CRE framework describes that loop.
That supports a constructive conversation with backup vendors and cloud partners. The question becomes specific: which requirement is unmet, what change would satisfy it, and what evidence will establish closure?
See How Forttic Decides for the decision architecture behind this approach.
Leave the review with an owned next step
For each material gap, record the service, requirement, evidence, classification, proposed response, approver and acceptance criterion. Include what remains uncertain and when the decision needs review.
Start the free CRE assessment to identify where your operating process needs attention. It is a maturity questionnaire; a technical assessment of a connected estate is a separate activity.
Name the gap before you name the product
A setting change, a missing test, an access limit and a capability limit can look the same in a findings list. They do not share a remedy.
Frequently asked questions
What is backup gap analysis?
Backup gap analysis compares required protection and recovery outcomes with observed configuration, available capabilities and relevant evidence. It identifies both the gap and the decision needed to address it.
Does a failed recovery test mean we need another vendor?
Not necessarily. Investigate the failure, test conditions and dependencies. The cause may be configuration, permissions, an unsupported recovery path or a capability limitation. The remedy should follow that diagnosis.
How can we compare different backup vendors fairly?
Apply the same service requirements, failure scenarios and acceptance criteria. Compare observed behavior and evidence while recording workload support, integration boundaries, ownership and costs.
Is missing evidence the same as failed protection?
No. Missing evidence means the claim is unverified within the review’s scope. Obtain the record or perform an appropriate check before treating the outcome as either established or failed.
Does Forttic require replacing existing backup systems?
Forttic is positioned to work across the existing protection stack. Supported integrations, data visibility, authorized actions and verification scope should be confirmed for the environment.