最近数月以来，两个法律领域接连发生了重大的、引人注目的新进展。一是刑事合规领域，历经了三年以上漫长蛰伏，深圳一声春雷，突然自最高检首席大检察官亲自挂帅，到六地基层检察院承担企业合规不起诉试点任务，再到浙江全省检察院探索企业合规不起诉制度。刑事合规，一下子从学界照进了现实。甚至各地已经纷纷出现“企业合规不诉首案”。另一则是数据法领域，《个人信息保护法（草案）》已经公布，《网络安全法》和《网络安全等级保护条例》、《关键信息基础设施安全保护条例》等法律法规相信也是指日可待。此外还有《APP违法违规手机个人信息行为认定方法》、《个人金融信息（数据）保护试行办法（初稿）》等既成、待成规范性文件的密集出台，再加上各地公安机关频频出击打击数据犯罪、各级媒体纷纷关注数据法律问题，数据侵权、违法和犯罪这些以前貌似高深的、前沿的“高科技案件”、“新型案件”“旧时王谢堂前燕，飞入寻常百姓家”成为了社会热点和泛法律行业关注的重点。
两相叠加——“数据企业刑事合规”的议题，就水到渠成地出现了。本文将从数据生命周期、公司组织架构、企业管理流程等三个不同角度观察审视这一工作领域，限于篇幅，只能是浅尝辄止地做一些粗略的、概要性的介绍，至于法律法规的精细辨析和工作实践的具体操作，鉴于笔者缺乏用简明的笔触描述复杂问题的能力，只能留待其他场合再向诸位读者方家请教。
一、数据生命周期中的刑事合规体现
从数据的生命周期去审视和安排一个数据企业的刑事合规工作可能是法律工作者最自然的想法。这可能是因为法律条文所给予的强烈暗示，例如2019年国家互联网信息办公室通过的《儿童个人信息网络保护规定》第三条 在中华人民共和国境内通过网络从事收集、存储、使用、转移、披露儿童个人信息等活动，适用本规定。2020年全国人大公布的《个人信息保护法（草案）》第四条第二款 个人信息的处理包括个人信息的收集、储存、使用、加工、传输、提供、公开等活动 等等大量条文都列举了数据生命周期的不同环节并表示该类环节受到法律约束。同时，数据行业广泛应用的数据安全、数据治理模型也经常选用数据生命全周期作为审视和执行的维度（例如微软提倡的DGPC框架、DSMM模型等）。因此，首先选取数据全生命周期作为线索串联数据企业刑事合规工作，是符合法律行业和数据行业思维习惯，易于融入双方操作框架的方式。 刑事合规工作在数据全生命周期维度中的体现，主要可以表现为各个环节的规范文件体系和标准操作步骤（SOP）。试举一例：将数据生命周期分解为采集、储存、运行、传输、升级、删除六个部分。在采集环节，首先考虑常见刑事风险，如侵犯公民个人信息罪、破坏计算机系统罪、非法获取计算机系统数据罪、侵犯商业秘密罪、帮助信息网络犯罪活动罪等；然后依照各个犯罪法律规定的构成要件和现实司法实务中的认定情况等对采集数据的目的、范围、方式，采集数据所获的授权内容、授权的获取方式等焦点问题进行审视，构建公司内部的规范文件体系、确定标准操作流程、设置监督检查清单并做好存证存照工作。在存储环节，重复上述步骤，从法律分析开始，除了刚才提及的罪名，还有拒不履行网络监管义务罪等在存储环节可能涉及的犯罪；关注存储数据的介质、存储的地点、存储的时间、对存储数据的访问权限、存储数据的安全保护、是否需要进行匿名化处理等问题。在运行环节，要审视访问和使用数据的目的、运行过程中的数据安全、授权所允许的使用和运行方法以及在必要时向数据主体通知数据运行使用情况等问题。在传输环节，要充分考虑传输数据的对象、对象的数据安全保护能力、对象的合规程度、传输的目的、传输的方式、传输过程中的安全保障等问题。在数据的升级环节，要考虑升级的目的、数据主体修改权的满足、升级过程中的数据安全、必要时对数据主体进行通知等问题。在数据的删除环节要考虑随着服务提供的解除或停止而删除数据、随着服务技术升级而删除不必要的数据、响应数据主体的删除权而删除数据等情况，还要甄别删除原始数据及其衍生数据的范围，对于不能彻底删除的数据的隔离，以及为了保障如刑事调查、公共卫生、公共安全等特殊原因不应删除的数据的恰当保护和必要时通知数据主体删除情况等问题。 总而言之，这是一个以数据全生命周期为线索，以法律条文为依据，目光在法律规定和业务操作间来回穿梭，以织就一张数据全生命周期刑事合规保护网的过程。
二、公司组织架构中的刑事合规体现
企业合规风险治理的一大要务是建立起专门的、独立的合规组织体系。但这里我们先放下这一点不谈，因为这是一个完全需要另起炉灶专章论述的问题。而且从目前国内的企业合规实务工作来说，在建设完整、有效的合规组织体系之前，必然需要经历一个依托现有企业结构承载合规任务的过渡阶段。所以接下来我们从企业尤其是数据行业企业除合规部门外的其他各个职能部门的角度观察一下刑事合规工作的分解。同时，下文也将暂且刻意回避掉法务部门和人事部门，先挑选几个围绕企业提供产品和服务的部门来讲。
在上一节中，以数据的全生命周期为线索，我们串联了一张合规网络。但这张网络有两个非常明显的风险敞口：其一是数据采集前的刑事风险。注意到这一点，我们马上就可以发现我们的视野不能仅仅局限于技术开发部门，在“程序猿”开始“种田”之前，还有产品“攻城狮”作为开端。而产品设计的环节，当然必须为刑事合规工作所覆盖。例如两个根本性的问题：该产品或服务的商业模式是否为现行法律所允许？该产品或服务的应用场景是否可能具有违法性？又如一些具体的产品设计问题：该产品的UI界面是否清晰、明确地向用户提示重要的法律问题、《隐私条款》等协议文件是否易于查找和阅读、是否提供客户简洁地实现数据权力的通道……当产品设计通过合规考验之后，技术开发部门则需要通过合法地、风险可控地方式进行需求实现。然而这又是一个深水区，因为计算机技术和法律技术都是高度专门化的，早已形成了各自具有特色的话语体系、习惯方法等城高池深的壁垒。这给两个行业群体的相互沟通、相互理解制造了极大困难。例如笔者曾在其他文章中举例过的《最高人民法院、最高人民检察院关于办理侵犯公民个人信息刑事案件适用法律若干问题的解释》第三条第二款中对于“不能复原”一词的不同理解，就会造成迥然不同的结果。一种解释是计算机技术从业者可能更加偏爱的解释，即将“能否复原”视为一个密码学问题或者说一个数学问题。但司法机关的执法人员将之解释为“在任何情况下均不可复原”，也就是说即使重标识攻击者引入独立的外源数据的情况下仍不能复原，才达到“不能复原”的标准。这样的理解也并没有超出司法解释用词的文义所允许的范围。最后的结果是：包括司法工作者在内的法律从业者大多对产品需求的技术实现只能做到一知半解甚至连蒙带猜，而计算机技术员们对法律要求也是云里雾里、不甚了了。如此一来，“具体的某个需求的某种实现手段是否合法？”就成了一个双方共同的难题。拉通程序员和法律工作者尤其是司法工作人员的话语体系，是技术开发部门刑事合规工作的一项突出重点。篇幅关系我们放过开发部门，到隔壁运维部门看一看。运维部门的工作职责使得他们既需要与供应商、客户亲密接触，又需要对产品、系统进行大量技术操作。这种属性让他们成为了刑事合规工作中值得关注的部门。除了与开发部门相类似的技术面的风险防控问题，还有在运维过程对异常状况的监测、分析，与客户接触中偶然了解到的异常信息的反馈、处理等需要有方法、有章法供运维人员倚之以开展相关工作。我们再到商务部门和财务部门走马观花一番。这两个部门除了承担着传统的合同审核、会计合规等任务之外，就刑事合规方面来说，尤为值得注意的是应当梳理两部门工作中会遇到的，对判断企业是否“知道或应当知道有犯罪行为发生或可能发生”会产生明显影响的部分。例如合同中的采购或销售价格、支付方式等条款是否与市场价格、行业惯例等有大幅偏差等等。再接下去是运营部门，首先涉及到的是日常运营中对异常数据的监测和分析，警惕可能与违法犯罪活动特征类似的情形等，再者就是一些宣发活动中的内容、方式和渠道选择等问题，需要对法律规定和实务认定有正确把握。最后不得不提到的是市场销售部门，销售部门在刑事合规工作中的地位也很重要。一方面是与客户背景调查相关的大量工作，客户经理是这些工作最直接的承担者。对客户进行筛选的checklist中应当包含哪些法律问题，在各问题项不能典型地、完全地满足的情况下应当如何抉择，都是客户经理的新考验。另一方面是在与客户进行商务往来过程中可能偶然得知的各种信息，这些信息是否具有法律含义，甚至是否提示了某种可能的违法犯罪活动的存在？客户经理对于这些信息的敏感性，以及如果接触到这些信息后的应对机制，都是刑事合规工作在销售部门的具体体现。这也就将我们带回了本节开头提到的话题，以数据生命周期为线索的刑事合规工作的另一风险敞口：数据或数据产品转移到下游客户之后仍可能继续产生刑事风险，需要有部门来采取适当防控措施。
还有很多部门目前的本职工作与刑事合规工作的连接点，此处就不及详述了，留在其他场合再行探讨。总而言之，以企业的组织结构为构架，也是刑事合规工作设计、展开的另一线索。
三、企业管理流程中的刑事合规体现
如果说组织架构是一个企业的骨架，那么管理流程就是企业的循环系统。空有骨架的躯壳没有生命，企业的经营活动也必须通过各个管理流程来驱动。那么刑事合规工作要成为企业日常经营活动的一部分，也就必须嵌入企业的各个、各级流程之中，才能有机地与其他工作结合在一起，共同组成企业的健康躯体。于是我们就找到了第三个观察、安排、执行刑事合规工作的维度：企业的管理流程角度。 这里我们以三个特别基本的流程为例来简单看一下刑事合规工作的浸润。 首先是IPD（Integrated Product Development），它规定着产品集成开发过程中各个参与部门的工作程序，控制着业务节点。如何将产品定义、开发过程中的刑事合规任务分配到各个流程环节中去，即是合规工作者需要解决的问题。如前述产品部门需要对商务模式的合法性进行的考量和论证，是否应当分配到概念阶段，在概念阶段的何处设置怎样的控制点？又如需求管理层面对各种需求的合法性的分析又以怎样的形式在哪个流程节点进行等等。当然也不必说开发阶段、验证阶段中的各项操作的合法性问题，技术规划、技术平台开发层面的合法问题等等时序的、分层的合规工作的分解和展开。 再粗略瞥一眼LTC（Lead to Cash）流程。从市场观察开始，就存在合法性甄别的问题。例如金融行业大量需要类个人征信信息或者个人信用评估服务，这个市场是否适合数据企业进入？到了销售线索的收集环节，就涉及到潜在客户的背景、具体应用场景、服务客户群的法律风险分析等问题。至合同谈判、签署的部分，则要注意合同条款对业务数据使用目的、使用方式的授权和约定等关键问题的把握。收付款环节有支付方式等要素需要考虑。及至合同交付和关闭，还有大量数据安全和最后数据删除等工作需要在流程中找到立足之地。 最后谈几句ITR（Issues to Resolve）流程，首先这个流程显然承担了数据安全方面的一大部分责任，尤其是在数据安全事件发生时，技术层面和人员层面的保障需要ITR流程予以事先考虑。对客户服务需求的合法性、满足需求的方式的合法性也要有必须的分析、决策环节。此外还不能忘记上一节提到运维部门日常工作中接触到的具有法律意义的异常事态发生时，ITR流程应该允许运维人员有处理问题的程序模板。
数据企业刑事合规服务是两个新兴领域的交叉问题，理论和实践都在摸着石头过河，而且是摸着石头却速度很快地冲过河，于是谈起这个话题常有意犹未尽之感，又有“以其昏昏，使人昭昭”的惭愧之意。只是篇幅有限，实在不允许笔者继续讲下去了，仅以上述拙见，贻笑大方之家。
作者：上海靖予霖律师事务所 、辩护技能研究部副主任、辩论队教练 刘笛
