ICT 事件刚被定为重大：DORA 报告负责人必须收到什么？
围绕知悉、定级、报告时钟、受影响服务和证据负责人，建立 DORA 重大 ICT 事件交接记录，而不是只转发故障摘要。
重点监测信号
- 受监管金融实体说 ICT 事件已被定为重大，但知悉和定级时间没有记在同一条记录里
- 客户影响、服务中断和地域范围散落在不同运营讨论中，同时没有人负责监管报告
- 初始通知已有草稿，但主管机关、下一报告节点或支持证据负责人仍未确定
欧盟金融实体把一项 ICT（信息与通信技术）相关事件定为重大之后，真正有用的交接不是转发一段故障摘要，而是一份带时间的记录：实体何时知悉事件、何时由谁作出重大定级、初始通知最晚何时提交，以及下一份报告缺少的每项事实由谁负责。四处都没有时间和来源，服务商就无法判断客户缺的是证据恢复、表格制作，还是普通事件响应。
ICT 事件报告或监管响应服务商的商务拓展负责人，在获授权的银行、保险、支付和事件响应 Telegram 群里尤其要分清这件事。“重大事件，要给监管更新”只有在指向受监管实体、真实定级动作和未解决的报告工作时才值得优先查看。晚一天看到，初始通知可能已带着空白字段提交，而知道客户影响的人已转去恢复系统。
定义：报告事件从实体的定级动作开始
《数字运营韧性法案》（DORA）即条例（EU）2022/2554。第 17–20 条要求金融实体管理、定级并报告重大 ICT 相关事件。客户在投诉、状态页变红、工程师把严重等级写成 critical，都不会自动让事件在法律上成为“重大”。定级责任仍在金融实体。
授权条例（EU）2024/1772给出了更细的标准和重要性阈值，包括受影响客户与交易、持续时间和停机、地域范围、数据损失、受影响服务的关键性以及经济影响。真实群消息通常不会一次交代所有阈值所需证据。
这一区分影响时钟：报告时限跟实体的知悉和重大定级有关，不跟第一条群消息的发送时间有关。外部服务商必须先找回实体自己的记录，才能讨论是否按时。
先写四枚印章，不要先写四段说明
一页交接表就够。每枚印章都要有时间、来源和人工负责人。
第一枚：知悉
记录金融实体何时知悉事件，而不是信息跟踪工具第一次报警的时间。来源可以是事件工单、值班人员确认、服务台记录或其他获授权系统。如果不同业务单元在不同时间知道事件，先保留差异，不要擅自用最早聊天时间替代。
第二枚：重大定级
记录实体何时把事件定为重大、哪个岗位批准、当时哪些标准已有证据。之后重新定级也不能抹去早先记录。交接表应区分“定级时已知”和“之后补到”的事实。
第三枚：初始通知截止点
实施条例（EU）2025/302规定了标准表格和时限。初始通知应尽早提交，并须在事件定为重大后四小时内、且不晚于实体知悉事件后 24 小时。两个上限要同时计算。
可以把计算直接写出来：
知悉：欧洲中部时间 07:40。重大定级：15:10。定级后四小时：19:10。知悉后 24 小时：次日 07:40。操作上的初始通知截止点：当天 19:10，前提是实体确认了适用报告路径。
这是说明计算方式的虚构例子，不是真实事件。它解释了为什么“明早交”可能错误，即使 24 小时尚未走完。
第四枚：证据负责人
逐项写出能提供证据的岗位：事件指挥负责时间线，服务运营负责停机，客户运营负责受影响客户，数据保护或安全团队负责数据影响，财务负责成本估算，监管事务负责主管机关路径。写具体姓名最好，至少也应是明确岗位，不能只填“engineering”。
后面的时钟会改变工作重点
同一实施条例要求在初始通知后 72 小时内提交中期报告，即使恢复尚未结束。最终报告须在中期报告或最后一次更新中期报告后一个月内提交。信息会随着调查在不同报告中成熟。
因此，服务商第一次沟通不应先润色叙述。更有用的问题是：哪些必填事实已有来源，哪些只是估计，哪些连负责人都没有？ 中期报告需要事件发展、影响和缓解情况；最终报告还需根因、解决情况和更完整影响。今天缺一条来源，之后就可能变成多份报告互相矛盾。
例如，运营群里可能只有：
“支付恢复了，大概四十分钟。合规下午三点左右说算重大。客户数还在 support 那边。”
这段合成消息不来自客户。它透露了恢复、粗略持续时间、一次定级动作和缺失的影响数字，却没有说明受监管实体、知悉时间、主管机关、受影响支付服务、交易数、地域、数据损失、成本或报告状态。
服务商可以追问定级记录和当前报告回执，却不能仅凭这段话宣布漏报或认定超过某个阈值。
给报告负责人一张证据队列
一行写一个事实，不要一行写一个团队：
| 报告事实 | 当前证据 | 未知 | 负责人 | 用于 |
|---|---|---|---|---|
| 知悉时间 | 事件工单确认 | 是否有更早业务报警已被接收 | 事件指挥 | 初始通知 |
| 重大定级 | 带日期的定级决定 | 标准后来是否调整 | 监管事件负责人 | 初始通知 |
| 受影响客户 | 客服正在导出 | 去重后的最终客户数 | 客户运营 | 中期报告 |
| 服务中断 | 观测与恢复标记 | 部分降级窗口 | 服务负责人 | 中期报告 |
| 根因 | 调查中 | 促成故障的控制缺口 | 技术负责人 | 最终报告 |
这张队列是本文的原创贡献。它让缺失证据保持可见，不会把未知补成事实，也能把商业范围说具体：恢复证据、准备表格、校对时间线或复核报告质量。
TOP Prospect 可以在用户主动连接且有权访问的 Telegram 群里筛选、合并和排序相关片段，保留原文、来源、时间、摘要和判断理由供人工查看。它不能替实体定级、读取内部事件系统、选择主管机关、提交报告或联系发言者。价格与访问方式介绍的是发现工具，不是 DORA 报告服务。另一个 DORA 证据问题可阅读信息登记表修复项目；转发的监管要求失去官方来源时，可用官方来源层级找回控制文本。
关键事实
- DORA 第 17–20 条涉及金融实体对 ICT 相关事件的管理、定级和报告。
- 授权条例（EU）2024/1772 给出详细定级标准和重要性阈值。
- 实施条例（EU）2025/302 要求初始通知尽早提交，并在重大定级后四小时内、且不晚于知悉后 24 小时。
- 中期报告须在初始通知后 72 小时内提交。
- 最终报告须在中期报告或最后一次更新中期报告后一个月内提交。
- 群消息能暴露交接缺口，却不能证明定级、主管机关或合规结论。
常见问题
每次严重故障都会成为 DORA 重大 ICT 相关事件吗？
不会。金融实体必须依据 DORA 和适用定级标准作出定级。群消息里的“严重”或“关键”措辞不能代替法律定级。
DORA 的主要报告时钟是什么？
根据实施条例（EU）2025/302，初始通知应尽早提交，并须在定为重大后四小时内、且不晚于知悉事件后 24 小时；中期报告应在初始通知后 72 小时内提交，最终报告应在中期报告或最后一次更新中期报告后一个月内提交。
事件响应服务商能替客户选择主管机关吗？
不能。受监管金融实体必须确认适用于自己的报告路径。服务商可以协助保存和整理证据，但不能仅凭事件内容推断主管机关。
最小可用交接记录应包含什么？
记录知悉时间、重大定级时间与负责人、由此算出的初始通知截止点、受影响服务与客户、主管机关路径、各证据负责人和下一个报告节点。
当每个时钟都有来源、每个缺失事实都有负责人时，这份交接已足够决定是否安排范围沟通；第一天不需要假装已经有完整根因报告。
常见问题
每次严重故障都会成为 DORA 重大 ICT 相关事件吗？
不会。金融实体必须依据 DORA 和适用定级标准作出定级。群消息里的“严重”或“关键”措辞不能代替法律定级。
DORA 的主要报告时钟是什么？
根据实施条例（EU）2025/302，初始通知应尽早提交，并须在定为重大后四小时内、且不晚于知悉事件后 24 小时；中期报告应在初始通知后 72 小时内提交，最终报告应在中期报告或最后一次更新中期报告后一个月内提交。
事件响应服务商能替客户选择主管机关吗？
不能。受监管金融实体必须确认适用于自己的报告路径。服务商可以协助保存和整理证据，但不能仅凭事件内容推断主管机关。
最小可用交接记录应包含什么？
记录知悉时间、重大定级时间与负责人、由此算出的初始通知截止点、受影响服务与客户、主管机关路径、各证据负责人和下一个报告节点。
资料来源与延伸阅读
值得关注的潜在线索 Signal 是怎样被发现的
了解 Top商业线索怎样发现和整理值得核实的 Signal、保留 Telegram 原始上下文、去掉重复消息并安排查看顺序。是否跟进以及下一步做什么，仍由用户决定。