A database can have a backup policy and still leave the business with an unacceptable recovery gap. Its latest usable recovery point might be too old. Its copies might share a failure domain. The account that administers production might also be able to delete the backups. A restore procedure might exist without recent evidence that it works.
All of those situations demand attention. None can be resolved by a single protected-or-unprotected label.
The question for resilience leaders is therefore larger than whether backups exist. It is whether the organization has enough evidence to trust its recovery options across the tools it already operates, and a way to act when that evidence reveals a gap.
Coverage
Has protection been observed?
A coverage check asks whether a resource has evidence of protection under the assessment’s definition. It is a necessary first count, not a recovery claim.
Recoverability
Can that protection meet the requirement?
Recoverability needs freshness, copy separation, deletion resistance, usable access, and a test whose scope matches the claim.
What a backup coverage census can tell you
Eon’s September 2026 Cloud Backup Coverage Census reports 61.2% of production as unprotected under its stated definition. Its methodology considers assigned policies, platform-created recovery points, and visible native snapshots. Snapshot visibility varies by resource type; protection through other tools may sit outside the assessment’s view unless visible through those snapshots.
That scope matters when interpreting the figure. It describes the assessed population under a particular evidence model, rather than proving that 61.2% of all production resources everywhere have no backup. Eon also acknowledges that classification can be imperfect and that counting protection does not establish restore quality.
Those disclosures identify two questions every assessment buyer should ask:
What protection can this assessment see?
What does its evidence actually prove?
A multi-vendor estate needs a view across its protection systems
Consider an illustrative enterprise using cloud-native backups for some databases, a separate platform for virtual machines, and another service for long-term retention. A report assembled from only one source may miss legitimate protection elsewhere. Combining dashboard totals introduces a different problem: the same workload or copy may appear more than once.
The work is to reconcile the production inventory with evidence from the systems protecting it. Each conclusion needs a resource identity, an evidence source, and an observation time. A resource with no observed protection should also carry enough context to distinguish an actual gap from a disconnected integration or insufficient permissions.
Identity
Which production resource is this conclusion about, and can it be distinguished from a duplicate copy of the same workload?
Evidence source
Which connected vendor, cloud service, or snapshot view supplied the observation?
Observation time
When was the evidence collected, and is that timestamp still relevant to the requirement?
Forttic’s vendor coverage model is designed around governance across existing protection systems, including Veeam, Commvault, Druva, Clumio, and cloud-native backup services. It can coordinate approved changes through connected protection systems. This lets teams retain their backup stack while assessing it through a common governance layer.
The practical boundary remains important: coverage depends on the integrations, permissions, resource types, and evidence available in the connected estate. Cross-vendor governance should expose those boundaries, not imply visibility into systems that have never been connected.
What 843 findings reveal that a coverage percentage cannot
An example findings overview supplied by Forttic records 843 open findings across 39 controls and 11 categories. Its value is the range of questions it raises beyond whether a backup exists.
Scoped example · Forttic-supplied overview
Open findings by category
| Finding category | Controls | Open findings | Highest severity |
|---|---|---|---|
| Immutability gaps | 3 | 134 | Critical |
| RPO over SLA target | 1 | 5 | Critical |
| Backup coverage and freshness | 9 | 168 | High |
| Copy count and offsite copies | 4 | 215 | High |
| 3-2-1-1 composite failures | 2 | 135 | High |
| Encryption and access | 6 | 49 | High |
| Retention and point-in-time recovery | 4 | 11 | High |
| Availability design | 3 | 6 | High |
| Media diversity | 1 | 102 | Medium |
| Restore testing | 3 | 4 | Medium |
| Log retention and snapshot hygiene | 3 | 14 | Low |
| Total | 39 | 843 |
These counts must be read carefully. The same asset can fail several controls. A copy-count failure, an offsite failure, and an immutability failure can also trigger a composite 3-2-1-1 failure. Adding them counts control findings; it does not count unique affected assets. The overview does not provide the asset denominator needed to calculate a failure rate.
How to read the units
Findings, controls, and assets are different counts
843 findings
Each row is a control result. One resource can appear in several rows, including a composite 3-2-1-1 failure.
39 controls
Three critical, 22 high, 11 medium, and three low-rated controls. That is a control inventory, not a finding mix.
Assets unknown
This overview does not include a unique-asset count or an in-scope denominator, so it cannot support a failure rate.
Keep these units separate
Finding severity is not the same as control rating
- Critical
- High
- Medium
- Low
The operational significance is in the categories themselves.
Existing copies can still leave important failure paths open
Copy count and offsite controls account for 215 findings in this example. Those findings ask whether the available protection satisfies requirements for the number and location of copies. Several copies do not automatically mean several independent recovery options.
The 134 immutability findings raise a different issue: whether recovery points have the required protection against alteration or deletion. Fixing a missing copy does not necessarily fix deletion exposure. Likewise, placing a copy in another region does not automatically establish isolation from the identities that administer production.
215 findings · copy count and offsite
Enough independent copies?
A second copy in the same failure domain is not a second recovery option. Location and independence need their own evidence.
134 findings · immutability
Protected against deletion?
Adding a copy does not close a deletion path. The closure condition is the required lock, hold, or write-once control.
Related, not interchangeable
Isolated from production identities?
A copy in another region can still share the account that administers production. Isolation is a separate check.
These are related requirements, but each needs its own evidence and closure condition.
Coverage and freshness belong together
The overview contains 168 coverage-and-freshness findings and five findings in the RPO-over-SLA category. A policy assignment expresses intent. A recent usable recovery point is evidence that protection has produced something relevant to the business requirement.
For an illustrative workload with a four-hour recovery point objective, a twelve-hour-old recovery point deserves attention even if the console shows an assigned policy. The report should identify the requirement, the observed recovery-point age, and the gap between them. It should not quietly convert “a copy exists” into “the recovery objective is met.”
Illustrative workload · not a measured estate
A policy can be assigned while the recovery point is already too old
This is the same distinction Forttic’s article on backup coverage after cloud changes makes after a deployment: an assigned policy is not the same as current, usable protection.
Missing restore evidence is a separate problem
Four findings sit in the restore-testing category. That small count should not be read as a low business impact, nor as proof that four restores failed. Missing evidence, an unsuccessful test, and a successful test outside the required window are different states.
Four findings · four possible meanings
Restore-test states are not interchangeable
Missing evidence
No recorded test in the required window. This is unknown, not a failed restore.
Unsuccessful test
A restore was attempted and did not meet the stated pass condition.
Success outside the window
A prior pass exists, but it is older than the required evidence period.
In-window, scoped pass
The test passed, and the claim matches what was actually exercised.
A useful verification record explains what was tested, when it was tested, and what passed. Restoring a database does not, on its own, show that the application can authenticate users or complete a business transaction. The scope of the claim must match the scope of the test. Forttic’s recovery dependency mapping guide treats that customer-journey check as a separate claim from the restore job.
What a stronger resilience report should contain
A better report is not simply a larger list of failed checks. It helps the reader distinguish known exposure, incomplete evidence, remediation progress, and demonstrated recovery.
- State the assessment boundary: connected clouds, accounts, vendors, resource types, collection times, and known blind spots.
- Show unique in-scope assets beside the finding count, and mark composite controls.
- Keep unknown visible. A stale or missing source is not protected, and it is not unprotected.
- Separate proposed actions, approvals, attempted changes, successful changes, and verified closures.
Then make the evidence actionable. Each priority finding should identify the affected resource, the relevant requirement, the observed state, its evidence source, an accountable owner, and the next action.
Editorial standard · not a product inventory
What a priority finding record should make visible
- Resource The affected identity, not a vendor dashboard total.
- Requirement The policy, RPO, or control the observation is judged against.
- Observed state What the latest evidence shows, including age.
- Evidence source Which system supplied the observation, and when.
- Owner Who is accountable for the next action.
- Next action The closure condition, not only the ticket update.
Finally, separate activity from outcomes. A successful API response may establish that a configuration change was accepted. A subsequent check is still needed to establish that the required state holds. Some findings also require a recovery test before the intended outcome can be claimed. Forttic’s verified-closure guide keeps that distinction in the remediation record.
This is a reporting standard worth applying to any platform, including Forttic. Readers should be able to trace a claim back to the evidence that supports it.
How Forttic connects findings to enforcement and verification
Forttic’s Continuous Resilience Enforcement framework follows five stages. Discovery maps assets and protection. Assessment evaluates drift against requirements and business impact. Enforcement applies authorized changes within guardrails, with higher-impact actions escalated for approval. Verification checks outcomes through tiered checks and isolated recovery testing. Reporting preserves the resulting evidence.
Discover Assess Enforce Verify Report
The distinction becomes concrete in a hypothetical stale-backup finding.
- Identify the old recovery pointThe finding opens the investigation. It does not yet prescribe a change.
- Establish why the job stoppedA paused job, a permission change, and a failed run need different responses.
- Apply an authorized correctionThe action stays inside the granted permissions and the workload’s intended state.
- Check the new recovery pointA fresh copy, plus the relevant follow-up checks, is evidence for closure.
- Restore-test when requiredSome findings need a scoped recovery test before the intended outcome can be claimed.
The exact response depends on the connected platform and the permissions granted. It also depends on the workload: a deliberately paused job should not be re-enabled merely because a generic rule expects it to run.
That is why the enforcement boundary matters as much as the assessment boundary. The goal is to maintain the required protection state through approved actions and demonstrate the result. Reporting should show where that process has completed and where work remains open.
Ask for evidence beyond the coverage headline
Coverage assessments are a useful starting point. They force teams to examine whether production resources have observed protection. The next step is to examine the quality, independence, freshness, and tested usability of that protection across the backup stack.
Forttic’s example findings make that broader conversation tangible. They show why coverage, immutability, separation, retention, access, and recovery verification need distinct controls. They also show why honest counting matters: a finding total is useful only when readers understand its scope and units.
Download the free 2026 Forttic CRE Report: Backup Is Outrunning Governance. The research brief explains the gap between completed backup jobs and recovery evidence, and introduces an action plan for continuous resilience governance. It is available with a business email.
For a view of your own operating maturity, the free CRE Assessment provides an eight-question maturity snapshot. It is separate from a connected-estate technical assessment.
Coverage is the first check, not the last
A protected-or-unprotected label cannot answer freshness, separation, deletion exposure, or restore evidence. Ask what the assessment can see, what each finding unit means, and what still needs a verified outcome.
Frequently asked questions
What is the difference between backup coverage and recoverability?
Coverage indicates whether a resource has protection evidence under the assessment’s definition. Recoverability requires evidence that the available recovery option can meet the applicable requirements. That can include freshness, access to keys, copy separation, retention, and successful testing within a stated scope.
Can an assessment miss backups created by another vendor?
Yes, if that protection is outside its connected evidence sources. Check which vendor integrations and resource types are included, what permissions are available, and how unknown states are handled before interpreting an unprotected count.
Do 843 findings mean 843 assets are at risk?
No. The supplied overview counts findings across controls. One asset can contribute several findings, including a composite failure. A unique affected-asset count and an in-scope asset denominator are needed to describe asset exposure accurately.
Does a backup policy prove that the recovery objective is met?
No. A policy expresses the intended behavior. Recovery-point evidence, applicable control checks, and appropriately scoped tests establish what actually happened and whether the requirement was met.
Does Forttic replace existing backup products?
Forttic operates as a governance and enforcement layer across connected backup systems. Teams keep their protection tools while using Forttic to assess drift, coordinate authorized responses, and maintain evidence of outcomes.
Is the free CRE report an assessment of my environment?
No. The free 2026 CRE Report is a research brief. The separate online CRE Assessment is a maturity questionnaire. An assessment using your actual cloud and backup data requires an agreed scope and the appropriate connections.