compliance-checklist-generation

name	compliance-checklist-generation
description	为 SOC2、HIPAA、PCI-DSS 和 GDPR 生成合规检查清单，含差距分析与整改优先级。
license	MIT
metadata	{"author":"community","version":"1.0.0"}

合规检查清单生成

为包括 SOC2、HIPAA、PCI-DSS 和 GDPR 在内的主要监管框架创建结构化、可执行的合规检查清单。本技能将控制项映射到要求，评估每项控制的就绪状态，识别差距，并生成按优先级排序的整改计划。输出包含状态跟踪、证据要求和每项控制的工作量估算。

工作流

1. 识别适用的框架 — 根据业务类型、处理的数据、客户要求和地理覆盖范围，确定适用哪些合规框架。医疗 SaaS 需要 HIPAA。处理信用卡的公司需要 PCI-DSS。企业级 B2B SaaS 客户几乎普遍要求 SOC2。服务欧盟用户则触发 GDPR。多个框架经常重叠——识别共享控制项以减少重复工作。

2. 将控制项映射到要求 — 将每个框架拆解为各自的 control 类别与具体要求。对于 SOC2，映射到五项信任服务准则（Security、Availability、Processing Integrity、Confidentiality、Privacy）。对于 HIPAA，覆盖管理性、物理性和技术性保障措施。对于 PCI-DSS，覆盖全部 12 个要求族。对于 GDPR，映射到涵盖原则、权利与义务的第 5–49 条。

3. 评估当前状态 — 对每个控制项，评估当前实施状态：已实施（有证据）、部分实施（有控制但存在缺口）、未实施（无控制）、或不适用（有书面依据）。在可能的情况下，引用现有文档、工具配置或流程产物作为证据。

4. 生成带状态与差距的检查清单 — 生成按控制类别组织的结构化清单，每项显示：要求描述、当前状态、所需证据、差距描述（若有），以及整改工作量估算（小时/天）。包含一个汇总看板，展示每个类别的整体就绪百分比。

5. 整改优先级排序 — 结合风险严重度、审计影响、实施工作量和跨框架的共享覆盖率对差距排序。应优先处理"速赢"项（高影响、低工作量）。将可一并处理的关联整改项分组，例如实施单一日志方案同时满足 SOC2、HIPAA 和 PCI-DSS 的日志要求。

使用方式

指明你需要的框架、业务类型、当前安全态势，以及任何即将到来的审计截止日期。关于现有控制项的上下文越充分，差距分析就越准确。

示例提示：

为我们的 A 轮初创公司生成一份 SOC2 Type II 就绪检查清单。我们是一家运行在 AWS 上的 B2B SaaS。使用 GitHub 管理代码、Datadog 做监控，约有 20 名员工。我们需要在 6 个月内达到可审计状态。

示例

示例 1：某初创公司的 SOC2 Type II 就绪评估

输入： 20 人的 B2B SaaS 初创公司，运行在 AWS 上。使用 GitHub、Datadog、Google Workspace、Slack。尚无正式的安全计划。6 个月后接受 SOC2 审计。

输出：

就绪度概要： 约 34% 就绪（估算）

类别	控制项	已实施	部分	缺失	就绪度
访问控制	12	3	4	5	28%
变更管理	8	5	2	1	63%
事件响应	6	0	1	5	8%
风险评估	5	0	0	5	0%
监控与日志	7	4	2	1	57%
供应商管理	4	0	1	3	13%
人力资源与安全意识	6	1	2	3	17%

样例控制（访问控制类别）：

#	要求	状态	所需证据	差距 / 动作	工作量
AC-1	对所有生产系统强制 MFA	部分	AWS IAM 策略截图、IdP 配置	AWS 控制台已启用 MFA，但 EC2 实例的 SSH 访问尚未启用。为所有访问路径启用 MFA。	2 天
AC-2	基于角色的访问控制与最小权限	缺失	IAM 角色定义、访问矩阵	无正式 RBAC 模型。定义角色，映射到 AWS IAM 策略、GitHub 团队和 Google Workspace 组。	5 天
AC-3	季度访问审查	缺失	访问审查记录、审批日志	无对应流程。实施对所有系统访问的季度审查，需经理签字。工具建议：Vanta 或 Drata 用于自动跟踪。	3 天
AC-4	离职时 24 小时内移除访问	部分	离职清单、取消配置日志	存在临时流程但尚未文档化。将覆盖所有系统的清单正式化，尽可能通过身份提供商自动化。	2 天

优先整改（第 1 个月）： 风险评估（所有其他控制项的基础）、跨所有系统强制 MFA、正式访问控制策略文档、事件响应计划草案。

示例 2：电商的 GDPR 合规

输入： 总部在欧盟、销售消费电子的电商网站。收集姓名、地址、邮箱、支付数据、浏览行为。使用 Google Analytics、Meta Pixel、Mailchimp 做邮件营销。配送至所有欧盟国家。

输出：

就绪度概要： 约 42% 就绪（估算）

GDPR 领域	要求	满足	差距	就绪度
合法依据与同意	8	3	5	38%
数据主体权利	7	2	5	29%
数据处理记录	4	1	3	25%
国际传输	3	1	2	33%
安全措施	6	4	2	67%
泄露通知	3	1	2	33%
DPO 与治理	4	2	2	50%

样例控制（数据主体权利）：

#	要求	状态	差距 / 动作	工作量
DSR-1	访问权（第 15 条）——30 天内响应	缺失	无自动流程汇总关于某用户的所有数据。实施从数据库、Google Analytics、Mailchimp 导出数据。构建内部工具或使用隐私管理平台。	5 天
DSR-2	删除权（第 17 条）——按请求删除	部分	可从主数据库删除，但无法从分析、备份或 Mailchimp 删除。梳理所有数据存储并在所有系统中实现级联删除。	4 天
DSR-3	可携权（第 20 条）——机器可读导出	缺失	无导出功能。为用户数据构建 JSON/CSV 导出端点。	3 天
DSR-4	带细粒度 opt-in 的 Cookie 同意	部分	Cookie 横幅存在但使用预勾选框（不合规）。替换为合规的 CMP（如 Cookiebot、OneTrust），提供细分类别与"全部拒绝"选项。	2 天

最佳实践

• 从单一框架入手再扩展——SOC2 安全准则与 HIPAA 技术保障、PCI-DSS 高度重叠，因此第一个框架可提供基础。
• 跨框架映射控制项，识别共享要求，避免对同时满足多个标准的控制项重复投入。
• 使用合规自动化平台（Vanta、Drata、Secureframe）持续收集证据，而非临到审计前手忙脚乱。
• 正式记录"不适用"的依据——审计员会质疑每一个 N/A 项并要求书面理由。
• 为周期性控制项（季度访问审查、年度风险评估、渗透测试）设置日历提醒，避免审计周期间出现疏漏。
• 将检查清单视为活文档——在积极整改期间每周更新状态，合规后每季度审查一次。

边缘情况

• 没有既有安全计划的初创公司 — 从风险评估入手建立基线。许多控制项可通过云原生功能快速实施（AWS CloudTrail、GitHub 分支保护、Google Workspace 安全设置）。优先处理基础策略：信息安全、可接受使用、事件响应。
• 多框架审计 — 同时推进 SOC2 + HIPAA + PCI-DSS 时，构建统一的控制框架，将每个内部控件映射到各标准下所有适用要求。审计员可能接受重叠控制项的共享证据。
• 使用无服务器或 PaaS 架构的公司 — 在责任共担模型下，许多基础设施控制项转移给云提供商。记录哪些控制项是继承的（物理安全、hypervisor 补丁）与哪些仍属客户责任（应用安全、访问管理）。
• 快速增长或频繁组织变动 — 依赖员工数或角色结构的控制项（访问审查、安全培训完成度）需要可扩展的流程。自动化入职/离职清单，并将安全培训绑定到 HR 入职流程。
• 来自收购的继承合规 — 收购公司时，其合规状态不会自动转移。对被收购实体进行合规差距评估，并制定将其纳入你合规范围的时间线。