4. 数据合规评审实战

数据合规评审是金融科技产品上线前最容易被低估、却最容易触发监管处罚的一环。与功能合规、营销合规不同，数据合规的评审对象不是"产品说了什么"，而是"产品在后台对数据做了什么"——采集了哪些字段、存在哪里、谁能访问、流向何处、留存多久。本节围绕个人信息保护、数据分类分级、授权同意与跨境传输四条主线，给出一套可落地的评审方法。

一、先建立数据资产台账，再谈合规判断

评审的第一步不是看隐私政策，而是让产品与研发团队交出一份数据资产台账。台账的最小字段应包括：数据项名称、所属业务功能、采集方式（用户输入/系统生成/第三方接口）、存储位置（库表或对象存储路径）、是否属于个人信息、是否属于敏感个人信息、对外提供方、留存期限。没有台账，后续的分类分级和授权核对都无从谈起。

实践中常见的坑是"字段名与业务含义脱节"。例如某信贷产品数据库中有一个字段叫 ext_info，研发认为只是扩展信息，实际内容却是用户通讯录的哈希值。因此台账必须由产品经理与研发共同确认，评审人员抽查 3～5 个高风险字段做反向验证。

二、数据分类分级：把"敏感"落到字段级

分类分级不是给整个系统贴一个标签，而是落到字段级。金融科技场景下，可参考如下分级口径（示例，需结合机构自身制度调整）：

分级完成后要检查三件事：L3 及以上字段是否加密存储（推荐 AES-256 或国密 SM4）；是否在展示层做了脱敏（如身份证保留前 1 后 1、银行卡保留后 4 位）；是否设置了独立的访问审批与操作日志。若某 L3 字段在日志中明文打印，应直接判定为高风险问题。

三、授权同意：从"勾选一次"到"分场景可追溯"

《个人信息保护法》要求处理敏感个人信息取得单独同意，向第三方提供需单独告知并取得同意。评审时要核对同意链路是否与数据流一致。常见缺陷是：隐私政策里写了"可能向合作方提供信息"，但实际接口把用户手机号传给了三家外部机构，且没有独立的同意记录。

可执行的核对方法是画一张"同意—数据流对照表"：左侧列出每个采集/对外提供动作，右侧列出对应的同意文案、同意时间戳、同意版本号。评审时随机抽取 10 条真实用户记录，验证同意记录能否覆盖全部数据流。若存在"先传数据、后补同意"或"一次概括同意覆盖全部场景"，均需整改。

四、跨境传输评估：先判断路径，再判断条件

跨境传输评审的核心是回答三个问题：数据是否真的出境？出境路径是什么？该路径下是否满足合规条件？常见路径包括：向境外总部/关联公司传输、使用境外云服务、调用境外 API、境外人员远程访问境内数据。其中"境外人员远程访问"最容易被忽略，但同样构成出境。

以下是一段可用于评审记录的判断逻辑示例（伪代码，仅表达判断顺序）：

if 数据接收方位于境外 or 数据存储于境外节点:
    if 属于重要数据 or 达到规定数量的个人信息:
        必须申报安全评估
    elif 属于敏感个人信息 or 达到规定数量的个人信息:
        需订立标准合同并备案，或通过认证
    else:
        仍需完成个人信息保护影响评估(PIA)并留存记录
else:
    按境内数据处理规则评审

评审时要特别核对：是否已完成个人信息保护影响评估并留存至少三年；标准合同是否与境外接收方实际签署并备案；境外接收方的数据再转移是否被限制。若产品使用境外 SaaS 做客服工单，工单中含用户手机号，则属于个人信息出境，不能以"只是工具"为由跳过评估。

五、评审结论如何写才可执行

数据合规评审的结论不应停留在"基本合规"，而应落到可整改的条目。建议每条问题包含：问题描述、涉及字段或接口、风险等级、整改建议、责任方、复评方式。例如："用户通讯录哈希值 ext_info 未在隐私政策中披露，且未取得单独同意，风险等级高；建议下线该字段采集或补充单独同意与披露；责任方为客户端研发；复评方式为抓包验证接口不再上传该字段。"

把上述四条主线串起来，数据合规评审就从"看文档"变成了"验链路"：台账确认数据在哪，分级确认保护强度，同意确认处理合法性，出境评估确认跨域风险可控。任何一条链路断裂，都应在产品上线前完成整改或明确风险接受决策。