CCRC 八大类别逐个拆：每一类审什么、要什么证据

八类速览

先看全局。这张表的用法不是"挑一个"，而是对照你手里的合同和交付记录，看哪一行的证据重点和你的实际业务重合。

一、信息系统安全集成：看的是安全被实施进项目，不是设备卖出去了

审什么

集成类审的是安全建设能力，落点固定为四个动作：安全需求界定、安全设计、建设实施、安全加固。四个动作要在同一个项目里都留下痕迹，缺一环，整条链就断在那一环。判断标准很直白：你能指着方案的某一页、清单的某一条、记录的某一份，说明"安全"是在哪一步被做进去的——指不出来，就还没到这个类别的要求上。

谁适合

系统集成商、安全设备商，以及做安全方案设计与实施的企业。合同里出现安全设计、安全配置、加固、安全测试内容的，属于可梳理的范围；团队里有设计、实施、加固三类角色分工的，匹配度更高。纯供货不适合放这一类：只有设备清单和发票、没有设计实施加固动作的项目，核查时问两句就空，建议等有了实施类项目再报。

证据怎么组织

• 合同：签约主体必须是申报主体；服务内容条款要能看出设计、实施、加固这些动作，只写"系统集成""技术服务"的，需要把其中的安全部分单独说明清楚。
• 交付记录：按四个动作归位——需求调研记录与差距说明、安全方案与评审记录、实施计划与安装调试及割接回退记录、加固基线与配置核查、测试整改闭环、验收报告。每个动作至少有一份能独立看懂的文件。
• 人员：项目角色表里的人，要能在实施记录、验收签字里找到同名同岗；设计和加固往往是不同的人，别写成一个人全包。
• 工具：配置核查、基线管理、测试类工具，附脱敏后的导出结果，说明用在哪个项目、哪个阶段。

常见退回原因

• 纯供货硬报集成。项目里没有设计、实施、加固，只有采购清单和到货验收，属于项目与类别不对应。
• 方案是厂家模板。拓扑、设备选型、配置基线跟本项目的现状没有对应关系，看不出是为这个客户做的设计。
• 有清单没过程。设备清单齐全，但安装调试、割接、变更记录缺失，无法说明实施阶段的风险是怎么控的。
• 加固记录是通用模板。没有本项目的核查结果和整改闭环，加固这个动作等于没做。

二、信息系统安全运维：证明"一直在做"，而不是"做过一次"

审什么

运维类的核心不是"做过"，而是一直在做。所以它的证据形态和其他类别不一样：不是一个时间点的交付物，而是一条有时间轴的服务记录。核查看的是这条线连不连续——服务起止时间能不能从合同和报告期数对上，中间有没有大段空白，问题从发现到关闭有没有走完。

谁适合

IT运维与驻场服务商、帮客户维护安全设备和安全平台的企业。手里是年度维护、驻场值守、平台代维这类周期性合同的，天然贴合这一类。多数做IT服务的企业从这里起步，是因为运维合同相对常见、服务记录容易成序列；但"常见"不等于"容易"，持续性证明不出来的，照样退回。

证据怎么组织

• 合同：要有服务目录与服务级别约定、服务期限、续约或年度回顾的痕迹。框架协议下没有具体订单的，先补齐订单再谈申报。
• 交付记录：值班与巡检计划、日常巡检与监控记录、告警与工单处置、变更管理、漏洞通告与修复闭环、周期服务报告。报告要成序列，本期事件、处理结果、遗留问题都写进去。
• 人员：驻场还是远程、几个人、什么岗位、什么时候在岗，要能和值班表、工单处理人对上。人在册但社保不在本主体，是这一类的高频卡点。
• 工具：监控平台、漏洞扫描、日志与堡垒机类工具，附导出结果或界面记录，注明客户与时间段。

常见退回原因

• 十张巡检表，没有一条闭环。闭环比数量重要：一条"发现—上报—处置—复核—关闭"的完整记录，胜过一堆打勾的表格。
• 报告不成序列。合同写服务一年，报告只有两个月，中间空白无法解释服务是连续的。
• 把一次性交付当运维报。项目只有一次上线或一次整改，没有周期性服务过程，形态上就不属于这一类。
• 工具清单很长，没有任何使用记录。只写工具名和版本，说不清用在哪个客户、哪个时间段。

这一类的具体条件与材料清单，可以对照 CCRC 三级安全运维资质 那篇逐条看。

三、信息安全风险评估：方法能不能被另一个人复现

审什么

评估类审的是方法论的可复现性。同一个企业做十个项目，方法应当是稳定的；核查时拿两个项目一对比，方法有没有成形立刻能看出来。再往里看一层，是结论背后的过程：风险值是怎么算出来的，定级规则是什么，谁复核过。只有一份结论性报告、说不清算法的，很难站住。

谁适合

做等保测评、定级备案、安全评估的机构与企业，以及有稳定评估方法和复核机制的咨询团队。判断依据不是"我们也能做评估"，而是过去做的评估项目，报告结构是不是一套——每个项目换一种写法，看起来像十家机构出的报告，这一类就还不成立。

证据怎么组织

• 合同：写清评估对象、范围、交付物与成果形式。范围含糊的合同，后面很难证明你到底评了什么。
• 交付记录：评估依据与范围、资产识别与赋值、威胁与脆弱性分析、风险计算与定级规则、评估结论、整改建议、报告交付与客户确认。往上一层还要有把方法固定下来的东西：作业指导书、赋值标准、报告模板、质量控制与复核记录。
• 人员：评估、复核、报告批准分别是谁，要能与岗位能力对应。复核这一环常被漏掉，它恰恰是方法稳定性的证据。
• 工具：测评与分析类工具的导出结果，说明用在哪个项目、支撑了哪一部分结论。

常见退回原因

• 只有结论，没有过程。资产清单、访谈记录、分析表全空，风险值无从复算。
• 一项目一变模板。方法不稳定，等于没有方法。
• 整改建议是通用条款堆叠。建议与发现的风险对不上，看不出是针对这个系统写的。
• 等保边界没分清。哪些是本企业做的评估工作、哪些是引用外部机构的结果，混在一份材料里，责任与能力都说不清。

四、信息安全应急处理：演练证明准备过，事件记录证明处置过

审什么

应急类审的是响应能力，从准备到处置到复盘，是一条完整的能力链：有没有预案、有没有练过、真出事时怎么处置、处置完有没有复盘整改。这里有一条容易搞混的界线：演练记录证明"准备过"，真实事件记录证明"处置过"，两者互相替代不了，所以要分开列，不能混成一条。

谁适合

做攻防演练、应急响应、安全事件处置的服务商与团队。有真实事件处置经历的，材料支撑更扎实；以演练组织为主的企业同样可以梳理，但重心要放在预案的完整性、演练的组织过程和复盘整改上，不要拿演练记录去顶事件记录。日常巡检、监控告警属于运维的服务过程，不该塞进这一类。

证据怎么组织

• 合同：应急服务、演练组织、事件处置三类合同要能区分开；服务内容里看得出"响应"这个动作，而不是笼统的安全服务。
• 交付记录：预案要含组织、联系人、事件分级、处置流程；演练要有计划与记录；真实事件要有处置记录和处置报告；两者都要有复盘与整改。事件记录的价值在时间线——发现、上报、处置、恢复、复盘，五个点写清楚。
• 人员：指挥、处置、复盘三类角色，与预案里的组织架构、事件记录里的处理人对得上。
• 工具：取证、分析、监测类工具，附在具体事件或演练中的使用记录，而不是一张设备清单。

常见退回原因

• 把应急当运维写。材料全是巡检和告警处理，看不到事件分级、应急指挥、恢复与复盘。
• 演练与事件混成一条。同一条记录既当演练又当事件，两边的证明力都被削弱。
• 演练记录全部顺利。没有发现问题、没有问题整改，过程真实性经不起追问。
• 事件记录只有结论。写了"已恢复"，但没有时间线、没有处置动作、没有复盘。

五、软件安全开发：审的是研发流程里的安全节点，不是成品功能

审什么

这个方向评的是开发过程中的安全控制，不是产品功能有多安全。所以证据的重心在流程节点，不在成品：需求阶段有没有提安全要求、设计阶段有没有做威胁分析、编码有没有规范、代码审计和测试做没做、发现问题怎么修、谁验证关闭。制度里写了"每次发布前做安全测试"，就要能拿出对应版本的测试记录——写了做不到，比不写更麻烦。

谁适合

有自研软件产品的企业，以及为客户做软件开发服务的团队。两类业务的证据侧重不同：前者看产品线里的流程执行，后者看项目交付中的流程执行。纯代理销售、纯实施部署的业务不适合放这个方向——没有研发过程，就没有这个类别的证据。

证据怎么组织

• 合同：软件开发或产品交付类合同，交付物里能看出系统与版本；为客户开发的，合同要能对应到具体项目。
• 交付记录：安全需求、威胁分析与安全设计、安全编码规范、代码审计与白盒测试、开源与第三方组件管理、安全测试、上线前安全检查、漏洞修复闭环、发布与回滚。每个节点留的是评审记录、缺陷与修复记录、测试报告、版本记录。
• 人员：开发、安全测试或代码审计、发布审批三类角色分开；一人兼多角色时，要在记录里体现不同环节的签字。
• 工具：代码审计与组件分析报告必须能指到具体项目与版本，否则只能证明"买了个工具"。

常见退回原因

• 用产品功能说明代替流程记录。讲了一堆安全特性，拿不出研发过程中的任何一个安全节点记录。
• 工具报告没有项目归属。报告是通用扫描结果，不知道扫的是哪个系统、哪个版本。
• 只有修复清单，没有验证关闭。发现了多少问题不重要，重要的是谁修、谁验证、什么时候关闭。
• 流程文件与项目记录两张皮。制度要求的表单，在实际项目里从来没出现过。

六、信息系统灾难备份与恢复（资源服务类）：资源在、能切换、有验证

审什么

资源服务类审的是资源保障与运维能力：你有没有真实可用的灾备资源（机房、设备、云资源），资源是不是在持续运行，需要切过去的时候能不能切、切过去之后能不能维持。落点在"资源"和"验证"两个词上——只有资源清单没有切换验证，这一类是空的。

谁适合

IDC、云服务商、自建灾备中心并对外提供资源的企业。手里有可交付的资源清单、有负责资源运维与切换操作的队伍，匹配度就高。反过来说，不掌握资源、只做方案设计与演练组织的，应该去看技术服务类，不要往这一类里套。

证据怎么组织

• 合同：资源租用或灾备中心服务合同，写清资源类型、容量、服务期限与可用性安排；框架协议要有具体订单。
• 交付记录：资源与配置清单、恢复目标从业务需求推导出来的说明、切换或演练记录、演练报告与问题整改、日常运维记录。恢复目标不是拍出来的数字，要有推导过程。
• 人员：资源运维、切换操作、演练组织三类角色，与值班安排和演练记录上的操作人对得上。
• 工具：监控、备份与切换演练相关的平台或工具，附运行记录与演练时的操作记录。

常见退回原因

• 只有机房照片和资源清单。没有切换或演练验证，无法证明"需要时能切过去"。
• 恢复目标是拍的。没有从业务需求推导的说明，目标值与资源投入对不上。
• 把资源服务写成方案设计。材料重心跑到方案文本上，资源与运维记录反而缺失，方向就错了。
• 演练报告只有"成功"。没有过程、没有耗时、没有问题与整改，验证等于没做。

七、信息系统灾难备份与恢复（技术服务类）：方案能落地，演练能组织

审什么

技术服务类审的是方案设计与演练组织能力：恢复目标怎么从业务影响推出来，方案怎么落到资源和具体步骤，切换的顺序与回退怎么设计，演练怎么组织、发现的问题怎么闭环。和资源服务类的差别很清楚——这一类不要求资源是你的，但要求方法和组织是你的。

谁适合

灾备方案商、系统集成商、做灾备建设与咨询的团队。客户买的是你的设计和你的组织能力，资源可能在客户机房或第三方机房，这类业务形态正对应技术服务类。判断依据是：你交付的是不是方案、步骤、演练组织与报告，而不是机柜和带宽。

证据怎么组织

• 合同：灾备方案设计、灾备建设、演练组织类合同，服务内容里能看出设计或演练这个动作。
• 交付记录：业务影响与恢复目标说明、方案设计（含切换顺序与回退）、资源与配置建议、演练计划与记录、演练报告与整改。方案里要有针对这个客户的业务判断，不能是通用模板。
• 人员：方案设计、演练指挥、切换操作三类角色；演练当天的分工要能从记录里看出来。
• 工具：设计与演练辅助工具、切换脚本与操作记录，注明用于哪个客户、哪次演练。

常见退回原因

• 方案是通用模板。没有业务影响分析，恢复目标看不出是从客户业务推出来的。
• 有方案没演练。设计能力只有文本，没有组织过的验证，落不了地。
• 演练没有回退步骤。只写怎么切过去，不写切不回来怎么办，风险控制这一环缺失。
• 两类灾备材料互相套用。把资源清单当技术类的成果，或把方案文本当资源类的证明，两边都对不上。

八、网络安全审计：底稿决定结论是查出来的还是写出来的

审什么

审计类审的是检查评价的规范性与可追溯性。它和风险评估的区别在落点：评估指向风险与整改优先级，审计指向符合性与检查结论。所以这一类看的不是结论漂不漂亮，而是每条结论能不能顺着底稿回指到具体的记录、配置和时间点。工作底稿是这个方向的关键材料——它决定了结论是"查出来的"还是"写出来的"。

谁适合

安全审计与咨询服务商、做合规检查与符合性评价的企业。同时承接建设类和审计类业务的，要能在材料里说清两类业务怎么区分、审计的独立性怎么安排——这一点含糊带过，比不写更让人追问。

证据怎么组织

• 合同：审计范围、对象、依据写清楚；范围写得过宽的合同，后面很难界定"查了什么"。
• 交付记录：审计依据与范围、检查项或控制点清单、取证方法（访谈、配置核查、日志与记录检查）、抽样规则与样本说明、发现与分级、审计报告、整改跟踪与复核。底稿要与报告逐条对应。
• 人员：审计、复核、报告批准分开；复核记录是规范性的直接证据。
• 工具：配置核查、日志分析类工具的导出结果，能指到具体检查项与样本。

常见退回原因

• 没有工作底稿。报告里的发现回指不到任何记录，看起来像照着模板写的。
• 抽样规则说不清。为什么抽这几个、抽了多少、覆盖什么范围，答不上来就不算方法。
• 只列问题不跟踪整改。审计闭环缺一半，评价能力也就没证明完整。
• 建设与审计边界不清。同一批人既建又审、材料里不作区分，独立性与客观性都会被追问。

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

八个类别审的东西不同，但有一批材料是所有类别都要用的。把这批材料单独整理成一套"公共底座"，比每次申报重新翻箱倒柜省力得多，也更容易保持一致。

共用不等于照搬。有三条纪律，违反任何一条都会在核对时暴露出来：

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

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

十、等级与升级路径：在同一个类别里往上走

每个类别都分三级、二级、一级，三级为入门，一级对能力沉淀的要求更高。三级看的是"这个方向的基本能力成立不成立"，二级看的是能力的稳定性和项目覆盖面，一级看的是体系化程度、技术手段与复杂项目的承载能力。级别不同，要证明的东西是同一套能力的不同深度，不是换一套材料。

关于升级，有四句判断值得记住：

• 级别看的是能力和案例，不是成立年限。公司开了十年但项目单薄，不会因为"老"就够二级。
• 先三级，再往上。三级拿到后运行一段时间，把项目、人员、体系文件都跑顺，再申报二级，材料是从容的；一上来冲高等级，人员、项目、体系任何一项对不上都会被退回。
• 升级不是换类别。类别之间是能力方向的差别，不是难度差别。集成做不顺，换成运维也解决不了证据问题。
• 多类别并行要分清引用角度。一个企业同时报集成和运维是常见的，同一批项目可以用，但每一类只指它关心的环节。证书有效期 3 年，到期需按规定办理再认证，期间新增的项目要继续归档，别等到期前才回头找。

十一、行动清单：从类别到材料，按这个顺序推

看完八类，落到动作上其实是一条线。顺序别颠倒——先定类别，再盘项目，再补缺口，然后才谈文件。

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

八个类别拆到这一步，其实是同一句话的八种说法：你在这个方向上真的交付过什么，材料就要能把它讲到别人可以核查。类别选对了，材料是整理；类别选错了，材料是重做。而整理和重做之间的差别，往往就在你有没有在动手之前，把每一类"审什么"想清楚。

▍不确定自己这一类证据够不够？留言备注"CCRC逐类清单"，我发你一份按八个类别归档的材料对照表

普华智科 / CertFastLine 普华认证｜出口认证 & 检测 & 管理体系咨询 本文为合规科普参考，非法律意见；类别划分、等级条件与判定要求以 CCRC 现行实施规则为准