sys-analysis-design/sa-output/e-commerce/02-architecture/adr/ADR-008_vung-luu-tru-pii-chinh-sach-chia-se-seller.md

ADR-008 — Vùng lưu trữ dữ liệu cá nhân (residency) và chính sách chia sẻ PII cho seller khi tách đơn

Tên file: adr/ADR-008_vung-luu-tru-pii-chinh-sach-chia-se-seller.md

Status	Proposed (🔴 — phủ quyết thuộc Security/Legal, chưa có người, xem OQ-007)
Date	2026-09-15
Người quyết	Security/Legal (theo decision-radar.md §5 — "Bảo mật, quyền riêng tư": đề xuất SA, chốt Security, phủ quyết Security). Chưa có đại diện Pháp chế/Bảo mật được chỉ định — OQ-007 mở từ GĐ1, kế thừa RISK-03 của BA
Người đề xuất	SA (qua skill sa-2-architecture, hoạt động adr)
Điểm radar	~7/10
Supersedes	—
Superseded by	—
Liên quan	ASR-008 · QAS-011 · CON-06 · ASM-04 · RBAC_CartCheckout §4 (BA) · OQ-007

⚠️ ADR bất biến sau khi Accepted. Muốn đổi quyết định thì viết ADR mới có Supersedes: ADR-008 và đổi trạng thái bản cũ thành Superseded by.

---

1. Bối cảnh

Khi tách đơn theo seller (ADR-003), hệ thống phải chia sẻ một số trường PII của khách hàng (địa chỉ giao hàng, số điện thoại người nhận) cho seller tương ứng để họ giao hàng. DRV-07 ghi nhận: việc này chưa được rà soát theo Nghị định 13/2023 vì dự án chưa có đại diện Pháp chế/Bảo mật được chỉ định (OQ-007, kế thừa RISK-03 của BA). RBAC_CartCheckout §4 (BA) đã đánh dấu "mức che dữ liệu khi hiển thị cho seller — chưa chốt". ASM-04 (residency ap-southeast-1 đủ đáp ứng NĐ13/2023) cũng chưa được xác nhận.

🔴 Đây là ADR mà SA KHÔNG có thẩm quyền chốt — theo decision-radar.md §5 và D10, quyết định bảo mật/quyền riêng tư thuộc Security, phủ quyết thuộc Security. SA chỉ chuẩn bị phương án và danh sách trường để người có thẩm quyền quyết.

Ràng buộc đang chi phối:

Nguồn	Nội dung
CON-06	NĐ13/2023 — bảo vệ dữ liệu cá nhân, cứng, không thương lượng
ASR-008	Data-minimization khi chia sẻ PII cho seller + xác nhận residency trước go-live
QAS-011	100% trường PII rà soát trước go-live, 0 trường dư thừa
RBAC_CartCheckout §4 (BA)	Mức che dữ liệu khi hiển thị cho seller — chưa chốt

Cái đã biết chắc / cái còn là giả định:

Điều	🟢 Đã kiểm chứng / 🔴 Giả định	Bằng chứng
NĐ13/2023 áp dụng cho cả PII khách hàng và giấy tờ KYC seller	🟢 Đã kiểm chứng	CON-06, pháp luật hiện hành
Region ap-southeast-1 (Singapore) đáp ứng đủ yêu cầu residency của NĐ13/2023	🔴 Giả định (ASM-04)	Chưa có xác nhận Pháp chế — NĐ13/2023 không yêu cầu dữ liệu phải nằm trong lãnh thổ VN tuyệt đối trong mọi trường hợp, nhưng cần đánh giá cụ thể theo loại dữ liệu
Danh sách trường PII "cần thiết để giao hàng" đã đầy đủ và không dư thừa	🔴 Giả định	SA đề xuất ở §2, chưa có Pháp chế/Bảo mật rà soát

2. Phương án đã cân nhắc

PA-1 — Chia sẻ toàn bộ hồ sơ khách hàng cho seller (không data-minimization)

Mô tả	Khi tách đơn, gửi toàn bộ thông tin Customer (bao gồm email, lịch sử mua hàng…) cho seller tương ứng
Ưu	Đơn giản nhất về mặt kỹ thuật — không cần lọc trường
Nhược	Vi phạm rõ nguyên tắc data-minimization của NĐ13/2023; tăng đáng kể bề mặt rủi ro nếu seller bị lộ dữ liệu (seller không có cùng mức kiểm soát bảo mật như sàn)
Chi phí đảo ngược	Cao — nếu vi phạm bị phát hiện sau go-live, phải thu hồi truy cập + có thể chịu chế tài pháp lý

PA-2 — Whitelist trường tối thiểu cần thiết để giao hàng (đề xuất, chờ Security/Legal chốt)

Mô tả	Chỉ chia sẻ: recipient_name, phone, address_line cho seller tương ứng với OrderSeller của họ — không chia sẻ email, lịch sử mua hàng, hay thông tin của các seller khác trong cùng Order
Ưu	Đáp ứng nguyên tắc data-minimization; giới hạn bề mặt rủi ro đúng phạm vi cần thiết cho nghiệp vụ (giao hàng)
Nhược	Cần cơ chế lọc trường chính xác ở tầng API (không được lộ nhầm trường khi trả response cho seller); cần review định kỳ khi thêm trường mới vào Customer/Order
Chi phí đảo ngược	Thấp — mở rộng whitelist sau này nếu cần thêm trường là thay đổi nhỏ, không phải viết lại

PA-3 — Không chia sẻ trực tiếp, dùng dịch vụ vận chuyển làm trung gian (ẩn danh hoá địa chỉ)

Mô tả	Sàn không gửi PII trực tiếp cho seller; địa chỉ giao hàng được gửi thẳng cho GHN/GHTK, seller chỉ nhận mã vận đơn để đóng gói mà không biết địa chỉ cụ thể của khách
Ưu	Giảm bề mặt rủi ro nhiều nhất — seller không bao giờ thấy PII khách hàng
Nhược	Không khớp mô hình vận hành thực tế của marketplace VN hiện tại (seller thường tự đóng gói và ghi địa chỉ lên đơn hàng, không phải drop-shipping qua đơn vị vận chuyển trung gian hoàn toàn); cần thay đổi quy trình vận hành seller đáng kể — vượt phạm vi MVP
Chi phí đảo ngược	Cao — thay đổi mô hình vận hành sau go-live ảnh hưởng trải nghiệm seller đã quen

Bảng so sánh

Tiêu chí	PA-1	PA-2	PA-3
Đáp ứng data-minimization (CON-06, QAS-011)	❌	✅	✅ Cao nhất
Khớp mô hình vận hành seller hiện tại	✅	✅	❌ Cần thay đổi lớn
Độ phức tạp kỹ thuật thêm	Thấp	Trung bình (lọc trường)	Cao (tích hợp vận chuyển sâu hơn)

3. Quyết định

Đề xuất PA-2 — Whitelist trường tối thiểu (recipient_name, phone, address_line) cho seller tương ứng với OrderSeller của họ.

🔴 Đây là đề xuất của SA, chưa phải quyết định. Theo D10, chấp nhận rủi ro bảo mật/quyền riêng tư là quyết định của Security/Legal, không phải của SA. ADR này giữ Proposed cho tới khi có đại diện Pháp chế/Bảo mật thật rà soát và ký.

Vì sao đề xuất PA-2: Cân bằng giữa đáp ứng data-minimization (loại PA-1) và khả thi vận hành trong MVP (loại PA-3, vốn cần thay đổi mô hình vận hành seller ngoài phạm vi hiện tại).

Phạm vi áp dụng (nếu được chốt): Toàn bộ luồng tách đơn theo seller (ADR-003) và mọi API trả dữ liệu OrderSeller cho phía Seller Management.

Điều kiện chuyển Proposed → Accepted

Điều kiện	Ai xác nhận	Trạng thái hiện tại
PO chỉ định đại diện Pháp chế/Bảo mật	PO	🔴 Chưa có người (OQ-007, mở từ GĐ1)
Đại diện đó rà soát danh sách trường whitelist ở §2 PA-2 và ký chấp nhận	Security/Legal	Chờ có người
Xác nhận ASM-04 — region ap-southeast-1 đáp ứng đủ residency NĐ13/2023	Security/Legal	Chưa xác nhận

🔴 ADR này chặn hoàn toàn cho tới khi có người — không có ai để ký ngoài SA đề xuất. Đây là điểm chặn nghiêm trọng nhất trong 12 ADR (theo GUIDE.md: "phát hiện muộn nhất và đau nhất luôn đến từ đây").

4. Phương án bị loại và lý do

Phương án	Loại vì	Gắn với	Điều kiện nào thì xét lại
PA-1 — Chia sẻ toàn bộ hồ sơ	Vi phạm rõ data-minimization của NĐ13/2023	CON-06, QAS-011	Không xét lại — vi phạm pháp luật
PA-3 — Ẩn danh hoá qua vận chuyển trung gian	Không khớp mô hình vận hành seller hiện tại; vượt phạm vi MVP	Mô hình vận hành seller đã chốt ở brief	Nếu về sau chuyển sang mô hình fulfillment tập trung (kho sàn quản lý đóng gói) — xét lại, ngoài phạm vi MVP hiện tại

5. Hệ quả

Hệ quả tích cực (nếu PA-2 được Security/Legal chấp nhận)

• Giới hạn bề mặt rủi ro đúng phạm vi cần thiết cho nghiệp vụ giao hàng
• Có cơ sở whitelist rõ ràng để audit định kỳ

Hệ quả tiêu cực phải sống chung

• Cần cơ chế lọc trường chính xác ở tầng API — rủi ro lộ nhầm trường nếu code thay đổi không rà soát lại whitelist
• Chưa có người ký — dự án phải chấp nhận rủi ro pháp lý mở cho tới khi có đại diện Pháp chế

Cái quyết định này khoá lại

Muốn đổi về sau thì	Tốn
Mở rộng chia sẻ thêm trường sau khi đã chốt whitelist hẹp	Cần rà soát lại toàn bộ với Pháp chế trước khi thay đổi — không tự ý mở rộng

Việc phát sinh

Việc	Chủ	Hạn	Ghi ở đâu
PO chỉ định đại diện Pháp chế/Bảo mật	PO	Trước go-live, càng sớm càng tốt	OQ-007
Đại diện đó rà soát whitelist + xác nhận residency	Security/Legal	Sau khi có người	—
Thiết kế cơ chế lọc trường ở tầng API	SA (hoạt động sec/dat)	GĐ2 tiếp theo	SEC_e-commerce, DAT_e-commerce

6. Cách kiểm chứng quyết định này được tuân thủ

Cách kiểm	Công cụ	Chạy ở đâu	FIT
Response API trả cho Seller Management chỉ chứa đúng trường whitelist	Contract test / schema validation	CI	FIT-11 (ứng viên)
Audit định kỳ so khớp trường thực tế truyền cho seller vs whitelist đã duyệt	Review thủ công định kỳ bởi Security/Legal	Hàng quý (đề xuất, chưa chốt tần suất)	⚠️ Khuyến nghị — không tự kiểm được hoàn toàn, cần review thủ công

7. Điều kiện xét lại

Dấu hiệu	Ngưỡng	Ai theo dõi
Có đại diện Pháp chế/Bảo mật được chỉ định	Ngay khi có	PO
Phát hiện lộ trường PII dư thừa qua audit	Bất kỳ phát hiện nào	Security
NĐ13/2023 hoặc quy định liên quan thay đổi	Khi có văn bản pháp luật mới	Legal

8. Tham chiếu

• POC: Không áp dụng
• Bài đo: Audit thủ công định kỳ (chưa chốt tần suất)
• Tài liệu ngoài: RBAC_CartCheckout_v1.0.md §4 (BA), RISK_CartCheckout_v1.0.md RISK-03 (BA)

9. Review log (không đổi Status)

Ngày	Người review	Vai trò	Quyết định	Lý do chưa chuyển Accepted
2026-09-15	Điều phối dự án (thay mặt Tech Lead, chế độ chạy thử)	Tech Lead (ký thay, ngoại lệ DEC-01)	Reviewed (Proposed giữ nguyên) — nội dung đủ làm cơ sở thiết kế tiếp (icd/dat/sec/inf/fail)	Chặn hoàn toàn — PO chưa chỉ định đại diện Pháp chế/Bảo mật (OQ-007); không ai có thẩm quyền ký

Đây là ghi nhận review nội dung, không phải "sign" theo nghĩa gate: Status giữ nguyên Proposed. Xem 00-index/ADL_e-commerce.md (Change Log — Review 2026-09-15) và ADL §8 "Việc phải làm" cho điều kiện chuyển Accepted. Confidence tổng thể của lượt review: 🔴 — AG2 chưa ký.

• Thảo luận: ASR_e-commerce_v1.0.md §B2 ASR-008, ARISK_e-commerce_v1.0.md §3 ARISK-06