Nearly every B2B SaaS vendor now has a dedicated security or trust page, often accompanied by a row of compliance badges and reassuring language about encryption and protection. These pages have become a standard part of the sales process, which also means they've become a standard part of the marketing process, and not everything on them carries equal weight for an actual buyer trying to assess real risk.
Compliance badges tell you a process was followed, not that the product is secure
SOC 2, ISO 27001, and similar certifications are genuinely valuable signals, but what they certify is often misunderstood. These frameworks primarily verify that a company has documented security processes and controls in place and follows them consistently, not that the underlying product is free of vulnerabilities or architecturally sound. A vendor can hold a valid SOC 2 report and still have meaningful security weaknesses in areas the specific audit scope didn't cover.
The more useful question isn't just whether a certification exists, but what its actual scope covers. SOC 2 reports come in different types, Type I assesses controls at a point in time, Type II assesses whether those controls were operating effectively over a period, typically six to twelve months, which is a meaningfully stronger signal. Asking to see the actual report, most vendors will share it under NDA, rather than just noting the badge exists, reveals scope details that the marketing page alone won't show.
Encryption claims need to specify what's actually encrypted, and when
"We use encryption" is close to meaningless as a standalone claim, since nearly every modern service encrypts data in transit by default at this point. The more meaningful distinctions are whether data is encrypted at rest, not just in transit, whether encryption keys are managed by the vendor or by the customer, and whether the vendor technically has the ability to decrypt customer data or has architected the system so they genuinely cannot.
Vendor-managed encryption keys mean the vendor retains technical access to decrypt customer data even if their policies say they won't. Customer-managed keys, where available, provide a structurally stronger guarantee, since decryption becomes technically impossible for the vendor even under a policy violation or compromised access scenario. Few vendors offer this, but its absence or presence is a much more meaningful data point than the generic presence of encryption.
Sub-processor lists reveal the real data flow, not just the primary vendor
Most SaaS products depend on a chain of sub-processors, cloud infrastructure providers, email delivery services, analytics tools, customer support platforms, each of which may touch customer data in some form. A vendor's security posture is only as strong as the weakest link in this chain, and the primary vendor's own security page rarely makes this chain obvious without deliberately looking for their sub-processor disclosure, which regulations like GDPR generally require vendors to maintain and make available.
Reviewing this list specifically for any sub-processors that handle sensitive data categories, and checking whether those sub-processors carry their own adequate certifications, provides visibility that the primary vendor's marketing page is unlikely to volunteer prominently on its own.
Incident history and disclosure practices are a stronger signal than a clean marketing page
A vendor's security page will understandably never lead with past incidents. But a vendor's actual track record on past security incidents, and specifically how transparently and promptly they disclosed them when they occurred, is a more informative signal about real security culture than the current state of their marketing page. A public post-incident report that clearly explains what happened and what changed as a result is a genuinely positive signal, arguably more informative than a spotless page with no incident history at all, particularly for vendors that have been operating long enough that a completely clean record starts to seem statistically unlikely.
Searching for the vendor's name alongside terms like "security incident" or "data breach" as a standard part of due diligence, rather than relying solely on what the vendor chooses to publish about themselves, fills in a gap the marketing page structurally can't cover.
Data residency and deletion practices matter more than most buyers check
Where data is physically processed and stored, and what actually happens to it after a contract ends, are practical questions that matter enormously for compliance but are often addressed only vaguely on a security page, if at all. Confirming specific data center regions, whether data residency commitments are contractually guaranteed rather than just described as a default, and what the actual data deletion process and timeline looks like after offboarding, requires going past the marketing page and into the actual contract or a direct conversation with the vendor's security team.
A practical approach to evaluation
The security page is a reasonable starting point for identifying what to ask about, but it functions more as an index than as a complete answer. The higher-value information, actual audit report scope, sub-processor details, real incident history, and specific data handling practices, generally requires going one layer deeper than what's published for general marketing purposes. Vendors serious about security are typically willing and prepared to provide this deeper information when asked directly; reluctance to do so is itself a meaningful signal worth weighing in the evaluation.
Top comments (0)