Luật Bảo vệ dữ liệu cá nhân: phần pháp lý đọc trong một buổi, phần kỹ thuật mất nhiều tháng

Ngày 26/6/2025, Quốc hội thông qua Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15 gồm 5 chương, 39 điều; luật chính thức có hiệu lực từ ngày 1/1/2026. Cùng ngày, Nghị định 356/2025/NĐ-CP ban hành ngày 31/12/2025 bắt đầu áp dụng — 5 chương, 42 điều và một phụ lục gồm 10 hồ sơ, biểu mẫu — thay thế Nghị định 13/2023/NĐ-CP.

Đọc hết cả hai văn bản mất một buổi chiều. Nhưng câu hỏi doanh nghiệp thực sự cần trả lời là câu khác: *hệ thống hiện tại có làm được những điều đó không*. Đó là câu hỏi kỹ thuật, và với một doanh nghiệp đang vận hành, trả lời nó thường mất nhiều tháng.

Bài này viết từ góc nhìn kiến trúc hệ thống, không phải tư vấn pháp lý. Các mốc thời gian, ngưỡng và tiêu chí phân loại doanh nghiệp nên đối chiếu với văn bản gốc và ý kiến của người có chuyên môn pháp lý trước khi ra quyết định.

Ba câu hỏi mà hệ thống phải trả lời được

Bỏ qua thuật ngữ, phần lớn nghĩa vụ quy về ba câu hỏi vận hành:

• Bạn đang giữ dữ liệu cá nhân nào, ở những đâu?
• Với mỗi loại dữ liệu đó, căn cứ nào cho phép bạn giữ, và giữ đến bao giờ?
• Khi một người yêu cầu truy cập hoặc xoá, bạn thực hiện được ở tất cả những nơi đó trong bao lâu?

Ba câu nghe đơn giản đến mức dễ bị bỏ qua. Trong thực tế rà soát hệ thống đang chạy, phần lớn doanh nghiệp không trả lời được câu đầu tiên — và đó không phải một thiếu sót về ý thức pháp lý, đó là hệ quả tự nhiên của cách hệ thống đã lớn lên qua nhiều năm.

Vì sao câu hỏi đầu tiên lại khó

Không ai cố tình làm mất dấu dữ liệu khách hàng. Nó xảy ra dần: CRM mua từ 2019, file Excel của phòng kinh doanh, phần mềm chấm công, log web server, công cụ analytics, hộp thư chăm sóc khách hàng — và bản sao lưu của tất cả những thứ đó. Đây chính là tình trạng 5–6 hệ thống rời rạc mà chúng tôi đã mô tả, chỉ khác ở chỗ từ 2026 nó có thêm hệ quả pháp lý.

Bản đồ dữ liệu vì thế không phải một file Word liệt kê các bảng trong cơ sở dữ liệu. Cách làm dùng được là bắt đầu từ luồng thu thập: mỗi form, mỗi API công khai, mỗi tệp import, mỗi tích hợp bên thứ ba là một cửa vào. Đi theo từng cửa vào để xem dữ liệu chảy tới đâu sẽ lộ ra những nơi lưu trữ mà không ai nhớ tới khi ngồi liệt kê bằng trí nhớ.

Xoá là bài toán kiến trúc, không phải một nút bấm

Thử liệt kê những nơi một bản ghi khách hàng tồn tại trong một hệ thống trung bình: cơ sở dữ liệu chính, read replica, data warehouse, chỉ mục tìm kiếm, cache, hàng đợi message, log ứng dụng, các tệp export đã gửi qua email, hệ thống của đối tác — và bản sao lưu của gần như tất cả những thứ trên.

Một nút "xoá tài khoản" chỉ xử lý được mục đầu tiên trong danh sách đó.

Bản sao lưu là chỗ khó nhất, và cũng là chỗ hay bị lờ đi nhất trong các bản chính sách. Bạn không thể mở một snapshot của sáu tháng trước để xoá một dòng; mà nếu sửa được thì nó không còn là một bản sao lưu đúng nghĩa. Có hai hướng thực tế:

• Crypto-shredding — mã hoá dữ liệu của mỗi chủ thể bằng một khoá riêng và lưu khoá tách khỏi dữ liệu. Xoá khoá thì dữ liệu trong mọi bản sao lưu trở thành vô nghĩa mà không cần chạm vào snapshot nào. Cái giá: phải thiết kế từ đầu, và kho khoá lập tức trở thành hệ thống trọng yếu nhất của bạn.
• Danh sách chặn khi phục hồi — giữ danh sách các chủ thể đã yêu cầu xoá và áp nó như một bước bắt buộc trong quy trình khôi phục. Rẻ hơn nhiều, nhưng chỉ có tác dụng nếu bước đó nằm trong script khôi phục chứ không nằm trong tài liệu hướng dẫn.

Nếu chưa có cả hai, điều đúng đắn là ghi lại giới hạn đó một cách trung thực trong hồ sơ nội bộ và trong thông tin gửi tới chủ thể dữ liệu, thay vì cam kết "xoá toàn bộ ngay lập tức" — một câu mà hệ thống không thực hiện được.

Đồng ý phải chứng minh được, không chỉ hiển thị được

Một ô tích trên giao diện không phải bằng chứng. Bằng chứng là một bản ghi trả lời được: ai đồng ý, lúc nào, cho mục đích nào, qua kênh nào, và với phiên bản nào của chính sách.

Chi tiết cuối là chi tiết bị bỏ sót nhiều nhất. Nếu trang chính sách quyền riêng tư được sửa đè lên bản cũ — cách gần như mọi website đang làm — thì mọi đồng ý thu được trước đó mất ngữ cảnh: bạn không còn chứng minh được người dùng đã đồng ý với cái gì. Cách sửa rất rẻ: đánh phiên bản cho chính sách, giữ bản cũ ở một URL cố định, và ghi số phiên bản vào từng bản ghi đồng ý.

Ở chiều ngược lại, rút lại đồng ý phải dễ ngang mức cho đồng ý, và phải lan được xuống hạ nguồn. Một lượt rút lại chỉ đổi một cờ trong CRM nhưng không dừng chiến dịch email đang chạy là một lượt rút lại chưa hoàn tất.

Ba loại dữ liệu cá nhân thường không có trong bản đồ

• Log. Địa chỉ IP, user-agent, mã người dùng, đôi khi cả số điện thoại lọt vào thông báo lỗi. Log thường được giữ vô thời hạn chỉ vì chưa ai đặt hạn lưu cho nó — trong khi đây là kho dữ liệu cá nhân tăng nhanh nhất của hầu hết hệ thống.
• Dữ liệu sinh trắc học sinh ra ở những nơi không ai gọi là "hệ thống dữ liệu". Máy chấm công vân tay hoặc nhận diện khuôn mặt tạo ra dữ liệu sinh trắc học của toàn bộ nhân viên. Chi tiết này quan trọng hơn vẻ ngoài của nó, vì loại dữ liệu quyết định bạn có thuộc diện được miễn trừ hay không — phần dưới.
• Dữ liệu suy ra. Điểm tín dụng nội bộ, phân khúc khách hàng, nhãn dự đoán hành vi do mô hình sinh ra. Khách hàng không cung cấp chúng nên chúng hiếm khi xuất hiện trong bản kiểm kê, nhưng chúng vẫn gắn với một con người xác định.

Chuyển dữ liệu ra nước ngoài xảy ra cả khi bạn không nghĩ mình đang chuyển

Nhiều doanh nghiệp trả lời "chúng tôi không chuyển dữ liệu ra nước ngoài" trong khi đang dùng CRM SaaS đặt máy chủ ở nước ngoài, công cụ analytics, CDN, dịch vụ gửi email marketing — và ngày càng phổ biến là API mô hình ngôn ngữ.

Điểm cuối đáng dừng lại lâu hơn. Mỗi lời gọi API mang theo tên khách hàng, số điện thoại, nội dung khiếu nại hay tóm tắt hồ sơ y tế là một lần dữ liệu cá nhân rời khỏi hạ tầng của bạn. Về bản chất kiến trúc, nó không khác một tích hợp bên thứ ba — nhưng vì nó nằm trong một dòng code gọi thư viện chứ không nằm trong một hợp đồng, nó thường không đi qua quy trình rà soát nhà cung cấp.

Hệ quả kỹ thuật: bản đồ luồng dữ liệu ra ngoài phải lập ở mức mã nguồn và cấu hình, không phải ở mức danh mục hợp đồng. Ba kỹ thuật thu hẹp phạm vi, theo thứ tự chi phí tăng dần: gửi ít trường hơn (phần lớn prompt không cần tên thật); thay dữ liệu định danh bằng mã giả trước khi gửi rồi ghép lại sau; và chạy mô hình tại chỗ cho đúng những luồng chạm dữ liệu nhạy cảm.

Đây cũng là lý do chúng tôi thiết kế tầng điều phối AI theo hướng thay được nhà cung cấp: khi ràng buộc pháp lý hoặc nơi đặt dữ liệu thay đổi, phần phải sửa nên là cấu hình chứ không phải kiến trúc.

Hồ sơ đánh giá tác động: 60 ngày, rồi định kỳ 6 tháng

Đây là phần có mốc thời gian cụ thể nên đáng ghi ra. Theo Điều 21, bên kiểm soát dữ liệu lập và lưu hồ sơ đánh giá tác động xử lý dữ liệu cá nhân, gửi một bản chính cho cơ quan chuyên trách trong 60 ngày kể từ ngày đầu tiên xử lý dữ liệu cá nhân; hồ sơ được thực hiện một lần cho suốt thời gian hoạt động và cập nhật theo Điều 22 — định kỳ 6 tháng một lần khi có thay đổi, và cập nhật ngay trong các trường hợp thay đổi lớn như tổ chức lại doanh nghiệp hay đổi nhà cung cấp dịch vụ bảo vệ dữ liệu. Với dữ liệu chuyển ra nước ngoài, hồ sơ đánh giá tác động chuyển dữ liệu cũng nộp trong 60 ngày kể từ lần chuyển đầu tiên.

Câu hỏi kỹ thuật ẩn bên trong là câu về nguồn của hồ sơ. Một hồ sơ gõ tay sẽ đúng ở lần lập đầu tiên, lệch ở lần cập nhật thứ hai, và trở thành hư cấu ở lần thứ tư — vì hệ thống đổi hằng tuần còn hồ sơ thì sáu tháng mới nhìn lại một lần. Hồ sơ chỉ giữ được độ chính xác nếu phần lớn nội dung sinh ra từ hệ thống: danh sách trường có gắn nhãn loại dữ liệu, danh sách tích hợp ra ngoài lấy từ cấu hình, hạn lưu lấy từ chính sách retention đang chạy thật.

Nói cách khác, tuân thủ bền vững trông giống một quy trình giám sát chất lượng dữ liệu hơn là một đợt làm hồ sơ.

Miễn trừ — và cái bẫy nằm trong miễn trừ

Luật có nhượng bộ rõ ràng cho quy mô nhỏ. Hộ kinh doanh và doanh nghiệp siêu nhỏ không phải thực hiện Điều 21, Điều 22 và khoản 2 Điều 33 — khoản quy định việc chỉ định bộ phận, nhân sự đủ điều kiện bảo vệ dữ liệu cá nhân hoặc thuê tổ chức, cá nhân cung cấp dịch vụ. Doanh nghiệp nhỏ và doanh nghiệp khởi nghiệp được quyền chọn thực hiện hay không, trong 5 năm kể từ ngày luật có hiệu lực.

Cái bẫy nằm ở mệnh đề loại trừ. Miễn trừ không áp dụng cho đơn vị kinh doanh dịch vụ xử lý dữ liệu cá nhân, đơn vị trực tiếp xử lý dữ liệu cá nhân nhạy cảm, hoặc đơn vị xử lý dữ liệu của số lượng lớn chủ thể. Ba mệnh đề đó mô tả rất nhiều doanh nghiệp nhỏ có thật:

• Một phòng khám tư xử lý dữ liệu sức khoẻ — dữ liệu nhạy cảm.
• Một công ty 30 người chấm công bằng vân tay — dữ liệu sinh trắc học.
• Một ứng dụng có vài trăm nghìn tài khoản đăng ký, dù công ty vẫn là doanh nghiệp nhỏ xét theo doanh thu và số lao động.

Hai điểm cần nói rõ. Thứ nhất, ranh giới "số lượng lớn" và tiêu chí phân loại doanh nghiệp nhỏ, siêu nhỏ là câu hỏi pháp lý phải đối chiếu văn bản gốc — không phải thứ nên phỏng đoán từ cảm giác về quy mô. Thứ hai, miễn trừ này chỉ áp cho ba nhóm nghĩa vụ về hồ sơ và nhân sự; nghĩa vụ bảo vệ dữ liệu và các quyền của chủ thể dữ liệu không được miễn. Không phải nộp hồ sơ đánh giá tác động không có nghĩa là không phải xoá dữ liệu khi được yêu cầu.

Mức phạt: đọc phần trần, đừng đọc phần trung bình

Theo quy định về xử phạt vi phạm hành chính trong lĩnh vực này, mức tối đa với tổ chức là 3 tỷ đồng cho một lần vi phạm; riêng hành vi mua, bán dữ liệu cá nhân có mức tối đa bằng 10 lần khoản thu có được từ hành vi vi phạm; và vi phạm quy định chuyển dữ liệu cá nhân xuyên biên giới có mức tối đa bằng 5% doanh thu của năm trước liền kề. Với cá nhân, mức tối đa bằng một nửa mức áp dụng cho tổ chức.

Điểm đáng chú ý nằm ở cách hai mức sau được thiết kế: chúng không phải một số tiền cố định mà gắn với khoản thu và với doanh thu. Nghĩa là rủi ro tài chính lớn lên cùng quy mô doanh nghiệp, và không thể quy về một khoản chi phí vận hành dự toán được rồi bỏ qua.

Cách kiểm chứng: một bài diễn tập, không phải một bản chính sách

Chúng tôi dùng cho tuân thủ dữ liệu đúng phương pháp đã dùng cho accessibility: đo trên hệ thống thật trước khi viết ra bất kỳ cam kết nào.

Bài kiểm tra cụ thể: chọn một tài khoản đã dùng đủ lâu để có dấu vết ở nhiều hệ thống — với sự đồng ý của chủ thể, hoặc một tài khoản nội bộ — rồi thực hiện trọn vẹn một yêu cầu truy cập và một yêu cầu xoá, từ lúc nhận yêu cầu đến lúc xác nhận đã xong.

Đo ba con số: mất bao lâu, phải nhờ bao nhiêu người, và sót bao nhiêu nơi so với bản đồ dữ liệu. Lần chạy đầu tiên gần như luôn phát hiện ít nhất một hệ thống không có trong bản đồ — thường là một công cụ marketing, một bảng tính, hoặc một môi trường thử nghiệm đang giữ bản sao dữ liệu thật.

Bản sao dữ liệu thật trong môi trường thử nghiệm đáng được nói riêng: nó thường không được kiểm soát truy cập chặt như production, không nằm trong quy trình xoá, và tồn tại vì một lý do rất hợp lý — cần dữ liệu thật để kiểm thử. Cách xử lý bền vững là sinh dữ liệu giả lập theo phân phối của dữ liệu thật thay vì sao chép; tốn công một lần và tiết kiệm mãi về sau, giống cách dual-write và backfill tốn công thiết kế nhưng đổi lại một lần cutover không rủi ro.

Sau khi sửa, chạy lại bài kiểm tra và so ba con số. Đó là khác biệt giữa "chúng tôi có tuân thủ" và "chúng tôi đã đo".

Kết luận

Phần pháp lý đọc trong một buổi chiều: 39 điều luật, 42 điều nghị định, 10 biểu mẫu. Phần kỹ thuật là ba câu hỏi ở đầu bài, và không câu nào trả lời được bằng một bản chính sách viết cho đẹp.

Điều đáng mừng là hướng đi trùng với việc doanh nghiệp lẽ ra nên làm kể cả khi không có luật: biết mình đang giữ dữ liệu gì, ở đâu, vì sao, và đến bao giờ. Những nơi trả lời được câu hỏi đầu tiên gần như luôn là những nơi đã dọn dữ liệu về một nguồn tin được từ trước — với họ, tuân thủ chủ yếu là ghi chép lại thứ đã có chứ không phải xây mới.

Nếu bạn muốn biết hệ thống của mình trả lời được đến đâu, liên hệ với chúng tôi để rà soát một luồng dữ liệu cụ thể, hoặc xem năng lực Data Analytics và Development của KonexForge.