客户安全与隐私问卷答案库（按 CAIQ / CCM 主题分组）

章节结构（11）

1. 1. 答案库的治理：归口、版本、有效期与审批

   先把规则定死，否则答案库三个月后就会退化成互相矛盾的若干份文档。要写明：每条答案的归口责任人（安全 / 法务 / 基础设施 / 人力）、审批人、最后复核日期与有效期（建议不超过 6 个月）、以及允许直接对外发送的密级。同时定义三类答案状态：可直接引用、需按客户裁剪、须法务逐案审批。销售在提案阶段只能取用第一类；涉及承诺时限、赔偿、审计权的回答一律走第三类。答案库应与合同模板的安全附件保持一致 —— 问卷里答"支持"、合同里写"不承诺"，会在法务审查阶段被直接打回。

   需要附的证据

   • · 答案库条目表（问题、答案、归口人、审批人、复核日期、有效期、状态、密级）
   • · 答案库与合同安全附件条款的对照表
   • · 过期条目提醒机制与复核记录
   • · 对外发送审批流程说明

   常见失分点

   • · 答案库由售前维护、安全团队不知情，回答与实际控制脱节
   • · 没有有效期机制，两年前的架构描述仍在使用
   • · 销售直接把内部答案库原文发给客户，泄露内部系统名称与拓扑细节

2. 2. 服务范围声明与共享责任模型

   每份问卷的第一部分都应当是一段固定的范围声明：本次回答覆盖哪个产品/服务、哪些部署形态（SaaS 多租户 / 单租户 / 私有化部署 / 边缘设备）、托管在哪些区域与云厂商、以及客户与我方各自承担哪些控制。共享责任模型要做成一张表而不是一段话：按 CCM 的域逐项标注"我方负责 / 客户负责 / 双方共担"，并在共担项写清交接点。中国厂商向欧美客户销售时，这张表还要额外标注"由境内团队执行"与"由境外实体执行"的控制，因为客户的第三方风险团队会据此判断数据接触面与跨境风险。

   需要附的证据

   • · 产品与部署形态清单及对应的控制范围
   • · 共享责任矩阵（按 CCM 域逐项划分，含交接点说明）
   • · 托管区域、云厂商与子处理者清单
   • · 按执行主体标注的控制归属表（境内/境外）

   常见失分点

   • · 一份答案覆盖所有产品线，客户发现私有化部署与 SaaS 的控制根本不同
   • · 共享责任只写"按行业惯例"，客户无法据此做自己的风险评估
   • · 未披露子处理者与托管区域，合同签署后才被发现，触发重新评审

3. 3. 治理、风险与合规（GRC）与审计鉴证（A&A）

   这一组问题问的是"你们有没有一套在运转的体系"，而不是单个技术控制。答案骨架：安全方针的批准层级与复核周期；安全组织与职责（含是否设有专职安全负责人及汇报路径）；风险评估的频率、方法与上一次执行日期；合规义务清单及其跟踪方式；已取得的认证与报告（ISO/IEC 27001 证书编号与范围、SOC 2 报告类型与覆盖期间、CSA STAR 注册库条目链接）；内部审计与管理评审的频率与最近一次结论。没有证书时不要含糊其辞 —— 直接写"尚未取得，计划于 X 时间启动，现以 Y 控制替代"，比"符合国际标准"更能通过评审。

   需要附的证据

   • · 安全方针文本与批准记录、复核周期规定
   • · 安全组织架构与岗位职责说明（含汇报路径）
   • · 最近一次风险评估报告与风险处置计划
   • · 认证证书扫描件（编号、范围、有效期）与 SOC 2 报告（含桥接函）
   • · 内部审计计划、审计报告与管理评审纪要
   • · 合规义务登记册

   常见失分点

   • · 出示 ISO/IEC 27001 证书但范围只覆盖一个办公场所，未覆盖售卖的服务
   • · SOC 2 报告覆盖期间已过期且拿不出桥接函
   • · 把"符合 ISO/IEC 27001 要求"写成"已通过 ISO/IEC 27001 认证"，被要求出示证书时无法提供
   • · 风险评估报告日期是两年前，且无年度执行记录

4. 4. 身份与访问管理（IAM）、密码学与密钥管理（CEK）

   答案要具体到机制而非原则。身份与访问：员工与承包商的入离职流程与时限、最小权限与职责分离的实现方式、特权账号管理（是否使用堡垒机/临时提权、会话录制）、多因素认证的覆盖范围（是否覆盖全部管理面与 VPN）、访问权限复核的频率与上次执行记录、客户侧支持的单点登录与目录同步协议。密码学：传输与静态加密的算法与密钥长度、密钥的生成与保管（是否使用 KMS/HSM）、轮换周期、客户自带密钥（BYOK）是否支持、以及生产环境密钥与开发环境的隔离。中国厂商常被追问的一点：运维人员从境内访问境外生产环境时的鉴权与审计方式，要正面回答而不是回避。

   需要附的证据

   • · 入离职与权限变更流程文档及近期工单样本（脱敏）
   • · 特权访问管理配置截图与会话审计日志样本
   • · 多因素认证覆盖范围清单
   • · 权限复核记录（执行日期、范围、发现与整改）
   • · 加密算法与密钥管理制度、KMS/HSM 配置说明、轮换记录
   • · 跨境运维访问的鉴权与审计方案说明

   常见失分点

   • · 回答"采用行业标准加密"而不给算法与密钥长度
   • · 声称全员多因素认证，但运维跳板机走的是共享账号
   • · 权限复核制度存在但拿不出执行记录
   • · 回避跨境运维访问问题，客户据此推定存在未披露的数据接触面

5. 5. 数据安全与隐私（DSP）：分类、留存、删除与跨境

   这是 AI 厂商被追问最深的一组。要准备的答案包括：数据分类分级规则与客户数据的默认等级；客户数据的物理与逻辑隔离方式（多租户下的隔离机制要具体到实现，"逻辑隔离"四个字不够）；留存期限与到期删除的触发与验证方式；客户要求删除时的响应时限与备份中残留数据的处理；数据出境的路径、法律机制与已完成的评估（对中国厂商而言，个人信息保护影响评估、标准合同备案或安全评估申报的状态应当可出示）；以及最关键的一条 —— 客户数据是否用于模型训练。最后这一条必须给出无歧义的默认立场与可配置选项，含糊表述会在法务审查中被认定为最高风险项。

   需要附的证据

   • · 数据分类分级制度与客户数据默认等级说明
   • · 多租户隔离机制的技术说明（含隔离层级与验证方式）
   • · 留存与删除策略、到期删除执行记录、备份保留期说明
   • · 数据流向图（含境内外链路、子处理者与存储位置）
   • · 个人信息保护影响评估报告、跨境传输机制文件与备案/申报状态
   • · "客户数据是否用于模型训练"的产品默认设置与合同条款、可配置项说明

   常见失分点

   • · "客户数据不用于训练"写在营销页却没有写进合同与产品默认配置
   • · 删除承诺覆盖生产库但不提备份，客户追问备份保留期时答不上来
   • · 数据流向图与实际架构不符（例如漏掉境内的日志分析与客服系统）
   • · 跨境机制只写"已签署标准合同"，拿不出备案回执或影响评估报告

6. 6. 应用与接口安全（AIS）、变更控制（CCC）、威胁与漏洞管理（TVM）

   安全开发：需求与设计阶段的安全评审、代码审计与静态/动态扫描的工具与频率、依赖与开源组件管理（是否产出软件物料清单 SBOM）、密钥与凭据不入代码库的强制手段。变更控制：变更分级、审批路径、回滚方案、生产变更的双人复核与记录。漏洞管理：扫描频率、按严重程度的修复时限（给出具体天数而不是"及时"）、渗透测试的频率与执行方（内部还是第三方，是否可提供摘要报告）、漏洞披露与赏金渠道。对销往欧盟的产品，欧盟网络韧性法案对含数字元素产品的漏洞处置与 SBOM 有直接要求，答案应与产品侧的合规准备保持一致。

   需要附的证据

   • · 安全开发流程文档与设计评审记录样本
   • · SAST/DAST/SCA 扫描配置与最近一次扫描结果摘要
   • · 软件物料清单（SBOM）样例与生成方式说明
   • · 变更管理流程与近期生产变更工单样本
   • · 漏洞修复时限政策与实际达成率统计
   • · 第三方渗透测试报告摘要与整改闭环记录

   常见失分点

   • · 修复时限写"尽快"或"根据实际情况"，采购方一律按最差情形评分
   • · 声称每年渗透测试但拿不出报告，或报告范围与售卖服务不符
   • · 拿不出 SBOM，而客户合同里已经写了提供义务
   • · 扫描工具装了但高危告警长期挂起，达成率统计被现场抽查发现

7. 7. 基础设施与虚拟化（IVS）、数据中心（DCS）、日志与监控（LOG）、终端管理（UEM）

   基础设施：网络分段与生产/非生产隔离、基线加固标准与合规检查频率、容器与编排平台的安全配置、镜像来源与签名。数据中心：自建机房的物理门禁、监控与环境控制；使用公有云或托管时，直接引用云厂商与托管商的合规证明并说明自己在共享责任中承担的部分。日志与监控：采集范围（是否覆盖管理面操作与数据访问）、留存期限、防篡改措施、告警与值守安排（是否 7×24）、以及客户能否获得与其数据相关的审计日志。终端管理：办公终端的加密、补丁、防恶意软件与丢失处置，研发终端是否允许接触生产数据与源代码外带控制。

   需要附的证据

   • · 网络拓扑与分段说明（生产/非生产/管理面）
   • · 基线加固标准与合规检查报告
   • · 云厂商与托管商的合规证明（SOC 2 / ISO 证书）及共享责任说明
   • · 日志采集范围清单、留存策略与防篡改配置
   • · 值守与告警响应安排（含轮班与升级路径）
   • · 终端管理平台配置与合规率统计

   常见失分点

   • · 日志留存期短于客户合同要求的取证期限
   • · 开发人员可直接访问生产数据且无审批与审计
   • · 直接把云厂商的合规证明当作自己的控制，不说明共享责任边界
   • · 答"7×24 值守"实际是轮流值班手机接警，无法说明响应时限

8. 8. 业务连续性与韧性（BCR）、安全事件管理与取证（SEF）

   连续性：业务影响分析的执行时间与结论、恢复时间目标与恢复点目标（按服务分级给出具体数值）、备份策略与异地/跨区域安排、上一次恢复演练的日期范围与结果、以及退出与数据取回安排（客户终止合同时如何取回数据、格式与时限）。事件管理：事件分级标准、发现到响应的时限、通报机制与时限（区分合同约定的客户通报与法定通报）、取证能力与证据保全、事后复盘与整改跟踪。中国厂商需在这一节把多重法定通报义务讲清：面向欧盟的个人数据泄露通报、面向中国监管的网络数据安全事件报告、以及合同约定的客户通报，三者时限不同，答案库应给出统一的内部触发表而不是让一线临场判断。

   需要附的证据

   • · 业务影响分析报告与 RTO/RPO 定义表
   • · 备份策略、异地安排与最近一次恢复演练报告
   • · 退出与数据取回流程说明（格式、时限、验证方式）
   • · 事件分级标准与响应流程图
   • · 通报义务触发表（法定 vs 合同，含时限与责任人）
   • · 近期事件复盘报告与整改闭环记录（脱敏）

   常见失分点

   • · RTO/RPO 给了数字但从未演练验证，客户要求演练报告时无法提供
   • · 客户通报时限承诺得比内部实际发现能力更短，事后必然违约
   • · 退出安排只写"协助客户导出数据"，无格式与时限，合同谈判时成为卡点
   • · 把法定通报与客户通报混为一谈，导致要么漏报要么过度披露

9. 9. 供应链透明与问责（STA）：子处理者与分包管理

   给出子处理者与关键供应商清单（名称、服务内容、所在地、涉及的数据类型）、准入评估方式、合同中的安全与数据保护条款、变更通知机制（提前多少天通知客户、客户是否有异议权）、以及对下游的持续监控方式。欧盟客户会特别关注两点：处理者合同是否把同等义务传递给子处理者；供应链安全措施是否覆盖直接供应商。金融业客户还会引用信息通信技术第三方服务合同的必备要素要求，把具体条款清单直接发过来要求逐条确认 —— 答案库应预置对照表，标明哪些条款可接受、哪些需谈判。

   需要附的证据

   • · 子处理者与关键供应商清单（含地点与数据类型）
   • · 供应商安全评估记录与准入标准
   • · 与子处理者签署的数据保护/安全附件模板
   • · 子处理者变更通知机制说明与历史通知记录
   • · 金融客户合同必备要素对照表（可接受 / 需谈判 / 不可接受）

   常见失分点

   • · 子处理者清单不含 AI 基础模型与算力供应商，客户在架构问询中发现遗漏
   • · 承诺"子处理者承担同等义务"但拿不出已签署的附件
   • · 变更通知机制不存在，静默更换子处理者被客户在年度复评中发现

10. 10. AI 专项追问：模型、训练数据、输出与人工监督

    传统安全问卷之外，采购方越来越多附加 AI 专项问卷（如 CSA 的 AI 控制矩阵与配套 AI-CAIQ）。预置答案应覆盖：所用模型清单（自研 / 第三方，含版本与提供方）、训练与微调数据的来源与权利状态、客户数据是否进入训练与如何隔离、推理阶段的数据留存与日志、模型评估与红队测试的方法与频率、输出内容的标识与可追溯性、幻觉与有害输出的缓解措施、人工监督与人工接管机制、以及模型更新的变更管理与客户通知。向欧盟销售时还须准备：AI 系统角色定位（提供者 / 部署者）、是否属于高风险用途、以及可提供给部署者的使用说明与技术信息。

    需要附的证据

    • · 模型清单（自研/第三方、版本、提供方、用途）
    • · 训练与微调数据来源清单及权利状态说明
    • · 模型评估与红队测试报告摘要
    • · 输出标识实现方式与可追溯性说明
    • · 人工监督与接管机制的产品实现说明
    • · 模型更新的变更管理流程与客户通知记录
    • · 面向部署者的使用说明与技术信息包

    常见失分点

    • · 回答"我们不保存推理数据"，但日志系统实际保留了完整请求内容
    • · 第三方基础模型的提供方与版本不披露，客户无法完成自己的供应链评估
    • · 训练数据权利状态含糊，客户法务据此判定知识产权风险不可接受
    • · 模型静默更新，客户在效果变化后才发现，信任受损比技术问题更难修复

11. 11. 缺口、例外与补偿性控制的答法

    答案库最有价值的部分往往不是"是"，而是把"否"写得可被接受。标准写法四段式：(1) 明确回答当前不具备该控制；(2) 说明当前采取的补偿性控制及其覆盖程度；(3) 给出补齐计划的具体里程碑与负责人；(4) 说明可接受的合同安排（例如在达标前接受更严格的通报时限或限制数据类型）。绝不要用"部分符合""正在推进中"这类无信息量的表述 —— 有经验的评审人会把它们等同于"否"并额外扣分。同时维护一份"已知常见拒答项"清单：哪些问题我方一律不回答（如详细网络拓扑、具体安全产品型号、员工个人信息），并准备统一的替代提供方式（在保密协议下现场演示、提供第三方审计报告对应章节）。

    需要附的证据

    • · 控制缺口登记册（缺口、补偿控制、计划、负责人、期限）
    • · 补偿性控制的有效性验证记录
    • · 常见拒答项清单与替代提供方式
    • · 缺口对合同承诺影响的法务评估意见

    常见失分点

    • · 为了通过评审把"否"答成"是"，交付后被客户现场审计发现，后果远重于最初被扣分
    • · 补齐计划年年顺延，客户在续约复评时逐条比对发现无进展
    • · 拒答但不给替代方案，被记为"不配合"