Ask an IT manager whether the company’s data is backed up and the answer is always yes. Ask when the settlement database was last restored from that backup, by whom, how long it took, and how much data was lost between the last good copy and the point of failure, and the room goes quiet. The difference between those two questions is the whole audit. Backups are a job that runs; recovery is an outcome that has either been demonstrated or has not. Every organization that has lost data to a ransomware attack, a storage failure or a deleted volume had backups. What they did not have was a restore that had been proven, from a copy the attacker could not reach, within the time the business could survive.
This guide is the method for auditing backup and recovery as an outcome rather than a job. It defines the objective in terms of recovery point and recovery time, sets out the nine controls that make up the domain with their NIST, ISO, CISA and DORA references, works through the inventory question of what must be backed up in the first place, explains how to get the real recovery objectives rather than the aspirational ones, treats the restore test as the only evidence that matters and gives a template for recording it, covers what ransomware changed about backup architecture, sets out a twelve-test program, and finishes with a worked example at MidState Beverage, where a restore test run during an acquisition integration engagement showed a four-hour recovery objective that was actually nine hours and a transaction-log backup that had been failing for five months. It sits alongside the business continuity and resilience guide, which covers the wider program; this one is the technology layer underneath it.
In this guide
- The objective: recover the right data, to the right point, in the right time, from a copy the attacker cannot reach
- The nine controls, and the frameworks behind them
- The inventory question: what has to be backed up
- Recovery objectives: getting the real numbers
- The restore test is the only test
- What ransomware changed: immutability, isolation and the backup server as the target
- The twelve-test program
- Cloud and SaaS: snapshots are not backups and retention is not recovery
- Worked example: MidState Beverage restores a settlement database and finds five months of silent failure
- Common mistakes
The objective: recover the right data, to the right point, in the right time, from a copy the attacker cannot reach
Written out in full, the control objective has four parts, and an audit that tests fewer than four is incomplete. The right data: everything the business needs to operate and report, which is a larger set than the servers the IT team thinks of as important. The right point: the recovery point objective, the maximum tolerable data loss measured backwards from the failure, which determines how often copies must be taken. The right time: the recovery time objective, the maximum tolerable outage, which determines how the copies must be stored and how the restore must be rehearsed. And a copy the attacker cannot reach: the requirement that ransomware made explicit, that at least one copy sits somewhere a compromised administrator credential cannot delete or encrypt it. A backup process can satisfy the first three and fail completely on the fourth, which is why most of the catastrophic losses of the last several years happened at organizations whose backup jobs were green every morning.
The two objectives are defined by the business, not by IT. A recovery point of 24 hours means the business has accepted that a full day of transactions may need to be re-entered or reconstructed; for a distributor settling three hundred routes a day that is a specific, quantifiable amount of work and risk, and the finance director should have agreed to it knowingly. A recovery time of four hours means every process that depends on the system has a four-hour manual workaround, or has accepted that it will stop. When the auditor finds that these numbers were set by the infrastructure team without business involvement, or were copied from a template, the finding is not about backups; it is about the business impact analysis that should have produced them, and the backup audit has just become a governance audit.
The nine controls, and the frameworks behind them
The domain reduces to nine controls. They are listed in the order an auditor should evaluate them, because the later ones are meaningless if the earlier ones are absent: a rehearsed restore of a system that was never in scope proves nothing about the systems that were, and an immutable copy of an incomplete backup is an immutable copy of a gap. The evidence column names what to ask for; a backup audit that accepts a policy and a screenshot of a green dashboard has tested control 1 and part of control 3 and nothing else.
| # | Control | What it ensures | Evidence that it operates |
|---|---|---|---|
| 1 | Backup policy and scope derived from the system and data inventory and the business impact analysis | Nothing the business needs is outside the backup set | Policy, inventory with backup status per item, BIA tiers, reconciliation of inventory to backup jobs |
| 2 | Schedule and method aligned to each system’s recovery point objective | Data loss on failure stays within the agreed tolerance | Job schedules per system compared with RPO; transaction-log or continuous protection where RPO is short |
| 3 | Job monitoring with failure alerts and documented resolution | Failures are noticed and fixed before they matter | Job history for the period, failure tickets, time to resolution, evidence someone reads the alerts |
| 4 | Multiple copies on different media with at least one offline, offsite or immutable | A single event cannot destroy all copies | Copy topology per system; immutability or air-gap configuration; offsite location and transfer evidence |
| 5 | Encryption of backup data at rest and in transit, with key management independent of the backup administrator | Stolen backup media or repositories do not become a breach; keys survive the disaster | Encryption settings, key custody, key backup and recovery procedure |
| 6 | Access to backup systems restricted, separately authenticated with MFA, not tied to the production directory | A compromised production credential cannot delete backups | Backup console access list, authentication configuration, deletion alerts, privileged access review |
| 7 | Retention aligned to legal, regulatory and operational needs, with legal hold and secure disposal | Data is kept long enough and not forever; media are destroyed properly | Retention schedule, retention configuration per job, disposal certificates |
| 8 | Restore testing at file, database, application and site level with recorded results against RTO and RPO | Recovery is proven, not assumed | Test log with scope, method, duration, data loss, issues and remediation; auditor-selected restore |
| 9 | Documented recovery procedures, assigned roles, alternate processing arrangements, and integration with incident response | Recovery happens under pressure without the one person who knows how | Runbooks, role assignments, alternate site or cloud recovery configuration, exercise records |
The framework map matters more in this domain than in most, because regulators have started writing backup requirements into law rather than guidance. The table gives the references an auditor is likely to need. Two deserve emphasis. The CISA #StopRansomware Guide, updated in September 2023 and co-authored with the FBI, NSA and MS-ISAC, tells organizations to maintain offline, encrypted backups of critical data and to test their availability and integrity regularly in a disaster-recovery scenario, and it warns that many ransomware variants search for and delete or encrypt any backup they can reach. DORA Article 12 requires financial entities in the EU to have backup policies specifying scope and minimum frequency, restoration and recovery procedures, periodic testing of both, and, when restoring, the use of systems physically and logically segregated from the source system. Neither is exotic; both simply state the four-part objective in regulatory language.
| Source | What it requires or recommends | Use in the audit |
|---|---|---|
| NIST SP 800-34 Rev. 1 (2010), Contingency Planning Guide for Federal Information Systems | Seven-step contingency planning process from policy and BIA through strategy, plan, testing and maintenance; backup methods and alternate site types (cold, warm, hot, mirrored) | The structure for evaluating controls 1, 8 and 9 and the vocabulary for alternate sites |
| NIST SP 800-53 Rev. 5 | CP-9 System Backup, CP-10 System Recovery and Reconstitution, CP-4 Contingency Plan Testing, with enhancements for testing restoration, separate storage and cryptographic protection | Control statements to cite for federal and federally influenced environments |
| NIST Cybersecurity Framework 2.0 (2024) | PR.DS-11: backups of data are created, protected, maintained and tested | The single line most cyber programs map to; ask what evidence sits behind it |
| ISO/IEC 27001:2022 Annex A | 8.13 Information backup; 8.14 Redundancy of information processing facilities | Certification evidence and the auditee’s own internal audit results |
| CISA #StopRansomware Guide (updated September 2023) | Offline, encrypted backups; regular restore testing in a disaster-recovery scenario; caution that reachable backups are deleted by attackers; immutable cloud storage with configuration care | The reference for control 4 and control 6 and for the ransomware section of the report |
| DORA, Regulation (EU) 2022/2554, Article 12 (applies from 17 January 2025) | Backup policies with scope and minimum frequency; restoration and recovery procedures; periodic testing; segregated systems for restoration | Binding for EU financial entities; a useful benchmark elsewhere |
| FFIEC IT Examination Handbook, Business Continuity Management (2019) | Examiner expectations for backup, recovery and resilience testing at US financial institutions | The standard US bank examiners apply; ask for the last examination comments |
The inventory question: what has to be backed up
The first substantive test is a reconciliation, and it is the one most backup audits skip. Take the organization’s inventory of systems and data, the one the IT audit plan should already be built on, and compare it line by line with the list of backup jobs. Every item in the inventory should either be covered by a job or carry a documented decision that it does not need to be. The gaps found this way are rarely the core ERP, which everyone remembers; they are the things nobody classified as a system. The table lists the categories that go missing and who usually owns the gap.
| Category | Why it is missed | What is lost if it is | Typical owner of the gap |
|---|---|---|---|
| Application configuration and customizations | Backups target the database; the application server’s configuration, custom code and integration settings are assumed to be rebuildable | Weeks of rebuild after a restore that technically succeeded | Application team |
| Departmental spreadsheets and file shares used in financial processes | Not on the system inventory; live on local drives or unmanaged shares | Reconciliations, deposit listings, allocation models with no other source | Finance; depot or branch managers |
| SaaS data | Assumed to be the vendor’s responsibility; the vendor’s contract says otherwise | Customer-side deletions and corruption beyond the vendor’s recycle-bin window | Whoever signed the SaaS contract |
| Secrets, keys and certificates | Stored in a vault with its own backup that nobody has restored | Encrypted backups that cannot be decrypted; services that cannot start | Security team |
| Infrastructure state and code | Treated as reproducible from the repository, which itself may not be backed up | Inability to rebuild environments during recovery | Platform team |
| Endpoints of key staff | Policy says nothing should live on laptops; practice differs | Working papers, models, drafts | Everyone |
| The backup catalog and configuration | The backup system is not backed up | Copies that exist but cannot be found or mounted | Backup administrator |
| Systems inherited through acquisitions or run by contractors | Outside the corporate inventory; managed by a departing individual | Entire business units’ records | Integration program |
The reconciliation also surfaces the opposite error: jobs backing up systems that were decommissioned years ago, consuming capacity and attention while a live system sits uncovered. Both directions belong in the workpaper. Where the organization has no inventory to reconcile against, the audit should say so as a finding before anything else, because every subsequent test is being performed against a scope that management cannot define.
Recovery objectives: getting the real numbers
Recovery objectives exist in three versions, and the audit has to find all three. The stated version is in the policy or the business impact analysis. The configured version is implied by the backup schedule: a system backed up once nightly has an achievable recovery point of up to 24 hours regardless of what the policy says, and a system with transaction-log backups every fifteen minutes has an achievable point of fifteen minutes plus the time to apply the logs. The demonstrated version comes from restore tests: the actual elapsed time of the last full restore, and the actual data loss measured against the last good copy. The finding is the gap between the versions, and it is usually large. A stated four-hour recovery time with a demonstrated nine hours, or a stated one-hour recovery point with nightly backups only, is a business decision that was never taken.
The auditor gets the stated numbers from the BIA and, where it is stale or absent, from the business owners directly, by asking what happens after one hour, four hours, one day and one week without the system, and how much re-keying a day of lost transactions represents. The configured numbers come from the backup schedules and the copy topology, read system by system. The demonstrated numbers come from the restore log, or from a restore the auditor observes. The table gives typical tiers as a sanity check, not as a standard; a tier that does not match the business’s own answers is wrong for that business however common it is elsewhere.
| Tier | Typical systems | Recovery point | Recovery time | Backup method that can meet it |
|---|---|---|---|---|
| Critical | Core transaction systems, payment platforms, settlement, trading | Minutes to one hour | One to four hours | Continuous replication or transaction-log shipping plus periodic full copies; warm or hot alternate site |
| Essential | ERP, order management, payroll, email | Four to twenty-four hours | Eight to twenty-four hours | Nightly full or incremental with intra-day log backups; documented rebuild at alternate site or cloud |
| Important | Reporting, data warehouse, document management | Twenty-four hours | One to three days | Nightly backups; rebuild from copies |
| Deferrable | Archives, development environments, historical data | Days to a week | One week or more | Weekly copies; long retention |
The restore test is the only test
Everything before this point is design. Operating effectiveness of the domain is demonstrated by one thing: data restored from a backup and shown to be complete, usable and within the objectives. A job log proves that a job ran. A verification flag proves that the backup software could read what it wrote. Neither proves that the database will mount, that the application will start against it, that the configuration matches, that the restore completes within the recovery time, or that the person doing it at three in the morning can follow the runbook. Restore testing exists at four levels, and a mature program performs all four at frequencies that depend on the tier.
| Level | What is restored | What it proves | What it does not prove | Frequency for critical and essential tiers |
|---|---|---|---|---|
| File or object | Individual files, mailboxes, records | The catalog works and copies are readable | Anything about system recovery | Monthly, often exercised by real requests |
| Database | A database restored to a point in time on a separate server | Consistency, log application, achievable recovery point, restore duration | That the application works against it | Quarterly |
| Application | Database plus application servers, configuration and integrations, brought up and exercised | End-to-end recoverability and the real recovery time | Recovery of dependent systems and networks | Semi-annually |
| Site or full disaster recovery | Critical systems recovered at the alternate site or cloud region with users connected | The plan, the people, the sequence and the dependencies | Nothing; this is the full proof | Annually, with a scenario |
The auditor’s strongest procedure is the auditor-selected restore: choose a system and a date from the backup catalog, without notice where the policy allows it, and have the team restore it to an isolated environment while you observe, timing the work and comparing the restored data to production at the chosen point. It is the backup equivalent of counting the cash. It should be done for at least one critical system in every backup audit, and the result recorded on the template below, which is also the template management should be using for its own tests. Every field exists because its absence has been a finding somewhere: a test log that records “successful” with no duration, no data-loss measurement and no issues is a log of tests that were not really performed.
Restore test record. System: ________ Tier: ________ Test type (file / database / application / site): ________ Date: ________ Performed by: ________ Observed by: ________
1. Scope and selection. [Which backup copy was used (date, time, location, media or repository), who selected it, and whether the selection was made without notice.]
2. Target environment. [Where the restore was performed; confirmation that it was isolated from production and, where required, physically and logically segregated from the source system.]
3. Procedure followed. [Runbook reference and version; deviations from the runbook and why.]
4. Timing. [Start time, time data was mounted, time application was available, total elapsed; comparison with the recovery time objective of ________.]
5. Data loss. [Timestamp of the last transaction in the restored data versus the selected recovery point; comparison with the recovery point objective of ________.]
6. Completeness and usability checks. [Record counts or control totals compared with production at the recovery point; application started; key transactions exercised; integrations verified.]
7. Issues encountered. [Every error, workaround and missing item, however small.]
8. Result and actions. [Pass or fail against objectives; actions raised with owners and dates; runbook updates required.]
9. Sign-off. [Performer, observer, system owner, date.]
What ransomware changed: immutability, isolation and the backup server as the target
Until roughly a decade ago the threat model for backups was hardware failure, human error and fire. Ransomware added an adversary who understands backups better than most administrators do, whose first action after gaining privileged access is to find the backup infrastructure and destroy it, and who waits until that is done before encrypting production. The consequence for the audit is that the copy topology and the access model matter as much as the schedule. The three architectural questions are whether at least one copy is immutable or physically disconnected, whether the backup infrastructure can be administered with production credentials, and whether a deletion of backups would be noticed.
Immutability means a copy that cannot be altered or deleted for a defined period by anyone, including administrators, enforced by the storage rather than by permissions: object-lock and vault-lock features in cloud storage, write-once media, or backup appliances with a retention lock. An air gap means a copy on media or a system that is not network-reachable from production, such as rotated tapes held offsite or a backup target that is powered on only for the copy window. The 3-2-1 rule of thumb, three copies on two media types with one offsite, predates ransomware and is necessary but not sufficient; its modern extensions add that one copy must be offline or immutable and that restores must be verified with zero errors. The CISA guide’s observation that some cloud vendors offer immutable storage but that misconfiguration can impose significant cost is a warning to test the configuration rather than the brochure: an object-lock policy in governance mode that a privileged account can override is not immutability.
The backup server is the most common single point of failure. In many mid-sized environments it is joined to the production directory, administered with domain-administrator accounts, and reachable from every workstation. An attacker who captures a domain administrator credential, which is the normal course of a ransomware intrusion, therefore owns the backups before touching production. The controls that address this are separation of identity (backup consoles authenticated independently of the production directory, with multi-factor authentication and no shared accounts), restriction of deletion rights to a very small group with a delay or dual authorization for deletions, alerting on deletion and retention changes, and isolation of the backup network segment. These are privileged access controls applied to a specific target, and they are tested the same way. DORA’s requirement that restoration use systems physically and logically segregated from the source system is the same idea from the other direction: the recovery environment must not be the compromised one.
Two further points belong in any post-2020 backup audit. First, backups of a compromised environment contain the compromise; a recovery plan needs a way to identify the last clean copy, to scan restored systems before they are reconnected, and to rebuild rather than restore where the attacker’s persistence cannot be excluded, which is why recovery is now designed jointly with the incident response function and why the cybersecurity program audit and this one share findings. Second, retention has to be long enough to reach back before the intrusion, which is often measured in weeks or months rather than the days that a snapshot-only strategy provides.
The twelve-test program
The program below is built for a first full audit of the domain; a follow-up audit can drop tests 1 and 2 and lean on the restore work. Populations are systems and jobs rather than transactions, so sampling is usually judgmental, choosing every critical-tier system and a selection of the rest, and the rationale belongs in a documented judgmental selection. Where a population is large enough to sample statistically, the job history for instance, the usual sample sizes apply. The work program guide covers how to lay the program out and the workpaper example how to evidence it.
| # | Test | Population and selection | Evidence | What a failure looks like |
|---|---|---|---|---|
| 1 | Reconcile the system and data inventory to backup jobs in both directions | Full inventory | Inventory, job list, matching workpaper, documented exclusions | Financial file shares, SaaS data or acquired systems with no job; jobs for dead systems |
| 2 | Compare stated recovery objectives with the configured schedule and topology for each critical and essential system | All critical and essential systems | BIA, schedules, replication or log-shipping configuration | Stated RPO shorter than the backup interval; RTO with no alternate processing arrangement |
| 3 | Test job monitoring: failures, alerts and resolution for the period | Full job history; sample 25 failures if numerous | Job logs, alert configuration, tickets, resolution times | Failures unresolved for days; alerts routed to a mailbox nobody reads; jobs silently disabled |
| 4 | Inspect the copy topology for each critical system: number of copies, media, location, immutability or air gap | All critical systems | Backup configuration, object-lock or retention-lock settings, offsite transfer records | All copies online in the same domain; immutability in a mode administrators can override |
| 5 | Test encryption and key custody | All repositories and media types | Encryption settings, key storage, evidence keys are backed up separately and can be recovered | Keys held only on the backup server; nobody can state who could decrypt after a disaster |
| 6 | Review access to backup infrastructure | All accounts with backup console, repository or deletion rights | Access list, authentication method, MFA, deletion alerts, last privileged access review | Domain administrators with full backup rights; shared service account; no deletion alerting |
| 7 | Test retention configuration against the retention schedule and legal holds | All jobs for in-scope systems | Retention settings, schedule, legal hold register, disposal records | Retention shorter than the longest plausible dwell time of an attacker; media never destroyed |
| 8 | Review management’s restore test records for the period | All tests performed; compare with the required frequency per tier | Test records with timing, data loss, issues and actions | Tests recorded as “successful” with no measurements; critical systems never restored at application level |
| 9 | Perform or observe an auditor-selected restore of at least one critical system | Auditor’s choice of system and copy | Completed restore test record; comparison of restored data to production at the recovery point | Restore fails, exceeds RTO, or loses more data than RPO; runbook unusable |
| 10 | Evaluate recovery procedures, roles and alternate arrangements | Runbooks for critical systems; the recovery plan | Runbooks with versions, role assignments, contact lists, alternate site or cloud recovery configuration, exercise records | Runbooks dependent on one individual; alternate site never exercised |
| 11 | Assess the ransomware recovery scenario | The recovery plan and the backup architecture together | Method for identifying the last clean copy, clean-room or isolated recovery environment, scanning before reconnection, coordination with incident response | No concept of a clean copy; recovery would reconnect compromised systems |
| 12 | Confirm reporting to management and the board on backup and recovery status | Reports issued in the period | Metrics: job success, restore tests performed versus required, objectives met, open issues | Reporting limited to job success rates; no restore metrics; audit committee has never seen a recovery result |
Cloud and SaaS: snapshots are not backups and retention is not recovery
Cloud infrastructure has made two comfortable errors common. The first is treating storage snapshots as backups. A snapshot is a point-in-time copy held in the same account, usually the same region, deletable by the same credentials that manage the volume. It protects against a corrupted disk and an accidental deletion; it does not protect against a compromised account, a region-wide event or a malicious administrator. A backup in the cloud sense requires a copy in a separate account or subscription with separate credentials, preferably a separate region, with retention locked, which the major providers offer through their backup services and vault-lock features and which most customers have not switched on. The second error is assuming durability means recoverability. The provider’s durability figure describes how unlikely it is to lose your object; it says nothing about your ability to get back a version you overwrote or deleted last Tuesday, which depends on versioning and retention settings that are the customer’s responsibility under every shared-responsibility model. The cloud audit guide treats the shared responsibility split in full.
SaaS applications shift the question again. The vendor backs up its platform for its own resilience and will restore the whole service after its own failure; it does not, under most contracts, restore an individual customer’s data after the customer’s user deletes or corrupts it, and its recycle-bin or retention window, often measured in days, is not a backup. For SaaS holding financial or operational records the audit asks four things: what the contract commits the vendor to, whether the customer exports or backs up its own data through the vendor’s API or a third-party service, what recovery point that arrangement achieves, and whether anyone has tested a restore into the tenant. Vendors’ SOC reports usually describe their own backup controls; how to read them for what they do and do not cover is the subject of the SOC 1 review method.
Worked example: MidState Beverage restores a settlement database and finds five months of silent failure
MidState Beverage is a three-state drinks distributor with twelve depots, three hundred routes and an ERP whose route-accounting module dates from 2013. Its FY27 audit plan includes a 750-hour engagement on the integration of two acquisitions whose depots still run their own systems, and the six-person function used that engagement to examine backup and recovery across the acquired depots and, because the acquired data was being migrated into it, the core ERP. The analytics and IT auditor led the work with the infrastructure manager as the main contact. MidState’s backup policy, last revised in 2021, states a four-hour recovery time and a one-hour recovery point for the ERP and “daily backups” for everything else.
The inventory reconciliation came first. The corporate inventory listed 31 systems; 27 had backup jobs. The four without were the two acquired depots’ local route-accounting servers, a fleet telematics database and the shared drive where seven depots kept the deposit listings they re-key into the ERP, a practice already reported in the FY27 route cash engagement. One of the acquired depots backed up its server to a portable drive that the depot manager took home weekly; the other had no backup of any kind and was running on a server whose warranty had expired in 2023. The configured recovery point for the ERP, from the schedule, was a nightly full backup with transaction-log backups every fifteen minutes to a separate repository, consistent with the policy on paper.
The auditor-selected restore was of the ERP settlement database, from the copy taken at the close of the previous Wednesday, into an isolated server the infrastructure team built for the purpose. The full backup restored in three hours and ten minutes. The transaction logs did not apply: the log backup job had been failing since a storage array migration five months earlier, its alerts going to a distribution list that had been retired in the same migration, and the backup console showed the nightly job green and the log job in a warning state that nobody had opened. The achievable recovery point was therefore up to 24 hours, not one hour, and had been for five months. Bringing the application up against the restored database, resolving two configuration mismatches and re-pointing the pricing interface took a further five hours and fifty minutes; the demonstrated recovery time was nine hours against a stated four. Record counts and settlement totals for the recovered day matched production once the manual adjustments the finance team had posted that day were excluded, which the team documented as expected.
| Measure | Stated | Configured | Demonstrated | Gap |
|---|---|---|---|---|
| ERP recovery point objective | 1 hour | 15 minutes (log backups) if the log job ran | Up to 24 hours (log job failing for 5 months) | 23 hours; five months undetected |
| ERP recovery time objective | 4 hours | No estimate documented | 9 hours (3h10 restore plus 5h50 application recovery) | 5 hours; runbook incomplete |
| Copies of ERP backups | “Offsite copy” per policy | Two copies, both on repositories joined to the production domain; no immutable or offline copy | Not tested (design failure) | Ransomware would reach both copies |
| Backup console access | Restricted to backup administrators | Domain administrator group (11 accounts) held full rights including deletion; no MFA on the console | Not applicable | Privileged access finding |
| Depot deposit-listing share | Not in policy | No backup job | Not recoverable | Seven depots’ working records unprotected |
| Acquired depot servers | Not in policy | One portable drive taken home weekly; one no backup | Not recoverable within any objective | Integration program finding |
The report carried five findings. Transaction-log backups failing undetected for five months, with the recovery point consequently 24 times the stated objective, was rated High, with the root cause recorded as the retired alert distribution list rather than the job failure itself. No immutable or offline copy of ERP backups, combined with domain-administrator control of the backup console, was rated High as a single finding, because together they meant a ransomware intrusion would destroy every copy. Demonstrated recovery time of nine hours against a stated four was rated Medium, with the recommendation that either the runbook and environment be improved to meet four hours or the business formally accept a longer objective. Systems outside the backup scope, the depot share, telematics and the acquired servers, were rated Medium and assigned to the integration program with a thirty-day date for the two depots. Restore testing not performed at application level for any system in the previous two years was rated Medium. The CAE took the first two to the audit committee with the restore test record attached; the committee asked for the immutable copy to be in place before the FY28 external quality assessment and for a repeat auditor-selected restore in the second quarter, and the resilience engagement already planned for FY28 was expanded to cover the alternate-site question the restore had raised.
Common mistakes
- Auditing the job, not the outcome. A green job history proves the job ran. Only a restore proves the data can come back; perform or observe one.
- Skipping the inventory reconciliation. The systems that are not backed up are the ones nobody classified as systems: shares, spreadsheets, SaaS data, acquired servers, keys.
- Accepting stated recovery objectives. Compare stated, configured and demonstrated values for every critical system and report the gap as a business decision that has not been taken.
- Ignoring the log backups. The nightly full job is the one everyone watches; the intra-day log job is the one that delivers the recovery point, and its failure is the one that goes unnoticed.
- Treating snapshots as backups. Same account, same credentials, same region is a single point of failure, however durable the storage.
- Assuming the SaaS vendor restores your data. Read the contract. Platform resilience is not customer data recovery.
- Not testing immutability. Check the lock mode, the retention period and who can override it. Governance-mode locks that administrators can lift are permissions, not immutability.
- Leaving the backup console on the production directory. If domain administrators can delete backups, the ransomware threat model is unaddressed whatever the copy topology says.
- Accepting “successful” as a test result. A restore test without duration, data-loss measurement, issues and actions is not a test record.
- Stopping at IT. Recovery objectives, scope decisions and the acceptance of a nine-hour outage belong to the business. Write the finding to the owner who has to decide.
Related guides
- Business continuity and organizational resilience
- Auditing cybersecurity programs
- Auditing cloud computing
- IT general controls: the complete primer
- Building the IT audit plan
- How to audit IT change management
- How to audit privileged access
- The IIA Topical Requirements, including cybersecurity
- Control deficiency evaluation
- Root cause analysis for audit findings
- The risk register
- Templates and downloads
- Business Continuity & Resilience guides
Leave a Reply