2. 法律合规基线
个人信息保护治理工程的第一项基础工作，不是买工具、也不是写制度，而是把“法律要求”翻译成“工程可执行的控制项”。这一节要解决三个问题：三部法律各自管什么、违反后承担什么责任、以及如何把法条映射到具体系统与流程上。
一、三部法律的分工与核心义务
《网络安全法》《数据安全法》《个人信息保护法》并非并列替代关系，而是层层递进的三条基线。理解它们的分工，是避免合规工作重复或遗漏的前提。
《网络安全法》管的是“网络运行安全”，核心义务包括：网络运营者按等级保护制度履行安全保护义务（等保2.0）、落实实名制、留存网络日志不少于六个月、制定网络安全事件应急预案、发生事件时立即启动预案并向主管部门报告。它关注的是系统本身能不能安全运行。
《数据安全法》管的是“数据处理活动的安全”，核心义务包括：建立数据分类分级保护制度、对重要数据实行更严格管理、开展数据安全风险评估、数据处理者应建立全流程数据安全管理制度、发生数据安全事件立即处置并告知用户与主管部门。它关注的是数据从采集到销毁的全生命周期安全，不区分是否属于个人信息。
《个人信息保护法》管的是“个人信息处理行为的合法性”，核心义务包括：处理个人信息须有合法性基础（同意、合同必需、法定义务等）、告知同意规则、最小必要原则、个人权利响应（查阅、复制、更正、删除、可携带）、委托处理与对外提供的合同约束、跨境传输的单独同意与安全评估、处理敏感个人信息需单独同意并做个人信息保护影响评估（PIA）。它关注的是“处理个人信息的每一个动作是否合法”。
二、法律责任：违规的代价结构
三部法律的责任形式可以归纳为四类：责令改正、警告、罚款、停业整顿/吊销执照，情节严重的还可能追究直接责任人的个人责任。
以《个人信息保护法》为例，违法处理个人信息且情节严重的，可处五千万元以下或者上一年度营业额百分之五以下罚款，并可以责令暂停相关业务、停业整顿、吊销相关业务许可或营业执照；对直接负责的主管人员和其他直接责任人员处十万元以上一百万元以下罚款。这个“营业额百分之五”的封顶，意味着大型平台的合规风险敞口可能达到数十亿元级别。
《数据安全法》对未履行数据安全保护义务的，可处五万元以上五十万元以下罚款；情节严重的，处五十万元以上二百万元以下罚款，并可责令停业整顿、吊销执照。《网络安全法》对未履行等保义务的，可处一万元以上十万元以下罚款，情节严重的处十万元以上一百万元以下罚款。
除行政责任外，还有民事赔偿（个人可提起侵权之诉）和刑事责任（侵犯公民个人信息罪、拒不履行信息网络安全管理义务罪）。合规基线不是“最好做到”，而是“做不到就有明确法律后果”。
三、配套标准：把法律变成可操作的控制项
法律条文是原则性的，落地需要标准支撑。最常用的配套标准包括：
- GB/T 35273《个人信息安全规范》：给出个人信息收集、存储、使用、共享、转让、公开披露、删除等环节的具体操作要求，是PIA和合规审计的主要参照。
- GB/T 22239《网络安全等级保护基本要求》：等保2.0的核心标准，规定不同等级系统应满足的安全控制项。
- GB/T 41479《网络数据处理安全要求》：针对数据处理活动的安全要求，与数安法配套。
- GB/T 39335《个人信息安全影响评估指南》：规定PIA的评估流程、评估要点和报告结构。
这些标准的作用是把“应当采取必要措施”这类模糊表述，拆解成“是否加密存储身份证号”“是否在收集前展示隐私政策并取得勾选同意”“是否对敏感个人信息单独弹窗告知”等可检查项。
四、合规映射方法：从法条到控制项
合规映射的本质是建立一条可追溯的链路：法律条款 → 标准控制项 → 系统/流程控制点 → 证据。具体做法分四步：
- 拆条：把每部法律中与自身业务相关的义务条款逐条列出，标注条款号与义务类型（告知、同意、评估、报告、留存等）。
- 对标：为每条义务找到对应标准中的控制项，例如“处理敏感个人信息需单独同意”对应GB/T 35273中“敏感个人信息收集需明示目的并取得明示同意”。
- 落点：把控制项落到具体系统或流程上，例如“单独同意”落到App的弹窗组件、后端同意记录表、日志留存策略。
- 留证：为每个控制点定义可验证的证据，例如隐私政策版本快照、同意记录数据库字段、PIA报告、日志保留时长配置截图。
映射完成后，应形成一张“合规映射表”，至少包含：法律条款号、义务描述、对应标准控制项、责任部门、系统/流程落点、证据形式、当前状态。这张表既是合规检查的依据，也是后续审计和整改的基线。
五、一个可执行的映射示例
假设某电商App要处理用户的“身份证号+银行卡号”用于实名认证和支付。按上述方法映射：
| 法律条款 | 义务描述 | 标准控制项 | 系统落点 | 证据 |
|---|---|---|---|---|
| 个保法第28条 | 敏感个人信息需单独同意 | GB/T 35273 敏感信息明示同意 | 实名认证弹窗单独勾选 | 弹窗截图+同意记录表 |
| 个保法第55条 | 处理敏感信息前做PIA | GB/T 39335 评估流程 | 上线前PIA工单 | PIA报告+审批记录 |
| 数安法第27条 | 建立全流程数据安全管理制度 | GB/T 41479 数据处理安全 | 数据分类分级表+加密策略 | 分类分级文档+加密配置 |
| 网安法第21条 | 日志留存不少于6个月 | GB/T 22239 安全审计 | 日志平台保留策略 | 日志保留配置截图 |
这张表就是合规基线的“最小可运行版本”。它不追求覆盖全部法条，而是先把高风险、高频率、易被检查的义务落下去。后续每新增一个业务功能，都应先查这张表：是否触发新的告知同意、是否涉及敏感信息、是否需要PIA、日志是否覆盖。这样合规就不是一次性项目，而是嵌入研发流程的常规动作。
最后需要强调：三部法律与配套标准之间不是简单的一对一映射，同一条义务可能同时来自多部法律，同一个控制点也可能同时满足多项要求。映射表的价值在于让团队看清“哪条法律、哪个标准、哪个系统、哪份证据”之间的对应关系，从而在整改时能精准定位，而不是盲目堆砌安全产品。