ISO 27001 审计前自查引擎

它解决什么问题

内部审核前一周才开始补记录，是 ISO 27001 项目最常见的死法。外部审核的发现往往集中在少数固定区域：风险清单超过一年没刷新、访问权限评审记录只有零碎截图、供应商清单停留在上次认证时的版本、事故复盘缺少事后回顾证据、管理评审漏掉了标准明确列出的输入项。等到审核员要证据时，补做的痕迹往往比不做更明显。

这个技能的思路不是帮你"生成合规材料"，而是反过来：用六个抽样驱动的问题对 ISMS 施压，让你在正式审核前就把空洞暴露出来。

工作原理

触发命令 /cs:iso27001-audit-prep，它会按顺序抛出六个问题：

• 三年覆盖节奏：Clause 4–10 与每个适用的 Annex A 控制是否都纳入了三年轮审计划，且样本中没有自审（需调用 ra-qm-team/skills/isms-audit-expert/ 下的调度脚本核对）。
• 风险清单新鲜度：是否按季度刷新（至少每年），每个高/关键风险是否至少关联一个 Annex A 控制，剩余风险接受是否有签字记录。
• 访问评审记录：Annex A.5.15、A.8.2、A.8.3 要求最近四个季度的连续记录，必须从 Okta / IAM 拉真实数据，不接受精心整理的审核专用包；过去 90 天内离职员工的权限回收需在 24 小时 SLA 内有证据，特权访问要按更细粒度复核。
• 供应商管理：A.5.19–A.5.21，关键 SaaS 供应商至少年度评审，个人数据处理方需有 DPA，使用第三方 AI 服务时需有 AI 专项合同条款。
• 事故响应证据：A.5.24–A.5.27 与 A.6.8，最近 5 起事故是否在 30 天 SLA 内完成事后回顾，严重级定义是否一致应用，通知时限是否与 GDPR 第 33/34 条对齐。
• 管理评审输入：Clause 9.3 要求的输入项是明确的（审核结果、风险、绩效、不符合、改进机会），输出需记录并跟踪到关闭。

什么时候跑它

Clause 9.2 年度内审前、Stage 1/2 认证审核前、第 2/3 年监督审核前、ISMS 范围发生实质变更（新事业部、新产品线、新 SaaS）之后、事故触发临时审核之后，以及高速增长期按季度跑。

边界与注意点

它只做自查施压，不替代审核员判断，也不负责生成符合性矩阵或整改工单。多框架视角请走 /cs:compliance-readiness；SOC 2 交叉对照约 75% 重叠；AI 服务另需 ISO 42001 侧的 /cs:aims-audit。跨框架整合评审优于多套分开的评审。