在欧盟拥有用户的软件企业应在2026年9月11日前建立的事件响应机制

欧盟的《网络韧性法》（Cyber Resilience Act，Regulation (EU) 2024/2847，以下简称CRA）已于2024年11月20日刊登于官方公报，并已正式生效。
原文：欧洲议会和欧盟理事会第2024/2847号条例

2024年10月23日

不过，这些义务的适用是分阶段进行的，在实务中首先生效的是自2026年9月11日起适用的第14条报告义务。虽然主要规定（如符合安全要求和CE标志等）自2027年12月11日起才开始适用，但仅针对漏洞和安全事件的报告义务将提前一年多开始实施。

也就是说，对于向欧盟市场提供软件的企业而言，截至本文撰写之时，剩余的准备时间不到两个月。本文将根据《CRA》的条款，梳理需要“报告什么”、“最迟何时”以及“向何处”进行报告，并说明从现在起应做哪些准备工作。

首先，本公司是否属于适用范围？

CRA的适用对象是“具有数字元素的产品（products with digital elements）”，其中广泛涵盖在欧盟市场作为商业活动提供的软件和硬件（第2条、第3条）。

无论是付费的软件包还是移动应用程序，还是免费分发的软件，只要存在盈利意图，都可能被视为“商业活动”。

需要注意的是云服务的处理方式。SaaS本身原则上不属于CRA的范畴，而是属于NIS2指令的范畴，但对产品功能不可或缺的远程数据处理（remote data processing）则属于CRA的适用范围（第3条第2款、前文第11项和第12项）。

例如，如果移动应用必须依赖公司自主开发的API或后端才能运行，那么该后端部分也将被视为产品的一部分。若贸然断言“我们使用的是云服务，因此与CRA无关”，这是非常危险的。

此外，承担报告义务的“制造商（manufacturer）”是指以自有品牌将产品投放市场的企业（第3条第13项）。即使是在欧盟境内没有据点的日本企业，只要向欧盟市场供应产品，也属于适用对象。

第14条：两阶段+最终报告，共三步

第14条规定的报告义务，主要针对两类情况。

第一项是“正在被积极利用的漏洞（actively exploited vulnerability）”。这指的是存在可靠证据表明恶意第三方确实利用了该漏洞的情况（第3条（42））。善意安全研究人员出于验证和报告目的所发现的漏洞，不属于此强制报告的范围（前文（68））。

第二点是“影响产品安全性的重大事件（severe incident）”。第14条第5款对“重大”的标准作了定义，包括：(a) 损害（或有能力损害）敏感或重要数据及功能的可用性、真实性、完整性或机密性的情况；(b) 导致（或有能力导致）恶意代码被引入或执行于产品或用户系统的情况。前文(68)中列举了攻击者在制造商的发布渠道中植入恶意软件的情况，即供应链攻击。

这两起事件的报告时间线都具有相同的结构。

起算点是“制造商知悉之时（becoming aware）”。虽然这并非侵权发生之时，但也不意味着在公司内部发现后，需等待经营决策而使时限暂停。考虑到节假日和时差因素，24小时这一期限实际上要求建立“在发现当天的同一时间启动报告流程”的机制。

应该向哪里报告？

报告将通过由ENISA（欧盟网络安全局）运营的统一报告平台提交，该机制确保报告同时送达负责的CSIRT（被指定为协调员的CSIRT）和ENISA（第14条第1款第3项、第16条）。

应向哪个成员国的CSIRT报告，由第14条第(7)款规定。如果在欧盟境内设有主要据点（即主要进行网络安全决策的据点），则向该成员国报告；如果欧盟境内没有据点，则按以下顺序确定：①经营该产品最多的授权代理人的所在国 → ②进口商的所在国 → ③分销商的所在国 → ④用户最多的成员国。

对于日本企业而言，如果等到紧急情况发生后才开始进行这一判定，肯定会超过24小时，因此必须在平时就确定好“本公司的报告对象是谁”。

不仅限于向主管部门报告：向用户通知的义务

第14条第8款规定，制造商在获悉存在被滥用的漏洞或重大安全事件后，必须向受影响的用户（必要时包括所有用户）发出通知，并告知用户可采取的缓解措施和纠正措施。应特别注意该条款明确指出：若制造商未能及时履行上述义务，CSIRT可代为向用户提供相关信息。这意味着，即使企业保持沉默，相关信息仍可能通过主管部门公开。

如违反规定

根据第64条规定，违反第13条、第14条规定的义务以及附件I中的强制性要求，可能被处以最高1,500万欧元或全球年度销售额的2.5%（以较高者为准）的罚款。其他违规行为最高可处以1,000万欧元或2%的罚款；向主管部门提供虚假或不完整信息最高可处以500万欧元或1%的罚款。此外，对于微型和小型企业，逾期未在24小时内发出早期预警的，不予处以罚款（前文(120)）。

比罚款更具威慑力的，是市场监管机构可能下达的产品停售和召回令。被排除在欧盟市场之外，对许多企业而言比经济制裁更令人痛心。

与现有报告义务的关系：首先确定GDPR下的“地位”

需要注意的是，CRA报告是在现有义务基础上“额外增加”的。此外，当涉及个人数据泄露时，企业的应对方式将根据其在GDPR中的身份——即控制者（controller）还是处理者（processor）——而发生重大变化。如果在此问题上存在模糊之处便遭遇突发事件，就可能弄错报告的接收方和截止期限。

• 本公司作为数据控制者的情况
  典型的情形是，公司直接向消费者提供应用程序或服务，并自行决定处理最终用户个人数据的目的和方式。

  在这种情况下，一旦发现个人数据泄露，公司有义务根据《通用数据保护条例》（GDPR）第33条的规定，原则上在72小时内直接向监管机构报告。此外，如果数据泄露可能对个人的权利和自由造成高风险，则根据第34条的规定，还必须通知数据主体本人。

• 本公司属于数据处理者的情况

  这是指在B2B SaaS或软件中，根据客户企业（即管理员）的指示处理其员工或客户的个人数据的情况。

  此时，负有向监管机构在72小时内报告义务的是作为控制者的客户方；而作为处理者的本公司根据第33条第2款规定的法定义务，是在发现数据泄露后，应在不合理延误的情况下通知控制者。

  虽然乍看之下似乎可以理解为“72小时与我们无关”，但实际操作远非如此简单。与客户签订的DPA（数据处理协议）中，往往规定了比法定“不得无故拖延”更短的具体通知期限（如24小时、48小时等），因此，为了确保自身能遵守72小时的规定，客户对处理方提出的时间要求往往比法定标准更为严格。

  对本公司签订的DPA中的通知条款进行盘点，并将最短的合同期限作为本公司的实质性SLA反映在操作规程中，这是作为数据处理者进行事件响应的起点。

此外，同一家企业根据产品线或功能的不同，同时兼具“管理者”和“处理者”的双重身份的情况并不少见（例如：在B2B SaaS主业务中担任“处理者”，而在处理公司内部营销或计费信息时则担任“管理者”）。由于处理遭泄露数据时，具体流程会根据当时所处的身份而有所不同，因此必须在数据映射阶段就将身份与相关数据进行关联。

此外，重要的是，CRA的义务与该《通用数据保护条例》（GDPR）中的地位无关。 由于CRA第14条规定的报告义务直接适用于“制造商”，因此“我们只是数据处理者，与监管机构的沟通由客户负责”这种说法在CRA框架下并不成立。即使是数据处理者，若发生影响本公司产品安全性的重大安全事件或存在被滥用的漏洞，本公司仍负有向CSIRT/ENISA报告的义务。

因此，在同一事件中，多个报告触发条件可能同时存在。

• CRA第14条：影响产品安全 → 向CSIRT/ENISA提交24小时、72小时及最终报告（无论立场如何，均属制造商的义务）

• 《通用数据保护条例》（GDPR）第33条：个人数据泄露 → 若为数据控制者，须在72小时内向监管机构报告；若为数据处理者，须立即向数据控制者报告（+数据保护机构（DPA）的合同期限）

• 《通用数据保护条例》（GDPR）第34条：高风险的个人数据泄露 → 作为数据控制者，应向数据主体发出通知

• 《NIS2指令》：当企业属于云服务提供商等《NIS2》适用对象时，其报告义务

由于报告对象、期限和格式各不相同，如果在事件应对规程中不设置“该事件对应哪些法律法规或合同中的哪些报告义务”的判定要点，现场工作肯定会陷入混乱。

现在应该做的准备工作

根据条文推算，截至9月11日，至少应准备好以下5项内容。

1. 确定汇报对象

   根据前述第14条第7款的规定，应确定作为本公司报告窗口的CSIRT隶属于哪个成员国，并在操作手册中予以明确记载。

2. 将CRA定义纳入事件分类标准

   在现有的事件响应流程中，增加“是否属于‘被主动利用的漏洞’”以及“是否属于第14条第5款规定的‘严重事件’”的判定标准，并向包括具备决策权限的人员在内的所有相关人员明确告知：一旦符合上述条件，24小时倒计时将立即启动。设计一套即使在深夜或节假日也能确保决策流程顺畅运行的升级机制至关重要。

3. 第三，报告模板的预先准备

   在24小时内能撰写的信息是有限的。如果将早期预警、72小时通知和最终报告中各自所需的项目（第14条第2款第4项）制作为模板，那么在发生紧急情况时，就无需从“该写什么”开始讨论了。

4. 用户通知的流程

   应事先确定受影响用户的识别方法、通知方式（产品内通知、电子邮件、网站公告）以及公告文本的审批流程。考虑到可能与GDPR中关于向数据主体通知的规定（第34条）存在重叠的情况，建立一个由法务和公关部门共同参与的机制更为现实。

5. 梳理GDPR下的法律地位并清点DPA

    将公司针对各产品及功能所承担的管理者或处理者身份与数据映射关联并予以明确，同时汇总列出已与客户签订的《数据处理协议》（DPA）中的违规通知条款（通知期限、通知方式、应载明事项）。将CRA规定的24小时、GDPR规定的72小时以及DPA合同中的期限叠加到同一条时间轴上，便能具体了解在突发事件发生后的最初几小时内，需要并行推进哪些工作。

此外，为迎接2027年12月的全面实施，除报告机制外，还需落实整体漏洞处理流程（包括协调性漏洞披露政策、完善软件材料清单（SBOM）、设定原则上不少于5年的支持期限、提供免费安全更新、设立用户可联系的单一窗口等。第13条及附件I）的相关要求。将履行报告义务视为这一整体框架中的第一步，这一定位较为妥当。

结语

仅从“72小时”这一数字来看，CRA的报告义务似乎与GDPR相似，但实际上两者在实质内容上存在显著差异：CRA在72小时前设有24小时的早期预警机制；报告对象不是个人数据泄露，而是产品安全事件；报告对象不是数据保护机构，而是CSIRT/ENISA；此外，无论是否担任数据控制者或处理者的角色，制造商都直接承担报告义务。因此，无法直接沿用GDPR的应对机制。

尽管期限迫在眉睫，但上述5点并不涉及大规模的系统投资，主要是在现有的事件响应流程中进行补充，并向相关人员进行通告。建议首先确认贵公司产品是否属于CRA的报告范围，并确定应向哪个CSIRT提交报告。

于是便来到了Incident Lake

正如前文所述，在CRA之后的事件响应中，除了响应速度本身之外，还要求具备“做好记录并确保能在规定期限内进行报告”的能力。

若要在24小时内发布早期预警，必须从发现问题的瞬间起就开始记录时间线；而若在应对过程中，需从散落在Slack及各类工单中的信息中事后回溯挖掘最终报告所要求的根本原因以及已实施和正在实施的对策，这种做法根本无法在期限内完成。若同时还要履行GDPR下DPA规定的客户通知义务，情况就更加严峻了。

我们正在开发的、专为事件管理设计的Agentic AI“Incident Lake”，正是为解决这一难题而打造的产品。它将分散在Slack对话及Jira等现有工具中的处理中信息整合到一个事件记录中，并按时间顺序记录事件时间线、严重程度判定及其变更历史、处理任务以及影响范围。

本文中提到的“判定事件是否属于CRA定义的严重事件”以及“对24小时、72小时、1个月等多项时限进行管理”等流程，可作为SOP检查清单纳入其中，从而防止应对措施出现疏漏；此外，还可以基于积累的记录起草报告草案，从而大幅减轻最终报告的文档编制工作量。

该设计旨在随着使用次数的增加，不断积累组织特有的判断标准和历史经验，从而提高AI辅助的准确性。

如果您希望将CRA的报告义务处理从“临时应付的手工操作”转变为“制度化流程”，请务必 了解Incident Lake 。

本文基于《欧盟法规（EU）2024/2847》的条文（2024年11月20日刊载于《官方公报》的版本）提供一般性信息，不构成法律建议。关于具体适用情况的判断，请咨询熟悉欧盟法律的律师等专业人士。