Hệ thống ứng phó sự cố mà các công ty phần mềm có người dùng tại EU cần phải hoàn thiện trước ngày 11 tháng 9 năm 2026

“Luật Khả năng phục hồi mạng (Cyber Resilience Act, Quy định (EU) 2024/2847; sau đây gọi tắt là CRA)” của Liên minh châu Âu (EU) đã được công bố trên Công báo vào ngày 20 tháng 11 năm 2024 và hiện đã có hiệu lực.
Bản gốc: QUY ĐỊNH (EU) 2024/2847 CỦA NGHỊ VIỆN CHÂU ÂU VÀ HỘI ĐỒNG

ngày 23 tháng 10 năm 2024

Tuy nhiên, việc áp dụng các nghĩa vụ này sẽ diễn ra theo từng giai đoạn; trên thực tế, nghĩa vụ báo cáo theo Điều 14 – có hiệu lực từ ngày 11 tháng 9 năm 2026 – sẽ là quy định đầu tiên được áp dụng. Mặc dù việc áp dụng các quy định chính (như việc tuân thủ các yêu cầu về an ninh và dán nhãn CE) sẽ bắt đầu từ ngày 11 tháng 12 năm 2027, nhưng riêng nghĩa vụ báo cáo về lỗ hổng bảo mật và sự cố sẽ được áp dụng sớm hơn hơn một năm.

Nói cách khác, đối với các doanh nghiệp đang cung cấp phần mềm cho thị trường EU, tại thời điểm viết bài này, thời gian chuẩn bị còn lại là chưa đầy 2 tháng. Trong bài viết này, chúng tôi sẽ tổng hợp những nội dung cần báo cáo, thời hạn báo cáo và địa chỉ gửi báo cáo dựa trên các quy định của CRA, cũng như những việc cần chuẩn bị ngay từ bây giờ.

Trước hết, liệu công ty chúng tôi có thuộc đối tượng áp dụng hay không?

Phạm vi áp dụng của CRA là “các sản phẩm có yếu tố kỹ thuật số (products with digital elements)”, bao gồm rộng rãi phần mềm và phần cứng được cung cấp dưới hình thức hoạt động thương mại trên thị trường EU (Điều 2 và Điều 3).

Không chỉ các phần mềm đóng gói và ứng dụng di động có thu phí, mà ngay cả các sản phẩm được phân phối miễn phí cũng có thể bị coi là “hoạt động thương mại” nếu có mục đích tạo ra doanh thu.

Điều cần lưu ý là cách xử lý các dịch vụ đám mây. Về nguyên tắc, bản thân SaaS không thuộc phạm vi của CRA mà thuộc phạm vi của Chỉ thị NIS2; tuy nhiên, việc xử lý dữ liệu từ xa (remote data processing) – vốn là yếu tố không thể thiếu đối với chức năng của sản phẩm – lại nằm trong phạm vi điều chỉnh của CRA (Điều 3 (2), phần mở đầu (11) và (12)).

Ví dụ, nếu một ứng dụng di động không thể hoạt động nếu thiếu API hoặc hệ thống backend do chính công ty phát triển, thì phần hệ thống backend đó cũng sẽ được coi là một phần của sản phẩm. Sẽ rất nguy hiểm nếu vội vàng kết luận rằng: “Công ty chúng tôi sử dụng đám mây nên không liên quan đến CRA”.

Ngoài ra, “nhà sản xuất (manufacturer)” có nghĩa vụ báo cáo là những doanh nghiệp đưa sản phẩm ra thị trường dưới thương hiệu riêng của mình (Điều 3 (13)). Ngay cả các doanh nghiệp Nhật Bản không có cơ sở tại khu vực EU cũng thuộc đối tượng áp dụng nếu họ cung cấp sản phẩm cho thị trường EU.

Điều 14: 3 bước gồm 2 giai đoạn và báo cáo cuối cùng

Nghĩa vụ báo cáo quy định tại Điều 14 chủ yếu áp dụng đối với hai loại sự kiện chính.

Thứ nhất là “lỗ hổng bảo mật đang bị khai thác tích cực (actively exploited vulnerability)”. Điều này đề cập đến trường hợp có bằng chứng đáng tin cậy cho thấy bên thứ ba có ý đồ xấu đã thực sự khai thác lỗ hổng đó (Điều 3 (42)). Việc phát hiện nhằm mục đích kiểm chứng và báo cáo của các nhà nghiên cứu bảo mật có thiện chí không thuộc phạm vi báo cáo bắt buộc này (Phần mở đầu (68)).

Thứ hai là “sự cố nghiêm trọng (severe incident) ảnh hưởng đến an ninh của sản phẩm ”. Tiêu chuẩn về mức độ “nghiêm trọng” được định nghĩa tại Điều 14 (5), bao gồm các trường hợp: (a) gây tổn hại (hoặc có khả năng gây tổn hại) đến tính sẵn sàng, tính xác thực, tính toàn vẹn và tính bảo mật của dữ liệu hoặc chức năng nhạy cảm hoặc quan trọng; (b) dẫn đến (hoặc có khả năng dẫn đến) việc đưa vào hoặc thực thi mã độc hại vào sản phẩm hoặc hệ thống của người dùng.Trong phần mở đầu (68), các trường hợp như kẻ tấn công cài đặt phần mềm độc hại vào kênh phát hành của nhà sản xuất, tức là các cuộc tấn công chuỗi cung ứng, đã được nêu làm ví dụ.

Cả hai sự kiện này đều có cấu trúc thời gian báo cáo giống nhau.

Thời điểm khởi đầu là “thời điểm nhà sản xuất nhận thức được sự việc (becoming aware)”. Đây không phải là thời điểm xảy ra vi phạm, nhưng cũng không có nghĩa là quá trình sẽ bị đình trệ chỉ vì phải chờ quyết định của ban lãnh đạo sau khi phát hiện sự việc trong nội bộ công ty. Xét đến các ngày nghỉ và chênh lệch múi giờ, tốt hơn hết là nên hiểu rằng thời hạn 24 giờ này thực chất yêu cầu phải có “một cơ chế để quy trình báo cáo bắt đầu ngay trong ngày phát hiện sự việc”.

Phải báo cáo ở đâu?

Hệ thống này được thiết kế sao cho các báo cáo sẽ được gửi đồng thời đến CSIRT phụ trách (CSIRT được chỉ định làm đơn vị điều phối) và ENISA thông qua nền tảng báo cáo duy nhất do ENISA (Cơ quan An ninh Mạng Liên minh Châu Âu) vận hành (Điều 14(1)(3), Điều 16).

Việc báo cáo cho CSIRT của quốc gia thành viên nào được quy định tại Điều 14(7). Nếu có trụ sở chính (trụ sở nơi chủ yếu đưa ra các quyết định liên quan đến an ninh mạng) trong lãnh thổ EU thì đó là quốc gia thành viên đó. Trong trường hợp không có trụ sở trong lãnh thổ EU, việc xác định sẽ được thực hiện theo thứ tự sau: ① quốc gia nơi đại lý ủy quyền phân phối nhiều sản phẩm nhất → ② quốc gia nơi nhà nhập khẩu đặt trụ sở → ③ quốc gia nơi nhà phân phối đặt trụ sở → ④ quốc gia thành viên có số lượng người dùng nhiều nhất.

Đối với các doanh nghiệp Nhật Bản, nếu chỉ bắt đầu tiến hành việc xác định này khi tình huống khẩn cấp xảy ra thì chắc chắn sẽ mất hơn 24 giờ; do đó, cần phải xác định rõ “cơ quan báo cáo của công ty là đâu” ngay từ thời bình.

Không chỉ dừng lại ở việc báo cáo cho cơ quan chức năng: Nghĩa vụ thông báo cho người dùng

Điều 14 (8) yêu cầu nhà sản xuất, khi phát hiện lỗ hổng bảo mật đang bị lợi dụng hoặc sự cố nghiêm trọng, phải thông báo cho người dùng bị ảnh hưởng (hoặc tất cả người dùng nếu cần thiết) và hướng dẫn các biện pháp giảm thiểu rủi ro cũng như khắc phục mà người dùng có thể thực hiện. Cần lưu ý rằng điều khoản này quy định rõ: nếu nhà sản xuất không thực hiện việc này kịp thời, CSIRT có thể thay mặt cung cấp thông tin cho người dùng. Điều này có nghĩa là ngay cả khi doanh nghiệp giữ im lặng, thông tin vẫn có thể được công bố thông qua các cơ quan chức năng.

Trong trường hợp vi phạm

Theo Điều 64, việc vi phạm các nghĩa vụ quy định tại Điều 13 và Điều 14 cũng như các yêu cầu bắt buộc tại Phụ lục I có thể bị phạt tiền tối đa 15 triệu euro hoặc 2,5% tổng doanh thu hàng năm trên toàn cầu, tùy theo mức nào cao hơn.Việc vi phạm các nghĩa vụ khác có thể bị phạt tối đa 10 triệu euro hoặc 2%; việc cung cấp thông tin sai lệch hoặc không đầy đủ cho cơ quan chức năng có thể bị phạt tối đa 5 triệu euro hoặc 1%. Ngoài ra, đối với các doanh nghiệp siêu nhỏ và nhỏ, sẽ không bị phạt tiền trong trường hợp quá thời hạn cảnh báo sớm 24 giờ (Điều khoản mở đầu (120)).

Điều có tác động mạnh hơn cả mức tiền phạt chính là khả năng cơ quan giám sát thị trường ra lệnh ngừng bán hoặc thu hồi sản phẩm. Việc bị loại khỏi thị trường EU sẽ gây tổn thất nặng nề hơn so với các biện pháp trừng phạt về mặt tài chính đối với nhiều doanh nghiệp.

Mối quan hệ với nghĩa vụ báo cáo hiện hành: Trước tiên cần xác định “vị trí” theo GDPR

Cần lưu ý rằng báo cáo CRA được thực hiện “bổ sung” cho các nghĩa vụ hiện có. Hơn nữa, trong trường hợp liên quan đến vi phạm dữ liệu cá nhân, cách thức xử lý của doanh nghiệp sẽ thay đổi đáng kể tùy thuộc vào vị trí của doanh nghiệp theo GDPR, tức là liệu doanh nghiệp đó là bên kiểm soát (controller) hay bên xử lý (processor). Nếu vấn đề này vẫn còn mơ hồ khi sự cố xảy ra, doanh nghiệp có thể nhầm lẫn về đối tượng nhận báo cáo và thời hạn báo cáo.

• Trường hợp doanh nghiệp đóng vai trò là người quản lý
  Trường hợp điển hình là khi doanh nghiệp trực tiếp cung cấp ứng dụng hoặc dịch vụ cho người tiêu dùng và tự quyết định mục đích cũng như phương thức xử lý dữ liệu cá nhân của người dùng cuối.

  Trong trường hợp này, khi phát hiện vi phạm dữ liệu cá nhân, công ty sẽ trực tiếp chịu trách nhiệm báo cáo cho cơ quan giám sát trong vòng 72 giờ theo quy định tại Điều 33 của GDPR. Hơn nữa, nếu vi phạm có khả năng gây ra rủi ro cao đối với quyền và tự do của cá nhân, thì theo Điều 34, công ty cũng phải thông báo cho chính chủ thể dữ liệu.

• Các trường hợp công ty chúng tôi đóng vai trò là bên xử lý

  Đây là trường hợp trong lĩnh vực SaaS và phần mềm B2B, khi dữ liệu cá nhân của nhân viên và khách hàng của doanh nghiệp khách hàng (= người quản trị) được xử lý theo chỉ thị của doanh nghiệp đó.

  Trong trường hợp này, bên phải chịu nghĩa vụ báo cáo cho cơ quan giám sát trong vòng 72 giờ là phía khách hàng với tư cách là người kiểm soát; còn nghĩa vụ pháp lý của công ty chúng tôi với tư cách là bên xử lý là phải thông báo cho người kiểm soát ngay khi phát hiện vi phạm, không được chậm trễ một cách vô lý, theo quy định tại Điều 33 (2).

  Dù có vẻ như câu “72 giờ không liên quan đến chúng tôi” là đúng, nhưng trên thực tế, công việc không đơn giản như vậy. Trong các Thỏa thuận xử lý dữ liệu (DPA) được ký kết với khách hàng, thường có quy định cụ thể về thời hạn thông báo (24 giờ, 48 giờ, v.v.) ngắn hơn so với quy định pháp luật “không được chậm trễ một cách bất hợp lý”; do đó, để đảm bảo tuân thủ thời hạn 72 giờ của mình, khách hàng thường đặt ra các yêu cầu về thời gian đối với bên xử lý dữ liệu nghiêm ngặt hơn so với tiêu chuẩn pháp luật.

  Việc rà soát các điều khoản thông báo trong các thỏa thuận xử lý dữ liệu (DPA) mà công ty đã ký kết, đồng thời phản ánh thời hạn hợp đồng ngắn nhất vào quy trình làm việc như một Thỏa thuận mức dịch vụ (SLA) thực tế của công ty, sẽ là điểm khởi đầu cho việc ứng phó với sự cố với tư cách là bên xử lý dữ liệu.

Ngoài ra, không hiếm trường hợp cùng một doanh nghiệp vừa đóng vai trò là người quản lý vừa là người xử lý dữ liệu tùy theo dòng sản phẩm hoặc chức năng (ví dụ: đóng vai trò là người xử lý dữ liệu trong nền tảng SaaS B2B chính, nhưng đóng vai trò là người quản lý dữ liệu khi xử lý thông tin tiếp thị nội bộ hoặc thông tin thanh toán). Do quy trình xử lý sẽ thay đổi tùy thuộc vào vai trò mà dữ liệu bị rò rỉ đang được xử lý ở thời điểm đó, nên cần phải xác định rõ vai trò này ngay từ giai đoạn lập bản đồ dữ liệu.

Điều quan trọng là nghĩa vụ của CRA phát sinh độc lập với vị trí này theo GDPR. Do nghĩa vụ báo cáo theo Điều 14 của CRA áp dụng trực tiếp đối với “nhà sản xuất”, nên cách suy luận rằng “chúng tôi chỉ là bên xử lý dữ liệu nên khách hàng sẽ là người giải quyết các vấn đề với cơ quan chức năng” sẽ không được chấp nhận trong khuôn khổ CRA. Ngay cả khi là bên xử lý dữ liệu, nếu xảy ra sự cố nghiêm trọng ảnh hưởng đến an ninh của sản phẩm do công ty sản xuất hoặc có lỗ hổng bảo mật đang bị khai thác, công ty vẫn phải chịu nghĩa vụ báo cáo cho CSIRT/ENISA.

Do đó, trong một sự cố, các yếu tố kích hoạt báo cáo tiếp theo có thể diễn ra đồng thời.

• Điều 14 của CRA: Ảnh hưởng đến an ninh sản phẩm → Báo cáo trong vòng 24 giờ, 72 giờ và báo cáo cuối cùng cho CSIRT/ENISA (nghĩa vụ của nhà sản xuất bất kể lập trường nào)

• Điều 33 của GDPR: Vi phạm dữ liệu cá nhân → Nếu là người kiểm soát dữ liệu thì phải thông báo cho cơ quan giám sát trong vòng 72 giờ; nếu là người xử lý dữ liệu thì phải thông báo cho người kiểm soát dữ liệu ngay lập tức (+thời hạn quy định trong hợp đồng với DPA)

• Điều 34 của GDPR: Vi phạm dữ liệu cá nhân có rủi ro cao → Người kiểm soát dữ liệu phải thông báo cho chủ thể dữ liệu

• Chỉ thị NIS2: Nghĩa vụ báo cáo trong trường hợp doanh nghiệp thuộc đối tượng điều chỉnh của NIS2, chẳng hạn như nhà cung cấp dịch vụ đám mây

Do đối tượng báo cáo, thời hạn và mẫu báo cáo đều khác nhau, nên nếu không thiết lập các điểm kiểm tra trong quy trình xử lý sự cố để xác định “sự việc này thuộc nghĩa vụ báo cáo theo quy định pháp luật hay hợp đồng nào”, thì chắc chắn sẽ gây ra sự hỗn loạn tại hiện trường.

Những việc cần chuẩn bị ngay từ bây giờ

Dựa trên nội dung điều luật, có thể thấy rằng trước ngày 11 tháng 9, cần phải chuẩn bị đầy đủ ít nhất 5 điểm sau đây.

1. Xác định đơn vị báo cáo

   Theo quy định tại Điều 14, khoản (7) nêu trên, cần xác định CSIRT của quốc gia thành viên nào sẽ là đầu mối báo cáo của công ty và ghi rõ điều này trong quy trình hướng dẫn.

2. Việc tích hợp định nghĩa CRA vào tiêu chuẩn phân loại sự cố

   Cần bổ sung các tiêu chí đánh giá “liệu sự cố có thuộc trường hợp ‘lỗ hổng bảo mật đang bị khai thác tích cực’ hay không” và “liệu sự cố có thuộc trường hợp ‘sự cố nghiêm trọng’ theo Điều 14 (5) hay không” vào quy trình xử lý sự cố hiện có, đồng thời thông báo rộng rãi cho tất cả các bên liên quan, bao gồm cả những người có thẩm quyền ra quyết định, rằng ngay khi sự cố đáp ứng các tiêu chí này, bộ đếm thời gian 24 giờ sẽ bắt đầu chạy. Việc thiết kế quy trình báo cáo lên cấp trên để đảm bảo quá trình ra quyết định vẫn diễn ra suôn sẻ ngay cả vào ban đêm hay ngày nghỉ là yếu tố then chốt.

3. Thứ ba, chuẩn bị trước mẫu báo cáo

   Thông tin có thể ghi chép trong vòng 24 giờ là có hạn. Nếu lập sẵn các mẫu biểu cho các mục cần thiết trong từng loại thông báo — cảnh báo sớm, thông báo 72 giờ và báo cáo cuối cùng (Điều 14 (2)(4)) — thì khi có sự cố, chúng ta sẽ không phải bắt đầu cuộc thảo luận từ việc “nên ghi gì”.

4. Quy trình thông báo cho người dùng

   Cần xác định trước phương pháp xác định người dùng bị ảnh hưởng, các phương thức thông báo (thông báo trong ứng dụng, email, đăng tải trên trang web) cũng như quy trình phê duyệt nội dung thông báo. Do có thể xảy ra trường hợp trùng lặp với quy định về thông báo cho chủ thể dữ liệu theo GDPR (Điều 34), việc thiết lập một cơ chế có sự tham gia của bộ phận pháp chế và truyền thông là giải pháp thực tế.

5. Xác định rõ vị trí pháp lý theo GDPR và rà soát DPA

    Chúng tôi sẽ xác định rõ vai trò của công ty (là bên quản lý hay bên xử lý) đối với từng sản phẩm và chức năng bằng cách liên kết với bản đồ dữ liệu, đồng thời lập danh sách các điều khoản về thông báo vi phạm trong các thỏa thuận DPA đã ký kết với khách hàng (thời hạn thông báo, phương thức thông báo, nội dung cần nêu). Khi chồng các mốc thời gian lên một dòng thời gian duy nhất – bao gồm 24 giờ theo CRA, 72 giờ theo GDPR và thời hạn hợp đồng theo DPA – chúng ta sẽ thấy rõ những công việc cần triển khai song song trong những giờ đầu tiên khi xảy ra sự cố.

Ngoài ra, để chuẩn bị cho việc áp dụng chính thức vào tháng 12 năm 2027, bên cạnh hệ thống báo cáo, cũng cần phải tuân thủ các quy định liên quan đến toàn bộ quy trình xử lý lỗ hổng bảo mật (chính sách công bố lỗ hổng bảo mật một cách phối hợp, xây dựng SBOM, thiết lập thời gian hỗ trợ tối thiểu 5 năm, cung cấp các bản cập nhật bảo mật miễn phí, thiết lập một đầu mối liên hệ duy nhất cho người dùng, v.v.Điều 13 và Phụ lục I). Việc tuân thủ nghĩa vụ báo cáo nên được xem là bước đầu tiên trong bức tranh tổng thể đó.

Lời kết

Nếu chỉ nhìn vào con số “72 giờ”, nghĩa vụ báo cáo theo CRA có vẻ tương tự như GDPR; tuy nhiên, về bản chất, hai quy định này có sự khác biệt đáng kể: trước tiên là có cảnh báo sớm trong vòng 24 giờ; đối tượng báo cáo là các sự cố an ninh sản phẩm chứ không phải vi phạm dữ liệu cá nhân; cơ quan tiếp nhận báo cáo là CSIRT/ENISA chứ không phải cơ quan bảo vệ dữ liệu; và nghĩa vụ này được áp dụng trực tiếp cho nhà sản xuất, bất kể họ là người kiểm soát hay người xử lý dữ liệu. Do đó, không thể áp dụng nguyên vẹn hệ thống tuân thủ GDPR vào trường hợp này.

Mặc dù thời hạn đang đến gần, nhưng 5 điểm nêu trên không đòi hỏi phải đầu tư lớn vào hệ thống, mà chủ yếu là việc bổ sung vào quy trình ứng phó sự cố hiện có và thông báo cho các bên liên quan. Trước tiên, chúng tôi khuyên quý vị nên bắt đầu bằng việc xác nhận xem sản phẩm của công ty mình có thuộc đối tượng áp dụng của CRA hay không, đồng thời xác định CSIRT là đơn vị tiếp nhận báo cáo.

Và thế là Incident Lake

Như chúng ta đã thấy ở trên, trong công tác ứng phó sự cố kể từ khi có CRA, ngoài tốc độ ứng phó, điều được yêu cầu còn là khả năng “ghi chép và duy trì tình trạng sẵn sàng báo cáo đúng hạn ”.

Để phát đi cảnh báo sớm trong vòng 24 giờ, cần phải ghi lại toàn bộ diễn biến sự việc ngay từ thời điểm phát hiện; hơn nữa, nếu phải tìm lại thông tin từ các nguồn rải rác trên Slack hay các hệ thống vé hỗ trợ trong quá trình xử lý sự cố để bổ sung vào báo cáo cuối cùng — bao gồm nguyên nhân gốc rễ cùng các biện pháp đã thực hiện và đang triển khai — thì sẽ không thể đáp ứng được thời hạn. Điều này càng trở nên cấp bách hơn nếu việc thông báo cho khách hàng theo quy định của Cơ quan Bảo vệ Dữ liệu (DPA) thuộc GDPR cũng phải được tiến hành song song.

“Incident Lake” – hệ thống AI dựa trên Agentic chuyên về quản lý sự cố mà chúng tôi đang phát triển – chính là sản phẩm được thiết kế để giải quyết thách thức này. Hệ thống này tổng hợp các thông tin về quá trình xử lý sự cố, vốn đang phân tán trong các cuộc trò chuyện trên Slack hay các công cụ hiện có như Jira, vào một bản ghi sự cố duy nhất, đồng thời lưu lại theo trình tự thời gian các thông tin như dòng thời gian, đánh giá mức độ nghiêm trọng cùng lịch sử thay đổi, các tác vụ xử lý và phạm vi ảnh hưởng.

Các quy trình được nêu trong bài viết này, chẳng hạn như “xác định xem sự cố có thuộc loại sự cố nghiêm trọng (severe incident) theo tiêu chuẩn CRA hay không” và “quản lý các mốc thời gian 24 giờ, 72 giờ và 1 tháng”, có thể được tích hợp vào danh sách kiểm tra SOP để ngăn ngừa việc bỏ sót các bước xử lý; đồng thời, nhờ có thể soạn thảo bản nháp báo cáo dựa trên các hồ sơ đã lưu trữ, nên sẽ giúp giảm đáng kể khối lượng công việc lập hồ sơ cho báo cáo cuối cùng.

Thiết kế này cho phép tích lũy các tiêu chí đánh giá riêng của tổ chức và những bài học kinh nghiệm từ quá khứ theo thời gian sử dụng, từ đó nâng cao độ chính xác của sự hỗ trợ từ AI.

Nếu quý vị mong muốn biến việc tuân thủ nghĩa vụ báo cáo của CRA từ “công việc thủ công mang tính tạm bợ” thành một “hệ thống” thực sự, xin hãy tham khảo Incident Lake.

Bài viết này chỉ nhằm cung cấp thông tin chung dựa trên nội dung của Quy định (EU) 2024/2847 (phiên bản đăng trên Công báo ngày 20 tháng 11 năm 2024) và không phải là tư vấn pháp lý. Để có đánh giá cụ thể về việc áp dụng, quý vị nên tham khảo ý kiến của các chuyên gia như luật sư am hiểu về luật pháp EU.