数据安全的概念在近年来，越来越受企业重视，更多的是因为合规性的驱动，尤其是GDPR的巨额罚款，让企业开始愿意去投入更多的成本来满足数据保护合规性要求。数据安全的合规，最终不可避免的涉及到信息安全体系的建设、IT架构的设计以及应用系统的开发。作为一名信息安全从业人员，在此不去深究法律层面的术语概念，专业的事情就给专业的法律人员，而是从信息安全人员的角度去做相关的设计建设。

而在数据安全合规建设中，尤其是对GDPR的合规中，大型企业一般不会完全重新设计新的流程，而是尽可能的与过往的iso27001、SDL流程等现有体系流程相结合。同时对于研发来说，为了发布一套系统四处填写类似信息，亦会造成研发的反感。

本人有幸参与了东家SDL和devsecops建设、iso27701和iso29151认证、数据加解密项目、GDPR合规项目等工作，遂在此分享一下相关工作的思考，同时希望得到各位大佬的指正，共同学习进步。

那如何在安全需求评审中融合数据合规呢？我们今天先来看看需要业务研发团队提交的信息。

0x01安全需求评审的内容

在《信息安全技术 个人信息安全规范》中，规定了在某些场景下，需进行个人信息安全影响评估，包括信息所用于的目的、根据评估应当采取的安全措施等等。在GDPR中，第35条提出了企业要进行DPIA的要求，DPIA的步骤一般分为3步，即项目负责人填写初步清单、是否进行DPIA评估、实施DPIA。这其中包括是否收集个人信息、使用目的、处理方式、数据主体权利的履行措施、保护措施等等。iso27701中，7.2.5条说明需进行隐私影响评估，其中7.2.8中说明应当涉及将被处理的个人信息类型、处理目的、相关信息描述、接收者类别、技术及组织安全措施等等。

可以看出DPIA的进行其实和安全需求评审的实施阶段类似，都是在项目立项或者需求阶段进行介入；其次，安全需求评审往往也需要了解业务涉及的敏感级别、业务的目的、处理方式、安全措施等情况，在内容上和DPIA需要研发所提供的信息有重合的地方，因此两者可以合并在一起进行。

关于在安全需求评审阶段进行DPIA，应当如何设计各个模块，可以参考各个主要法律法规和标准。在《个人信息安全规范》中，分别从个人信息的收集、存储、使用、共享等个人信息全生命周期各个环节进行要求。在《数据安全能力成熟度模型》中，也主要通过数据的全生命周期各个阶段进行指导。而GDPR中，更多使用的是“处理”这一概念，涵盖所有围绕个人信息的操作，更侧重于数据主体的权利，这些权利不是针对数据全生命周期的某一特定环节。

由此可以看出，我们可以从个人信息全生命周期各个阶段和数据主体权利来设计各个模块。

除了相关法律法规、国家标准以外，对于某些细化类别，我们也可以参考相关配套标准或者实践指南进行设计。《app收集使用个人信息自评估指南》可以看做是对《个人信息安全规范》中的个人信息收集和信息主体权利部分的一种细化，实践的具体要求。《个人信息告知同意指南》也具体指出了很多细化场景。GDPR因为刻意避免提出相关技术措施，因此对于实施细节，说明较少，往往是通过第29条工作组或者监管机构如英国ICO的解释进行指导，如cookies的合规、同意的解释等等。

最后，在明确了相关内容后，根据之前在SDL建设和devsecops建设中的经验，设计问答形式的表格，让研发填写长篇大论，往往会造成更多的沟通成本，这往往是安全需求评审阻碍devsecops建设的一大瓶颈。因此，应当更多的让研发做选择题，并通过选择题，让部分需求评审能够自动化（不要指望完全自动化）。

0x02需要业务研发团队提供的信息

在《个人信息安全规范》和GDPR中，都提到了收集个人信息的两种方式，即直接收集个人信息和间接收集个人信息。其中，《个人信息安全规范》中提到，如果产品或服务的提供者提供工具供个人信息主体使用，提供者不对个人信息进行访问的，则不属于个人信息收集。规范同时举了个例子，即采集的信息不回传给软件提供者，则不算个人信息收集。这里要注意一下，在GDPR中，并没有发现类似规定，在GDPR中，这类也算是信息处理的一种方式。

数据采集或者个人信息的采集，一般需要了解三个部分：采集了什么数据，采集的目的是什么，如何采集的。但是根据整个安全需求评审的逻辑来看，应该是先看当前版本主要开发了什么新的业务模块，为了实现这个业务模块需要哪些数据（是否包含个人信息），这些数据是如何获取的。

（1）当前涉及的业务模块

2020年版《app收集使用个人信息自评估指南》评估点二“是否明示收集使用个人信息的目的、方式和范围”中，要求完整列举，不允许使用“等”“例如”等方式。对于“目的”列出了相关举例，如下所示：

地图导航，网络约车，即时通讯，网络支付，新闻资讯，网上购物，短视频，快递物流，餐饮外卖，交通票务，婚恋相亲，房屋租售，求职招聘，网络借贷等。

根据《信息安全技术 移动互联网应用程序收集个人信息基本规范》，其中列出了一系列业务功能，如下所示：

以上业务，需根据各公司实际情况进行微调或者合并（比如将涉及较少的业务功能统一先归并到“其他”里面）。

在GDPR当中，并非如上通过业务功能进行要求，而是从对数据主体所享有的基本权利产生影响的角度出发，提出一系列处理方式类型。具体如下：

同时，要考虑到不同法律法规和标准的适用范围，因此还需要了解该功能模块面向服务对象的范围。

可使用该服务模块的用户所在国家范围

可使用该服务模块的用户的年龄范围

提供该服务的控制者主体所在国家范围

（2）该功能模块需要的数据

在法律法规或者标准中，对于个人信息的定义较广，尤其是GDPR，其第4条规定，“个人数据”是指已识别到的或可被识别的自然人的所有信息。所以，完全让研发团队说明自己采集了哪些个人信息，势必会漏掉很多在常见语境下，不被认为是“个人信息”。因此，需要给研发团队列明相关个人信息和个人敏感信息。

《个人信息安全规范》划分了个人信息和个人敏感信息两大信息。

表1个人信息举例

表2个人敏感信息举例

GDPR中，第9条规定了在GDPR管辖下的敏感个人数据，包括8类：

种族或民族出身

政治观点

宗教或哲学信仰

工会会员资格

基因数据

生物学数据

健康有关的数据

性生活或性取向数

同时，在《个人信息安全规范》和GDPR中，都规定了收集或者处理个人信息的合法理由或者说是征得数据主体同意的例外情况，因此，在进行该业务模块实现时，可以让研发项目团队提供需要该数据的原因。

这里要说明的是，从《个人信息安全规范》和《个人信息告知同意指南》可以看出，在采集个人信息时，应当征求数据主体的同意，然后再规定了可以不征求同意的情况。但是从GDPR可以看出，以及相应判例来看，“同意”并不是万能的，不能所有的采集都使用“同意”机制，因为“同意”是有“撤回同意”操作的合法理由必须适用适当。

根据《个人信息安全规范》，需要说明的原因包括：

具体示例，可以参考《个人信息告知同意指南》规定的相关不需取得同意的例外情形。

根据GDPR第6条规定，需要说明的原因包括：

同时，为了满足PECR中的cookies政策，在数据采集中，应当再增加一部分，即cookies收集部分。需研发项目组提交的信息包括：

cookie名称

cookie所有者（比如是公司自己还是第三方统计分析的，如百度、谷歌）

cookie类别（绝对必要、优化类、分析类、隐私偏好）

cookie目的

（3）采集的方式

根据《个人信息告知同意指南》第5.1条，可以将个人信息采集方式细化如下：

这里再次涉及到《个人信息安全规范》和《个人信息告知同意指南》中，指出的例外情况。

后续，会根据以上收集的信息，对如何提出安全评审的要求进行分享。