CCRC 选定类别之后：证据怎么准备

为什么"选定之后"反而更难？因为选类别回答的是"我该报哪一类"，而证据准备回答的是另一个问题：审核方在这一个类别里，会顺着哪几个动作往回查，我手上的材料能不能一路接到底。同一批项目，在安全集成下被问的是"你怎么做安全设计和加固"，在安全运维下被问的是"你怎么证明服务是连续的"，在风险评估下被问的是"你的评估方法能不能复现"。项目没变，被要求证明的东西变了——这就是这篇要解决的。

另外先分清一件事，避免两套材料互相打架：CCRC 评的是服务能力资质，看的是你交付过的项目；ISO 27001 评的是组织级信息安全管理体系，看的是体系有没有建起来、跑起来。两者材料可以互相支撑，但不能互相替代（对照见 ISO 27001 体系认证）。

一、证据链的四个支点：合同、交付、人员、工具

不管报哪一类，支撑一个项目的材料都落在四个支点上。四者单独看都像模像样，凑不到一起就全是散的。

判断是否闭环，可以用一句话自检：随便抽一个项目，能不能只靠这套材料，把"谁在什么时间、用什么手段、为客户做了什么事、客户如何确认"讲完，且中途不需要口头补充。讲不完的那一环，就是需要补的地方——注意是补记录、补说明，不是补故事。

跨类别共用的证据：一次整理，多处引用

有几类材料是所有类别都要用的，值得单独整理成一套"公共底座"，避免每次申报重新翻箱倒柜：

• 主体类：营业执照、场所证明、组织架构与部门职责、财务与信誉类材料。这一套要长期维护更新，主体变更后及时同步。
• 体系文件类：制度、流程、作业指导书、记录表单模板。这是"能力可复制"的证明，也是现场核查时被翻得多的部分。
• 人员类：人员台账、劳动关系与社保记录、学历与培训记录、项目履历。建议按人建档，一人一份，随项目追加。
• 工具类：工具台账（名称、版本、来源、用途、责任人）＋使用记录（导出结果、截图、报告）。

共用不等于照搬，有三条纪律：

1. 同一数据只能有一个版本。项目名称、合同金额、起止时间、参与人数，在申报表、项目说明、验收材料里必须完全一致。前后差一个数字，就要花时间去解释。
2. 同一份流程文件，要指到本类别的活动节点。运维的服务级别管理流程、集成的变更与回退流程、评估的风险赋值规则，指向的条款不同；只写"我们有这个制度"没有意义。
3. 不同类别分别申报时，别把 A 类别的叙述直接搬给 B。同一项目在两个类别下都可以用，但引用的交付物和环节必须换成 B 关心的那部分。

二、信息系统安全集成：把"设备＋实施"接成一条建设链

集成类看的是安全建设能力，落点是四个动作：安全需求界定、安全设计、建设实施、安全加固。四个动作在同一个项目里都要有痕迹，缺一环，整条链就断在那一环。

实操上有两个判断要先做：

• 纯供货项目，不要硬报集成。只有设备清单和发票、没有设计、实施、加固动作的项目，放进集成类别里，核查时问两句就空。这类业务更适合去看运维或其他方向，或者等有了实施类项目再报。
• 集成项目的"安全含量"要能被指出来。如果合同写的是"系统集成"，就把其中的安全设计、安全配置、加固、安全测试部分单独说明清楚：哪一页方案、哪一条清单、哪一份记录对应哪个动作。

人员与工具在这类项目里对应的是设计、实施、加固三类角色，以及配置核查、基线管理、测试类工具。角色要和实施记录上的人名对得上——项目里出现的人，才是这个项目的人。

三、信息系统安全运维：证据要能证明"持续"

运维类的核心不是"做过"，而是一直在做。所以它的证据形态和其他类别不一样：不是一个时间点的交付物，而是一条有时间轴的服务记录。

一条完整的运维证据链通常包含：服务目录与服务级别约定 → 值班与巡检计划 → 日常巡检与监控记录 → 告警与工单处置 → 变更管理 → 漏洞通告与修复闭环 → 周期服务报告 → 年度回顾或续约。核查时看的正是这条线是否连续：服务起止时间能不能从合同和报告期数对上，中间有没有大段空白。

• 闭环比数量重要。十张巡检表不如一条"发现问题—上报—处置—复核—关闭"的完整记录。运维的价值体现在处置过程中，不在表格数量。
• 报告要成序列。月度或季度服务报告能直接证明服务连续性，报告里要有本期事件、处理结果、遗留问题。
• 人员要能落到班次。驻场还是远程、几个人、什么岗位、什么时候在岗，与值班表、工单处理人对得上。
• 工具要有导出物。监控平台、漏洞扫描、日志与堡垒机类工具，附脱敏后的导出结果或界面记录，说明用在哪个客户、哪个时间段。

运维三级是多数企业起步的方向，具体条件与材料清单可以对照 CCRC 三级安全运维资质 那篇逐条看。

四、信息安全风险评估：方法要能复现

评估类看的是方法论的可复现性。同一个企业做十个项目，方法应该是稳定的；核查时只要拿两个项目对比，方法是否成形立刻能看出来。

一个评估项目的证据骨架：评估依据与范围 → 资产识别与赋值 → 威胁与脆弱性分析 → 风险计算与定级规则 → 评估结论 → 整改建议 → 报告交付与客户确认。往上一层，还要有把方法固定下来的东西：评估作业指导书、赋值标准、报告模板、质量控制与复核记录。

• 结论背后要有过程。只有一份结论性的报告，说不清风险值是怎么算出来的，这一项就很难站住。资产清单、访谈记录、工具导出、分析表，都是过程的组成部分。
• 模板要一致，不要一项目一变。方法稳定是能力；每个项目换个写法，看起来像十家公司的报告。
• 整改建议要可执行。建议与发现的风险要一一对应，能看出是针对这个系统写的，不是通用条款堆叠。
• 人员能力要落到角色。评估、复核、报告批准分别是谁，与本类别的岗位能力对应。

这类方向的另一个特点：客户往往同时要等保相关服务。两类业务的材料要分清边界——哪些是本企业做的评估工作，哪些是引用外部机构的结果，别混在一份材料里。

五、应急处理与灾难备份恢复：一个看响应，一个看切换

这两个方向常被写在一起，但证据完全不同，分开准备更省事。

应急处理看响应过程。核心证据是：应急预案（含组织、联系人、事件分级、处置流程）→ 演练计划与演练记录 → 真实事件处置记录 → 处置报告与复盘整改。真实事件和演练要分开列，不要混成一条——演练记录证明"准备过"，事件记录证明"处置过"，两者互相替代不了。

灾难备份与恢复看目标与验证。核心证据是：恢复目标（RTO／RPO）从业务需求推导出来的说明 → 灾备方案设计 → 资源与配置清单 → 切换或演练记录 → 演练报告与问题整改。部分资料把灾备按资源服务与技术服务的侧重分别评价：前者看资源保障与运维能力，后者看方案设计与演练组织，材料重心不同，以现行类别划分为准。

还有一个容易踩的坑：把应急当运维写。日常巡检、监控告警属于运维的服务过程；事件分级、应急指挥、恢复与复盘才是应急处理的内容。两个方向同时申报时，同一份记录可以有不同引用角度，但要把各自的环节说清楚。

六、软件安全开发：把安全放进研发流程里

这个方向评的是开发过程中的安全控制，不是产品功能有多安全。所以证据的重心在流程节点，而不在成品。

可用的流程节点大致是：安全需求（需求阶段提出安全要求）→ 威胁分析与安全设计 → 安全编码规范 → 代码审计与白盒测试 → 开源与第三方组件管理 → 安全测试（含渗透测试类）→ 上线前安全检查 → 漏洞修复与闭环 → 发布与回滚。每个节点对应研发过程中的记录：评审记录、缺陷与修复记录、测试报告、版本记录。

• 先界定业务形态。"自研产品"和"为客户做开发服务"证据侧重不同：前者看产品线里的流程执行，后者看项目交付中的流程执行。纯代理销售、纯实施部署的业务，不适合放这个方向。
• 工具报告要有项目归属。代码审计、组件分析的报告，必须能指到具体项目与版本，否则只是"买了个工具"。
• 修复闭环是关键证据。发现了多少问题不重要，重要的是发现问题之后怎么修、谁验证、什么时候关闭。
• 流程文件要与项目记录一致。制度里写"每次发布前做安全测试"，就要能拿出对应版本的测试记录；写了做不到，比不写更麻烦。

七、网络安全审计：过程可追溯，结论才可信

审计类看的是检查评价的规范性与可追溯性。它和风险评估的区别在于落点：评估指向风险与整改优先级，审计指向符合性与检查结论。

证据骨架：审计依据与范围 → 检查项或控制点清单 → 取证方法（访谈、配置核查、日志与记录检查）→ 抽样规则与样本说明 → 发现与分级 → 审计报告 → 整改跟踪与复核。工作底稿是这个方向的关键材料——它决定了结论是"查出来的"还是"写出来的"。

• 抽样要说清规则。为什么抽这几个、抽了多少、覆盖了什么范围，写清楚才算方法。
• 发现要有证据指向。每条发现对应哪份记录、哪条配置、哪个时间点，能回指到底稿。
• 整改要有复核。只列问题不跟踪整改，审计的闭环就缺一半。
• 业务边界要说明。企业如果同时承接建设类与审计类业务，在材料里把两类业务的区分方式说清楚，比含糊带过稳妥。

八、开工前先自查：六种高频退回，和一份行动清单

退回多数不是因为企业能力不够，而是材料内部对不上。以下六种情形，在提交之前都值得逐条过一遍。

还有一条不属于"退回"，但必须单独说：把不属于本企业的项目写进来，或者把做过一小部分的事写成全程承接。这类问题的后果不是补材料能解决的。核查会问到委托方、会看签章、会核时间线，任何一处对不上，整批材料的可信度都要重新建立。宁可少报一个项目，也不要让一个项目毁掉整份申报。

行动清单：选定类别后的十步

• ⬜用一句话写下本类别的核心动作（例如运维是"持续服务"，集成的"设计—实施—加固"），后面所有材料都往这句话上靠
• ⬜列出候选项目清单，只保留本企业真实承接、且能拿出完整交付记录的项目
• ⬜逐个核对签约主体、执行主体、人员劳动关系是否同一主体
• ⬜为每个项目画一条从需求到验收的环节表，标出已有证据与空缺环节
• ⬜把空缺环节按"能否找回原始记录"分类：能找回的补档，找不回的写说明或换项目
• ⬜建立项目主数据表（名称、金额、起止时间、参与人员、交付物），作为全篇一致性的基准
• ⬜整理人员档案：岗位、能力凭据、项目角色，一人一份
• ⬜整理工具台账与使用记录，确保每件工具都能指到具体项目
• ⬜让体系文件的条款与本类别动作一一对应，表单与项目实际使用的表单统一
• ⬜提交前做一次交叉核对：抽两个项目，只靠材料复述全过程，看能否讲完

回到开头那句话：选定类别之后，真正的工作是把已有项目按这个类别的语言重新组织。组织得好，你手上那些看起来零散的项目会连成一条线；组织不好，再多的合同也只是堆在一起。这条线怎么走，取决于你对"审核会问什么"的理解——这也是 CCRC 类别选择 之后真正值得投入的地方。

▍选定类别后不确定先补哪一块？留言备注"CCRC证据清单"，我发你一份按类别归档的材料对照表