关于 data-inventory-mapping
此技能提供构建个人数据清单和数据流图的方法，面向隐私、合规及数据治理团队。它将系统发现、数据元素分类、法律依据映射与 GDPR 第 30 条处理记录衔接起来。
主要功能
- 01按阶段发现处理个人数据的系统
- 02提取并分类各系统的数据元素
- 03绘制组织内外的数据流
- 04映射处理目的与法律依据
- 05整合并持续维护数据清单
适用场景
- 01为 GDPR 第 30 条处理记录准备数据
- 02梳理系统间个人数据流转
- 03识别需要跨境传输保障的数据
- 04将数据分类关联到安全与保留控制
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/data-inventory-mapping确认已加载。
包含的文件
除 SKILL.md 外，安装时一起下载的参考资料和脚本。
assets/template.mdreferences/standards.mdworkflows.mdscripts/process.py详细介绍
数据清单与分类映射
概述
数据清单是隐私合规的基础文档，提供组织内所有个人数据处理活动的结构化目录。GDPR 第 30 条要求控制者维护处理活动记录（RoPA），其中包含特定字段，包括个人数据类别、处理目的、接收方类别以及向第三国传输的数据。本技能侧重于构建供 RoPA 使用的数据清单，重点包括逐系统发现、数据流映射、分类关联，以及为每类数据指定法律依据。
控制者必须提供的第 30 条内容 — 第 30 条第 1 款
| 必填字段 | 描述 | 与分类的关联 |
|---|---|---|
| (a) 控制者身份 | 控制者、共同控制者、代表、DPO 的名称和联系方式 | 行政信息——不依赖分类 |
| (b) 处理目的 | 每项处理活动的具体目的 | 目的决定适用的合法依据，并影响分类与处理方式之间的映射 |
| (c) 数据主体类别 | 数据被处理的个人类型（客户、员工、申请人） | 数据主体类别会影响适用的保护措施（例如，儿童、员工） |
| (d) 个人数据类别 | 每项活动所处理的个人数据类型 | 数据分类的直接结果——个人数据、特殊类别数据、犯罪相关数据 |
| (e) 接收方类别 | 数据接收方，包括处理者 | 决定传输和共享控制措施 |
| (f) 向第三国传输 | 国际传输及保障机制 | 触发第 V 章的合规要求 |
| (g) 保留期限 | 不同类别数据的预期删除时限 | 分类层级决定保留政策 |
| (h) 安全措施 | 第 32 条所述技术和组织措施的总体说明 | 分类层级决定安全控制级别 |
数据清单构建方法
阶段 1：系统发现（第 1–3 周）
步骤 1：企业应用清单
完整列出处理个人数据的系统：
| 发现方法 | 来源 | 输出 |
|---|---|---|
| IT 资产管理系统 | CMDB、ServiceNow、Lansweeper | 已登记的应用程序和服务器 |
| 采购记录 | 供应商合同、SaaS 订阅、许可证管理 | 处理数据的第三方系统 |
| 网络流量分析 | 防火墙日志、代理日志、DNS 查询 | 流向外部服务的未记录数据流 |
| 影子 IT 发现 | 云访问安全代理（CASB）日志、SaaS 工具费用报告 | 未经授权或未知的应用程序 |
| 部门访谈 | 业务部门负责人、数据管家 | 部门工具和本地数据库 |
Vanguard 金融服务——系统清单示例
| 系统 | 类型 | 部门 | 数据主体 | 分类优先级 |
|---|---|---|---|---|
| Salesforce CRM | SaaS | 销售、客户服务 | 客户、潜在客户 | Tier 1 |
| Workday HR | SaaS | 人力资源 | 员工、候选人 | Tier 1 |
| ADP GlobalView | SaaS | 薪资 | 员工 | Tier 1 |
| Oracle Data Warehouse | 本地部署 | 数据工程 | 所有数据主体 | Tier 1 |
| SharePoint Online | SaaS | 所有部门 | 所有数据主体 | Tier 1 |
| NICE Actimize | 本地部署 | 合规 | 客户、交易对手 | Tier 1 |
| HID Global Access | 本地部署 | 设施管理 | 员工、承包商 | Tier 2 |
| Cority Occ Health | SaaS | 职业健康 | 员工 | Tier 2 |
| Bloomberg Terminal | SaaS | 交易 | 交易对手 | Tier 2 |
| Microsoft Teams | SaaS | 所有部门 | 员工、外部联系人 | Tier 2 |
| Adobe Analytics | SaaS | 营销 | 网站访客 | Tier 2 |
| ServiceNow ITSM | SaaS | IT | 员工 | Tier 3 |
| Confluence Wiki | SaaS | 工程 | 员工 | Tier 3 |
阶段 2：数据元素映射（第 3-6 周）
针对每个系统，记录所有数据元素：
步骤 2：架构提取
- 结构化数据库：通过 SQL 元数据查询或数据目录 API 提取架构元数据（表名、列名、数据类型）
- SaaS 应用程序：使用 API 文档列举数据对象和字段
- 非结构化存储库：编制文档类型及其通常包含的个人数据内容目录
- 自动化发现：部署扫描工具，在所有存储库中识别 PII（参见
auto-data-discoveryskill）
步骤 3：数据元素分类
针对每个数据元素，指定：
- 个人数据分类：PERSONAL_DIRECT、PERSONAL_INDIRECT、SPECIAL_CATEGORY、CRIMINAL_ART10、PSEUDONYMISED、ANONYMISED、NON_PERSONAL（参见
personal-data-testskill） - 分类层级：公开、内部、机密、受限（参见
classification-policyskill） - 第 6 条合法依据：针对每项既定目的处理此元素的法律依据
- 第 9(2) 条条件：若属于特殊类别，则注明具体处理条件
阶段 3：数据流映射（第 6-9 周）
步骤 4：系统内部数据流
记录数据在组织内部的流转方式：
Customer Onboarding Data Flow — Vanguard Financial Services
Customer ──[web form]──► Salesforce CRM
│
┌─────────┼──────────┐
▼ ▼ ▼
Oracle DW SharePoint Email (welcome)
(analytics) (documents) (notifications)
│
▼
Adobe Analytics
(web behaviour)
步骤 5：外部数据流（与第三方共享）
记录与外部各方共享的所有数据：
| 发送方系统 | 接收方 | 数据类别 | 传输机制 | 法律保障 |
|---|---|---|---|---|
| Salesforce CRM | Salesforce Inc.（处理者） | 客户个人数据 | SaaS 托管 | 标准合同条款 (2021/914) |
| Workday HR | Workday Inc.（处理者） | 员工个人数据 + 特殊类别数据 | SaaS 托管 | 欧盟-美国数据隐私框架 |
| ADP Payroll | HMRC（法定接收方） | 员工财务数据 | 安全文件传输 | 法律义务，第 6(1)(c) 条 |
| NICE Actimize | NCA（法定接收方） | 客户 AML 数据（第 10 条） | SAR Online 门户 | 法律义务，POCA 2002 |
| Oracle DW | Deloitte（审计方） | 匿名化财务数据 | 加密文件传输 | 共同控制者协议 |
阶段 4：法律依据与目的映射（第 9-11 周）
步骤 6：目的与法律依据矩阵
针对每项处理活动，将数据类别映射到处理目的和法律依据：
| 处理活动 | 数据类别 | 目的 | 第 6 条依据 | 第 9(2) 条 / 第 10 条 |
|---|---|---|---|---|
| 客户账户管理 | 姓名、电子邮件、地址、账户号码 | 履行合同 | 第 6(1)(b) 条 | 不适用 |
| KYC 身份验证 | 姓名、出生日期、身份证件、地址 | 法定义务（MLR 2017） | 第 6(1)(c) 条 | 不适用 |
| 员工薪资管理 | 姓名、NINO、银行账户信息、薪资 | 履行合同 | 第 6(1)(b) 条 | 不适用 |
| 员工多样性监测 | 种族、性取向 | 平等监测 | 第 6(1)(a) 条 / 第 6(1)(c) 条 | 第 9(2)(a) 条 / 第 9(2)(b) 条 |
| 建筑物门禁控制 | 指纹模板 | 实体安全 | 第 6(1)(f) 条 | 第 9(2)(a) 条 |
| AML 监测 | 交易模式、SAR 数据 | 法定义务（POCA 2002） | 第 6(1)(c) 条 | 第 10 条 — DPA 附表 1 第 2 部分第 10 段 |
| 网站分析 | IP 地址、Cookie、浏览记录 | 合法利益 | 第 6(1)(f) 条 | 不适用 |
| 营销通信 | 电子邮件、偏好设置 | 同意 | 第 6(1)(a) 条 | 不适用 |
阶段 5：文档编制与维护（持续进行）
步骤 7：整合清单
将所有发现整合到正式数据清单中：
- 每个系统中的每个数据元素对应一条记录
- 与 RoPA 中的处理活动交叉引用
- 为每个元素应用分类标签
- 按分类层级设置审查日期
步骤 8：持续维护
| 维护活动 | 频率 | 负责人 |
|---|---|---|
| 自动发现扫描结果核对 | 每月 | 隐私工程 |
| 新系统上线清单编制 | 每次部署新系统时 | 系统负责人 + 隐私分析师 |
| 部门数据管理员审查 | 每季度 | 数据管理员 |
| 全面清单准确性审计 | 每年 | DPO |
| 分类重新评估审查 | 每年（临界情况：每 6 个月） | 隐私分析师 |
数据流图标准
符号约定（基于 DFD 第 0/1 级）
| 符号 | 含义 |
|---|---|
| 矩形 | 外部实体（数据主体、第三方、监管机构） |
| 圆角矩形 | 处理过程（系统或应用程序） |
| 开口矩形（两条平行线） | 数据存储（数据库、文件共享） |
| 箭头 | 数据流（标注数据类别） |
| 虚线箭头 | 可选或有条件的数据流 |
| 红色边框 | 包含特殊类别数据或犯罪数据 |
| 蓝色边框 | 国际传输 |
执法先例
- Österreichische Datenschutzbehörde（奥地利 DPA）诉 Local Bakery Chain（2020）：因未维护第 30 条记录而被罚款 4,000 欧元。DPA 指出，即使是小型组织也必须维护处理记录。
- CNIL 诉 Sergic（2019）：被罚款 400,000 欧元，部分原因是数据映射不充分——控制者无法证明其知道个人数据存储在哪里，导致数据泄露未能及时发现。
- ICO 诉 British Airways（2020）：被罚款 2,000 万英镑；数据映射不充分导致数据泄露检测延迟——控制者无法掌握个人数据在其 Web 基础设施中的流动情况。
集成点
- auto-data-discovery：自动扫描将数据元素送入清单
- personal-data-test：对清单中的每个数据元素应用分类决定
- special-category-data：标记第 9 条数据，并映射至处理条件
- criminal-data-handling：识别第 10 条数据，并映射至国内法律授权
- data-lineage-tracking：沿袭图通过动态流转信息扩展静态清单
评论
支持 Markdown