SOC 2 vendor management workflow (CC9.2, CC3.4)
A SOC 2-ready vendor management workflow: due diligence, risk assessment, contracting, ongoing monitoring, and offboarding, with approval gates and reviewer signatures captured for the Type II audit window.
What the soc 2 vendor management workflow (cc9.2, cc3.4) process is
Vendor management rarely breaks because nobody assessed the vendor. It breaks because the assessment happened once, in a spreadsheet tab, and was never repeated. A year later the vendor is processing customer data in a new region, the contract auto-renewed, and there's no record that anyone weighed in on either change.
CC9.2 asks for a lifecycle, not a form. The diagram needs to show how a new vendor gets classified by risk, what documentation each tier requires, who approves the relationship, and what triggers a reassessment. Risk classification is the branch that matters most: it decides whether a vendor goes through a full security review or a light registration.
For a Type II audit, the process existing isn't enough. Auditors sample across the whole period and ask for evidence of each instance: the completed assessment, the signed approval, and the record of offboarding. Every step in the diagram needs an owner and a named piece of evidence.
What this flowchart covers
In this template
- Intake: who may nominate a new vendor, what data and systems the vendor needs access to, and how the nomination gets logged
- Risk classification that branches the process: a vendor with no data access follows the light path, while a data processor with production access goes to a full security review
- Due diligence: collecting a SOC 2 report or ISO 27001 certificate, reviewing subprocessors and the data processing agreement, with a branch for when the documentation falls short
- Contract and approval: security requirements written into the agreement, legal review, and a signed approval before the vendor is used
- Ongoing monitoring: annual reassessment, follow-up on new reports, and a branch that triggers a fresh risk assessment when the service or data access changes (CC3.4)
- Offboarding: termination, access revocation, data deletion or return, and a documented close-out in the vendor register
When to use this template
- You're heading into a SOC 2 Type II audit and need to show vendor management as a controlled process with evidence across the whole period
- Vendors get onboarded without a shared assessment because procurement, IT and legal each work from their own list
- Nobody can answer which vendors process personal data or when they were last assessed
- Contracts auto-renew without anyone checking whether the risk picture has changed
- You need to document the same vendor process for both SOC 2 and ISO 27001 and want to avoid two versions that say different things
Controls documented
- CC9.2
- CC3.4
- CC9.1
How it works
Set the risk tiers before you draw
Two or three tiers are enough. Define them by data access and operational criticality, not contract value.
Put the approval where the decision actually gets made
If security has veto power over data processors, it needs its own approval step.
Draw reassessment as a real loop
Both the annual reassessment and the event-triggered reassessment (CC3.4) need to lead back into the process.
Name the evidence for every step
Note in the comment field what the documentation actually is: the assessment, the agreement, the approval, the offboarding receipt.
Review the diagram with procurement and legal
Vendor management crosses at least three departments.
Frequently asked questions
What does SOC 2 require for vendor management?
CC9.2 (third-party relationships) and CC3.4 (risk assessment for changes affecting controls) require documented procedures for due diligence, contract review, ongoing monitoring, and termination.
How does QueryChart help with a SOC 2 Type II audit?
Every workflow execution is captured in the immutable audit trail with author, timestamp, and approver signatures.
What's the difference between CC9.2 and CC3.4?
CC9.2 covers the vendor relationship itself. CC3.4 covers what happens when something changes and requires a fresh risk assessment.
Does every vendor need the full assessment?
No — classify vendors by data access and operational criticality, and only send the critical ones through the full path.