简介这份《计算机信息系统分级保护方案》文档面向涉密信息系统建设与合规管理人员、安全集成工程师及等保测评备考者围绕分级保护要求给出可落地的整体设计思路。内容涵盖系统总体部署、物理安全防护、电磁泄漏防护等模块具体涉及服务器区、安全管理区与终端区的组网模式核心交换机VLAN划分与ACL访问控制策略入侵检测与网络安全审计的镜像部署以及邮件系统按1至7级安全级别控制信息流向的机制。物理层面则展开红外对射、红外报警、视频监控、门禁系统、线路干扰仪、视频干扰仪与红黑电源隔离插座等防护措施的部署位置、运行策略与管理制度。资源包共1个doc文件约2.06MB结构完整、条款清晰适合作为方案撰写模板或技术参考。目前已有58人学习可帮助读者快速理解分级保护的设计逻辑与防护要点减少从零梳理的时间成本。1. 一份 .doc 方案为什么总在测评现场翻车做过等保测评的人都有个共识手里那份《计算机信息系统分级保护方案.doc》写得再厚到了现场该扣分还是扣分。问题往往不在技术本身而在这份文档从立项那天起就被当成了交差材料——复制模板、改个系统名、把拓扑图一贴就完事。等到测评机构拿着检查表逐条核对才发现定级依据对不上业务实际、安全域划分和网络现状两张皮、控制项照搬了三级要求却漏掉了系统自身的特殊场景。这份方案真正要解决的问题是把一个信息系统的安全保护等级从拍脑袋定级变成有依据、可落地、能验证的工程闭环。它适合三类人——需要独立完成定级备案的系统负责人、要按方案配置设备的运维工程师、以及准备迎检的安全管理员。核心逻辑就一条先定级、再定域、后定措施每一步都要留下可追溯的记录。热搜里计算机信息系统和分级保护这两个词落到实操上就是定级对象怎么划、等级怎么算、措施怎么配这三件事。2. 定级对象与等级把拍脑袋变成可复算的推导2.1 先划清边界再谈等级定级的第一步不是查表是确定定级对象到底是谁。很多方案翻车就翻在这里把整个机房当成一个系统或者把一套业务拆成七八个系统分别定级结果备案时被退回。常见做法是——以独立运行、独立管理、承担独立业务为原则划分。一个对外提供服务的业务系统即使跑在三台服务器上只要业务逻辑闭环、由同一团队运维就应作为一个定级对象。边界划完后要写清楚三样东西系统承载的业务类型、服务的用户范围内部/公众、以及一旦中断造成的影响面。这三样直接决定后面受侵害的客体和侵害程度。我一般会让业务方用一句话回答这个系统停了谁最先打电话来骂答案往往比填表更接近真实等级。2.2 等级由两个维度相乘得出等级不是选出来的是算出来的。依据是受侵害的客体乘以对客体的侵害程度。客体分三类公民法人合法权益、社会秩序公共利益、国家安全。侵害程度分三档一般损害、严重损害、特别严重损害。两者交叉后落到五级。受侵害客体一般损害严重损害特别严重损害公民法人合法权益一级二级二级社会秩序公共利益二级三级三级国家安全三级四级五级实操中最容易出错的是把业务重要直接等同于等级高。一个内部OA再重要只要不涉及公共利益顶多二级。反过来一个面向公众的预约系统哪怕数据量不大只要泄露会影响社会秩序就可能到三级。定级时要把判断依据写成文字比如该系统存储10万条公民身份信息泄露后可能被用于电信诈骗判定为对社会秩序造成严重损害这样测评时才有据可查。2.3 把定级过程固化成可复现的步骤定级不是一次性动作系统扩容、业务变更后都要复核。建议把下面这套流程写成脚本或检查表每次变更后跑一遍。# 定级辅助计算输入客体类型和侵害程度输出建议等级 # 客体权重1公民法人, 2社会秩序, 3国家安全 # 侵害程度1一般, 2严重, 3特别严重 def calc_level(object_type, damage_level): # 等级矩阵行对应客体列对应侵害程度 matrix { 1: {1: 1, 2: 2, 3: 2}, # 公民法人合法权益 2: {1: 2, 2: 3, 3: 3}, # 社会秩序公共利益 3: {1: 3, 2: 4, 3: 5}, # 国家安全 } if object_type not in matrix: raise ValueError(客体类型必须是 1/2/3) if damage_level not in (1, 2, 3): raise ValueError(侵害程度必须是 1/2/3) return matrix[object_type][damage_level] # 示例面向公众的预约系统泄露影响社会秩序严重损害 level calc_level(object_type2, damage_level2) print(f建议等级第 {level} 级) # 输出建议等级第 3 级这段代码的价值不在于计算本身而在于把判断逻辑显式化。参数说明object_type对应三类客体damage_level对应三档侵害程度矩阵值直接来自定级指南。实际使用时把每次定级的输入和输出记录到台账里系统变更时重新跑一遍等级变化一目了然。注意代码只做辅助最终等级还要经专家评审确认不能拿脚本输出直接备案。3. 安全域划分让拓扑图和控制措施对得上号3.1 安全域不是画着好看是隔离依据定级完成后下一步是把系统拆成若干安全域。安全域的本质是同一防护需求的区域同一域内设备等级相同、访问策略一致。常见划分方式边界接入域、核心业务域、数据存储域、运维管理域、终端接入域。划分依据是业务流向和数据敏感度不是物理位置。很多方案把安全域画得很漂亮但一问域间用什么设备隔离、策略怎么配就答不上来。正确的顺序是先画数据流图标出哪些数据从哪来到哪去再把流向相同、敏感度相近的节点圈成一个域。域间必须经过访问控制设备且默认拒绝。这一步做完后面的控制措施才有挂靠点。3.2 用表格把域间策略写死安全域划分的产出物是一张域间访问控制矩阵。这张表是后续配置防火墙、网闸的直接依据也是测评时必查的材料。源域目的域允许协议/端口访问方向审批人终端接入域核心业务域HTTPS/443单向安全管理员运维管理域核心业务域SSH/22单向安全管理员核心业务域数据存储域MySQL/3306单向安全管理员边界接入域核心业务域仅限已发布API单向安全管理员其他数据存储域拒绝——这张表的关键是默认拒绝和最小权限。我见过太多方案只写了允许项没写拒绝项结果测评时被追问未列出的流量怎么处理。正确做法是最后一行明确写其他一律拒绝并在设备上配置隐式拒绝规则。审批人一栏不能空每次策略变更都要有记录这是可追溯性的基本要求。3.3 域间隔离设备的选型与配置要点不同等级的系统域间隔离设备要求不同。二级系统可用防火墙做逻辑隔离三级系统涉及重要数据时建议用网闸或单向导入设备。选型时看三个参数吞吐量要匹配业务峰值、并发连接数要留30%余量、策略条数要能覆盖矩阵表。配置时有个血泪经验先配拒绝所有再逐条加允许最后测试。反过来先配允许再补拒绝很容易漏掉某条路径。配置完成后用扫描工具从每个域分别发起探测确认只有矩阵表里列出的路径可达。这一步不能省很多方案文档写得完美设备上却留着一条any any permit的临时规则忘了删。4. 控制措施落地从文档条款到设备配置的映射4.1 把控制项拆成谁在什么设备上做什么分级保护方案里最虚的部分就是控制措施——写一堆应部署入侵检测应启用审计但没写具体在哪台设备、由谁操作、多久检查一次。落地做法是把每个控制项拆成四要素责任岗位、承载设备、配置动作、验证方法。以身份鉴别为例责任岗位是系统管理员承载设备是应用服务器和数据库配置动作是启用强密码策略并绑定双因素验证方法是尝试用弱密码登录应被拒绝。这样拆完方案就从要求变成了工单。测评时专家问你怎么证明做了身份鉴别直接调出配置截图和测试记录即可。4.2 三级系统必配的几类措施与参数三级系统的控制项比二级多出不少但真正容易漏配的是下面几类。每类给出关键参数配置时照着填。# 以Linux应用服务器为例三级系统身份鉴别与审计的关键配置 # 1. 密码策略长度≥8含大小写数字特殊字符90天更换 # 编辑 /etc/security/pwquality.conf minlen 8 minclass 4 maxrepeat 2 # 2. 登录失败锁定5次失败锁定10分钟 # 编辑 /etc/pam.d/system-auth auth required pam_tally2.so deny5 unlock_time600 # 3. 审计日志记录登录、提权、文件访问保留180天 # 编辑 /etc/audit/auditd.conf num_logs 12 max_log_file 200 max_log_file_action ROTATE # 4. 启用审计规则 auditctl -w /etc/passwd -p wa -k passwd_change auditctl -w /etc/shadow -p wa -k shadow_change参数说明minclass4表示必须包含四类字符deny5和unlock_time600对应登录失败锁定策略num_logs12配合max_log_file200保证日志容量满足180天留存。审计规则里-p wa表示监控写入和属性变更-k是自定义关键字便于检索。配置完用auditctl -l确认规则生效再手动改一次文件验证日志是否记录。注意不同发行版的PAM模块名可能不同配置前先确认系统版本。4.3 数据备份与恢复的验证不能只写在纸上方案里都会写定期备份但测评时真正看的是恢复演练记录。三级系统要求本地备份加异地备份备份介质要场外存放。关键参数全量备份每周一次增量备份每天一次恢复演练每季度一次恢复时间目标RTO不超过4小时。验证方法很直接从备份介质恢复一份数据到测试环境比对数据完整性和时间戳。我一般会随机抽一个文件核对哈希值。这一步做完把恢复过程、耗时、结果写成记录附上截图。没有这份记录数据备份这一项基本拿不到分。5. 避坑与排查测评现场最容易被扣分的五个点5.1 定级依据与业务实际脱节现象方案里写该系统涉及公民个人信息定为三级但测评时发现系统只存了姓名和工号没有身份证号、手机号等敏感字段。原因定级时照抄了同类系统的模板没做数据梳理。解决定级前先做一次数据资产盘点列出所有字段并标注敏感级别用实际数据支撑定级结论。盘点表要作为方案附件。5.2 安全域划分与网络现状两张皮现象方案画了五个安全域现场一看核心业务域和终端接入域在同一网段中间没有隔离设备。原因方案是设计阶段写的实施时为了省事没按设计布线。解决方案评审时必须让网络实施方参与确认每条域间策略都有对应设备承载。如果现状无法整改要么调整方案要么在方案里写明补偿措施和整改计划。5.3 控制措施只写要求不写参数现象方案写应启用访问控制但没写访问控制列表的具体内容。测评时专家要求提供配置拿不出来。原因写方案的人不懂设备配置懂配置的人没参与写方案。解决每个控制项后面附一张配置对照表写明设备型号、配置命令、预期结果。这张表由运维工程师填写安全管理员审核。5.4 审计日志留存时间不够现象方案要求日志留存180天实际设备只配了30天滚动。原因设备默认配置没改或者存储空间不足自动覆盖。解决配置前先算存储需求——每天日志量乘以180天留20%余量。如果本地存储不够配日志服务器集中收集。配置完用du -sh检查日志目录确认容量。5.5 应急预案没有演练记录现象方案附了应急预案但拿不出演练记录。原因预案写完就归档从没实际跑过。解决每季度做一次桌面演练或实操演练记录参与人、演练场景、发现的问题、改进措施。演练记录要有签字不能只有电子版。这一项在三级测评里权重不低别抱侥幸心理。6. 用一份检查表把方案从文档变成可验证的工程方案写完不是终点能通过测评、能指导运维才算数。我自己的习惯是在方案定稿前用一份检查表反向验证——把测评机构可能问的问题提前问自己一遍。这份检查表不写在方案正文里但每个编制人都该有一份。检查项验证方式通过标准定级依据调取数据盘点表每个敏感字段有标注等级推导可复算安全域边界现场查看隔离设备域间策略与矩阵表一致无多余放通身份鉴别尝试弱密码登录被拒绝并记录日志访问控制从非授权域发起访问被拒绝无响应审计日志查看日志留存周期满足方案要求天数可检索备份恢复调取最近一次恢复记录有记录、有截图、数据完整应急预案调取演练记录有签字、有改进项闭环这份表的价值在于把我觉得做了变成我能证明做了。每次系统变更后重新过一遍变更部分重点核对。我一般会把检查表存成电子表格每季度更新一次状态测评前打印出来逐项打勾。最后一个习惯方案里的每个数字都要有出处。写日志留存180天就要能说出依据是哪个条款写RTO不超过4小时就要有业务方确认的邮件。没有出处的数字测评时就是给自己挖坑。这套方法我用了几年最大的体会是——方案的质量不取决于写得多厚而取决于每个结论能不能被验证。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/29 17:56:01 · 阅读 1.2k 计算机信息系统分级保护方案：从定级到测评的工程化落地指南
简介这份《计算机信息系统分级保护方案》文档面向涉密信息系统建设与合规管理人员、安全集成工程师及等保测评备考者围绕分级保护要求给出可落地的整体设计思路。内容涵盖系统总体部署、物理安全防护、电磁泄漏防护等模块具体涉及服务器区、安全管理区与终端区的组网模式核心交换机VLAN划分与ACL访问控制策略入侵检测与网络安全审计的镜像部署以及邮件系统按1至7级安全级别控制信息流向的机制。物理层面则展开红外对射、红外报警、视频监控、门禁系统、线路干扰仪、视频干扰仪与红黑电源隔离插座等防护措施的部署位置、运行策略与管理制度。资源包共1个doc文件约2.06MB结构完整、条款清晰适合作为方案撰写模板或技术参考。目前已有58人学习可帮助读者快速理解分级保护的设计逻辑与防护要点减少从零梳理的时间成本。1. 一份 .doc 方案为什么总在测评现场翻车做过等保测评的人都有个共识手里那份《计算机信息系统分级保护方案.doc》写得再厚到了现场该扣分还是扣分。问题往往不在技术本身而在这份文档从立项那天起就被当成了交差材料——复制模板、改个系统名、把拓扑图一贴就完事。等到测评机构拿着检查表逐条核对才发现定级依据对不上业务实际、安全域划分和网络现状两张皮、控制项照搬了三级要求却漏掉了系统自身的特殊场景。这份方案真正要解决的问题是把一个信息系统的安全保护等级从拍脑袋定级变成有依据、可落地、能验证的工程闭环。它适合三类人——需要独立完成定级备案的系统负责人、要按方案配置设备的运维工程师、以及准备迎检的安全管理员。核心逻辑就一条先定级、再定域、后定措施每一步都要留下可追溯的记录。热搜里计算机信息系统和分级保护这两个词落到实操上就是定级对象怎么划、等级怎么算、措施怎么配这三件事。2. 定级对象与等级把拍脑袋变成可复算的推导2.1 先划清边界再谈等级定级的第一步不是查表是确定定级对象到底是谁。很多方案翻车就翻在这里把整个机房当成一个系统或者把一套业务拆成七八个系统分别定级结果备案时被退回。常见做法是——以独立运行、独立管理、承担独立业务为原则划分。一个对外提供服务的业务系统即使跑在三台服务器上只要业务逻辑闭环、由同一团队运维就应作为一个定级对象。边界划完后要写清楚三样东西系统承载的业务类型、服务的用户范围内部/公众、以及一旦中断造成的影响面。这三样直接决定后面受侵害的客体和侵害程度。我一般会让业务方用一句话回答这个系统停了谁最先打电话来骂答案往往比填表更接近真实等级。2.2 等级由两个维度相乘得出等级不是选出来的是算出来的。依据是受侵害的客体乘以对客体的侵害程度。客体分三类公民法人合法权益、社会秩序公共利益、国家安全。侵害程度分三档一般损害、严重损害、特别严重损害。两者交叉后落到五级。受侵害客体一般损害严重损害特别严重损害公民法人合法权益一级二级二级社会秩序公共利益二级三级三级国家安全三级四级五级实操中最容易出错的是把业务重要直接等同于等级高。一个内部OA再重要只要不涉及公共利益顶多二级。反过来一个面向公众的预约系统哪怕数据量不大只要泄露会影响社会秩序就可能到三级。定级时要把判断依据写成文字比如该系统存储10万条公民身份信息泄露后可能被用于电信诈骗判定为对社会秩序造成严重损害这样测评时才有据可查。2.3 把定级过程固化成可复现的步骤定级不是一次性动作系统扩容、业务变更后都要复核。建议把下面这套流程写成脚本或检查表每次变更后跑一遍。# 定级辅助计算输入客体类型和侵害程度输出建议等级 # 客体权重1公民法人, 2社会秩序, 3国家安全 # 侵害程度1一般, 2严重, 3特别严重 def calc_level(object_type, damage_level): # 等级矩阵行对应客体列对应侵害程度 matrix { 1: {1: 1, 2: 2, 3: 2}, # 公民法人合法权益 2: {1: 2, 2: 3, 3: 3}, # 社会秩序公共利益 3: {1: 3, 2: 4, 3: 5}, # 国家安全 } if object_type not in matrix: raise ValueError(客体类型必须是 1/2/3) if damage_level not in (1, 2, 3): raise ValueError(侵害程度必须是 1/2/3) return matrix[object_type][damage_level] # 示例面向公众的预约系统泄露影响社会秩序严重损害 level calc_level(object_type2, damage_level2) print(f建议等级第 {level} 级) # 输出建议等级第 3 级这段代码的价值不在于计算本身而在于把判断逻辑显式化。参数说明object_type对应三类客体damage_level对应三档侵害程度矩阵值直接来自定级指南。实际使用时把每次定级的输入和输出记录到台账里系统变更时重新跑一遍等级变化一目了然。注意代码只做辅助最终等级还要经专家评审确认不能拿脚本输出直接备案。3. 安全域划分让拓扑图和控制措施对得上号3.1 安全域不是画着好看是隔离依据定级完成后下一步是把系统拆成若干安全域。安全域的本质是同一防护需求的区域同一域内设备等级相同、访问策略一致。常见划分方式边界接入域、核心业务域、数据存储域、运维管理域、终端接入域。划分依据是业务流向和数据敏感度不是物理位置。很多方案把安全域画得很漂亮但一问域间用什么设备隔离、策略怎么配就答不上来。正确的顺序是先画数据流图标出哪些数据从哪来到哪去再把流向相同、敏感度相近的节点圈成一个域。域间必须经过访问控制设备且默认拒绝。这一步做完后面的控制措施才有挂靠点。3.2 用表格把域间策略写死安全域划分的产出物是一张域间访问控制矩阵。这张表是后续配置防火墙、网闸的直接依据也是测评时必查的材料。源域目的域允许协议/端口访问方向审批人终端接入域核心业务域HTTPS/443单向安全管理员运维管理域核心业务域SSH/22单向安全管理员核心业务域数据存储域MySQL/3306单向安全管理员边界接入域核心业务域仅限已发布API单向安全管理员其他数据存储域拒绝——这张表的关键是默认拒绝和最小权限。我见过太多方案只写了允许项没写拒绝项结果测评时被追问未列出的流量怎么处理。正确做法是最后一行明确写其他一律拒绝并在设备上配置隐式拒绝规则。审批人一栏不能空每次策略变更都要有记录这是可追溯性的基本要求。3.3 域间隔离设备的选型与配置要点不同等级的系统域间隔离设备要求不同。二级系统可用防火墙做逻辑隔离三级系统涉及重要数据时建议用网闸或单向导入设备。选型时看三个参数吞吐量要匹配业务峰值、并发连接数要留30%余量、策略条数要能覆盖矩阵表。配置时有个血泪经验先配拒绝所有再逐条加允许最后测试。反过来先配允许再补拒绝很容易漏掉某条路径。配置完成后用扫描工具从每个域分别发起探测确认只有矩阵表里列出的路径可达。这一步不能省很多方案文档写得完美设备上却留着一条any any permit的临时规则忘了删。4. 控制措施落地从文档条款到设备配置的映射4.1 把控制项拆成谁在什么设备上做什么分级保护方案里最虚的部分就是控制措施——写一堆应部署入侵检测应启用审计但没写具体在哪台设备、由谁操作、多久检查一次。落地做法是把每个控制项拆成四要素责任岗位、承载设备、配置动作、验证方法。以身份鉴别为例责任岗位是系统管理员承载设备是应用服务器和数据库配置动作是启用强密码策略并绑定双因素验证方法是尝试用弱密码登录应被拒绝。这样拆完方案就从要求变成了工单。测评时专家问你怎么证明做了身份鉴别直接调出配置截图和测试记录即可。4.2 三级系统必配的几类措施与参数三级系统的控制项比二级多出不少但真正容易漏配的是下面几类。每类给出关键参数配置时照着填。# 以Linux应用服务器为例三级系统身份鉴别与审计的关键配置 # 1. 密码策略长度≥8含大小写数字特殊字符90天更换 # 编辑 /etc/security/pwquality.conf minlen 8 minclass 4 maxrepeat 2 # 2. 登录失败锁定5次失败锁定10分钟 # 编辑 /etc/pam.d/system-auth auth required pam_tally2.so deny5 unlock_time600 # 3. 审计日志记录登录、提权、文件访问保留180天 # 编辑 /etc/audit/auditd.conf num_logs 12 max_log_file 200 max_log_file_action ROTATE # 4. 启用审计规则 auditctl -w /etc/passwd -p wa -k passwd_change auditctl -w /etc/shadow -p wa -k shadow_change参数说明minclass4表示必须包含四类字符deny5和unlock_time600对应登录失败锁定策略num_logs12配合max_log_file200保证日志容量满足180天留存。审计规则里-p wa表示监控写入和属性变更-k是自定义关键字便于检索。配置完用auditctl -l确认规则生效再手动改一次文件验证日志是否记录。注意不同发行版的PAM模块名可能不同配置前先确认系统版本。4.3 数据备份与恢复的验证不能只写在纸上方案里都会写定期备份但测评时真正看的是恢复演练记录。三级系统要求本地备份加异地备份备份介质要场外存放。关键参数全量备份每周一次增量备份每天一次恢复演练每季度一次恢复时间目标RTO不超过4小时。验证方法很直接从备份介质恢复一份数据到测试环境比对数据完整性和时间戳。我一般会随机抽一个文件核对哈希值。这一步做完把恢复过程、耗时、结果写成记录附上截图。没有这份记录数据备份这一项基本拿不到分。5. 避坑与排查测评现场最容易被扣分的五个点5.1 定级依据与业务实际脱节现象方案里写该系统涉及公民个人信息定为三级但测评时发现系统只存了姓名和工号没有身份证号、手机号等敏感字段。原因定级时照抄了同类系统的模板没做数据梳理。解决定级前先做一次数据资产盘点列出所有字段并标注敏感级别用实际数据支撑定级结论。盘点表要作为方案附件。5.2 安全域划分与网络现状两张皮现象方案画了五个安全域现场一看核心业务域和终端接入域在同一网段中间没有隔离设备。原因方案是设计阶段写的实施时为了省事没按设计布线。解决方案评审时必须让网络实施方参与确认每条域间策略都有对应设备承载。如果现状无法整改要么调整方案要么在方案里写明补偿措施和整改计划。5.3 控制措施只写要求不写参数现象方案写应启用访问控制但没写访问控制列表的具体内容。测评时专家要求提供配置拿不出来。原因写方案的人不懂设备配置懂配置的人没参与写方案。解决每个控制项后面附一张配置对照表写明设备型号、配置命令、预期结果。这张表由运维工程师填写安全管理员审核。5.4 审计日志留存时间不够现象方案要求日志留存180天实际设备只配了30天滚动。原因设备默认配置没改或者存储空间不足自动覆盖。解决配置前先算存储需求——每天日志量乘以180天留20%余量。如果本地存储不够配日志服务器集中收集。配置完用du -sh检查日志目录确认容量。5.5 应急预案没有演练记录现象方案附了应急预案但拿不出演练记录。原因预案写完就归档从没实际跑过。解决每季度做一次桌面演练或实操演练记录参与人、演练场景、发现的问题、改进措施。演练记录要有签字不能只有电子版。这一项在三级测评里权重不低别抱侥幸心理。6. 用一份检查表把方案从文档变成可验证的工程方案写完不是终点能通过测评、能指导运维才算数。我自己的习惯是在方案定稿前用一份检查表反向验证——把测评机构可能问的问题提前问自己一遍。这份检查表不写在方案正文里但每个编制人都该有一份。检查项验证方式通过标准定级依据调取数据盘点表每个敏感字段有标注等级推导可复算安全域边界现场查看隔离设备域间策略与矩阵表一致无多余放通身份鉴别尝试弱密码登录被拒绝并记录日志访问控制从非授权域发起访问被拒绝无响应审计日志查看日志留存周期满足方案要求天数可检索备份恢复调取最近一次恢复记录有记录、有截图、数据完整应急预案调取演练记录有签字、有改进项闭环这份表的价值在于把我觉得做了变成我能证明做了。每次系统变更后重新过一遍变更部分重点核对。我一般会把检查表存成电子表格每季度更新一次状态测评前打印出来逐项打勾。最后一个习惯方案里的每个数字都要有出处。写日志留存180天就要能说出依据是哪个条款写RTO不超过4小时就要有业务方确认的邮件。没有出处的数字测评时就是给自己挖坑。这套方法我用了几年最大的体会是——方案的质量不取决于写得多厚而取决于每个结论能不能被验证。希望帮到你。本文还有配套的精品资源点击获取