A collection of representative B2B lead discovery scenarios, showing how AI identifies qualified sales opportunities from real-world business conversations.
The Deal Is Nearly Done, but SSO Review Is Stuck: Which Evidence Does Sales Need?
Your buyer is bought in, but now Security wants proof of identity protocols, permission models and audit logs — and your deck doesn't have a single one. Here is the evidence checklist that closes the gap.
This is an illustrative scenario designed to explain the product’s judgement logic. It is not a real customer case, testimonial, contract, revenue result, or conversion claim.
01Situation
02Signal judgement
03Confidence vs priority
04Human next step
Signals considered
- sales lost the security room
- identity protocol evidence gap
- SSO audit readiness
Composite scenario. The buyer, the industry, and the deal details below are a teaching composite, not a named-company record. No customer results are claimed.
The Friday Call That Changed Everything
You have been running this deal for eleven weeks. The VP of Operations is on your side. The budget line is approved. Your champion just sent the celebratory emoji. Then the procurement liaison adds one sentence to the thread: “Security needs to complete an SSO review before signature. Can you send the identity protocol documentation, the permission model, and the audit evidence by Tuesday?”
Suddenly you are not talking to a buyer. You are talking to a security engineer you have never met, who judges software by the same standards they apply to a third-party identity provider — and your deal lives or dies on evidence you do not carry in your deck.
This article is not about SSO technical configuration. It is about the evidence gap that kills late-stage enterprise deals, and a repeatable method to close it before the security engineer joins the room.
Why a Feature Deck Fails the Security Room
A typical enterprise SaaS deal in late 2025 involves three security review gates: identity protocols (how users authenticate), permission models (how authorization works once authenticated), and audit evidence (what logs exist, how they are retained, who can access them).
Your product marketing page probably says “Enterprise-grade SSO with SAML 2.0 and SCIM provisioning.” That sentence convinces a buyer. It does not convince a security engineer. They want to see:
- Which SAML bindings are supported (Redirect vs POST, artifact resolution)
- Whether the SP-initiated flow logs the IdP issuer in the session record
- How session timeouts cascade when the IdP revokes a user
- Whether the permission model supports attribute-based (ABAC) or only role-based (RBAC) decisions
- Where audit events are stored, for how long, and whether they are immutable
A feature deck treats security as a feature. Security treats it as a risk surface. Until sales bridges that gap, the deal sits in a “pending security review” folder — and enterprise deals that sit there longer than three weeks close at roughly half the rate of those that clear security inside the first week.
The Method: A Security-Evidence Checklist the Whole Team Owns
The fix is not a thicker deck. The fix is a living evidence checklist that security, product, and sales maintain together. When you own a shared gap list, no stakeholder is surprised by a Tuesday-morning document request.
1. Identity Protocols Layer
Collect and version exactly one document per protocol your product supports.
| Protocol | What security teams look for |
|---|---|
| SAML 2.0 | Supported bindings, IdP-init vs SP-init, signed assertions, NameID format, logout URL handling |
| OIDC / OAuth 2.0 | Grant types enabled, token lifetime config, refresh token rotation, audience claim |
| SCIM 2.0 | Attribute mapping schema, sync direction, deprovisioning behavior (soft vs hard delete) |
Gap to watch: If your product falls back to password-based login when SSO is unavailable, that fallback must be documented with its own risk treatment — not hidden in a settings page.
2. Permission Model Layer
Security reviewers evaluate three things: scope, inheritance, and defaults.
Create a single-page table that lists every role in your product (admin, editor, viewer, API-only, read-only) and the data objects each role can access. If your permission model allows custom roles, document which permissions are composable and which are atomic.
Then answer: What is the default permission set for a new user? The safest answer is “no access until explicitly assigned.” If your product grants default viewer access to any shared resource, that needs a documented exception.
3. Audit Evidence Layer
This is the layer that stalls the most deals. Security teams want to know:
- Which events are logged (auth success, auth failure, privilege escalation, permission change, data export)
- How long logs are retained (and whether that retention is configurable)
- Whether logs are append-only (immutable) or can be rotated/deleted by an admin
- Whether customers can export their own tenant logs (SIEM integration or raw JSON)
- Whether the log timestamp is UTC, server-local, or user-local
Create a single audit-matrix table. If a row is not yet implemented, mark it “planned — Q1 2026” rather than omitting it. Security reviewers accept a roadmap far more readily than an omission they have to discover.
What You Deliver to the Buyer: A Shared Gap List
After you assemble the three layers above, you produce one document: the SSO Evidence Gap List. Each row has:
- Evidence item (e.g., “SAML logout URL handler behavior”)
- Status (available / partial / planned)
- Owner (product engineering / security team / sales enablement)
- Estimated completion date (or “available now”)
Share this document with your champion and the security reviewer in the same meeting. The gap list transforms the conversation from “Sales, go find this documentation” to “The product team owns five items, security consulting owns two, and sales owns zero. Here is the timeline for each.” The reviewer stops blocking and starts tracking.
A Natural Bridge: When the Gap List Resembles a Signal Framework
Once you have built this checklist two or three times, you notice that the gaps are never random. Identity protocols, permission models, and audit evidence follow patterns. The same gaps appear across deals in the same industry vertical, and the same remediation timelines apply.
That pattern is useful beyond a single deal — it becomes the foundation for a repeatable security-review playbook that sales, product, and security can reference without starting from zero each quarter. Some teams formalize this pattern as a business signal framework that maps technical evidence to buyer confidence. Others build a source governance practice so the evidence stays current across product releases. And when the evidence itself becomes a competitive asset, it evolves into what some organizations call signal intelligence — the capability to know which evidence will be requested before the reviewer asks for it.
The checklist above is the starting point. The pattern recognition is what turns a stalled deal into a repeatable motion.
Summary: What Changes After This Article
- You stop treating security evidence as a feature. You treat it as a deliverable with an owner and a date, exactly like a contract clause.
- You build the checklist before the deal needs it. The three layers (identity protocols, permission models, audit evidence) take roughly four hours with your product team to draft, and they apply to every enterprise deal you run this quarter.
- You share the gap list first. The document that says “here is what we have, here is what is planned, here is who owns it” closes more security reviews than any feature deck ever will.
FAQ
How early should I ask my champion about the security review process?
Before the POC ends. The champion can tell you whether their security team runs a formal review, which frameworks they follow, and who the reviewers are. That intel lets you assemble evidence before the formal request lands — and it signals to the champion that you know how enterprise deals actually close.
Our product has SSO but we never documented the permission model. What is the fastest fix?
Map each role to its scoped data access in a single table — admin, editor, viewer, API key. List the claim attributes your IdP sends (groups, roles, email) and which ones your app reads for authorization. Security teams accept a well-structured one-pager far faster than a polished but vague feature page.
The security team asked for SOC 2 Type II and penetration test reports. I do not have either yet. Can I still advance the deal?
Yes, but you need a credible timeline. Share a written plan that shows when each report will be available, plus interim evidence: architecture diagrams, an in-progress audit letter, and a third-party pentest scoping document. Security teams stall on unknowns, not on timelines — a dated plan is better than silence.
My product uses OIDC but the reviewer asked about SAML logout behavior. How do I handle out-of-scope questions?
Clarify the scope gamely: “Our product authenticates via OIDC, which does not use SAML logout. Here is how our OIDC session termination works instead.” A respectful scope correction builds credibility. Then note the question in the gap list as “out of scope — documented.” Security reviewers track questions even when they fall outside your product boundary.
Sources
Frequently Asked Questions
How early should I ask my champion about the security review process?
Before the POC ends. The champion can tell you whether their security team runs a formal review, which frameworks they follow, and who the reviewers are. That intel lets you assemble evidence before the formal request lands — and it signals to the champion that you know how enterprise deals actually close.
Our product has SSO but we never documented the permission model. What is the fastest fix?
Map each role to its scoped data access in a single table — admin, editor, viewer, API key. List the claim attributes your IdP sends (groups, roles, email) and which ones your app reads for authorization. Security teams accept a well-structured one-pager far faster than a polished but vague feature page.
The security team asked for SOC 2 Type II and penetration test reports. I do not have either yet. Can I still advance the deal?
Yes, but you need a credible timeline. Share a written plan that shows when each report will be available, plus interim evidence: architecture diagrams, an in-progress audit letter, and a third-party pentest scoping document. Security teams stall on unknowns, not on timelines — a dated plan is better than silence.
Frequently asked questions
How early should I ask my champion about the security review process?
Before the POC ends. The champion can tell you whether their security team runs a formal review, which frameworks they follow, and who the reviewers are. That intel lets you assemble evidence before the formal request lands — and it signals to the champion that you know how enterprise deals actually close.
Our product has SSO but we never documented the permission model. What is the fastest fix?
Map each role to its scoped data access in a single table — admin, editor, viewer, API key. List the claim attributes your IdP sends (groups, roles, email) and which ones your app reads for authorization. Security teams accept a well-structured one-pager far faster than a polished but vague feature page.
The security team asked for SOC 2 Type II and penetration test reports. I do not have either yet. Can I still advance the deal?
Yes, but you need a credible timeline. Share a written plan that shows when each report will be available, plus interim evidence: architecture diagrams, an in-progress audit letter, and a third-party pentest scoping document. Security teams stall on unknowns, not on timelines — a dated plan is better than silence.