个人信息委托处理、共享、转让和公开披露
个人信息委托处理、共享、转让和公开披露，均属于个人信息的对外提供。为了满足合作业务开展的需求，个人信息的对外提供时常发生。与此同时，对外提供个人信息，相较于网络运营者内部处理个人信息，网络运营者的直接掌控能力明显较弱，这也导致了在对外提供环节，个人信息泄露、个人信息违规使用等个人信息安全事件屡屡发生，造成重大损失。因此需要对个人信息对外提供环节加以规范，尽可能地降低个人信息安全事件发生的风险。
（一）个人信息主体同意及例外情形
1.个人信息主体同意
《网络安全法》第42条对个人信息对外提供进行了原则性的规定：“……未经被收集者同意，不得向他人提供个人信息。但是，经过处理无法识别特定个人且不能复原的除外……”该条明确了对外提供个人信息的合法性基础，即经个人信息主体同意。
《App违法违规认定方法》第5条也规定了不得未经同意向他人提供个人信息的要求，其中第5.1条规定不得“既未经用户同意，也未做匿名化处理，App客户端直接向第三方提供个人信息，包括通过客户端嵌入的第三方代码、插件等方式向第三方提供个人信息”，第5.2条规定不得“既未经用户同意，也未做匿名化处理，数据传输至App后台服务器后，向第三方提供其收集的个人信息”，第5.3条规定不得“App接入第三方应用，未经用户同意，向第三方应用提供个人信息”。
对于用户同意的方式和内容，这里宜理解为明示同意，具体操作方式为通过个人信息保护政策、个人信息查询使用授权书等授权文本告知用户对外共享、转让、公开披露个人信息的目的，涉及的个人信息类型，接收方类型或身份，各自的安全和法律责任，并通过用户手动点击确认个人信息授权文本等主动的意思表示来获得用户的明示同意。对于这里的接收方类型或身份，能够列明具体的接收方名称更好，如考虑到业务合作方动态变化，则至少应说明接收方的机构类型，如银行、物流公司、行业协会等，避免直接使用“提供给第三方”等类似过于宽泛的表述。
需要指出的是，相较于征求意见稿，《个人信息安全规范》新增了对个人生物识别信息共享、转让的要求。《个人信息安全规范》第9.2i）条规定，个人生物识别信息原则上不应共享、转让。因业务需要，确需共享、转让的，应单独向个人信息主体告知目的、涉及的个人生物识别信息类型、数据接收方的具体身份和数据安全能力等，并征得个人信息主体的明示同意。从要求看，不共享、转让个人生物识别信息为原则，确需共享、转让需符合以下四个条件要求：（1）必要性，确因业务需要。也就意味着，共享转让个人生物识别信息需要经得起必要性的检验，在面临监管检查和公众质疑时需要有足够的业务需要作为支撑。（2）告知方式，单独告知。（3）告知内容，告知目的、涉及的个人生物识别信息类型、数据接收方的具体身份和数据安全能力等。（4）同意方式，明示同意。从理解适用角度，可供参考的模式为，如确需对外共享、转让个人生物识别信息的，在个人生物识别信息保护规则或说明中告知用户前述需要告知的内容，并通过征得用户对个人生物识别信息规则的明示同意的方式，来满足这里对于共享、转让个人生物识别信息的明示同意要求。但是否确切能够满足《个人信息安全规范》的要求，还有待实践的进一步探索和监管部门的进一步意见。
此外，《个人信息安全规范》第9.3条对收购、兼并、重组、破产时的个人信息转让进行了特殊规定，要求网络运营者发生收购、兼井、重组、破产等变更时，网络运营者应：a）向个人信息主体告知有关情况；b）变更后的网络运营者应继续履行原网络运营者的责任和义务，如变更个人信息使用目的时，应重新取得个人信息主体的明示同意；c）如破产且无承接方的，对数据做删除处理。根据该条，在收购、兼井、重组、破产等情形下，并非当然要求个人信息主体明示同意，而是要求告知有关情况，只有后续网络运营者变更个人信息使用目的，才需要重新取得个人信息主体的明示同意。
2.征得个人信息主体同意的例外
前述《网络安全法》第42条，在明确要求个人信息主体同意的基础上，为了推动大数据的发展，设置了俗称的“大数据条款”，即经过处理无法识别特定个人且不能复原的除外，也就是说该等信息的对外提供无需征得个人信息主体的同意。
《个人信息安全规范》第9.5条明确了共享、转让、公开披露个人信息时事先获得同意的例外情形，具体包括：a）与网络运营者履行法律法规规定的义务相关的；b）与国家安全、国防安全直接相关的；c）与公共安全、公共卫生、重大公共利益直接相关的；d）与刑事侦查、起诉、审判和判决执行等直接相关的；e）出于维护个人信息主体或其他个人的生命、财产等重大合法权益但又很难得到本人授权同意的；f）个人信息主体自行向社会公众公开的个人信息；g）从合法公开披露的信息中收集个人信息的，如合法的新闻报道、政府信息公开等渠道。
《数据安全管理办法（征求意见稿）》第27条也规定了对外提供个人信息征得同意的例外，“网络运营者向他人提供个人信息前，应当评估可能带来的安全风险，并征得个人信息主体同意。下列情况除外：（一）从合法公开渠道收集且不明显违背个人信息主体意愿；（二）个人信息主体主动公开；（三）经过匿名化处理；（四）执法机关依法履行职责所必需；（五）维护国家安全、社会公共利益、个人信息主体生命安全所必需”。相较于《个人信息安全规范》的规定，该条删减了很多情形。具体适用，建议关注后续正式版的相关规定。
（二）数据接收方的尽调和约束
在数据对外提供前，对数据接收方的尽调是必不可少的环节，也是网络运营者有效防范风险和减轻责任承担的有利举措。通过尽调，评估数据接收方的身份、数据接收方的数据安全能力和可能产生的个人信息安全风险。在尽调的基础上，根据尽调结果采取有效的约束措施，能够更好地规范数据接收方的数据处理行为，降低潜在的安全风险。
1.数据接收方的尽调
对数据接收方的尽调，可以通过以下方式进行：
（1）对数据接收方进行必要的网络检索，检索内容包括个人信息方面的涉诉情况、行政处罚情况、通报情况、新闻报道情况和用户投诉情况；
（2）要求数据接收方提供数据安全能力相关方面的证明，提供数据安全相关制度并说明执行情况，说明个人信息保护方面的技术措施和安全措施，说明是否出现过数据安全风险事件以及处理情况。
2.数据接收方的约束
对数据接收方的约束，主要包括约束方式和约束内容：
（1）约束方式
从约束方式看，《个人信息安全规范》第9.1d）条和第9.2d）条分别规定了委托处理和共享、转让个人信息情形下对数据接收方的约束要求，其约束方式均为通过合同等方式规定数据接收方的责任和义务。实践中常见方式为合同条款约定和签署单独的承诺函，前者适用于后续新增签署的合同，后者适用于合作合同已经签署但未约定该等内容或者想要强化个人信息保护的情形。
（2）约束内容
前述《个人信息安全规范》第9.1d）条和第9.2d）条强调约束的内容为数据接收方的责任和义务，具体来说，建议明确约定：1）数据接收方应采取的安全措施和技术措施；2）应合法合规、根据双方的约定和个人信息主体的授权范围处理个人信息；3）违法违规或违约处理个人信息应采取的补救措施；4）在个人信息面临安全风险或威胁时应采取的补救措施；5）网络运营者享有的约束和监督的权利以及有权采取的具体措施；6）发生个人信息安全事件时数据接收方应向个人信息主体和网络运营者承担的赔偿责任等。
（三）对外提供的安全措施
《个人信息安全规范》第6.3a）条规定，传输和存储个人敏感信息时，应采用加密等安全措施。注：采用密码技术时宜遵循密码管理相关国家标准。
对外提供个人信息，在传输过程中的安全措施必不可少，以防止在传输过程中被攻击、被窃取等安全事件的发生。相较于征求意见稿，《个人信息安全规范》新增了“采用密码技术时宜遵循密码管理相关国家标准”的注的要求。按照该等国家标准执行有助于规范密码技术的使用、提高密码的防护能力，更好地保障个人敏感信息的安全。《密码法》已于2020年1月1日生效，其第22条强调了建立和完善商用密码标准体系的要求、第24条直接指出了：“商用密码从业单位开展商用密码活动，应当符合有关法律、行政法规、商用密码强制性国家标准以及该从业单位公开标准的技术要求。国家鼓励商用密码从业单位采用商用密码推荐性国家标准、行业标准，提升商用密码的防护能力，维护用户的合法权益。”可以看出，密码管理相关国家标准的重要性。企业应予以学习、研究和应用。
（四）对外提供的记录
准确记录个人信息对外提供情况，有助于内部核查的顺利开展，也有助于应对监管核查。同时，若不幸发生安全事件，能够快速回溯对外提供情况，有助于进行情况核实和责任划分。
《个人信息安全规范》第9.1e）条规定了委托处理个人信息情形下的记录要求，“应准确记录和储存委托处理个人信息的情况”。第9.2e）条规定了个人信息共享、转让情形下的记录要求，该要求更加细化，“准确记录和存储个人信息的共享、转让情况，包括共享、转让的日期、规模、目的，以及数据接收方基本情况等”。第9.4d）条规定了个人信息公开披露情形下的记录要求，“准确记录和存储个人信息的公开披露的情况，包括公开披露的日期、规模、目的、公开范围等”。
对于这里的数据接收方基本情况，建议将对数据接收方的尽调结果以书面形式呈现并作为存档。此外，建议准确记录对外提供个人信息的操作人员，方便后续的管理和追踪。
（五）数据接收方的持续监督
数据接收方的约束并非一蹴而就，需要持续监督，方能及时掌握数据接收方处理个人信息和个人信息安全保护相关方面的动态，并及时根据不同的动态采取相应的措施。
根据《个人信息安全规范》第9.1f）条和第9.2f）条，在委托处理和共享、转让个人信息情形下，网络运营者应对数据接收方采取如下持续监督措施：网络运营者得知或发现数据接收方未按照委托要求或违反法律法规要求或双方约定处理个人信息的，应立即要求数据接收方停止相关行为，且采取或要求数据接收方采取有效补救措施（例如更改口令、回收权限、断开网络链接等）控制或消除个人信息面临的安全风险；必要时网络运营者应解除与数据接收方的委托或业务关系，并要求数据接收方及时删除从网络运营者获得的个人信息。
从上述要求，可以再次看出在对数据接收方进行约束时，通过合同条款、承诺函等方式，约定数据接收方违法违规或违约处理个人信息应采取的补救措施，在个人信息面临安全风险或威胁时应采取的补救措施和网络运营者享有的约束和监督的权利以及有权采取的具体措施的重要性。
从具体执行角度，建议定期对数据接收方进行必要的网络检索，检索内容包括个人信息方面的涉诉情况、行政处罚情况、通报情况、新闻报道情况和用户投诉情况。同时，可行条件下不定期进行现场考察，实地了解数据接收方最新的数据安全能力状况和个人信息处理活动的实际开展情况。
（六）第三方接入管理
第三方接入管理，主要指对接入具备收集个人信息功能的第三方产品或服务的管理，如接入小程序、软件开发工具包（SDK）等。其中，随着App违法违规专项治理行动的开展，SDK的使用和安全问题浮出水面，成为监管和公众关注的重点。
1.SDK概述及存在的安全问题
（1）SDK概述
根据《软件开发包（SDK）安全与合规白皮书》，SDK是Software Development Kit的缩写，即软件开发工具包。简单来看，它是辅助开发某一类应用软件的相关文档、范例和工具的集合。对App来说，为了提高开发效率，可以将某项功能交给第三方来开发，第三方服务提供商将服务封装为工具包（即SDK）供开发者使用。目前，SDK类型主要包括：第三方登录分享类、支付类、推送类、广告类、数据统计分析类、地图类、风控插件以及一些基础库等。常见的SDK有高德地图、微信支付、支付宝支付、小米推送、友盟、TalkingData等。
根据南都个人信息保护研究中心发布的《常用第三方SDK收集使用个人信息测评报告》，受测的60款App平均每款使用19.3个SDK，足以看出App使用SDK的普遍性。而究其原因，《软件开发包（SDK）安全与合规白皮书》指出主要包括三方面：一是接入第三方SDK可以大幅度提升使用者的开发效率，明显降低开发成本；二是SDK的易用性和灵活性较强，为App提供流畅及定制化的用户体验；三是SDK能够帮助提高App的兼容性，扩大用户使用范围。
（2）SDK存在的安全问题
SDK的广泛应用，带来便利的同时也带来了很多安全问题。《软件开发包（SDK）安全与合规白皮书》指出，SDK主要存在如下安全问题：
一是SDK自身安全性不容乐观。已经发现的SDK安全漏洞包括http误用、SSL/TLS不正确配置、敏感权限滥用、身份识别、本地服务、通过日志造成信息泄露、开发人员失误等。[3]
二是SDK成为病毒传播的新途径。不法分子通过制作、发布、吸引App嵌入含有恶意代码的第三方SDK，造成短时间、大范围的病毒传播和感染；并且使用代码分离、动态代码加载等技术，能够实现远程控制恶意代码的执行，具有很强的隐蔽性和对抗杀毒软件的能力，如此前曝光的“寄生推”SDK。
三是第三方SDK隐蔽收集个人信息问题逐步显现。SDK收集了哪些个人信息，用户往往难以感知，App开发者也未必完全知悉。该问题最为常见，也是当前整治的重点问题。2019年12月20日，App专项治理工作组曾发布《关于61款App存在收集使用个人信息问题的通告》，其中涉及44款App在既未经用户同意，也未做匿名化处理的情况下，通过客户端嵌入的SDK向第三方提供用户设备IMEI号、地理位置等个人信息的违规问题。
2.第三方接入管理的要求及实操建议
（1）相关规定
《个人信息安全规范》第9.7条明确了第三方接入管理的要求，具体包括：
a）建立第三方产品或服务接入管理机制和工作流程，必要时应建立安全评估等机制设置接入条件；
b）应与第三方产品或服务提供者通过合同等形式明确双方的安全责任及应实施的个人信息安全措施；
c）应向个人信息主体明确标识产品或服务由第三方提供；
d）应妥善留存平台第三方接入有关合同和管理记录，确保可供相关方查阅；
e）应要求第三方根据本标准相关要求向个人信息主体征得收集个人信息的授权同意，必要时核验其实现的方式；
f）应要求第三方产品或服务建立响应个人信息主体请求和投诉等的机制，以供个人信息主体查询、使用；
g）应督促第三方产品或服务提供者加强个人信息安全管理，发现第三方产品或服务没有落实安全管理要求和责任的，应及时督促整改，必要时停止接入；
h）产品或服务嵌入或接入第三方自动化工具（如代码、脚本、接口、算法模型、软件开发工具包、小程序等）的，宜采取以下措施：1）开展技术检测确保其个人信息收集、使用行为符合约定要求；2）对第三方嵌入或接入的自动化工具收集个人信息的行为进行审计，发现超出约定的行为，及时切断接入。
（2）实操建议
对于第三方接入，建议参照前述《个人信息安全规范》第9.7条采取相应举措。需要指出的是，相较于征求意见稿，《个人信息安全规范》删去了“妥善留存、及时更新第三方产品或服务建立响应个人信息主体请求和投诉等的机制”的要求。从放宽了第三方接入管理中对于核验第三方征得个人信息主体同意的方式的要求看，只有在必要时企业才需要进行核验，而不再要求必须核验，一定程度上减轻了企业的负担。对于“必要”的理解，宜理解为收到用户对于第三方未经同意收集使用个人信息的投诉、第三方被曝出违法违规收集使用的相关新闻或者监管通报第三方存在违法违规收集使用个人信息等情形。从删去“妥善留存、及时更新第三方产品或服务建立响应个人信息主体请求和投诉等的机制”的要求看，减少了可能产生的歧义理解和操作中的困难，将确保个人信息主体能够表达权利请求和投诉等的要求，强化在了第三方这一主体身上。
此外，对于SDK接入，除前述举措外，建议在个人信息保护政策中，列明接入的SDK名称、该等SDK收集使用的个人信息类型以及收集使用目的。要做到该点，需要全面梳理已经接入的全部SDK，并与SDK服务商充分沟通或通过SDK服务商公示的服务条款、个人信息保护政策等相关文本获取该等信息。此外，可供借鉴的做法为，部分App已经将接入的SDK的服务条款、个人信息保护政策等相关文本的链接放置在App个人信息保护政策的最后，方便用户快速查看和了解接入的SDK的具体情况。
（七）公开披露个人信息的特殊要求
公开披露个人信息，受众面广，无法有效掌握公开后的个人信息面临什么样的处理活动，因此，在公开披露场景下，个人信息面临的安全风险较高。这就需要赋予公开披露个人信息特殊的要求。
《个人信息安全规范》第9.4f）条要求，不应公开披露个人生物识别信息。第9.4g）条要求“不应公开披露我国公民的种族、民族、政治观点、宗教信仰等个人敏感数据的分析结果”。随着人脸识别、指纹支付、指纹解锁等技术的广泛应用，个人生物识别信息的泄露可能对个人财产安全、手机使用、家庭门锁使用等造成较大的安全威胁。而第9.4g）条要求，主要在于防止该等个人敏感数据分析结果的公开披露，可能给国家安全、行政管理和社会稳定等造成安全威胁。需要指出的是，实践中最常见的公开披露部分个人信息主体的民族信息，如市管干部的任前公示会公示干部的民族、籍贯、出生年月、学历、现任职务和拟任职务等信息，属于民族信息的直接披露，不属于该条规制的民族信息的分析结果。
除前述要求外，公开披露个人信息时，宜对个人信息采取部分脱敏措施。以金融机构公布借款人逾期信息为例，在借款协议等相关协议文本中经常可见约定“借款人明确知悉并同意，在借款人逾期的情况下有权以任何方式公布借款人的逾期信息”或相类似的条款。对于该等情形，即使获得借款人的授权，也无法当然豁免公开披露个人信息原始信息的责任，宜采取身份证号隐去出生日期、住址公布到街道或村等部分脱敏的方式。
（八）对外提供个人信息的责任承担
对外提供个人信息，一旦发生个人信息安全事件，势必涉及责任承担的问题。对于不同情形下的责任承担，主要根据网络运营者的过错承担相应的责任，具体的规定如下：
1.个人信息共享、转让情形下的责任承担
根据《个人信息安全规范》第9.2g）条，因共享、转让个人信息发生安全事件而对个人信息主体合法权益造成损害的，网络运营者应承担相应的责任。
这里相应的责任取决于网络运营者的过错程度。如果网络运营者已经采取有效的约束措施，准确记录共享、转让情况，并且对数据接收方进行了持续监督，最重要的是能够出示充分的证据证明采取了前述措施，能够一定程度上为网络运营者减责。
2.个人信息公开披露情形下的责任承担
根据《个人信息安全规范》第9.4e）条，网络运营者应承担因公开披露个人信息对个人信息主体合法权益造成损害的相应责任。
在公开披露情形下，数据接收方为全体公众，不存在特定的数据接收方，因此如果侵犯个人信息主体合法权益，根据过错程度，由网络运营者承担相应责任。具体合规要求和建议之前已经进行说明，此处不再赘述。
3.第三方接入情形下的责任承担
根据《数据安全管理办法（征求意见稿）》第30条，网络运营者对接入其平台的第三方应用，应明确数据安全要求和责任，督促监督第三方应用运营者加强数据安全管理。第三方应用发生数据安全事件对用户造成损失的，网络运营者应当承担部分或全部责任，除非网络运营者能够证明无过错。
关于第三方应用发生的数据安全事件，该条对网络运营者采用过错推定原则，除非网络运营者能够证明其无过错，否则网络运营者应当向用户承担部分或全部责任。而要想证明无过错或者减轻过错，是否参照《个人信息安全规范》第9.7条和本书前述对于第三方接入的实操建议采取了相应举措，就显得尤为重要。