DPA, điều khoản dữ liệu và quy trình mua sắm: FDE cần biết gì để dự án không kẹt ở khâu pháp lý

Thử hình dung bạn đang ở tuần thứ ba tại site khách. Pipeline đã chạy ổn trên dữ liệu mẫu, và bạn muốn thử một model provider khác cho bước tóm tắt ticket hỗ trợ. Kỹ sư phía khách đồng ý ngay. Rồi một email từ bộ phận pháp chế gửi tới với đúng một câu hỏi: provider này có trong danh sách subprocessor đã được duyệt chưa?

Đây là kiểu điểm dừng không nằm trong code. Bạn không cần thành luật sư. Nhưng bạn là người chạm trực tiếp vào dữ liệu của khách, vì vậy bạn phải đọc được những điều khoản quyết định mình được chạm vào đâu.

Bài này dạy một kỹ năng cụ thể: đọc DPA như đọc một bản spec, rồi chuẩn bị câu trả lời cho vendor review trước khi khách hỏi.

Hợp đồng dữ liệu chính là phạm vi công việc của bạn

Trong ngôn ngữ của GDPR, khách hàng là bên kiểm soát (controller), còn công ty bạn là bên xử lý (processor). Điều 28 của GDPR yêu cầu bên xử lý chỉ xử lý dữ liệu cá nhân theo chỉ dẫn được ghi lại của bên kiểm soát.

Luật Việt Nam đặt ra yêu cầu gần như giống hệt: bên xử lý phải xử lý dữ liệu đúng theo thỏa thuận hoặc hợp đồng đã ký với bên kiểm soát.

Hệ quả rất thực tế. Mỗi khi bạn chạy một script trên dữ liệu thật, export một bảng để debug, hay gửi một đoạn text sang API bên ngoài, hãy hỏi việc đó có nằm trong phạm vi hợp đồng không, rồi mới hỏi nó có chạy được không.

Và “hợp đồng” ở đây phải là văn bản: GDPR yêu cầu thỏa thuận xử lý dữ liệu được lập thành văn bản, kể cả dưới dạng điện tử. Trong một DPA, có bốn điều khoản đụng thẳng vào công việc kỹ thuật.

Subprocessor. Bên xử lý không được dùng thêm bên xử lý khác nếu chưa có sự cho phép bằng văn bản của bên kiểm soát, dù là cho phép cụ thể hay cho phép chung.

Kết thúc dịch vụ. Toàn bộ dữ liệu cá nhân phải được xóa hoặc trả lại, tùy khách chọn.

Audit. Khách có quyền audit, kể cả kiểm tra tận nơi.

Chuyển dữ liệu ra nước ngoài. Nếu dữ liệu rời khỏi EU, cần có cơ chế bảo vệ như Standard Contractual Clauses (SCC), tức các điều khoản mẫu đã được Ủy ban châu Âu phê duyệt sẵn.

Đi trọn một ví dụ: thêm model provider giữa dự án

Quay lại email của bộ phận pháp chế. Giả sử khách là một công ty bán lẻ ở EU, còn provider bạn muốn thử đặt máy chủ ngoài EU. Dưới đây là cách xử lý từng bước.

Bước đầu là xác định provider mới có phải một bên xử lý mới không. Nếu bạn gửi ticket chứa tên và email khách hàng sang API của họ thì câu trả lời là có. Như vậy bạn cần khách cho phép bằng văn bản. Hãy kiểm tra xem DPA hiện tại cho phép chung kèm danh sách subprocessor, hay yêu cầu duyệt từng trường hợp.

Bước thứ hai là chuyện dữ liệu ra nước ngoài. Máy chủ ngoài EU nghĩa là có chuyển dữ liệu sang nước thứ ba, nên pháp chế sẽ hỏi về SCC. Bạn sẽ có câu trả lời nhanh nếu biết DPA của provider hoạt động thế nào.

Lấy ví dụ Anthropic: theo trang hướng dẫn của họ, khi chấp nhận Commercial Terms of Service thì khách cũng chấp nhận luôn DPA của Anthropic, có kèm SCC, và không cần một bước ký riêng. Gửi pháp chế đường link đến điều khoản đó thì nhanh hơn nhiều so với hứa rằng sẽ đi xin chữ ký.

Bước thứ ba là chuyện lưu trữ. Bên mua sẽ hỏi provider giữ dữ liệu bao lâu. Tài liệu hướng dẫn due diligence của Apptension viết thẳng: nếu nhà cung cấp không đưa ra được cơ chế kiểm soát thời gian lưu rõ ràng, hãy mặc định dữ liệu sẽ bị giữ lâu hơn bạn muốn. Bạn cần nắm câu trả lời trước khi vào cuộc họp.

Bước cuối hay bị quên nhất là kết thúc dự án. Nghĩa vụ xóa hoặc trả lại không chỉ áp dụng cho database chính. Nó áp dụng cho cả file CSV bạn trích ra để debug, notebook trên laptop và log có chứa đoạn ticket gốc.

Bảng dưới đây là data-flow map cho chính tình huống này:

Dữ liệu	Nơi lưu	Ai xử lý	Region	Thời gian lưu	Khi kết thúc
Ticket gốc	DB của khách	Khách	EU	Theo chính sách của khách	Khách giữ
Đoạn ticket gửi đi tóm tắt	API provider mới	Subprocessor (chờ duyệt)	Ngoài EU, cần SCC	Hỏi provider	Xóa theo DPA
File trích để debug	Máy của FDE	Bên bạn	Theo nơi đặt máy	Đến hết sprint	Xóa và ghi lại việc đã xóa
Log ứng dụng	Hệ thống log	Bên bạn	Ghi rõ region	Đặt TTL	Xóa hoặc trả lại

Hàng thứ hai chính là câu hỏi pháp chế gửi tới. Có bảng này, bạn trả lời được trong một email thay vì phải mất ba cuộc họp.

Nếu khách ở Việt Nam, lịch dự án có thêm mốc mới

Trước hết cần tách bạch cũ và mới. Luật Bảo vệ dữ liệu cá nhân của Việt Nam có hiệu lực từ ngày 1/1/2026, đi kèm Nghị định 356 ban hành ngày 31/12/2025 để hướng dẫn thi hành, thay cho khung Nghị định 13 trước đây.

Với kế hoạch dự án của bạn, khung mới thêm vào mấy điểm sau.

Mốc 60 ngày. Theo tổng hợp của DLA Piper, phải có hồ sơ đánh giá tác động xử lý dữ liệu (DPIA), và cơ quan chức năng phải nhận được hồ sơ này trong vòng 60 ngày kể từ ngày bắt đầu xử lý. Hãy ghi nó vào kế hoạch triển khai như một milestone thật.

Chu kỳ sáu tháng. Theo phân tích của Tilleke & Gibbins, luật mới yêu cầu cập nhật cả DPIA lẫn hồ sơ đánh giá chuyển dữ liệu xuyên biên giới (TIA) theo chu kỳ sáu tháng nếu có thay đổi. Thêm một model provider đặt ở nước ngoài chính là loại thay đổi đó.

Rủi ro khi chuyển dữ liệu ra nước ngoài. Vi phạm về chuyển dữ liệu xuyên biên giới có thể bị phạt tới 5% doanh thu năm. Vì thế, hãy báo cho phía khách sớm mỗi khi luồng dữ liệu đổi hướng.

Phần hồ sơ của bên bạn. Thời Nghị định 13, bên xử lý cũng phải tự lập và lưu hồ sơ đánh giá tác động như bên kiểm soát, còn chuyển dữ liệu ra nước ngoài cần một hồ sơ riêng nộp Cục An ninh mạng. Quy định cũ đã bị thay thế, nên hãy hỏi pháp chế của khách xem dưới Nghị định 356 bên bạn chịu phần hồ sơ nào.

Vendor review sẽ hỏi gì, và vì sao bạn nên trả lời trước

Quy trình mua sắm ở doanh nghiệp lớn thường có một vòng vendor review. Theo hướng dẫn của Apptension dành cho bên mua, vòng này nên bắt đầu từ luồng dữ liệu và thời gian lưu.

Nhà cung cấp nào không trả lời rõ ràng sẽ bị xếp vào nhóm rủi ro cao. Tài liệu đó cũng nói rằng nếu không kể tên được subprocessor và data region, bạn không thể trả lời một cách thuyết phục câu hỏi dữ liệu đi đâu khi bị audit.

Câu hỏi hay làm vòng review mắc kẹt là phạm vi của báo cáo SOC 2. Một báo cáo SOC 2 chỉ có giá trị với đúng sản phẩm và môi trường được ghi trong phần phạm vi.

Lời khuyên của Apptension là muốn giảm rủi ro cho một vòng review SOC 2 thì đọc phần phạm vi trước tiên. Nếu bạn triển khai một môi trường riêng cho khách mà báo cáo chỉ bao phủ bản SaaS dùng chung, đó là khoảng trống cần nói ra trước khi khách tự phát hiện.

Các bước để tự làm, và những lỗi hay gặp

Ở mỗi khách hàng mới, hãy đi theo một thứ tự cố định. Xin bản DPA và danh sách subprocessor ngay tuần đầu, rồi vẽ data-flow map trước khi chạm vào dữ liệu thật. Đánh dấu mọi công cụ bên ngoài sẽ nhận dữ liệu, đưa các mốc như duyệt subprocessor hay hồ sơ DPIA vào kế hoạch, và viết sẵn checklist xóa dữ liệu cho ngày bàn giao.

Lỗi phổ biến nhất là coi chuyện pháp lý là việc của người khác. Kết quả là FDE thêm một công cụ observability hay một API mới chỉ vì kỹ sư phía khách đồng ý miệng.

Lỗi kế tiếp là quên rằng log và file trích ra cũng là dữ liệu cá nhân. Và một lỗi nữa là đưa ra một báo cáo SOC 2 mà không biết nó bao phủ sản phẩm nào.

Biến nó thành một câu chuyện phỏng vấn

Khi đọc mô tả công việc FDE, bạn nên để ý các cụm như security review, procurement hay customer compliance: nếu chúng xuất hiện, kỹ năng này đáng được đưa lên CV. Và khi được hỏi về một deployment từng bị kẹt, ví dụ ở trên là chất liệu tốt.

Một cách kể gọn: tuần thứ ba, pháp chế của khách chặn việc thêm provider tóm tắt vì chưa có trong danh sách subprocessor và máy chủ đặt ngoài EU. Bạn lập data-flow map sáu cột, gửi kèm link DPA có SCC của provider, đặt TTL cho log và viết checklist xóa file debug.

Kết quả: khách duyệt qua email, không cần thêm cuộc họp. Câu chuyện này cho thấy bạn hiểu cả hai phía của một deployment.

Lần tới khi pháp chế của khách gửi câu hỏi, hãy trả lời bằng một bảng có đủ sáu cột. Đừng trả lời bằng một lời hứa.