Business Continuity and Backups Auditors Will Accept

Backups are the control everyone assumes they have. The pipeline runs nightly, the dashboard is green, and nobody has thought about it in a year. Then an auditor asks a simple question: when did you last restore from one of these, and can you show me? The room goes quiet.

This post is about the gap between having backups and having recoverability, and what evidence closes that gap for an ISO 27001 audit.

Backups are not the control. Recovery is.

An auditor does not care that data is being copied somewhere. They care that you can get your service and your data back after something goes wrong. Those are different things.

A backup that has never been restored is an untested assumption. It might be corrupt. It might be missing a critical dataset. The restore procedure might take three days when your customers expect three hours. You do not know, because you have never tried.

This reframing matters because it changes what you build and what you document. If the control is recovery, then the evidence is a successful recovery, not a green backup dashboard. Everything in this post follows from that shift.

The uncomfortable truth many teams discover during their first restore test: the backup was running fine, but restoring it surfaced a dependency nobody had documented, or took far longer than anyone assumed. Finding that during a test is a good day. Finding it during a real outage is the worst day.

Define objectives before you design anything

You cannot judge whether your backups are good enough without knowing what "good enough" means. That is what recovery objectives are for, and auditors will expect them.

Two numbers anchor the conversation:

• RTO, the recovery time objective. How long can the service be down before the impact becomes unacceptable. If your RTO is four hours, a recovery process that takes two days does not meet it.
• RPO, the recovery point objective. How much data you can afford to lose, measured in time. If your RPO is one hour, backups taken once a day do not meet it.

The mistake is setting these numbers by gut feel, or copying them from a template. They should come from a short business impact analysis: for each critical system, what does downtime or data loss actually cost, in money, in contractual penalties, in customer trust. For a payments company, an hour of processing downtime has a very different weight than an hour of marketing-site downtime. Your objectives should reflect that difference, and they should differ by system.

Once the objectives exist, they become the yardstick. Your backup frequency has to be at least as often as your RPO. Your recovery process has to be at least as fast as your RTO. If there is a gap, you either close it or you consciously accept the risk and record that decision. Auditors are comfortable with a documented accepted risk. They are not comfortable with a gap nobody noticed.

Test restores, and keep the evidence

This is the single most valuable thing you can do, and the thing most teams skip. Regularly restore from backup and prove it worked.

A restore test does not have to be a full disaster simulation. Start proportionate:

• Restore a single dataset into an isolated environment and verify integrity.
• Restore a full database and confirm the application runs against it.
• Time the restore and compare it against your RTO.
• Note what broke or surprised you and feed it back into the runbook.

The frequency should match the criticality. For the systems that carry your top-tier data, quarterly restore tests are a reasonable baseline. Annually is the minimum you can defend, and only for less critical systems.

Now the part that turns this into audit evidence. Record each test: the date, who ran it, what was restored, how long it took, whether it met the objective, and what issues came up. A short dated record for each restore test is worth more to an auditor than any amount of architecture documentation, because it is proof the control works, not a claim that it should.

Business continuity is broader than IT recovery

Backups and system recovery are necessary, but they are not the whole of business continuity. Auditors probing this area will widen the lens, and you should too.

Business continuity asks: if a serious disruption hits, how does the organisation keep operating and coordinate a response. That includes technical recovery, but also the human and process side.

• Who decides a continuity plan is invoked, and who takes charge.
• How people communicate when normal systems are down, including an out-of-band channel if your usual tools are the thing that failed.
• Key person dependency. If the one engineer who knows how to run the recovery is unreachable, does the plan still work. Runbooks should let a competent second person execute the recovery.
• Third-party dependency. If a critical cloud region or SaaS provider goes down, what is your response. You cannot fix their outage, but you can have a documented plan for how you operate through it and communicate with customers.

A plan that lives only in one person's head is a finding waiting to happen. Write it down, keep it somewhere reachable during an outage, and make sure the reachable location does not depend on the systems that might be down.

Make it audit-ready without making it heavy

You do not need a hundred-page continuity manual. You need a small set of things that are current and demonstrably real.

The core artefacts an auditor will want:

• Recovery objectives per critical system, traceable to a business impact analysis.
• A backup approach that meets those objectives, with backups protected and, ideally, held in a location isolated from the primary environment.
• Restore test records showing recent successful recoveries.
• A continuity plan covering roles, communication, and key dependencies.
• Evidence of review. The plan and objectives were looked at in the last year and updated as the business changed.

The last point catches many teams. A continuity plan written two years ago that still references systems you have retired tells an auditor the plan is decoration. A plan reviewed three months ago, with a note on what changed, tells them it is a living control. The review is cheap. Skipping it is expensive.

Bottom line

Auditors accept backups when you can prove recovery, not just retention. Set recovery objectives from real business impact, test your restores on a schedule, keep dated evidence of each test, and make sure your continuity plan covers people and dependencies, not just infrastructure. The green backup dashboard is the starting line, not the finish.

If you have backups but have never run a restore test, or your continuity plan has not been opened since it was written, a Kellwick readiness review can help you turn hopeful assumptions into evidence an auditor will accept.