SOC 2's CC9 has two criteria. CC9.1 asks you to identify, select and develop risk mitigation for business disruption. CC9.2 asks you to assess and manage risks from vendors and business partners. You meet them with a continuity plan, tested recovery, and a vendor inventory with tiers, assessments, contracts and owners.
CC9.1: business disruption
The criterion says the entity identifies, selects and develops risk mitigation activities for risks arising from potential business disruptions. The points of focus describe planned policies, procedures, communications and alternative processing solutions to respond to, mitigate and recover from incidents, plus considering insurance to offset financial impact.
Control ideas
- A business impact analysis listing services, dependencies and how long each can be down.
- A continuity and recovery plan with named roles and a communication tree.
- A decision record on insurance: what cover exists, or why not.
- Alternative processing options, such as a second region or a manual workaround for critical steps.
- A yearly tabletop exercise with notes and follow-up actions.
Evidence: the plan with approval date, the impact analysis, exercise notes, insurance schedule or decision memo, and tickets for actions arising.
If you include the Availability category, A1.2 and A1.3 add backups and tested recovery, which overlap with CC9.1.
CC9.2: vendors and business partners
The criterion is short: assess and manage risks associated with vendors and business partners. The points of focus are more useful. They list establishing requirements for engagements (scope, roles, compliance requirements, service levels), identifying vulnerabilities from vendor relationships including third-party access to your systems, assessing vendor risks by inventorying and tiering on a periodic basis, and assigning responsibility and accountability for each vendor.
Control ideas
- Vendor inventory with owner, service, data shared and access level.
- Tiering rule, such as critical, important and low, based on data sensitivity and operational dependence.
- Due diligence by tier: for critical vendors, collect their assurance report or security questionnaire before signing and at your review interval.
- Contract terms: security obligations, breach notice, confidentiality, subprocessors and service levels.
- Access controls for vendor accounts, with named users and removal on offboarding.
- Periodic review: renewal checkpoints where the vendor owner confirms nothing material changed.
- An exit note for critical vendors: how you would move if they failed.
Their threats include financial failure, security vulnerabilities, operational disruption and failure to meet business or regulatory requirements, according to the points of focus. Your assessment should cover at least those four.
Reading a vendor's SOC report
Do not file it unread. Check the period covered, the scope against the service you use, the opinion, any exceptions, subservice organisations and the complementary user entity controls listed for you. Those last items are things you must do for the vendor's controls to work. Record your response to each.
Auditor questions to expect
Show me your vendor list. How did you decide which are critical? Pick three vendors: show the diligence and the contract. Who owns this vendor? When did you last review it? What do you do if it goes down?
Keeping it proportionate
A ten person company does not need a vendor risk committee. A spreadsheet with tier, owner, last review and a link to the evidence is enough, as long as you actually use it. Spend your effort on the few vendors whose failure would stop service or expose customer data, and keep a light touch for the rest.
What to do
- Build the vendor list from finance records, SSO app lists and cloud marketplace bills.
- Define tier rules and mark each vendor.
- Request assurance reports or questionnaires for critical and important vendors.
- Review reports and log findings and your responses.
- Add security terms to your contract templates.
- Complete the business impact analysis and recovery plan, then run an exercise.
- Set annual review dates for both processes.
Quick check
Do all vendors need a SOC 2 report?
No. The criteria ask you to assess and manage vendor risk. Reports are one input, and low risk vendors may need less.
Is insurance required for CC9.1?
The points of focus say to consider insurance. You need a documented consideration, not necessarily a policy.
How Safeguard helps automate this
Vendor risk is a pile of recurring documents. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and monitoring runs continuously between audits, which saves time for other work. Some vendor risk arrives through code, so technical evidence from your real dependencies, via scans, SBOMs and reachability, shows which third-party packages you actually ship and which findings matter. Autonomous remediation can open tested fix pull requests for vulnerable dependencies; it is off by default, every category starts on Manual, and you choose which categories run automatically and the approval level. Safeguard helps you prepare; your auditor makes the assessment. Book a call.
Sources
- AICPA, Trust Services Criteria (2017, with 2022 points of focus): CC9.1, CC9.2, A1.2, A1.3. Paraphrased.
Last reviewed: 18 October 2026.
