--- title: "The Distance Between Holding a Backup and Proving a Restore" description: "What decides a backup and disaster recovery review is not the existence of copies but the documented result of a restore drill. Where RTO and RPO commitments cannot be substantiated by the most recent exercise, the arrangement is treated as untested, and technology risk migrates into conditions to closing or into the escrow percentage." url: https://www.beirek.com/en/blog/backup-disaster-recovery-due-diligence canonical: https://www.beirek.com/en/blog/backup-disaster-recovery-due-diligence published: 2026-07-08 modified: 2026-07-08 category: "Technology & Engineering" category_url: https://www.beirek.com/en/blog/category/technology-engineering language: en-US reading_time_minutes: 9 publisher: BEIREK LLC publisher_url: https://www.beirek.com license: "© BEIREK LLC — citation with attribution and link permitted" keywords: ["disaster recovery due diligence","backup and restore testing","RTO and RPO objectives","technology risk in valuation","shared responsibility model","escrow and conditions to closing","key person dependency"] topics: ["Technology due diligence","Business continuity and disaster recovery","Operational risk and valuation adjustment","IT governance and accountability"] alternate_language_url: https://www.beirek.com/tr/blog/backup-disaster-recovery-due-diligence --- # The Distance Between Holding a Backup and Proving a Restore > **In short:** What decides a backup and disaster recovery review is not the existence of copies but the documented result of a restore drill. Where RTO and RPO commitments cannot be substantiated by the most recent exercise, the arrangement is treated as untested, and technology risk migrates into conditions to closing or into the escrow percentage. *Backup and disaster recovery is a capability nearly every company asserts and comparatively few have ever demonstrated through an actual restore. The question posed at the review table is not whether copies are being taken, but by whom, within what interval, and against what evidence a recovery has been repeated.* --- Asked during a technical due diligence session whether backups are in place, the systems administrator will, almost without exception, answer in the affirmative, share a screen, and display a console in which the previous night's jobs have all completed in green — at which point the subject is treated as closed. The room changes character when the next question is put: when, on which system, against which data set was a restore last performed, and how long did it take. What follows is usually a recollection rather than a record — a user deleted a folder some months ago and it was brought back within the day. The distance between retrieving a single folder and bringing a production database, an application tier and an identity infrastructure back up together, in sequence and under time pressure, is wider than that recollection can span. This pattern repeats across nearly every capital-intensive, technology-dependent company, and it repeats for reasons that have little to do with negligence. Backup, once configured, is a self-reporting process: it runs nightly, announces that it has run, and raises an alert when it has not. Restore is the opposite kind of process — it executes only when demanded and emits no signal of its own during an interval that may extend for years. Operating attention gravitates, naturally and at low cost, toward processes that generate signal, leaving those that do not to the domain of assumption; under a constrained engineering budget this allocation is, within limits, a defensible shortcut. The difficulty lies not in the shortcut but in its persistence — data volumes grow, system dependencies multiply, customer commitments harden into contractual uptime language, and the assumption remains exactly where it was first placed. A second mechanism arises from the gap between what backup software counts as success and what the business would count as recovery. For the software, success means that source files have been written to a target in readable form; for the business, success means that operations resume within a tolerable interval and with a tolerable quantity of lost data. The relationship between the two is not linear. An encrypted database may be backed up faithfully while the key material sits inside the same system and never leaves it, rendering the copy unusable; a machine image may be captured in full while licence keys bound to hardware identifiers refuse to activate in the recovery environment; object storage may carry version retention while delete authority is concentrated in a single administrative account, so that a ransomware scenario consumes the primary and the archive together. Dependencies of this kind surface only under an actual restore attempt. What the review table is looking for, accordingly, is not a backup policy document. The existence of a policy is a threshold condition carrying little information on its own, since in most companies the document was drafted for a certification exercise, signed, and left unopened since. What is sought instead is the coincidence of three records: an inventory in which recovery time and data loss objectives are defined system by system and agreed with the business units that absorb the outage; a results report in which those objectives are set against the values actually measured in the most recent drill; and remediation items opened against the deviations that drill produced, each carrying a named owner and a closing date. Where the three exist, the topic closes within hours. Where they do not, the reviewer continues to listen — but is now recording the absence of evidence rather than the substance of the explanation. The measurement dimension deserves particular refinement here, because backup metrics degrade into reassurance more readily than most. A ninety-nine percent job success rate excludes nothing about whether the single critical system sits inside the failing one percent; a mean restore time conceals the restore time of the largest data set, which is invariably the one that matters in a genuine outage. Measurement that carries weight is stratified by system criticality, shows how the backup window lengthens as workload grows — the leading indicator of a window that will eventually fail to close — and reports the coverage ratio of verification testing, meaning tests establishing not merely that a copy was written but that it is readable and internally consistent. A dashboard assembled without these distinctions does not give a board assurance; it produces the sensation of assurance, which is a different and considerably more expensive thing. Ownership is the dimension that connects most directly to valuation. Responsibility for backup and disaster recovery is typically distributed not by written job description but by accumulated familiarity: whoever built the system becomes the only person capable of resurrecting it. The arrangement functions perfectly well for as long as that person remains, which is precisely why the reviewing party asks whether the capability is separable from the individual — what is being acquired is an institutional capacity, not one engineer's memory. The continuity test applied at the table is simple and applied often: can the recovery procedure be executed by a technical employee who never built the system, working from the documentation alone, without telephoning anyone. Where the answer is no, the technology risk item enters pricing through the same channel as founder dependency — broader representations and warranties, an added condition precedent, or an escrow percentage revised upward. The mechanics of that pricing rarely present as an explicit reduction in headline value, which is why sellers tend to underweight it. What appears at the contract table takes one of two shapes. In the first, the buyer makes an independently witnessed restore drill a condition to closing and requires the result to be shared; the drill adds weeks to the timetable, and every week of delay erodes the seller's negotiating position, particularly where financing commitments or key-employee retention arrangements are running clocks of their own. In the second, the buyer releases the condition and asks in exchange for a specific indemnity covering data loss and business interruption; where that indemnity carries no cap, or extends the escrow period beyond the general survival window, a portion of the seller's consideration remains suspended for an indeterminate interval. In both configurations the cost exceeds the cost of the drill by an order of magnitude. Reliance on cloud platforms and managed services does not simplify this picture; it relocates the boundary of responsibility to a place where it is harder to see. The durability commitment a provider makes at the infrastructure layer and the obligation the customer retains at the data layer are distinct undertakings resting on distinct contractual language. Restoring records that a user deleted in error, or that an integration corrupted at the application level, generally falls outside a standard subscription altogether, or is offered only within a narrow window and only as a tenant-wide rollback that overwrites correct data alongside incorrect. Where that boundary sits in the agreement, which event categories the service level commitment actually covers, and whether the stipulated remedy is a service credit bearing no relation to realised loss, are clauses read individually in review. Given the standard architecture of provider agreements, data-layer recovery obligation most probably remains with the customer. Intervention in this area begins not with drafting a new policy but with reconstructing the existing arrangement so that it generates evidence. The first step is to tier the system inventory by business criticality and to fix, for each tier, recovery time and data loss objectives agreed not with the engineering team but with the business unit that actually absorbs the consequence of the outage; until that agreement is reduced to writing, the objectives remain a technical preference and cannot be defended in a negotiation. The second step is to establish a drill calendar: a full-scope exercise at least annually and partial restores of selected systems each quarter, executed on each occasion by a different member of staff working from the documentation alone. The third is to bind each drill to a standard one-page record — target value, measured value, deviation, cause of deviation, remediation item, owner, closing date. The principal function of that record is institutional rather than technical. An investment committee, or the technical adviser retained by a buyer, reading four drill records laid side by side across twelve months, is reading more than a recovery capability: it is reading the company's discipline in measuring and closing its own weaknesses. A series in which the deviation between target and measured value narrows over time is a stronger signal of management quality than any policy document, because it evidences a feedback loop operating without external compulsion. The converse inference is equally available. Where no such record has ever been kept, the same reader reasonably concludes that comparable verification gaps may exist across the technology function as a whole, and the scope of the review widens accordingly — scope expansion being charged to the seller's account twice, once in calendar time and once in adviser fees. The intervention on the ownership side concerns the consolidation of accountability rather than the distribution of authority. A single named owner is designated for disaster recovery, but that owner's mandate is not to perform the recovery; it is to demonstrate, at regular intervals, that the recovery can be performed without them, which is what the rule requiring a different operator at each drill exists to establish. Break-glass credentials, password vault recovery keys and administrative access to provider accounts are placed under a separate custody arrangement with dual control, since access concentrated in one person leaves the structure technically sound and institutionally fragile at the same time. Whether that arrangement functions is itself tested annually through an access drill, on the reasoning that an emergency credential nobody has retrieved in eighteen months is indistinguishable, at the moment it is needed, from one that was never provisioned. What the reviewing party is looking for in this area, in the end, is not a statement of assurance but a demonstration of repeatability, and that demonstration is produced only in the moments a company deliberately halts its own systems, brings them back, and writes down what happened while it was doing so. Backup earns confidence cheaply, reporting every night that it has worked; disaster recovery begins to earn confidence only once it has been tested, and holds that confidence only for as long as the test remains recent. Were the maturity of a technology function to be assessed through a single question, the question would not concern which tools are deployed or which provider holds the archive, but when the last restore was performed and whose hands performed it. ## Key Points - A log confirming that a backup job completed successfully establishes nothing about whether a restore will work; the two processes must generate evidence separately and on their own terms. - Recovery time and data loss objectives carry no weight in a negotiation unless they are numbers the business units have accepted and the most recent drill has verified. - Where disaster recovery ownership rests with a single systems administrator, the item enters pricing through the same channel as founder dependency — broader warranties, added conditions precedent, or a higher escrow percentage. - A recovery plan that has never been exercised operates, in the first genuine incident, not as a plan but as improvisation, and the resulting outage duration becomes unforecastable. - In SaaS and managed service arrangements, where the responsibility boundary is not fixed in the contract, data-layer loss risk in practice remains with the customer. ## Questions ### What is the difference between backup and disaster recovery? Backup is the process of copying data to a separate medium, and it reports its own result each time it runs. Disaster recovery is the restoration of systems, data and access together following an interruption, and its scope extends beyond data to the application tier, identity infrastructure, encryption key material and licensing. The existence of a copy does not establish that recovery is possible; only a completed restore test establishes that. ### Which documents does an investor request for disaster recovery during due diligence? Three records are typically requested: an inventory tiering systems by business criticality with recovery time and data loss objectives defined for each tier; a results report from the most recent restore drill comparing target values against measured values; and remediation items opened against the deviations that drill produced, each carrying a named owner and a closing date. A policy document standing alone is not treated as verifiable evidence. ### How frequently should a disaster recovery drill be conducted? Common practice is a full-scope exercise covering critical systems at least annually, supplemented by partial restore tests on selected systems each quarter. More decisive than frequency is the condition that each drill be executed by a different member of staff, working from the documentation alone and without informal assistance. That condition is the only practical test demonstrating that the capability is separable from any particular individual. ### If we use cloud services, does backup responsibility still rest with us? A provider's commitment is generally confined to infrastructure durability. Customer-initiated deletion, erroneous data entry and application-level corruption fall outside most standard service scopes, or are addressed only within a narrow window and as a tenant-wide rollback. Where the responsibility boundary sits should be read from the service agreement itself, together with whether the stipulated remedy for breach is limited to a service credit bearing no relation to realised loss. --- Source: https://www.beirek.com/en/blog/backup-disaster-recovery-due-diligence Publisher: BEIREK LLC — https://www.beirek.com