Ngày 11 tháng 9 năm 2026, nghĩa vụ báo cáo theo CRA có hiệu lực — Làm thế nào để các doanh nghiệp phần mềm chuẩn bị cho hệ thống cảnh báo sớm 24 giờ?
Tác giả của bài viết này
Chuyên gia về quyền riêng tư
Kohei Kurihara
【Miễn trừ trách nhiệm】 Bài viết này được viết dựa trên quan điểm cá nhân của tác giả, và tác giả không có chứng chỉ hành nghề luật sư. Xin lưu ý rằng bài viết này không nhằm mục đích tư vấn pháp lý.
Lời mở đầu
Ngày 23 tháng 10 năm 2024, Luật Khả năng phục hồi mạng của Liên minh châu Âu (sau đây gọi tắt là EU CRA) đã được thông qua. Luật này được thiết kế nhằm yêu cầu các sản phẩm kết nối với các yếu tố kỹ thuật số (viễn thông) trong khu vực châu Âu phải đáp ứng các yêu cầu về an ninh mạng.
Đối với các doanh nghiệp kinh doanh sản phẩm tại châu Âu, do các quy định về an ninh mạng sẽ có sự thay đổi, nên cần phải xác nhận lịch trình trong thời gian tới và sắp xếp các nội dung cần thực hiện. Đặc biệt, kể từ ngày 11 tháng 9 trở đi sẽ phát sinh nghĩa vụ báo cáo, vì vậy điều quan trọng là trước tiên phải xác nhận những nội dung cần có biện pháp ứng phó ban đầu.
Bối cảnh ban hành Luật Khả năng phục hồi mạng và lịch trình trong thời gian tới
Về bối cảnh dẫn đến việc ban hành luật này, mặc dù đã có các quy định áp dụng cho các sản phẩm cụ thể trong khu vực châu Âu, nhưng chưa có cơ chế nào yêu cầu áp dụng pháp luật một cách toàn diện; do đó, Quy định khung về Danh mục L được ban hành ngày 15 tháng 1 năm 2013, Quy định về giám sát thị trường châu Âu được ban hành ngày 20 tháng 6 năm 2019, cùng với việc sửa đổi Chỉ thị về các vụ kiện tập thể của người tiêu dùng được ban hành ngày 25 tháng 11 năm 2020, đã dẫn đến việc ban hành Quy định về Cơ quan Giám sát Tiêu dùng châu Âu (EU CRA).
Một trong những điểm mà các doanh nghiệp cần chú ý về EU CRA là luật này có một số khía cạnh liên quan đến cả việc bảo vệ dữ liệu lẫn bảo vệ người tiêu dùng. Theo Công báo Liên minh Châu Âu được ban hành vào ngày 20 tháng 11 năm 2024, việc thực hiện các biện pháp an ninh mạng sẽ giúp bảo vệ dữ liệu cá nhân của người tiêu dùng và các tổ chức, đồng thời cũng đề cập đến việc bảo vệ quyền riêng tư của cá nhân.
Thoạt nhìn, có những phần dường như là luật nhằm tăng cường an ninh mạng, nhưng văn bản cũng nêu rõ rằng cơ quan quản lý thị trường sẽ phối hợp với cơ quan quản lý bảo vệ dữ liệu để thực hiện công tác giám sát, đồng thời yêu cầu phải xem xét các biện pháp an ninh mạng từ góc độ của người tiêu dùng sử dụng sản phẩm.
Để chuẩn bị cho việc có hiệu lực vào ngày 11 tháng 12 năm 2027, các công tác chuẩn bị về mặt môi trường, bao gồm cả việc tiêu chuẩn hóa, đang được tiến hành. Về lịch trình trong thời gian tới, tác giả đã lập một biểu đồ thời gian theo trình tự thời gian dựa trên thông tin được công bố trên trang web của công ty i46 s.r.o.
※Dòng thời gian này là lịch trình dự kiến tại thời điểm hiện tại và không nhất thiết phải diễn ra đúng theo lịch trình này.
Ngày | Các mốc quan trọng | Chi tiết và các vấn đề cần xử lý |
|---|---|---|
Ngày 11 tháng 9 năm 2026 | Việc áp dụng nghĩa vụ báo cáo | ・Nghĩa vụ báo cáo của các nhà sản xuất: Trong trường hợp phát hiện lỗ hổng bảo mật bị lợi dụng hoặc xảy ra sự cố nghiêm trọng, các nhà sản xuất có nghĩa vụ phải báo cáo cho Cơ quan An ninh mạng Liên minh Châu Âu (sau đây gọi tắt là ENISA) và các CSIRT của các quốc gia. |
Ngày 31 tháng 10 năm 2026 | Phát triển và hoàn thiện các tiêu chuẩn cốt lõi ban đầu | ・Dự kiến sẽ hoàn tất việc xây dựng hai tiêu chuẩn chính (phát triển bảo mật và ứng phó với lỗ hổng bảo mật). *Thời hạn này đã được lùi lại 2 tháng so với thời hạn ban đầu là ngày 30 tháng 8 năm 2026, theo bản dự thảo sửa đổi vào tháng 7 năm 2026. |
Ngày 31 tháng 12 năm 2026 | Phát triển và hoàn thiện các tiêu chuẩn cho từng sản phẩm | ・Thực hiện việc phát triển và hoàn thiện tiêu chuẩn cho từng sản phẩm. *Thời hạn ban đầu là ngày 30 tháng 10 năm 2026, nhưng theo dự thảo sửa đổi của Ủy ban Châu Âu vào tháng 7 năm 2026, thời hạn này đã được lùi lại 2 tháng, đến ngày 31 tháng 12 năm 2026. |
Ngày 30 tháng 10 năm 2027 | Phát triển và hoàn thiện các tiêu chuẩn mang tính liên ngành | ・Tiến hành xây dựng và hoàn thiện các tiêu chuẩn mang tính tổng hợp, đồng thời chuẩn bị để các nhà sản xuất có thể tuân thủ các tiêu chuẩn mà chúng tôi đã bắt đầu triển khai từ 1 năm trước. |
Ngày 11 tháng 12 năm 2027 | Việc thi hành toàn diện và áp dụng đầy đủ luật | ・Tuân thủ tất cả các điều kiện: Phải tuân thủ tất cả các điều kiện theo quy định của pháp luật. |
Nếu xem xét theo lộ trình dự kiến, có thể dự đoán rằng trong năm nay, công tác xây dựng tiêu chuẩn chung sẽ được triển khai, và trước khi quy định có hiệu lực, việc xây dựng các tiêu chuẩn mang tính liên ngành sẽ được tiến hành, không chỉ giới hạn ở các tiêu chuẩn sản phẩm. Trước mắt, việc đặt mục tiêu là “việc áp dụng nghĩa vụ báo cáo” sẽ bắt đầu từ ngày 11 tháng 9 và triển khai các biện pháp một cách tuần tự được cho là hợp lý.
Các yêu cầu liên quan đến việc áp dụng nghĩa vụ báo cáo
Tại Điều 14 của Quy định EU về An ninh mạng (EU CRA), các nhà sản xuất có nghĩa vụ báo cáo tình trạng lỗ hổng bảo mật cho ENISA thông qua CSIRT với tư cách là đơn vị điều phối. Theo Điều 14, nhằm mục đích thực hiện nghĩa vụ báo cáo này, ENISA yêu cầu các nhà sản xuất báo cáo các nội dung sau đây thông qua Hệ thống Báo cáo An ninh (SRP) do ENISA cung cấp.
※CSIRT là viết tắt của Computer Security Incident Response Team (Đội ứng phó sự cố an ninh máy tính). Theo “Hiệp hội CSIRT Nhật Bản”, đây là “tên gọi chung của các tổ chức chuyên xử lý các sự cố liên quan đến an ninh máy tính. Đây là đội thực hiện các hoạt động như liên tục thu thập và phân tích thông tin về sự cố, lỗ hổng bảo mật, dấu hiệu tấn công, cũng như xây dựng chính sách và quy trình ứng phó”.
Các giai đoạn | Thời hạn | Mục đích của báo cáo | Nội dung báo cáo chính |
Giai đoạn 1: Báo cáo ban đầu | Trong vòng 24 giờ | Chia sẻ tình hình kịp thời | ・Thông báo về việc phát hiện sự cố |
Giai đoạn 2: Báo cáo giữa kỳ | Trong vòng 72 giờ | Cập nhật tình hình hiện tại | ・Thông tin chi tiết về lỗ hổng bảo mật |
Giai đoạn 3: Báo cáo cuối cùng | Trong vòng 14 ngày kể từ khi các biện pháp khắc phục hoặc giảm nhẹ có hiệu lực | Báo cáo về việc rà soát sau sự cố và các biện pháp khắc phục lâu dài | ・Thực hiện các biện pháp giảm thiểu rủi ro (cài đặt các bản cập nhật bảo mật, v.v.) |
*Bảng này do tác giả lập dựa trên thông tin được công bố trên Công báo Liên minh Châu Âu
Ngoài ra, quy định này cũng quy định nghĩa vụ báo cáo về các sự cố an ninh có thể đe dọa đến sản phẩm. Tại Điều 14, nhằm mục đích thực hiện nghĩa vụ báo cáo, quy định yêu cầu báo cáo các nội dung sau đây thông qua SRP do ENISA cung cấp.
Các giai đoạn | Thời hạn | Mục đích của báo cáo | Nội dung báo cáo chính | |
Giai đoạn 1: Báo cáo ban đầu | Trong vòng 24 giờ | Chia sẻ tình hình kịp thời | ・Thông báo phát hiện mối đe dọa và sự cố | ・Phạm vi ảnh hưởng trong khu vực châu Âu (các sản phẩm được phân phối và tình hình thiệt hại) |
Giai đoạn 2: Báo cáo giữa kỳ | Trong vòng 72 giờ | Đánh giá tình hình và chia sẻ phương án ứng phó | ・Thông tin chi tiết và đánh giá về sự cố | ・Giảm thiểu thiệt hại tạm thời |
Giai đoạn 3: Báo cáo cuối cùng | Trong vòng 1 tháng kể từ khi nộp báo cáo 72 giờ | Báo cáo về việc rà soát sau sự cố và thực hiện các biện pháp giảm thiểu | ・Hoàn tất việc thực hiện các biện pháp giảm thiểu thiệt hại ・Xác định chi tiết sự cố và phạm vi ảnh hưởng | ・Thông tin cụ thể về mối đe dọa gây ra sự cố |
*Bảng này do tác giả lập dựa trên thông tin được công bố trên Công báo Liên minh Châu Âu
CSIRT (đơn vị điều phối) là nơi tiếp nhận các báo cáo về lỗ hổng bảo mật và sự cố sẽ là CSIRT của quốc gia thành viên nơi đặt trụ sở chính (cơ sở kinh doanh chính) của nhà sản xuất tại khu vực châu Âu, nơi nhà sản xuất chủ yếu thực hiện các quyết định liên quan đến an ninh mạng. Tuy nhiên, việc thành lập trụ sở tại châu Âu không phải là điều kiện bắt buộc để thực hiện việc báo cáo. Trong trường hợp nhà sản xuất không có trụ sở chính tại khu vực châu Âu, quốc gia thành viên có thẩm quyền (CSIRT) sẽ được xác định theo thứ tự ưu tiên sau đây.
Mức độ ưu tiên | Tiêu chí ra quyết định | Các quốc gia thành viên liên quan (CSIRT có thẩm quyền) |
Ưu tiên hàng đầu | Đại diện được ủy quyền | Quốc gia thành viên nơi đại lý được ủy quyền, hành động thay mặt nhà sản xuất, có trụ sở kinh doanh (dựa trên tiêu chí là đại lý có lượng sản phẩm liên quan được xử lý nhiều nhất) |
Ưu tiên thứ hai | Nhà nhập khẩu | Các quốc gia thành viên nơi các nhà nhập khẩu – những đơn vị phân phối nhiều sản phẩm của các nhà sản xuất nhất ra thị trường – đặt trụ sở |
Ưu tiên thứ 3 | Nhà phân phối | Các quốc gia thành viên nơi các nhà phân phối cung cấp nhiều sản phẩm của các nhà sản xuất nhất ra thị trường có trụ sở kinh doanh |
Ưu tiên thứ 4 | Người dùng cuối | Quốc gia thành viên có số lượng người dùng sản phẩm của nhà sản xuất nhiều nhất |
*Bảng này do tác giả lập dựa trên thông tin được công bố trên Công báo Liên minh Châu Âu
Nhà sản xuất liên quan phải thông báo một cách thích hợp cho người tiêu dùng về các lỗ hổng bảo mật và các sự cố an ninh tiềm ẩn trong sản phẩm. Về nội dung thông báo, ngoài việc nêu rõ đó là lỗ hổng hay sự cố, nhà sản xuất còn phải cung cấp thông tin về các biện pháp giảm thiểu rủi ro và các biện pháp khắc phục. Hơn nữa, để người tiêu dùng có thể tự xử lý các lỗ hổng và sự cố, thông báo cần được trình bày theo một định dạng có cấu trúc và có thể đọc được bằng máy.
Trong trường hợp nhà sản xuất không thể thông báo trực tiếp cho người tiêu dùng, CSIRT sẽ được chỉ định làm đơn vị điều phối để thực hiện việc thông báo thích hợp cho người tiêu dùng.
Tích hợp với Nền tảng Báo cáo Đơn nhất do ENISA cung cấp
Để thực hiện một cách đơn giản các nghĩa vụ báo cáo đã được giới thiệu ở trên thông qua hệ thống, Điều 16 của Luật Khả năng phục hồi mạng quy định rằng ENISA phải thiết lập SRP. ENISA sẽ chịu trách nhiệm thiết kế và quản lý SRP, và hệ thống này dự kiến sẽ được thiết kế để cho phép thực hiện việc báo cáo thông qua thông báo điện tử.
※Dựa trên tài liệu công bố của ENISA, tác giả đã tổng hợp bức tranh toàn cảnh về “Single Reporting Platform (SRP)”
Sau khi SRP gửi thông báo báo cáo, cùng với việc thông báo được chuyển đến CSIRT của thị trường châu Âu liên quan, ENISA cũng sẽ nhận được thông báo tương tự. Ngoài ra, báo cáo sẽ được chuyển đến cơ quan giám sát thị trường của quốc gia đó thông qua CSIRT, và cơ quan này sẽ đưa ra quyết định về việc có tiến hành thực thi hay không.
Theo lịch trình đã nêu ở trên, việc áp dụng nghĩa vụ báo cáo thông qua SRP sẽ bắt đầu từ ngày 11 tháng 9 năm 2026, do đó, cần phải rà soát trước tình hình thực hiện, bao gồm cả việc có hay không có báo cáo.
Quy trình đăng ký Nền tảng Báo cáo Đơn nhất (SRP)
Từ đây, chúng tôi sẽ giới thiệu từng bước về quy trình đăng ký SRP, dịch vụ sẽ có thể sử dụng được từ ngày 11 tháng 9 trở đi.
1. Chọn người phụ trách làm đại diện và đăng ký vào EU Login
Khi sử dụng SRP, quý vị cần chỉ định một đại diện được gọi là “Assigned Representative” (sau đây gọi tắt là AR) để thực hiện việc báo cáo. AR cần đăng nhập vào hệ thống EU trước bằng email và mật khẩu, sau đó điền thông tin đăng ký.
※Trang đăng nhập EU mà tác giả đã đăng ký
Bằng cách đăng ký AR trước và xác minh nội dung đăng ký, nhà sản xuất hoặc người quản lý phần mềm mã nguồn mở sẽ có thể thực hiện báo cáo thông qua AR. Về AR, việc xác minh sẽ do CSIRT thực hiện (điều này không phải là nghĩa vụ khi thực hiện báo cáo); tuy nhiên, do quy trình xác minh khác nhau tùy theo CSIRT của từng quốc gia liên quan, nên trong trường hợp cần phải thông báo đặc biệt, nhà sản xuất hoặc người quản lý phần mềm mã nguồn mở sẽ phải tự thực hiện việc xác minh.
2. Đăng ký vào SRP
Khi đăng ký SRP, bạn cần điền các thông tin cần thiết theo các bước hướng dẫn trên biểu mẫu đăng ký.
Bước | Các công việc cần thực hiện | Chi tiết và nội dung nhập |
Chuẩn bị | Xác thực EU Login | Đăng nhập vào hệ thống bằng tài khoản EU Login |
Bước 1 | Xác nhận các điều khoản đồng ý | Xác nhận và đồng ý với các điều khoản pháp lý (Điều khoản sử dụng, Chính sách bảo mật, v.v.) |
Bước 2 | Xác nhận thông tin tài khoản | Kiểm tra xem các thông tin cơ bản đã đăng ký trước đó (họ, tên, địa chỉ email, tên chính thức của pháp nhân) có chính xác hay không |
Bước 3 | Nhập thông tin nhà sản xuất | Ghi rõ thông tin chi tiết về doanh nghiệp (tên pháp lý, địa chỉ trụ sở, và các thông tin bổ sung cần thiết khác) |
Bước 4 | Cài đặt vai trò (Đăng ký AR) | Trong quy trình đăng ký, hãy chọn và đăng ký vai trò AR (Đại diện được chỉ định) cho người dùng, sau đó nhấp vào “Tiếp tục” |
Bước 5 | Lựa chọn CSIRT có thẩm quyền | Từ menu thả xuống, hãy chọn CSIRT cần chỉ định, sau đó nhấp vào “Tiếp tục” để hoàn tất |
※Do trang web của SRP chưa được công bố tại thời điểm viết bài này, tác giả đã tham khảo Hướng dẫn đăng ký do ENISA công bố (phiên bản công bố ngày 31 tháng 7 năm 2026 và cập nhật ngày 3 tháng 8) để trình bày nội dung. Do chính ENISA đã lưu ý rằng “nội dung có thể thay đổi”, nên khi tiến hành đăng ký thực tế, quý vị vui lòng tham khảo hướng dẫn mới nhất.
Khi quá trình đăng ký hoàn tất và được phê duyệt, AR sẽ chính thức hợp tác với nhà sản xuất; ngoài việc tài khoản được kích hoạt, AR còn được chỉ định đảm nhận vai trò chính. Cùng với email xác nhận, nếu thông tin về nhà sản xuất đã được cung cấp, thông tin này cũng sẽ được đăng ký vào SRP.
※Sau khi hoàn tất đăng ký AR chính, trong một số trường hợp, bạn có thể gửi email mời đến AR phụ (AR phụ trong trường hợp AR chính là tài khoản chính) để thực hiện đăng ký. Trong trường hợp này, AR phụ sẽ mở email được gửi từ AR chính và tiến hành thủ tục đăng ký. Lúc đó, vì lời mời sẽ được gửi từ AR chính, AR phụ chỉ cần chấp nhận lời mời là quá trình đăng ký sẽ hoàn tất. Sau khi đăng ký, AR phụ sẽ hoạt động với tư cách là người dùng dự phòng của AR chính.
Quy trình báo cáo trên Nền tảng Báo cáo Đơn nhất (SRP)
AR phải gửi thông báo báo cáo thông qua SRP. Nội dung báo cáo bao gồm hai loại: báo cáo lỗ hổng bảo mật (Actively Exploited Vulnerability, sau đây gọi tắt là AEV) và sự cố nghiêm trọng (Severe Incident, sau đây gọi tắt là SI). Mục đích của báo cáo này là yêu cầu CSIRT có liên quan xem xét và thảo luận về các biện pháp ứng phó trong tương lai. Đối với việc báo cáo, các bước xử lý đối với báo cáo ban đầu, báo cáo sau 72 giờ và báo cáo cuối cùng sẽ được thực hiện theo các thủ tục sau đây.
Giai đoạn báo cáo | Xác nhận trước và các thao tác cần thực hiện | Nội dung ghi chép | Xác định nội dung thông báo và nộp | Xử lý sau khi hoàn tất・Ghi chú |
| Chọn “Thông báo báo cáo mới” từ SRP (tải thông tin AR đã đăng ký trước đó) | • Thông tin cần thiết cho thông báo báo cáo ban đầu | Chọn “Gửi thông báo” hoặc “Lưu nội dung đã nhập” | Sau khi gửi, CSIRT sẽ tiến hành xác minh. Khi hoàn tất, thông báo “Đã hoàn tất xác minh” và “Thời gian xử lý” sẽ được hiển thị |
Báo cáo 72 giờ | Sau khi đăng nhập vào SRP, hãy mở trang tổng quan, kiểm tra nội dung báo cáo ban đầu, rồi chọn mục “Báo cáo ban đầu” tương ứng | Các trường bắt buộc trong tab “Báo cáo 72 giờ” | Chọn “Gửi thông báo” hoặc “Lưu nội dung đã nhập” | |
Báo cáo cuối cùng | Sau khi đăng nhập vào SRP, hãy mở trang tổng quan, kiểm tra nội dung báo cáo trong 72 giờ và chọn “Báo cáo cuối cùng” tương ứng | Các trường bắt buộc trong tab “Báo cáo cuối cùng” | Chọn “Gửi thông báo” hoặc “Lưu nội dung đã nhập” |
* Bảng này do tác giả lập dựa trên thông tin được công bố trên trang web của ENISA
Ngoài các thủ tục trong giai đoạn thông báo báo cáo, nếu chưa đến hạn chót sửa đổi thông báo báo cáo hoặc chưa nộp báo cáo cuối cùng, thì có thể sửa đổi nội dung thông báo báo cáo.
Hãy kiểm tra mẫu nội dung báo cáo và chuẩn bị sẵn sàng trước khi SRP được công bố vào ngày 11 tháng 9.
Như đã giới thiệu ở trên, việc ứng dụng SRP sẽ giúp việc thực hiện thủ tục báo cáo và thông báo trở nên đơn giản hơn; do đó, cần phải kiểm tra trước các bước thực hiện thủ tục này và chuẩn bị sẵn sàng trước khi hệ thống chính thức đi vào hoạt động vào ngày 11 tháng 9.
Dưới đây là mẫu các mục cần ghi trong thông báo báo cáo mà ENISA đã công bố trong phần Câu hỏi thường gặp (FAQ).
Các mục chung | Báo cáo ban đầu (trong vòng 24 giờ) | Báo cáo 72 giờ | Báo cáo cuối cùng | |
1 | Loại thông báo (Lỗ hổng bảo mật/Sự cố) | X | C | C |
2 | Loại thông báo (Báo cáo ban đầu/Báo cáo sau 72 giờ/Báo cáo cuối cùng) | X | X | X |
3 | Thời gian báo cáo - Báo cáo ban đầu | A | A | A |
4 | Thời gian báo cáo - Báo cáo trong vòng 72 giờ | A | A | A |
5 | Thời gian báo cáo - Báo cáo cuối cùng | A | A | A |
6 | Người báo cáo | A | A | A |
7 | Tên nhà sản xuất hoặc người quản lý phần mềm mã nguồn mở | X | C | C |
8 | Sản phẩm | X | C | C |
9 | Loại sản phẩm (Mặc định/Quan trọng/Khẩn cấp) | O | C | C |
10 | Phân loại sản phẩm (Xem Phụ lục III/IV của CRA để xác định liệu loại sản phẩm có phải là loại mặc định hay không) | O | C | C |
11 | Khu vực châu Âu nơi công ty đang phân phối sản phẩm | I | C | C |
12 | Tiêu đề | X | C | C |
Các lỗ hổng bảo mật | ||||
v13 | Mã CVE (Mã định danh lỗ hổng chung) | O | C | C |
v14 | Cơ sở dữ liệu lỗ hổng bảo mật châu Âu | O | C | C |
v15 | Thông tin chung | O | X | C |
v16 | a. Giải thích về bản chất, đặc điểm và cơ chế hoạt động của lỗ hổng (lỗi bảo mật) | O | X | C |
v17 | b. Thông tin cơ bản giải thích một cách tổng quát về “cơ chế hoạt động, mục tiêu tấn công và tác động gây ra” của phương thức tấn công (exploit) | O | X | C |
v18 | Các phương pháp khắc phục và giảm thiểu các lỗ hổng bảo mật đã được xử lý | O | X | C |
v19 | Các phương pháp khắc phục và giảm thiểu lỗ hổng bảo mật mà người dùng có thể thực hiện | O | X | C |
v20 | Các thông tin nhạy cảm có thể có | O | I | C |
v21 | Ngày áp dụng các biện pháp khắc phục và giảm thiểu các lỗ hổng bảo mật đã được xử lý | O | O | X |
v22 | Mô tả chi tiết về lỗ hổng bảo mật | O | O | X |
v23 | a. Mức độ nghiêm trọng của lỗ hổng | O | O | X |
v24 | b. Tác động do lỗ hổng bảo mật gây ra | O | O | X |
v25 | Các yếu tố dẫn đến việc khai thác lỗ hổng bảo mật | O | O | I |
v26 | Chi tiết về tình trạng cập nhật bảo mật và cách khắc phục | O | O | X |
Các sự cố tiềm ẩn nguy cơ | ||||
i13 | Tính trái pháp luật và tính ác ý của sự cố | X | C | C |
i14 | Thông tin chung về sự cố | O | X | C |
i15 | Ngày và giờ phát hiện sự cố | O | X | C |
i16 | Ngày và giờ xảy ra sự cố | O | X | C |
i17 | Nội dung đánh giá sự cố ban đầu | O | X | C |
i18 | Các phương pháp khắc phục và giảm thiểu các sự cố đã được xử lý | O | X | C |
i19 | Các phương pháp khắc phục và giảm thiểu sự cố mà người dùng có thể thực hiện | O | X | C |
i20 | Các thông tin nhạy cảm có thể có | O | I | C |
Thông tin chi tiết về sự cố | O | O | X | |
i21 | a. Mức độ nghiêm trọng của sự cố | O | O | X |
i22 | 1) Trong trường hợp ảnh hưởng hoặc có khả năng ảnh hưởng tiêu cực đến khả năng bảo vệ tính bảo mật, tính sẵn có, tính xác thực, tính toàn vẹn hoặc tính bảo mật của dữ liệu hoặc chức năng quan trọng của sản phẩm có chứa yếu tố kỹ thuật số; | |||
i23 | b. Tác động do sự cố gây ra | O | O | X |
i24 | Loại và nguồn gốc của các mối đe dọa gây ra sự cố | O | O | X |
i25 | Các biện pháp đã được triển khai để giảm thiểu sự cố và phương pháp đang được thực hiện hiện nay | O | O | X |
※Bảng này do tác giả lập dựa trên thông tin được công bố trong phần Câu hỏi thường gặp (FAQ) của ENISA
A - Được điền tự động (không hiển thị cho người nộp)
X - Trường bắt buộc
C - Theo mặc định, bản sao nội dung báo cáo liên quan đến thủ tục trước đó hoặc thông tin cập nhật sẽ được ghi đè
O - Tùy chọn
I - Các mục bắt buộc nếu đã thu thập được thông tin
Trong bài viết này, chúng tôi đã giới thiệu từng bước những điểm mà các doanh nghiệp cần chuẩn bị cho ngày 11 tháng 9. Chúng tôi cho rằng có lẽ nhiều người đang băn khoăn về việc nên giao nhiệm vụ AR tại địa phương cho ai, cũng như nên dựa vào tiêu chí nào để chuẩn bị sau khi SRP được công bố.
Chỉ riêng việc báo cáo theo SRP cũng đòi hỏi phải thực hiện rất nhiều cuộc đánh giá trước đó, vì vậy điều quan trọng là trước tiên cần rà soát lại các sản phẩm đang được triển khai tại châu Âu, đồng thời theo dõi và xác minh kỹ lưỡng các sự cố tiềm ẩn lỗ hổng bảo mật và mối đe dọa.
Trong trường hợp đó, tôi cho rằng cách tối ưu nhất là chuẩn bị trước các nội dung cần báo cáo trong quá trình xử lý sự cố dựa trên mẫu có sẵn, đồng thời bổ sung dần các điểm đặc thù của công ty để lưu lại dưới dạng tài liệu toàn diện.
Ngoài ra, do vẫn còn đủ thời gian trước khi luật này có hiệu lực đầy đủ vào ngày 11 tháng 12 năm 2027, chúng ta cần tiếp tục theo dõi các thông báo và xu hướng tiêu chuẩn hóa từ phía châu Âu.
Tài liệu tham khảo
Nghị định (EU) 2024/2847 của Nghị viện Châu Âu và Hội đồng Châu Âu ngày 23 tháng 10 năm 2024 về các yêu cầu an ninh mạng mang tính tổng quát đối với các sản phẩm có thành phần kỹ thuật số và sửa đổi các Nghị định (EU) số 168/2013 và (EU) số 2019/1020 cũng như Chỉ thị (EU) 2020/1828 (Đạo luật về Khả năng phục hồi mạng)
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2847Nghị định (EU) số 168/2013 của Nghị viện Châu Âu và Hội đồng Châu Âu ngày 15 tháng 1 năm 2013 về việc phê duyệt và giám sát thị trường đối với các phương tiện hai hoặc ba bánh và xe bốn bánh
https://eur-lex.europa.eu/eli/reg/2013/168/oj/engNghị định (EU) 2019/1020 của Nghị viện Châu Âu và Hội đồng Châu Âu ngày 20 tháng 6 năm 2019
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:32019R1020CHỈ THỊ (EU) 2020/1828 CỦA NGHỊ VỆ CHÂU ÂU VÀ HỘI ĐỒNG ngày 25 tháng 11 năm 2020 về các vụ kiện đại diện nhằm bảo vệ lợi ích tập thể của người tiêu dùng và bãi bỏ Chỉ thị 2009/22/EC
https://eur-lex.europa.eu/eli/dir/2020/1828/oj/engTình hình hiện tại của CRA
https://www.cyberresilienceact.eu/state-of-play.htmlHiệp hội C-SART Nhật Bản là gì?
https://www.nca.gr.jp/outline/about.htmlNền tảng Báo cáo Đơn nhất (SRP)
https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srpHướng dẫn CRA SRP - Đăng ký người dùng AR
https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-guidance-ar-user-registrationCâu hỏi thường gặp https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions
Câu hỏi thường gặp
https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions
Tác giả của bài viết này
Chuyên gia về quyền riêng tư
Kohei Kurihara
Trong thời gian học đại học, ông làm việc tại văn phòng của một chính trị gia và sau khi tốt nghiệp, ông gia nhập công ty Rakuten. Sau 2 năm kinh nghiệm trong lĩnh vực kinh doanh, ông quyết định khởi nghiệp. Ông hỗ trợ việc mở rộng các dịch vụ kỹ thuật số nước ngoài vào thị trường Nhật Bản cũng như việc mở rộng các dịch vụ trong nước ra thị trường quốc tế. Từ năm 2017, ông đảm nhiệm vai trò đại diện Nhật Bản tại tổ chức phi lợi nhuận Government Blockchain Association của Hoa Kỳ.
Sau đó, bên cạnh việc tham gia thành lập các công ty khởi nghiệp, ông còn có kinh nghiệm phát biểu về chủ đề blockchain tại các hội nghị quốc tế, trong đó có UNESCO. Năm 2020, ông thành lập Hiệp hội Privacy by Design Lab và tập trung vào các hoạt động vận động chính sách về quyền riêng tư, đồng thời nỗ lực xây dựng các diễn đàn quốc tế. Lĩnh vực chuyên môn của ông bao gồm bảo vệ dữ liệu (bảo vệ thông tin cá nhân), tiếp thị kỹ thuật số và blockchain. Ông hiện đang điều hành “Privacy Talk” – một nền tảng phỏng vấn trực tiếp với các nhà lãnh đạo trong ngành bảo vệ quyền riêng tư cả trong và ngoài nước.
Chia sẻ bài viết này
Danh sách các bài viết hữu ích
