compliance-checklist-generation

合规检查清单生成

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

工作流

1. 确定适用的框架 — 根据业务类型、处理的数据、客户要求和业务覆盖的地域，确定适用的合规框架。医疗 SaaS 需要遵循 HIPAA。处理信用卡的公司需要遵循 PCI-DSS。企业级 B2B SaaS 客户几乎都会要求 SOC2。服务覆盖欧盟用户则会触发 GDPR。多个框架通常存在重叠——找出共用的控制措施，以减少重复工作。

2. 将控制措施映射到要求 — 将每个框架拆分为其组成控制类别和单项要求。对于 SOC2，映射五项信任服务准则（安全性、可用性、处理完整性、保密性、隐私）。对于 HIPAA，涵盖管理、物理和技术保障措施。对于 PCI-DSS，处理全部 12 个要求类别。对于 GDPR，映射涵盖原则、权利和义务的第 5 至 49 条。

3. 评估当前状态 — 评估每项控制措施当前的实施状态：已实施（有证据）、部分实施（控制措施已存在但仍有差距）、未实施（尚无控制措施）或不适用（有记录的理由）。尽可能引用现有文档、工具配置或流程资料作为证据。

4. 生成包含状态和差距的检查清单 — 按控制类别组织结构化检查清单，每项都应显示：要求说明、当前状态、所需证据、差距说明（如有）以及整改工作量估算（小时/天）。包含摘要仪表板，显示各类别的总体就绪百分比。

5. 确定整改优先级 — 根据风险严重程度、审计影响、实施工作量以及在多个框架中的共用覆盖情况，对差距排序。应优先处理快速见效项（影响大、工作量低）。将可一并处理的相关整改项归组，例如，实施单一日志记录解决方案，同时满足 SOC2、HIPAA 和 PCI-DSS 的日志要求。

用法

说明所需的框架、业务类型、当前安全状况以及即将到来的审计期限。关于现有控制措施的背景信息越充分，差距分析就越准确。

提示词示例：

Generate a SOC2 Type II readiness checklist for our Series A startup. We're a B2B SaaS running on AWS. We use GitHub for code, Datadog for monitoring, and have about 20 employees. We need to be audit-ready in 6 months.

示例

示例 1：初创公司的 SOC2 Type II 就绪情况

输入： 一家拥有 20 名员工、基于 AWS 的 B2B SaaS 初创公司。使用 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	提供细分选择加入选项的 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 架构的公司——在共同责任模型下，许多基础设施控制措施由云服务提供商负责。记录哪些控制措施由提供商继承（物理安全、虚拟机监控程序修补），哪些仍由客户负责（应用程序安全、访问管理）。
• 快速增长或频繁调整组织架构——依赖员工人数或角色结构的控制措施（访问权限审查、安全培训完成情况）需要可扩展的流程。将入职和离职清单自动化，并将安全培训纳入 HR 入职流程。
• 通过收购继承合规状态——收购公司时，其合规状态不会自动转移。对被收购实体开展合规差距评估，并制定整合时间表，使其纳入公司的合规管理范围。