Learn · Vendor Risk
Do All Your Vendors
Need SOC 2?
No. No trust services criterion names SOC 2 as a vendor requirement, and no auditor will fail you for having suppliers without one. What the criteria require is that vendor risk is assessed and managed proportionately — which means a small number of vendors get deep scrutiny and most get a register entry.
The distinction that actually matters: risk tier decides how hard you look at a vendor. Whether they are a subservice organization decides whether they appear in your own report. Those are two different tests, and a vendor can pass one and fail the other.
Plain-English explainer · TSC 2017 (rev. 2022) · Last reviewed August 2026
No. Vendor assurance is meant to be risk-based, and requiring a SOC 2 report from every supplier is both impractical and a reliable sign of an immature program. The applicable criterion is CC9.2 in the 2017 Trust Services Criteria (points of focus revised in 2022): assess and manage the risks that vendors and business partners represent to your objectives. That is a process obligation, not an artifact obligation. Nothing in the criteria, in the description criteria at DC section 200, or in the attestation standards at AT-C 105 and AT-C 205 names a report type your suppliers must hold. ISO/IEC 27001:2022 works the same way — Annex A controls A.5.19 to A.5.23 require a supplier-security process, agreements, ICT supply-chain management, monitoring and cloud governance, not a certificate from the counterparty. A blanket “all vendors must be SOC 2 compliant” policy actively weakens your position, because it shows a risk assessment that does not distinguish a payroll platform from a stock-photo subscription — and because, as the certified-versus-attested distinction makes plain, there is no such status as “SOC 2 compliant” to hold in the first place.
What the criteria require
The rule is proportionality, not paperwork
The blanket-SOC-2 reflex usually starts in the right place. A security team reads CC9.2, sees “vendors and business partners”, and reaches for the strongest available artifact rather than the appropriate one.
What CC9.2 asks for is a working process: conditions for engaging vendors, an assessment of the risk each represents, allocated responsibility, communication and exception handling, performance evaluation, confidentiality commitments, and defined termination. Two adjacent criteria carry weight as well — risk identification and analysis under CC3.2, where a vendor first enters your risk universe, and the monitoring criterion at CC4.1, which is what an auditor points at when your stated review cadence did not happen. Availability commitments draw A1.2 over vendors running your backup and recovery infrastructure; confidentiality commitments draw the C-series over anyone holding covered information.
None of them specify an artifact, and that is deliberate. An examination under AT-C 205 tests whether the controls you described were suitably designed and — in a Type 2 — operated effectively over the period. If your control description says every vendor holds a SOC 2 report, the auditor tests that claim against your register, and every supplier without one becomes an exception you wrote yourself.
“Write the control you can operate, then operate it. A tiered process with three honest tiers passes; a universal requirement you quietly ignore for thirty vendors does not.”
— the readiness note we give clients before the control description is drafted
Tiering inputs
Four questions that set a vendor’s tier
Contract value is not one of them, and it is the input teams most often smuggle in. The largest line item on your supplier ledger is frequently Tier 3, and a free browser extension with an OAuth grant into your mailbox is frequently Tier 1.
1. Data sensitivity
What the vendor can actually reach — not what the contract permits. Production records, authentication secrets, payment data, health data and source code sit at the top; aggregated telemetry and public content sit far lower. Measure the worst record class they could touch on a bad day, not the average one.
2. Access level
Whether they hold a standing credential into your environment, and what it can do. A read-only, time-boxed support role is a different animal from a build-pipeline token that can push to production. Standing privileged access is the strongest single escalator, and the most routinely under-weighted, because the contract is usually cheap.
3. Availability dependence
What breaks for your customers if they are down four hours, or gone in ninety days. If your product cannot serve requests without them, they sit inside your availability commitment whether you named them or not. Concentration counts: three Tier 2 vendors in the same underlying region are one Tier 1 dependency.
4. Effect on your own commitments
Whether they perform part of the service you promised your customers. This decides more than the tier — it decides whether they are a subservice organization and must be disclosed in your own description. A vendor can be commercially trivial and still sit squarely inside your commitments.
Vague dimensions produce vague tiers, so put named examples against each band and score high, medium or low. The rubric below is the one we hand to clients; it is market practice rather than anything a standard prescribes, and its only real requirement is that you use the same one every time.
| Dimension | High | Medium | Low |
|---|---|---|---|
| Data sensitivity | Production customer records, authentication secrets or key material, cardholder data, protected health information, source code. | Internal business data, non-production copies that still contain real records, employee personal data. | Aggregated telemetry, public marketing content, anonymized usage counts. |
| Access level | A standing credential that can write to production, or a CI token that can deploy. | Scoped read access, or time-boxed support access granted on approval and expiring on its own. | No path into your environment at all — they receive nothing and hold no credential. |
| Availability dependence | Your product cannot serve requests without them. | Degraded but still serving; a workaround exists and can be stood up within days. | No customer-visible effect if they disappear tomorrow. |
| Effect on commitments | Performs part of the service you deliver — which is also the subservice organization test. | Supports delivery indirectly: tooling, monitoring, or a process your own staff operate around. | Internal back office, with no line to what you promised a customer. |
The tier is set by the highest single score rather than an average. One high is enough: a vendor holding nothing but a deploy token is Tier 1, and averaging that away is precisely how a privileged integration ends up in the moderate tier with a questionnaire against it. What matters to the auditor is that the method is written down, applied consistently, and produces a rationale you can point at eleven months later.
The tiering table
What is proportionate at each tier
Three tiers is enough for almost everyone. Five-tier models look rigorous and collapse in practice, because the middle tiers become indistinguishable and reviewers stop believing the boundaries. This table reflects market practice across enterprise vendor-risk programs; no standard prescribes these thresholds.
| Tier | What puts a vendor here | Proportionate assurance | Cadence & contract |
|---|---|---|---|
| Tier 1 — Critical | Production data, standing privileged access, or inside your service commitments | A current SOC 2 Type 2, or an ISO/IEC 27001:2022 certificate whose scope statement and Statement of Applicability cover the service you buy. Read it rather than filing it: map every complementary user entity control the report assigns to you. Where the report is Type 1, or the certificate scope is narrower than your usage, treat the difference as unassured and cover it with the Tier 2 measures. | Formal review annually and on material change; refreshed report or certificate each cycle; security schedule, breach-notification window, subprocessor-change notice, evidence or audit rights, and exit and data-return obligations in the contract. |
| Tier 2 — Moderate | Limited or non-production data, scoped access, or a dependency you could route around within days | A completed and dated questionnaire — CAIQ, SIG, or your own short form — plus contractual controls. Take an attestation where one exists; do not manufacture a requirement for one where it does not. A named owner, a written rationale for the tier, and evidence that someone read the answers are worth more than an unread report. | Annual or biennial questionnaire refresh; confidentiality, security-standard and breach-notification terms in the contract; re-tier on any change in data or access. |
| Tier 3 — Low | No access to your systems, no customer data, no bearing on availability or commitments | Register entry only: legal entity, owner, purpose, data classification, tier and the reason for it, approval date. No questionnaire, no report chase. Completeness is the point here, not depth — this tier is what proves the process discriminates rather than decorates. | Reconfirm the tier at the annual register review; no scheduled assessment unless the relationship changes. |
Two refinements are worth making explicit in the policy. First, a documented de minimis line — utilities, the landlord, the coffee supplier — so the register does not fill with entries that carry no information. Second, a rule that anything touching production data is Tier 1 regardless of how it scored on the other dimensions; the exceptions to that rule are the ones that hurt.
What the register has to carry
The tiering model only works if the register can carry the answer. These are the fields an auditor ends up asking for, and the reason each one exists. Anything beyond them is optional; anything missing from them turns into a request during fieldwork.
Legal entity name, and any trading name
The reconciliation to the accounts-payable ledger runs on the legal name. Trading names are where duplicate and missing entries hide.
Business owner
A named individual, not a team. The auditor tests approvals and reviews against this field, so an unowned row is an untestable row.
Business purpose
One line. It is what makes the tier rationale legible to somebody reading the register eleven months later.
Data classes touched
Record the worst class, not the average. This is the field the tier is most often argued from.
Access type and persistence
Standing or just-in-time, read or write, and into which environment. Standing write access to production is the single strongest escalator.
Tier, and the written rationale for it
Sampled directly. A tier assignment with no recorded reasoning is treated as no assessment at all.
Subservice organization: yes or no
Drives what has to appear in Section 3 of your own description, and which complementary subservice organization controls you must state.
Assurance artifact held, with its period or certificate expiry
The report period or certificate validity — not the date you downloaded the file. This is the field that makes staleness visible.
Date the questionnaire was returned
A questionnaire with no return date proves nothing about when the answers were true.
Contract reference, and whether a security schedule and a data-processing agreement exist
At the moderate tier the contract is the control. The auditor will ask to see the schedule, not the master agreement.
Breach-notification window, in hours
A number, so it can be compared against what your own customer commitments require you to pass on.
Subprocessor flag
Lets the register reconcile against the subprocessor list you publish and the annex to your data-processing agreements.
Onboarding approval date and approver
The approver must be someone other than the requester. Self-approval is one of the most commonly raised exceptions in this area.
Next review due date
The field that turns your stated cadence into something a sample can be drawn against.
Offboarding date, and the revocation ticket reference
A termination date with no revocation ticket is the classic offboarding exception: the relationship ended, the credential did not.
One thing the register does not do is watch. Point-in-time assurance and continuous signal answer different questions, and it is worth being explicit about which you are buying. Security-ratings platforms and breach-intelligence feeds observe attack surface visible from outside — certificate hygiene, exposed services, credentials in public dumps, incident reporting — which makes a downgrade a reasonable trigger for an off-cycle review of a Tier 1 vendor and an unreasonable substitute for the review itself, because none of it observes whether a control operated. And if you cite continuous monitoring in your control description, the auditor will test that somebody acted on the alerts, so only claim it if you have the tickets.
Regulatory overlays
When the answer is not risk-based
Everything above is proportionate. Some obligations are not. Where one of the regimes below applies to a relationship, the duty is fixed by law or by scheme rule and your tiering outcome does not lower it — a Tier 3 vendor that touches protected health information still needs a business associate agreement. Read this table as the floor beneath the risk model, not as a competing model.
| Regime | What it actually mandates | Does it require SOC 2? | Artifact that satisfies it |
|---|---|---|---|
| DORA — Regulation (EU) 2022/2554, applicable from 17 January 2025 | A maintained register of information covering every contractual arrangement for ICT services, mandatory contractual content under Article 30, and materially heavier requirements — including exit strategies and testing — where the arrangement supports a critical or important function. | No. The regulation names a register and contractual terms; it does not name an assurance report. | The register of information in the prescribed form, the executed clauses themselves, and evidence of the assessment that decided whether the function is critical or important. |
| GDPR Article 28 | A written contract with every processor carrying the Article 28(3) terms. Article 28(2) requires the controller to authorize sub-processors, and Article 28(4) requires equivalent obligations to be flowed down to them. | No. Article 28(3)(h) gives you information rights and audits or inspections; it names no report type. | The executed data-processing agreement, the sub-processor list with its change-notice mechanism, and the record of the authorization you gave. |
| HIPAA (US) | A Business Associate Agreement executed before protected health information is disclosed — 45 CFR 164.502(e) and 164.308(b) — with the required satisfactory assurances in writing. | No, and no report substitutes for the agreement. A HIPAA-focused SOC 2 does not discharge the BAA obligation. | The signed BAA, plus flow-down agreements wherever the business associate uses subcontractors that handle the same information. |
| PCI DSS v4.0, requirements 12.8.1 to 12.8.5 | Maintain a list of third-party service providers; hold written agreements in which they acknowledge responsibility for the cardholder data they hold, process or could affect; perform due diligence before engagement; monitor their compliance status at least once every 12 months; and keep a documented matrix of which requirements each party manages. | No. The usual artifact is the provider’s own Attestation of Compliance, not a SOC 2 report. | The TPSP list, the acknowledgement clauses, the current AOC or evidence of assessment, and the responsibility matrix. |
| US interagency third-party risk guidance (OCC, Federal Reserve, FDIC — June 2023) | Risk-based lifecycle management of third-party relationships: planning, due diligence and selection, contract negotiation, ongoing monitoring, and termination — with intensity proportionate to the risk of the activity. | No. It is principles-based and names no artifact. It binds the bank, and reaches you as a contractual demand when you sell into one. | Whatever your bank customer’s own program asks for — commonly a SOC 2 Type 2 plus their questionnaire, but as their contractual term rather than a regulatory requirement on you. |
The pattern in the third column is the point of the table. Five regimes, none of which names a SOC 2 report. What they mandate is a record, a contract, and evidence that somebody looked — which is the same shape as CC9.2, arrived at from a different direction. The practical consequence is that these obligations should be fields in your register rather than a parallel process: a business-associate flag, a subprocessor flag, a DORA criticality flag, a cardholder-data flag. Run them as a second dimension over one register and the reconciliation stays possible; run them as separate spreadsheets and they will diverge inside a year.
Worked example
A 43-vendor register, tiered
An illustrative case, not a client: a 60-person B2B SaaS company running its first twelve-month Type 2 over 1 January to 31 December 2026, with Security, Availability and Confidentiality in scope.
Step 1
Build the population
The register held 38 entries. Reconciling it against the accounts-payable ledger, corporate-card statements and applications registered in the identity provider surfaced five more — four SaaS tools bought on a card, one contractor engaged through a staffing firm. Final population: 43, and the reconciliation itself became the evidence of completeness.
Step 2
Apply the four questions
Five scored high on at least one dimension: the infrastructure provider, the managed database service, a document-parsing API receiving customer uploads, the payroll platform, and an observability vendor holding logs that include request payloads. Twelve landed in Tier 2. Twenty-six were Tier 3 — design tools, a job board, a scheduling app, e-signature used only for internal HR.
Step 3
Collect what the tier calls for
Three of the five Tier 1 vendors provided current SOC 2 Type 2 reports. One provided an ISO/IEC 27001:2022 certificate whose scope covered the platform and whose Statement of Applicability included the relevant Annex A controls. The document-parsing API had neither — twelve people, eighteen months old, holding customer uploads.
Step 4
Compensate on the one with neither
Exposure first: the integration was changed to strip identifiers before upload and hold parsed output for 24 hours rather than 30 days. Then a questionnaire dated 4 March 2026, a 90-minute architecture review, a security schedule with a 48-hour breach-notification window and an evidence right, a penetration-test summary dated November 2025 with two high findings closed, and two customer references. Risk accepted in writing by the CTO, re-assessment 4 March 2027.
Step 5
Separate the subservice question
Two of the five were subservice organizations — the infrastructure provider and the document-parsing API, whose controls are necessary in combination with the company’s own for the service commitments to be met. Both were disclosed in Section 3 under the carve-out method with complementary subservice organization controls stated. Payroll, though Tier 1 on data sensitivity, is not part of the service delivered to customers and is therefore not a subservice organization.
Step 6
Live with the result
The auditor tested all five Tier 1 reviews, five of the twelve Tier 2, five of the nine vendors onboarded in the period, and all three offboarded. One exception: a Tier 2 review due in Q3 2026 was completed on 14 February 2027, outside the period. Management’s response recorded the cause — one owner holding all twelve reviews — and the reassignment that followed.
What it costs to run. As a planning figure rather than a benchmark: a Tier 1 review takes roughly four to eight hours per vendor per cycle once you count reading the report, mapping its complementary user entity controls onto your own controls, checking the contract terms still match what you rely on, and logging the findings — plus another hour or two whenever something material changes mid-year. A Tier 2 review is 60 to 90 minutes: read the returned questionnaire, confirm the contractual terms, record the decision. Tier 3 costs minutes at the annual register review. Five Tier 1 and twelve Tier 2 vendors therefore comes to something like 50 to 60 hours a year — which one person can carry only if it is scheduled rather than remembered. That is exactly the exception this example produced: a single owner holding the whole Tier 2 list, which is the commonest cadence failure in this area and the easiest to fix once someone has written the number down.
Note what the report ended up saying. Not “all vendors hold SOC 2” — that would have been false and would have generated five exceptions. It said that vendors are tiered on documented criteria, that Tier 1 vendors are reviewed annually against available independent assurance, and that where such assurance is unavailable, compensating due diligence is performed and the residual risk accepted by an executive owner. All of which was true, and all of which was testable.
The distinction that decides your report
Vendor, or subservice organization?
Every subservice organization is a vendor. Almost no vendors are subservice organizations. The AICPA test is not size, spend, or sensitivity — it is reliance: a subservice organization is a vendor whose controls are necessary, in combination with your own, for you to provide reasonable assurance that your service commitments and system requirements were achieved.
| Question | Ordinary vendor | Subservice organization |
|---|---|---|
| Do you rely on their controls to meet your commitments? | No. You may buy something valuable from them, but your own controls stand alone. | Yes. Without their controls operating, your criteria cannot be met — this is the whole test. |
| Do they appear in your system description? | No requirement to name them. Your vendor-management control covers them generically. | Yes. DC section 200 requires the description to identify them, the functions they perform, and whether the carve-out or inclusive method is used. |
| Does your auditor do anything about them? | Tests your vendor-management control, not the vendor. | Under carve-out, tests your controls for monitoring them. Under the inclusive method, tests controls at the subservice organization itself. |
| Do complementary controls get stated? | No. | Yes — complementary subservice organization controls (CSOCs): the controls you assume they operate, stated so your readers can see the seam. |
| Typical examples | Payroll, corporate email, HR systems, the pen-test firm, design tools, a CRM used only by sales. | The IaaS or PaaS provider running production, a managed database service, a data-center colocation provider, a payment processor inside the flow you promised, an API that performs part of the delivered function. |
| What it means for your risk tier | Tiering is independent — an ordinary vendor can still be Tier 1 on data sensitivity. | Effectively always Tier 1, because a failure at the subservice organization is a failure of your service. |
The consequence people miss: carving a subservice organization out does not remove your obligation. Under the carve-out method the description excludes their controls from the scope of the opinion, but you are still expected to have controls that monitor them — typically obtaining and reviewing their own SOC report each year, tracking their exceptions, and confirming the CSOCs you rely on are still in place. Those monitoring controls are yours, they sit in Section 4, and they get tested. See subservice organizations and CUECs and CSOCs for the mechanics.
Decision tree
When a critical vendor has neither
This is the case that generates the real questions, and the honest answer is that a small, fast, well-run vendor may be genuinely better than a large one with a thick report. Work the gates in order — each one either lowers the risk or produces evidence you can show an auditor.
| Gate | If yes | If no |
|---|---|---|
| Gate 1Can you reduce the exposure instead of assuring it? | Do that first. Tokenize, cut the data set to the fields actually needed, replace standing access with just-in-time access, or put the integration behind a proxy you control. A vendor demoted to Tier 2 by design beats a Tier 1 vendor with a thick file. | Proceed to Gate 2 and record why the exposure is irreducible. |
| Gate 2Does any other independent assurance exist? | Take an adjacent artifact on its merits: ISO/IEC 27001:2022 with ISO/IEC 27017 or 27018, a PCI DSS Attestation of Compliance, HITRUST, FedRAMP or GovRAMP (formerly StateRAMP) authorization, or a parent report that demonstrably covers this entity and this service. Check scope before you check the logo, and check that the certification body is accredited before you credit the certificate. | Proceed to Gate 3. Absence of a report is not evidence of weakness — it is absence of evidence. |
| Gate 3Will they complete a questionnaire and sit for an architecture review? | Run both. A 90-minute walkthrough tells you more than any questionnaire, because you can ask the second question. The ten questions that actually discriminate are set out below the table. | This is itself a meaningful signal. Escalate it as a finding, not as a formality. |
| Gate 4Will they accept security terms in the contract? | Get them in writing: named minimum controls, a breach-notification window in hours, subprocessor-change notice, an evidence or audit right, deletion and return on exit, and liability not capped below the value of the data. | A refusal to commit contractually to controls they claim to operate is the clearest negative signal in the sequence. |
| Gate 5Can they evidence independent technical testing? | Ask for the executive summary of a penetration test performed in the last twelve months by a firm they do not own, plus remediation status for anything high or critical. A letter closing findings is more informative than a clean report. | Fund a test yourself under the audit right you negotiated at Gate 4, or scope your usage down until you can. |
| Gate 6Do reference checks from comparable customers hold up? | Ask two customers of similar size and data sensitivity how the vendor handled their last incident, their last outage and their last security review. Incident behavior is the reference that predicts. | Record the gap and raise monitoring: alerting on the integration, quarterly rather than annual review, and an exit plan you have actually rehearsed. |
Gate 3 in full: the ten questions that discriminate
A generic questionnaire produces generic answers. These ten are the ones that separate a vendor who has thought about the problem from one who has bought a policy template, and they are short enough to work through inside a 90-minute call.
- 01Tenancy model — shared schema, shared instance, or dedicated — and what technically separates one customer’s data from another’s.
- 02Who holds the encryption keys, and whether bring-your-own-key or hold-your-own-key is available on your plan rather than in principle.
- 03Who at the vendor can decrypt customer data, under what approval, and whether that access produces a log you can be shown.
- 04The joiner-mover-leaver process, and specifically what a leaver’s last day does to production access and to any shared credential.
- 05Where production data is replicated, and into which jurisdictions — including backups and disaster-recovery copies.
- 06The current subprocessor list, and the notice period before it changes.
- 07Default retention, and the shortest retention the product can actually be configured to.
- 08Log retention, and whether customer-facing access logs are available to you on request or only internally.
- 09The date of the last restore test, and the recovery time and recovery point it demonstrated — not the ones in the marketing page.
- 10The date and firm of the last penetration test, and the count of open high and critical findings today.
The answers are not assurance. They are a record of what the vendor asserted, on a date, in writing — which is what a compensating-controls file needs and what an unread questionnaire never produces.
It is worth naming the questionnaire artifacts rather than the category, because the names are what vendors recognize. The Consensus Assessments Initiative Questionnaire (CAIQ v4) is the Cloud Security Alliance’s standard form, aligned to the Cloud Controls Matrix v4; where a vendor has already published a Level 1 self-assessment to the CSA STAR Registry, that is the same content sitting in public, free to read before you ask them for anything. The Shared Assessments SIG comes in two useful sizes — SIG Lite for a first pass or a Tier 2 vendor, SIG Core when the vendor is Tier 1 and you need the detail behind the yes. A vendor’s trust center is a starting point rather than assurance: it tells you what they choose to publish, not what an independent party tested. Our note on SOC 2 and security questionnaires covers the same ground from the answering side.
The sequence ends in one of four places, and all four are defensible provided you write down which one you chose and why: accept with standard monitoring; accept with compensating controls and a dated re-assessment; accept with the scope of use reduced so the vendor no longer sits in Tier 1; or decline. What is not defensible is the fifth outcome — onboarding anyway, recording nothing, and discovering during fieldwork that the only artifact in the file is an invoice.
Scope of the examination
What your auditor actually tests
A frequent misunderstanding is that the CPA firm assesses your vendors. It does not. It examines your control over vendors — the one you wrote in Section 4 — for suitability of design and, in a Type 2, operating effectiveness across the period. Design testing asks whether the control as described would achieve CC9.2 if it operated: does it define tiers and the criteria for them, name an accountable owner, specify what happens before onboarding, state a review frequency per tier, and describe termination? A control that says vendors are “periodically reviewed” usually fails at design, because “periodically” cannot be tested.
Operating-effectiveness testing then samples the period through inquiry, inspection, observation and occasionally reperformance, and the things tested are almost always the same five: the register is complete, new vendors were assessed before onboarding, reviews occurred at the claimed frequency, any subservice organizations named in your description were monitored, and offboarding removed access and returned or destroyed data. None of it reaches into the vendor, which is exactly why a proportionate policy survives the examination and a maximal one does not — the auditor measures you against your own words, and short honest words are far easier to satisfy than long aspirational ones.
Fails at design
“Vendors are periodically reviewed for security posture.”
Passes at design
“All third parties are recorded in the vendor register and assigned a tier (1–3) using documented criteria covering data sensitivity, access, availability dependence and effect on service commitments. Tier 1 vendors are reviewed at least annually by the Security Lead against available independent assurance; where none exists, compensating due diligence is performed and the residual risk accepted in writing by an executive owner with a stated re-assessment date. Tier 2 vendors complete a security questionnaire on onboarding and at least biennially thereafter. Access and data are revoked within 5 business days of termination.”
The second passes for four reasons worth being explicit about. The population is defined — “all third parties” against a named register, so the completeness test has something to reconcile to. The frequency is testable against a calendar rather than against a feeling. The reviewer is named by role, so there is somebody whose records get sampled. And the failure branch is written down: what happens when no assurance exists is part of the control, not something improvised during fieldwork. Length is not what makes it work — specificity is.
Evidence
The evidence request, line by line
What the CPA firm asks for, how the population is defined and proved complete, roughly how much gets sampled, and what comes back rejected. Sample sizes are set by each firm from its own methodology and risk assessment — no AICPA publication prescribes them for SOC 2 — so treat the ranges below as what is commonly seen rather than as requirements.
| What is tested | Population & completeness | Typical sample | Commonly rejected |
|---|---|---|---|
| The register is complete | The register as at a date inside the period — with completeness proved from outside it. The auditor reconciles it to the accounts-payable ledger, corporate-card statements, applications registered in your identity provider, and cloud-marketplace spend. | Population-level. The auditor picks a handful of payees or SSO applications and traces each into the register, then works back the other way. | A spreadsheet with no version history. A GRC screenshot with no underlying record. Any register whose earliest entry post-dates the start of the period. |
| New vendors were assessed before onboarding | Every third party onboarded during the period — an event-driven population, so its size is whatever actually happened, often five to thirty for a growing company. | Usual practice is to test the whole population when it is small and sample when it is not. No AICPA publication prescribes SOC 2 sample sizes — firms set them from their own methodology and risk assessment. | Assessments dated after contract signature or after the integration went live. A tier with no recorded rationale. Approval by the person who requested the vendor. |
| Reviews happened at the stated cadence | Every vendor whose tier obliges a periodic review in the period — for most organizations the Tier 1 and Tier 2 lists, not the whole register. | Sized to the stated frequency. Ranges seen in practice run one for an annual control, two for quarterly, two to five for monthly, five to fifteen for weekly, twenty to forty for daily. Firm methodology, not a standard, and no governing body requires them. | A review completed after the period end for a review due inside it. A report obtained but never read — no CUEC mapping, no exception review, no reviewer, no date. |
| Subservice organizations were monitored | Every subservice organization named in Section 3 of your own description — a small, closed population the auditor reads straight off your description, so there is nowhere to hide an omission. | Tested in full. The auditor expects one review record per named subservice organization per period, and will compare the report period you reviewed against your own examination period to see whether the coverage actually overlaps. | The vendor report downloaded but no review record. A review that notes the opinion but not the exceptions. No confirmation that the complementary subservice organization controls you rely on are still operating. A report whose period ended before your period began, offered without a bridge letter. |
| Offboarding removed access and data | Every relationship terminated during the period, including trials and pilots that quietly lapsed. | Usually tested in full: the population is small and the failure mode severe. Expect the auditor to pull the ticket, not the policy. | Termination recorded in the register with no evidence the credential, API key or integration was revoked. A deletion clause offered as evidence that deletion occurred. |
The artifacts that get accepted without argument
A register export with a system-generated timestamp and change history. The executed agreement with its security schedule and any data-processing addendum. A completed questionnaire showing when it was returned and by whom. The vendor’s SOC 2 report together with your review record — reviewer, date, opinion noted, exceptions considered, complementary user entity controls mapped to your own. A dated approval by someone other than the requester. For offboarding, the ticket showing the credential revoked and confirmation of data return or destruction. The pattern is consistent: a record created at the time by a system, not a narrative assembled afterwards for the audit.
Edge cases
Where this gets contested
The tiering model handles most of a register without discussion. These are the cases that produce the meetings.
The report exists, but the boundary excludes what you buy
A vendor operates six products and the description in Section 3 covers two. The opinion is clean and irrelevant to you. Check the system name, the legal entity and the environment before you check the opinion — a clean report on the wrong system assures nothing about your risk.
ISO 27001 certified, but the certificate is narrow
An ISO/IEC 27001:2022 certificate carries a scope statement that can legitimately cover one site, one product line or one entity. Read it, then ask for the Statement of Applicability, then check that the certification body itself is accredited by a recognized accreditation body — unaccredited certificates exist. A certificate covering a head-office ISMS tells you little about the platform your data sits on.
The report is Type 1, or the period ended long ago
A Type 1 speaks to design at a point in time and nothing about operation. A Type 2 whose period ended more than twelve months ago is treated as lapsed by most enterprise programs — comfortable to about six months past period end, bridge-letter territory from six to twelve, out of date beyond that. Neither is a reason to reject the vendor — record what is unassured and cover it: a bridge letter for a short gap, compensating measures for a long one.
The opinion is qualified
A qualification is not automatic disqualification. Read what it touches: a qualification on a criterion irrelevant to your use is a different matter from one on logical access, and management’s response and remediation timeline usually tell you more than the qualification itself.
AI and model providers added mid-period
Inference providers move faster than procurement and often arrive behind a feature flag. Treat the provider as a vendor in the ordinary way, ask specifically about training-data use and retention, and decide whether it sits inside your service commitments before a customer asks you.
Open source and unpaid dependencies
There is no counterparty to question and no contract to negotiate. This is a supply-chain control problem, not a vendor-assessment one: dependency inventory, provenance and signature verification, pinned versions, patch cadence. Say so in your control description rather than implying the vendor process covers it.
Staffing firms, contractors and outsourced engineering
People-based arrangements are often the largest unassessed exposure on a register. If the contractor works under your controls — your laptop, your identity provider, your review process — you are testing your own controls. If the supplier manages the work under its own controls, it may well be a subservice organization.
Your vendor’s vendor
Fourth-party risk is real and rarely tractable directly. The usable levers are contractual: subprocessor lists, notice of change, flow-down obligations. Where a Tier 1 vendor’s own report carves out its infrastructure provider, you inherit the job of forming a view on that provider too.
The vendor will not share the report
SOC 2 reports are restricted-use, so a request for an NDA is normal and not a red flag. A refusal to share under NDA is. Where only a SOC 3 is offered, take it as a starting point and know what you are not getting: no Section 4 matrix, no exceptions, no complementary user entity controls.
Objection handling
What buyers push back on, and the answer
These arrive in security questionnaires and in the call afterwards. The answers below continue the illustrative example above, worded as the service organization would say them. In every case the strong answer is the specific one.
“Twelve of your vendors have no SOC 2 report.”
Correct, and none of them are Tier 1. Here is the tiering method, the dimension each of those twelve scored on, and the questionnaire and contractual terms that apply at that tier. Requiring an attestation from a design-tool subscription would not reduce your risk — it would only make the register longer.
“Our policy requires SOC 2 from all subprocessors.”
Then let us reconcile lists rather than argue about policy. Subprocessors — the parties that process your data — are a much narrower set than the vendor register. Here is that subset, the assurance held for each, and the compensating due diligence where none exists. Most policies of this kind are satisfied once the actual list is on the table.
“Our MSA requires SOC 2 from every subprocessor, and yours does not have one.”
Then the contract settles it before the risk model does, and the honest move is to check what was already signed. Reconcile three lists — the vendor register, the published subprocessor list, and the annex to the data-processing agreement — and identify precisely where the gap sits. Where one exists, ask for a written waiver with the compensating-controls file attached and a re-assessment date, rather than back-filling the register so the gap disappears. A documented waiver reads as a control operating; a retrospective edit reads as an integrity question, and auditors treat the two very differently.
“Why is the document-parsing API not covered by an attestation?”
Because they are twelve people and have not commissioned one. Here is what was done instead: reduced what they receive, reviewed their architecture, put minimum controls and a 48-hour notification window in the contract with an evidence right, obtained their penetration-test summary and remediation status, and had the CTO accept the residual risk in writing with a review date. That file is available under NDA.
“Your penetration test was performed by a firm you have a commercial relationship with.”
A fair challenge, and the answer is evidence rather than assertion. The position stated plainly: here is the firm, here is the nature of the relationship, and here are the scope document and the remediation letter so you can judge the work rather than the affiliation. Where independence genuinely cannot be demonstrated, the proportionate response is to rotate the tester next cycle or commission a second test against the highest-risk component — not to argue the point.
“Your vendor scores a C on our security-ratings platform.”
Ratings platforms measure attack surface observable from outside — certificate hygiene, exposed services, credentials in public dumps, published breach reporting. That makes a downgrade a good trigger for an off-cycle review and a poor substitute for one, because none of it observes whether a control operated over a period. Here is what the review found when the downgrade triggered one, what was remediated, and by when. If a rating were sufficient on its own, nobody would need an examination.
“Your auditor did not test your vendors.”
No auditor does. An examination under AT-C 205 tests the service organization’s own controls. Where a vendor’s controls are necessary for our commitments, they are a subservice organization and appear in Section 3 with the complementary subservice organization controls stated. For every other vendor, what is tested is the vendor-management control itself.
One note on where we sit. Tranquility Cybersecurity builds the vendor-risk process, tiers the register, drafts the control description so it is testable, and assembles the evidence — and coordinates the examination through independent licensed CPA firms. The opinion always comes from the CPA firm; we never certify, attest or sign. If you are starting from a spreadsheet and a deadline, the SOC 2 services overview sets out how that works, at a fixed fee from $4,000 for early-stage startups quoted after scoping, with the CPA firm’s attestation fee billed separately.
Vendor Assurance — Common Questions
Tiering, subservice organizations, and what happens when the report does not exist.
Do all my vendors need to be SOC 2 compliant?
No, and no trust services criterion requires it. CC9.2 requires that you assess and manage the risks vendors and business partners represent to your objectives — a process obligation, not a requirement that suppliers hold a particular report. Strictly there is no such thing as being "SOC 2 compliant" either: a SOC 2 is an attestation report on a stated period, not a certification or a status anyone holds. A well-run program asks for a SOC 2 Type 2 or a scope-checked ISO/IEC 27001:2022 certificate at the critical tier, a dated questionnaire plus contractual controls at the moderate tier, and nothing beyond a register entry at the low tier. Applying the top tier to everything is the most common sign of an immature program.
What makes a vendor critical rather than moderate?
Four things, and contract value is not among them: the sensitivity of data they can reach, the level and persistence of their access to your systems, how far your availability depends on them, and whether they perform part of the service you promised your own customers. Score each high, medium or low against named examples — production records and key material are high on sensitivity, a standing credential that can write to production is high on access — and set the tier by the highest single score rather than an average. Write the method down, apply it consistently, and record the rationale for each assignment, because that record is what the auditor samples.
What do we do if a critical vendor has no SOC 2 and no ISO 27001?
Work through it in order. Reduce the exposure first — minimize the data, shorten retention, replace standing access with just-in-time access. Then look for adjacent assurance: PCI DSS, HITRUST, FedRAMP or GovRAMP, ISO/IEC 27017. If none exists, compensate with a completed questionnaire, an architecture review covering tenancy, key custody, joiner-mover-leaver, replication, retention and restore testing, contractual security terms carrying breach-notification and audit rights, a recent independent penetration-test summary with remediation status, and reference checks. Finish by naming an executive risk owner, recording the acceptance in writing and setting a re-assessment date. Documented compensating due diligence is defensible; an empty file is not.
What is the difference between a vendor and a subservice organization?
Reliance. A subservice organization is a vendor whose controls are necessary, in combination with your own, for you to provide reasonable assurance that your service commitments and system requirements were achieved. An ordinary vendor may hold highly sensitive data and still not meet that test — payroll is the classic example. The distinction matters because DC section 200 requires your system description to identify subservice organizations, the functions they perform, whether you use the carve-out or inclusive method, and the complementary subservice organization controls you assume they operate.
Does carving out a subservice organization remove our responsibility?
No. Carve-out excludes the subservice organization’s controls from the scope of the opinion and describes them as complementary subservice organization controls instead. You are still expected to operate controls that monitor them — typically obtaining and reviewing their SOC report annually, reading their exceptions, and confirming the controls you rely on remain in place. Those monitoring controls are yours, they appear in Section 4, and they are tested like any other — usually in full, because the population is simply the list you named in Section 3. Carve-out changes what the auditor examines at the vendor, not what you are answerable for.
Is ISO 27001 an acceptable substitute for SOC 2 from a vendor?
Usually yes, provided you check the scope and the accreditation. ISO/IEC 27001:2022 certification is issued by a certification body against a management system — check the body is accredited by an IAF-recognized accreditation body, because unaccredited certificates exist. Ask for the certificate, the scope statement and the Statement of Applicability, then confirm the service you buy sits inside all three; a scope statement can legitimately cover only one site, entity or product line. A SOC 2 tells you more about how specific controls operated over a period; an ISO certificate tells you more about the durability of the management system. Both are reasonable Tier 1 evidence.
Does any regulation actually require our vendors to hold a SOC 2?
None that we are aware of. DORA requires a register of information and specific contractual content under Article 30; GDPR Article 28 requires a written processor contract with defined terms, authorization of sub-processors and flow-down of equivalent obligations; HIPAA requires a business associate agreement before protected health information is disclosed; PCI DSS v4.0 requirements 12.8.1 to 12.8.5 require a provider list, written acknowledgements, due diligence, at least annual monitoring of compliance status and a responsibility matrix. Each mandates a record, a contract and evidence that somebody looked. None names a SOC 2 report. Where these apply, though, the obligation is fixed regardless of the tier your risk model produced.
How many vendors should be in the top tier?
There is no rule, but a register where more than roughly a fifth of entries sit at the top usually means the criteria are not discriminating. For a mid-sized SaaS company with forty to sixty third parties, four to eight critical vendors is a common shape: infrastructure, a managed data service, one or two integrations touching production data, and often payroll. If nearly everything is critical, the tier has stopped carrying information and the review workload makes the cadence unachievable — at roughly four to eight hours per Tier 1 review per cycle, twenty critical vendors is most of a full-time month, which is precisely how cadence exceptions get created.
Does the auditor review our vendors’ SOC 2 reports?
Not the vendors themselves. The auditor tests your control, so what gets inspected is your review record: which report you obtained, its period and opinion, who read it and when, what exceptions were noted, and how the complementary user entity controls it assigns to you map onto your own controls. Expect the report period to be compared against your own examination period to see whether the coverage overlaps at all. A report sitting in a folder with no review record is the single most commonly rejected artifact in this area. Obtaining the report is not the control; reading it and acting on it is.
How do we prove our vendor register is complete?
From outside the register. Auditors reconcile it against sources not maintained by the same process: the accounts-payable ledger, corporate-card statements, applications registered in your identity provider, and cloud-marketplace spend. Expect that reconciliation to surface entries you did not have — free tiers, tools bought on a card, contractors engaged through a staffing firm. Finding them is the point. Adding them with the date you found them is correct; back-dating the register so the gap disappears turns a routine finding into an integrity problem.
Related reading: subservice organizations, CUECs and CSOCs, certified versus attested, how to read a SOC 2 report, how long a report stays usable, opinions and exceptions, the Trust Services Criteria, and the ISO 27001 hub.
Written By Expert Auditors
Keep Exploring
Related Reading
Subservice Organizations
Carve-out vs inclusive — how your vendors' vendors appear in the report.
Read moreOur Cloud Provider Has SOC 2 — Why Do We Need One?
The shared-responsibility split, and the CUECs your provider’s own report assigns to you.
Read moreDoes SOC 2 Replace Security Questionnaires?
What the report answers, what it never could, and how to use it to compress a questionnaire.
Read moreCarve-Out vs Inclusive Method
How subservice organisations are described and tested — and what carve-out does not let you avoid.
Read moreSOC 2 Knowledge Hub
Type 1 vs Type 2, criteria, timelines and audit prep — all guides.
Read moreISO 27001 Overview
The ISMS standard — the baseline certificate global buyers ask for.
Read moreGet in touch
Book a free consultation or send us your requirements. We respond within 24 hours.
Quick Call
Pick a time slot
Send Requirements
Get a custom quote in 24 hours