合规框架检查清单生成

解决什么问题

面对 SOC2、HIPAA、PCI-DSS、GDPR 等合规框架，团队常陷入重复劳动：把同一控制项对照多份标准逐条打勾，证据散落在文档、云配置和工单里，直到审计前才发现缺口。这个技能把「对照标准 → 评估现状 → 记录差距 → 排期修复」串成一次可重复的流程，输出结构化检查清单，而不是泛泛的建议。

核心能力与工作流程

• 识别适用框架：根据业务类型、处理的数据、客户要求和地域覆盖判断哪些框架适用，并找出跨框架重叠的控制项
• 映射控制项：把框架拆成控制类别与具体要求，如 SOC2 的五大信任服务标准、HIPAA 的行政/物理/技术防护、PCI-DSS 的 12 个要求族、GDPR 第 5–49 条
• 评估现状：每项控制标注为 已实施 / 部分实施 / 未实施 / 不适用，并尽可能引用现有文档或工具配置作为证据
• 生成清单与差距：按控制类别输出条目，包含需求描述、当前状态、所需证据、差距描述和修复工作量估算（天），并附分类就绪度汇总
• 排定修复优先级：综合风险严重度、审计影响、实施成本与跨框架覆盖度排序，优先处理「高影响、低成本」的快速见效项；可合并可一并满足多个标准的控制，例如一套日志方案同时覆盖 SOC2、HIPAA、PCI-DSS 的日志要求

使用时需说明目标框架、业务类型、现有安全措施和审计期限，对现有控制的描述越细，差距分析越准确。

适用边界与注意点

• 尚无安全体系的初创团队：先做风险评估建立基线，再借助云原生能力快速补齐信息安全、可接受使用、事件响应等基础策略
• 多框架并行审计：建立统一控制框架，把每条内部控制映射到各标准条款，审计员可能接受共享证据
• Serverless / PaaS 架构：注意共享责任模型，区分继承自云商的控制（物理安全、虚拟化补丁）与仍需自担的责任（应用安全、访问管理）
• 快速扩张或并购：把访问评审、安全培训等依赖人数和角色结构的流程自动化，并挂接到 HR 入职流程；并购对象的合规状态不会自动转移，需单独做差距评估并制定整合时间表
• 清单是活文档：整改期间每周更新状态，合规后每季度复审
• 「不适用」项必须附正式书面理由，审计员会逐条追问每个 N/A