CC9.1 Business disruption risk mitigation: requirements and evidence

What CC9.1 asks for before a SOC 2 auditor arrives

CC9.1 asks the organization to identify, select and develop activities that mitigate risks arising from potential business disruptions. In practice, the auditor will want to see that you listed the disruptions that could stop your service, chose responses to them, and built those responses into working activities before the examination period begins. The criterion is about the decision-making chain, not only about whether a continuity document exists. Its points of focus ask you to consider mitigating business disruption risks and to consider insurance as a way to offset financial impact, so the evidence should show both operational and financial choices. CC9.1 is easy to confuse with two neighboring areas. CC9.2 covers risks that come from vendors and business partners, such as a hosting provider failing. CC9.1 covers disruptions that originate inside your own environment or from events you must plan for, such as a failed deployment, loss of a key engineer, or a regional outage. The availability criteria A1.2 and A1.3 add detail on backup and recovery infrastructure and recovery plan testing, but only when availability is in scope. If you have not included availability, you still need CC9.1 evidence, and that evidence should not depend on the A1 criteria.

The criterion is hard for two reasons. First, the risks are scattered. Engineering owns deployment and data stores, operations owns on-call and capacity, finance or leadership decides on insurance, and no single person sees the whole picture. Second, continuity plans often exist as documents that nobody has used. An auditor will ask when the plan was last reviewed, who approved the risk selections, and what happened the last time something went wrong. Before the auditor arrives, confirm who owns the disruption risk register, that each mitigation has a named owner and a status, and that you can produce records of a review, a test, or a real incident. Confirm also with your broker what insurance you carry and whether its coverage matches the risks in your register, since the auditor will test the stated rationale rather than the policy alone.

Which systems, teams and third parties does CC9.1 cover?

CC9.1 is judged against the business disruptions your system description says you can suffer, so scope starts with what the service actually depends on. The decisions below determine which risks you must mitigate, which criteria apply, and how much evidence the examination will ask for.

Production systems in the system description

The system description defines the boundary of the examination, and CC9.1 mitigations must cover disruptions to the components inside that boundary. List production applications, databases, message queues, identity services and monitoring tools that customers rely on. Check that every component named in the description has a documented disruption scenario, and that components left out of the boundary are not quietly required to deliver the service. A component missing from the description is often where an assessor finds an unmitigated risk.

Business functions that depend on those systems

A disruption matters to the business through the functions it stops, such as customer onboarding, billing, support, or payment processing. Map each function to the systems it needs and to the people who run it. Ask which functions customers would notice first and how long each could stop before contracts or obligations are breached. Those answers set the priority order for continuity planning and for the recovery targets your team commits to.

Facilities and cloud regions

Single-region deployments, a single data center, or one office where administrators work all create concentrated risk. Record where production runs, where backups are stored, and which facilities or regions could fail together. Confirm whether backups sit in a separate location from production and whether your team can operate the platform if a primary site or region is unavailable. For self-hosted platforms, the same questions apply to your own data centers and air-gapped networks.

Whether availability is in scope

Availability is an optional category. If it is not in scope, CC9.1 still requires disruption mitigation, but the detailed recovery criteria A1.2 (backup and recovery infrastructure) and A1.3 (recovery plan testing) do not apply. If availability is in scope, both criteria apply and the examination will expect backup design, restore records and test results. Confirm this decision with your auditor before you write the system description, because it changes the evidence list more than any other scoping choice.

Insurance as a scoping decision

CC9.1 points of focus include considering insurance to offset the financial impact of disruption. Decide whether cyber, business interruption or technology errors and omissions cover is part of your mitigation strategy, and record the decision and its basis. Insurance does not replace operational controls, and an auditor will look for the reasoning behind coverage levels and for evidence that policies are current. Ask your broker which losses each policy excludes and whether the coverage matches the functions identified above.

Third parties whose outages stop you

Cloud providers, hosting partners, payment processors and managed service providers can interrupt your service even when your own systems are healthy. List each third party that supports an in-scope system, and note which ones have their own SOC reports or contractual recovery commitments. Confirm how you learn about their outages and who decides whether to fail over. These dependencies connect CC9.1 to the vendor risk work in CC9.2, so record them once and reference them in both places.

How an assessor tests risk mitigation for disruption

This table compares what an assessor examines for CC9.1, the evidence requested for each step, and the findings that usually appear. Read it as a checklist of what to have ready before fieldwork, since gaps in ownership or linkage to risks are the most common reasons a control is written up.

Test area	What the assessor does	Evidence requested	Common finding
Disruption risk assessment	Confirms the risk assessment considers business disruption scenarios such as cloud region outage, loss of a key vendor, ransomware or staff unavailability	Risk register entries for disruption scenarios, dated assessment records, reviewer sign-off	Risk assessment covers security threats only and omits operational or vendor disruption
Selected mitigations	Traces each disruption risk to a chosen mitigation and checks the mitigation addresses that risk	Mitigation register linking risk ID to control, backup job, failover design or continuity plan	Mitigations listed with no link to any identified risk
Ownership	Checks a named owner is accountable for each mitigation and that the owner has the authority and skills to act	Owner field in the register, role descriptions, meeting or approval records	Mitigations listed with no owner or with a shared team name only
Insurance decision	Reviews whether the organization considered insurance for financial impact and recorded why it was or was not used	Decision memo, board or management minutes, current policy schedules and coverage limits	No documented decision, or the decision was made but the policy is not on file
Implementation in place	For Type 2, tests whether mitigations such as backups, failover or continuity exercises operated across the whole observation period	Backup job logs, restore test records, exercise reports dated across the period, change tickets for any design changes	Mitigation documented but evidence stops partway through the period or was not produced for every sample
Review and update	Checks that the risk assessment and mitigations are reviewed on a defined schedule and after significant changes	Review records, change-driven updates, lessons from incidents or tests	Reviews happen only informally, so the register no longer matches the current architecture

Implementing CC9.1 step by step

The sequence below moves from the system description to a recorded decision on each disruption risk, so that an auditor can trace every mitigation back to a scenario the organization identified, ranked and owned. Each step leaves a document or record that the examination can sample.

Define the system boundary and dependencies
Start from the system description the organization has written for the SOC 2 examination. List the services, data stores, cloud accounts, network paths, third-party platforms and people that the in-scope system depends on to deliver its commitments. Name an owner for each component. The step is complete when the dependency list matches the system description and every component has a named owner. The auditor will compare the two documents, so any gap between them will surface during fieldwork.
Identify disruption scenarios for each dependency
For each dependency, write the ways it could stop or degrade the service. Examples include loss of a data center or cloud region, failure of a database cluster, compromise of a key administrator account, loss of a key engineer, outage at a critical vendor and corruption of backup data. Involve operations, engineering, security and finance so that scenarios reflect how the business actually runs. The output is a scenario register with one line per scenario, its affected dependency and its owner.
Assess and rank each scenario
Rate each scenario for likelihood and impact on the commitments in the system description, using the same scale the organization applies in its risk assessment under CC3. Record the rationale for each rating, including the data or incident history used. Rank the scenarios and set a threshold above which a mitigation is required. The output is a ranked risk register that a reviewer can challenge, and the ratings become the basis for the mitigation decisions in the next steps.
Select mitigations for each ranked risk
For each scenario above the threshold, choose one or more mitigations. Options include redundant infrastructure across failure domains, tested backups, failover procedures, cross-trained staff and documented delegation of authority, and alternative vendors or exit plans for critical third parties. Record why each option was chosen and what it does not cover. A mitigation that exists only on paper should be marked as such. The output is a mitigation selection record that links each scenario to its chosen controls.
Develop and assign the mitigation activities
Turn each selected mitigation into a concrete activity with an owner, a description of the work and the evidence it will produce. For backup and recovery work, this usually means defining what is backed up, how restores are verified and where recovery procedures are kept. Where a mitigation depends on a third party, record that dependency and the controls the organization relies on from that party. The output is a mitigation plan with owners and evidence expectations, which feeds the control matrix used in the examination.
Decide on insurance for residual financial impact
After the technical and operational mitigations are set, review the financial impact that remains for scenarios that could still disrupt the business. CC9.1 points organizations to consider insurance as a way to offset that impact. Finance, legal and the risk owner should document whether insurance is used, what it covers, which scenarios it does not cover and the review date for the policy. Confirm the coverage details with the insurer or broker, because policy terms vary and this page does not describe any specific product. The output is a recorded decision with its rationale, whether the answer is to insure or to accept the residual risk.
Record the decisions and approve the plan
Bring the ranked register, the mitigation plan and the insurance decision together in one approved record. Management with authority over the risk should sign off on the accepted residual risks and the threshold used. Keep prior versions so the auditor can see how the plan changed over the observation period. The step is complete when the approval is dated, every ranked scenario above the threshold maps to a mitigation or an accepted risk, and the record is stored where the auditor can request it.
Review the plan and test the recovery activities
Set a recurring review of the scenario register and mitigation plan, and trigger an extra review after material changes to the system, a major incident or a change in a critical vendor. Where availability is in scope, the recovery and backup activities should be tested as described in A1.2 and A1.3. Keep the test results, any corrective actions and the updated plan. The review record is what shows the mitigation process operating over time, which matters most for a Type 2 report.

How the risk register, continuity plan and recovery tests fit together

CC9.1 asks the organization to identify, select and develop activities that mitigate risks arising from potential business disruptions. A reviewer tests this as a chain rather than as three separate documents. The disruption risk register is the starting point: it lists the events that could interrupt the service (a cloud region failure, loss of a key supplier, ransomware on the backup host, loss of staff who run the platform) with an owner, an impact statement and a likelihood judgment. Each entry should then point to the mitigations chosen for it, such as a secondary region, a documented manual workaround, an insurance decision or an accepted residual risk. Where the organization decides not to mitigate a risk, the register should record who accepted it and why. The reviewer expects to see that the selection followed from the register and was not written afterward to fit existing controls.

The continuity plan is where those mitigations become procedures. For each mitigated risk, the reviewer looks for recovery objectives set by the business, the roles that act during an outage, the order of recovery steps and the communication path to customers. Insurance belongs in the same chain: the register should say which financial impacts are transferred to a policy, and the organization should confirm with its broker which losses that policy actually covers. If availability is in scope, A1.2 and A1.3 connect the chain to evidence. Backup and recovery infrastructure must be shown to work, and recovery plan testing must be run and its results recorded. Open-source tools can produce some of that evidence. Bareos keeps a catalog of backup, restore and verify jobs, and restic's check command with --read-data-subset can confirm that stored backup data is unmodified. Confirm with your own environment which job logs, restore reports and test records your auditor will sample.

For an illustrative example, suppose the register lists loss of the primary database host as a high-impact risk, the selected mitigation is restore to a standby environment, and the continuity plan assigns the restore to a named engineer. The trace a reviewer wants is the register entry, the plan step, a recent restore test with its date, the result and any corrective action, and the scheduled verification job that shows the backup was readable. Gaps are usually found in the links: a restore test that exercised a different system than the one in the register, or a plan that names a role nobody holds. Before the audit period starts, walk one risk through every link yourself and fix any break in the chain.

Which evidence passes a CC9.1 review

An auditor testing CC9.1 looks for a chain of records: a disruption risk assessment, mitigation decisions with named owners, recovery plans, proof that backups and drills happened, and documented insurance choices. Each artifact should be dated, approved by someone accountable, and refreshed on a schedule so the sample drawn during the observation period reflects how the business actually operated.

Disruption risk assessment

A register of the events that could interrupt the service, such as loss of a data center, a failed cloud region, a key vendor outage, ransomware, or the departure of a person who holds critical knowledge. Each entry records likelihood, impact on customers, and the owner who accepted or treated the risk. Check that the register links to the broader CC3 risk assessment rather than standing alone. Review it at least annually and after any material change in hosting or dependencies.

Selected mitigation list with owners

The decisions taken from the risk assessment, each with a named owner, a target state, and a status. Typical entries include a second availability zone, offline copies of backups, a standby runbook for a single engineer, or a supplier contract with recovery terms. An auditor will ask why a risk was accepted without mitigation, so record that reasoning and the approver. Keep the list in the same tracker used for other control remediation so changes are traceable.

Continuity and recovery plans

Written plans that state who declares a disruption, which systems come back first, what the recovery time and recovery point targets are, and how staff communicate with customers. Plans should name the infrastructure they depend on, including self-hosted platforms, cloud accounts and network paths. Confirm that the version in use is the one approved, that contact details are current, and that each plan was reviewed after the last significant architecture change.

Backup job and restore records

Job logs showing scheduled backups completed, catalog entries that identify what was backed up and when, and restore tests that recovered data to a separate environment. Open-source tools such as Bareos keep a catalog of backed-up files and can restore from a chosen backup or one before a given date and time, while restic can read pack files back to confirm stored data is unmodified. Keep failure alerts and their resolutions, because a reviewer will check exceptions as closely as successes.

Drill and tabletop results

Records of exercises that tested the recovery plans, including the scenario, participants, timings, what failed, and the corrective actions opened afterward. A tabletop discussion alone is weaker evidence than a restore or failover that was executed and measured. Where availability is in scope, the recovery plan testing criterion (A1.3) adds detail on what must be tested. Schedule exercises across the observation period so the auditor can see more than one event.

Insurance decision records and coverage summaries

The record of whether business interruption and cyber insurance were considered as a way to offset financial impact, the reasoning behind the coverage chosen, and the current policy summary with limits and exclusions. CC9.1 asks whether insurance was considered, not that it was bought, so a documented decision not to insure is acceptable if reasoned. Ask the broker or insurer to confirm the policy period and sign off on the summary, and record the renewal date so it does not lapse unnoticed.

What meeting CC9.1 costs in money and effort

This table breaks down the cost components of CC9.1 by who is paid, whether the cost is one-time or recurring, and what drives it up or down. Use it to build a quote request and to separate license spend from the engineering effort that self-hosted open-source platforms still require. No figures are stated because none were supplied; ask each provider for written pricing against your own scope.

Cost component	Who is paid or who carries it	One-time or recurring	What drives the cost
Tooling or licenses	Software vendors, or no license fee for open-source components	Recurring for commercial tools, usually none for open-source licenses	Number of systems in scope, support tier, and whether backup or GRC tools are commercial
Engineering time for redundancy and backups	Internal platform or infrastructure team, or an implementation partner under a fixed-scope agreement	One-time build, then recurring upkeep	Architecture complexity, recovery objectives the organization sets, and number of data stores
Risk workshops and business impact analysis	Internal risk owners, operations leads, and any facilitator you hire	Recurring at each review cycle	Number of business processes, dependencies, and how many teams must attend
Continuity plan drafting and external review	Internal staff, consultants, or an independent reviewer	One-time drafting, recurring review	Plan depth, how often plans change, and whether reviewers must be independent of the team
Recovery drill execution	Internal engineers and business owners, plus any external facilitator	Recurring	Scope of each drill, test environment availability, and how much production impact is allowed
Evidence upkeep	Internal compliance or operations staff	Recurring	Frequency of backup job logs, restore test records, and plan approvals the assessor will sample
Auditor sampling and fieldwork	The CPA firm that performs the examination	Recurring each examination period	Sample sizes the auditor selects, number of drills in the period, and quality of prepared evidence
Insurance premiums	Insurance carrier, through the organization's broker	Recurring at each policy term	Organization size, claims history, coverage limits, and the business interruption exposure the carrier assesses

Who owns CC9.1 and what to outsource

Your organization owns CC9.1. That means deciding which business disruptions matter, which mitigations to fund, how much financial exposure to accept, and whether insurance is part of the answer. These are management decisions, and they must be documented as such. An auditor will ask who approved the risk assessment, who accepted residual risk, and when the continuity plan was last reviewed and by whom. An implementation partner cannot answer those questions on your behalf.

Risk decisions: Management selects which disruption scenarios to plan for, such as cloud region loss, ransomware, loss of a key supplier or staff unavailability, and records the reasoning.
Mitigation funding: Your leadership approves budgets for redundancy, backup storage and recovery exercises, and signs off on any scenario left unmitigated.
Insurance decisions: Management decides whether business interruption or cyber cover is needed, what limits apply, and whether the policy matches the scenarios in the plan. Confirm the coverage terms with your broker and counsel.
Plan ownership: Name an accountable owner for the continuity plan and for each recovery procedure, with a deputy.
Review cadence: Set and record how often the plan is reviewed after material changes to systems, vendors or the business.

Ask your auditor early which of these records they will request, and keep them in one place.

Where CC9.1 evidence usually breaks down

Auditors testing CC9.1 rarely fail a company for having no continuity plan. They more often find a plan that was never exercised, a risk register that does not connect to anything, or insurance and backup decisions with no record behind them. The gaps below share one root cause: the mitigation exists on paper but cannot be shown to work or to have an accountable owner.

Continuity plans never tested

A continuity or disaster recovery plan that has never been exercised gives an assessor nothing to sample. CC9.1 asks whether the activities you selected would actually reduce disruption, and a plan with no test record cannot answer that. Where availability is in scope, A1.3 asks specifically about testing recovery plans. Check that each plan names the scenarios it covers, that tabletop or live exercises are dated and minuted, and that the findings from each exercise led to changes in the plan. Confirm the test cadence with your auditor before the observation period starts.

Risk register disconnected from mitigations

Many organizations maintain a risk register for CC3 and a separate list of controls for CC5, and nobody links the two. CC9.1 asks you to identify and select the activities that mitigate business disruption risk, so an assessor will trace a disruption risk to a named mitigation and then to evidence that it operates. A risk with no mitigation, or a control that protects against no recorded risk, is a visible gap. Pick the top disruption risks, map each to a control or recovery activity, and keep the link current when either side changes.

Insurance decisions left undocumented

The points of focus for CC9.1 include considering insurance to offset financial impact. Organizations often hold cyber or business interruption cover without recording why a limit was chosen, what it excludes or who reviewed it. An assessor may ask how management decided whether to insure a risk, retain it or accept it. Keep a short memo per decision that states the financial exposure considered, the policy in force, its review date and the approver. Ask your broker to confirm exclusions for outages at your hosting provider, since those often matter most for self-hosted platforms.

Backups never restored

A backup job showing success does not prove that data can be recovered. Auditors look for restore tests, not just backup logs, and for evidence that the restored data was complete and usable. Open-source tools can help here: Bareos keeps a catalog of backed-up files and restores files from a chosen backup, and restic's check command can read pack files back to confirm stored data is unmodified. Record each restore test with its date, scope, the person who ran it and the result, and keep failed restores in the record with the fix that followed.

Mitigations with no named owner

A mitigation that no one is accountable for tends to lapse after the first quarter. Assessors commonly ask who approves the continuity plan, who maintains the backup schedule and who decides whether a risk is accepted. Each mitigation should name one accountable owner, a backup owner for absences, and a review date. Evidence of ownership is usually a role assignment in the policy or the control matrix, plus sign-off records showing the owner reviewed the mitigation during the period under examination.

What buyers ask about CC9.1 before hiring help

How much effort does CC9.1 take to satisfy?

CC9.1 asks the organization to identify the business disruptions that could affect its service, choose mitigation activities for them, and develop those activities into working plans. The effort depends on how many services, locations and dependencies are in scope, how much continuity planning already exists, and whether the organization has already run a risk assessment under CC3. A small single-product company with one cloud account usually has less to document than a multi-region provider with several critical vendors. Ask any partner to break the effort into risk identification, plan writing, testing and evidence collection, and to state which of those steps recur each year.

Can our own team handle CC9.1 without outside help?

Often yes, if someone owns risk and continuity decisions and has time to write and test the plans. Internal teams usually struggle with three things: getting leadership to agree on acceptable downtime, running a real recovery test instead of describing one, and keeping plans current after infrastructure changes. Outside help is most useful for a neutral review of the risk analysis, for building backup and recovery tooling, and for preparing test records the auditor can sample. Decide early which parts your team keeps, since the organization always owns its controls.

How long does it take to be ready for a CC9.1 review?

There is no fixed duration in the sources, so the answer depends on what exists today. An organization with a current risk register, documented backups and at least one recovery exercise on record has far less to build than one starting from nothing. The main drivers are the number of critical services, how quickly leadership can approve recovery targets, whether backup systems need to be built or only reviewed, and how long a recovery test takes to schedule and execute. Ask a prospective partner for a written readiness assessment and a timeline tied to your named deliverables before you commit.

Is insurance required to meet CC9.1?

No. The criterion asks the organization to consider the use of insurance to mitigate financial impact from business disruption, which is a point of focus, not a mandated product. Insurance does not replace continuity planning, since it offsets financial loss but does not restore service. If you carry cyber or business interruption cover, document how it was considered, what it covers and what it excludes. If you do not carry it, record the reasoning behind that decision so an auditor can see the risk was assessed. Confirm the terms with your broker and legal counsel rather than relying on general descriptions.

What does a partner need from us to start?

A partner needs access to the people and systems that define the service: a list of in-scope products, cloud accounts or data centers, critical vendors, current backup configurations, existing continuity or disaster recovery documents, and the owners of each. They also need a decision-maker who can approve recovery objectives and accept residual risk. Expect to provide recent incident and outage records, since they show how disruptions have actually been handled. Agree on a written scope and a list of deliverables before fieldwork begins, so both sides know what evidence will be produced.

What backup tools can support CC9.1 evidence when we self-host?

Open-source tools can produce the records that show backups run and can be restored. Bareos schedules and supervises backup, restore, verify and archive jobs and keeps a SQL catalog of backed-up files, which gives you job history and restore records. restic's check command verifies the structural consistency of snapshots, trees and pack files, and with --read-data or --read-data-subset reads pack files back to confirm stored data is unmodified. Confirm each tool's current version, licensing and supported storage targets in your environment before adopting it, and remember that the tool produces evidence but the recovery plan and test results still need your own documentation.

Can the partner that prepares us also issue the SOC 2 report?

No. A partner such as DeployOpen prepares systems, controls and evidence for an assessment, but only an independent CPA firm can examine the controls and issue a SOC 2 report. The organization owns its controls and its management assertion, and the auditor forms the opinion. For that reason, avoid any arrangement where the preparing party also performs the examination, since that undermines independence. Ask your preparation partner to document what they did and did not do, and confirm the CPA firm's engagement letter before fieldwork starts.

How DeployOpen prepares CC9.1 evidence

DeployOpen starts every CC9.1 engagement with a written scope that names the business disruption scenarios in view, the systems whose recovery matters most, the backup and recovery components to be deployed in the client's own cloud accounts, data centers or air-gapped networks, and the deliverables and dates both parties accept. The client's risk owners approve that scope before work begins. From there, DeployOpen configures the open-source backup tooling the client has chosen. For example, a Bareos Director can be set up to schedule backup, restore, verify and archive jobs and keep its SQL catalog, while restic repositories can be configured with scheduled restic check runs, including --read-data-subset checks that read pack files back to confirm stored data is unmodified. Each job, schedule and retention setting is documented so an assessor can trace it to the control description.

Evidence is assembled from what those systems actually produce: job schedules and configuration files, catalog and repository records of completed backups, restore test logs, and the results of verification runs. Where availability is in scope, DeployOpen organizes this material against the backup and recovery and recovery plan testing criteria, so the client can show the auditor how recovery was designed and how it was exercised. Confirm with your auditor which periods of operating evidence they will sample and whether they expect exercises to be run on a set cadence. CISO Assistant can hold the control mapping and assessment records, though the mapping itself should be reviewed by the client's compliance lead.

DeployOpen does not issue SOC 2 reports, attestations or certificates. Only an independent CPA firm issues the opinion. The client owns its business continuity decisions, including which disruptions to plan for, how much downtime is tolerable, whether to buy business interruption or other insurance, and how much coverage to carry. Those decisions, and the insurance policies themselves, should be reviewed by the client's management, finance and insurance advisers before the auditor's fieldwork. DeployOpen's role is to make the chosen controls configurable, testable and provable on the client's infrastructure.

CC9.1 Business disruption risk mitigation