SOC 2 vendor management when you cannot get their SOC 2 report

You need to review your vendors’ SOC 2 reports. Half your vendors gate them behind enterprise pricing tiers you don’t qualify for.

This is one of the most frustrating parts of going through a SOC 2 audit as a smaller company. The CC9.2 criteria specifically requires you to assess and manage risks from third-party vendors. Your auditor expects evidence that you did this work. But the actual mechanism for getting that evidence from vendors? Nobody standardized it, and vendors treat their SOC 2 reports like classified documents.

At Tallyfy, we run a SOC 2 Type 2 audit annually, and this problem comes up every single cycle. Some vendors hand over their reports within a day. Others require an NDA, a formal request through their sales team, and three weeks of follow-up. A few just never respond. You still need to show your auditor that you did due diligence on all of them, and that is where the formal review alternative comes in.

The vendor SOC 2 access problem

SOC 2 reports are intentionally confidential documents. They contain detailed descriptions of a company’s internal controls, and sharing them publicly would essentially hand attackers a blueprint of the security architecture. That confidentiality is by design, not a flaw.

But confidentiality has turned into gatekeeping.

What you encounter in practice: vendors who only share reports with enterprise-tier customers. Vendors who require mutual NDAs before sending a PDF. Vendors whose security team takes weeks to respond. Startups that haven’t been audited yet but handle your data. Open-source tools with no corporate entity to even ask.

The AICPA doesn’t mandate that you obtain a SOC 2 report from every vendor. What CC9.2 actually requires is that you establish a process for assessing vendor risks, assign accountability, and document your findings. The report is one way to gather evidence. Not the only way.

Your auditor cares about the process. The same principle applies to mapping controls to evidence throughout your compliance program. Can you demonstrate that you identified your vendors, categorized them by risk, and assessed their security posture? If so, you’re meeting the criteria. The requirement is the assessment, not the specific artifact.

The formal review alternative

When a vendor won’t share their SOC 2 report, you build your own assessment from publicly available information. This isn’t a lesser option. Done properly, it satisfies auditors because it shows you did the work rather than just downloading a PDF and filing it.

Here is the structure we use. For each vendor, we create a formal review document that covers published certifications, trust center content, data processing agreements, and an assessment of what complementary user entity controls apply.

The review starts with checking the vendor’s trust center or security page. Most SaaS companies maintain a public trust center that lists their certifications, compliance status, and sometimes even summaries of their SOC 2 scope. You document what you find there. If they list SOC 2 Type 2, that tells you they’ve been through the audit even if you can’t read the full report.

Then you review their data processing agreement or terms of service for security commitments. What do they promise about encryption, access controls, incident notification, and data retention? These contractual obligations are enforceable evidence of their security posture.

You can also send a security questionnaire. The SIG questionnaire from Shared Assessments is one of the more widely recognized standards, with a lite version covering 126 questions and a core version at 855. Not every vendor will complete one, but asking and documenting their response (or non-response) is itself part of your due diligence record.

The final review document includes: vendor name, review date, tier classification, published certifications found, trust center URL and what it disclosed, DPA review notes, questionnaire responses, and your conclusion about residual risk. That conclusion is the part your auditor reads most carefully. It shows you actually thought about the risk rather than just checking a box.

Structured vendor compliance review format

If you’ve set up your compliance system in a Git repo, these review documents get version-tracked automatically alongside your other evidence.

Vendor tiering by risk

Not every vendor deserves the same level of scrutiny. Your email marketing tool and your cloud infrastructure provider present wildly different risk profiles. Treating them the same wastes time and annoys your auditor, who knows the difference.

Tier 1 vendors are high risk. They process customer PII, have production access, or store regulated data. Think AWS, your database provider, your authentication service. For these, you really do need the full SOC 2 report. If they won’t provide it, that’s a finding to escalate internally. At Tallyfy, our Tier 1 vendors like AWS and Cloudflare provide their reports, and we review them on a regular cadence.

Tier 2 vendors are medium risk. They touch internal data or have limited system access but don’t directly handle customer PII. Your project management tool, your CI/CD platform, your monitoring service. The formal review based on public compliance docs works here. Check the trust center, review the DPA, document findings.

Tier 3 vendors are low risk. No data access, utility-level services. Your domain registrar, your font CDN, your analytics snippet. A one-line entry noting “no data access, low risk, basic verification completed” satisfies most auditors.

The tiering itself is evidence. Understanding what SOC 2 actually requires helps you calibrate the depth of each tier. When your auditor sees risk-based classification with proportional assessment depth, that demonstrates exactly what CC9.2 expects. Document the criteria for each tier explicitly so the classification is repeatable and defensible.

What to look for in public compliance docs

When you’re reviewing a vendor’s public security information instead of their actual SOC 2 report, you need to know what matters and what is marketing noise. Understanding what a SOC 2 report actually contains helps you evaluate what the public disclosures are telling you versus what they’re leaving out.

Start with certifications. SOC 2 Type 2 is the gold standard for service organizations, but ISO 27001, PCI DSS, HIPAA compliance, and FedRAMP authorization all tell you something meaningful about their security maturity. A company with ISO 27001 has been through a formal audit by an accredited body, which provides real assurance even without seeing their SOC 2 report.

Look at their subprocessor list. Most companies publish this for GDPR compliance. It tells you who else touches the data you’re entrusting to this vendor. If your Tier 2 vendor is shipping data to five subprocessors you’ve never heard of, that changes the risk calculation.

Check their incident disclosure history. Published post-mortems and status pages with historical uptime data are stronger signals than polished security marketing. Transparency about failures tells you more than carefully worded trust pages.

Watch out for vague language. “We take security seriously” means nothing. “SOC 2 Type 2 report available upon request under NDA” tells you something specific. “Enterprise-grade security” is marketing fluff, while “AES-256 encryption at rest with customer-managed keys available” is a concrete commitment you can verify.

The AICPA’s trust services criteria provide a framework for evaluating vendor disclosures. Map what they claim back to these criteria. Do they address availability? Processing integrity? Confidentiality? The more criteria they cover with specifics, the more confident you can be.

Tracking vendor compliance over time

Point-in-time assessments are necessary but not sufficient. Your auditor expects ongoing monitoring, and so does the CC9.2 framework. A vendor that looked fine a year ago might have had a breach, changed ownership, or let certifications lapse.

Set a review cadence tied to your vendor tiers. Tier 1 vendors get reviewed every 180 days, with updated SOC 2 reports or bridge letters for gap periods. Tier 2 vendors get an annual review. Revisit their trust center, check for new certifications or disclosed incidents, update your review document. Tier 3 vendors get a quick annual check that they still exist and haven’t made breach headlines.

If you’re using AI tools in your compliance workflow, vendor review refreshes are one of the best places to apply them. Have the AI compare this year’s trust center content against last year’s and flag anything that changed. That differential analysis takes hours manually and minutes with AI.

Keep a log of vendor communications. When you requested a report, when they responded, what they provided. A vendor that ignores three consecutive requests is information your auditor wants to see.

Third-party SOC 2 report tracking with refresh cycles

The hardest part isn’t the initial assessment. It’s doing it again next cycle. Build the cadence into your operations with a workflow automation tool, calendar reminders, or a spreadsheet with due dates. The system matters less than the habit.

• Need help with this? Let’s talk.