7 Questions the Board Should Ask Before Signing the Next Storage or Backup Renewal
A backup renewal can look like a simple procurement exercise, until the company has to recover from a ransomware attack.
The failure mode is simple: the audit committee approves a three-year backup renewal, the company later hits a ransomware event, the team restores the newest recovery point, and the workload comes back carrying the encryptor.
Three questions follow: who approved the vendor, what evidence did they review, and why did the contract not require proof that the data inside the backup was clean.
Short answer
Before a storage or backup renewal, the board should ask whether the vendor can prove which recovery points are clean, how fast that proof arrives, what data the inspection covers, and what evidence the company can produce for regulators, insurers, and internal governance.
Key takeaways
- Immutability protects the backup object. It does not inspect the data inside it.
- The SEC cybersecurity disclosure rule, DORA, and NYDFS Part 500.16 raise the evidence bar around recovery governance, testing, and restore capability. A retention SLA is not a substitute for tested recovery.
- Many renewals commit to retention windows, immutability, and restore throughput. Fewer define what evidence proves the restored data is clean.
- The seven questions below are designed to expose where the vendor’s capability ends before the renewal is signed.
Why the renewal is now a board question, not a procurement question
The SEC’s final rule on cybersecurity disclosure requires public registrants to disclose material cybersecurity incidents on Form 8-K within four business days of materiality determination, including the material aspects of the incident’s nature, scope, timing, and impact. DORA requires financial entities to test ICT business continuity plans and ICT response and recovery plans at least yearly for systems supporting all functions, with particular attention to critical or important functions. NYDFS 23 NYCRR Part 500.16 requires covered entities to test their incident response and business continuity and disaster recovery plans and their ability to restore critical data and information systems from backups.
The renewal cycle is the cleanest moment to put that evidence requirement into the contract, while the customer still has negotiating power and the vendor still has to prove fit.
The control the renewal usually skips
Almost every backup vendor now includes immutability features. Immutability prevents a backup object from being changed for a defined period. AWS’s S3 Object Lock documentation describes Object Lock as a write-once-read-many model that can prevent objects from being deleted or overwritten. That protects object state, but it does not claim to inspect the protected object’s contents.
A backup can be immutable, retained, replicated, and still be unsafe to restore. The seven questions below force the vendor to address the part of the recovery contract that the brochure typically does not.
1. Where in the recovery pipeline does the platform actually inspect the contents of the backup?
There is a meaningful gap between metadata anomaly detection and content-level inspection.
Metadata anomaly detection flags entropy changes, file-count deltas, or write-pattern shifts that suggest something is wrong on the storage layer. Content-level inspection opens the protected objects and tests the data inside them against malware indicators, encryption patterns, and integrity checks.
Ask the vendor to draw the architecture on a whiteboard. If the answer is that detection happens entirely through storage-layer metadata signals, the vendor cannot tell the board what is inside the backup. It can only tell the board that the backup looks different from yesterday’s.
NIST Special Publication 800-209, the federal guidance on storage infrastructure security, names data protection and restoration assurance as separate storage-infrastructure security areas. Vendors that conflate the two should be expected to defend the conflation in technical detail, not in marketing terms.
2. What encryption ratios does the detector reliably catch, and what does it miss?
Partial and intermittent encryption are documented ransomware tradecraft. CISA and FBI have described Royal ransomware using partial encryption that lets the actor choose how much of a file to encrypt, and the joint RansomHub advisory documents intermittent encryption that encrypts chunks and skips data between them.
Those techniques create weak spots for detectors that depend on whole-file entropy jumps or full-file hash changes.
Ask the vendor for the smallest encrypted portion of a file that the platform reliably flags, and the detection rate at that threshold. A vendor that cannot answer in numbers is asking the board to take its word for it.
3. How quickly can the platform identify the most recent recovery point that is verifiably clean?
Restore throughput is not the first bottleneck during a real incident. Decision speed is. If the team has thirty days of recovery points and the compromise may predate visible encryption, the binding question is which recovery point predates the bad state.
The operational version of that metric is clean recovery point age: the gap between now and the newest recovery point with evidence that it is safe to restore. Ransomware Recovery Starts With a Provable Clean Recovery Point walks through how that evidence is produced and why most backup contracts do not require it.
Ask the vendor for time-to-identify-clean-recovery-point on a dataset matched to the customer’s production estate. A vendor that quotes restore throughput in TB per hour is answering a different question.
The team that has to use the answer at 3 a.m. is not the team that signed the contract. The contract should answer the 3 a.m. question.
4. How does the platform handle dormant malware inside data files such as Office documents, PDFs, archives, and container images?
Recovery points contain more than operating system images. They contain user data, application data, archives, and container artifacts that may be reopened, imported, mounted, or pulled after restore.
If inspection only covers boot volumes or executable files, it misses content that can carry malware, corrupted state, or unsafe application data into the recovered environment.
Ask whether scanning extends inside non-executable file formats, nested archives, and container layers, with which static and behavioral engines, and on what cadence. A vendor that only inspects boot volumes is leaving part of the recovery surface untested.
5. What isolation discipline applies to the validation environment, and what is the blast radius if it is compromised?
Validation has to run somewhere. Running it on production carries the risk of executing the malware the validation was meant to detect. Running it in a poorly isolated environment carries the risk of giving the attacker a new vantage point.
NIST SP 800-209 names isolation as a distinct storage-infrastructure security area alongside data protection and restoration assurance. The vendor should be able to describe how the validation environment is network-isolated, identity-isolated, and credentialed separately from the production estate.
A common operational failure mode is a validation environment that uses production-domain service accounts. Once those accounts are compromised, the validation environment becomes part of the attack surface, not a check on it.
6. What artifact will the vendor produce for a SEC 8-K, DORA, NYDFS, insurer, or board review?
The answer should not be “a dashboard screenshot.” The useful artifact is a dated record that ties a verdict to a recovery point, shows what was inspected, lists skipped content, identifies the validation environment, and records who approved the recovery point for use.
Our summary of how recovery assurance maps to NYDFS 500.16 and DORA describes the artifact pattern. A companion post on what CISOs must prove about recovery in 2026 walks through DORA-specific recovery evidence expectations.
The SEC Item 1.05 clock is not a backup-control requirement; it is a disclosure deadline. But when recovery teams already have artifact-level clean-point evidence, legal and leadership are not reconstructing recovery status while the clock is running.
Ask the vendor to show a sample evidence packet, not a screenshot of the console.
7. Can the vendor demonstrate clean-state continuity on the customer’s own data for the last 30 days, before the renewal is signed?
Reference datasets and lab demonstrations do not predict performance on the customer’s actual workloads. A platform that catches synthetic encryption on a vendor-supplied corpus may or may not catch a tailored attack on a real customer’s mix of SQL Server dumps, Office documents, application logs, and container images.
A 30-day window is not magic. It is a practical test window long enough to expose stale scans, skipped data types, verdict latency, and environment-specific failure modes.
Ask the vendor to validate the customer’s own backups, in place, over a representative window, and to produce the resulting evidence. Independent recovery-assurance platforms, including Elastio, can run this assessment against an existing backup estate before signature.
The decision the board is actually making
The renewal is not a question about whether the company can take a backup. The renewal is a question about whether the company can prove a clean restore on the worst day of its year.
If the vendor cannot answer in technical specifics, with audit-ready evidence, on the customer’s own data, the board is approving retention, not recovery.
When the next backup renewal lands in the audit committee packet, can the company produce dated, artifact-level evidence that the newest recovery point is safe to restore, on its own data, this quarter?
Bring evidence to the next renewal review
Run a 30-day recovery assessment against your existing backup estate and produce the artifact-level clean-point evidence the board, regulators, and insurers expect.
Sources
[1] AWS, Locking objects with Object Lock, Amazon S3 User Guide.
[2] CISA and FBI, #StopRansomware: Royal Ransomware, Joint Cybersecurity Advisory AA23-061A, 2 March 2023.
[3] CISA, FBI, MS-ISAC, and HHS, #StopRansomware: RansomHub Ransomware, Joint Cybersecurity Advisory AA24-242A, 29 August 2024.
[4] European Union, Regulation (EU) 2022/2554 (Digital Operational Resilience Act), 14 December 2022.
[5] Elastio, Ransomware Recovery Starts With a Provable Clean Recovery Point.
[7] Elastio, DORA: What CISOs Must Prove About Recovery in 2026.
[8] NIST, Special Publication 800-209: Security Guidelines for Storage Infrastructure, October 2020.
[9] NYDFS, Second Amendment to 23 NYCRR 500: Cybersecurity Requirements for Financial Services Companies, November 2023.
[10] SEC, Final Rule: Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure, Release Nos. 33-11216; 34-97989; July 2023.
Can you prove your recovery points are clean?
Your board will ask if you can recover clean. This checklist lets you answer with evidence.
