Báo cáo sự cố theo DORA và NIS2: nhận cuộc gọi trước khi hết giờ

Mục lục

Các đồng hồ báo cáo thực sự đòi hỏi điều gì
Vì sao một thời hạn báo cáo thực chất là bài toán đánh thức người
Cuối tuần có mua thêm thời gian cho bạn không?
Cách đặt một chiếc điện thoại đổ chuông trước quy trình báo cáo của bạn
Bước 1 — Tạo một kênh Cuộc gọi chỉ dành cho các sự cố phải báo cáo
Bước 2 — Trỏ hệ thống phát hiện của bạn tới webhook đó
Bước 3 — Dùng điều kiện để chỉ những trường hợp khả dĩ mới đổ chuông
Bước 4 — Bắt cả những hệ thống chỉ gửi email
Bước 5 — Đưa những người chịu trách nhiệm về thời hạn vào cùng kênh
Bước 6 — Kiểm thử với Không làm phiền đang bật
Những gì Echobell không làm
Câu hỏi thường gặp
Dùng Echobell có làm chúng tôi tuân thủ DORA hay NIS2 không?
Chính xác thì đồng hồ 4 giờ của DORA bắt đầu chạy khi nào?
Cảnh báo sớm theo NIS2 có cần đầy đủ chi tiết sự cố không?
Hệ giám sát của chúng tôi vốn đã gửi email cho kỹ sư trực. Vậy chưa đủ sao?
Bộ phận tuân thủ và bộ phận kỹ thuật có thể nhận cùng một cảnh báo không?
Cuộc gọi có thật sự lọt qua được chế độ Không làm phiền không?
Cái này chỉ dành cho iOS thôi à?
Chúng tôi nên đưa dữ liệu gì vào payload webhook?
Liên quan

Mọi thời hạn báo cáo sự cố của EU đều bắt đầu đếm từ một thứ mà máy móc nhận ra, và tiếp tục đếm trong lúc cả nhóm bạn đang ngủ. Nếu cảnh báo khởi động đồng hồ đó đến dưới dạng thông báo đẩy im lặng lúc 02:40 một sáng Chủ nhật, thì bạn đã đốt mất một phần tư cửa sổ báo cáo theo DORA trước khi có bất kỳ con người nào đọc nó. Bài viết này chỉ cho bạn cách đặt một cuộc gọi đổ chuông thật ngay phía trước quy trình báo cáo của mình bằng Echobell — để đồng hồ và phản ứng của bạn bắt đầu gần như cùng lúc.

Quy mô của chuyện này giờ đã được đo đạc chứ không còn phỏng đoán. Ngày 3 tháng 6 năm 2026, ba Cơ quan Giám sát châu Âu công bố bản tổng quan đầu tiên trên toàn EU về các sự cố ICT nghiêm trọng được báo cáo theo DORA: 3.383 sự cố nghiêm trọng trong năm 2025, trung bình 0,18 sự cố trên mỗi tổ chức tài chính thuộc phạm vi điều chỉnh, với khoảng một phần ba có tác động xuyên biên giới (EBA, ESMA). Chi tiết đáng để định hình cách bạn cảnh báo: chỉ 10% liên quan tới an ninh mạng. Lỗi hệ thống và sự kiện bên ngoài mới là nguyên nhân chính.

Nói cách khác, những sự kiện khởi động một chiếc đồng hồ pháp lý phần lớn lại là những chuyện nhàm chán — một lần deploy hỏng, một dependency chết, một nhà cung cấp gặp sự cố. Đúng những thứ mà hệ giám sát của bạn vốn đã bắt được lúc 3 giờ sáng và gửi tới một chiếc điện thoại đang bật Không làm phiền.

Các đồng hồ báo cáo thực sự đòi hỏi điều gì

Ba khung quy định, ba tiếng súng khởi hành khác nhau — và tất cả đều chạy theo thời gian thực. Đây là những gì các văn bản hiện hành quy định.

Khung quy định	Thời hạn đầu tiên	Tiếp theo	Cuối cùng
DORA (tổ chức tài chính EU)	Thông báo ban đầu trong vòng 4 giờ kể từ khi phân loại sự cố là nghiêm trọng, và không muộn hơn 24 giờ kể từ khi biết về nó	Báo cáo trung gian chậm nhất 72 giờ sau thông báo ban đầu	Báo cáo cuối cùng không muộn hơn một tháng sau báo cáo trung gian (gần nhất)
NIS2 (tổ chức thiết yếu và quan trọng của EU)	Cảnh báo sớm không chậm trễ vô lý và trong mọi trường hợp trong vòng 24 giờ kể từ khi biết về sự cố đáng kể	Thông báo sự cố trong vòng 72 giờ kể từ khi biết	Báo cáo cuối cùng không muộn hơn một tháng sau thông báo sự cố
SEC Item 1.05 (công ty niêm yết tại Mỹ)	Mẫu 8-K thường phải nộp trong bốn ngày làm việc sau khi xác định sự cố là trọng yếu	—	—

Các mốc thời gian của DORA đến từ Quy định ủy quyền (EU) 2025/301 của Ủy ban châu Âu, tức chuẩn kỹ thuật quản lý về nội dung và thời hạn báo cáo sự cố, công bố ngày 20 tháng 2 năm 2025 và bổ sung cho Quy định (EU) 2022/2554 (Ủy ban châu Âu, nội dung Điều 5). Bản thân DORA đã có hiệu lực áp dụng từ ngày 17 tháng 1 năm 2025 (ESMA).

Các mốc thời gian của NIS2 nằm ở Điều 23(4) của Chỉ thị (EU) 2022/2555; các quốc gia thành viên phải nội luật hóa trước ngày 17 tháng 10 năm 2024 (Ủy ban châu Âu). Thời hạn của SEC đến từ các quy tắc công bố thông tin an ninh mạng được thông qua ngày 26 tháng 7 năm 2023 (SEC).

Vì sao một thời hạn báo cáo thực chất là bài toán đánh thức người

Bởi vì chẳng đồng hồ nào trong số đó được neo vào giờ làm việc của bạn. DORA đo từ lúc phân loại và từ lúc tổ chức biết về sự cố. NIS2 đo từ lúc tổ chức biết. SEC đo từ lúc xác định tính trọng yếu. Việc một thời điểm cụ thể có được tính là "biết" hay không là phán đoán pháp lý do bộ phận tuân thủ của bạn đưa ra — nhưng không có văn bản nào trong số đó cho đếm lại từ đầu chỉ vì người đầu tiên nhìn thấy cảnh báo tình cờ đang ngủ.

Hãy tính ngược trên nhánh khắt khe nhất của DORA. Bạn có 4 giờ kể từ khoảnh khắc một sự cố được phân loại là nghiêm trọng, và việc phân loại không thể xảy ra trước khi có người nhìn vào nó. Nếu phát hiện lúc 02:40, không ai xác nhận cho tới 08:00, và việc phân loại tốn thêm 90 phút điều tra, thì bạn nộp thông báo ban đầu vào khoảng 11:00 — vẫn nằm trong giới hạn ngoài 24 giờ, nhưng đã tiêu hơn tám tiếng của trần 24 giờ chỉ để ngủ. Thu hẹp khoảng trống xác nhận thì mọi bước phía sau đều có chỗ để thở.

Đây không phải lời kêu gọi cảnh báo thêm nhiều thứ hơn. Đây là lời kêu gọi rằng một nhóm cảnh báo cụ thể và hẹp — những cảnh báo có khả năng trở thành phải báo cáo — phải là thứ không thể ngủ quên mà bỏ qua. Mọi thứ khác nên giữ im lặng. (Nếu nhóm bạn vốn đã chìm nghỉm trong cảnh báo, hãy bắt đầu bằng việc chữa chứng mệt mỏi vì cảnh báo trước khi thêm một kênh ồn ào hơn.)

Cuối tuần có mua thêm thời gian cho bạn không?

Một chút, theo DORA — và rất có thể là không dành cho bạn. Quy định ủy quyền (EU) 2025/301 cho phép một tổ chức tài chính có thời hạn rơi vào ngày cuối tuần hoặc ngày lễ ngân hàng tại quốc gia thành viên của mình được nộp trước trưa ngày làm việc kế tiếp. Nhưng cũng chính điều khoản đó không cho ưu đãi này với các tổ chức tín dụng, đối tác thanh toán bù trừ trung tâm và đơn vị vận hành sàn giao dịch, cũng như với các tổ chức thuộc nhóm thiết yếu hoặc quan trọng theo NIS2. Cơ quan có thẩm quyền cũng có thể rút ưu đãi này với các tổ chức có tầm quan trọng hệ thống khác (Điều 5, tóm tắt của Advisera).

Vậy nên chính những tổ chức dễ gặp sự cố vào tối Chủ nhật nhất lại là những tổ chức không được nới cuối tuần. Điều 23 của NIS2 hoàn toàn không có ưu đãi cuối tuần nào. Hãy lên kế hoạch với giả định đồng hồ chạy vào thứ Bảy y hệt như vào thứ Ba, rồi coi bất kỳ ưu đãi nào bạn đủ điều kiện hưởng là món quà thêm chứ không phải khoảng đệm.

Cách đặt một chiếc điện thoại đổ chuông trước quy trình báo cáo của bạn

Echobell làm đúng một việc: nó biến webhook hoặc email thành một cuộc gọi — một cuộc gọi đổ chuông và rung thật sự, xuyên qua chế độ Tập trung và Không làm phiền của iOS đúng như cách một cuộc gọi từ người thân vẫn làm được (xem cách vượt qua chế độ Tập trung của iOS cho cảnh báo nguy cấp). Nó nằm giữa hệ thống phát hiện sự cố và con người phải khởi động chiếc đồng hồ.

Bước 1 — Tạo một kênh Cuộc gọi chỉ dành cho các sự cố phải báo cáo

Hãy tạo một kênh trong Echobell và đặt loại thông báo là Cuộc gọi. Đây là thứ khiến điện thoại đổ chuông thay vì gửi một thông báo đẩy im lặng (các loại thông báo). Hãy đặt cho nó cái tên không thể nhầm lẫn — "Sự cố phải báo cáo — dậy ngay" — và đừng dùng nó vào việc gì khác. Sao chép webhook URL của kênh trong phần chi tiết kênh; nó trông như https://hook.echobell.one/t/<channel-token>. Hãy coi đó là thông tin bí mật.

Bước 2 — Trỏ hệ thống phát hiện của bạn tới webhook đó

Bất cứ thứ gì nhận ra sự cố đều gửi một HTTP request tới URL của kênh. Echobell có hướng dẫn riêng cho Grafana, Prometheus Alertmanager, Uptime Kuma và UptimeRobot; mọi thứ khác gửi được JSON qua POST đều dùng được theo hướng dẫn webhook. Một payload hữu ích cần mang đủ thông tin để đưa ra quyết định phân loại đầu tiên mà không phải mở laptop:

{
  "title": "Reportable candidate: {{service}}",
  "message": "{{service}} down since {{started_at}} — client-facing: {{client_impact}}",
  "externalLink": "https://status.internal.example/incident/{{id}}"
}

Biến externalLink trở thành một liên kết bấm được trong bản ghi thông báo, nên ai nghe máy sẽ vào thẳng được sự cố.

Bước 3 — Dùng điều kiện để chỉ những trường hợp khả dĩ mới đổ chuông

Một cuộc gọi kích hoạt với mọi cảnh báo thì thôi không còn là cuộc gọi nữa, nó trở thành tiếng ồn nền. Điều kiện của Echobell lọc theo giá trị biến với logic AND/OR, nên bạn có thể yêu cầu, ví dụ, severity == "critical" và client_impact == true thì kênh mới gọi cho ai đó. Hãy đưa mọi thứ dưới ngưỡng đó sang một kênh Khẩn cấp hoặc Thông thường riêng. Kênh sự cố phải báo cáo của bạn nên đổ chuông vài lần mỗi năm, chứ không phải mỗi tuần.

Bước 4 — Bắt cả những hệ thống chỉ gửi email

Rất nhiều luồng trạng thái của nhà cung cấp, công cụ giám sát gian lận và bên thứ ba chỉ báo qua email chứ không gì khác — điều này quan trọng với DORA, nơi sự cố phía nhà cung cấp nằm rõ trong phạm vi điều chỉnh. Mỗi kênh Echobell đều có thể có địa chỉ riêng, nên một quy tắc chuyển tiếp là đủ để biến những thư đó thành cuộc gọi (kích hoạt qua email, thiết lập email thành cuộc gọi).

Bước 5 — Đưa những người chịu trách nhiệm về thời hạn vào cùng kênh

Kỹ thuật là bên phát hiện sự cố; còn tuân thủ, người trực ca hay DPO mới là bên chịu trách nhiệm về thời hạn. Hãy chia sẻ kênh và để mỗi người đăng ký tự chọn mức khẩn cấp của mình, sao cho kỹ sư trực nhận cuộc gọi còn người ứng phó thứ hai nhận cảnh báo khẩn cấp. Hãy bật Gọi lại khi cuộc gọi thất bại để một cuộc gọi bị chế độ Tập trung chặn sẽ được thử lại.

Bước 6 — Kiểm thử với Không làm phiền đang bật

Hãy gửi một webhook thử với chế độ Không làm phiền đang bật trên mọi chiếc điện thoại quan trọng, ít nhất mỗi quý một lần. Một đường leo thang chưa được kiểm thử chỉ là một giả định, và giả định chính là thứ làm nên các buổi rà soát hậu sự cố.

Những gì Echobell không làm

Nói cho chính xác ở đây còn quan trọng hơn bất cứ đâu khác trong một quy trình chịu sự quản lý.

Echobell có: biến webhook hoặc email thành một cuộc gọi đổ chuông, một cảnh báo khẩn cấp hoặc một thông báo đẩy thông thường; xuyên qua chế độ Tập trung và Không làm phiền của iOS với cảnh báo loại Cuộc gọi; lọc bằng điều kiện và mẫu; gửi cùng một cảnh báo tới một kênh dùng chung của cả nhóm.

Echobell không:

Phân loại sự cố. Nó không có quan điểm gì về việc một chuyện là "nghiêm trọng" theo DORA, "đáng kể" theo NIS2 hay "trọng yếu" theo quy tắc của SEC. Đó là những phán đoán do con người của bạn đưa ra dựa trên tiêu chí trong các văn bản liên quan.
Nộp bất cứ thứ gì cho bất cứ ai. Nó không gửi hồ sơ tới cơ quan có thẩm quyền, tới CSIRT hay tới SEC. Nó chỉ đưa một con người tới điểm mà họ có thể làm việc đó.
Đóng vai hệ thống lưu trữ hồ sơ hay GRC của bạn. Các khung quy định này đòi hỏi tài liệu, sổ đăng ký và bằng chứng mà một ứng dụng cảnh báo không tạo ra được. Echobell cố ý chỉ lưu nội dung và lịch sử thông báo trên thiết bị của bạn, còn máy chủ chỉ giữ tài khoản, kênh và đăng ký (mô hình quyền riêng tư) — tốt cho việc tối thiểu hóa dữ liệu, nhưng vô dụng với vai trò dấu vết kiểm toán.
Đi kèm chứng nhận tuân thủ. Không có chứng chỉ, báo cáo kiểm toán hay SLA hợp đồng nào gắn với nó. Nếu bạn đưa nó vào một quy trình chịu quản lý, hãy cho nó đi qua quy trình quản trị rủi ro bên thứ ba về ICT của chính bạn như với mọi công cụ khác, và hãy duy trì một kênh không phụ thuộc vào nó.
Bảo đảm gửi đến nơi. Một cuộc gọi phụ thuộc vào hạ tầng push, vào mạng và vào một chiếc điện thoại còn pin. Hãy xem nó là lớp giúp rút ngắn mạnh thời gian xác nhận, chứ không phải một biện pháp kiểm soát mà bạn có thể chỉ ra trong một cuộc kiểm toán.

Cách nói thật thà nhất: nghĩa vụ pháp lý của bạn không thay đổi vì ứng dụng nào làm điện thoại bạn đổ chuông. Thứ mà một cuộc gọi thay đổi là số giờ giữa lúc máy móc nhận ra và lúc con người quyết định — và với một chiếc đồng hồ 4 giờ, những giờ đó chiếm gần hết ngân sách.

Câu hỏi thường gặp

Dùng Echobell có làm chúng tôi tuân thủ DORA hay NIS2 không?

Không. Việc tuân thủ phụ thuộc vào quản trị, quy trình phân loại, tài liệu và việc nộp hồ sơ thực tế của bạn tới cơ quan có thẩm quyền hoặc CSIRT. Echobell chỉ rút ngắn khoảng cách giữa phát hiện và xác nhận của con người. Nó là một đầu vào cho quy trình, không phải bản thân quy trình.

Chính xác thì đồng hồ 4 giờ của DORA bắt đầu chạy khi nào?

Từ lúc phân loại. Theo Quy định ủy quyền (EU) 2025/301, thông báo ban đầu phải nộp trong vòng bốn giờ kể từ khi phân loại một sự cố là nghiêm trọng, và trong mọi trường hợp không muộn hơn 24 giờ kể từ thời điểm tổ chức biết về nó. Đó là hai ràng buộc riêng biệt và bạn phải thỏa mãn cả hai — đó là lý do một quyết định phân loại nhanh cũng quan trọng ngang một cảnh báo nhanh.

Cảnh báo sớm theo NIS2 có cần đầy đủ chi tiết sự cố không?

Không. Điều 23(4) của Chỉ thị (EU) 2022/2555 cố ý để cảnh báo sớm trong 24 giờ ở mức sơ bộ: sự cố có bị nghi ngờ do hành vi trái pháp luật hay ác ý gây ra không, và nó có thể có tác động xuyên biên giới không. Bức tranh đầy đủ hơn thuộc về thông báo trong 72 giờ, còn phân tích nguyên nhân gốc rễ nằm ở báo cáo cuối cùng một tháng sau đó.

Hệ giám sát của chúng tôi vốn đã gửi email cho kỹ sư trực. Vậy chưa đủ sao?

Nó đủ khi có người còn thức và đang nhìn vào đó. Email và thông báo đẩy thông thường bị chế độ Tập trung, Không làm phiền và lịch ngủ làm câm lặng — đúng những điều kiện trong những đêm và cuối tuần mà chiếc đồng hồ ít khoan dung nhất. Khoảng trống nằm ở khâu xác nhận, chứ không phải khâu phát hiện.

Bộ phận tuân thủ và bộ phận kỹ thuật có thể nhận cùng một cảnh báo không?

Có. Hãy chia sẻ kênh và mọi người đã đăng ký đều nhận được kích hoạt, mỗi người tự chọn loại thông báo của mình. Một cách bố trí phổ biến: kỹ sư trực đăng ký ở mức Cuộc gọi, còn cán bộ tuân thủ trực ca đăng ký ở mức Cuộc gọi cho kênh sự cố phải báo cáo và Khẩn cấp cho mọi thứ còn lại.

Cuộc gọi có thật sự lọt qua được chế độ Không làm phiền không?

Loại thông báo Cuộc gọi của Echobell được thiết kế để đổ chuông xuyên qua chế độ Tập trung và Không làm phiền của iOS, và tùy chọn Gọi lại khi cuộc gọi thất bại sẽ thử lại những cuộc gọi bị chế độ Tập trung chặn. Hãy kiểm chứng trên đúng thiết bị thật của từng người ứng phó trước khi trông cậy vào nó — cài đặt và phiên bản hệ điều hành mỗi máy mỗi khác.

Cái này chỉ dành cho iOS thôi à?

Không. Echobell có trên iOS và trên Android qua Google Play (xem thông báo ra mắt bản Android). Hành vi của cảnh báo dạng cuộc gọi khác nhau giữa các nền tảng, nên hãy kiểm thử trên đúng thiết bị mà người ứng phó của bạn đang mang theo.

Chúng tôi nên đưa dữ liệu gì vào payload webhook?

Càng ít càng tốt. Hãy gửi một định danh và một liên kết thay vì thông tin khách hàng hay chi tiết sự cố — dùng biến externalLink để trỏ tới bản ghi sự cố của bạn, thứ vốn nằm trong một hệ thống được xây để chứa nó. Việc của cảnh báo là đánh thức ai đó dậy, không phải để tường trình cho họ.