Trả lời ngắn
GDPR breach notification: controller báo supervisory authority trong 72 giờ kể từ khi biết, báo người dùng khi rủi ro cao và ghi hồ sơ mọi sự cố.
GDPR breach notification là nghĩa vụ của data controller phải báo personal data breach cho supervisory authority "không chậm trễ và, khi khả thi, không muộn hơn 72 giờ" sau khi biết (Điều 33), trừ khi breach khó gây rủi ro cho cá nhân. Nếu rủi ro cao, phải báo cả người bị ảnh hưởng (Điều 34). Đây là một phần của chương trình GDPR compliance.
Đồng hồ 72 giờ bắt đầu từ lúc nào?
Đồng hồ chạy từ khi controller biết (becomes aware) về breach, không phải từ lúc breach xảy ra. Theo hướng dẫn 9/2022 của EDPB, controller được coi là đã biết khi có mức độ chắc chắn hợp lý rằng một sự cố bảo mật đã xảy ra và làm ảnh hưởng đến dữ liệu cá nhân. Một cảnh báo chưa xác minh cho phép một khoảng điều tra ngắn, nhưng điều tra phải bắt đầu ngay; chờ kết quả forensic đầy đủ mới tính giờ là sai. Ví dụ, khi phát hiện mất một USB chứa dữ liệu khách hàng chưa mã hóa, controller đã biết ngay lúc nhận ra USB bị mất.
Breach theo GDPR không chỉ là bị tấn công: gửi email nhầm người, mất laptop, ransomware làm dữ liệu không truy cập được, hay nhân viên xem dữ liệu không được phép đều là personal data breach theo Điều 4(12).
Phải báo supervisory authority những gì?
Điều 33(3) yêu cầu thông báo tối thiểu gồm: bản chất của breach, kể cả loại và số lượng ước tính data subject và bản ghi bị ảnh hưởng; tên và liên lạc của DPO hoặc đầu mối; hậu quả có thể xảy ra; và biện pháp đã hoặc sẽ áp dụng. Nếu chưa đủ thông tin, Điều 33(4) cho phép báo theo từng giai đoạn. Nếu báo muộn hơn 72 giờ, phải kèm lý do chậm trễ.
Doanh nghiệp không có cơ sở tại EU nhưng thuộc phạm vi GDPR theo Điều 3(2) thường không được hưởng cơ chế one-stop-shop, nên có thể phải báo cho supervisory authority của từng quốc gia nơi người bị ảnh hưởng cư trú; EU representative (Điều 27) là đầu mối liên lạc với các cơ quan này.
Khi nào phải báo người dùng bị ảnh hưởng?
Theo Điều 34, controller phải báo trực tiếp cho data subject "không chậm trễ không cần thiết" khi breach có khả năng gây rủi ro cao cho quyền và tự do của họ, ví dụ lộ dữ liệu tài chính, mật khẩu, dữ liệu sức khỏe hoặc dữ liệu có thể dẫn đến lừa đảo và mạo danh. Thông báo phải dùng ngôn ngữ rõ ràng, nêu những gì đã xảy ra và cách người dùng tự bảo vệ.
Điều 34(3) miễn thông báo trực tiếp khi dữ liệu đã được bảo vệ khiến người không có quyền không đọc được (như mã hóa mạnh với khóa không bị lộ), khi biện pháp sau sự cố đã loại bỏ rủi ro cao, hoặc khi thông báo từng người đòi hỏi nỗ lực không tương xứng, khi đó phải thông báo công khai.
| Mức rủi ro với cá nhân | Báo supervisory authority | Báo data subject | Ghi hồ sơ nội bộ |
|---|---|---|---|
| Khó gây rủi ro | Không bắt buộc | Không | Có (Điều 33(5)) |
| Có rủi ro | Có, trong 72 giờ khi khả thi | Không bắt buộc | Có |
| Rủi ro cao | Có, trong 72 giờ khi khả thi | Có, không chậm trễ không cần thiết (trừ ngoại lệ Điều 34(3)) | Có |
Data processor có nghĩa vụ gì khi xảy ra breach?
Processor phải báo cho controller "không chậm trễ không cần thiết" sau khi biết về breach (Điều 33(2)), và DPA thường đặt thời hạn cụ thể như 24 hoặc 48 giờ. Với công ty outsourcing Việt Nam xử lý dữ liệu cho khách hàng EU, đây là nghĩa vụ trực tiếp nhất: đồng hồ 72 giờ của khách hàng có thể bắt đầu ngay khi họ nhận tin từ bạn, nên việc báo chậm của bạn rút ngắn thời gian của họ. Điều khoản này nằm trong DPA, xem thêm DPA và SCCs.
Quy trình ứng phó cần chuẩn bị trước gồm những gì?
Đồng hồ 72 giờ quá ngắn để vừa xử lý kỹ thuật vừa soạn quy trình. Quy trình nên có sẵn trước:
- Phát hiện và báo cáo nội bộ: một kênh mà mọi nhân viên biết để báo nghi ngờ sự cố, kể cả ngoài giờ.
- Khoanh vùng và đánh giá ban đầu: xác định dữ liệu, số người và hệ thống bị ảnh hưởng.
- Đánh giá rủi ro với cá nhân: không rủi ro, có rủi ro, hay rủi ro cao, và ghi lại lý do.
- Quyết định thông báo: ai quyết định, báo cơ quan nào, có cần báo người dùng không, và báo khách hàng controller nếu bạn là processor.
- Ghi hồ sơ: Điều 33(5) yêu cầu lưu hồ sơ mọi breach, kể cả breach không phải thông báo, gồm sự việc, ảnh hưởng và biện pháp khắc phục.
- Rút kinh nghiệm: cập nhật risk assessment và kiểm soát sau sự cố; nếu breach phát sinh yêu cầu từ người dùng, xử lý theo quy trình quyền của người dùng EU theo GDPR.
pTrackly hỗ trợ phần nào?
Mục Privacy của pTrackly ghi nhận sự cố với thời điểm xảy ra và thời điểm phát hiện, luật áp dụng (GDPR Điều 33, HIPAA hoặc luật khác), quyết định có phải breach cần thông báo không, và đếm ngược 72 giờ từ lúc phát hiện. Hạn sắp đến và quá hạn được nhắc trong ứng dụng; hạn được đánh dấu hoàn thành khi bạn ghi nhận đã báo supervisory authority. Nhân viên báo sự cố qua form có sẵn. pTrackly không tự đánh giá mức rủi ro và không gửi thông báo thay bạn; quyết định và nội dung thông báo thuộc về controller và tư vấn pháp lý của bạn.
Câu hỏi thường gặp
72 giờ có tính cả cuối tuần và ngày lễ không?
Có. 72 giờ là giờ thực, không phải giờ làm việc, nên quy trình cần có người trực và người có thẩm quyền quyết định thông báo cả ngoài giờ hành chính.
Chưa chắc đó có phải breach không thì có cần báo không?
Đồng hồ bắt đầu khi bạn có mức độ chắc chắn hợp lý rằng dữ liệu cá nhân bị ảnh hưởng. Trong khoảng điều tra ngắn trước đó, hãy ghi lại các bước đã làm; nếu đã chắc chắn mà vẫn thiếu chi tiết, hãy báo ban đầu và bổ sung sau theo Điều 33(4).
Không báo breach đúng hạn bị phạt bao nhiêu?
Vi phạm Điều 33 và 34 thuộc mức phạt theo Điều 83(4), tối đa 10 triệu euro hoặc 2% doanh thu toàn cầu năm trước, tùy mức nào cao hơn. Mức phạt thực tế do supervisory authority quyết định theo từng vụ.
Processor có phải báo trực tiếp cho supervisory authority không?
Thường là không; processor báo cho controller, và controller báo supervisory authority. Processor chỉ báo trực tiếp nếu DPA giao việc đó và controller đồng ý.
pTrackly giúp bạn triển khai GDPR nhanh hơn với templates và evidence collection tự động.
Đặt Demo Miễn Phí