Bảo vệ dữ liệu người tiêu dùng – Phần 2

Một data flow*, doanh nghiệp phải tuân thủ những nghĩa vụ nào dưới Luật Bảo vệ quyền lợi người tiêu dùng và Luật Bảo vệ dữ liệu cá nhân?

Một khách hàng A tải ứng dụng của Công ty X, đăng ký tài khoản bằng số điện thoại, tìm kiếm sản phẩm, đặt hàng, thanh toán, nhận hàng và sau đó tiếp tục nhận các đề xuất sản phẩm hoặc thông báo khuyến mại. Xét ở góc độ trải nghiệm khách hàng, đây là một customer journey** tương đối quen thuộc. Nhưng xét ở góc độ dữ liệu, mỗi bước trong hành trình này đều có thể làm phát sinh một hoặc nhiều hoạt động thu thập, lưu trữ, sử dụng, phân tích hoặc chia sẻ thông tin về A.

Như đã phân tích tại Phần 1, khi A vừa là “người tiêu dùng” theo Luật Bảo vệ quyền lợi người tiêu dùng 2023 (“Luật BVQLNTD”), vừa là “chủ thể dữ liệu” theo Luật Bảo vệ dữ liệu cá nhân 2025 (“Luật BVDLCN”), cùng một data flow có thể đồng thời chịu sự điều chỉnh của hai lớp pháp luật. Điều này dẫn đến một vấn đề thực tế: doanh nghiệp không chỉ cần biết mình đang có dữ liệu gì, mà còn phải xác định dữ liệu được tạo ra ở bước nào, được sử dụng cho mục đích nào, đi qua những chủ thể nào và tại mỗi bước đó người dùng đang có quyền gì.

Trong bài viết này, LexNovum Lawyers (“LNV”) tiếp tục tuyến bài bằng cách đi theo một data flow thông dụng của doanh nghiệp B2C (Business-to-Consumer), qua đó phân tích cách Luật BVQLNTD và Luật BVDLCN cùng tác động lên quá trình xử lý thông tin người dùng; đồng thời chỉ ra một số điểm doanh nghiệp thường dễ bỏ sót khi chuyển các nghĩa vụ pháp lý thành quy trình vận hành thực tế.

* Data flow: luồng di chuyển và xử lý dữ liệu trong suốt vòng đời của dữ liệu, từ thời điểm dữ liệu được thu thập, chuyển qua các hệ thống hoặc bộ phận nội bộ, chia sẻ cho bên thứ ba, sử dụng cho các mục đích khác nhau cho đến khi được lưu trữ, xóa hoặc hủy.

**Customer journey: hành trình của khách hàng trong quá trình tương tác với doanh nghiệp, từ thời điểm bắt đầu tiếp cận sản phẩm/dịch vụ, đăng ký tài khoản, tìm kiếm, mua hàng, thanh toán, sử dụng dịch vụ, nhận hỗ trợ sau bán hàng cho đến các tương tác tiếp theo. Trong bối cảnh bài viết này, thuật ngữ này được dùng để mô tả chuỗi điểm chạm mà tại mỗi bước, dữ liệu của người dùng có thể được thu thập, sử dụng, lưu trữ hoặc chia sẻ.

1. Một data flow nhưng có hai lớp nghĩa vụ cần được rà soát

Nếu Phần 1 tập trung vào câu hỏi “thông tin nào đang được bảo vệ”, thì Phần 2 này sẽ tập trung vào câu hỏi tiếp theo: khi một thông tin đồng thời nằm trong vùng giao nhau của hai hệ thống pháp luật, doanh nghiệp phải làm gì với thông tin đó?

Theo LNV, điểm cần lưu ý là hai luật được đề cập trong bài viết này không vận hành như hai bộ quy tắc hoàn toàn tách biệt, song, cũng không song trùng. Trên cùng một hoạt động, Luật BVQLNTD có thể quan tâm đến việc người tiêu dùng đã được thông báo và có quyền lựa chọn hay chưa, trong khi Luật BVDLCN lại đi sâu hơn vào tính hợp pháp của hoạt động xử lý, mục đích xử lý, vai trò của từng bên tham gia và khả năng chứng minh việc tuân thủ trong suốt vòng đời dữ liệu. Vì vậy, việc đáp ứng một lớp nghĩa vụ không nên được mặc định là đã hoàn tất lớp nghĩa vụ còn lại.

Ví dụ, doanh nghiệp có thể đã xây dựng một thông báo xử lý dữ liệu khá chi tiết theo Luật BVDLCN. Tuy nhiên, nếu trong customer journey người tiêu dùng không có cơ chế lựa chọn riêng đối với việc chia sẻ thông tin cho một bên thứ ba trong trường hợp Luật BVQLNTD yêu cầu, thì việc có một Privacy Policy (Chính sách bảo mật) đầy đủ vẫn chưa giải quyết hết các nghĩa vụ doanh nghiệp cần tuân thủ. Ở chiều ngược lại, một checkbox (ô) lựa chọn trên giao diện cũng không tự động chứng minh rằng toàn bộ hoạt động xử lý phía sau đã được thiết kế đúng mục đích, đúng phạm vi và đúng vai trò giữa các bên.

Qua rà soát, LNV khái quát sự khác nhau về trọng tâm của hai lớp nghĩa vụ này như sau:

Như vậy, điểm quan trọng không phải là lựa chọn “luật nào áp dụng”, mà là nhận diện tại bước nào của data flow có hai lớp nghĩa vụ đang cùng tồn tại. Để thấy rõ hơn, có thể đi lần lượt theo một customer journey thông thường.

2. Đi theo một customer journey: nghĩa vụ pháp lý phát sinh ở đâu?

2.1. Đăng ký tài khoản: một checkbox “Tôi đồng ý” có giải quyết được toàn bộ data flow không?

Giả sử để mở tài khoản, A được yêu cầu nhập họ tên, số điện thoại, email và mật khẩu. Phía dưới form (biểu mẫu) có một checkbox với nội dung “Tôi đồng ý với Điều khoản sử dụng và Chính sách bảo mật”. Đây là cách thiết kế khá phổ biến vì đơn giản và ít làm gián đoạn trải nghiệm người dùng.

Tuy nhiên, về mặt pháp lý, một checkbox duy nhất có thể đang được doanh nghiệp sử dụng để phục vụ nhiều mục đích rất khác nhau: xác lập tài khoản, xác thực người dùng, thực hiện giao dịch, gửi thông tin marketing (tiếp thị), phân tích hành vi và thậm chí chia sẻ dữ liệu với các đối tác. Khi các mục đích này được gom thành một lựa chọn duy nhất, doanh nghiệp cần đánh giá liệu người dùng có thực sự biết mình đang chấp thuận điều gì và các mục đích nào là cần thiết cho dịch vụ, mục đích nào là bổ sung.

Dưới góc Luật BVQLNTD, Điều 17 và Điều 18 Luật BVQLNTD đặt ra yêu cầu về việc xây dựng quy tắc bảo vệ thông tin, thông báo rõ ràng cho người tiêu dùng trước khi thu thập, sử dụng và thiết lập phương thức để người tiêu dùng lựa chọn phạm vi thông tin đồng ý cung cấp, cũng như thể hiện sự đồng ý hoặc không đồng ý trong các trường hợp luật định. Trong khi đó, Luật BVDLCN và Nghị định 356/2025/NĐ-CP yêu cầu doanh nghiệp nhìn rộng hơn vào toàn bộ hoạt động xử lý: dữ liệu gì được xử lý, cho mục đích nào, trên căn cứ nào, ai tham gia xử lý và doanh nghiệp sẽ chứng minh việc tuân thủ bằng cách nào.

Ví dụ: A cần cung cấp số điện thoại để nhận mã OTP khi đăng nhập. Việc xử lý số điện thoại để xác thực tài khoản gắn trực tiếp với chức năng mà A đang yêu cầu. Nhưng nếu cùng số điện thoại đó được tự động đưa vào một danh sách SMS marketing, mục đích sử dụng đã thay đổi. Doanh nghiệp cần tách hai data flow này để đánh giá riêng, thay vì dựa vào việc “A đã tick (chọn) đồng ý khi đăng ký” như một căn cứ chung cho mọi hoạt động về sau.

2.2. Người dùng chỉ “lướt xem”, nhưng dữ liệu vẫn tiếp tục được tạo ra

Sau khi có tài khoản, A bắt đầu xem sản phẩm, tìm kiếm từ khóa, thêm hàng vào giỏ, bỏ giỏ, quay lại một sản phẩm nhiều lần hoặc chỉ dừng ở một trang trong vài giây. A không nhập thêm thông tin nào, nhưng hệ thống vẫn có thể tạo ra một lượng dữ liệu mới về hành vi của A.

Đây là điểm doanh nghiệp thường dễ bỏ sót khi xây dựng data inventory***. Dữ liệu người dùng không chỉ là những trường thông tin mà khách hàng chủ động điền vào form. Trong môi trường số, dữ liệu còn có thể được tạo ra từ log (nhật ký) hệ thống, cookie (tệp lưu thông tin truy cập), lịch sử tìm kiếm, lịch sử click (nhấp chuột/tương tác), thời lượng xem, vị trí truy cập hoặc các dấu vết kỹ thuật khác. Nếu các dữ liệu này gắn với tài khoản hoặc có thể liên hệ với một cá nhân cụ thể, chúng có thể tiếp tục nằm trong phạm vi của pháp luật bảo vệ dữ liệu cá nhân. Đồng thời, khi phản ánh quá trình tìm kiếm, mua hoặc sử dụng hàng hóa, dịch vụ, chúng cũng có thể thuộc phạm vi “thông tin của người tiêu dùng” đã phân tích tại Phần 1.

Ví dụ: hệ thống ghi nhận A đã mở trang “máy lọc không khí” bảy lần trong ba ngày nhưng chưa mua. Về kỹ thuật, đây có thể chỉ là một chuỗi sự kiện trong hệ thống analytics (phân tích dữ liệu). Nhưng khi chuỗi sự kiện đó được gắn với user ID (mã định danh người dùng) của A và được dùng để hiển thị lại sản phẩm hoặc gửi mã giảm giá riêng cho A, dữ liệu đã được sử dụng để tác động trực tiếp lên trải nghiệm của một cá nhân xác định. Do đó, việc doanh nghiệp không trực tiếp hỏi A về nhu cầu mua máy lọc không khí không có nghĩa là hoạt động xử lý dữ liệu này nằm ngoài phạm vi cần rà soát.

***Data inventory: danh mục dữ liệu mà doanh nghiệp đang thu thập, lưu trữ hoặc xử lý, thường ghi nhận các thông tin như loại dữ liệu, nguồn thu thập, mục đích sử dụng, hệ thống lưu trữ, bộ phận được truy cập, thời hạn lưu giữ và các bên có liên quan đến việc xử lý dữ liệu.

2.3. Từ “có dữ liệu” đến “hiểu khách hàng”: hoạt động xử lý thông qua quá trình phân tích và suy luận làm phát sinh một lớp dữ liệu mới

Data flow thường không dừng ở việc ghi nhận dữ liệu gốc. Khi dữ liệu đủ nhiều, doanh nghiệp có thể kết hợp các điểm dữ liệu để phân nhóm khách hàng, dự đoán nhu cầu, chấm điểm khả năng mua hàng hoặc cá nhân hóa nội dung. Chính ở bước này, doanh nghiệp bắt đầu tạo ra các thông tin suy luận mà người dùng chưa từng trực tiếp cung cấp.

Ví dụ, A thường mua thức ăn cho mèo, tìm kiếm cát vệ sinh và theo dõi các chương trình tiêm phòng cho thú cưng. Hệ thống có thể xếp A vào nhóm “người nuôi mèo” và từ đó đề xuất các sản phẩm tương ứng. Trong một tình huống khác, doanh nghiệp có thể kết hợp lịch sử giao dịch, giá trị đơn hàng và tần suất sử dụng voucher (mã ưu đãi) để xếp A vào nhóm khách hàng “nhạy cảm về giá”. Hai nhãn này đều là kết quả của quá trình phân tích, chứ không phải dữ liệu A chủ động khai báo.

Điều này quan trọng vì mỗi bước phân tích có thể làm thay đổi cả mục đích lẫn mức độ rủi ro của hoạt động xử lý. Một tập dữ liệu ban đầu được thu thập để thực hiện giao dịch có thể sau đó được dùng để xây dựng hồ sơ hành vi, phục vụ quảng cáo hoặc chia sẻ cho một hệ thống quảng cáo bên ngoài. Khi đó, LNV cho rằng các mục đích sử dụng mới này cần được kiểm tra xem có nằm trong phạm vi đã được thông báo hay không; dữ liệu suy luận được lưu ở đâu; ai được truy cập; và việc sử dụng kết quả phân tích có làm phát sinh thêm quyền hoặc cơ chế lựa chọn cho người dùng hay không.

Nói cách khác, “vòng đời của dữ liệu” không kết thúc ở thời điểm doanh nghiệp thu được dữ liệu. Dữ liệu có thể tiếp tục được làm giàu, kết hợp và chuyển hóa. Vì vậy, một sơ đồ dữ liệu chỉ liệt kê nguồn dữ liệu đầu vào mà không ghi nhận các dữ liệu được tạo ra trong quá trình phân tích sẽ rất dễ bỏ sót một phần quan trọng của hoạt động xử lý.

2.4. Thực hiện đơn hàng: dữ liệu phải đi qua vendor (bên cung cấp dịch vụ), nhưng trách nhiệm không dừng ở việc “đã có hợp đồng”

Để hoàn tất một đơn hàng, Công ty X có thể cần chuyển một số dữ liệu của A cho cổng thanh toán, đơn vị vận chuyển, hệ thống CRM – Customer Relationship Management (Quản lý quan hệ khách hàng), nhà cung cấp cloud (dịch vụ điện toán đám mây) hoặc call center (trung tâm chăm sóc khách hàng). Đây đều là những hoạt động bình thường trong kinh doanh. Tuy nhiên, mỗi lần dữ liệu rời khỏi hệ thống chính của doanh nghiệp, data flow lại dài thêm một đoạn và khả năng kiểm soát trực tiếp của doanh nghiệp giảm đi một phần.

Dưới góc Luật BVQLNTD, doanh nghiệp cần xem việc chia sẻ thông tin có đúng với mục đích, phạm vi đã thông báo và cơ chế lựa chọn của người tiêu dùng hay không. Dưới góc Luật BVDLCN, doanh nghiệp còn phải xác định bên nhận dữ liệu đang đóng vai trò gì trong quá trình xử lý: họ chỉ xử lý theo hướng dẫn của doanh nghiệp, hay họ tự quyết định một mục đích xử lý riêng; họ nhận toàn bộ database (cơ sở dữ liệu) hay chỉ phần dữ liệu thật sự cần thiết; dữ liệu được giữ trong bao lâu; có được chuyển tiếp cho sub-vendor (bên cung cấp dịch vụ phụ) hay không.

Ví dụ: đơn vị vận chuyển cần tên, số điện thoại và địa chỉ của A để giao hàng. Việc chia sẻ những dữ liệu này có logic (mối liên hệ) trực tiếp với mục đích thực hiện đơn hàng. Nhưng nếu file (tệp dữ liệu) gửi cho đơn vị vận chuyển đồng thời chứa lịch sử mua hàng trong tháng, ngày sinh và phân nhóm khách hàng của A, doanh nghiệp cần lý giải vì sao các trường thông tin bổ sung đó là cần thiết. Tương tự, nếu agency (đơn vị cung cấp dịch vụ) chỉ được thuê để gửi email khuyến mại nhưng lại tải toàn bộ customer database (cơ sở dữ liệu khách hàng) về máy cá nhân để thao tác, rủi ro không còn nằm ở nội dung hợp đồng mà nằm ở cách data (dữ liệu) thực sự được xử lý.

Do đó, “đã ký NDA (thỏa thuận bảo mật thông tin)/DPA (thỏa thuận xử lý dữ liệu) với vendor” không nên là điểm kết thúc của việc rà soát. Hợp đồng chỉ là một lớp kiểm soát. Doanh nghiệp còn cần biết vendor thực tế đang nhận dữ liệu gì, thông qua kênh nào, ai có quyền truy cập và điều gì xảy ra với dữ liệu khi hợp đồng kết thúc.

2.5. Sau giao dịch: cùng một số điện thoại nhưng mục đích đã khác

Một trường hợp rất điển hình là việc xử lý số điện thoại sau giao dịch của thị trường thực tế được LNV quan sát trong thời gian gần đây. A cung cấp số điện thoại để nhận mã OTP, nhận cuộc gọi của shipper (nhân viên giao hàng) hoặc được liên hệ khi đơn hàng có vấn đề. Nhưng chuyện gì xảy ra nếu sau khi giao dịch kết thúc, doanh nghiệp tiếp tục sử dụng số này để gửi tin nhắn SMS quảng cáo hoặc chuyển vào tệp remarketing (tiếp thị lại).

Về mặt dữ liệu, doanh nghiệp vẫn đang sử dụng cùng một trường thông tin. Nhưng về mặt pháp lý, mục đích xử lý đã thay đổi. Mục đích “thực hiện giao dịch” và mục đích “tiếp thị” không nên được mặc định là một, chỉ vì chúng dùng chung một dữ liệu. Đây là lý do việc quản trị dữ liệu theo từng mục đích thường hữu ích hơn việc chỉ quản trị theo loại dữ liệu.

Ví dụ: A mua một máy chạy bộ và cung cấp số điện thoại để giao hàng. Sau đó, số điện thoại được dùng để gửi thông tin về gói bảo trì của chính sản phẩm đã mua và đồng thời được chia sẻ cho một công ty bảo hiểm để giới thiệu sản phẩm sức khỏe. Hai hoạt động này có mức độ liên hệ với giao dịch ban đầu rất khác nhau. Doanh nghiệp cần tách riêng từng data flow để đánh giá mục đích, thông báo và cơ chế lựa chọn tương ứng; không nên dựa vào một sự đồng ý chung ở thời điểm checkout (hoàn tất) để bao trùm toàn bộ chuỗi khai thác về sau.

2.6. Khi người dùng thực hiện quyền: policy (chính sách) có ghi, nhưng hệ thống có làm được không?

Một Privacy Policy có thể ghi rất đầy đủ rằng người dùng có quyền truy cập, chỉnh sửa, rút lại sự đồng ý, yêu cầu xóa hoặc thực hiện các quyền khác theo pháp luật. Nhưng quyền chỉ thực sự có ý nghĩa khi doanh nghiệp có thể tiếp nhận và xử lý yêu cầu đó trong thực tế.

Ví dụ: A yêu cầu xóa tài khoản. Customer Service (bộ phận chăm sóc khách hàng) xác nhận đã đóng tài khoản trên ứng dụng, nhưng dữ liệu của A vẫn còn trong CRM, nền tảng email marketing, hệ thống chăm sóc khách hàng và một file Excel mà sales (bộ phận kinh doanh) từng export (xuất dữ liệu). Nếu doanh nghiệp không có cơ chế xác định nơi dữ liệu của A đang tồn tại và phân biệt dữ liệu nào phải xóa, dữ liệu nào cần tiếp tục lưu vì nghĩa vụ pháp lý hoặc mục đích hợp pháp khác, việc “xóa tài khoản” trên giao diện chưa chắc đã đồng nghĩa với việc yêu cầu của A đã được xử lý đầy đủ.

Tương tự, nếu A rút lại sự đồng ý đối với mục đích tiếp thị nhưng CRM đã cập nhật còn nền tảng email của vendor chưa đồng bộ, A vẫn tiếp tục nhận quảng cáo. Khi đó, vấn đề nằm ở việc hệ thống nội bộ có truyền được lựa chọn của người dùng tới tất cả các điểm đang sử dụng dữ liệu hay không. Nếu điểm này không được kiểm tra và giải quyết đồng bộ, vi phạm vẫn có thể âm thầm len lỏi mà doanh nghiệp không thể ngờ đến.

Vì vậy, để thực hiện quyền của người dùng cần, thay vì chỉ đặt ra những điều khoản chung trong chính sách, sẽ hiệu quả hơn nếu doanh nghiệp thiết lập một workflow (quy trình xử lý) cụ thể: ai tiếp nhận, ai xác minh, hệ thống nào cần kiểm tra, vendor nào cần được thông báo, ai phê duyệt ngoại lệ và bằng chứng nào được lưu để chứng minh yêu cầu đã được xử lý. Lộ trình này nên được công bố rõ ràng tại chính sách, cùng các biểu mẫu/phương thức mà người dùng cần điền để thực hiện mỗi yêu cầu.

Tóm lại, có thể nhìn toàn bộ customer journey ở trên qua bảng sau:

3. Những điểm doanh nghiệp thường dễ vướng khi hai lớp nghĩa vụ giao nhau

Từ customer journey trên, qua thực tế tư vấn cho các khách hàng hoạt động B2C có hoạt động xử lý trên 2 nhóm dữ liệu, LNV nhận thấy rủi ro thường không nằm ở việc doanh nghiệp hoàn toàn không có chính sách mà nằm ở khoảng cách giữa các lớp tài liệu này với data flow thực tế, thường thấy là:

3.1. “Consent overload” (Quá tải yêu cầu đồng ý): càng nhiều checkbox chưa chắc càng minh bạch

Khi cố gắng đáp ứng nhiều yêu cầu pháp lý cùng lúc, một số doanh nghiệp có xu hướng thêm nhiều checkbox hoặc gộp một loạt mục đích vào một câu “đồng ý tất cả”. Cả hai cách đều có bất cập. Nếu tách quá nhiều, người dùng có thể bấm liên tục để đi qua màn hình mà không đọc. Nếu gộp quá rộng, người dùng lại khó biết lựa chọn của mình đang áp dụng cho mục đích nào.

Ví dụ, một form có bốn lựa chọn riêng cho tạo tài khoản, cá nhân hóa, email marketing và chia sẻ dữ liệu cho đối tác thường cho phép doanh nghiệp quản trị consent (sự đồng ý) chính xác hơn một checkbox duy nhất. Tuy nhiên, nếu mỗi màn hình lại có thêm năm đến bảy consent khác nhau với cách diễn đạt kỹ thuật, trải nghiệm lại trở nên nặng nề. Do đó, không phải là “càng nhiều checkbox càng an toàn”, bài toán cần giải quyết ở đây là thiết kế sự lựa chọn tương ứng với từng purpose quan trọng, đủ rõ để người dùng hiểu và đủ cấu trúc để hệ thống có thể ghi nhận, cập nhật và tôn trọng lựa chọn đó.

3.2. “Vendor sprawl” (Sự phân tán nhà cung cấp): doanh nghiệp biết vendor nào có data, nhưng chưa chắc biết vendor đang làm gì với data

Một doanh nghiệp có thể dễ dàng lập danh sách các nhà cung cấp đã ký hợp đồng. Khó hơn là lập danh sách các nhà cung cấp đang thực sự chạm vào dữ liệu. Một nền tảng email có thể dùng sub-processor ở nước ngoài; agency có thể dùng một công cụ social listening (công cụ theo dõi và phân tích thảo luận trên mạng xã hội); call center có thể thuê thêm đơn vị hạ tầng; nhân viên sales có thể tự dùng một phần mềm SaaS (phần mềm cung cấp dưới dạng dịch vụ) mà IT (bộ phận công nghệ thông tin) không quản lý.

Ví dụ, doanh nghiệp chỉ ghi nhận “Agency A” trong vendor register (danh sách bên cung cấp dịch vụ). Nhưng trên thực tế Agency A dùng thêm ba công cụ để phân tích và gửi quảng cáo, trong đó có một công cụ lưu trữ dữ liệu ở hệ thống riêng. Nếu doanh nghiệp không biết chuỗi này, việc đánh giá data flow sẽ dừng quá sớm. Vì vậy, vendor mapping (việc rà soát chuỗi các bên cung cấp dịch vụ) nên đi đến ít nhất các câu hỏi: vendor nhận dữ liệu gì, vì mục đích gì, lưu ở đâu, có chuyển cho ai khác và khi nào phải xóa/trả lại dữ liệu.

3.3. Chính sách – Hệ thống – Thực hành “không khớp nhau”

Đây là rủi ro khó nhìn thấy nhất vì trên giấy doanh nghiệp có thể đã “đủ”, nhưng cũng là vấn đề mà LNV thường xuyên phát hiện được khi thực hiện việc rà soát. Trong trường hợp này, chính sách thường quy định khá chuẩn, hệ thống chính cũng được cấu hình theo cách đó, nhưng hoạt động hàng ngày của các đội ngũ nhân sự như marketing, sales hoặc vendor lại tạo thêm những data flow ngoài thiết kế ban đầu.

Ví dụ, Privacy Policy ghi rằng dữ liệu khách hàng chỉ được truy cập bởi các bộ phận có thẩm quyền. Hệ thống CRM cũng phân quyền đúng. Nhưng để chạy một campaign (chiến dịch) gấp, marketing export toàn bộ danh sách khách hàng ra file Excel và gửi qua email cho agency. Từ thời điểm đó, doanh nghiệp đã có thêm một bản dữ liệu ngoài CRM, ngoài cơ chế phân quyền, ngoài quy tắc lưu trữ và có thể ngoài cả sơ đồ dữ liệu. Rủi ro ở đây không nằm ở câu chữ của policy mà ở việc thực hành đã tạo ra một luồng xử lý mới mà hệ thống quản trị không nhìn thấy.

4. Ở chiều ngược lại, sự giao thoa này cũng tạo ra một bài toán tuân thủ không đơn giản cho doanh nghiệp

Việc bảo vệ dữ liệu và tăng quyền kiểm soát cho người dùng là cần thiết. Tuy nhiên, nhìn từ phía doanh nghiệp, việc cùng một data flow phải đồng thời đi qua nhiều lớp quy định cũng làm tăng đáng kể chi phí nhận diện và tổ chức tuân thủ.

Thứ nhất, cùng một hành vi có thể phải được trả lời bằng nhiều bộ câu hỏi pháp lý. Ví dụ, khi chia sẻ số điện thoại của khách hàng cho một vendor, doanh nghiệp không chỉ cần xác định “có được chia sẻ hay không” mà còn phải xác định người dùng đã được thông tin và có quyền lựa chọn gì dưới Luật BVQLNTD; đồng thời xác định vai trò của vendor, mục đích xử lý, phạm vi dữ liệu và các nghĩa vụ quản trị dưới Luật BVDLCN. Nếu doanh nghiệp hoạt động trong lĩnh vực thương mại điện tử, tài chính, y tế hoặc quảng cáo, data flow còn có thể chịu thêm quy định chuyên ngành.

Thứ hai, chi phí compliance (tuân thủ) không được phân bổ đồng đều. Doanh nghiệp lớn có thể có privacy counsel (luật sư hoặc chuyên gia pháp lý về quyền riêng tư và bảo vệ dữ liệu), DPO/data team (nhân sự/bộ phận phụ trách bảo vệ dữ liệu), consent management platform (nền tảng quản lý sự đồng ý) và hệ thống vendor management (quản lý nhà cung cấp). Một SME (doanh nghiệp nhỏ và vừa) vài chục nhân sự thường không có các nguồn lực này, nhưng vẫn phải xử lý cùng các vấn đề nền tảng: data nằm ở đâu, ai có quyền truy cập, consent nào còn hiệu lực, vendor nào đang giữ dữ liệu. Nếu con đường tuân thủ quá phức tạp, có thể phát sinh một kết quả ngược: doanh nghiệp mua một bộ policy và biểu mẫu để “đủ hồ sơ”, trong khi data flow thực tế gần như không thay đổi.

Theo góc nhìn của LNV, hiệu quả của khung pháp luật vì vậy không chỉ phụ thuộc vào mức độ chặt chẽ của nghĩa vụ mà còn phụ thuộc vào khả năng chuyển những nghĩa vụ đó thành một quy trình đủ rõ, đủ khả thi để doanh nghiệp thực hiện trong vận hành hàng ngày. Ở phía doanh nghiệp, cách tiếp cận thực dụng nhất không phải là lập hai project (dự án) hoàn toàn riêng biệt – một cho Consumer Protection (bảo vệ quyền lợi người tiêu dùng) và một cho Data Protection (bảo vệ dữ liệu) – mà là dùng cùng một customer journey để rà soát đồng thời các lớp nghĩa vụ có liên quan.

Doanh nghiệp có thể bắt đầu bằng một “data compliance map” (bản đồ tuân thủ dữ liệu)

Doanh nghiệp không nhất thiết phải bắt đầu bằng một dự án privacy quá lớn. Một điểm khởi đầu tương đối trực quan là vẽ lại customer journey thực tế: Đăng ký → sử dụng → mua hàng → thanh toán → giao hàng → marketing → chăm sóc → kết thúc/xóa tài khoản. Sau đó, tại mỗi bước, doanh nghiệp có thể xây bốn lớp bản đồ để trả lời bốn nhóm câu hỏi khác nhau.

Ví dụ, với riêng trường dữ liệu “số điện thoại”, data compliance map (bản đồ tuân thủ dữ liệu) có thể cho thấy dữ liệu đi qua bốn mục đích (purpose): (i) OTP khi đăng nhập; (ii) giao hàng; (iii) chăm sóc khách hàng; và (iv) marketing. Doanh nghiệp từ đó sẽ thấy ngay rằng không nên đánh giá “số điện thoại” như một khối duy nhất. Cùng một dữ liệu, nhưng mỗi purpose có data flow, chủ thể nhận dữ liệu, thời hạn lưu trữ và quyền lựa chọn của người dùng khác nhau.

Cách rà soát theo customer journey cũng giúp các bộ phận nói cùng một ngôn ngữ. Legal (bộ phận pháp chế) nhìn thấy căn cứ và nghĩa vụ; IT nhìn thấy hệ thống; product (bộ phận sản phẩm) nhìn thấy trải nghiệm người dùng; marketing nhìn thấy purpose; procurement (bộ phận mua sắm) nhìn thấy vendor. Khi bốn góc nhìn này được đặt trên cùng một data map, doanh nghiệp sẽ dễ phát hiện những điểm “đứt” hơn so với việc mỗi bộ phận tự duy trì một danh sách riêng.

Để kiểm tra nhanh một data flow, LNV gợi ý doanh nghiệp có thể sử dụng các câu hỏi sau:

Cuối cùng, đứng từ đơn vị đã theo dõi quá trình phát triển của hai nhóm văn bản quy phạm ở 02 phương diện, đồng thời tham gia vào quá trình tư vấn tuân thủ tại một số doanh nghiệp B2C, LNV cho rằng sự giao thoa giữa Luật BVQLNTD và Luật BVDLCN không chỉ dừng lại ở việc làm phát sinh thêm một lớp nghĩa vụ pháp lý cho doanh nghiệp. Quan trọng hơn, nó buộc doanh nghiệp nhìn cùng một data flow từ hai phía: một phía là cách dữ liệu được quản trị bên trong hệ thống; phía còn lại là những gì người dùng được biết, được lựa chọn và có thể kiểm soát trong customer journey.

Theo LNV, một chính sách dữ liệu phù hợp chỉ nên được xem là điểm bắt đầu. Việc tuân thủ chỉ trở nên có ý nghĩa khi chính sách, giao diện người dùng, cấu hình kỹ thuật, hoạt động thực tế của các bộ phận và cách vendor xử lý dữ liệu phản ánh cùng một data flow. Nếu một trong các lớp này vận hành khác với những lớp còn lại, khoảng trống tuân thủ thường xuất hiện chính ở phần chênh lệch đó.

Vì vậy, thay vì rà soát từng văn bản pháp luật như những dự án độc lập, doanh nghiệp B2C có thể bắt đầu từ chính hành trình của người dùng và theo dấu dữ liệu xuyên suốt hành trình đó. Khi doanh nghiệp trả lời được dữ liệu đi từ đâu, được dùng vì lý do gì, ai đang chạm vào dữ liệu, người dùng đã được biết và lựa chọn đến đâu, và dữ liệu kết thúc ở đâu, việc tuân thủ pháp luật mới có cơ sở để chuyển từ “đủ hồ sơ” sang quản trị dữ liệu thực chất. Và, nếu các Anh, Chị muốn tìm kiếm một đội ngũ chuyên nghiệp đồng hành trong quá trình này, LNV rất mong được Quý Anh, Chị nhớ đến như một trong những lựa chọn tiềm năng.

Người thực hiện: Luật sư Phan Nhi, Cộng sự Hoàng Vy

Lưu ý: Bài viết này được thực hiện dựa trên quy định của pháp luật Việt Nam (hiện hành). Những thông tin tại bài viết này chỉ nên được sử dụng nhằm mục đích tham khảo. Chúng tôi không chịu trách nhiệm hay có nghĩa vụ pháp lý đối với bất kỳ cá nhân, tổ chức nào sử dụng thông tin tại bài viết này ngoài mục đích tham khảo. Trước khi đưa ra bất kỳ sự lựa chọn hoặc quyết định nào, Quý khách vui lòng tham vấn thêm các khuyến nghị một cách chính thức, hoặc liên hệ LexNovum Lawyers để nhận được sự tư vấn chuyên sâu từ chúng tôi.

Vui lòng trích dẫn nguồn “LexNovum Lawyers” khi sử dụng hoặc chia sẻ bài viết này tại bất kỳ đâu.