合规检查清单生成

它解决什么问题

合规审计的准备过程往往散落在多个团队：安全策略写在文档里，访问控制记录在 IAM 配置里，日志分布在 Datadog 和 CloudTrail 中。等到审计前几周才开始整理，结果要么证据链不完整，要么同一个控制项在不同框架下重复实现一遍。本技能做的不是"给你一份模板清单"，而是把控制项拆开、映射到具体需求、评估当前实现状态，并输出带优先级的修复计划。

核心能力与工作方式

技能按五个步骤运行：

• 识别适用框架 —— 根据业务类型、处理的数据、客户要求与地域覆盖判断哪些框架适用。医疗 SaaS 走 HIPAA，处理信用卡的必须满足 PCI-DSS，面向 EU 用户则触发 GDPR。多数情况下多个框架存在重叠控制项。
• 控制项映射 —— SOC 2 拆到五类 Trust Services Criteria，HIPAA 覆盖 Administrative、Physical、Technical Safeguards，PCI-DSS 对应 12 个 requirement family，GDPR 映射到 Article 5–49。
• 现状评估 —— 每项标记 Implemented、Partially Implemented、Not Implemented 或 Not Applicable，并引用现有文档、工具配置或流程产物作为证据。
• 生成清单 —— 按控制类别组织，每项包含需求描述、当前状态、所需证据、差距说明和工时估算，另附各分类就绪度的汇总看板。
• 优先级排序 —— 综合风险严重度、审计影响、实施成本和跨框架复用价值排序；把能同时满足 SOC 2、HIPAA、PCI-DSS 的日志方案归为一组一次做完。

适用边界与注意点

• 结果质量依赖你提供的上下文：现有控制措施、业务类型、审计截止日期越具体，差距分析越准。
• 它不会替你收集证据。清单标出"需要什么证据"，实际的截图、日志导出、审批记录仍需工程团队落实。
• 云上架构需要区分责任边界：serverless 或 PaaS 场景下，物理安全、hypervisor 补丁等控制项通常由云厂商继承，应用安全与访问管理仍归你。
• 标注 Not Applicable 的项必须写明理由，审计时每个 N/A 都会被追问。
• 清单是活文档，主动修复期间建议每周更新状态，合规后按季度回顾。