Vendor-Provided Compliance Reports as SOC 2 Evidence

What Trust Services Criteria demand of vendor oversight

CC9.2 calls for a business to set up, apply, and share rules covering vendor management. This falls under Common Criteria. It covers every SOC 2 audit no matter what trust service categories sit within scope. It can't be avoided by calling it a limited audit.

CC9.1 does more. The rule requires each organization to find and lower threats from vendor relationships, making vendor oversight a hands-on duty, not a background one. Vendor awareness alone won't cut it. Most organizations slip up here by not handling the risk those vendors create. Security, availability, processing integrity, and confidentiality often involve outside companies, so vendor oversight affects more than the security team.

The 2017 Trust Services Criteria, along with the AICPA's October 2022 updates, still set the rules. That version hasn't been replaced, so treat any claim that the AICPA has issued a formal AI-specific rewrite of the criteria with skepticism, because no such rewrite exists as of this writing. SSAE 23 is the latest update, applying to engagements starting December 15, 2025 or later. It aligns attestation engagements with the AICPA's Statements on Quality Management Standards (SQMS) Nos. 1, 2, and 3, and changes how audit firms document engagement quality internally. That counts most when the vendor's report is from a newer CPA practice, because the level of rigor has now become easier to spot if you understand where to check.

Taken as a whole, the rules make the organization that gets a vendor's report responsible, not the vendor that creates it. Receiving it isn't what's required. Doing so is, yet most compliance plans miss it.

Choosing which report type to request

There are 2 kinds of report, while treating them like interchangeable items is the top common mistake across this process. One Type I review checks whether the vendor's controls fit appropriately on one date, acting like a snapshot. It gives some assurance, and shouldn't be the main evidence about a vendor with private data. Anyone accepting a Type I report on a critical vendor then treating their file as finished is asking for an audit issue down the line.

The Type II report checks how controls are set up and work during the defined observation period, usually 6 to twelve months. It shows whether controls actually did the job, not just in theory. That's why most big customers insist on it. Consider Type II the starting point for critical and high-risk vendor relationships involving data, infrastructure, or sensitive operations. There's no real argument for accepting less, whatever a vendor's sales team might say about "equivalent assurance."

How recent it is counts just like type. Any report whose observation period wrapped up fourteen months back is completely stale, no debate, since most compliance groups cap things at twelve months. Always Check the observation period’s end date before treating it as valid, in every case.

SOC 3 reports stand apart. Meant for broad sharing, they leave out the granular detail a proper vendor risk review needs. However nice it seems, that SOC 3 page found on any vendor's trust section is just sales talk pretending to be assurance, never replacing the actual underlying SOC 2 report itself.

Some vendors provide letters covering the period after a report’s stated date to show controls remained effective, though these are not AICPA-mandated.

Report source also points to quality, but many miss it. On May 14, 2026, the AICPA's Peer Review Board said structured outreach to captains looking at high-volume SOC 2 work would start June 1, 2026, extending oversight already underway for those companies. They want to spot cookie-cutter documents where firms paste an identical TSC mapping for each client, even when it doesn't fit what that client handles. When a vendor's report seems to be a template with the business details swapped in, it signals credibility issues, so don't shrug it off.

Confirming the things your organization relies on fall within the report's scope

When managing third-party risk, Scope misalignment is a very common error that folks skip checking. The SOC 2 report from a vendor could leave out the very thing your company needs, or it could apply to just part of their overall setup. If you take coverage for granted without verifying it, gaps stay hidden until an auditor turns them up.

Before anyone depends on the report's statements, confirming a few points is essential. Look at the dates covered by the period to confirm the observation window is recent. Review the services within scope and make sure the exact tool the organization runs appears there, not any sibling offering or old release. Also look at which criteria they tested: Confidentiality and Privacy aren't required, so a company might have one that's Security-only while your team requires protection under Confidentiality for the information it shares with them.

Vendor scope drifts as vendor relationships grow while compliance is left out, and audit findings often flag that drift. Even when scope covered a vendor relationship completely in the last audit period, it may have expanded afterward. Suppose the accounting crew brings in another payment processor without looping in compliance at all: the existing report only covers the original vendor, and nobody spots it until an auditor comes asking. Revisiting the vendor inventory regularly helps identify relationships that have transformed.

Subservice organizations introduce extra complexity. Konfirmity noted the CBIZ 2024 SOC Benchmark Study found 89.6% of SOC 2 audits list subservice providers, compared with 82% previously. Not every vendor is covered, so look through the report to find the vendor's critical subprocessors listed out, and examine carved-out subservice organizations to see whether they require another review.

When scope falls short of the organization needs, documentation is the solution. Spot the gap, link it to a questionnaire, penetration findings, or contractual assurance that closes it, and record the decision on residual risk, showing who took it and why.

Understanding the report's content

Control descriptions reveal more than many reviewers realize. Naming who runs the check, when, and which system handles it points to a seller that put the safeguard into daily work. Vague language ("access is periodically reviewed") usually signals a control that exists mostly as a policy document, and a reviewer who lets that phrasing slide is missing the actual warning sign sitting right there in the report.

Your organization relies on each criterion, so it must map back to what the vendor's scope needs. Compare every criterion to the controls it describes, then note which trust services commitments of your own rely on that vendor control. You need to write down how that vendor's evidence connects with your compliance posture so it stays explicit.

Exceptions call for close attention, not all carry the same weight. One problem fixed through the documented remediation plan stands materially apart from that control breaking down over several review rounds. Review each exception against your own numbers: figure out what that exact failure tells you about the data going to this third party, not anything general. An adverse finding isn't a point to record and leave behind. This requires escalation, with documented risk acceptance by the right people or a choice to leave that vendor.

Think of the auditor's take as the report's main message: the controls were built the right way (Type I), or they actually worked across the period covered (Type II). Start there, and treat both exceptions plus the control descriptions like evidence backing that conclusion, because this auditor arranged their report that way.

A long Report doesn't signal quality, and treating an extensive one as superior remains a common mistake among reviewers. The CBIZ 2024 SOC Benchmark Study shows 23% of SOC 2 reports contained more than 150 security controls. Lots of controls could signal the vendor runs a thorough system, or that padding fills the report with basic controls failing to map real risk. See whether the controls match the vendor's work, or come across as a stretched template chasing a count.

Track Confidentiality coverage on its own. The CBIZ 2024 SOC Benchmark Study shows 64.4% of SOC 2 reports include the Confidentiality criterion, up from 34% the year before. When a vendor handles data this organization calls confidential, and a report skips this criterion, it creates a documented gap.

Complementary User Entity Controls: the obligations the vendor places on you

People usually skip over one part of each Type II audit: User Entity Controls, called CUECs. The report itself flags them as things the customer has to handle so the vendor's stated controls actually do their job. Say a vendor lays out some review process, and it assumes the organization deprovisions people inside a defined window. If you aren't handling it, a good vendor's view won't protect you, however much evidence stands behind it.

The danger here is plain: a clean vendor report won't shield you from an audit gap if you skip the controls it takes for granted you'll operate. When an auditor asks whether your CUECs were handled and you say no, that gap is yours.

There’s another subtler warning sign to note. When a CUEC section is too long, or requires buyers to handle controls no normal business could keep up with, the seller has likely pushed its own protection duties onto them rather than doing the work itself. A fair CUEC list asks customers to do only what they plausibly can. A bloated CUEC shows a vendor pushing off its own duty, so those reviewing should count it against the vendor rather than seeing it as just a bother.

The CUEC review process runs on fixed steps, a plus since anyone can repeat it the same way. Review each CUEC listed in the report and determine whether your organization meets the requirements or needs to address gaps. Documenting the review of CUECs provides evidence of compliance oversight.

Specific evidence auditors expect when AI vendors are in scope

There's no official AI-specific SOC 2 standard yet. AICPA hasn't issued one, and signals suggest one isn't coming in the near term. Even so, auditors handling live engagements during 2026 want AI-specific evidence. What shows up on vendor questionnaires now tracks what auditor teams ask for in real work, not what the criteria say.

Auditors usually request the same kinds of materials from AI vendors. Rules for versioning, plus documentation tracing lineage of training data. Inference and prompt logs with personal details redacted, recorded per request, including timestamp, system and release, ask, answer, and a set retention window, keeping data briefly in active storage then longer in cold storage ahead of deletion. Reports tracking how the AI works as weeks pass. Risk assessments covering each third-party LLM the vendor treats as one of its subprocessors.

That final point needs separate evidence, since every LLM subprocessor remains a subprocessor. Letting it slide past subprocessor review is an error reviewers are flagging today, not one they may address down the road. They should look for a completed Data Processing Agreement for every live LLM company, clear terms saying data is not kept or used for training in the agreement (not taken from sales material), the LLM firm’s SOC 2, or that firm’s ISO 27001 audit, plus an up-to-date register of subprocessors with a way to alert clients when it is updated.

Unapproved AI use is among the common findings auditors flag in 2026. A worker puts pastes customer data inside a chatbot with no vendor sign-off, sending confidential details to a subprocessor missing management review and any oversight process. This is what failure mode auditors see most, not some entirely hypothetical scenario dreamed up for a slide presentation. As you go through an AI vendor's report, check whether their controls cover workers running unapproved AI, because that failure mode applies at their company too, not only yours.

AI vendors increasingly bring up two related frameworks next to SOC 2, each covering distinct territory. SOC 2 certifies nothing about explainability, bias, or how AI gets run, but ISO/IEC 42001 (an AI management guide from December 2023) plus the Generative AI Profile (NIST-AI-600-1, published July 2024) from NIST's AI Risk Management Framework both cover those topics. A vendor that carries a SOC 2 report along with ISO 42001 certification reaches further than one with just SOC 2. Reviewers must know what the document assures first, not treating those materials like interchangeable items, because stacking certifications does not fill a gap.

Building a documented review process that produces audit-ready evidence

Missing records still trigger audit findings, even when the vendor risk beneath them stayed under control. An auditor treats a review with no documentation as though it never took place. The written record is the evidence, not extra support, full stop.

Any documented review process needs several key parts. Begin with a full vendor inventory based on the service descriptions, each vendor’s risk level, the most recent review date, and what every report within the file covers. Add review levels by risk: critical vendors (those touching live client data, hosting platforms, or protective tools) get a complete review, whereas safer ones receive a written reason for why a reduced check was enough.

Create an organized review list and put each company through it, including type and date, checked limits, TSC fit, quality in the controls, issue tracking and remediation state, CUEC links, third-party details, plus AI-specific proof where needed. If the review spots a gap, record it, who holds the risk, any compensating control or remediation plan, plus residual risk acceptance, and a statement confirming that report arrived and got stored.

Reviewers look for evidence that controls operated continuously across the review period, even when the report was prepared. Auditors expect records showing controls operated throughout the reporting period.

Many compliance platforms handle this at scale across 2026. Tools for evidence alone, like Vanta, Drata, Secureframe, plus Sprinto and Thoropass, handle gathering and matching. Strac Comply, for instance, puts the controls right into the product itself. The 2026 strac.io reference reports licensing fees aimed at mid-market organizations at $7,000 up to $30,000 each year, with first-year Type II totals all-in generally sitting from $30,000 through $120,000. Picking the right type comes down to wanting only the compliance piece, or having the tool generate CC6.x proof straight from internal data controls.

The same kind of record-keeping shows up in nearby fields too. Firms handling AI visibility for a roster of customers run into a challenge that is structurally comparable: knowing which digital platforms and AI channels every client depends upon, plus gathering evidence of monitoring on each account individually. Some tools use a many-brand hub with per-client weekly reports, showing the same basic idea that makes review systems succeed. Oversight lives in one spot, yet the records behind it must stay detailed enough to stand up per client relationship or per vendor relationship.

Vendor oversight amid audits

Pulling files just one time annually won't meet what the audit team wants from Type II coverage. They want ongoing oversight, documented throughout that entire audit window, not one report push each January that’s ignored come February.

Ongoing monitoring involves several recurring tasks to follow on a schedule. Check fresh SOC paperwork when vendors publish it, and monitor expiration deadlines so renewal happens proactively rather than late. Track vendor breaches plus service disruptions, and log how the organization found each issue and its reaction. Monitor SLA compliance on an ongoing basis instead of a single annual check. Do periodic reassessments when the vendor relationship shifts: added services, fresh data paths, or different owners. Watch for shifts in who runs a vendor or how they operate, because a purchase or management shakeup might alter whether vendor's controls hold up later.

Bridge letters show up again here as well. If a vendor's audit deadline has already gone by and the upcoming Type II cycle isn't finished, that gap gets filled by an interim note, and getting one needs recording with any key updates it reveals.

Across ongoing monitoring, Vendor scope drift is a frequent compliance gap that organizations overlook. A vendor inventory needs to be an active document, since teams may introduce new SaaS applications without involving compliance, and auditors frequently identify this gap in organizations.

Some industries face growing oversight as well. Under the PS24/16 framework, FCA's Critical Third Parties rules took effect in January 2025, while SEC's 2024 amendments to the Regulation S-P standards set deadlines that stretch into 2026 depending on company scale. SOC 2 still asks for the same things on paper, yet both regulations make bad vendor oversight far more expensive in the industries they cover. The review begins with a vendor report, yet it doesn't stop there.