GDPR là gì

GDPR (General Data Protection Regulation) là quy định bảo vệ dữ liệu cá nhân của Liên minh châu Âu, có hiệu lực từ tháng 5/2018. Đây không phải là directive (chỉ thị) cần chuyển đổi thành luật quốc gia mà là regulation, nghĩa là áp dụng trực tiếp và đồng nhất trên toàn bộ 27 quốc gia thành viên EU.

Điểm thường bị hiểu nhầm nhất về GDPR là phạm vi địa lý. Rất nhiều công ty ngoài EU nghĩ rằng GDPR không liên quan đến mình vì mình không đặt văn phòng tại EU. Suy nghĩ này sai từ gốc. Article 3 của GDPR quy định rõ phạm vi extraterritorial: quy định này áp dụng cho bất kỳ tổ chức nào xử lý dữ liệu cá nhân của data subjects (người dùng, cư dân) đang cư trú tại EU, bất kể tổ chức đó đặt trụ sở ở đâu trên thế giới.

Nếu bạn có khách hàng EU, xây hệ thống chứa dữ liệu người dùng EU, hay làm outsourcing cho công ty EU, bạn nằm trong phạm vi GDPR.

Nguồn: EUR-Lex GDPR Article 3 (eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32016R0679)

GDPR áp dụng cho công ty Việt Nam khi nào

Article 3 xác định ba trường hợp kích hoạt extraterritorial scope. Hiểu ba trường hợp này giúp bạn tự đánh giá được mình có nằm trong phạm vi hay không, thay vì phải đợi khách hàng EU hỏi.

Trường hợp thứ nhất: bạn cung cấp hàng hóa hoặc dịch vụ cho cư dân EU, dù có tính phí hay miễn phí. Một SaaS Việt Nam có free tier mà người dùng EU đăng ký cũng đã đủ điều kiện.

Trường hợp thứ hai: bạn monitor hành vi của cư dân EU. Bất kỳ hệ thống analytics, tracking cookie, profiling, hay behavioral targeting nào nhắm vào người dùng EU đều thuộc trường hợp này.

Trường hợp thứ ba là phổ biến nhất với ngành IT outsourcing Việt Nam: bạn xử lý dữ liệu EU theo hợp đồng với một controller đặt tại EU. Nghĩa là dù bạn không trực tiếp giao tiếp với người dùng EU, chỉ cần bạn xây hoặc vận hành hệ thống xử lý dữ liệu đó theo chỉ thị của khách hàng EU, bạn nằm trong phạm vi GDPR.

Một số ví dụ cụ thể của công ty Việt Nam:

Đội outsourcing xây CRM hoặc ERP cho công ty Đức, trong đó có dữ liệu khách hàng người Đức. Đây là trường hợp điển hình của GDPR processor.

SaaS Việt Nam có user base tại EU, ví dụ công cụ project management, email marketing, hay HR software. Công ty này là data controller theo GDPR vì tự quyết định mục đích xử lý dữ liệu.

E-commerce Việt Nam ship hàng sang EU và lưu tài khoản người dùng EU. Có tài khoản người dùng là đã xử lý dữ liệu cá nhân.

Dev agency xây website cho thương hiệu EU, tích hợp analytics và cookie tracking. Chỉ cần tích hợp Google Analytics thu thập hành vi người dùng EU là đã kéo GDPR vào phạm vi.

Controller vs Processor: công ty Việt Nam là loại nào

GDPR phân biệt hai vai trò chính. Data controller là tổ chức quyết định mục đích và phương thức xử lý dữ liệu. Data processor là tổ chức xử lý dữ liệu theo hướng dẫn của controller, không tự quyết định mục đích.

Ví dụ đơn giản: một công ty Đức thuê đội outsourcing Việt Nam xây hệ thống quản lý nhân sự. Công ty Đức là controller vì họ quyết định dữ liệu nhân viên được thu thập như thế nào và dùng để làm gì. Đội Việt Nam là processor vì họ xây hệ thống theo spec của khách hàng, không tự quyết định mục đích xử lý.

Điều quan trọng cần nắm: nhiều công ty Việt Nam vừa là processor với khách hàng EU, vừa đồng thời là controller với dữ liệu nội bộ của chính mình, bao gồm dữ liệu nhân viên, vendor, và khách hàng trong nước. Hai vai trò này tồn tại song song và có nghĩa vụ khác nhau.

Một nhầm lẫn phổ biến là processor nghĩ mình có ít trách nhiệm hơn controller vì mình chỉ làm theo hướng dẫn. GDPR Article 28 nói ngược lại. Processor có nghĩa vụ pháp lý rõ ràng: phải có Data Processing Agreement (DPA) với controller, phải áp dụng appropriate technical và organizational measures để bảo vệ dữ liệu, phải báo cáo data breach cho controller, và phải hỗ trợ controller thực hiện quyền của data subjects. Không có DPA không phải là lỗ hổng nhỏ. Đây là vi phạm trực tiếp GDPR Article 28.

Nguồn: EUR-Lex GDPR Article 28 (eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32016R0679)

6 nguyên tắc cốt lõi của GDPR (Article 5)

Article 5 đặt ra sáu nguyên tắc mà mọi hoạt động xử lý dữ liệu cá nhân phải tuân theo.

Nguyên tắc đầu tiên là lawfulness, fairness, và transparency. Bạn phải có legal basis hợp lệ trước khi xử lý dữ liệu (consent của người dùng, legitimate interest, thực hiện hợp đồng, nghĩa vụ pháp lý, hoặc một số cơ sở khác). Và bạn phải minh bạch với người dùng về việc bạn thu thập gì và dùng để làm gì.

Nguyên tắc thứ hai là purpose limitation. Dữ liệu chỉ được dùng cho mục đích đã khai báo lúc thu thập. Nếu thu thập email để gửi hóa đơn, bạn không được dùng email đó để gửi marketing trừ khi có consent riêng cho mục đích đó.

Thứ ba là data minimisation. Chỉ thu thập những gì thực sự cần thiết cho mục đích đã nêu. Thu thập thêm "phòng khi cần" không phải là cơ sở hợp lệ.

Thứ tư là accuracy. Dữ liệu phải được giữ chính xác và cập nhật. Nếu người dùng thay đổi địa chỉ, dữ liệu cũ không được tiếp tục dùng cho các mục đích liên quan.

Thứ năm là storage limitation. Dữ liệu không được giữ lâu hơn cần thiết cho mục đích xử lý. Không có khung thời gian cố định trong GDPR, nhưng bạn phải xác định được retention period và có cơ sở cho nó.

Thứ sáu là integrity và confidentiality. Dữ liệu phải được bảo vệ bằng các biện pháp kỹ thuật và tổ chức phù hợp, chống mất mát, phá hủy, hoặc truy cập trái phép.

Quyền của data subjects

Mỗi quyền dưới đây đòi hỏi hệ thống phải hỗ trợ một hoặc nhiều thao tác kỹ thuật cụ thể, không phải chỉ là policy trên giấy.

Quyền truy cập, còn gọi là Subject Access Request, cho phép người dùng yêu cầu bản sao toàn bộ dữ liệu cá nhân bạn đang giữ về họ. Deadline để trả lời là một tháng. Điều này đòi hỏi hệ thống có khả năng export toàn bộ dữ liệu của một user cụ thể, từ database chính đến logs, backup, và analytics.

Quyền xóa (Right to Erasure hoặc Right to be Forgotten) cho phép người dùng yêu cầu xóa dữ liệu trong một số trường hợp nhất định, ví dụ khi dữ liệu không còn cần thiết cho mục đích ban đầu, hoặc khi người dùng rút consent. Từ góc độ kỹ thuật, "xóa" ở đây không chỉ là soft delete trong database chính. Bạn phải trace xem dữ liệu đó còn ở đâu: backup tables, data warehouse, email marketing platform, analytics third-party, logs.

Quyền sửa đổi cho phép người dùng yêu cầu sửa dữ liệu không chính xác. Cần có flow để xử lý yêu cầu này và cập nhật ở tất cả nơi dữ liệu đó tồn tại.

Quyền data portability cho phép người dùng nhận dữ liệu của họ ở định dạng machine-readable, phổ biến là JSON hoặc CSV. Khác với Subject Access Request là để người đọc, data portability là để người dùng chuyển sang dịch vụ khác.

Quyền phản đối (right to object) cho phép người dùng phản đối việc dùng dữ liệu của họ cho direct marketing hoặc profiling. Khi nhận được yêu cầu này, bạn phải dừng các hoạt động đó ngay lập tức.

Implication thực tế: nếu hệ thống của bạn không có API hoặc admin tool để thực hiện deletion, export theo user, và correction, bạn chưa đủ điều kiện kỹ thuật để tuân thủ GDPR. Đây không phải vấn đề policy, đây là vấn đề engineering.

Data Processing Agreement (DPA)

GDPR Article 28 bắt buộc phải có DPA giữa controller và processor trước khi bất kỳ dữ liệu cá nhân EU nào được xử lý. Không có ngoại lệ.

DPA phải bao gồm những nội dung tối thiểu sau: subject matter và duration của việc xử lý, nature và purpose, loại dữ liệu cá nhân và categories of data subjects, cùng với nghĩa vụ và quyền hạn của controller.

DPA không phải NDA. Đây là nghĩa vụ pháp lý cụ thể theo GDPR, không phải thỏa thuận tùy chọn giữa hai bên. Trong thực tế, phần lớn khách hàng EU trong lĩnh vực tech đã quen với việc yêu cầu DPA trong quy trình vendor onboarding. Nếu bạn chưa có DPA template, đây là điểm dừng đầu tiên cần chuẩn bị.

Một điểm cụ thể trong DPA thường bị bỏ qua: processor chỉ được sử dụng subprocessor (nhà thầu phụ xử lý dữ liệu) khi có sự chấp thuận của controller, và phải ký DPA tương đương với mọi subprocessor. Nếu bạn dùng AWS, SendGrid, hay bất kỳ third-party nào để xử lý dữ liệu EU, bạn phải có DPA với họ và thông báo cho controller.

Chuyển dữ liệu EU ra ngoài EU

Nhiều công ty Việt Nam chưa xem xét đến phần này, dù đây là nơi vi phạm GDPR xảy ra thầm lặng nhất.

GDPR Chapter V quy định dữ liệu cá nhân của cư dân EU không được chuyển ra ngoài EU và EEA (European Economic Area) trừ khi có cơ chế chuyển hợp pháp. Việt Nam không nằm trong "adequacy list" của EU, tức là EU chưa công nhận Việt Nam có mức bảo vệ dữ liệu tương đương. Điều này có nghĩa là mỗi lần dữ liệu EU được gửi về server tại Việt Nam, đó là cross-border transfer và phải có cơ sở pháp lý.

Cơ chế phổ biến nhất và khả thi nhất cho công ty Việt Nam hiện nay là Standard Contractual Clauses (SCC), được EU Commission cập nhật vào năm 2021. SCC là bộ điều khoản hợp đồng tiêu chuẩn do EU soạn sẵn, khi ký vào là đủ cơ sở pháp lý cho việc chuyển dữ liệu. Trong trường hợp outsourcing Việt Nam (processor) nhận dữ liệu từ khách hàng EU (controller), module áp dụng là Module 2: controller-to-processor.

Không có SCC khi nhận và xử lý dữ liệu EU = vi phạm GDPR Chapter V. Đây là loại vi phạm nằm trong Tier 2 về mức phạt.

Nguồn: EUR-Lex SCC Decision 2021 (eur-lex.europa.eu/eli/dec_impl/2021/914/oj)

Mức phạt GDPR

GDPR phân mức phạt thành hai tier.

Tier 1 áp dụng cho các vi phạm nhẹ hơn như không có DPA với processor, không có records of processing activities, không thông báo breach đúng hạn. Mức phạt tối đa là €10 triệu hoặc 2% doanh thu toàn cầu của năm tài chính trước, tùy mức nào cao hơn.

Tier 2 áp dụng cho vi phạm nghiêm trọng hơn: vi phạm nguyên tắc cơ bản của Article 5, vi phạm quyền của data subjects, cross-border transfer không có cơ sở pháp lý. Mức phạt tối đa là €20 triệu hoặc 4% doanh thu toàn cầu.

Một số trường hợp phạt nổi bật: Meta bị phạt €1.2 tỷ năm 2023 bởi DPC Ireland liên quan đến cross-border transfer sang Mỹ. Amazon bị phạt €746 triệu năm 2021 bởi Luxembourg CNPD liên quan đến advertising tracking.

Với công ty Việt Nam, cơ chế phạt trực tiếp từ EU Data Protection Authority phức tạp hơn vì không có hiện diện pháp lý tại EU. Tuy nhiên rủi ro thực tế không nằm ở tiền phạt trực tiếp. Vi phạm GDPR thường kéo theo kiện dân sự từ phía khách hàng EU do vi phạm điều khoản hợp đồng, hoặc mất hợp đồng khi khách hàng phát hiện trong quá trình audit. Uy tín trong thị trường EU cũng bị ảnh hưởng lâu dài khi vi phạm được công khai.

Nguồn: EDPB Enforcement Tracker (enforcementtracker.com)

GDPR và Nghị định 13/2023 của Việt Nam

Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân của Việt Nam, có hiệu lực từ tháng 7/2023, có cấu trúc tổng thể khá giống GDPR: cũng có consent, quyền của chủ thể dữ liệu, và nghĩa vụ bảo vệ.

Nhưng chi tiết thì khác. Nghị định 13 định nghĩa dữ liệu nhạy cảm rộng hơn GDPR ở một số loại, ví dụ bao gồm dữ liệu về tình trạng hôn nhân và người bị kết án. Cơ chế thực thi khác hoàn toàn: Nghị định 13 yêu cầu đăng ký với Bộ Công an trong một số trường hợp, điều không có trong GDPR. Phạm vi áp dụng cũng có khác biệt về cách xác định "chủ thể dữ liệu".

Tuân thủ GDPR không tự động đồng nghĩa với tuân thủ Nghị định 13. Đây là hai framework pháp lý riêng biệt với cơ quan quản lý khác nhau. Một bài riêng sẽ so sánh chi tiết hai luật này.

5 bước đầu tiên cho công ty Việt Nam

Bước một: xác định phạm vi. Lập danh sách các hệ thống, sản phẩm, và dự án có xử lý dữ liệu cá nhân của cư dân EU. Bao gồm cả dự án outsourcing đang chạy và các SaaS product có user base EU.

Bước hai: xác định vai trò. Với mỗi hệ thống trong danh sách trên, bạn là controller hay processor? Câu hỏi thực tế để phân biệt: ai quyết định dữ liệu này được dùng để làm gì? Nếu là bạn, bạn là controller. Nếu là khách hàng EU, bạn là processor.

Bước ba: review hợp đồng. Nếu bạn là processor, kiểm tra hợp đồng hiện tại với mỗi khách hàng EU. Có DPA không? Nếu không có, đây là điểm cần bổ sung trước tiên. DPA có thể thêm vào dưới dạng addendum mà không cần ký lại toàn bộ hợp đồng gốc.

Bước bốn: kiểm tra cross-border transfer mechanism. SCC đã được ký chưa? Nếu bạn là processor nhận dữ liệu EU về server tại Việt Nam mà chưa có SCC, đây là vi phạm đang xảy ra và cần xử lý ngay.

Bước năm: thực hiện data mapping. Với mỗi loại dữ liệu cá nhân EU bạn đang xử lý, ghi lại: dữ liệu gì, thu thập từ đâu, lưu ở đâu (database, backup, third-party), chia sẻ với ai, giữ trong bao lâu. Data mapping không phải yêu cầu nộp cho cơ quan quản lý, nhưng là nền tảng để thực hiện mọi yêu cầu GDPR khác. Không có data map, bạn không thể trả lời Subject Access Request hay thực hiện deletion một cách đầy đủ.

Tài liệu tham khảo:

Thẻ:
GDPRBảo vệ dữ liệuEUOutsourcingVietnam
← Quay lại Blog