---
title: "Đồng hồ 24 giờ của CRA bắt đầu chạy từ 11/9/2026: Hãy chắc chắn có người nghe máy"
description: "Từ 11/9/2026, Đạo luật Cyber Resilience của EU cho nhà sản xuất 24 giờ để gửi cảnh báo sớm — qua trình duyệt, không có API báo cáo. Đây là cách biến sự kiện đó thành một cuộc gọi với Echobell, và những gì cảnh báo ồn hơn vẫn không giải quyết được."
date: 2026-08-21
author: Nooc
authorAvatarLink: /images/avatars/nooc.webp
authorLink: https://nooc.me
tags:
  - Cyber Resilience Act
  - báo cáo CRA
  - báo cáo sự cố
  - công bố lỗ hổng
  - cảnh báo bằng cuộc gọi
---

# Làm cho cảnh báo sớm 24 giờ của CRA đổ chuông trước khi hết giờ

Ngày **11/9/2026**, các nghĩa vụ báo cáo của Đạo luật Cyber Resilience (CRA) của EU bắt đầu có hiệu lực. Từ ngày đó, một nhà sản xuất khi biết về một lỗ hổng đang bị khai thác trong sản phẩm có yếu tố số — hoặc về một sự cố nghiêm trọng ảnh hưởng tới sản phẩm đó — có **24 giờ** để gửi cảnh báo sớm tới CSIRT điều phối của mình và tới ENISA ([Ủy ban châu Âu](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting), [Quy định (EU) 2024/2847](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng)).

Hạn chót đó có một đặc điểm mà phần lớn hạn chót tuân thủ khác không có: nó chạy theo giờ đồng hồ thật. Không có ngoại lệ ngày làm việc, không dừng lại vào cuối tuần, và cũng chẳng gia hạn khi người phụ trách báo cáo của bạn đang ngồi trên máy bay. Còn nền tảng bạn phải nộp qua đó, Single Reporting Platform của ENISA, là một biểu mẫu web — "sẽ không có Giao diện lập trình ứng dụng nào được cung cấp ở giai đoạn này" ([Hỏi đáp của ENISA](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions)). Phải có một con người cụ thể đăng nhập và bấm gửi.

Điều đó khiến quy tắc 24 giờ trở thành bài toán cảnh báo trước khi là bài toán giấy tờ. Bài viết này chỉ cách đưa khoảnh khắc "biết chuyện" thành một chiếc điện thoại đổ chuông bằng [Echobell](https://apps.apple.com/app/apple-store/id6743597198?pt=128151925&ct=blog-cra-24-hour-reporting-alerts-vi&mt=8), và nói thẳng về phần lớn công việc sẵn sàng tuân thủ CRA mà không công cụ thông báo nào chạm tới.

## Chính xác thì điều gì bắt đầu vào ngày 11/9/2026?

**Nhà sản xuất các sản phẩm có yếu tố số phải báo cáo lỗ hổng đang bị khai thác và sự cố nghiêm trọng qua một nền tảng chung của EU, theo một chuỗi mốc thời gian bắt đầu ngay khi họ biết chuyện.** Mọi phần khác của CRA — dấu CE, các yêu cầu thiết yếu ở Phụ lục I, đánh giá sự phù hợp — áp dụng từ 11/12/2027. Nghĩa vụ báo cáo đến sớm hơn mười lăm tháng, và nó áp dụng cho cả sản phẩm đã có trên thị trường, chứ không chỉ cho những gì bạn xuất xưởng sau ngày đó ([cyberresilienceact.eu](https://www.cyberresilienceact.eu/reporting.html)).

Điều 14 định nghĩa hai nhánh song song có cùng hình dạng:

| Giai đoạn | Lỗ hổng đang bị khai thác — Điều 14(2) | Sự cố nghiêm trọng — Điều 14(4) |
| --- | --- | --- |
| Cảnh báo sớm | Trong vòng **24 giờ** kể từ khi biết | Trong vòng **24 giờ** kể từ khi biết |
| Thông báo | Trong vòng **72 giờ** kể từ khi biết | Trong vòng **72 giờ** kể từ khi biết |
| Báo cáo cuối | Không muộn hơn **14 ngày** sau khi có biện pháp khắc phục hoặc giảm nhẹ | Trong vòng **một tháng** sau thông báo 72 giờ |

Nguyên văn là "không chậm trễ quá mức và trong mọi trường hợp là trong vòng 24 giờ kể từ khi nhà sản xuất biết về việc đó" ([Điều 14](https://www.european-cyber-resilience-act.com/Cyber_Resilience_Act_Article_14.html)). Hai mươi tư giờ là mức trần, không phải mục tiêu.

Điều 14(5) đặt ra ngưỡng cho chữ "nghiêm trọng": một sự cố được tính khi nó ảnh hưởng tiêu cực, hoặc có khả năng ảnh hưởng tiêu cực, tới khả năng của sản phẩm trong việc bảo vệ tính sẵn sàng, tính xác thực, tính toàn vẹn hay tính bảo mật của dữ liệu hoặc chức năng nhạy cảm, quan trọng; hoặc khi nó đã dẫn tới, hay có khả năng dẫn tới, việc mã độc bị đưa vào hoặc được thực thi. Cụm "có khả năng" rất đáng chú ý — bạn có thể đã phải báo cáo trước cả khi khách hàng thực sự gặp chuyện.

Điều 14(8) bổ sung một nghĩa vụ thứ hai chạy song song: bạn cũng phải thông báo cho những người dùng bị ảnh hưởng về lỗ hổng hoặc sự cố, và khi cần thì cả về các biện pháp khắc phục mà họ có thể thực hiện. Đó là một nhóm người nhận khác với CSIRT, đi theo con đường riêng.

## Ai thực sự chịu nghĩa vụ này?

**Nhà sản xuất sản phẩm có yếu tố số, dù đặt trụ sở ở đâu, cộng thêm những người quản lý (steward) phần mềm nguồn mở theo phạm vi hẹp hơn.** Một công ty ngoài EU bán hàng vào Liên minh không thoát khỏi nghĩa vụ này; quy định yêu cầu phải có một chủ thể kinh tế tại EU chịu trách nhiệm về các nghĩa vụ liên quan ([cyberresilienceact.eu](https://www.cyberresilienceact.eu/explained.html)).

Bạn báo cáo cho CSIRT được chỉ định làm điều phối viên tại quốc gia thành viên nơi bạn đặt cơ sở chính trong EU, đồng thời báo cho ENISA — nhưng bạn chỉ nộp **một lần**, qua Single Reporting Platform, và nền tảng này chuyển tiếp tới cả hai ([Ủy ban châu Âu](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting)).

Người quản lý phần mềm nguồn mở thuộc phạm vi điều chỉnh ở một phần xác định: nghĩa vụ tại Điều 14(1) áp dụng trong chừng mực họ tham gia phát triển sản phẩm có yếu tố số, còn Điều 14(3) và (8) áp dụng trong chừng mực các sự cố nghiêm trọng ảnh hưởng tới hệ thống mạng và thông tin mà họ cung cấp cho việc phát triển đó. Nếu bạn đang quản lý một dự án được dùng rộng rãi, hãy đọc Điều 24 cùng với Điều 14 thay vì mặc định theo một trong hai thái cực.

Điều 15 cũng cho phép báo cáo tự nguyện — về lỗ hổng, mối đe dọa mạng, sự cố và tình huống suýt xảy ra — từ nhà sản xuất cũng như bất kỳ ai khác. Báo cáo tự nguyện không tạo ra nghĩa vụ mới, nhưng vẫn dùng đúng nền tảng đó, và vẫn vướng đúng bài toán "phải có người còn thức".

## Vì sao hạn 24 giờ lại là một bài toán cảnh báo?

**Vì đồng hồ bắt đầu chạy khi bạn biết chuyện, mà việc biết chuyện hiếm khi rơi vào giờ hành chính.** Yếu tố kích hoạt là một sự việc đến được tổ chức của bạn, không phải một quyết định mà tổ chức bạn đưa ra.

Hãy nhìn xem sự việc đó thường đến từ đâu. Một nhà nghiên cứu bảo mật gửi email tới `security@` lúc 23:40 một tối thứ Bảy. Một khách hàng phía dưới mở ticket hỗ trợ mô tả việc bị khai thác. Một feed CVE hay KEV sáng đèn với một thành phần mà bạn đang dùng trong sản phẩm. Chính EDR của bạn phát hiện mã lạ chạy trong hệ thống build. Ghi chú chuẩn bị của DLA Piper chỉ ra rõ phiên bản chuỗi cung ứng của chuyện này: nhà sản xuất thường không phải người biết đầu tiên, và thông tin đến qua nhà nhập khẩu, nhà phân phối, nhà nghiên cứu hoặc nhà cung cấp linh kiện ([DLA Piper](https://www.dlapiper.com/en-us/insights/publications/2026/08/the-cras-24-hour-rule-preparing-for-the-cyber-resilience-acts-september-2026-reporting-obligations)).

Mọi con đường đó đều kết thúc bằng một thông báo mà thiết lập hiện tại của bạn nhiều khả năng gửi đi trong im lặng — một email trong hộp thư dùng chung, một tin nhắn Slack trong kênh không ai canh ban đêm, một ticket trong hàng đợi được phân loại vào thứ Hai. Không cái nào thất bại cả. Chúng gửi rất đúng, tới không một ai.

Ba chi tiết khiến khoảng trống này tệ hơn vẻ ngoài của nó:

- **Không có API.** ENISA nói thẳng rằng sẽ không cung cấp API báo cáo ở giai đoạn này. Bạn không thể để một script nộp cảnh báo sớm giùm trong lúc cả nhà đang ngủ.
- **Quyền truy cập phải thiết lập trước, cho từng người.** Người đại diện được ủy quyền phải đăng ký tài khoản EU Login, và CSIRT điều phối sẽ xác thực thẩm quyền của họ sau lần truy cập đầu tiên. Có một người đại diện chính và một người dự phòng, và lời mời gửi cho người dự phòng hết hạn sau bảy ngày ([Hỏi đáp của ENISA](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions), [cyberresilienceact.eu](https://www.cyberresilienceact.eu/news/enisa-srp-step-by-step-instructions-31-july-2026.html)). Nếu đúng người duy nhất có thể nộp lại không liên lạc được, hạn chót cũng chẳng quan tâm.
- **Mức phạt thuộc nhóm cao.** Điều 64 xếp việc không tuân thủ nghĩa vụ tại Điều 13 và 14 vào khung phạt hành chính "tới 15.000.000 EUR hoặc, nếu bên vi phạm là doanh nghiệp, tới 2,5% tổng doanh thu toàn cầu hằng năm của năm tài chính liền trước, tùy mức nào cao hơn" ([Điều 64](https://www.european-cyber-resilience-act.com/Cyber_Resilience_Act_Article_64.html)).

Một điểm cần nói cho công bằng về ý cuối, vì nó đổi cách tính toán với nhóm nhỏ: Điều 64 miễn phạt hành chính cho các nhà sản xuất thuộc diện siêu nhỏ hoặc nhỏ **khi trễ hạn** tại Điều 14(2)(a) hoặc 14(4)(a) — tức riêng mốc cảnh báo sớm 24 giờ. Nghĩa vụ báo cáo vẫn còn nguyên, và ngoại lệ này không mở rộng sang thông báo 72 giờ hay phần còn lại của Điều 14. Hãy đọc điều luật và hỏi ý kiến tư vấn, đừng tin lời một bài blog về chuyện công ty bạn rơi vào nhóm nào.

## Cảnh báo sớm 24 giờ thực ra gồm những gì?

**Rất ít — và đó chính là điểm mấu chốt.** Hướng dẫn của ENISA mô tả một bộ trường bắt buộc nhỏ ở giai đoạn cảnh báo sớm: loại thông báo (lỗ hổng hay sự cố), mức độ, thời điểm báo cáo, thông tin người báo cáo, tên nhà sản xuất hoặc steward, sản phẩm, một tiêu đề, và với sự cố thì thêm việc có nghi ngờ hành vi trái pháp luật hay cố ý phá hoại hay không. Các trường tùy chọn ở giai đoạn này gồm CVE ID hoặc EUVD ID.

Bức tranh kỹ thuật đầy đủ hơn — bản chất chung của lỗ hổng hay cách khai thác, đánh giá ban đầu, các biện pháp khắc phục và giảm nhẹ — thuộc về thông báo 72 giờ, chứ không phải 24 giờ đầu tiên.

Vậy nên cảnh báo sớm không phải một đề tài nghiên cứu. Nó là một biểu mẫu ngắn mà người đã chuẩn bị sẵn có thể nộp trong vài phút. Ràng buộc thật sự không nằm ở biểu mẫu, mà ở chỗ một người đã đăng ký, đã được ủy quyền và đang tỉnh táo có kịp biết chuyện hay không. Đó là bài toán định tuyến thông báo, và hôm nay đã giải được.

## Làm sao đặt một chiếc điện thoại đổ chuông vào trước đồng hồ 24 giờ?

Echobell biến một lệnh gọi webhook hoặc một email thành cảnh báo reo chuông và rung như cuộc gọi đến, và chính nhờ vậy nó xuyên qua được chế độ Tập trung và Không làm phiền trên iOS (xem bài [vượt qua chế độ Tập trung của iOS](/vi/blog/how-to-bypass-ios-focus-mode-for-critical-alerts)). Cách thiết lập dưới đây nằm bên cạnh quy trình ticket và PSIRT bạn đang chạy — nó không thay thế chúng.

### Bước 1 — Tạo một kênh dạng Cuộc gọi dành riêng cho các trường hợp CRA

Trong ứng dụng, hãy tạo một kênh và đặt kiểu thông báo là **Cuộc gọi** ([các kiểu thông báo](/vi/docs/notification)). Đặt tên theo quyết định mà nó kích hoạt, đừng theo nguồn dữ liệu: "CRA — đồng hồ 24h có thể đã chạy" hay hơn nhiều so với "Cảnh báo bảo mật".

Kênh này phải luôn im ắng. Nếu nó reo cho mọi khuyến cáo, mọi lần quét thất bại và mọi lần nâng phiên bản thư viện, người ta sẽ thôi nghe máy, và bạn đã tiêu phí kênh ồn ào duy nhất của mình vào tiếng ồn. Hãy đẩy những thứ đó đi nơi khác — [hướng dẫn về mệt mỏi vì cảnh báo](/vi/blog/fix-alert-fatigue-developer-guide) bàn về cách phân tách này.

Sao chép webhook URL của kênh trong phần chi tiết; nó có dạng `https://hook.echobell.one/t/<channel-token>`. Hãy coi nó là bí mật, vì ai cầm được nó cũng có thể làm điện thoại cả nhóm bạn reo lên ([hướng dẫn webhook](/vi/docs/webhook)).

Hãy đặt mẫu sao cho đọc được ngay trên màn hình khóa lúc 2 giờ sáng bởi một người còn nửa tỉnh nửa mê:

```
Title: Possible CRA report — {{product}}
Body: {{kind}} — {{summary}} (aware since {{time}} UTC)
```

`{{time}}`, `{{date}}`, `{{hour}}` và các [biến thời gian hệ thống](/vi/docs/template) khác luôn được chèn theo giờ UTC, nên thông báo vẫn ghi lại được dấu thời gian ngay cả khi bên gửi quên kèm. Dấu thời gian đó không phải bằng chứng pháp lý về thời điểm bạn bắt đầu biết chuyện, nhưng là một mốc hữu ích khi bạn dựng lại dòng thời gian về sau.

### Bước 2 — Trỏ các đường phát hiện của bạn vào kênh

Bất kỳ hệ thống nào gọi được webhook đều kích hoạt được kênh. Các trường bạn gửi lên sẽ trở thành biến trong mẫu:

```bash
curl -X POST https://hook.echobell.one/t/<channel-token> \
  -H "Content-Type: application/json" \
  -d '{
    "product": "Acme Gateway 4.x",
    "kind": "actively exploited vulnerability",
    "summary": "researcher report, working exploit attached",
    "craCandidate": true,
    "externalLink": "https://issues.internal.example/PSIRT-4412"
  }'
```

Biến đặc biệt `externalLink` trở thành một liên kết bấm được trong bản ghi thông báo, nên khi nghe máy xong, người trực chỉ cách ticket chứa chi tiết đúng một cú chạm.

Những nguồn đáng nối vào, xếp đại khái theo mức độ thường là tín hiệu đầu tiên:

- **Hàng đợi tiếp nhận của PSIRT hoặc bộ phận bảo mật** — bắn webhook khi một vấn đề được gắn nhãn là ứng viên CRA.
- **GitHub security advisories và cảnh báo Dependabot** trên các repository dùng để build sản phẩm đã phát hành ([tích hợp GitHub](/vi/docs/developer/github)).
- **SIEM, EDR hoặc WAF của bạn**, cho các phát hiện nhắm vào hạ tầng build, phát hành hoặc ký số — Điều 14(5) nói rõ là bao gồm cả sự cố có thể dẫn tới việc mã độc bị đưa vào.
- **Các feed thông tin lỗ hổng** bạn vốn đã theo dõi, lọc theo những thành phần xuất hiện trong SBOM của chính bạn.

### Bước 3 — Dùng điều kiện để chỉ những trường hợp hợp lý mới reo chuông

**Đây là bước giữ cho kênh còn đáng tin.** [Điều kiện](/vi/docs/conditions) trong Echobell đánh giá đúng những biến và HTTP header mà mẫu của bạn dùng, và kênh chỉ kích hoạt khi biểu thức đúng:

```
craCandidate == true && confirmed == true
```

Hoặc chặn theo header nếu hệ thống gửi không tự định dạng được phần thân:

```
header["x-cra-severity"] == "reportable"
```

Hãy đặt ngưỡng ở mức "một người đủ năng lực nên xem chuyện này trong vòng một tiếng", chứ không phải "chắc chắn phải báo cáo". Việc quyết định Điều 14 có được kích hoạt hay không là phán đoán cần một con người nắm dữ kiện; nhiệm vụ của kênh là đưa con người đó tới dữ kiện thật nhanh. Lọc quá tay mới là sai lầm đắt giá, vì một báo cáo bạn chưa từng bắt đầu còn tệ hơn một cuộc gọi hóa ra không cần thiết.

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

Phần lớn liên hệ đầu tiên từ bên ngoài công ty đến dưới dạng email — nhà nghiên cứu, khách hàng, CSIRT quốc gia, nhà cung cấp linh kiện. Mỗi kênh Echobell đều có thể có địa chỉ riêng, nên chỉ cần một quy tắc chuyển tiếp trên `security@` là những thư đó biến thành cuộc gọi ([kích hoạt qua email](/vi/docs/email-trigger)).

Kích hoạt qua email cung cấp các biến `from`, `to`, `subject`, `text` và `html`, nên bạn lọc được mà chẳng cần phân tích gì:

```
subject != "" && (from == "cert@vendor.example" || subject == "[EXPLOITED]")
```

Hãy đề nghị những bên hay báo cáo và các nhà cung cấp trọng yếu dùng một dấu hiệu thống nhất trong tiêu đề, rồi khớp theo đó. Đó là chi tiết nhỏ trong thỏa thuận nhưng biến một hộp thư lộn xộn thành tín hiệu định tuyến được.

### Bước 5 — Đưa mọi người đại diện đã đăng ký vào kênh

Hãy chia sẻ kênh với tất cả những ai thực sự nộp được báo cáo: người đại diện được ủy quyền chính, người dự phòng, và trưởng nhóm bảo mật có thể ra quyết định theo Điều 14. Mỗi người đăng ký tự chọn kiểu thông báo của mình, nên người đang trực có thể để ở **Cuộc gọi** còn những người còn lại dùng **Khẩn cấp**.

Đây chính là mục đích của cả bài tập này. SRP đòi một con người đã đăng ký và được xác thực. Nếu công ty bạn chỉ có đúng một người đăng ký, thì hạn 24 giờ của bạn có một điểm hỏng duy nhất phụ thuộc vào pin điện thoại.

### Bước 6 — Diễn tập trước ngày 11/9, đừng để sau

Hai bài diễn tập, cả hai đều đáng làm ngay trong tháng này:

1. **Đường cảnh báo.** Hãy chạy lệnh `curl` ở trên khi chế độ Không làm phiền thực sự đang bật, trên chính chiếc điện thoại sẽ nằm ở đầu giường ai đó. Bật **Gọi lại khi thất bại** trong ứng dụng để cuộc gọi hỏng một lần sẽ được thử lại. Một đường leo thang chưa thử chỉ là một giả định.
2. **Đường nộp báo cáo.** Hãy đi qua toàn bộ quy trình báo cáo trên giấy, theo hướng dẫn đăng ký và nộp từng bước của ENISA, vốn được cập nhật đến tháng 8/2026 ([ENISA SRP](https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp)). Hãy tạo tài khoản EU Login ngay bây giờ, xác nhận CSIRT nào là điều phối viên của bạn, và gửi sớm lời mời cho người đại diện dự phòng — nó hết hạn sau bảy ngày.

Bài diễn tập thứ hai có một điểm vướng đáng biết: tính đến hướng dẫn tháng 7 của ENISA, URL công khai của nền tảng vẫn được ghi là "sẽ cung cấp khi ra mắt", nên chưa thể thử toàn tuyến ([cyberresilienceact.eu](https://www.cyberresilienceact.eu/news/enisa-srp-step-by-step-instructions-31-july-2026.html)). ENISA cam kết nền tảng sẽ vận hành trước ngày 11/9/2026. Hãy diễn tập mọi thứ bạn kiểm soát được và đừng lấy việc nền tảng chưa sẵn sàng làm lý do trì hoãn phần của mình.

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

Nói rõ chuyện này ở đây quan trọng hơn bình thường, vì chủ đề liên quan đến pháp lý:

- **Nó không làm bạn tuân thủ.** Echobell là một kênh thông báo. Việc xác định phạm vi sản phẩm, vận hành quy trình xử lý lỗ hổng, quyết định Điều 14 có được kích hoạt hay không, đăng ký với SRP và nộp đúng hạn đều là việc của bạn. Chưa từng có công cụ cảnh báo nào tự nó hoàn thành một nghĩa vụ báo cáo.
- **Nó không nộp gì cả.** Không có API để nộp, và kể cả có thì Echobell cũng không phải thứ gọi API đó. Nó làm điện thoại reo; một con người đã đăng ký làm phần còn lại.
- **Nó không phải dấu thời gian pháp lý.** Biến `{{time}}` ghi lại thời điểm sự kiện kích hoạt đến Echobell, theo giờ UTC. Việc "bắt đầu biết chuyện" từ lúc nào là một câu hỏi dữ kiện về tổ chức của bạn, và hồ sơ sự cố của bạn — chứ không phải một thông báo đẩy — mới là thứ ghi nhận điều đó.
- **Nó không có chính sách leo thang hay xác nhận đã nhận.** Không có "nếu mười phút không ai nghe máy thì gọi người kế tiếp", không có lịch trực xoay vòng, không có nhật ký kiểm toán ai đã xác nhận gì. Muốn những thứ đó bạn cần một nền tảng quản lý sự cố — xem [các lựa chọn thay thế Opsgenie](/vi/blog/opsgenie-end-of-life-alternatives).
- **Nó không bảo đảm việc gửi tới nơi.** Một cuộc gọi phụ thuộc vào hạ tầng push, mạng và một chiếc điện thoại còn pin. Hãy xem nó là lớp giúp rút ngắn khoảng cách giữa lúc sự việc đến và lúc một người biết chuyện, chứ không phải một biện pháp kiểm soát bạn có thể trưng ra khi bị kiểm toán.
- **Nó không theo giờ địa phương.** Các biến thời gian dựng sẵn chỉ dùng UTC và không theo giờ mùa hè. Điều kiện khoanh vùng theo khung giờ cần được chỉnh tay hai lần mỗi năm.

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

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

Không. CRA đặt nghĩa vụ lên nhà sản xuất, và không ứng dụng thông báo nào gánh thay được. Cái Echobell xử lý là đúng một kiểu hỏng cụ thể: cảnh báo sớm 24 giờ bị lỡ vì người có thể nộp nó mãi tới ngày làm việc kế tiếp mới biết chuyện. Đó là kiểu hỏng có thật và phổ biến, nhưng nó chỉ là một phần trong một chương trình tuân thủ lớn hơn nhiều.

### Đồng hồ 24 giờ thực sự bắt đầu chạy khi nào?

Khi nhà sản xuất biết về lỗ hổng đang bị khai thác hoặc về sự cố nghiêm trọng. Quy định không định nghĩa một thời điểm chính xác, và việc "biết" phụ thuộc vào dữ kiện cùng tốc độ xác minh chúng ([DLA Piper](https://www.dlapiper.com/en-us/insights/publications/2026/08/the-cras-24-hour-rule-preparing-for-the-cyber-resilience-acts-september-2026-reporting-obligations)). Trên thực tế, điều này ủng hộ việc phân loại nhanh và có ghi chép: khoảng trống giữa lúc tín hiệu đến và lúc có người đánh giá càng dài thì về sau càng khó giải thích.

### Chúng tôi là công ty nhỏ. Có được miễn không?

Không được miễn nghĩa vụ báo cáo. Điều 64 miễn phạt hành chính cho doanh nghiệp siêu nhỏ và nhỏ, nhưng chỉ riêng cho việc trễ hạn 24 giờ tại Điều 14(2)(a) hoặc 14(4)(a). Nghĩa vụ báo cáo vẫn còn, thông báo 72 giờ và báo cáo cuối không bị ảnh hưởng, và định nghĩa doanh nghiệp siêu nhỏ với doanh nghiệp nhỏ không phải thứ bạn tự suy đoán. Hãy coi đó là một sự giảm nhẹ hẹp, không phải một tấm vé miễn trừ.

### Hộp thư bảo mật của chúng tôi được theo dõi trong giờ hành chính. Vậy chưa đủ sao?

Chỉ đủ nếu bạn chấp nhận mất tới hai phần ba khung thời gian vào một cuối tuần bình thường. Một báo cáo đến lúc 18:00 thứ Sáu để lại cho bạn hạn chót là 18:00 thứ Bảy. Theo dõi trong giờ hành chính là mặc định ổn cho mọi thứ khác; đồng hồ 24 giờ đúng là trường hợp mà nó không bao phủ.

### Bộ phận tuân thủ, pháp chế và kỹ thuật có nhận được cùng một cảnh báo không?

Có, và họ nên như vậy. Hãy chia sẻ chung một kênh, mọi người đăng ký đều được báo khi kênh kích hoạt, ai nấy tự chọn mức khẩn của mình. Kỹ sư xác nhận việc bị khai thác và người sẽ nộp biểu mẫu cần bắt đầu cùng một phút, không phải lần lượt.

### Cái này có giúp gì cho nghĩa vụ thông báo người dùng tại Điều 14(8) không?

Gián tiếp thôi. Điều 14(8) yêu cầu thông báo cho người dùng bị ảnh hưởng về lỗ hổng hay sự cố và, khi cần, cả các biện pháp khắc phục. Đó là việc truyền thông với khách hàng và cần các kênh riêng của bạn. Echobell có thể đánh thức những người phụ trách phần truyền thông đó cùng lúc với những người phụ trách việc nộp báo cáo, để hai luồng công việc khởi động cùng nhau.

### Chúng tôi đã báo cáo theo NIS2 hoặc DORA. Có phải cùng một chuyện không?

Không, dù hình dạng có phần giống nhau. NIS2 và DORA đặt nghĩa vụ lên các tổ chức dựa trên lĩnh vực và mức độ trọng yếu; CRA đặt nghĩa vụ lên nhà sản xuất dựa trên sản phẩm họ đưa ra thị trường EU. Một tổ chức có thể chịu cả ba, với những chiếc đồng hồ khác nhau và người nhận khác nhau. Nếu các khung này cũng nằm trong phạm vi của bạn, hãy xem [cảnh báo báo cáo sự cố theo DORA và NIS2](/vi/blog/dora-nis2-incident-reporting-alerts) — và lưu ý rằng lớp cảnh báo có thể dùng chung ngay cả khi nghĩa vụ thì không.

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

Thông báo dạng cuộc gọi được gửi như cảnh báo kiểu cuộc gọi, và đó là thứ giúp chúng xuyên qua chế độ Tập trung trên iOS. Không có phép màu nào ở đây: nó vẫn phụ thuộc vào thiết lập hệ điều hành, mạng và một chiếc điện thoại còn pin. Hãy thử trên đúng thiết bị, với chế độ Tập trung bật thật, trước khi bạn đặt niềm tin vào nó — và nhớ bật **Gọi lại khi thất bại**.

### Cái này chỉ có trên iOS thôi à?

Không. Echobell có trên iOS và trên [Android qua Google Play](https://play.google.com/store/apps/details?id=one.echobell.echobellandroid) ([bản phát hành Android](/vi/blog/echobell-android-release)). Cách hoạt động của cảnh báo kiểu cuộc gọi khác nhau giữa hai nền tảng, nên hãy thử trên đúng thiết bị mà người trực sẽ mang theo.

### Chúng tôi nên đưa gì vào payload webhook?

Tối thiểu là đủ để quyết định có nên bật dậy hay không: sản phẩm, loại tín hiệu, một dòng bối cảnh, và một `externalLink` trỏ tới ticket chứa chi tiết. Echobell giữ nội dung và lịch sử thông báo trên thiết bị, còn máy chủ chỉ lưu tài khoản, kênh và đăng ký ([mô hình quyền riêng tư](/vi/docs/features)), nhưng với tài liệu nhạy cảm về bảo mật thì thói quen đúng vẫn là gửi một con trỏ, không gửi nội dung.

---

## Bài liên quan

- [Cảnh báo báo cáo sự cố theo DORA và NIS2](/vi/blog/dora-nis2-incident-reporting-alerts)
- [Cách khắc phục mệt mỏi vì cảnh báo](/vi/blog/fix-alert-fatigue-developer-guide)
- [Cách vượt qua chế độ Tập trung của iOS cho cảnh báo nguy cấp](/vi/blog/how-to-bypass-ios-focus-mode-for-critical-alerts)
- [Các lựa chọn thay thế khi Opsgenie ngừng hoạt động](/vi/blog/opsgenie-end-of-life-alternatives)
- [Hướng dẫn tích hợp webhook](/vi/docs/webhook)
- [Kích hoạt qua email](/vi/docs/email-trigger)
- [Hướng dẫn về điều kiện](/vi/docs/conditions)