每一项监管披露规则都提出同一个问题。只是各自使用了不同的表述。
Falco Feeds 通过提供专家编写且随新威胁发现而持续更新的检测规则，扩展了 Falco 的能力，使专注于开源的公司能够受益。
去年在讨论欧盟银行和金融科技行业的监管环境时，我提到《网络弹性法案》（CRA）虽已生效，但直到 2027 年 12 月才会正式适用于法律层面。对于 CRA 的大部分内容而言，这一说法仍然成立，但其报告义务除外。
从2026 年 9 月 11 日起，向欧盟市场销售含数字元素产品的制造商，必须报告已被积极利用的漏洞和严重事件。这些组织要求在 24 小时内向欧盟网络安全局（ENISA）和相关的国家计算机安全事件响应团队（CSIRT）发出早期预警。随后，需在 72 小时内提交更详细的通知，并在 14 天内提交关于漏洞的最终报告，或在 1 个月内提交关于严重事件的最终报告。新规则不仅适用于新产品，也适用于市场上已有的产品。
对大多数受监管的组织而言，这并非一项新的义务，只是在一堆现有义务上又加了一个新的披露倒计时。如果你是为高度受监管行业提供软件销售的服务商，情况则更为严峻：你的通知不仅启动了自身的合规流程，同时也触发了客户的合规倒计时。
截止日期通常最引人关注，因为它们最容易呈现在董事会幻灯片上。但值得注意的是，这些截止日期都取决于一个关键判断。大多数组织正是在这个判断环节上失败。
然而，在倒计时结束后，你才能清晰且自信地做出该判断。
倒计时正在激增
以下是全球组织可能需要同时跟踪的一些并行时间线：
- 欧盟《通用数据保护条例》(GDPR) 第 33 条。受监管实体必须“无不当延迟”地通知监管机构，最迟不得晚于 意识到个人数据泄露后的 72 小时，除非该泄露不太可能对个人的权利和自由构成风险。根据第 34 条，如果个人面临高风险，也必须通知他们。
- 《网络和信息安全指令 2》(NIS2) 第 23 条。受监管实体在意识到重大事件后，必须提交 24 小时初步预警，在 72 小时内发送更完整的通报，并在一个月内提交最终报告。
- 《数字运营韧性法》(DORA)。受监管实体必须在将事件分级为重大事件的 4 小时内发送初始通报，且无论如何不得晚于意识到事件后的 24 小时。随后需在 72 小时内提交中期报告，并在一个月内提交最终报告。
- 美国证券交易委员会 (SEC) 8-K 表格，第 1.05 项。组织必须在认定网络安全事件具有重大性的 4 个工作日内进行披露。
- 《关键基础设施网络事件报告法案》(CIRCIA)。预计美国网络安全和基础设施安全局 (CISA) 将在 2026 年 9 月完成 CIRCIA 的最终定稿。该法案生效后，预计将强制要求受监管实体在合理认为发生相关网络事件后的 72 小时内上报，并在支付赎金后的 24 小时内上报赎金支付情况。
- 《网络韧性法》(CRA)。如上所述，自 2026 年 9 月 11 日起，受监管实体必须在 24 小时内向欧盟网络安全局 (ENISA) 和相关国家计算机安全事件响应团队 (CSIRT) 发送初步预警，在 72 小时内跟进更详细的通报，并针对漏洞或严重事件分别在 14 天或一个月内提交最终报告。
这就是六套监管体系，各自的截止时限、报告对象和申报表单都非常相似，只是细节略有差异。一家跨国金融机构，既做软件又在美国上市，一次安全事件就有可能同时触发其中四套。
直觉的做法是做一张截止时间矩阵表，交给事件响应团队。这确实值得做，但并不是抢在信息披露前面最关键的一步。
读秒不是最难的部分
仔细看每套框架的时钟从什么时候开始计时，因为它们的触发"事件"并不相同。
第一类——DORA 和 SEC——时钟从你做出判断的那一刻启动。DORA 的四小时从你把事件定级为重大开始，SEC 的四个工作日从你认定事件构成重大事项（material）开始。注意，这两个时钟都不是从发现事件本身算起的。
第二类——GDPR、CIRCIA、NIS2 和 CRA——时钟从"知悉"开始计时，这个词听起来很客观，实际上没那么简单。GDPR 的 72 小时从你掌握足够信息、可以判断大概率发生了数据泄露时算起。CIRCIA 的 72 小时从你有合理理由相信事件已经发生的那一刻算起。NIS2 给你 24 小时，从你知悉发生重大事件时算起。CRA 也给你 24 小时，从你知悉自己产品的漏洞正在被积极利用时算起。
无论哪种情况，时钟都是从你发现的那一刻开始，而不是攻击发生的那一刻。更有意思的是下面这一点：
第一类的时钟很短，但要等你判断完事件是否属于重大事项或重大事件才启动。第二类的时钟启动得更早，但在做出类似判断之前你照样什么都不能报；门槛问题决定了你到底要不要申报。
不管怎样，真正关键的工作发生在任何时钟启动之前，而且监管机构已经堵上了那个明显的漏洞。SEC 要求在发现事件后毫不迟疑地完成重大性评估，想拖时间是行不通的。DORA 把整个过程硬性限制在知悉后 24 小时内，不管你何时完成定级。GDPR 则要求你如果错过 72 小时的期限，就得解释清楚原因。
你没有暂停时钟慢慢想的余地。要么快速做出判断，要么解释为什么做不到。
| 监管框架 | 报告时限 | 计时起点 |
|---|---|---|
| GDPR | 72小时 | 发现已发生数据泄露 |
| NIS2 | 24小时 | 意识到发生“重大”事件 |
| DORA | 4小时 | 事件被认定为“严重” |
| CRA | 24小时 | 发现产品漏洞正被积极利用 |
| CIRCIA | 72小时 | 合理认为已发生安全事件 |
| SEC | 4个工作日 | 事件被认定为“重大” |
同一判断，四种表述
剥离法律术语，上述所有监管框架本质上都在问同一个问题：“这件事是否已跨出内部边界，让组织外部的人也需要知晓？” 每个框架只是用了不同的词来定义这条边界。
SEC 称之为重大（material），DORA 称之为严重（major），NIS2 称之为显著（significant），CRA 则称之为严重（severe），或在漏洞情况下指正被积极利用。GDPR 则没有专用名词，而是描述对自然人权利和自由的风险，直接通知个人时门槛更高，需达到“高风险”。
归根结底，这些不过是同一个判断的四种表述。
安全团队每天都在做同样的事，他们称之为优先级排序——划定一条线，筛选出最关键的事项。监管层面的做法本质相同，只是多了倒计时的时钟和法律责任，赌注更大，但性质未变。
这样理解有实际意义。若把披露门槛视为法务介入后才启动的流程，就会太慢，因为事实信息在别处。若视其为面向特定受众的优先级排序——即便这个受众能罚款甚至判刑——你就能利用团队现有的能力提前准备。
DORA 考验你的数学能力
若想明白这无法靠临场发挥，不妨细读 DORA 的分类规则。根据监管技术标准，只有当关键服务受到影响时，事件才被视为重大，且须满足其余六项标准中的至少两项。
这些标准涵盖受影响的客户或交易对手数量、声誉影响、攻击及服务中断的持续时间、数据丢失的范围、地理分布以及经济影响。通常情况下，如果某事件触及使用受影响服务的超过 10% 的客户，即可达到该特定阈值。甚至还存在复发规则：若多个单独来看不构成重大的事件在六个月内发生至少两次，拥有明显的共同根本原因，且共同满足上述标准，则视为一次重大事件。
再读一遍，这次请将其视为操作要求而非法律条文：你必须在四小时内知晓影响了多少客户、持续了多久、涉及哪些司法管辖区，并清楚哪些数据被窃取。这不是仅凭配置快照就能做出的判断。快照只显示环境是如何配置的，却无法揭示内部发生了什么、发生顺序如何以及波及了谁。
这正是合规对话常常失准之处。行业花了多年时间，擅长证明特定时刻控制措施的存在。几乎所有框架都对此给予奖励，这对通过审计确实有用。但我们讨论的六大制度中，没有一项询问“控制措施是否存在”；它们询问的都是“发生了什么”。
这是不同的问题，需要不同的证据。
准确的事实模式究竟需要什么
将六项法规剥离到共同点，你会得到以下内容：
- 被访问或受影响的对象，需有足够细节来界定涉及的数据。
- 事件发生的时间，包括起始时间——这通常早于你实际识别出事件的时间。
- 受影响的人员，按数量统计，通常还要按司法管辖区划分。
- 是否带有恶意性质，因为 NIS2 明确询问非法行为，而 CRA 则区分主动利用的漏洞与理论上的漏洞。
- 你采取了什么措施，以及还有哪些待办事项（注：原文在此处截断，未显示完整句子）
