The backup nobody has ever restored
An organization can run its nightly backup for years without a single reported failure, then discover on the day of an incident that the file is corrupt, a database is missing, or a full restore takes thirty hours when the continuity commitment said four.
A backup that has never been restored is an assumption, not a control. It's also one of the most frequent findings in continuity reviews.
What we manage
Continuous execution of backups according to the policy defined for each system, monitoring that they actually ran, and periodic restore tests with documented results.
The policy isn't the same for everything. A transactional system and a document repository have different frequencies, recovery windows and retention periods. Defining them separately avoids overpaying for some and falling short on others.
Retention and traceability
In supervised entities, how long information must be kept isn't up to the organization: it's set by the applicable regulations. The backup system has to be able to prove that the period is met and that the information remained intact throughout it.
That means logging every run, keeping evidence of restore tests and controlling access to the copies. Without that evidence, compliance is a claim with nothing to back it up.
Disaster recovery
A backup solves data loss. Business continuity is a broader problem: how long it takes the organization to get back up and running, and with what resources.
That's why the service includes setting recovery time and recovery point objectives for each system, and testing that they are met. A continuity plan that has never been rehearsed describes an organization that has probably already changed.