App Compliance Review

---
name: app-compliance-review
version: 1.0.0
description: 中国APP个人信息保护合规检查技能。面向公司法务、数据合规律师或合规顾问，对移动应用程序（APP）开展完整的个人信息保护合规评审，可直接面向业务部门交付合规审查报告与整改清单。采用"合规事实查明 + 声明一致性核验"两阶段审查方法论，覆盖11大合规模块53检查项，法规依据通过运行时检测的MCP后端（北大法宝/华宇元典）实时核验。触发关键词：APP合规检查、个人信息保护合规、隐私政策审查、APP合规评审、数据合规审查、移动应用合规、SDK合规、权限合规、个人信息保护法合规、APP隐私合规检测、APP整改。
agent_created: true
---

# APP个人信息保护合规检查技能

> **面向公司法务、数据合规律师或合规顾问的APP个人信息保护合规评审工具包。** 采用"合规事实查明 + 声明一致性核验"两阶段审查方法论，覆盖11大合规模块53检查项，法规依据通过运行时检测的MCP后端实时核验。从"业务部门提交的APP材料"到"可直接交付的合规审查报告与整改清单"，一个包闭环完成。

## 概述

本技能为中国移动应用（APP）个人信息保护合规评审提供系统化、结构化的检查框架。以《个人信息保护法》《网络安全法》《数据安全法》为核心依据，结合监管执法实践与行业合规标准，建立覆盖APP个人信息处理全生命周期的合规检查体系。

所有法律法规依据均经法规核验MCP后端核验，确保法规名称、文号、条款编号及现行有效性准确。详见 `references/law-library.md`（含24部法律法规、国家标准及团体标准）。

## MCP法规核验后端（能力槽设计）

本技能的法规核验功能**不绑定任何特定MCP产品**。skill运行至阶段四（法规核验）时，自动扫描用户本地已连接的MCP连接器，按以下逻辑选择后端：

**运行时检测逻辑：**

1. 扫描已连接的MCP连接器，检测以下后端是否可用：

| 后端 | 检测方式 | 工具前缀 |
|------|----------|----------|
| 北大法宝（pkulaw） | 检测 `mcp__pkulaw__` 前缀工具是否可用 | `mcp__pkulaw__mcp-law/` |
| 华宇元典（yuandian） | 检测 `yuandian_` 前缀工具是否可用 | `yuandian_rh_fg_search` 等 |

2. 根据检测结果选择后端：
   - **0个可用** → 报告中标注"⚠️ 未检测到法规核验MCP后端，法规依据未能实时核验，建议人工确认"，跳过MCP核验步骤
   - **1个可用** → 自动使用该后端
   - **2个均可用** → **询问用户选择**使用哪一个后端进行本次核验

3. 询问用户时提供以下信息辅助决策：

| 后端 | 优势 |
|------|------|
| 北大法宝 | WorkBuddy内置，零额外配置，返回TimelinessDic字段直接判断时效性 |
| 华宇元典 | 额外支持法律幻觉校验接口，可批量校验报告中法律引用准确性 |

**后端确定后，按对应工具映射执行核验：**

| 核验动作 | 北大法宝 | 华宇元典 |
|----------|----------|----------|
| 核验法规现行状态 | `mcp__pkulaw__mcp-law/get_law_list(title=...)` | `yuandian_rh_fg_search(keyword=...)` |
| 核验条款内容 | `mcp__pkulaw__mcp-law-search-service/get_article(...)` | `yuandian_rh_ft_detail(...)` |
| 检索替代条款 | `mcp__pkulaw__mcp-law-search-service/search_article(...)` | `yuandian_law_vector_search(...)` |

华宇元典MCP配置方式（如用户尚未配置）：
```json
{
  "yuandian-law": {
    "type": "http",
    "url": "https://open.chineselaw.com/mcp/law/stream",
    "headers": {
      "Accept": "application/json, text/event-stream",
      "Authorization": "Bearer YOUR_YUANDIAN_API_KEY"
    }
  }
}
```

## 适用场景

- **APP上线前合规评审**：新APP或大版本更新上线前，全面排查个人信息保护合规风险
- **版本迭代合规自查**：小版本迭代中涉及个人信息收集行为变化时，增量审查变更部分
- **监管通报整改定位**：收到工信部通报、应用商店下架通知后，定位违规项并生成整改清单
- **并购尽调数据合规审查**：投资并购场景下，对标的APP进行数据合规尽职调查
- **SDK接入评估**：新增第三方SDK前评估其个人信息处理行为是否符合合规要求

## 审查边界（重要）

本技能的审查范围严格限定在**法务/律师通过业务部门提供的APP材料即可自闭环完成**的检查项。以下事项不纳入本技能，因为它们需要额外上下文或属于不同阶段的工作：

| 不纳入事项 | 原因 | 应在何时处理 |
|------------|------|-------------|
| 数据泄露应急响应预案 | 需要企业安全运营制度文档，非APP审查材料可覆盖 | 监管检查应对或专项安全审计 |
| 数据全生命周期管理制度 | 属企业内部数据安全管理体系，非APP层面审查 | 企业数据合规体系建设 |
| 个人信息保护影响评估（PIA） | 属产品设计阶段专项评估，需独立开展 | 产品立项或重大功能变更时 |
| 数据分类分级管理制度 | 属企业数据治理体系，非APP审查范畴 | 企业数据治理体系建设 |
| 网络安全等级保护测评 | 属网络安全合规专项，需持证机构测评 | 按等保2.0要求定期开展 |
| 合规审计（个保法§54） | 属定期审计制度，非上线前审查 | 按法定周期开展 |

如审查中发现上述事项的缺口，在报告中以**提示性建议**方式指出，但不作为合规判定项。

## 两阶段审查方法论

对APP的合规审查分为两大阶段：先**查明合规事实**，再**核验声明与事实的一致性**。大多数合规风险恰恰隐藏在"声明"与"事实"的偏差中，因此第二阶段是审查的核心。

### 阶段一：合规事实查明

从文本取证与技术取证两个维度采集合规事实：

| 取证维度 | 审查对象 | 方法 |
|----------|----------|------|
| **文本取证** | 隐私政策、用户协议、权限弹窗文案、第三方共享说明、双清单 | 逐条文本审查，对照法规要求与检查清单 |
| **技术取证** | APK安装包内的AndroidManifest.xml、权限声明、SDK包名、内嵌隐私政策文本/链接、资源文件 | 解包APK提取技术事实，使用 `scripts/apk_analyzer.py` 自动化分析 |

### 阶段二：声明一致性核验

将文本声明与技术事实、客户材料与安装包实际内容逐项比对，定位不一致之处（如隐私政策披露A/B/C三个SDK，安装包实际还有D；或隐私政策未声明某权限，APK却实际申请）。

技术取证获取的是"声明了什么、内嵌了什么、疑似接入了什么"，不等同于运行时实际调用行为。运行时真实行为需动态测试进一步确认，在报告中应明确标注静态取证与动态验证的边界。

## 输入材料要求

输入材料的完整性直接决定审查深度。启动审查前，须向业务部门发送 `assets/input-materials-template.md` 收集以下材料：

### 必需材料（缺一不可）

1. **APP安装包**（APK文件；iOS为IPA，但本技能以Android APK静态分析为主）
2. **最新版隐私政策**（完整文本，含第三方SDK清单）
3. **用户协议/服务协议**
4. **SDK清单**（含SDK名称、所属公司、功能、收集的个人信息类型、收集目的、使用场景）
5. **权限使用清单**（含权限名称、使用场景、目的说明）
6. **业务功能清单**（基本功能与附加功能划分）
7. **已收集个人信息清单**（双清单之一）
8. **与第三方共享个人信息清单**（双清单之一）

### 可选材料（影响审查完整度，如不适用可跳过）

收到材料后，逐项确认是否适用。某些材料在特定场景下可能不需要，审查人员须根据APP实际情况自行判断：

9. 个性化推荐/算法推送设置说明（如APP无个性化推荐功能则不需要）
10. 账号注销流程说明（如APP无账号体系则不需要）
11. 投诉举报渠道说明（如已在隐私政策中完整说明则可不需要）
12. 适老化改造说明（如APP不属于适老化改造重点APP范围则不需要）
13. 儿童个人信息保护规则（如APP不涉及未成年人业务则不需要）
14. 数据出境情况说明（如APP不存在跨境传输则不需要）
15. 自动续费/会员订阅机制说明（如APP无自动续费功能则不需要）

> **提示**：如某项可选材料不适用，在材料收集清单中标注"不适用"并说明原因即可，不影响审查启动。如某项材料适用但业务部门未能提供，在报告中将对应检查项标注为"材料缺失，未能完成审查"。

收到材料后，运行 `scripts/material_validator.py` 校验材料完整性，生成缺失项清单并提示业务部门补充。

```bash
# 校验材料完整性，输出缺失项清单与完整度评分
python scripts/material_validator.py --materials-dir /path/to/materials/
```

## 工作流程

### 阶段一：材料收集与校验（Day 1）

1. 向业务部门发送 `assets/input-materials-template.md` 材料收集清单
2. 收到材料后运行 `scripts/material_validator.py` 校验完整性
3. 列出缺失材料，要求业务部门在约定时限内补充

### 阶段二：技术核验（Day 2-3）

4. 运行 `scripts/apk_analyzer.py` 对APK安装包进行静态分析，提取：
   - AndroidManifest.xml中声明的全部权限
   - 安装包内识别的第三方SDK（基于包名特征库匹配）
   - 内嵌的隐私政策文本或链接
   - 应用基本信息（包名、版本号、targetSdkVersion等）
5. 将技术取证结果保存为结构化JSON，供后续一致性核验使用

```bash
# APK静态分析：提取权限、识别SDK、搜索内嵌隐私政策
# 脚本启动时会自动打印能力边界告知，并检测是否安装了增强工具
python scripts/apk_analyzer.py --apk /path/to/app.apk --output apk_report.json --format summary
```

> **能力边界**：APK分析脚本基于Python标准库零依赖运行，采用正则匹配+字节搜索方式。已知局限：权限提取可能遗漏非标格式、SDK识别仅覆盖未混淆的主流包名、包名版本号可能不准确。脚本启动时自动检测androguard/aapt2/apktool/jadx是否安装，如已安装则提示审查人员可用其交叉验证。

详细APK分析方法见 `references/apk-analysis-guide.md`。

### 阶段三：合规事实查明与声明一致性核验（Day 4-7）

6. 对照 `references/checklist-full.md` 中的11大模块检查项，先完成文本取证（审查文本材料）
7. 将隐私政策声明的SDK、权限、个人信息类型与APK技术取证结果逐项比对（一致性核验）
8. 将客户提供的SDK清单与APK识别的SDK逐项比对（一致性核验）
9. 将权限使用清单与AndroidManifest.xml声明的权限逐项比对（一致性核验）
10. 记录每项检查的事实发现、合规判定、风险等级

### 阶段四：法规依据实时核验（Day 7）—— MCP条文锚定

数据合规领域法律法规更新频繁（如《网络安全法》2025年10月已修正），skill必须在每次运行时核验所依据法规的现行有效性，避免引用已失效或已修订的条款。

**核验机制**：通过 `references/article-anchors.md` 条文锚定表，将每个检查项与具体法规条款建立程序化映射（共72个锚点）。每次运行时，先扫描已连接的MCP后端（见上方"MCP法规核验后端"能力槽设计），确定本次使用的后端后，按对应工具映射逐锚点核验。

**核验流程**：

1. 扫描已连接MCP连接器，检测pkulaw/yuandian可用性（0个→跳过并警告；1个→自动使用；2个→询问用户选择）
2. 加载 `references/article-anchors.md`，获取全部锚点清单
3. 对每个锚点，按核验频率策略执行：
   - `every_run` 类锚点（个保法、网安法、数据安全法、认定方法，共42个）：每次运行必核验
   - `quarterly` 类锚点（必要范围规定、移动互联网应用程序信息服务管理规定、164号文、524行动通知、26号文、算法推荐规定、广告管理办法、未成年人保护法、未成年人网络保护条例，共23个）：如距上次核验超90天则核验
   - `annual` 类锚点（GB/T国家标准，共7个）：标注"需手动核验"，因法规MCP后端通常不收录国家标准
4. 根据活跃后端调用对应MCP工具核验：

**后端为pkulaw（北大法宝）时：**

```python
# 核验法规现行状态（检查TimelinessDic字段是否为"现行有效"）
mcp__pkulaw__mcp-law/get_law_list(title="个人信息保护法")

# 核验具体条款内容
mcp__pkulaw__mcp-law-search-service/get_article(title="中华人民共和国个人信息保护法", number="十七")

# 法规已修订时检索替代条款
mcp__pkulaw__mcp-law-search-service/search_article(text="敏感个人信息单独同意")
```

**后端为yuandian（华宇元典）时：**

```python
# 核验法规现行状态（检查返回结果中的时效性字段）
yuandian_rh_fg_search(keyword="个人信息保护法")

# 核验具体条款内容
yuandian_rh_ft_detail(law_title="中华人民共和国个人信息保护法", article_no="十七")

# 法规已修订时检索替代条款
yuandian_law_vector_search(query="敏感个人信息单独同意")
```
   - **核验法规现行状态**：按活跃后端调用对应工具
     - pkulaw: `mcp__pkulaw__mcp-law/get_law_list(title=<law_search_key>)`，检查 `TimelinessDic` 字段
     - yuandian: `yuandian_rh_fg_search(keyword=<law_search_key>)`，检查返回结果中的时效性字段
     - 如显示"废止或失效"，标记该锚点为失效，暂停引用
     - 如存在多个版本，确认引用最新版本（如移动互联网应用程序信息服务管理规定须用2022修订版而非2016原版）
   - **核验条款内容**：按活跃后端调用对应工具
     - pkulaw: `mcp__pkulaw__mcp-law-search-service/get_article(title=<law_title>, number=<law_article_no>)`
     - yuandian: `yuandian_rh_ft_detail(law_title=<law_title>, article_no=<law_article_no>)`
     - 确认条款内容与skill引用的一致
   - **检索替代条款**（如法规已修订）：按活跃后端调用对应工具
     - pkulaw: `mcp__pkulaw__mcp-law-search-service/search_article(text=<关键词>)`
     - yuandian: `yuandian_law_vector_search(query=<关键词>)`
4. 将核验结果记入运行日志（JSON格式，含每个锚点的状态、核验时间、备注）
5. 对失效或已修订的依据，在报告中标注警告并调整引用条款

**核验结果处理规则**：
- 法规已废止 → 报告标注"⚠️ 原依据法规已废止，建议核实替代法规"
- 法规已修订 → 检索新条款，更新引用，报告标注"本报告已采用最新修订版条款"
- 法规MCP后端无法返回 → 报告标注"⚠️ 法规状态未能通过MCP核验，建议人工确认"
- 国家标准（GB/T系列）→ 报告标注"需通过全国标准信息公共服务平台人工核验"

11. 对每项不合规发现，引用 `references/law-library.md` 中的具体法规条款，并附条文锚点编号（如 [A014]）
12. 条文锚定表的核验结果作为报告附件，证明依据的现行有效性

### 阶段五：报告生成与交付（Day 8-10）

13. 运行 `scripts/report_generator.py` 或基于 `assets/compliance-report-template.md` 生成合规评审报告

```bash
# 方式一：交互式输入检查结果，生成Markdown报告
python scripts/report_generator.py --interactive --output compliance_report.md

# 方式二：从JSON文件读取检查结果，附带APK分析报告
python scripts/report_generator.py --input check_results.json --apk-analysis apk_report.json --output compliance_report.md
```

14. 生成 `assets/remediation-template.md` 整改清单，按优先级排序
15. 向业务部门交付：合规评审报告 + 整改清单 + 法规依据索引

## 11大合规检查模块

| 模块 | 检查重点 | 核心法规依据 |
|------|----------|-------------|
| M1 隐私政策合规 | 政策完整性、首次运行提示、易于访问阅读、双清单 | 个保法§7、§17；认定方法§1-2；524行动通知；26号文 |
| M2 知情同意 | 同意前不收集、拒绝后不频繁索要、不超授权、撤回途径 | 个保法§13-16、§22；认定方法§3；26号文 |
| M3 最小必要 | 与业务功能相关、可拒绝非必要、不强制捆绑、频率合理 | 个保法§6、§19；必要范围规定；认定方法§4；GB/T 41391-2022；T/TAF 077系列 |
| M4 权限管理 | 权限声明完整、申请同步告知、调用场景对应、拒绝机制 | 个保法§13-16；认定方法§3-4；164号文；26号文；T/TAF 078.4 |
| M5 SDK与第三方 | SDK清单完整、声明规范、第三方应用接入、自启动 | 个保法§23；认定方法§5；164号文；26号文；T/TAF 078.10 |
| M6 敏感个人信息 | 敏感信息识别、单独同意、必要性、安全措施、实名认证合规 | 个保法§28-32；GB/T 35273-2020；认定方法§3-4；网安法§24 |
| M7 用户权利 | 注销账号、更正删除、撤回同意、投诉举报、便捷卸载 | 个保法§44-50；认定方法§6；164号文；26号文 |
| M8 广告合规 | 广告标识、弹出、关闭、分发、未成年人广告、不误导 | 互联网广告管理办法§9-10、§14；广告法§14、§43-44；164号文；26号文；T/TAF 078.7 |
| M9 数据安全（展示与传输层） | 去标识化展示、加密传输、明文传输检查 | 个保法§51；网安法§21、§42；数安法§27 |
| M10 特殊场景 | 儿童、适老化、数据出境、个性化推荐（含禁止差别待遇）、自动续费 | 个保法§31、§36、§38-40；未保法；适老化通知；算法推荐管理规定§10、§15、§17、§24；T/TAF 078.2 |
| M11 分发平台信息明示 | APP在分发平台的信息明示、分发行为规范（仅适用于具有分发功能的APP）、备案号展示 | 移动互联网应用程序信息服务管理规定(2022)；164号文；26号文；APP备案工作通知 |

每个模块的完整检查项（含检测标准、违规情形、合规建议、法规条款）见 `references/checklist-full.md`（11大模块，53检查项）。

## 输出交付物

### 1. 合规评审报告

基于 `assets/compliance-report-template.md` 生成，包含：
- **执行摘要**：APP基本信息、审查范围、总体合规率、重大风险项概述
- **合规总览表**：11大模块的合规状态（✅合规 / ⚠️需关注 / ❌不合规 / —不适用），四色标注
- **逐项检查结果**：每项含检查项编号、检查内容、法规依据、事实发现、风险等级（高/中/低）、整改建议
- **一致性核验发现**：文本声明与技术事实不一致的清单
- **法规依据索引**：本报告引用的全部法律法规条款汇总

### 2. 整改清单

基于 `assets/remediation-template.md` 生成，按优先级排序：
- **P0 紧急**（上线前必须修复）：违反法律强制性规定、存在下架风险
- **P1 高优**（限期修复）：监管通报高频问题、用户权益影响较大
- **P2 中优**（版本迭代修复）：规范性瑕疵、完善性要求
- **P3 低优**（长期优化）：最佳实践建议

## 法规依据核验方法

本技能引用的法律法规均通过用户配置的MCP后端核验。核验方法：

1. 法规名称与文号以 `references/law-library.md` 为准
2. 读取 `assets/mcp-backends.yaml` 确认活跃后端（pkulaw或yuandian）
3. 如需确认法规是否被修改或废止，按活跃后端调用对应工具检索
4. 对于国家标准（GB/T系列），法规MCP后端可能未收录，通过官方渠道确认现行版本

**重要提示**：法规持续更新，使用本技能前应确认以下关键法规为最新版本：
- 《网络安全法》2025年10月修正，2026年1月1日施行
- 《移动互联网应用程序信息服务管理规定》使用2022修订版

## 资源说明

### references/（审查时按需加载）

| 文件 | 内容 | 加载时机 |
|------|------|----------|
| `law-library.md` | 经MCP后端核验的法规依据库（法规名称、文号、条款摘要、现行状态） | 引用法规依据时 |
| `article-anchors.md` | 条文锚定表（72个锚点，检查项与法规条款的程序化映射，支持双后端MCP核验） | 每次运行阶段四法规核验时 |
| `checklist-full.md` | 11大模块完整检查清单（检测标准、违规情形、合规建议） | 逐项审查时 |
| `input-materials-guide.md` | 输入材料详细格式要求与采集指引 | 材料收集阶段 |
| `apk-analysis-guide.md` | APK静态分析方法、工具使用、结果解读 | 技术核验阶段 |

### scripts/（可执行脚本）

| 脚本 | 功能 |
|------|------|
| `apk_analyzer.py` | APK解包与静态分析：提取权限、识别SDK、提取内嵌隐私政策 |
| `material_validator.py` | 输入材料完整性校验：检查必需材料是否齐备 |
| `report_generator.py` | 合规检查报告生成：汇总检查结果输出Markdown报告 |

### assets/（输出模板）

| 文件 | 用途 |
|------|------|
| `input-materials-template.md` | 发送给业务部门的材料收集清单模板 |
| `compliance-report-template.md` | 合规评审报告输出模板 |
| `remediation-template.md` | 整改清单输出模板 |

## 使用限制

- 本技能提供合规自查辅助，不构成正式法律意见
- APK静态分析不等同于运行时行为验证，动态行为需动态测试确认
- 涉及重大合规决策或监管调查，须咨询专业律师
- 法规持续更新，使用前应核验法规最新状态
- iOS（IPA）分析能力有限，本技能以Android APK分析为主

## Tips

- 各检查项的实操要点已内嵌于 `references/checklist-full.md` 对应检查项的"实操要点"标注中，审查时随规则一起呈现，不会遗漏
- 《认定方法》总共只有6条，分别对应6大类违规行为，引用时切勿编造不存在的条款编号（如§7-§11均不存在）
- 静态取证获取的是"声明了什么、内嵌了什么、疑似接入了什么"，不等同于运行时实际调用行为——报告中凡涉及运行时行为的结论须标注"需动态测试确认"
- 法规依据引用时须附条文锚点编号（如[A014]），便于MCP核验时追溯