Security and Compliance for B2B SaaS Customer Support: What to Verify (2026)

Last Updated
Published On
TL;DR
If you sell software to other businesses, your support tool holds some of your most sensitive data: customer conversations, account context, and the API tokens and logs customers paste when something breaks. So the real evaluation question is not “which inbox is nicest” — it’s “can I put regulated customer data in here and defend that to a security reviewer?” Here’s what to verify, and where each item tends to break down.
If your blocker is… | Verify this | What to ask the vendor for | Plain’s answer |
|---|---|---|---|
“Is it actually audited?” | SOC 2 Type II (not just a badge) | The current Type II report + bridge letter | SOC 2 Type II; report on request via Trust Center |
“Can I sign a DPA / handle EU data?” | GDPR posture, SCCs, DPA | A signable DPA and SCC/IDTA terms | Signable DPA, EU SCCs, UK IDTA, EU representative |
“Will they train AI on our data?” | A contractual no-training clause | The exact DPA language | DPA states customer data is not used to train AI/ML models |
“Can we enforce SSO?” | SSO / SAML / SCIM | Which plan, and the setup docs | SSO, SAML, SCIM via WorkOS (Frontier plan) |
“Who else touches the data?” | Subprocessor transparency | The list + change-notice policy | Public subprocessor list with advance notice |
The pattern across a security-driven evaluation is simple: the vendors that win are the ones that can hand you proof early, without a six-week procurement fight. Plain is built for that buyer.
Why security is now an upmarket gate, not a footnote
Across 2,216 conversations with B2B support leaders and engineers between June 2025 and June 2026, security and compliance requirements showed up as a recurring gate rather than a nice-to-have — and they concentrated upmarket. Among larger evaluations, questions about SOC 2, GDPR, and SSO surfaced far more often than in early-stage deals, and they tended to arrive early, from a security reviewer rather than the support team itself.
The takeaway for your own process: if you’re selling into mid-market and enterprise, the support tool you pick will be dragged through the same vendor-security review as the rest of your stack. It pays to evaluate it that way from the start, rather than discovering the gap when a prospect’s InfoSec team asks for a report you don’t have.
Three patterns from those conversations are worth planning around:
Security arrives early, and from a different person. In upmarket evaluations the SOC 2 / GDPR questions tend to come from a security reviewer near the start of the process, not from the support lead at the end. If your tool can’t produce a report on request, that’s where the deal stalls — quietly.
SSO is a hard requirement, not a preference. Among the larger evaluations, the ability to enforce single sign-on and provision users through a directory came up repeatedly as a gate — teams that standardize identity across their stack won’t make an exception for support.
“Will you train AI on our data?” is the new question. As support tools became AI-native, a specific objection surfaced that didn’t exist two years ago: buyers now want the no-training commitment in the contract, not just implied. It’s the first thing a careful reviewer greps the DPA for.
This guide is the checklist we’d want in that seat, followed by exactly how Plain, the AI-native Customer Infrastructure Platform, answers each item. Where something is plan-specific, we say so. Where Plain doesn’t offer something, we say that too.
What should you verify before trusting a support vendor?
Verify six things. Most “enterprise-ready” claims fall apart under these direct questions.
# | Criterion | Why it matters | What to ask for |
|---|---|---|---|
1 | Independent audit | A badge isn’t a report; Type II tests controls over time, not at one moment | The current SOC 2 Type II report (or ISO 27001) |
2 | Data protection posture | Determines whether you can lawfully process EU/UK and regulated data | A signable DPA + SCC/IDTA terms |
3 | AI data usage | AI-native tools can quietly reuse your data to train models | The exact no-training clause in the DPA |
4 | Encryption | Table stakes, but confirm it’s default at rest and in transit | The encryption statement in the security docs |
5 | Access controls | You need enforceable SSO and scoped, least-privilege access | SSO plan tier + a roles/permissions model |
6 | Subprocessor transparency | You inherit every vendor your vendor uses | The subprocessor list + change-notice policy |
If a vendor can’t answer these plainly, that’s usually your answer.
What’s the difference between SOC 2 Type I and Type II?
A Type I report says the controls were designed correctly on a single day. A Type II report says they actually operated correctly across a monitoring period (typically 3–12 months). Type II is the one a serious security reviewer wants, because it’s evidence of sustained practice rather than a point-in-time snapshot. When a vendor says “SOC 2,” ask which type — the difference is the whole point.
Is Plain SOC 2 compliant?
Yes. Plain is SOC 2 Type II certified — an independent auditor has verified how Plain manages security, availability, and confidentiality over a monitoring period, not just at a single point in time. The current SOC 2 Type II report, a SOC 2 bridge letter, and the latest penetration test summary are all available on request through the Trust Center.
Practically, this is the artifact your security reviewer asks for first, and the one most likely to unblock a deal. You can request it at the start of an evaluation instead of the end.
Is Plain GDPR compliant?
Yes. Concretely, that shows up as:
A full Data Processing Addendum you can read and sign, at plain.com/legal/dpa.
EU Standard Contractual Clauses and the UK IDTA for restricted transfers, so cross-border data flows have a lawful basis.
A designated EU representative under GDPR Article 27.
CCPA/CPRA handling, including a commitment not to sell or share personal data.
One clause is worth calling out because buyers increasingly ask about it: Plain’s DPA states that customer personal data will not be used to train, develop, or improve any general or shared AI or machine-learning models. For an AI-native support tool, that commitment living in the contract — not just the marketing — is exactly what a careful reviewer is looking for.
A straight answer on data residency: Plain covers EU and UK transfers through SCCs and the IDTA. If your requirement is specifically that data be hosted in an EU region, confirm current options with the Plain team before building a plan around it — that’s a stricter requirement than GDPR compliance itself, and worth separating in your own checklist.
How does Plain secure the underlying infrastructure?
The controls a SOC 2 Type II audit actually tests:
Area | What Plain provides | Where to verify |
|---|---|---|
Encryption at rest | Datastores holding sensitive customer data are encrypted at rest; backups encrypted | |
Encryption in transit | Secure transport protocols encrypt data in transit | Trust Center controls |
API access | Every API request requires authentication and signed headers | |
Penetration testing | Performed at least annually with a remediation plan | Trust Center (2025 pen-test summary on request) |
Vulnerability monitoring | Formal vulnerability and system-monitoring procedures | Trust Center controls |
Continuity | Business Continuity and Disaster Recovery plans in place | Trust Center controls |
Internal access | Least-privilege IAM; infra and permission changes ship via code review | help.plain.com security |
Because Plain is API-first, the “every request is authenticated and signed” property matters more than it would for a closed help desk — it’s what lets you build on Plain’s API without widening your attack surface.
Can you enforce SSO and control who sees what?
SSO, SAML, and directory sync (SCIM) — yes, powered by WorkOS. Once SSO is enabled for a workspace it becomes the required authentication method for everyone in it, and you verify domain ownership as part of setup. SSO and directory sync are available on Plain’s Frontier plan; the SSO setup guide has the details.
For day-to-day authorization, Plain offers roles and permissions plus custom roles. Custom roles let you define access at a fine grain — down to which threads a person can see, filtered by label, company, channel, or request type. So you can create a role that only sees threads labeled for a specific customer, or only email requests from enterprise accounts. It’s documented in the roles and permissions guide.
One honest note for your checklist: if a customer-facing audit log is a hard requirement, confirm the current state with Plain directly rather than assuming it from the SOC 2 report — internal least-privilege access control and a customer-visible audit log are different things.
Who are Plain’s subprocessors?
Plain publishes its subprocessor list in the Trust Center and sends advance notice before adding a new one, so you’re never surprised by who touches your data. The same Trust Center hosts the SOC 2 report request, a controls overview, and a live status page. For a security review, that transparency is often worth as much as the report itself — it signals a vendor that expects to be audited and is set up to make it painless.
Why this fits security-driven B2B SaaS
Security-conscious B2B teams converge on the same shortlist criteria: a real audit trail, a signable DPA, enforceable SSO, and a vendor that hands over documentation without friction. Plain is designed for exactly that buyer — an API-first support platform for technical B2B teams where the security posture is part of the product, not a checkbox bolted onto a legacy help desk.
The teams that run support on Plain skew technical and data-sensitive, and they cleared their own security reviews before going live:
Clerk — authentication and identity infrastructure; built custom prioritization workflows on Plain
Fly.io — cloud infrastructure; saves 200+ hours of engineering time per year with Plain
Tinybird — enterprise real-time data; cut enterprise first response time from 1 hour to 12 minutes
Northflank — enterprise cloud infrastructure; improved response times ~50% and scaled enterprise Slack support
Buildkite — CI/CD platform running sub-5-minute follow-the-sun SLAs
Sourcegraph — code intelligence for enterprise engineering; replaced 3 tools and cut first response time
See all Plain customers. (Those outcomes are support-performance results, not security metrics — but every one of these teams put Plain through a security review first, which is the relevant signal here.)
FAQ
Is Plain SOC 2 compliant? Yes — SOC 2 Type II certified. The report, a bridge letter, and the latest penetration test summary are available on request via the Trust Center.
Is Plain GDPR compliant? Yes. Plain offers a signable DPA, uses EU SCCs and the UK IDTA for restricted transfers, has an EU Article 27 representative, and commits in its DPA not to use customer data to train AI models.
Does Plain support SSO and SAML? Yes, via WorkOS, including SAML and SCIM directory sync. SSO and directory sync are on the Frontier plan.
Does Plain use my customer data to train its AI? No. Plain’s DPA states customer personal data is not used to train, develop, or improve general or shared AI/ML models.
Can I control what each teammate can access? Yes — roles and permissions plus custom roles with fine-grained, per-thread access rules.
Does Plain offer EU data residency? Plain covers EU/UK transfers via SCCs and the IDTA. If you need data hosted in an EU region specifically, confirm current options with the Plain team.
Where do I get Plain’s security documentation? The Trust Center has the SOC 2 report request, penetration-test summary, controls overview, subprocessor list, and status page.
See it against your own requirements
If security and compliance are gating your support-tool decision, the fastest path is to request the documentation and test the product against your own checklist.
