个人信息保护法解读：常见合规场景与应对

摘　要：

《中华人民共和国个人信息保护法》的实行，将对企业日常运营中的各类个人信息处理活动带来新的影响与挑战。通过选取三个较常见的业务场景，探讨企业在新合规背景下的应对策略。首先，基于产品的隐私设计管理机制建设提出建议，并聚焦移动 App 隐私合规设计，举例说明合规设计要点；其次，大数据场景下如何做到既赋能业务又保护用户权利，提出五大关注重点；最后，天有不测风云，针对企业在个人信息安全事件响应所面临的挑战，提出了事前、事中和事后的应对机制。

内容目录：

1　产品隐私设计

1.1　建立隐私设计的管理机制

1.1.1　自上而下的管理机制建设

1.1.2　自上而下的管理机制建设

1.2　关注热点——移动 App 隐私合规设计

2　当隐私遇到大数据

2.1　数据合法基础：多渠道个人信息处理的授权同意管理

2.2　弱化身份指向：个人信息的去标识化处理

2.3　个人权益保护：大数据处理和自动化决策的监督管理

2.4　安全基础保障：大数据平台的网络安全技术防护

3　致胜应急响应

3.1　事前准备，谋定而后动

3.2 事中应对，亡羊补牢未为迟

3.3　事后复盘，前事不忘后事之师

《中华人民共和国个人信息保护法》（以下简称“个人信息保护法”）的发布为企业的个人信息保护实务提出了新的挑战。我们已经通过观察法案变化亮点，解读了企业的合规策略与能力建构重点，企业只有通过破解个人信息保护难点，才能找到赋能长效合规的解决方案。那么随着企业数字化步伐的加速、数据战略的扩展，面对当前快速迭代的产品、海量的数据价值挖掘和日益严峻的威胁局势，企业应该如何应对？基于企业普遍面临的问题，选取了三个常见的合规场景，与大家共同探讨其应对策略。

01 产品隐私设计

面对新型的技术时，企业除了考虑该如何使用这项技术创造业务价值，也应该考虑是否尊重了用户的隐私权利。在思考这些问题的同时，企业也面临着一个巨大的痛点：隐私保护动作的滞后性将会带来更高的成本投入与沟通内耗。

为了解决这些问题，原生隐私设计（Privacy byDesign，PbD）的概念被提出并付诸实践。

企业可以通过建立系统的工程方法，将隐私保护纳入完整的产品开发流程中。这一过程中，企业不仅需要关注产品隐私设计流程、建立相应的隐私管理体系，更要着重关注该如何将此策略应用在设计实践中。

1.1　建立隐私设计的管理机制

在产品开发和系统设计之初定义数字化产品隐私功能需求，能够有效地实现对用户隐私数据权利的主张与产品的隐私合规，图 1 就是较为完善的隐私嵌入研发的全生命周期示例。企业建立隐私设计的机制和流程往往无法一蹴而就，而是需要通过跨职能协作、快速迭代和优化方能建立起高效的管理机制。

图 1 隐私嵌入研发全生命周期示例

1.1.1　自上而下的管理机制建设

在隐私设计管理机制定义初期，需要企业高层意志明确，自上而下地推动流程机制的建立，明确各部门协作分工的基调，坚定隐私保护团队与业务部门之间是合作模式，而非监察模式。针对安全成熟度较高的大企业，应立足于国内外隐私标准，结合业内最佳实践，基于企业本身的隐私保护管理体系形成一整套隐私设计开发管理框架。而对于大部分中小型企业，可以以“小步快跑”的形式，针对业务特点、产品特性建立最重要的流程和指引。比如 SDK 提供商，应优先针对 SDK 开发需求进行明确，并在上线前进行检测。

1.1.2　自上而下的管理机制建设

企业应建立项目关键节点，根据产品研发项目管理流程，选择合适的节点开展隐私安全评审工作，并明确在各个节点各人员的角色分工及职责要求。“三步走”的实施步骤可为企业提供参考：

第一步，需求分析。应至少包含对于隐私合规需求与业务需求的界定，由业务团队和隐私合规团队共同确认最终的产品需求。第二步，产品设计与开发。业务团队根据产品需求，输出产品设计说明书，经隐私合规团队评估合规性并沟通修改后，形成最终版的产品设计说明书，交付技术开发团队进行产品开发及编码实现。第三步，测试与实施。测试团队与业务团队在测试运行中确保系统能够满足隐私保护要求，并出具测试报告交由隐私合规团队进行审核以确认上线。

1.2　关注热点——移动 App 隐私合规设计

移动 App 隐私合规是当前炙手可热的话题，如何保证在不断开发迭代的过程中均不会出现问题，保证每一个发布的新版本都满足个人信息保护的合规要求，将安全和个人信息保护的要求嵌入 DevOps 流程中至关重要。

企业在移动 App 开发流程中实现原生隐私设计的初期，可能无法覆盖全生命周期的所有环节。企业可以选重要的流程进行卡点，比如产品需求阶段的隐私合规评审、产品上线前的隐私检查、第三方 SDK的引入检查等。

以引入新的 SDK 为例，当由于业务的需求引入新的SDK 时，需要对SDK 进行隐私合规评审。同时，App提供者还应该要求 SDK 提供方对其安全能力进行说明，提供安全评估报告，并通过合同等形式共同约定双方在防止恶意行为、安全漏洞响应、数据安全防护、个人信息安全保护方面各自应承担的责任和义务，并做到信息披露及时、准确。一旦确认引入新的SDK，应将个人信息保护需求作为非功能性故事用例提出交付开发团队，如表 1 所示，明确 SDK 嵌入使用的具体开发要求与相应的测试用例。

表 1 SDK 的个人信息保护要求示例

产品上线前，隐私合规部门除了对开发团队提供的测试验证文档进行审阅以确保满足隐私合规要求外，还可以考虑将自动化扫描工具嵌入 CI/CD 流程中，对可能存在的隐私风险如 SDK 超频收集个人信息、授权前收集个人信息、后台调用等风险进行识别。

此外，除了 SDK 的合规使用，根据移动 App 的个人信息收集使用合规还应当重点关注以下几个方面：

其一，移动 App 的隐私政策内容及展示。除了内容需要清晰易于查阅，包含收集使用的个人信息及其目的、App 运营者的基本信息等内容外，还需要在用户首次启动 App 时通过弹窗的方式或单独的页面提示隐私政策。弹窗至少要包括 3 个元素：隐私政策内容的重点介绍、访问链接、同意 / 拒绝选项。

其二，个人信息收集时的授权同意。在收集用户个人信息时，又分为用户主动提交个人信息和 App 自动收集个人信息。当用户主动提交个人信息时，需要获得用户授权，针对个人敏感信息，应获取用户的单独授权，向用户明示收集、使用个人信息的目的、方式和范围。当 App 自动收集个人信息时，应注意仅能在用户授权同意后（一般在同意隐私政策之后）开始进行收集。同时，应当在隐私政策中声明所收集个人信息的方式、类型、频率和目的等。

其三，系统权限的申请与调用。移动 App 调用系统权限属于个人信息收集的一种方式。在实践中，App 会调用位置信息、拍照等系统权限以获取用户的 GPS 定位信息或头像等个人信息。在 App 隐私合规设计时，推荐的做法是为每个系统功能设计一个单独的弹窗，明确 App启动时需获取系统权限的场景，以及后续业务场景中需要获取的系统权限。通过此设计也可以实现在下次启动 App 时，对用户选择“禁止” 的功能进行单独弹窗。

其四，用户权利的实现。移动 App 应为用户提供查询、修改、删除个人信息，注销账号，撤回同意，投诉等用户隐私需求的渠道。例如，用户提交的个人信息、评论、收藏的功能等应当可以进行访问、修改和删除；又如根据合规要求，移动 App 中应提供账号注销的功能，除了前端提供注销按钮方便用户进行注销，还应将后台的账号所涉及的个人信息进行去标识化处理，如手机号码、地址等信息。若移动 App 会根据用户个人信息、行为数据等进行个性化推送，移动 App 应为用户提供关闭个性化推送的开关。

总之，个人信息的保护不应该是一种事后的控制，仅在合规问题出现后才进行补救。伴随着公民隐私保护意识的觉醒，隐私与安全性逐渐也成为各大知名产品的宣传点和竞争优势。在产品需求、开发、上线的过程中嵌入隐私设计，将个人信息保护的要求考虑在内，不但能达到事半功倍的效果，更能为品牌赢得更多消费者的信任。

02 当隐私遇到大数据

在当今的企业运营过程中，数据不再仅仅是停留在信息系统后台的信息载体，而是为业务赋能的宝贵资源。通过分布式存储等基础设施来高效处理来自多渠道的海量大数据，已然成为企业使用数据赋能的不二选择。为保证企业灵活运用大数据赋能业务的同时落实个人信息保护，我们建议企业在应用大数据技术过程中应当关注五大重点。

2.1　数据合法基础：多渠道个人信息处理的授权同意管理

授权同意管理是企业个人信息保护的关键能力之一，而对于企业数据处理能力的核心系统——大数据平台来说，授权同意管理直接影响着其合法利用个人信息为业务赋能的能力。

针对不同的个人信息数据源，企业在获得个人同意的过程中可能面临不同的挑战：

一种情况是，第一方数据的挑战。

企业通过自建的个人信息收集渠道或触点所收集得来的用户个人信息。企业对第一方数据收集的方式、具体信息类型、收集频率、用户旅程等有着直接的决定权。尽管企业可以通过隐私协议、弹窗或其他交互形式来获得用户的授权同意，但由于大数据处理目的繁多且存在较大的可扩展性，仍需企业在用户界面、文本和交互形式等方面设法满足用户充分知情的法律规定。

另一种情况是，第三方数据的挑战。

模式 A：企业通过在第三方平台建立用户触点所间接收集的个人信息，如微信、天猫用户资料等。企业往往对这部分数据的获得方式有一定的控制权，但所收集的具体方式和类型、频率等会受到第三方平台的限制。该情况下，企业在主动获得用户授权同意的同时，还需遵守渠道平台的统一规则以及平台与用户之间的个人信息保护政策中所规定的条款。

模式 B：企业通过第三方服务间接获得的用户在第三方触点所留下的个人信息，如企业进行在线广告投放后所获得的用户设备、行为信息。企业获得这部分数据时往往不会与用户有直接的接触。企业往往会通过合同的形式来约定数据处理的范围以及数据安全、获取授权同意的责任归属，但企业通常较难验证第三方数据的实际授权情况。

挑战不止于收集个人信息时获得授权同意。在保证合法性基础的前提下，如何基于授权同意来对大数据的处理方式进行限制，也是企业使用大数据技术应当关注的重点与难点。此外，根据个人信息保护法第十五条，基于个人同意处理个人信息的，个人有权撤回其同意。企业除了在用户触点保障用户撤回授权同意的权利，内部数据处理平台中也应当及时同步授权状态。

面对繁杂的授权同意管理，我们提出以下几点建议：

第一，企业应建立组织内一致、高颗粒度的用户授权管理机制。在大数据处理系统中，通过技术手段实现对用户授权同意状态的自动化管理，保证用户提供、改变、撤回授权同意，以及在用户授权同意情况较为模糊的情况下，有效管理相关联的数据处理活动，并留下合规性审计证据。第二，企业应建立完善的数据引入管理机制。企业在向大数据平台导入数据时，均应进行个人信息保护影响评估，确保数据在大数据平台中的处理活动在用户授权范围内。针对三方数据，应在合同条款中明确数据合法性的责任、使用目的的限制等要求，并在必要时进行适当的尽职调查。第三，企业应实施隐私设计机制以实现多触点、细粒度的用户授权同意管理机制，确保采集一方数据的触点在设计之初便有着细颗粒度的用户授权同意机制，并通过用户界面为用户提供充分的透明性和决定权。

针对内控相对较弱的中小企业，在风险控制与业务的天平之间更容易倾向于后者，负责法务和安全的团队往往对业务部门的管控水平较低；此外，在整个数据生态链中，中小企业与互联网平台等第三方数据提供方的议价能力也较弱，往往会成为合规风险转移的接受方；同时，大数据平台安全和隐私管控的增强往往需要更多的资源投入和更专业庞大的团队支撑。在内外交困的形势下，中小企业较难形成复杂的授权同意管理机制。针对这种情况，我们建议中小企业对数据来源进行梳理并对其合规风险进行评估，在保证一方数据的合法性的前提下，通过减少非必要数据和匿名化等手段降低对三方数据的依赖性，从数据来源上尽可能地降低合规风险。

2.2　弱化身份指向：个人信息的去标识化处理

去标识化是企业实施个人信息保护、有效降低个人信息安全风险的重要手段之一，也是打开数据主动权的重要方式。将大数据平台内用于业务处理的个人信息进行必要的去标识化处理，并与原始信息进行隔离存储并实施严格的访问控制，将会很大程度上降低数据泄露的风险。在实践中，如何确保去标识化的有效性、降低重标识风险，与此同时确保信息的业务价值不被损害，为诸多企业带来了不小的挑战。

企业应意识到，去标识化工作不仅仅是脱敏处理，而应是完整的管理闭环，就此我们提出以下三点建议：第一，制定、实施数据分级分类及保护制度，对大数据平台中存储的数据进行发现和识别，并针对不同敏感级别的数据采取不同的保护措施。第二，针对不同级别和类别的个人信息，建立适用于企业不同场景的个人信息去标识化技术指引。企业可参考相关指南制定去标识化的标准和指引，对于部分特殊行业，还可参考行业监管部门的指导性建议，如金融行业的信息保护技术规范就提供了个人金融信息隐藏规则的示例。第三，恰当采用统一的平台和工具来进行数据去标识化处理，保证实施规则与设计要求相符合，实施效果可控，防止出现依赖于工程师安全意识而导致去标识化效果无效的情况出现。

2.3　个人权益保护：大数据处理和自动化决策的监督管理

基于大数据的智能决策为业务目的赋能，是大数据的价值所在，也是大数据的“危险” 之处。若大数据算法由于设计本身或训练数据集的偏差而导致算法带有歧视，同时企业对大数据处理结果缺乏有效控制，那么除了“大数据杀熟”，还可能会对个人信息主体其他合法权益带来更加严重、隐蔽的损害。

个人信息保护法第二十四条做出规定：“通过自动化决策方式作出对个人权益有重大影响的决定，个人有权要求个人信息处理者予以说明，并有权拒绝个人信息处理者仅通过自动化决策的方式作出决定。”并在第五十五至五十六条中要求，利用个人信息进行自动化决策前，应进行个人信息保护影响评估，对个人权益的影响及安全风险等方面进行评估。

企业在业务运营过程中，应当建立大数据处理结果和自动化决策的监督和管理机制：

第一，在算法设计与模型训练时应对算法的歧视、数据集的偏差进行有效评估和管控，合理平衡个人信息主体权利，并建立问责追责制度。第二，在进行个人信息自动化决策处理前，应进行个人信息保护影响评估，分析决策结果对个人信息主体合法权益的影响，进行用例审阅和审批，并在使用过程中定期（至少每年一次）进行影响评估，以在必要情况下进一步采取保护个人信息主体的措施。第三，在大数据平台数据处理与自动化决策的功能下，应当提供有效的人工干预能力，并支持对自动化决策结果进行人工复核。第四，建立透明性机制，为个人信息主体提供便利的查询、咨询和投诉渠道，为处理机制进行充分的说明和解释，并提供不针对个人的选项与停止自动化决策的服务方式。第五，提供救济渠道，在个人信息主体权益受到损害时，为主体提供救济和补助、补偿。

2.4　安全基础保障：大数据平台的网络安全技术防护

对于大数据平台来说，大数据常见开源架构在设计初期对安全的考虑不足和大数据的天然特性等因素，给企业也带来了新的安全风险。然而，这些平台级别的安全风险会直接或间接导致数据泄露的风险，如大量不同类型及不同敏感程度的数据汇聚所导致的数据泄露风险、组件自身安全管控措施不足所导致的访问控制缺失风险、用户拥有较大的自由度而导致的越权风险以及服务器及开放服务数量所导致的运维风险等。

由于大数据平台的安全所涉及的领域复杂多样，我们在此仅针对其安全技术防护思路提出如下五个高阶建议：

第一，大数据平台选商时应对其安全能力进行评估，选择具有相关安全认证的产品，并在合同中进行相关责任的明确。尤其针对很多中小型企业，其安全技术内审能力仍有待提高，对厂商存在较高的依赖性，安全认证与合同规定可能是行之有效的第一层保障。第二，建立覆盖数据全生命周期的安全防护，如数据源的认证、传输加密、数据加密存储、数据流动检测等技术。第三，引入身份认证和访问控制机制，包括用户和组件，防止数据的未授权访问。针对成熟度较高及角色复杂的企业，应考虑针对不同的用户采取不同级别和类型的数据的细粒度访问权限控制。第四，从被动防御向主动检测转变，提前识别数据泄露风险。利用用户行为日志，结合业务使用场景制定规则，对异常行为进行分析与监控，主动发现数据泄露的隐患点，及时采取补救措施。第五，保证大数据平台基础设施安全，如针对主流平台建立基本安全配置基线，确保所有组件的配置项符合基线要求。

总之，大数据中的个人信息保护不仅关乎合规，更关乎着客户对企业的信任。企业应当视挑战为机遇，将个人信息保护打造成为企业大数据应用中的内生能力和核心价值，使其为企业赋能的同时帮助企业与客户间建立信赖。

03 致胜应急响应

许多企业为了达到合规的目标，已经建立了针对个人信息安全事件的响应计划和应急预案。然而在实践中，企业往往面临着从组织架构、响应流程到技术支持、协作分工等诸多挑战。主要包括：

第一，职责分工不明且缺少及时的资源支持，导致实践处理时机延误。第二，安全事件识别能力不足，难以发现或收集事件的相关信息。第三，缺乏数据流转与血缘信息，难以快速定位影响范围和泄露渠道。第四，安全防御覆盖面不足，无法全面检测潜在事件。第五，事件记录不充足，难以满足事件分析的必要需求。

3.1　事前准备，谋定而后动

挑战在前，企业应当如何应对？制胜应急响应还应从事前准备做起，可从人员、技术、流程三个方面入手。

人员方面的准备包括：个人信息相关事件的应急响应，不仅仅是一个技术问题。针对大型的企业，关键职能如信息技术、公共关系、法务、人力资源和内控等部门，都应作为应急响应小组的成员，从专业角度提供事件处理的意见与建议，帮助企业更好地解决事件所带来的影响；而针对中小型企业，公司内部应当至少指定一位事件接口人进行协调，并赋予该同事在紧急情况下调配资源的权限。事件响应外包专家也是国外的最常见做法，以应对企业人员技能缺失的情况。

业务部门，作为个人信息的负责人，有责任和义务为事件的响应提供支持。

接受委托为企业处理个人信息的受托人，应当充分知晓其在应急响应中的职责以及事件发生时的沟通机制，必要时成为应急响应小组的编外成员。

技术方面的准备包括：安全体系建设相对成熟的企业应结合业务场景、IT 系统对所面临的个人信息安全风险进行威胁建模，构建自己的多层级纵深防御体系，铺排基于网络、终端、应用、数据的监测体系，实现多渠道日志的集成与联动分析，基于威胁场景进行监控，建立不同数据处理角色的基准与风险评分，识别异常行为。

预算相对有限的中小型企业可以考虑采用开源的日志系统，并基于风险最小的数据泄露场景提取最关键的日志信息进行分析，比如关键系统的重要数据操作日志、远程访问日志等进行聚合，分析各种潜在威胁，并定义相应的安全等级按照高中低危告警并通知 IT 或安全团队进行处理。比如针对提供专业客服的企业，可考虑将客服系统的接线日志与客户关系管理系统中查询用户个人信息的日志进行关联分析，识别出客服人员的异常行为，例如查询用户数量远大于接线日志，则可能存在滥用权限查询用户个人信息的风险。

流程方面的准备包括：检测应急响应预案是否有实操价值的最佳方式便是开展演练工作。演练方式应当根据业务场景、涉及人员等因素进行选择，让应急响应演练不再是一纸文书，而是意识提升或流程检测的手段。目前主流的应急响应演练方式可分为：提升企业管理层应急响应和执行团队意识及流程熟悉度的桌面沙盘演练；检测单个系统或特定岗位（如安全运维中心）应急响应部分功能的实际演练，如红蓝对抗；检测企业综合响应能力的全面演练。

3.2 事中应对，亡羊补牢未为迟

面对当前不断精进的攻击手段以及灵活的业务合作生态，个人信息安全事件的发生已经难以避免。但企业仍能通过各种手段，将此类事件的损失降到可接受范围内，减少对个人信息主体及企业造成的危害。我们建议，当事件发生时，企业需要关注的是如何进行快速止损以及事件的溯源取证。

当企业识别到可能发生或已发生的个人信息事件时，可通过数据样本对比等方式，确定可能受影响的数据源，并对于可能受影响的数据源制定可行的遏制措施，以防止事件扩大。对于这些遏制措施所带来的业务影响，应急响应小组与相应业务部门应当进行评估与协商，管理层应当在损失与影响之间进行权衡与决策。

个人信息相关事件可能是由不同类型的原因造成的，企业根据其自身具备的条件所采取的遏制措施也有所不同。以下举两个常见的事件类型：

对于外部攻击导致的事件，我们应进行如下处理：

第一，分析受影响主机的相关日志（例如主机进程、网络日志等）以及潜在可疑文件进行排查，调查并溯源黑客的攻击方及攻击路径。第二，尽快下线受影响服务器。如果主机下线会影响到关键业务，应尽可能切断主机的外网访问权限。第三，根据调查过程中发现的攻击方式、攻击路径以及可疑文件等整理出本次事件相关的 IOC，并通过 SIEM 或 EDR 等安全解决方案检查黑客横向入侵的痕迹。第四，对受到黑客横向移动影响的主机进行排查，确认横向移动是否成功，并对所有受影响主机进行清理。如果有必要，建议重装系统后上线。第五，紧急处置完成后，应考虑对受影响系统进行后续安全加固工作，例如安装补丁。

3.3　事后复盘，前事不忘后事之师

事件结束之后，首要任务便是事件的总结与复盘，防止事件再度发生，并进一步提升事件的应急响应效率。应急响应小组应识别出在实际事件响应和调查分析过程中遇到的问题，可以分为两类：

一方面，进行安全事件根本原因分析。根据过往经验，我们从账号管理、安全基线、数据安全、日志及监控四个维度总结了部分可能导致企业个人信息安全事件的不当控制如表 2 所示。另一方面，研究应急响应流程问题。应急小组可以通过召开复盘会议的形式，组织应急响应涉及的人员对整个过程的执行步骤和效果进行反馈。

表 2 安全事件根本原因示例

针对尚未发布应急响应预案的企业，在复盘阶段，参与到事件应急响应的成员应记录自身在应急响应过程中执行的操作，向应急响应负责人反馈，由信息安全部门主导制定和发布个人信息相关的应急响应预案，为之后类似事件的发生提供响应指南。

针对已发布应急响应预案的企业，应急响应预案应根据应急演练效果和实际应急响应流程，对应急响应预案进行迭代更新。在复盘阶段，应急小组应结合实际情况，判断应急流程是否按照应急响应预案严格执行，实际过程是否与预案有偏差，并究其原因进行相应优化。

事件复盘结束后，应急响应负责人应归档保存事件响应调查过程中的证据，形成事件调查报告，以供公司管理层、投资方、监管部门及履行个人信息保护职责的部门后续查阅。

企业同时也应防范重标识攻击，避免攻击者通过其他维度或关联信息进行关联或推断。

04 结　语

作为中国首部个人信息保护方面的专门法律，《中华人民共和国个人信息保护法》的颁布将引领整个社会步入一个新的篇章。同时，亦如《中华人民共和国网络安全法》生效后的四年以来，监管部门不断完善其支撑条例与执法细则，可以预见的是未来会有更多垂直行业、细分领域的个人信息保护的标准、指南以及行政管理细则出台和落地。我们也期待各个企业能主动进取、审慎经营，化合规挑战为机遇，共同构建可信的生态。

引用本文：施建俊 , 王瑾 . 个人信息保护法解读：常见合规场景与应对 [J]. 信息安全与通信保密 ,2021(11):19-29.