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`