合同都谈到最后了，SSO 安全审查却卡住：销售该补哪份证据？

判断时关注的线索

• 合同卡在安全部
• 身份协议证据不足
• 销售被动背锅

一封冻结邮件背后的三个月拉扯

业务方案通过了，预算也批了，合同走到内部用印前最后一站——安全部。一封邮件进来，附件里是二十多个技术问题：SAML 还是 OIDC？SCIM 同步走什么协议？权限模型是 RBAC 还是 ABAC？IdP 发起的单点登录是否支持 Just-In-Time 预置？

销售翻遍了自己的产品介绍文档、功能对比表和 FAQ 手册，发现能回答的不超过三个。剩下的只能写一句“我回去找产品确认”。

一封邮件变成五轮邮件往返。五轮变成三周。三周变成客户采购经理的内部通报：“安全审查未完成，合同暂停。” 业务部门的人比你还急，但他们推不动安全流程。

这不是个例。企业 SaaS 大额交易中，安全审查导致成交周期延长的场景正在快速增加。Gartner 在 2023 年的一项调研指出，超过 60% 的企业采购在安全评估环节出现过至少两周的延迟。而更隐蔽的成本是：每一次“回去问产品”都在消耗客户内部对你的信任额度。

为什么“回去问产品”是死胡同

销售遇到身份安全问题时，本能反应是把自己当成传声筒。这个做法有三个结构性缺陷。

缺陷一：产品团队没有统一的口径。 同一个问题，售前工程师、产品经理、研发负责人给出的答案可能侧重点完全不同。售前讲功能开关，产品讲路线图，研发讲实现细节。客户安全团队收到三份不一致的答复，只会认为供应商对自己产品的安全能力没有清晰认知。

缺陷二：问题没有分类，优先级无法判断。 二十个技术问题挤在一封邮件里，没有标注哪些是准入红线、哪些是“最好有”、哪些只是信息收集。销售无法判断应该催产品先回答哪个，产品也无法判断哪个问题在影响合同进度。

缺陷三：答复证据不可追溯。 邮件回复之后，下一次审计或人员变动时同样的安全问题会被重新问一遍。没有归档、没有版本号、没有责任方标注，每一次安全审查都是从头再来。

这三个缺陷叠加的结果是：销售在安全审查环节变成了瓶颈，而不是桥梁。

安全审查证据清单——三个维度一个模板

身份协议层

客户想知道：你的系统用什么方式确认“谁在访问”？

这一层覆盖的核心证据包括：

• 支持的 SSO 协议（SAML 2.0 / OIDC / CAS）及各自的支持阶段
• IdP 发起的 SSO 与 SP 发起的 SSO 是否都支持
• Just-In-Time 用户预置是否可用
• 多 IdP 场景下的身份源优先级规则

权限模型层

客户想知道：用户进来以后，你能控制“他能做什么”吗？

这一层的证据清单：

• 权限模型类型（RBAC / ABAC / 混合模型）
• 角色继承结构及其管理界面
• 是否支持细粒度资源级权限
• 权限变更的生效机制（实时同步 / T+1 / 手动触发）

审计证据层

客户想知道：出了问题，你能不能证明谁在什么时候做了什么？

需要准备的证据：

• 用户操作日志的字段覆盖（时间戳、操作人、操作对象、操作结果）
• 日志保留时长及导出格式
• 是否支持将日志推送到客户 SIEM 系统
• 管理员操作与普通用户操作是否分开记录

下面是一份可直接复用的审查缺口清单模板：

维度	审查项目	当前状态	证据来源	优先级
身份协议	SAML 2.0 支持	✅ 已支持	产品文档 v4.2	P0
身份协议	SCIM 预置同步	❌ 路线图中	产品路线图 Q4	P1
权限模型	RBAC 角色继承	⚠️ 部分支持	需产品确认上限	P0
权限模型	资源级细粒度权限	❌ 不支持	待评估替代方案	P2
审计证据	日志保留 >90 天	✅ 已支持	运维手册	P1
审计证据	SIEM 集成能力	⚠️ 需确认格式	待技术对接	P1

优先级标记释义：P0 = 客户准入红线，缺失即阻塞；P1 = 重要但可协商补偿控制；P2 = 加分项但不影响当前成交。

缺口清单：销售、安全、产品各有一份责任

拿到上面这份清单之后，销售的角色从“传声筒”变成了“编排者”。

第一步：把产品当前的能力映射到清单上。 能直接填的立刻填，需要产品确认的标注“待确认”，明确不支持的标注“路线图中”并注明计划时间。

第二步：用优先级与客户安全团队对齐。 把 P0 项的进展作为同步重点，P1 项说明补偿方案，P2 项列入后续路线图。这一步的关键动作是给出时间预期，而不是完美的答案。

第三步：将清单纳入合同附录。 把缺口清单与产品路线图、补偿控制方案一起作为附录放进合同。这样做的隐含价值是：安全审查从“一票否决”变成了“已知风险清单”，双方的对话从“能不能过”变成了“怎么管理已知缺口”。

这套方法的有效性不依赖任何特定产品。它本质上是把客户的安全关切翻译成一份可追踪、可分工、可归档的结构化证据。即使你所在的公司暂时没有完善的安全文档，你仍然可以用这份清单推动对话向前走。

关于如何更系统地识别客户业务信号并将其转化为需求框架，可以参考《Telegram 业务信号框架：从客户行为到需求翻译》。如果你需要建立更全面的安全审查证据治理体系，《Telegram 源头治理：安全审查中的证据结构》 提供了另一种视角。针对成交阶段的信号智能分析，可以进一步了解 Telegram 成交信号智能。

常见问题

安全审查到底应该由销售还是产品来回答？

都不单独承担。销售负责传递安全口的真实关切，产品负责出具架构层面的技术证据，双方共同维护一份缺口清单并标记责任方。销售要做的不是回答技术细节，而是确保每个问题都有对应的责任人和回复时间线。

客户要求我们提供 SOC 2 报告，我们没有怎么办？

SOC 2 等第三方审计报告属于高阶信任证据，并非所有交易阶段都需要。先用本文的清单补齐身份协议和权限模型的基础证据，再看是否有必要安排第三方报告作为后续里程碑。很多时候客户安全团队要的并不是一份报告，而是供应商展示出对安全问题的系统性理解。

公司产品还不支持 SCIM 或细粒度 RBAC，这单是不是没救了？

不支持不代表不能成交。在清单中如实标注“产品路线图中”，同时提供对应的补偿控制方案——例如用定期手动同步加上变更审计日志作为过渡措施。客户安全团队要的是风险可见，而不是零风险。一张标注了时间点和补偿措施的缺口清单，比一个空白的“已支持”更有说服力。

要点总结

• 客户安全审查造成合同阻塞时，销售的问题不是“不懂技术”，而是“没有分类工具”。
• 用身份协议、权限模型、审计证据三个维度整理客户问题，把被动应答变成主动管理。
• 缺口清单让销售从传声筒变成编排者，让安全团队从审查者变成风险管理伙伴。
• 把清单纳入合同附录，把安全审查从一票否决转化为已知风险清单。
• 方法的有效性不依赖特定产品：任何阶段的销售团队都可以从今天开始使用这套分类和归责机制。

在产品层面，TOP Prospect 提供了一套将客户安全关切自动映射为结构化缺口清单的引擎，帮助销售团队在安全审查环节保持主动态势。但这套能力是方法的延伸，不是前提。

常见问题

安全审查到底应该由销售还是产品来回答？

都不单独承担。销售负责传递安全口的真实关切，产品负责出具架构层面的技术证据，双方共同维护一份缺口清单并标记责任方。

客户要求我们提供 SOC 2 报告，我们没有怎么办？

SOC 2 等第三方审计报告属于高阶信任证据，并非所有交易阶段都需要。先用本文的清单补齐身份协议和权限模型的基础证据，再看是否有必要安排第三方报告作为后续里程碑。

客户安全团队问的问题我已经转给产品了，三个星期没回音怎么办？

把问题归类到本文的清单维度中，标注"产品待确认"状态，然后拿着缺口清单与安全负责人同步进展。透明比完美更重要——客户通常愿意接受有计划的等待，而不是石沉大海。

公司产品还不支持 SCIM 或细粒度 RBAC，这单是不是没救了？

不支持不代表不能成交。在清单中如实标注"产品路线图中"，同时提供对应的补偿控制方案——例如用定期手动同步加上变更审计日志作为过渡措施。客户安全团队要的是风险可见，而不是零风险。

资料来源与延伸阅读

1. NIST Cybersecurity Framework 2.0
2. CISA Secure by Design