如前一篇文章所介绍，基于GDPR第25条要求，我们需要在产品/服务开发的早期就执行DPIA。在ICO的网站上可以下载到DPIA的模版文件，当然我们也可以使用企业自有的模版或者是隐私平台产品(比如: OneTrust)的内嵌模版。 无论使用什么样的评估方式，整个DPIA的步骤和要覆盖的内容都是一致的。
一、评估是否需要DPIA
如果我们要开发的系统涉及到个人数据的处理，请注明具体的处理目的和方式，然后对照上文中注明使用DPIA的场景。根据匹配情况，写明是否执行DPIA的结论。
二、描述数据处理活动
如果#1的结论是需要DPIA，则进一步需要详细描述个人数据处理场景。它要覆盖如下几个关键点。
1. 数据处理的性质
1）数据全生命周期的处理情况描述， 包括如何收集/存储/使用数据，向谁开放数据的访问和共享，数据留存期限；
2）使用的个人数据保护技术手段；
3）是否使用新的数据处理技术；
2. 数据处理的范围： 包括数据采集的数量，类型，敏感度，以及数据处理的范围与频率
3. 数据处理的目的： 系统要实现的业务目的，处理者以及社会的预期收益
4. 数据处理的背景： 数据来源，数据主体与处理者的关系，数据主体拥有的数据控制权
三、确认是否需要咨询利益相关人
如果系统涉及到对已有个人数据的处理，需要一个咨询流程来征求特定个人或代表的意见。
如果有合理的理由(商业机密，成本过高等)可以不咨询，但需要在DPIA文档中记录决定及其原因。
四、评估必要性和对称性
主要是描述我们的数据处理活动和要实现的业务目标是否匹配，以及我们是准备如何保护自然人的个人数据。它包括
1）数据处理的合法性基础
2）规划的数据处理活动如何支持预定的业务明白；
3）系统中如何实现数据最小化和数据质量原则；
4）如何保障自然人的数据主体权利；
5）如何保障数据跨境传输的安全性。
五、识别和评估风险
利用风险评估框架，识别系统中可能的隐私风险，并进行定性评估。这里的隐私风险关注的是数据处理活动给自然人带来的主观或客观的伤害。
评估结果包括伤害发现的可能性，以及伤害发生对自然人的影响程度。
在启动阶段，我们可能无法完整列出所有的风险，可以在系统开发周期中逐步完善和更新。
六、识别风险缓解措施
针对已识别的风险，列出的可能的风险缓解措施，并基于措施实施的成本和收益(风险缓解情况)来选择合适的方案。
针对已识别风险，更新列表，记录采集缓解措施后的残余风险情况。
七、签署和记录DPIA结论
记录采取缓解措施后，剩余风险的总体情况。如果还有高风险，需要咨询监管机构。
如剩余风险达到了组织的可接受程度内，由评估人，DPO等进行签署。
DPIA的迭代需求
DPIA不是一个一次性任务，我们需要将它整合到整个系统开发项目中。DPIA中确定的缓解措施需要指定执行人，并作为项目任务进行验证和监督。在整个开发生命周期中，需要多次迭代执行DPIA，尤其是其中的隐私风险识别和管理任务，确保所有风险项被完整识别、记录、处理和沟通。
//参考资料： ICO - Guide to The GDPR
网友评论