SOC 2 CC9: disruption and vendor risk
CC9 is two criteria that get bolted on at the end and then hold up the report, because both of them need documents somebody outside engineering has to sign.
CC9 has two criteria. CC9.1 requires that you identify, select and develop activities to mitigate risks arising from potential business disruptions. CC9.2 requires that you assess and manage risks associated with vendors and business partners. The evidence is a continuity plan with stated recovery objectives and a tested restore for the first, and a vendor register with risk ratings and dated reviews for the second.
Both are cheap if you start them early and expensive if you leave them to month five, because both depend on other people. A continuity plan needs somebody to commit to a recovery time the company can actually meet, and the vendor register needs contracts, which live with whoever signs contracts.
What does CC9.1 want beyond a backup?
A backup is a CC7.5 and continuity artifact. CC9.1 is broader and asks what you have done about business disruption generally, which for a small SaaS company means four things: recovery objectives you can defend, a plan naming who does what, evidence the recovery mechanism actually works, and any risk transfer such as insurance where you chose it over mitigation.
| Disruption | Mitigation | Artifact |
|---|---|---|
| Data loss or corruption | Backups with a stated retention, and a tested restore | Restore test record with date, scope, duration and verifier |
| Region or provider outage | A stated recovery objective, multi-zone where you have it, and honesty where you do not | Architecture note plus the objective published in customer terms |
| Loss of a key person | Break-glass access documented, second administrator on every critical account | Break-glass procedure, administrator list per account |
| Ransomware or destructive incident | Immutable or separately controlled backups, incident plan, exercise | Backup configuration showing separation, tabletop notes |
| Residual financial loss | Cyber liability insurance, where you chose transfer | Policy certificate, and the risk register row saying you transferred rather than mitigated |
Insurance is not required by SOC 2 and it does not mitigate a control gap. As evidence against CC9.1 it is legitimate where your risk register records a deliberate transfer decision. Buying a policy and never referencing it in the register gets you nothing.
How thorough does vendor review have to be?
Proportionate to what the vendor touches. An auditor is not expecting you to audit your payroll provider; they are expecting you to have decided, in writing, which vendors matter and to have looked at those. The rating scheme below is enough for a first audit and takes an afternoon to apply across thirty vendors.
- Critical
- Processes or stores customer data, or its failure takes your product down. Cloud provider, database host, authentication provider, email infrastructure. Review the current SOC 2 or ISO 27001 report annually and note what you looked at.
- Important
- Holds company or employee data, or has access to systems in scope. Identity provider, code hosting, monitoring, HR system. Confirm a current attestation exists; a lighter review note is enough.
- Low
- No access to data in scope and no availability impact. Design tools, the coffee subscription. List them, rate them, and stop.
Where does Canadian law change the vendor wording?
PIPEDA's accountability principle keeps responsibility with your company when personal information is transferred to a third party for processing. You are required to use contractual or other means to provide a comparable level of protection while the information is with them. That is stronger than "we collected their SOC 2 report": the contract has to carry the protection obligation, which makes the data processing terms a CC9.2 artifact as much as a legal one.
If you hold personal information about Quebec residents, Law 25 adds a privacy impact assessment before communicating personal information outside Quebec, which for a company using US cloud infrastructure is most vendors. Record the assessment once per transfer arrangement and keep it with the vendor file. The Law 25 page covers how this lands on a SOC 2 program, and the PIPEDA overview on GetAudited covers the statute itself. The vendor management policy page has the clause wording that satisfies both at once.
Your cloud provider is your largest CC9.2 vendor and your CC6.4 answer
The review note you write when you read AWS, Google Cloud or Azure's SOC 2 report does two jobs: it is the vendor review under CC9.2 and it is the physical access evidence under CC6.4. Record the report date, the period it covers, the opinion, any qualifications, and the complementary user entity controls it says are yours. That last list is the part almost nobody reads and the part an auditor will ask about.
0 of 6 done ·
Get vendor and disruption risk documented
CC9 pulls in every vendor you rely on, which is more of them than most companies expect. Tell us your scope and compare firms that will work the list with you.
Get matchedCommon questions
How many criteria are in CC9?
Two. CC9.1 covers risk mitigation for business disruptions and CC9.2 covers vendor and business partner risk.
Do we need cyber insurance for SOC 2?
No. SOC 2 does not require insurance. It is one legitimate way to evidence a risk transfer decision under CC9.1, and it only counts if your risk register records the decision to transfer rather than mitigate.
What if a critical vendor has no SOC 2 report?
Document what you did instead: a security questionnaire, a review of their published security documentation, contractual commitments, or a decision to accept the risk with a named owner. An auditor accepts a reasoned alternative. What fails is a critical vendor with no report and no record of anyone having noticed.
How often do vendor reviews have to happen?
At whatever cadence your policy states, with at least one falling inside the observation window for critical vendors. Annual is the normal commitment and the one to write unless somebody will genuinely do more.
Is a subprocessor list the same as a vendor register?
No. The subprocessor list is the public, customer-facing subset of vendors that process customer personal information. The vendor register is internal, longer, and carries the ratings, review dates and contract references the auditor tests.