We’ve all seen the dog-and-pony shows. A vendor’s slide deck on their “enterprise-grade, multi-layered security” is about as trustworthy as a cloud provider’s list price. It’s theater. Yet, when you’re drafting an RFP for a SaaS platform that will hold customer data, you have to cut through the marketing fluff.
So, how do you actually evaluate a vendor’s *internal* security posture without just taking their word for it? Asking for a generic SOC 2 report is table stakes, but it’s a snapshot from a year ago. I want to know what’s happening *now*, and how it impacts my bill and my risk.
My usual starting point is to demand concrete, auditable evidence in the RFP response itself. I structure the security section to force specifics:
* **Break down the SOC 2.** Require them to provide the actual report (Type II, of course) and map its controls directly to your requirements. Ask for a log of *all* security exceptions and incidents noted during the audit period. If they balk, that’s your answer.
* **Penetration test transparency.** Demand the executive summary and a sample of findings from their most recent *third-party* pen test. I don’t need the full report, but I need to see they actually fix things. Ask: “What was your most critical finding in the last 24 months, and how long did it take to remediate?”
* **The real cost of their negligence.** Tie security to business continuity. Ask for their historical uptime/SLA credits *specifically related to security incidents* (e.g., DDoS, breach response). If their security fails, does my cost go up due to downtime? That’s a financial risk, not just a technical one.
* **Employee access.** How do they handle internal privilege escalation? Can their support staff access my data without my knowledge? Demand a clear description of their JIT (Just-In-Time) access and logging controls.
The goal is to move from checkbox compliance to operational reality. If their security is sloppy, they’re likely inefficient elsewhere—and inefficiency eventually gets passed on to me as a price hike. I’m not just buying a service; I’m buying their operational discipline.
What specific questions or evidence clauses have others here baked into their RFPs that actually got revealing answers?
-auditor
Show me the bill
I'm in marketing ops at a mid-size SaaS company, we push customer data between HubSpot, Snowflake, and our own platform. We vet a lot of tools and have to sign BAAs.
My approach is a mix of forced evidence and operational questions they hate:
**Real-time audit access.** Beyond the SOC 2 PDF, require a shared link to their *current* compliance dashboard (like Vanta, Drata). We got one vendor to give us view-only access. It showed 5 open minor findings, which was actually a green flag - it proved the tool was in use.
**Incident response runbook.** Ask for the actual playbook they use internally for a P1 security event. Not a summary - the doc. Its freshness date and detail level tell you more than any attestation. A vendor shared theirs and it included a 12-minute SLA for internal alerting, which was solid.
**Engineering hiring screen.** Require them to detail the security section of their engineering onboarding. We saw one that was just a 10-minute video; another had a mandatory, scored module. This shows if security is a culture or a checkbox.
**Third-party dependency list.** Make them list their top 5 critical sub-processors (like cloud, monitoring, email infra) *and* provide evidence those vendors are audited to the same standard. One vendor's "enterprise" platform relied on a small logging tool with no SOC 2 - that was a no-go.
I'd recommend starting with the runbook request. It's a concrete document that separates the prepared from the performative. If the OP can share their data classification level and whether they need real-time audit access, I could narrow it further.
Thanks!
Your point about the third-party dependency list is critical, but I'd push you to go deeper than just the top five sub-processors. The real risk often lies in the transitive dependencies. I require vendors to disclose their *observability stack* specifically: which tools have broad data access (like APM agents, log aggregators) and where that telemetry data is sent. A vendor using a popular cloud monitoring service might be piping your data through a processor you haven't approved.
the freshness of that list is a direct proxy for their internal governance. Ask for the date of the last review and the process for adding a new sub-processor. A static PDF from six months ago is useless. The ideal answer is a link to a live, internally maintained registry that their security team updates as part of their change management, which you can sometimes infer from their compliance dashboard access if they grant it.