DPIA không nên chỉ là tài liệu mô tả mục đích xử lý dữ liệu và tick-box tuân thủ. Giá trị thực sự của DPIA nằm ở việc chỉ ra dữ liệu đi đâu, ai có thể truy cập, hệ thống nào có thể làm lộ dữ liệu và biện pháp kỹ thuật nào thực sự giảm được rủi ro.
Một DPIA đầy đủ cần mô tả hoạt động xử lý, đánh giá rủi ro với chủ thể dữ liệu, đồng thời nêu rõ biện pháp bảo vệ và cơ chế bảo mật được áp dụng.
1. Bản đồ dữ liệu chỉ dừng ở hệ thống chính
Nhiều DPIA chỉ nêu CRM, ERP hoặc ứng dụng lõi, nhưng bỏ qua log hệ thống, file export, email, môi trường test, công cụ analytics, bản sao dữ liệu và backup.
Hãy truy vết toàn bộ vòng đời dữ liệu: thu thập, truyền, xử lý, lưu trữ, chia sẻ, sao lưu và xóa. Một data map cập nhật là nền tảng để nhận diện đúng rủi ro.
2. Mã hóa không đi cùng quản lý khóa
“Mã hóa dữ liệu” không phải câu trả lời đủ cho DPIA nếu chưa xác định: dữ liệu nào được mã hóa, ở trạng thái nào, khóa do ai quản lý, quyền truy cập khóa được cấp ra sao và khóa có được luân chuyển định kỳ hay không.
Cần đánh giá riêng mã hóa khi truyền, mã hóa khi lưu trữ và cơ chế quản trị khóa để tránh trường hợp dữ liệu đã mã hóa nhưng khóa lại dễ bị truy cập.
3. Quyền truy cập quá rộng
DPIA thường ghi “có phân quyền”, nhưng thiếu đánh giá cụ thể về role, quyền quản trị, tài khoản dịch vụ, quyền truy xuất dữ liệu nhạy cảm và quy trình thu hồi quyền khi nhân sự đổi vị trí hoặc nghỉ việc.
Kiểm soát truy cập theo vai trò hoặc theo danh tính, cùng nguyên tắc quyền tối thiểu, cần được chứng minh bằng cấu hình và quy trình vận hành thực tế.
4. Dữ liệu đã xóa ở production nhưng vẫn còn ở backup
Quy định lưu trữ và xóa dữ liệu phải bao gồm cả database replica, backup, snapshot, archive, data warehouse và tệp export.
Nếu doanh nghiệp không biết dữ liệu cá nhân tồn tại trong backup bao lâu, DPIA chưa thể đánh giá chính xác rủi ro lưu trữ quá thời hạn. Cơ quan quản lý dữ liệu cũng nhấn mạnh việc xác định lịch lưu trữ và xóa dữ liệu khi không còn cần thiết.
5. Log có thu thập nhưng không được bảo vệ
Log có thể chứa user ID, địa chỉ IP, token, nội dung request, email hoặc dữ liệu định danh khác. Đây là nguồn dữ liệu hữu ích để điều tra sự cố, nhưng cũng là mục tiêu có giá trị đối với kẻ tấn công.
DPIA cần xác định log nào chứa dữ liệu cá nhân, ai được xem log, thời gian lưu giữ, cơ chế che/mask dữ liệu nhạy cảm và phương án phát hiện truy cập bất thường.
6. Bỏ sót nhà cung cấp và tích hợp bên thứ ba
Dữ liệu không chỉ nằm trong hệ thống doanh nghiệp. Chatbot, công cụ marketing, nền tảng phân tích, API, cổng thanh toán, nhà cung cấp cloud và đơn vị hỗ trợ kỹ thuật đều có thể trở thành mắt xích trong luồng xử lý.
DPIA cần ghi rõ bên xử lý, phạm vi dữ liệu được chia sẻ, vị trí xử lý, phương thức truyền dữ liệu và các bảo đảm kỹ thuật – tổ chức của nhà cung cấp. Vị trí xử lý của bên nhận đặc biệt quan trọng khi có hoạt động chuyển dữ liệu quốc tế.
7. Không kiểm tra khả năng khôi phục khi có sự cố
Nhiều DPIA đề cập nguy cơ rò rỉ dữ liệu nhưng không trả lời: doanh nghiệp sẽ làm gì nếu hệ thống bị ransomware, cấu hình cloud sai hoặc tài khoản quản trị bị chiếm quyền?
Cần kiểm tra định kỳ khả năng backup, restore, cô lập sự cố, thu hồi quyền truy cập, bảo vệ dữ liệu trong quá trình khôi phục và lưu bằng chứng phục vụ điều tra.
DPIA tốt không chỉ nêu “có áp dụng biện pháp bảo mật”. DPIA tốt phải cho thấy biện pháp nào bảo vệ dữ liệu nào, trước rủi ro nào và ai chịu trách nhiệm kiểm tra hiệu quả của biện pháp đó.
ICS đồng hành cùng doanh nghiệp rà soát các điểm kỹ thuật trong DPIA - từ data flow, phân quyền, mã hóa, backup đến quản trị nhà cung cấp và ứng phó sự cố.