# Compliance Checklist Generation

> 为 SOC2、HIPAA、PCI-DSS 和 GDPR 生成合规检查清单，含差距分析与整改优先级。

- Skill: `cslawyer1985/compliance-checklist-generation` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add cslawyer1985/compliance-checklist-generation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/cslawyer1985/compliance-checklist-generation/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: cslawyer1985 (https://skillmd.com/u/cslawyer1985)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/cslawyer1985/compliance-checklist-generation

---


# 合规检查清单生成

为包括 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 入职流程。
- **来自收购的继承合规** — 收购公司时，其合规状态不会自动转移。对被收购实体进行合规差距评估，并制定将其纳入你合规范围的时间线。