隐私基本概念：个人数据、数据主体、数据控制者、数据处理者、隐私影响评估等核心术语
在ISO 27701的落地实施中，术语定义不仅是理论起点，更是隐私管理体系建设的“语法规则”。如果组织对“个人数据”的边界、对“控制者”与“处理者”的职责划分理解不一致，后续的风险评估、控制措施选择、DPA（数据处理协议）签署乃至隐私影响评估（PIA）都会失去统一基准。本章将围绕五个核心术语展开深度解读，并结合实际业务场景说明其应用逻辑。
2.1 个人数据：识别性与关联性的双重判定
核心原理：个人数据（Personal Data）在ISO 27701中延续了ISO/IEC 29100的定义，指“与已识别或可识别的自然人（数据主体）相关的任何信息”。这里的“可识别”包含两层含义：一是直接识别，如身份证号、手机号、人脸图像；二是间接识别，即通过一个或多个因素组合能够锁定特定自然人，例如“某公司35岁男性、产品经理、月薪3万”这类组合信息。值得注意的是，匿名化处理后的数据（无法再识别到个人）不属于个人数据，但假名化数据仍属于个人数据，因为通过密钥或关联信息可以重新识别。
判断方法：实务中建议采用“三问法”进行个人数据识别：
- 关联性：该信息是否与某个自然人的属性、状态、行为或活动相关？例如“设备MAC地址”本身不是个人数据，但若与设备持有人的位置轨迹关联，则构成个人数据。
- 可识别性：单独或结合其他信息能否直接或间接锁定到具体个人？例如“工号”在公司内部可直接识别员工，属于个人数据。
- 情境性：同一数据在不同场景下性质可能不同。例如“公司总机号码”通常不是个人数据，但若该号码是某员工直线电话且对外公开，则可能成为个人数据。
案例拆解：某电商平台在用户注册时收集“手机号+收货地址+浏览记录”。手机号可直接识别用户；收货地址结合手机号可锁定具体家庭住址；浏览记录单独看是行为数据，但结合用户ID后能反映个人偏好。因此，这三类数据均属于个人数据。平台在隐私政策中需明确告知收集范围、使用目的，并取得用户同意。若平台将“脱敏后的购买记录”（去除用户ID、手机号等标识符）用于数据分析，则不再属于个人数据，但仍需注意重新识别风险。
常见误区：许多组织误以为“加密后的数据”或“去标识化数据”不再是个人数据。实际上，只要存在可逆的映射关系（如加密密钥、映射表），数据仍属于个人数据。只有经过不可逆匿名化处理的数据才可豁免。此外，IP地址、Cookie标识符在多数司法管辖区（如GDPR）下也被视为个人数据，不能仅因“不是姓名”而忽略。
2.2 数据主体：权利主体与权益保护的核心
核心原理：数据主体（Data Subject）是个人数据所指向的自然人。ISO 27701强调数据主体的权利保障，包括知情权、访问权、更正权、删除权（被遗忘权）、限制处理权、可携带权、反对权等。这些权利不是抽象概念，而是组织必须通过流程和技术手段予以响应的具体义务。例如，当用户要求导出其个人数据时，组织需在合理期限内（通常为30天）提供结构化、机器可读的副本。
操作流程：组织应建立“数据主体请求（DSR）响应机制”：
- 请求接收：通过客服、邮件、在线表单等多渠道接收请求，并验证请求人身份（防止数据泄露给冒名者）。
- 请求分类：区分是访问、更正、删除还是其他类型，并判断是否属于豁免情形（如法律保留要求）。
- 内部流转：将请求分发至数据所有者（如业务系统负责人），限期核查数据位置和存储情况。
- 执行与反馈：在法定时限内完成操作，并记录处理结果；若拒绝请求，需说明法律依据。
实战场景：某SaaS企业收到一位企业客户的员工投诉，要求删除其在该平台上的个人数据。该企业作为数据处理者，不能直接删除数据，而应通知其客户（数据控制者）并配合执行。若控制者未及时响应，处理者需评估是否暂停处理或向监管机构报告。这一场景体现了控制者与处理者之间的协作机制。
常见误区：部分组织将“数据主体权利响应”视为法务部门的单一职责，而忽略了IT系统层面的支持。例如，若数据分散在多个数据库和备份中，仅删除前端记录而遗漏备份数据，仍可能违反删除权要求。建议建立数据映射清单，明确各类数据的存储位置、保留期限和删除机制。
2.3 数据控制者与数据处理者：责任划分的基石
核心原理：数据控制者（Controller）决定个人数据处理的目的和方式，是合规责任的主要承担者；数据处理者（Processor）代表控制者处理个人数据，仅能按照控制者的书面指示行事。这一区分直接影响DPA（数据处理协议）的签署、安全措施的实施以及违规时的责任分配。例如，云服务商通常是处理者，而使用云服务的企业是控制者；但若云服务商自行决定将客户数据用于训练模型，则其角色转变为控制者。
判断方法：可通过以下问题快速判定角色：
| 判断维度 | 数据控制者 | 数据处理者 |
|---|---|---|
| 决策权 | 决定“为什么处理”和“如何处理” | 仅按合同约定执行，无自主决策权 |
| 合同地位 | 与数据主体直接建立关系 | 与控制者签订DPA，不直接面对数据主体 |
| 安全责任 | 承担最终合规责任，需监督处理者 | 实施技术和管理措施，配合控制者审计 |
| 违规后果 | 可能面临行政处罚和民事赔偿 | 若超出指示处理，则视为控制者并承担同等责任 |
案例拆解：某银行（控制者）委托一家IT外包公司（处理者）开发客户管理系统。外包公司在开发过程中使用真实客户数据进行测试，且未征得银行同意。此时，外包公司因“超出指示处理”而转变为控制者，需独立承担违规责任。银行若未对外包公司进行充分尽调（如检查其安全能力、签署DPA），也可能因监督不力而承担连带责任。此案例说明，控制者不能仅依赖合同条款，还需建立持续监督机制。
常见误区：许多组织混淆“委托处理”与“共享”的边界。若控制者将数据传输给另一独立组织用于其自身目的（如市场调研），则后者是新的控制者，而非处理者。此时需单独取得数据主体的同意或基于合法利益评估，不能简单套用DPA。
2.4 隐私影响评估（PIA）：风险前置的工程化方法
核心原理：隐私影响评估（Privacy Impact Assessment, PIA）是一种系统化流程，用于识别个人数据处理活动可能带来的隐私风险，并评估缓解措施的有效性。ISO 27701要求组织在引入新技术、新产品或重大业务变更时开展PIA，尤其是涉及大规模敏感数据、监控行为或数据跨境传输的场景。PIA不是一次性的合规检查，而是嵌入项目生命周期的持续活动。
操作流程：PIA通常包含六个步骤：
- 启动筛选：判断项目是否触发PIA条件（如处理特殊类别数据、涉及自动决策、大规模监控）。
- 数据流映射：绘制数据从收集、存储、使用、共享到销毁的全链路图，标注数据类别、访问权限、传输路径。
- 风险识别：从机密性、完整性、可用性三个维度分析潜在威胁（如内部越权、外部攻击、误操作）。
- 风险分析：评估风险发生的可能性和影响程度，确定风险等级（高/中/低）。
- 缓解措施：设计并实施控制措施（如加密、访问控制、数据最小化），并验证其有效性。
- 记录与审批：形成PIA报告，由隐私负责人（DPO）审批，并保留记录以备监管审查。
案例拆解：某健康科技公司计划推出一款可穿戴设备，用于收集用户心率、睡眠数据。在PIA过程中，团队发现数据将通过蓝牙传输至手机APP，再上传至云服务器。风险识别阶段发现：蓝牙传输存在中间人攻击风险；云服务器位于境外，涉及跨境传输合规问题。缓解措施包括：采用AES-256加密传输、将服务器迁移至境内或签署标准合同条款、在APP中增加二次授权弹窗。PIA报告显示，剩余风险降至可接受水平，项目获批上线。若未开展PIA，该产品可能因违反数据本地化要求而面临下架处罚。
经验提醒：PIA应尽早启动，最好在需求分析阶段介入，而非等到开发完成后再补做。同时，PIA报告应包含“风险接受声明”，由业务负责人签字确认，避免“为了合规而走过场”。
常见误区：部分组织将PIA等同于“隐私自查表”，仅勾选几个选项就草草了事。实际上，PIA的核心价值在于“数据流映射”和“风险分析”的深度。建议使用标准化的PIA模板，但需根据项目特点定制风险场景，避免模板化思维。
2.5 术语间的联动关系与体系落地
核心原理：上述术语并非孤立存在，而是构成一个相互关联的体系。数据主体是权利源头，个人数据是处理对象，控制者与处理者是责任主体，PIA是风险管理工具。在ISO 27701的PIMS（隐私信息管理体系）中，组织需基于这些术语建立统一的隐私治理框架。例如，在制定隐私政策时，需明确控制者身份和联系方式；在签署供应商合同时，需界定处理者义务；在开展新产品评审时，需触发PIA流程。
体系落地建议：
- 建立术语表：在组织内部发布统一的术语定义，避免业务部门与法务部门理解偏差。
- 角色与责任矩阵：明确控制者、处理者、DPO、业务负责人的具体职责，并纳入绩效考核。
- 流程嵌入：将PIA、DSR响应、DPA签署等流程嵌入现有项目管理、采购管理和IT变更管理流程。
- 培训与宣贯：定期对员工进行隐私意识培训，重点讲解“个人数据识别”和“最小化收集”原则。
总结复盘：某跨国制造企业曾因未区分控制者与处理者角色，导致其HR系统供应商在未授权情况下将员工数据用于背景调查，引发集体诉讼。事后复盘发现，根本原因在于采购部门未签署DPA，且未对供应商进行隐私能力评估。该企业随后建立了“供应商隐私准入清单”，将PIA、DPA签署、数据映射作为供应商上线的强制条件，并在合同中明确违约赔偿条款。这一案例表明，术语理解不是纸上谈兵，而是直接关系到组织的法律风险敞口。
经验提醒：建议组织定期（如每半年）对现有数据处理活动进行“术语重新审视”，因为业务变化可能导致角色转变。例如，原本作为处理者的子公司若开始独立决定用户画像用途，则需重新评估其控制者身份。