Vendor risk management is the CC9 requirement that most technology companies underestimate — and that auditors are increasingly rigorous about. The question CC9 asks is not just whether you have assessed your vendors, but whether you have a systematic process for identifying which vendors matter most, how you assess their security, and how you monitor them on an ongoing basis. A vendor list in a spreadsheet that hasn’t been updated since last quarter’s audit preparation does not satisfy CC9.
Building the Vendor Inventory
The vendor inventory is the foundation of the vendor risk management program. Every third-party service provider with access to in-scope systems or data, or whose failure would materially impact the service organization’s ability to meet its commitments, should be in the inventory. This includes: cloud infrastructure providers, SaaS tools used in production, payment processors, security tools, subcontractors with system access, and professional service providers with data access.
| KEY IDEA | Most technology organizations have more relevant vendors than they initially believe. In addition to obvious infrastructure providers (AWS, Stripe, Twilio), consider: the HR platform that has employee data, the code scanning tool with production credentials, the customer success platform with client data, the video conferencing tool with recorded client calls, and the development agency with source code access. All of these are potential CC9 vendors. |
| Vendor Inventory Field | Purpose | Population Source |
|---|---|---|
| Vendor name and description | Identifies the vendor and the service provided | Finance/procurement system; security team inventory; engineering team survey |
| Data access (type and classification) | Determines which data the vendor can access — critical for Privacy and Confidentiality TSC | Data flow diagrams; system integration maps; contract review |
| System access (type and level) | Determines whether vendor has access to in-scope systems and at what privilege level | IT system access lists; contractor access reviews |
| Risk tier (Critical/High/Medium/Low) | Drives frequency and depth of due diligence | Risk tier methodology applied based on data access, system access, and business criticality |
| Due diligence status and last review date | Tracks when each vendor was last assessed and whether due diligence is current | GRC platform vendor module; compliance calendar |
| SOC 2 / ISO 27001 report on file | Records whether a third-party attestation has been obtained and reviewed | Vendor portal; vendor self-reporting; compliance team records |
Risk Tiering Methodology
Not all vendors require the same level of due diligence. Risk tiering allocates the most rigorous assessment to the vendors that pose the greatest risk: those with access to sensitive data, those with privileged system access, and those on whom the service organization critically depends. A practical three-tier model:
| Risk Tier | Criteria | Due Diligence Requirements | Review Frequency |
|---|---|---|---|
| Critical | Access to client personal data or confidential data; privileged access to production systems; infrastructure on which the service critically depends | Annual SOC 2 / ISO 27001 report review; vendor security questionnaire; DPA in place; right to audit clause in contract | Annual |
| High | Access to internal systems or data with business sensitivity; single point of failure for a non-core function | Annual vendor security questionnaire; DPA or security addendum in place; review of available attestation reports | Annual |
| Medium | No direct data access; access limited to internal systems; redundant vendors available | Onboarding questionnaire; security terms in contract; review every 2 years | Biennial |
| Low | No data or system access; commodity service with no security relevance | Security review not required; standard contract terms sufficient | As needed |
Contractual Security Requirements
CC9 requires that contractual security requirements are in place with critical vendors. At minimum, the contract or a supplemental data processing agreement (DPA) should include: confidentiality obligations for client data, data processing limitations (use only for the contracted purpose), security control requirements appropriate to the data involved, breach notification timeframe (typically 72 hours aligned to GDPR), data return/deletion obligations at contract termination, and the organization’s right to conduct or commission security reviews.
| BITLION INSIGHT | Many technology companies discover during readiness assessments that their largest SaaS vendors — AWS, Google, Salesforce, Slack — have standard DPAs available for signature on their websites. These pre-written DPAs satisfy most CC9 contractual requirements for those vendors without negotiation. Building a vendor contract review into the standard procurement process — requiring a DPA before approving any new SaaS tool — prevents the common situation of retrospectively executing DPAs with dozens of vendors in the weeks before an audit. |