CC7.5 Incident recovery: requirements and evidence

What CC7.5 incident recovery requires in a SOC 2 examination

CC7.5 requires the organization to identify, develop and carry out activities that recover from security incidents it has already identified. If a SOC 2 examination is underway or planned, the team must be able to show that after an incident, the affected environment was restored, the cause was understood and the same failure is less likely to happen again. Containment alone does not meet this criterion. The risk CC7.5 addresses is an incident that is stopped but leaves systems half-restored, data of unknown integrity, an unexplained root cause, or a weakness that stays in place until the next event. Customers reading the report will ask whether the company can get back to a known good state, and the auditor will look for records that show it.

What makes this hard is that recovery steps often exist only in the heads of a few engineers. Rebuilding a host, rotating credentials, restoring a database to a point before the compromise and confirming that the restored data is clean each involve decisions that someone must document and someone else must be able to repeat. Teams also tend to close the ticket once the service is back, without recording the root cause analysis or the change that followed it. Before fieldwork, confirm who owns recovery for each critical system, where the runbooks are kept, and whether the last incident produced a written record of restoration steps, root cause, and changes to procedures. Ask your auditor which of those records they expect to sample.

Illustrative example: a team that restored a compromised build server from an image but could not show which pipeline secrets had been exposed would struggle to answer the recovery question, even though the service was running again. For self-hosted platforms, a case tool such as DFIR-IRIS can hold the incident timeline, tasks and evidence in one record, which helps show the recovery sequence. Recovery itself depends on backups that can be restored and checked, which is covered in the other sections of this page. Confirm with your auditor how they plan to test CC7.5 for your system boundary and period before you decide how much of the recovery record needs to be automated.

Which systems, data, teams and vendors CC7.5 reaches

CC7.5 recovery is not one activity. Auditors expect the organization to decide, in writing, which production systems, recovery assets, people and outside parties sit inside its recovery work. Those decisions set the boundary of what the examination tests.

Production systems and dependencies

Start with the systems that process or store in-scope data, then map what each one depends on: identity providers, DNS, message queues, secrets stores and the networks between them. A restored application that cannot authenticate users is not recovered. Confirm that the system description lists these components and that each one has a named recovery owner and a documented restoration order.

Backup and recovery infrastructure

Backups and the systems that restore them are in scope for recovery, even when they sit outside the production boundary. Document where backups are stored, how they are isolated from the environment they protect, and who can restore them. Under the availability category, A1.2 and A1.3 add criteria on backup, recovery infrastructure and recovery plan testing, which widens this card considerably.

Teams that run recovery

Recovery depends on people as much as systems. Decide which internal teams restore services, who declares recovery complete, and who backs them up when the primary responder is unavailable. Include on-call engineers, platform staff and any contracted responders. Auditors will ask for evidence that the people named in the plan were assigned, trained and able to act.

Third parties with recovery roles

Hosting providers, managed security services and key software suppliers often perform recovery work the organization relies on. List each party, what it restores or supplies, and the contractual terms that govern response times and data access. Where a provider's own SOC report covers recovery, confirm that its scope matches the services you depend on and that any gaps are handled in your own controls.

Communication scope for confidential and private data

Communicating about an incident is a recovery activity, and its content changes with scope. When confidentiality or privacy is in scope, the messages to customers, regulators and affected individuals must reflect what data was exposed and what obligations apply. Check that the communication plan names the data categories it covers and who approves each external notice before it is sent.

Root cause and recovery testing records

Recovery work ends with evidence: a root cause analysis, the changes made to prevent recurrence, and records of tests of the recovery plan. Decide which systems each test covers and how often the plan is exercised. Keep the test results, the issues they raised and the fixes that followed, because these records show whether the plan works in practice.

How an assessor tests CC7.5 incident recovery

This table sets out how a service auditor typically tests CC7.5 across the examination period, what evidence they request, and where recovery work usually falls short. Read each row as a test step paired with the record the organization must be able to produce. The main takeaway is that an assessor follows individual incidents from restoration through root cause and procedure change, so every link in that chain needs a dated record.

Test approach	Evidence requested	Common findings
Review the defined recovery procedures and their approval	Current recovery procedures, version history, and the record of management approval and the date of last review	Recovery steps exist only in an engineer's head or a wiki page with no owner, approval or revision date
Confirm the procedures cover the affected environment and scope of the system	Mapping of recovery procedures to in-scope systems, data stores and critical services	Procedures cover the primary application but omit databases, identity services, or third-party components in scope
Sample incidents in the examination period and trace each to restoration	Incident tickets, restoration logs, system state before and after recovery, and sign-off that services were returned to normal	Restoration steps happened but were not recorded, so the assessor cannot confirm what was restored or when
Trace sampled incidents to communication records	Internal and customer notices, status page entries, and records of who approved the message and when it was sent	Communication occurred informally by chat or phone with no retained record of content or timing
Trace sampled incidents to root cause analysis	Root cause write-ups, timeline reconstruction, and the review or sign-off of the analysis	Root cause is never recorded, or the write-up names a symptom rather than the underlying cause
Trace root cause findings to corrective change records	Change or ticket records for the corrective action, linked to the originating incident, with completion evidence	Corrective actions are listed in a post-incident document but no tracked change or completion record exists
Review recovery plan tests and their results	Test plans, schedules, test scenarios, dated results, and records of who performed and reviewed each test	Tests happen on an informal basis, or results are captured without a pass, fail or gap determination
Check that test failures and incident lessons were followed up	Action items from tests and incidents, owners, due dates and closure evidence, plus updated procedure versions	Tests identify gaps that are never tracked to closure, and the recovery procedure is unchanged after the test
Check that lessons learned changed the procedures	Revised procedures with dated version history that cite the incident or test that prompted each change	Post-incident reviews recommend changes, but the procedure documents show no revision after the event

Building the recovery activities CC7.5 expects, step by step

This sequence turns CC7.5 from a policy statement into recovery procedures, responsibilities, root cause records, tracked corrective changes and tested plans that an examiner can trace from one incident to the next. Each step ends with an artifact the auditor can sample.

Define recovery procedures for each critical system
Start by listing the systems that support in-scope commitments, then write a recovery procedure for each one. Each procedure names the trigger for recovery, the restoration order, the data sources and backups used, and the conditions under which the affected environment is considered restored. Engineering owns the technical content and the incident response lead approves it. The output is a set of versioned runbooks, one per critical system, stored where responders can reach them during an outage that disrupts normal access.
Assign restoration and communication responsibilities
Map who restores each system and who communicates with customers, internal stakeholders and any other external parties when an incident affects them. Record a primary and a backup for each role, along with the decision-maker who can declare recovery complete. Include how customer notices are drafted and approved, so communication does not wait for ad hoc decisions. The output is a responsibility matrix attached to the recovery runbooks, reviewed after every staffing change.
Link each incident record to a root cause analysis
Every incident that required recovery gets a record in the case management system with fields for affected assets, restoration actions, timestamps and the root cause analysis. Open-source case tools such as DFIR-IRIS keep assets, indicators, tasks and evidence in one case with an audit trail, which makes the link between recovery work and the cause easy to show. The root cause analysis should explain why the failure happened, not only what was restored. The output is a closed incident record that references its analysis document.
Track corrective changes through to closure
Convert each root cause finding into a corrective action with an owner, a description and a status, and track it in the same system as other change work. Link the change record back to the incident so the auditor can follow the path from event to fix. Verify that the change was deployed and that the original condition no longer occurs, then record the closure decision and who approved it. The output is a corrective action register where each item moves from open to verified with evidence attached.
Schedule and run recovery plan tests
Set a test schedule for the recovery plan that covers each critical system and the backup and restore paths the runbooks depend on. Run the tests as written, record what was restored, how long it took against the stated objectives, and where the runbook was wrong or incomplete. For backups, verification tools can help confirm the stored data is usable. Restic's check command, for example, can read pack files back to confirm stored data is unmodified. The output is a dated test report for each exercise with pass, fail and remediation items.
Feed test and incident results into procedure updates
Review each test report and each closed incident against the recovery runbooks and responsibility matrix. Update procedures where a step failed, a contact was out of date or a dependency was missing, and record the version change with a reason. Confirm with the people who will run the procedure that the revised version is the one they will use. The output is a revision history for each runbook that links back to the test or incident that prompted the change, which shows the auditor that the process improves over time.

Evidence that satisfies CC7.5 incident recovery and how to keep it current

CC7.5 is tested by evidence that a recovery plan existed, was used during real incidents and was exercised before the examination period. The artifacts below connect to one another, so an incident that produces a ticket should also produce a root cause analysis, a change record and a review of the procedure.

Documented recovery procedures

Written recovery procedures for each system in scope, covering restoration order, roles, communication contacts and decision points. Keep version history and a named approver for each version, so an assessor can see which procedure was in force during the examination period. After every incident, review the procedure against what actually happened and record the change, even when the change is small. Confirm that the approved version matches the one staff used.

Incident tickets showing restoration

Tickets that record when the affected environment was restored, who authorized the return to service, and when customers, internal stakeholders and any regulators were informed. A ticket that stops at containment does not show recovery. Link each ticket to its alerts, timeline and approvals so the assessor can follow one incident from detection to restoration without reconstructing it from chat logs.

Root cause analyses

Written analyses that explain why the incident happened and why existing controls did not stop it earlier. A useful analysis separates the trigger from the contributing conditions and names the corrective actions with owners and due dates. Review open analyses at each monthly control meeting so that overdue actions are visible before the next examination period begins.

Change records for preventive fixes

Change tickets that implement the corrective actions from root cause analyses, such as new alert rules, hardened configurations or revised access settings. Each record should link back to the incident it addresses and show the approval and testing steps required by the change management process. Without this link, the assessor cannot confirm that lessons learned became changes to the environment.

Recovery plan test reports

Dated reports from tabletop exercises or technical restore tests, listing the scenario, participants, objectives, results and gaps. Record each gap as a tracked action and retest it. Schedule at least one test that falls inside the examination period, and schedule it early enough that remediation of any gap can finish before the period ends. Keep the test report and its follow-up actions together.

Backup restore logs

Logs from restore jobs showing which data was restored, when, from which backup, and whether integrity checks passed. Where backups support recovery, a restore log from a real or test restore is stronger evidence than a backup success report alone. Open-source backup tools such as Bareos keep catalog records of restore jobs, and restic can check that stored data is unmodified, so confirm which of these checks your environment runs and retain their output.

How DFIR-IRIS, Bareos and restic support CC7.5 evidence

DFIR-IRIS is an incident response case management platform licensed under LGPL-3.0-or-later. For CC7.5, its value is that it holds the story of an incident in one place. Each case becomes a single record that links affected assets, indicators of compromise, tasks and evidence items, with an audit trail of who changed what and when. That record is the starting point for showing how the root cause was determined and how the incident was communicated.

Single case record: Assets, indicators of compromise, tasks and evidence sit under one case, so the recovery narrative can be traced to source material.
Consolidated timeline: The platform builds an investigation timeline from case entries, which helps reviewers see when containment, recovery and communication steps happened.
Alert triage: Alerts from SIEM, EDR and REST sources can be triaged into cases, linking detection to recovery activity.
Evidence integrity: Evidence is logged with SHA-256 verification and chain of custody, supporting root cause analysis that must hold up under review.
Generated reports: Reports built from case data can serve as drafts for post-incident communication and lessons learned, subject to review.

Confirm with the vendor documentation how roles, retention and export work in your deployment before relying on it as the system of record. Check that the audit trail meets your retention rules.",

restic is an open-source backup tool licensed under BSD-2-Clause. Its check command verifies the structural consistency of snapshots, trees and pack files. With --read-data or --read-data-subset, it reads pack files back to confirm that the stored backup data has not been modified. For CC7.5, this gives evidence that a backup taken before or during an incident is still usable, which is a precondition for restoring the affected environment.

Structural checks: Running check regularly confirms that snapshots, trees and pack files are internally consistent.
Data read-back: The --read-data option reads all pack files to confirm stored content is unmodified, while --read-data-subset allows a sampled check that fits tighter windows.
Scheduled verification logs: Captured output from scheduled check runs gives the auditor dated evidence of backup integrity.
Restore rehearsal: Restoring a snapshot into a test location after a verify run shows the restore path works end to end.
Repository controls: Repository encryption keys and access should be documented, since the integrity evidence depends on them being protected.

Confirm the check schedule, the subset size and the reporting path against your recovery objectives and your evidence retention policy.

What meeting CC7.5 costs in money and effort

This table compares the cost components of meeting CC7.5 incident recovery, showing who is paid, whether each cost is one-time or recurring, what moves it up or down, and how to keep it contained. No prices or durations are given because none are supplied, so use the rows to structure a quote request and to decide which parts to build in house. The main takeaway is that most of the cost sits in recurring restore testing and case handling, not in the initial write-up.

Cost component	One-time or recurring	What drives it up or down	How to keep it down
Recovery procedure writing and approval	One-time, with upkeep	Number of environments, systems in scope, and how many teams must sign off on recovery steps	Write one procedure per recovery scenario, reuse templates, and tie approval to an existing change process
Backup and recovery tooling or licenses	Recurring	Commercial licensing scales with hosts and data volume; open-source tools shift spend to infrastructure and operations	Choose tools that fit your platform, such as Bareos or restic, and confirm licensing terms before deployment
Infrastructure for backups and recovery environments	Recurring	Storage size, retention period, replication targets and the size of any standby recovery environment	Set retention to what the recovery objectives require and size standby environments to the systems that must return first
Engineering time to run restores and tests	Recurring	Frequency of restore tests, number of systems covered, and how much restoration is manual	Automate restore runs, verification checks and evidence capture so each test produces records without rebuilding the process
Incident case management tooling	Recurring	Alert volume, number of users, and integration work with SIEM and endpoint sources	Use an existing case tool such as DFIR-IRIS and limit integrations to the sources that feed recovery decisions
Root cause and corrective change tracking	Recurring	Number of incidents per year and how many corrective actions must be tracked to closure	Link corrective actions to the change management workflow so each one has an owner, a due date and a closure record
Recovery plan testing effort	Recurring	Test scope (tabletop or technical), number of scenarios, and whether results must be re-tested after fixes	Rotate scenarios across periods, prioritize systems with the highest impact, and record lessons in the same plan
External testing or review by a partner	Optional, recurring if retained	Scope of the review, whether it is a one-off readiness check or ongoing testing, and whether the partner runs live recovery exercises	Ask for a fixed-scope review of recovery procedures and test records before the auditor's fieldwork begins
Auditor sampling effort during fieldwork	Recurring per examination period	Number of incidents or recovery events in the period, and how completely records are kept	Keep incident tickets, restore logs and test records in one place so the auditor can select samples quickly

Who runs CC7.5 recovery, who can help and where the auditor stops

Your organization owns CC7.5. The control is only meaningful if the people who run incidents can recover the affected environment, decide what to communicate, and sign off on root cause and the changes that follow. These decisions cannot be delegated to a vendor or an auditor, and the auditor will look for proof that your own staff made them and acted on them.

Incident command: Name who declares recovery is complete, who can authorize restoring from backup, and who takes over if the primary responder is unavailable.
Communication approval: Decide who approves external statements to customers and who confirms the facts they contain before release.
Root cause sign-off: A named owner accepts the root cause analysis and the list of changes that prevent recurrence, and records that acceptance.
Recovery testing: Schedule recovery plan tests, decide which scenarios to run, and review the results against the plan's objectives.
Procedure ownership: Keep runbooks current after each incident and each test, and retain the versions the auditor will sample.

Before the examination period starts, confirm that these roles are written down, assigned to named people, and that each person has actually exercised at least one part of the process.

Why recovery plan testing decides whether CC7.5 holds up

Writing a recovery plan is easy to do and hard to prove. CC7.5 asks the organization to identify, develop and carry out activities to recover from identified security incidents, and the points of focus include testing the incident recovery plan. An assessor will not accept a plan document on its own. They look for dated tests, a record of what was tested, the results, and the changes that followed from any gap the test exposed. If the plan has never been exercised, or the only record is a signed approval page, there is nothing for the auditor to sample. Before fieldwork, ask your CPA firm exactly what form of test evidence they expect and how they want it labeled and stored.

A test that only checks a restore command proves that one tool can bring back one dataset. It does not prove that the organization can recover. A test that exercises the whole recovery procedure runs the sequence end to end: someone declares the incident, the responders decide what to isolate, the affected environment is rebuilt or restored from backup, the people who hold credentials and approvals take their steps, and the communication path reaches the right internal and external parties. On a self-hosted stack, that often means the DFIR-IRIS case record, the Bareos restore job and the restic integrity check each appear in one scenario, with the handoffs between them written down. Restore jobs that complete successfully can still hide a missing approver or an outdated runbook, so the test should record where people hesitated or improvised.

Because a Type 2 report covers an observation period, one test shows that recovery worked once, and the examiner needs evidence that it was tested across the period. Plan the schedule so that tests recur, that scenarios vary, and that each test produces a dated record with a follow-up item tracked to closure. Confirm with your auditor how many tests and which kinds of scenarios they will sample, and whether they expect a tabletop exercise, a technical restore test, or both. Your recovery procedures also need to reflect the current environment, so changes to backup targets or infrastructure should trigger a review of the plan before the next test.

Where organizations fall short on CC7.5 and how to close each gap

CC7.5 is tested through records as much as through recovery itself. The gaps below tend to appear after a real incident, when the team is busy restoring service and the paperwork falls behind. Each card names the artifact that closes the gap.

Recovery steps undocumented or outdated

Many teams restore systems from memory or from a runbook last edited before the current architecture existed. CC7.5 asks the organization to identify and develop recovery activities, so an assessor will compare the documented procedure with the environment you actually run. Close the gap with a recovery runbook per critical system, with named owners, the restore order, dependencies, and a review date tied to each significant platform change. Confirm the review happens after architecture changes, not only once a year.

Restoration done but not recorded

After an incident, responders often restore services in a chat thread and never write down what was restored, from which backup, and when. An assessor will ask for proof that recovery happened as planned. Close the gap by opening a case record for each incident that logs every restore action, the source snapshot or backup identifier, the operator, and the verification result. Keep the chat excerpts as supporting material, not as the record itself.

Root cause never written down

Teams often close an incident once service returns and skip the question of why it happened. CC7.5 expects root cause to be determined, so a missing analysis is a visible gap. Close it with a root cause section in the incident record that states the cause, the contributing factors, how the cause was confirmed, and who approved the conclusion. Where the cause is unknown after investigation, record that decision and the remaining open questions.

Corrective changes not tracked to closure

A post-incident review may list sensible fixes that then sit in a document with no owner or due date. CC7.5 covers implementing changes to prevent recurrence, so the assessor will follow each corrective action to completion. Close the gap by logging each action as a ticket linked to the incident, with an owner, a target date, the change record that implemented it, and a verification step before closure. Review open actions at a recurring governance meeting.

Recovery plans never tested

A recovery plan that has never been exercised is hard to trust, and a test with no follow-up is worse because it shows a known problem was left open. CC7.5 includes testing the incident recovery plan. Close the gap with a documented test schedule, a scenario for each critical system, a record of what was tested and what failed, and tickets for every finding. Restore test data in an isolated environment and keep the test output, since it is the evidence an assessor will request.

Communication decisions without a record

Decisions about what to tell customers, regulators, or the public during recovery are often made in calls and never documented. CC7.5 includes communicating information about the incident, and an assessor will look for who decided what, when, and on what basis. Close the gap by recording each communication decision in the incident case with the audience, the approver, the timestamp, the content sent, and any notification obligations checked. Confirm contract and regulatory notice periods with counsel before the incident, not during it.

What buyers ask about CC7.5 cost, effort and outside help

How much effort does CC7.5 incident recovery take?

The effort depends mostly on how many systems are in scope, how complex the recovery paths are, and whether recovery procedures already exist in writing. CC7.5 is not a single document. It asks for recovery activities that are identified, developed and carried out, and an assessor will look for evidence that they have been run. Effort tends to rise with the number of production environments, the number of third-party services the platform depends on, and the number of teams that must act during a recovery. A team that already runs incident response under CC7.4 and keeps tested backups usually has a shorter path. Ask any provider to break the estimate into scoping, procedure writing, restore testing, and evidence collection, so you can see which parts drive the total.

Can an in-house team meet CC7.5 without a consultant?

Yes, an in-house team can meet CC7.5 if it has the skills and time to build and test recovery activities. The organization owns its controls, so the work of designing recovery procedures, running restore tests, and keeping records always sits with the organization. What an outside party can add is capacity and experience with recovery testing, not ownership. Check three things before deciding: whether someone can restore a production-like environment from backup and prove the data is intact, whether recovery steps are documented well enough for someone other than the author to follow, and whether the team can produce dated records of each test. If any of these is missing, a fixed-scope engagement may be cheaper than learning under audit pressure.

How long does it take to put recovery procedures and a first test in place?

No researched timeline is available for this, so treat any duration as something to confirm with the provider and your own environment. The schedule usually follows the work in sequence: confirming scope, mapping which systems must be restored and in what order, writing recovery procedures, configuring backup and restore tooling, and running a first recovery test with recorded results. Lead time is often set by access approvals, change windows and the availability of people who understand the production systems, rather than by the writing itself. Ask for a milestone plan with dependencies, and ask what the provider needs from your team in each week of the plan.

What does the work need from engineering and leadership?

Engineering supplies system knowledge and access, and leadership supplies decisions and accountability. Engineers must identify which components hold state, how they depend on each other, and what the correct recovery order is. They also need to run restore tests without disrupting production. Leadership must approve recovery priorities, name who may declare a recovery, and accept the business trade-offs of acceptable downtime and data loss. Both groups should review the recovery plan after each test and sign off on changes. The organization should also name an owner for the plan who will keep it current when systems change, because an outdated plan is an exception waiting to be recorded.

Can the auditor prepare us for the CC7.5 examination?

No. The independent CPA firm performing the SOC 2 examination must remain independent of the organization, so it issues the report but does not design the controls or write the recovery procedures. Whether one firm can also help you prepare depends on independence rules and the firm's policies, so ask the firm directly before engaging it. Separate preparation work, such as building procedures, configuring restore tooling, and running tests, is usually performed by a consultant or implementation partner, and the auditor then tests the results. DeployOpen prepares systems, controls and evidence for assessments but does not issue audit reports or attestations. Confirm the division of roles in writing before work starts.

What should a quote for a fixed-scope CC7.5 engagement include?

A useful quote states what is in scope and what is excluded, so you can compare providers on equal terms. Ask for these items in writing:

The systems, environments and data stores covered by recovery procedures
The deliverables, such as written recovery procedures, restore test scripts, and an evidence checklist
The number and type of recovery tests included, and who runs them
The people you must supply and the access they must grant
Assumptions about existing backups, tooling and documentation
How changes to scope are priced and approved
Which activities recur after delivery and which are one-time

Most fixed-scope engagements are agreed in writing before work begins, so a clear scope protects both sides.

Is ongoing recovery testing needed after the first examination?

Yes, because CC7.5 is about activities that are carried out, and a Type 2 examination tests how controls operated over a period. Recovery procedures change when systems, vendors, staff and data stores change, so a test run once and never repeated soon describes a system that no longer exists. Plan for periodic recovery tests, updates to procedures after each test or significant change, and retained records of results and corrective actions. These activities recur, so budget for them as an operating cost. Ongoing support, upgrades and continuous testing can be contracted as a retainer, and the scope of that retainer should be set in writing like the first engagement.

How DeployOpen works on this

DeployOpen plans, implements and documents the recovery side of CC7.5 inside your own cloud accounts, data centers or air-gapped networks. The organization owns its controls and its incident recovery plan, while an independent CPA firm tests them and issues the report.

How we scope

Written scope names the systems, environments and recovery activities covered under CC7.5 before work starts.
Scope records which recovery steps are in place for restoring the affected environment and who owns each step.
Scope states whether availability criteria A1.2 and A1.3 are in the SOC 2 scope, since they add backup and recovery testing.
Engagements are fixed-scope, with deliverables and timelines agreed in writing, and ongoing support is available as a retainer.

How we build

We configure self-hosted incident case management so each incident keeps assets, indicators, tasks, evidence and an audit trail in one record.
We set up backup and restore jobs with a catalog of backed-up files so recovery points can be selected and documented.
We configure integrity verification of backup data, so restores can be shown to rely on unmodified stored data.
We document the recovery runbook, including root cause review and change tracking that feeds preventive fixes back into procedures.

How we hand over

Handover includes the written recovery procedures, configuration records and the mapping of each CC7.5 point of focus to a system or artifact.
Evidence packages cover restore test records, timelines, case exports and post-incident review minutes, stored with a clear retention schedule.
We walk your team through running a recovery test and collecting its evidence, so the organization can repeat it without us.
Your organization approves the final documentation and retains ownership of the controls, the plan and every resulting record.

How we support

Retainers cover upgrades, backup restore drills, plan updates after platform changes and support during the observation period.
Recovery plan testing can be repeated on a schedule agreed in the retainer, with results added to the evidence set.
Security testing of recovery paths is available, so gaps found in restoration are tracked to remediation.
Confirm with your CPA firm which recovery tests and records it will sample, before the observation period begins.