CC9.2 Vendor and business partner risk: requirements and evidence

What CC9.2 vendor risk requires for a SOC 2 audit

CC9.2 requires the organization to assess and manage risks associated with vendors and business partners. An auditor testing this criterion wants to see that you know which third parties touch your system or its data, that you have judged the risk each one carries, and that you act on what you find over time. The points of focus describe the pieces of that cycle: setting requirements when you engage a vendor or partner, assessing their risks, assigning a named owner, defining how communication and exceptions are handled, reviewing performance, addressing issues found in assessments, and ending relationships when they no longer meet your needs. The risk being controlled is simple to state: a weak supplier can expose your customers' data or stop your service, and you carry that exposure in front of your customers even when the failure sits with someone else.

The criterion is hard for three recurring reasons. First, the inventory is incomplete, because nobody has listed every subprocessor, hosting provider, support tool and contractor with system access. Second, shadow SaaS fills the gaps: teams sign up for tools with corporate cards or free trials that never reach procurement or security review. Third, many reviews exist only on paper, with a questionnaire filed in a folder and no record of follow-up, a risk rating that never changes, or an annual check that nobody repeated. An auditor testing operating effectiveness over a Type 2 period will sample vendors and ask for the evidence behind each step, so the review trail matters as much as the review itself. Confirm with your auditor how many vendors and which review dates they expect to sample.

If your system is in scope for confidentiality or privacy, CC9.2 adds further points of focus. You must obtain confidentiality or privacy commitments from vendors and business partners and assess whether they keep them. In practice this means contract terms or data processing agreements that match the data each vendor handles, and periodic evidence that those terms are being followed. Start by building one inventory that records each third party, the data it receives, the criticality of the service, its contract owner and the date of its last review, then check whether every entry has the commitments and reviews the criterion expects.

Which vendors and partners fall under CC9.2 scope

Not every supplier belongs in CC9.2 in the same way. The decisions below determine which relationships need formal assessment, which need monitoring only, and which need confidentiality or privacy commitments. Settle them with your auditor before you build the vendor inventory.

Vendors with access to production systems

Any vendor that can reach production data, systems or credentials sits inside the risk your SOC 2 must manage, even if it never appears in your product. Examples include hosting providers, managed database services, observability platforms and support tools with administrative access. Check what each vendor can read, change or delete, and whether that access is documented, reviewed and removable. Record the reasoning, because the auditor will ask why a vendor was or was not included.

Subservice organizations versus vendors

A subservice organization performs a function that your controls depend on, such as hosting or data center operations. Its controls may be covered by its own SOC report, which changes how you test it. A vendor that supplies a tool without running any part of your control environment is usually handled through due diligence alone. Confirm the boundary early, since it decides whether you rely on carve-out treatment or on the vendor's report under monitoring.

Business partners with data access

Resellers, implementation partners, integrators and referral channels may receive customer data or hold accounts in your environment without being suppliers in the usual sense. They still create third-party risk and belong in the inventory when they handle information or act on your systems. Define what each partner may access, how that access is granted and removed, and what they must notify you about. Partners who only refer customers usually need a lighter review.

Open-source components with commercial support

A self-hosted open-source platform is software you run, so it is not a vendor in the same sense as a hosted service. However, a company that provides paid support, patches or hosted updates to that software is a vendor, and its access and responsiveness belong in CC9.2. Note which components have a supporting company, what that company can reach, and how security advisories reach your team. Unsupported community components still need an owner who tracks their risk.

Confidentiality category in scope

When you include the confidentiality category, CC9.2 also expects commitments from vendors and partners that handle confidential information, and assessment of whether they meet them. Confidentiality commitments usually appear in contracts and NDAs, so the inventory must link each confidential data flow to a signed agreement. Ask your auditor whether confidential data reaches vendors you have not yet listed. Adding the category later increases the number of vendors reviewed.

Privacy category in scope

If privacy is in scope, CC9.2 points of focus extend to privacy commitments from vendors that process personal information, and to checking that those commitments are followed. Your privacy notice and processing agreements define which vendors act on personal data for you. Map each vendor to the personal information categories it receives and the purposes it serves. Where that mapping is missing, the vendor review will not be complete.

How an assessor tests vendor risk management

This table sets out how an assessor tests each CC9.2 element, the evidence requested and the findings that most often appear. Read each row as a test step paired with what the organization should have ready, and note that operating effectiveness is tested across the Type 2 period, not on a single day.

Element tested	What the assessor does	Evidence requested	Common findings
Vendor inventory and risk tiering	Inspects the population of vendors and business partners and checks how each is tiered by risk	Current vendor register, tiering method, dated tiering decisions	Vendors missing from the register or tiers that do not match the data handled
Completed vendor risk assessments	Samples assessments across tiers and checks they were completed before or during onboarding	Due diligence files, questionnaires, reviews of vendor SOC reports or certifications	Assessments completed after go-live or with no documented conclusion
Named ownership	Checks that each vendor relationship has an accountable internal owner who acts on risk	Ownership assignments, role descriptions, owner sign-off on assessments	Missing or departed owners, or owners who never reviewed the vendor
Communication and exception handling	Reviews how vendor issues and exceptions are raised, approved and closed	Escalation records, exception approvals, correspondence with the vendor	Exceptions approved with no expiry, or issues raised but not tracked to closure
Periodic performance reviews	Checks that vendors are reassessed on a schedule set by their tier and that reviews cover performance	Dated review records, updated SOC reports, performance metrics against agreed terms	Stale reviews past the organization's own review interval
Confidentiality and privacy commitments	Where confidentiality or privacy is in scope, checks that commitments are on file and that compliance is assessed	Signed NDAs, data processing terms, records of compliance checks	No confidentiality commitments on file for a vendor that receives customer data
Issue handling and termination	Traces a vendor that was terminated to confirm access, data return or deletion and handover were completed	Termination checklist, access revocation records, data return or disposal evidence	Access left active after the contract ended or no record of data disposal
Test period	Tests whether the controls operated consistently across the observation window in a Type 2 examination	Evidence dated across the full period, not only at a single point	Reviews that were done in the final weeks only, suggesting the control was not operating earlier

Implementing CC9.2 vendor risk management step by step

This sequence turns CC9.2 from a policy statement into a working program: a complete vendor list, risk-based tiers, a consistent assessment standard, named owners, and documented handling for issues and exits. Each step produces a record an assessor can sample.

Build a complete vendor inventory
Start by listing every third party that supplies a service, software, data processing, or infrastructure the organization relies on, including subservice organizations that host or process in-scope systems. Pull the list from accounts payable, cloud and SaaS billing, procurement requests, single sign-on application catalogs, and the engineering team's dependency records, because finance records alone usually miss free tiers and open-source hosted services. The output is a single register with vendor name, service provided, business owner, and whether the vendor touches in-scope systems or data. Confirm the list with department heads before moving on, since an inventory missing a vendor makes every later step incomplete.
Tier vendors by data and system access
Assign each vendor to a risk tier based on the categories of data it can reach, the production systems it can access, and how much the organization would be disrupted if the vendor failed. Vendors with access to customer data, credentials, or production networks belong in the highest tier, while vendors that only provide non-sensitive tooling usually fall lower. Write the tiering criteria down so two reviewers would place the same vendor in the same tier. The output is a tiered register and a short criteria document that the assessment standard in the next step will reference.
Set the assessment standard for each tier
Define what each tier must provide before and during the relationship. For higher tiers, this usually includes requesting the vendor's current SOC 2 report or an equivalent independent report, reviewing its scope, period, and exceptions, and checking whether the vendor's subservice organizations and complementary user entity controls apply to your use. When the report period ends before the date of your review, request a bridge letter that covers the gap. Also decide which vendors need a security questionnaire, a contract review for confidentiality and privacy commitments, or a direct assessment. The output is a written assessment standard mapped to tiers, with a checklist for the reviewer.
Assign an owner to each vendor
Name one accountable internal owner for every vendor in the register, usually the business lead who selected the service, with a security or risk function that approves the tier and reviews exceptions. The owner signs off on the assessment results and is responsible for raising concerns. Record the owner in the register and in the assessment file, so an assessor can see who made each decision. The output is a register with a named owner for each vendor and a documented approval path for tier changes.
Define communication and exception handling
Set out how the organization and each vendor communicate about security, incidents, service changes, and disagreements about assessment findings. Define who the vendor contacts for security matters, how the organization records and escalates an exception, such as a vendor whose report contains a qualified opinion or a missing control, and what compensating action or acceptance is required before the relationship continues. The output is a communication matrix and an exception log template, with the approver for each type of exception named.
Schedule performance reviews by tier
Set a review calendar for each vendor based on its tier, covering a refresh of its SOC report or equivalent evidence, confirmation that confidentiality and privacy commitments are still in force, review of service performance against the agreed terms, and checks for changes in ownership, subservice providers, or data locations. Record each review and its result, and open a tracked issue for every gap found. The output is a review calendar and a set of completed review records that show the program operating over time.
Address issues found in assessments
When a review identifies a gap, route it through the exception process, assign a remediation owner and target date set by the organization, and track the item to closure. Where a vendor cannot close a material gap, decide whether to accept the residual risk formally, add controls on your side, or move the workload to another provider. The output is a remediation log with closure evidence for each issue, which shows the assessor that findings are acted on rather than filed.
Document termination and data return
Before a relationship ends, follow a documented exit procedure. Confirm that the vendor returns or deletes organization data, revokes its access to systems and credentials, and provides written confirmation of disposal. Remove the vendor from the register, retain the exit records, and check that any integrations, shared accounts, and API keys are retired. The output is a closed vendor file with signed or logged confirmation of data return or deletion and access removal, which closes the lifecycle that CC9.2 covers.

How a vendor risk review produces evidence

A vendor risk review produces evidence only when each step leaves a dated, attributable record. The usual sequence runs from a due diligence questionnaire, to a risk rating that sets how deep the review goes, to remediation of gaps, to a sign-off by the person who owns the relationship. CC9.2 asks the organization to assess and manage risks from vendors and business partners, so an assessor will look for the questionnaire responses, the rating method and its result, the open findings, the remediation tickets and the approval, each with a date and a named owner. A risk rating that exists only in a spreadsheet cell with no version history is hard to defend in fieldwork, because the auditor cannot tell when it was made or whether it changed after an incident.

The US banking agencies' 2023 interagency guidance on third-party relationships, published at 88 FR 37920, says a bank may consider reviewing a third party's System and Organization Controls reports during due diligence. For a service organization, this means a bank customer's vendor management team may ask for your SOC 2 report early, and may ask how you handle your own subservice providers. Confirm with your bank customers which report type they accept, whether they require a bridge letter for the gap between the report period end and today, and which of your own vendors they expect you to review. A current report from your own vendors is evidence that your review process reaches beyond your own walls.

Before the next audit period, pick one critical vendor and rebuild its file end to end: the questionnaire, the rating with its rationale, the findings, the remediation evidence and the sign-off. Check that every item carries a date and an approver who is not the person who wrote it. Also confirm whether your contracts include confidentiality and privacy commitments and whether you have a record of checking them, since those points of focus apply when those categories are in scope. The file you produce is the sample an auditor will most likely select, so it should read as a complete story without anyone explaining it afterward.

Evidence that satisfies vendor risk requirements

A CC9.2 examination tests whether vendor risk management happened, not just whether a policy exists. The artifacts below form a connected record: the inventory defines what is in scope, the tier register sets how deeply each vendor is reviewed, and the assessments, contracts and tickets show the work was done and followed through. Each card explains what to keep current between audits.

Vendor inventory

A single register listing every vendor and business partner that stores, processes or can reach in-scope data or systems, with the service provided, the data categories involved, the business owner and the contract end date. Auditors often start here, so an inventory that misses a SaaS tool used by one team undermines every later artifact. Refresh it when procurement approves a new vendor, when an integration goes live, and at each quarterly access review. Record who changed it and when.

Risk tier register

A register that assigns each vendor a risk tier based on data sensitivity, system access, criticality to operations and the consequences of failure. The tier determines the depth of assessment, review frequency and required contract terms. Check that each tier has written criteria, that the assignment rationale is recorded, and that tiers are re-scored after a material change such as a new data category or a security incident at the vendor.

Completed vendor assessments

Due diligence records for each vendor, showing the questionnaire or review performed, the evidence received, findings and the decision to accept, accept with conditions or reject. Every assessment needs a named reviewer and a date. Keep a reassessment schedule that matches the tier, and log the reason for any assessment that falls outside it. A form with blank reviewer fields is a common reason an auditor raises an exception.

Vendor SOC reports and gap analysis

The most recent SOC 2 or other independent report for each vendor that provides one, with the period covered, the bridge letter where the gap is significant, the list of complementary user entity controls the vendor expects you to operate, and a written analysis of exceptions and carve-outs. Confirm the report's scope covers the service you bought. Record where the vendor's report does not reach your data flows and how you addressed the gap. Review new reports when they are issued.

Contracts with security and confidentiality clauses

Signed agreements that set security obligations, breach notification timing, subprocessor approval, data return and deletion, audit or report access rights and confidentiality commitments. Where confidentiality or privacy is in scope, the contract is the main evidence that a commitment was obtained. Keep a clause checklist for each tier and track renewals so expired agreements are not running on old terms. Store executed copies, not drafts.

Performance review minutes

Notes from periodic reviews of each significant vendor, covering service levels, incidents, changes to the vendor's controls or ownership, report exceptions and open remediation items. Minutes should name attendees, the date and decisions taken. Schedule reviews by tier and set reminders in the GRC or ticketing tool. Auditors look for evidence that performance is monitored over the full period, so a single annual review with no interim record is a weak point.

Issue tickets with closure

Tickets recording each vendor finding, from a failed control or late breach notice to a gap found in a report, with an owner, a severity, a remediation plan and a closure note that cites the verifying evidence. Route tickets through the same tool used for internal issues so the trail is continuous. Review open items at each vendor review. A ticket closed without evidence of the fix is treated as unresolved.

Termination checklists

A completed checklist for each vendor exit showing that access was revoked, credentials rotated, data returned or deleted with confirmation from the vendor, and the vendor's subprocessors notified where required. Also record the reason for termination and any open obligations. Keep a template that is tested during an actual exit. Teams that only write termination steps on paper often discover lingering accounts months later.

What meeting CC9.2 costs in money and effort

This table breaks down the cost components of meeting CC9.2 by who does the work, whether the cost is one-time or recurring, and what drives it up. Use it to build a quote request and to see where self-hosted open-source tracking can reduce license spend, while labor and review time remain the larger share to plan for.

Cost component	One-time or recurring	What drives it	How to keep it down
Vendor inventory and tiering	One-time setup, then recurring upkeep	Number of vendors and business partners, and how many touch customer data	Start from a single system of record and tier by data sensitivity and service criticality
Engineering time for tracking tooling	Mostly one-time build, recurring maintenance	Whether tracking runs in a spreadsheet, a ticketing system or a self-hosted GRC platform	Use a self-hosted open-source tool to replace paid seats, and confirm its features before committing
Vendor risk assessment labor	Recurring, per assessment cycle	Number of bespoke questionnaires and how often high-tier vendors are reassessed	Standardize questionnaires and accept current SOC 2 reports where they cover the service
Reviewer and approver time	Recurring	Number of exceptions, escalations and contract reviews needing legal or security sign-off	Define risk acceptance thresholds and delegate routine approvals to named owners
External review of subservice reports	Recurring, once per report cycle	Number of subservice organizations, report periods and bridge letter gaps	Request reports early, map complementary user entity controls and track report expiry dates
Auditor sampling and evidence requests	Recurring, per examination period	Number of vendors sampled, how well records are kept and how quickly evidence can be produced	Keep vendor records in one place with dated reviews, so samples can be answered without rework
Termination and exit planning	One-time per relationship	Data return or deletion requirements, and dependency on the vendor for critical services	Document exit steps before onboarding and test them where the vendor is critical
Licensing for the tracking platform	Recurring, when a commercial tool is used	Seat count, modules and contracted support terms	Self-hosted open-source tools can remove per-seat license fees, but the hosting and maintenance labor still applies

Open-source tools that track vendor risk evidence

A vendor risk program produces a register, assessments, contract commitments and follow-up records, and an auditor will sample each of them. The cards below cover where an open-source GRC tool can hold that evidence and what to verify before relying on it.

CISO Assistant as the evidence register

CISO Assistant (AGPL-3.0-only) is an open-source GRC platform that ships more than 200 frameworks, including SOC 2, and runs audits and compliance assessments against them. For CC9.2, it can hold the vendor register and link each vendor to the assessments, risk entries and evidence files that support its review. Confirm in the current release whether vendor records, assessment templates and review workflows are included, or whether you must build them.

Mapping vendor reviews to SOC 2 criteria

CISO Assistant performs automatic mapping between frameworks, so a vendor assessment question can be tied to the SOC 2 criteria it supports. This helps an auditor trace CC9.2 points of focus, such as assessing vendor risk and addressing issues found, back to recorded reviews. Check how the mapping is maintained and whether you can edit it, because an auto-generated link is not proof that a control operates.

Licensing when you modify the code

The AGPL-3.0-only license requires that users who interact with a modified version over a network can obtain its source code. If your team changes CISO Assistant to add vendor workflows or integrations, legal review should confirm the obligations before the tool holds production vendor data. Using the unmodified release carries a lighter set of duties, so record which version you run and whether it has been altered.

Vendor assessment and due diligence records

Due diligence records show what you asked a vendor, what they returned, and who decided. Store the questionnaire version, the vendor's SOC 2 report or bridge letter, the reviewer, the date and the risk rating together. Under the 2023 US banking guidance, a bank may review a third party's SOC reports during due diligence, so these records should show that the report was read and its scope and exceptions were considered.

Issue tracking and exception handling

CC9.2 expects findings from vendor assessments to be addressed and relationships to be terminated when needed. Keep each finding as a tracked item with an owner, due date, remediation decision and closure evidence, linked to the vendor record. Exceptions accepted by management should carry a documented rationale and an approver. Confirm whether your chosen tool supports issue workflows or whether a ticketing system must hold this record.

Confidentiality and privacy commitment tracking

When confidentiality or privacy is in scope, CC9.2 expects you to obtain commitments from vendors and assess their compliance. Record each signed agreement, the clauses that cover data handling, subprocessors and breach notice, and the date of the last compliance check. Because a vendor's commitments change over time, review this register at each performance review rather than only at contract signing.

Who owns vendor risk, who prepares it, and who attests

Your organization owns the controls. CC9.2 expects management to decide which vendors and business partners matter, how much risk each relationship carries, who is accountable for each one, and what happens when a vendor falls short. Those decisions cannot be handed to a partner or an auditor, because the auditor tests whether management's process actually runs and the report describes your system, not someone else's.

Vendor ownership: Name an accountable owner for each vendor relationship, usually the business or technical lead who depends on it.
Risk decisions: Approve the risk rating method, accept or reject residual risk, and sign off on exceptions.
Contracts: Negotiate confidentiality and privacy commitments, notification duties and termination terms where your scope requires them.
Ongoing review: Read vendor SOC reports, bridge letters and security questionnaires, then record what you concluded.
Termination: Decide when to exit a vendor and carry out the offboarding, including data return or deletion.

Before the examination, confirm that each named owner can explain the vendor's role and that the review records show management's own judgment.

Where vendor risk programs usually fall short

Most vendor risk programs fail less on policy than on execution: the list of vendors is incomplete, reviews stop after the first pass, and the records an assessor asks for do not exist. The cards below cover the gaps auditors tend to find under CC9.2, each with a closing step the organization can take before fieldwork.

Incomplete vendor inventory

The inventory is the starting point for every CC9.2 activity, and it usually misses software bought on corporate cards, free tiers adopted by individual teams, and tools connected through single sign-on that nobody formally approved. An assessor who finds a processor missing from the list will question every review built on it. Closing step: reconcile the vendor list against card and expense records, identity provider applications and cloud billing data, then assign each new entry to an owner.

Reviews completed once

Many organizations run a thorough due diligence review at onboarding and never revisit it, so a vendor that changed its hosting region, its subprocessors or its security posture stays on a clean file. CC9.2 expects the assessment of vendor risk to be an ongoing practice, not a one-time event. Closing step: set a review trigger for each vendor tier, such as contract renewal, material service change or a published security incident, and record each review with its date and outcome.

No named owner

When a vendor relationship has no accountable person, reviews are skipped, renewals auto-extend, and performance problems go unescalated. Assessors look for an identified owner who can explain why a vendor is still in use and what happens if it fails. Ownership often sits with procurement by default, which leaves the technical risk without a business or engineering decision-maker. Closing step: record one accountable owner per vendor, with a backup, and confirm that the owner has accepted the role in writing.

Vendor SOC reports never read

Teams often file a vendor's SOC 2 report without reading the sections on exceptions, subservice organizations or complementary user entity controls. Those controls describe what the customer must do for the vendor's controls to work, such as configuring access, reviewing logs or approving changes. If nobody maps those obligations to internal controls, the organization relies on a report it has not actually met the conditions for. Closing step: read each critical vendor report, list its complementary user entity controls, and assign each one to an internal control owner.

Missing confidentiality and privacy commitments

When confidentiality or privacy is in scope, CC9.2 expects the organization to obtain commitments from vendors and business partners and to check that they keep them. Gaps appear when an onboarding form is signed but the data processing terms, retention limits or breach notification duties are missing from the contract. Assessors commonly ask which vendors handle protected data and where their commitments are stored. Closing step: compare each vendor that touches confidential or personal data against its signed contract terms, and fill any missing commitments before the next renewal.

No termination record

Vendor programs rarely document how relationships end, so data return, access removal and deletion certificates are left to chance. Under CC9.2, the termination of a vendor relationship is part of the risk management cycle, and an assessor may ask for evidence that access was revoked and data was returned or destroyed. Without that record, the organization cannot show that a retired vendor no longer holds its data. Closing step: create a termination checklist covering access removal, data return or deletion confirmation, and final invoice closure, and file a completed copy for each exited vendor.

How long and how much effort does CC9.2 take to meet?

Can an in-house team meet CC9.2 without outside help?

Yes, many organizations do, provided they have someone who owns the vendor risk process and the time to run it every cycle. CC9.2 asks the organization to assess and manage risks from vendors and business partners, so the work sits with the organization, not with an outside firm. Outside help is usually a choice about capacity and experience, not a requirement. An in-house team should confirm three things before starting: who owns each vendor relationship, which vendors are in scope, and whether the team can produce dated assessment records for the auditor. Only the independent CPA firm issues the SOC 2 report, so the internal team must be able to show its own work to that firm.

What drives the effort of CC9.2 the most?

The main driver is how many vendors and business partners touch the in-scope system and how much risk each one carries. Effort rises with the number of vendors, the sensitivity of the data they handle, and how often the relationship changes. Effort also rises when the organization has no inventory and must build one first. The points of focus cover engagement requirements, risk assessment, responsibility, communication, performance review, issue handling and termination, so each vendor needs a record across that full cycle. Confidentiality and privacy commitments add more work when those categories are in scope. Ask your team how many vendors are critical, how many hold customer data, and how many already have current assurance reports on file.

What does the organization need to provide for CC9.2?

The organization needs a current vendor inventory, a documented risk assessment method, named owners for each relationship, and a place to store results. It also needs contracts or agreements that set expectations for security, confidentiality and privacy, plus a defined way to raise exceptions and act on them. Recurring work includes reviewing vendor reports, tracking issues to closure and recording decisions when a vendor is retained, restricted or terminated. These inputs must exist during the observation period, not only at the start of the audit. Confirm with your CPA firm which records it will accept, how far back it will look, and how it wants evidence labeled.

How does the number of vendors change the audit effort?

More vendors means more assessments, more records, and more follow-up on open issues, and the effort grows faster than the vendor count because each relationship has its own history. A small set of critical vendors can often be reviewed in depth, while a long tail of low-risk tools may need a lighter, tiered method. Tiering is useful only if the organization can explain why each vendor sits in its tier and can show that the tier was reviewed. Subservice organizations also matter: if a vendor's own SOC report carves out controls that the organization relies on, those gaps need separate handling. Ask any partner how it would tier your vendor list before agreeing on scope.

What will an auditor sample for CC9.2?

An auditor will typically select a sample of vendors and business partners from the inventory, then test whether each one was assessed, owned, monitored and acted on during the period. For the sampled vendors, the auditor looks for evidence that risks were assessed before engagement, that performance was reviewed, that issues were tracked, and that confidentiality or privacy commitments were obtained where those categories apply. The auditor also checks that the inventory is complete, because a sample drawn from an incomplete list proves little. The exact sample size and method are set by the CPA firm and its own procedures, so ask the firm to explain them in its planning discussions.

What should a written scope for CC9.2 include?

A written scope should name the in-scope systems, the vendors and partners covered, and which Trust Services categories apply. It should list each deliverable, such as a vendor inventory, a risk assessment method, a tiering model, assessment templates, a review calendar and a decision log. It should state who on the client side owns each task, what the partner will prepare versus what the organization must approve, and how evidence will be stored and handed to the auditor. Ask for a clear boundary: the partner prepares systems and records, and the independent auditor issues the report. Finally, request the timeline, the assumptions behind it, and the conditions that would change the scope or fee.

Does CC9.2 cost more once confidentiality or privacy is in scope?

It generally adds work, because the points of focus for CC9.2 then include obtaining confidentiality or privacy commitments from vendors and business partners and assessing whether they keep them. The organization must collect those commitments, compare them to its own obligations, and record how it checks compliance. Where a vendor is a processor of personal information, the review may also need legal input on contract terms. The size of this addition depends on how many vendors handle confidential or personal data and how standardized their agreements are. Ask any quote to separate the confidentiality and privacy work from the core vendor assessments so you can see what each category adds.

How DeployOpen prepares vendor risk evidence for CC9.2

DeployOpen starts every CC9.2 engagement with a written scope that names the vendors and business partners in the system boundary, the platforms that will hold the vendor register and assessment records, the roles that own each vendor relationship, and the evidence the auditor is expected to request. The scope also states what is excluded. For example, a team may decide that a payroll provider with no access to production data sits outside the vendor assessment cycle, and that decision should be written down with the reason. Because the work is fixed-scope, the deliverables and timelines are agreed before any configuration begins. Ask the implementation partner to show the scope document and the list of deliverables before signing.

On the client's own infrastructure, the register and assessment records are built on self-hosted open-source tools that run in the client's cloud account, data center or air-gapped network. DeployOpen configures the vendor inventory, the risk tier for each vendor, the due diligence questionnaire templates, the review cadence, the named owner for each relationship, and the workflow for exceptions and terminations. Confidentiality and privacy commitments are stored alongside each vendor record when those categories are in scope. The tool choice is yours to confirm against your own requirements, including whether the platform supports the audit trail and access controls you need. Confirm these capabilities during scoping rather than assuming them.

The evidence pack is assembled for the independent CPA firm, not for DeployOpen to approve. It typically includes the vendor inventory with risk ratings, the completed assessments and their dates, the reviewed SOC reports or other assurance documents with the review notes, records of performance reviews and issue handling, and proof of termination steps where they occurred. DeployOpen can also prepare a short index that maps each record to the relevant point of focus, which helps the auditor sample efficiently. DeployOpen does not issue audit reports, attestations or certifications. Only an independent CPA firm performs the SOC 2 examination and issues the report, so the auditor's engagement letter and sampling approach should be agreed before the evidence pack is finalized.