Requesting a SOC 2 report should be boring. In practice it becomes a thread of "which email?", "wrong PDF," and "we only send that after NDA." A little structure on your side—and knowing where the vendor publishes instructions—cuts most of the noise.
Find the trust center first
Before you open a ticket, check whether the vendor publishes a trust or security portal. That page usually states:
- Which reports exist (SOC 2 Type I/II, ISO, PCI, etc.)
- Whether reports are public, gated, or NDA-only
- A submission form or security@ contact for diligence
If you are reviewing many vendors, use TrustLists to jump straight to known trust center URLs instead of guessing hostnames.
Use the channel the vendor specifies
Enterprise security teams often have a preferred email template. Vendors, in turn, route requests through systems that track NDAs and watermark PDFs. Sending your template to a random AE may work, but it is slower. Follow their process when one exists.
Ask for scope, not just the report name
In your request, name what you need clearly:
- Type I vs. Type II
- Report period end date (or point-in-time date for Type I)
- Whether subservice organizations are carved in or out
- Any Trust Services Categories you care about (e.g., Security + Availability)
That specificity reduces back-and-forth and signals that someone on your side will actually read the document.
NDA and handling
Most SOC 2 detailed reports are shared under confidentiality. Align with your legal team on standard terms so you are not negotiating a one-off NDA per vendor for routine reviews. Store the PDF in your GRC or document system with version metadata.
Log the decision
After review, record a concise outcome: accepted with conditions, accepted, or escalated. Future-you—and your auditors—will want to know why a vendor passed, not only that a PDF existed.
When you cannot get a report
Early-stage vendors may only have Type I or a bridge letter. Decide in advance how your program handles those cases (additional testing, shorter contract term, contractual audit rights). Publishing that policy internally avoids one-off exceptions becoming the default.
TrustLists does not host vendor reports. It helps you find where vendors publish compliance information and request flows.