报告的价值在结论
基线核查的成果不是命令输出，而是可执行的结论。同一台机器扫一百条，把终端输出原样贴进报告等于把判断责任推回给读者。规范做法是每条落「当前值、基线值、差距、结论、责任人、期限」，结论只允许三种取值，例外必须附批准人。
基本信息
| 适用平台 | Linux / Windows / 网络设备通用 |
|---|---|
| 输出物 | 核查报告（原始记录表 + 结论表） |
| 结论取值 | 达标 / 整改 / 例外（例外须附批准） |
| 记录要求 | 有时间点、执行人、复核人 |
典型使用场景
- 等保测评前自查：先把差距变成整改清单，避免现场被逐条挑出
- 新系统上线验收：交付方与复核方共用一套模板与判读口径
- 季度复盘：与上季度报告逐条比对，确认整改是否真的落地
- 外包交付把关：没有结论与责任人的报告一律退回，避免口头承诺
判读三问与模板
判读三问与模板
# 1) 这条是否属于基线要求？写明条款号（CIS 项号或等保条款）
# 2) 当前值是减配还是业务必需？业务必需要有书面说明与批准
# 3) 处置动作谁复核？整改-复核-归档必须闭环
# 报告固定列（顺序统一便于比对）
# 核查项 | 当前值 | 基线值 | 差距 | 结论 | 责任人 | 期限字段怎么填
| 列 | 填写要求 | 常见错误 |
|---|---|---|
| 核查项 | 写清机器与对象，如 sshd PermitRootLogin@10.0.0.5 | 只写条目名，复核时无法定位 |
| 当前值 | 贴原始值或命令输出的关键行 | 写「已配置」「基本满足」这类模糊描述 |
| 基线值 | 引用标准原文与条款号 | 凭印象写要求，与测评口径不一致 |
| 结论 | 达标 / 整改 / 例外 三选一 | 写「建议优化」「后续关注」等无法跟踪的表述 |
| 责任人 | 具体到人，不写部门 | 写「运维组」，出问题时无人认领 |
报告两大翻车点：只贴命令输出不给结论；只提问题不给整改建议与责任人。核查时间点也必须写清，三个月前的记录不能当作当前状态举证。
把「例外」单独出一张表并注明批准人与有效期，到期自动回到整改清单：这是区分「管理起来的风险」与「没人管的遗留」的唯一办法。