mcpField
R
regulatory-compliance

regulatory-compliance

github.com/oimiragieo安全4443 次安装17 周前更新
代码仓库

关于 regulatory-compliance

用于评估系统、流程、界面和数据处理协议的合规技能,覆盖隐私与无障碍要求。输出 PASS、CONDITIONAL 或 FAIL 结论,并列出分级发现和整改任务。

主要功能

  1. 01GDPR 与 CCPA 评估
  2. 02隐私设计审查
  3. 03ADA 与 WCAG 无障碍审计
  4. 04数据处理协议验证
  5. 05法规监测指导
  6. 06结构化结论与整改任务

适用场景

  1. 01评估处理个人数据的系统
  2. 02审查供应商协议与 DPA
  3. 03审计面向公众的界面无障碍性
  4. 04在 CI 流水线加入合规检查

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/oimiragieo/agent-studio --skill regulatory-compliance

安装后在 Claude Code 中输入/regulatory-compliance确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

commands/
regulatory-compliance.md
hooks/
post-execute.cjs
pre-execute.cjs
references/
research-requirements.md
rules/
regulatory-compliance.md
schemas/
input.schema.json
output.schema.json
scripts/
main.cjs
templates/
implementation-template.md

详细介绍

监管合规技能

概述

根据主要监管框架评估系统、流程和制品:

  • GDPR/CCPA — 符合欧盟和加利福尼亚州/美国各州的数据隐私法律
  • Privacy-by-Design — 按照 Ann Cavoukian 的 7 项原则,主动将隐私保护融入设计
  • ADA/WCAG — 符合 ADA 和 WCAG 2.1/2.2 AA 标准的 Web 和软件无障碍要求
  • DPA 验证 — 检查数据处理协议的完整性和正确性
  • 监管监控 — 提供跨司法管辖区跟踪监管变化的指导

输出结果分为 PASS / CONDITIONAL / FAIL,并包含按严重程度分级的发现和可执行的整改任务。

适用场景

  • 部署任何收集、处理或存储个人数据的功能之前
  • 在涉及 PII 或用户数据的系统架构评审期间
  • 验证第三方供应商协议和 DPA 时
  • 在欧盟、加利福尼亚州或任何实施隐私法的司法管辖区推出产品之前
  • 审计面向公众的界面是否符合无障碍要求时
  • 将其作为数据管道和 API 的 CI 合规门禁

铁律

  1. 绝不在合规不完整时报告 PASS — 任何项目不合格,结果都应为 CONDITIONAL 或 FAIL;部分合规会掩盖违规行为。
  2. 始终附上由具体责任 Agent 执行的整改任务 — 含糊的发现无法带来修复;每项 FAIL/CONDITIONAL 都必须说明由谁、如何修复。
  3. 绝不跳过多司法管辖区检查 — GDPR、CCPA 和 20 多部美国各州法律可能同时适用;必须明确记录范围。
  4. 始终在设计阶段验证隐私设计 — 部署后再补充隐私保护,成本会高得多,效果也更差。
  5. 绝不将无障碍要求视为可选项 — ADA/WCAG 合规面临现实的诉讼风险(2025 年上半年 ADA 诉讼增加 37%);必须验证所有公开界面。
  6. 始终记录法规版本和评估日期 — 监管指南会不断演进;每份报告都必须标注法规版本和评估日期。

工作流

第 1 步:范围定义

确定哪些法规适用于评估对象:

## Compliance Scope

- Subject: [System / Feature / DPA / Interface being assessed]
- Jurisdictions: [EU / California / Virginia / Colorado / Other states]
- Applicable Regulations:
  - [ ] GDPR (EU General Data Protection Regulation)
  - [ ] CCPA/CPRA (California Consumer Privacy Act / California Privacy Rights Act)
  - [ ] US State Laws (VCDPA, CPA, CTDPA, etc.)
  - [ ] ADA / Section 508 (US accessibility)
  - [ ] WCAG 2.1/2.2 AA (Web Content Accessibility Guidelines)
  - [ ] DPA Review (vendor data processing agreement)
- Personal Data Categories Involved: [list data types]
- Assessment Date: [YYYY-MM-DD]
- Regulation Versions Referenced: [e.g., GDPR as amended 2024, CPRA effective 2023]
第 2 步:GDPR/CCPA 合规检查清单

执行与评估对象相关的检查项:

数据清单与映射
  • 已编目所有个人数据类型(姓名、电子邮件、IP、行为数据、生物特征数据等)
  • 已记录数据流:收集 → 处理 → 存储 → 共享 → 删除
  • 已明确界定每种数据类型的用途,并限制其使用范围
  • 已记录处理的法律依据(同意、合法利益、合同、法律义务)
  • 已按数据类型定义数据保留期限
同意管理
  • GDPR:已针对每种处理目的分别取得同意(而非一揽子接受)
  • GDPR:撤回同意与给予同意同样便捷(一键取消订阅)
  • CCPA:已提供退出数据出售/共享的机制(“请勿出售或共享我的个人信息”)
  • 已保存同意记录(谁同意、何时同意、同意什么)
  • 已为跟踪 Cookie 实施 Cookie 同意机制(仅适用于 GDPR)
消费者权利请求处理
  • 已建立访问权请求机制(DSR/DSAR 门户或流程)
  • 已在规定时限内满足删除权请求(GDPR:30 天,CCPA:45 天)
  • 支持数据可携权(GDPR:提供结构化、机器可读的格式)
  • 支持更正/修正不准确信息的权利
  • DSR 记录至少保存 24 个月(审计跟踪)
第三方与供应商管理
  • 已与所有处理个人数据的供应商签订 DPA
  • 已维护供应商清单并每年审查
  • 国际数据传输已纳入标准合同条款(SCC)
  • DPA 中包含对子处理方的通知条款
安全要求
  • 已实施合理的安全措施(静态和传输中的加密)
  • 已执行访问控制和最小权限原则
  • 已记录数据泄露通知流程(GDPR:72 小时内通知监管机构)
  • 已对处理活动开展安全风险评估
第 3 步:隐私设计审查

根据 Ann Cavoukian 的 7 项基本原则进行评估:

原则评估
1. 主动而非被动隐私是否从设计阶段就融入其中,而非事后添加?
2. 默认保护隐私默认设置是否为最能保护隐私的设置?
3. 将隐私融入设计隐私是否是系统架构不可或缺的一部分,而非后加的功能?
4. 完整功能隐私是否与正当的业务目标并存?
5. 端到端安全是否确保从收集到删除的整个生命周期安全?
6. 可见性与透明度政策和实践是否公开且可验证?
7. 尊重用户隐私所有设计决策是否都以用户为中心?

将每项原则记录为:已实施 / 部分实施 / 缺失 / 不适用

第 4 步:ADA/WCAG 无障碍审计

根据 WCAG 2.1 AA(最低标准)/ WCAG 2.2 AA(当前标准)进行评估:

POUR 原则
  • 可感知:所有非文本内容都有文本替代;音频/视频配有字幕/文字稿;内容不只依赖颜色区分;普通文本的最低对比度为 4.5:1
  • 可操作:所有功能均可通过键盘使用;不存在键盘陷阱;提供跳过导航链接;有充足的交互时间;不存在会引发癫痫的内容(闪烁频率不超过 3Hz)
  • 可理解:页面语言已在 HTML 中设置;错误消息描述清晰且有帮助;页面间导航保持一致;表单标签和说明清楚
  • 健壮性:HTML/ARIA 有效;兼容当前辅助技术;正确应用 ARIA 标签和角色
AI 界面专属要求(2025+)
  • 聊天机器人界面支持键盘操作并兼容屏幕阅读器
  • AI 生成的内容具有适当的语义结构
  • 为 AI 生成的图像提供替代文本
  • 语音界面提供视觉替代方案
无障碍严重程度分类
  • 严重:完全阻止残障用户访问(缺少键盘导航、不支持屏幕阅读器)
  • 高:显著妨碍使用(对比度差、关键图像缺少替代文本)
  • 中:造成使用障碍,但存在变通方法(缺少跳过链接、标签不一致)
  • 低:最佳实践方面的改进(装饰性图像使用了非空替代文本)
第 5 步:DPA 验证清单

如果正在审查数据处理协议:

必需的 DPA 要素(GDPR 第 28 条)
  • 明确标识各方(控制者名称/地址、处理者名称/地址)
  • 明确处理的标的、性质和目的
  • 指明个人数据类型和数据主体类别
  • 指明处理期限
  • 记录控制者的义务和权利
  • 处理者的义务:
    • 仅根据控制者的书面指示进行处理
    • 确保负责处理的人员承担保密义务
    • 实施适当的技术和组织安全措施
    • 子处理者规则:须事先取得书面同意;将义务传递给子处理者
    • 协助控制者处理 DSAR 及履行第 32 至 36 条规定的义务
    • 服务结束时删除或返还数据
    • 配合审计并提供相关信息
  • 指明国际传输机制(SCC、充分性决定等)
  • 违规通知流程:处理者须毫不延迟地通知控制者
  • DPA 更新触发条件:每年审查,或在处理活动发生重大变化时审查
DPA 质量标记
  • 不得使用含糊的处理描述(“按需处理数据”)——必须具体说明
  • 详细描述安全措施(加密、访问控制、员工培训)
  • 提供并维护子处理者名单
  • 针对高风险国家开展传输影响评估(TIA)
步骤 6:监管监测指南

提供有关如何持续保持合规的指南:

监测来源
监测频率
  • 每月:审查监管机构的执法行动
  • 每季度:检查是否有新的或修订的州隐私法律
  • 每年:与所有处理者全面审查 DPA;全面进行无障碍审计
  • 发生变更时:数据处理活动、供应商或界面发生重大变化时,重新评估
步骤 7:作出合规决定

输出以下三种决定之一:

{
  "decision": "PASS | CONDITIONAL | FAIL",
  "regulationsAssessed": ["GDPR", "CCPA", "WCAG 2.1 AA", "DPA"],
  "assessmentDate": "YYYY-MM-DD",
  "findings": [
    {
      "id": "RC-001",
      "regulation": "GDPR",
      "severity": "CRITICAL | HIGH | MEDIUM | LOW",
      "category": "Consent Management",
      "description": "Cookie consent banner missing for analytics tracking cookies",
      "status": "FAIL",
      "remediation": "Implement cookie consent platform with granular purpose-based opt-in",
      "owner": "developer",
      "deadline": "Before next deployment"
    }
  ],
  "requiredMitigations": [],
  "evidencePaths": [".claude/context/reports/compliance/"],
  "regulatoryLinks": [
    "https://edpb.europa.eu/our-work-tools/documents/public-consultations/2023/guidelines-032023-deceptive-design-patterns_en"
  ],
  "nextReviewDate": "YYYY-MM-DD",
  "recommendedNextStep": "Assign RC-001 to developer agent; re-assess after remediation"
}

决定规则:

  • PASS:所有适用的检查清单项目均已核实,没有未解决的问题
  • CONDITIONAL:存在轻微或中等问题;可在制定书面整改计划后继续
  • FAIL:存在严重或高风险问题;必须在部署前完成整改

输出协议

报告位置

将合规报告保存至:.claude/context/reports/compliance/

命名:{subject}-compliance-{YYYY-MM-DD}.md

报告章节(必需)
  1. 范围定义(步骤 1 的输出)
  2. GDPR/CCPA 检查清单结果(步骤 2)
  3. 隐私保护设计评估(步骤 3)
  4. 无障碍审计结果(如适用,步骤 4)
  5. DPA 验证(如适用,步骤 5)
  6. 结构化决策 JSON(步骤 7)
  7. 包含负责人和截止日期的整改任务清单
  8. 监管监测建议

反模式

反模式失败原因正确做法
只检查 GDPR,忽略 CCPA 和州法律遗漏多司法管辖区风险始终评估所有适用的司法管辖区
大多数项目通过时就报告 PASS部分合规仍属于不合规存在任何未解决的问题时,标记为 CONDITIONAL/FAIL
补救措施笼统地写成“实施加密”开发者无法依据模糊的指导采取行动具体说明:“对 users 表中的 PII 字段采用 AES-256 加密”
将一次性审计视为持续合规法规每季度都会变化建立持续监控的周期
将无障碍访问视为可有可无ADA 诉讼是当前活跃的法律风险公共界面必须符合 WCAG 2.1 AA
DPA 中的数据处理说明含糊不清监管机构会拒绝含糊不清的 DPA明确指定数据类型、处理目的和保留期限

执行钩子

执行前,根据 schemas/input.schema.json 验证输入。 输出契约定义于 schemas/output.schema.json。 执行前钩子:hooks/pre-execute.cjs 执行后钩子:hooks/post-execute.cjs(发出可观测性事件)

记忆协议

开始前:

cat .claude/context/memory/learnings.md

检查以下内容:

  • 对类似系统进行的先前合规评估
  • 已知的监管模式和记录在案的决策
  • issues.md 中尚未解决的合规阻碍

完成后:

  • 新的合规发现 → 追加到 .claude/context/memory/issues.md
  • 监管决策 → 追加到 .claude/context/memory/decisions.md
  • 成功的合规模式 → 追加到 .claude/context/memory/learnings.md

假设任务可能中断:你的上下文可能会重置。如果没有记录在记忆中,就等于没有发生。

评论

支持 Markdown