"We Have Backups" Does Not Answer the Audit Question

When an audit question comes up on the database side, one of the most common answers is "we have backups, we can restore." That sentence is true and it matters, but it does not answer the question asked. This article separates what a backup solves from what it does not.

The "We Have Backups" Sentence

Backup is a mature discipline. In most organisations it runs on a schedule, is tested and has a defined retention period. On the recovery side that is solid ground.

The problem is offering a backup as the answer to an audit question. The auditor asks whether a change was authorised; the answer given is that it can be reversed if it goes wrong. These are different questions. The first is about control, the second about recovery.

The confusion is not harmless. An organisation that trusts its recovery capability tends to relax its preventive controls: the thought that it can always be reversed shortens approval steps and reduces review depth. Yet recovery has a cost and is not always possible.

Three Questions a Backup Cannot Answer

• Who requested this change and who approved it? A backup is a photograph of data. It does not contain the decision taken before the photograph. You can see the difference between two backups but not why that difference exists.
• Was the text that ran the approved text? A backup shows the outcome, not the statement. If the approved script and the executed script differ, comparing two backups will not reveal it.
• Did something change that should never have changed? A backup only answers the question you ask it. If you do not know what to ask, finding a single unauthorised change inside millions of rows of difference between two backups is practically impossible.

The answers to those three live only in a record produced at the moment of the change. They cannot be reconstructed later, because the context of the decision has passed.

Restore and Rollback Are Not the Same

Restoring from a backup moves the whole database to a point in time. It is the most expensive way to fix a bad change, because every correct transaction in between is lost as well.

A rollback is targeted: a script that reverses only that change and leaves everything else alone. Preparing the rollback script alongside the change request itself brings the cost of recovery down from hours to minutes.

From an audit point of view the difference matters even more. A rollback is itself a request: it has a record, an approval, a known executor and a link to the source request. A restore usually survives as one line in an incident record, with no documentation of which change it undid.

When and how the rollback script is produced is also a decision. Automatic generation is possible but not for every statement; some operations are irreversible by nature and that has to be known while the request is being raised. The product flags irreversible cases as a separate finding in the risk assessment: the surprise should come at decision time, not during the incident.

A Backup Is a Copy of Personal Data

This is the real risk backups create in an audit, and it usually comes from the data protection side. A production backup is a copy of all the personal data in production, and it lives on for the whole retention period.

When an erasure request arrives, deleting from production is easy. The standard answer for copies in backups is that those records will be deleted again if the backup is ever restored. That is a defensible position, but it requires a written procedure and a record showing the procedure operates. Most organisations have neither.

The second risk is restoring a backup into a test environment. This is common practice and it moves production data into a less controlled place. Taking a backup is a control; opening it in a test environment is a risk. Because both sit inside the same procedure they are usually approved together and never assessed separately.

Where a Backup Really Is Evidence

Asked the right question, a backup does produce evidence, and that value should not be dismissed.

• Proof of recovery capability. Restore tests carried out regularly and recorded are direct evidence for business continuity controls.
• Proof that data was not lost. After an incident, which point was restored and how much data was lost is shown from backup records.
• Refuting a claim. An assertion that a record did not exist on a given date can be checked against the backup from that date. It is rarely used in audits but it is a strong method.

The common thread: a backup produces evidence about the state of data. It produces none about decisions, authority or process. The two kinds of evidence do not substitute for each other, and an audit asks for both.

Frequently Asked Questions

Is taking a backup before every change a sufficient control?

It is good practice on the recovery side and not a control on the governance side. A backup does not show whether the change was authorised, against which rule it was assessed, or whether the text that ran was the text approved. On large databases taking a backup before every change is also not always feasible, and that is where the control is quietly skipped.

Who should prepare the rollback script?

The person requesting the change prepares it, but that alone is not enough: the existence and correctness of the rollback script should be part of the approval step. In some cases a rollback can be generated automatically, and the cases where it cannot should be flagged explicitly. A request being irreversible is not an obstacle, but approving it without knowing is a finding.

What should we do about personal data in backups?

You need a written procedure: a list of records subject to an erasure request is kept, and those records are deleted again whenever a backup is restored. Having the procedure is not enough; a record showing that it operates is needed too. Restoring a backup into a test environment should also be treated as its own decision, and that decision should leave a trace.

Should audit records be backed up separately?

Audit records live in the product's own database and are covered by that database's backup. Beyond that, a full row copy of the records can be written to a second database, ideally on a separate server. That is a control rather than a backup: its purpose is not to prevent data loss but to leave a copy to compare against if the main record is deleted. The two do different jobs and neither replaces the other.