EWA 的個人數據地圖和影響評估 (DPIA)
EWA 中的個人數據地圖：影響評估和生命周期控制清單
EWA 系統不僅僅處理金錢。為了正確識別可訪問的個人和收入部分，系統可能使用身份證、照片、位置、設備、工作日曆、單價、銀行賬戶、交易和工資單。因此，數據保護必須從收集到刪除進行設計，而不僅僅停留在同意屏幕上。
> 簡而言之：企業需要繪製數據地圖，確定哪些數據 → 從哪裡獲取 → 用於什麼目的 → 誰可以查看 → 發送給誰 → 保存多久 → 如何刪除。然後評估風險並選擇控制措施。
> 警告：這是一個管理框架和參考內容，並非完整的影響評估文件或法律意見。法律角色、處理依據、文件和具體義務必須根據《個人數據保護法》、指導文件和實際活動進行確定。
1. 為什麼 EWA 需要單獨的數據地圖？
普通的人力資源系統已經擁有勞動者的數據。EWA 增加了兩個敏感的運營因素：根據已完成的工作獲得報酬的權利和在工資發放前進行支付交易。身份證、打卡代碼或銀行賬戶的錯誤匹配可能同時導致：
- 個人數據洩露；
- 收入顯示錯誤；
- 可用金額計算錯誤；
- 錯誤轉賬；
- 工資結算錯誤；
- 難以解決投訴和證明責任。
數據地圖幫助企業看到整個鏈條，而不是單獨檢查每個應用程序。
2. 發布時需要更新的法律框架
(安全框架：參見 EWA 部署中的數據安全和隱私權。)
在文章更新之日，兩個需要納入審查清單的正式文件是：
- 《個人數據保護法》第 91/2025/QH15 號，於 2025 年 6 月 26 日頒布，2026 年 1 月 1 日生效；
- 第 356/2025/NĐ-CP 號法令，於 2025 年 12 月 31 日頒布，2026 年 1 月 1 日生效，詳細規定了法律的一些條款和執行措施。
企業還必須根據模型審查與勞動、電子交易、網絡安全、銀行支付、稅務、會計和存儲相關的規定。
不應從其他項目複製文件：EWA 的目的、數據、接收方和基礎設施可能不同。
3. EWA 中的 10 個數據組地圖
| 組別 | 數據示例 | 可能的業務目的 | 突出風險 |
|---|---|---|---|
| 人事 | 姓名、員工編號、工作狀態 | 確定資格 | 已離職人員仍可使用 |
| 身份識別 | 身份證、文件照片、OCR 結果 | 正確匹配個人 | 冒名頂替、文件洩露 |
| 聯繫方式 | 電話、電子郵件 | 登錄、通知、支持 | 賬戶被盜、垃圾郵件 |
| 設備 | 設備 ID、登錄會話 | 防止代用、保護安全 | 過度監控、錯誤鎖定 |
| 打卡 | 上下班時間、班次、工號 | 確認已完成的工作 | 工作錯誤、來源錯誤 |
| 位置/圖片 | GPS、自拍、帶水印照片 | 驗證打卡 | 侵犯隱私、位置洩露 |
| 收入 | 單價、工時、保留金、可用金額 | 計算獲得權利 | 工資洩露、計算錯誤 |
| 銀行 | 賬戶號、賬戶持有人姓名 | 驗證和支付 | 錯誤轉賬、欺詐 |
| 交易 | 金額、時間、狀態、訂單號 | 支付、查詢、對賬 | 重複支付、推測財務狀況 |
| 工資單/投訴 | 工資單、扣除項目、工單 | 結算和支持 | 信息洩露、錯誤周期 |
實際清單必須從數據庫、API、日誌、導入/導出文件和子供應商中獲取；不能僅依賴用戶界面。
4. 日薪預支中的數據生命周期
步驟 1 — 同步人事檔案
ERP 提供勞動者、客戶、入職/離職日期和管理關係的名單，根據當前技術日曆。身份證作為身份識別鍵；company_id 和打卡代碼將個人與客戶連接。
需要的控制措施：字段清單、授權來源、重複記錄處理、離職人員鎖定和同步日誌。
步驟 2 — 身份識別和設備綁定
勞動者提供身份證照片；系統使用 OCR 匹配信息並在當前流程中應用一人一設備原則。
需要澄清：每張照片的目的、存儲位置、期限、可查看人員、更換設備流程和 OCR 錯誤處理。
步驟 3 — 記錄打卡
數據可以來自應用程序、客戶的 Google Sheet 或 ERP。應用程序支持自拍/GPS、地理圍欄、QR、信標、WiFi 和上下班打卡。
最小化原則：客戶應僅啟用為已確定的打卡目標所需的方法和數據字段。
步驟 4 — 審核和修改工時
客戶或監督者有權審核/拒絕。已審核的工時修改將記錄返回待審核狀態並保存前後歷史。
控制措施：按客戶分配權限、日誌不可隨意修改、變更警告和權限審查周期。
步驟 5 — 計算可用金額
服務器根據已審核的工時、單價、已接收金額和保留金進行計算；應用限制和四捨五入。
需要透明化：哪些數據影響決策、金額為零/變更的原因、投訴渠道和修改源數據的權限。
步驟 6 — 驗證接收賬戶
標準流程核對 VPBank 賬戶名稱，對比名稱並在驗證後鎖定賬戶號。
控制措施：屏蔽屏幕/日誌中的賬戶號、解鎖/更改賬戶的權限、保存驗證證據和管理查詢供應商。
步驟 7 — 創建和處理交易
系統記錄金額、交易號、時間、反饋和狀態。支付服務保持銀行鎖定與業務應用分離。
控制措施：防重碼、限制包含完整數據的日誌、鎖定/保密權限和狀態不明時保持等待。
步驟 8 — 對賬和工資單
T+1 對賬單、交易賬簿和工資單數據進行匹配。已覆蓋的工作日標記為不再累加。
控制措施：橋接報告、查看工資單的權限、導出限制和差異處理流程。
步驟 9 — 支持、投訴和故障
工單可能會收集更多照片、賬戶、工時和交易數據。
風險：支持人員要求通過未經批准的渠道發送身份證/對賬單或將數據複製到個人設備。
步驟 10 — 保存、刪除和終止
每個數據組可能有不同的保存需求。企業必須制定保存計劃、鎖定/刪除/匿名機制、法律義務例外和完成證據。
5. 誰可以參與數據處理？
不應僅根據公司名稱標記角色。應根據每個活動製作表格：
| 活動 | 可能參與方 | 需要回答的問題 |
|---|---|---|
| 人事管理 | Nhân Kiệt/客戶 | 誰決定目的和數據字段？ |
| 打卡 | 勞動者、客戶、NK、平台 | 誰記錄，誰審核，誰修改？ |
| 存儲/同步 | 基礎設施/軟件供應商 | 數據在哪裡，哪個子供應商訪問？ |
| 賬戶名稱查詢 | NK、VPBank、查詢基礎設施 | 哪些數據被發送和保存？ |
| 支付 | NK、VPBank | 誰決定命令，誰執行？ |
| 工資單 | NK/支付單位 | 哪些數據被輸入，誰批准？ |
| 支持 | NK/客戶/服務方 | 員工看到什麼，通過哪個渠道？ |
法律部門必須根據每個目的確定相應的法律角色；一個組織在不同活動中可能有不同的角色。
6. 30 個影響評估問題清單
(另見：EWA 內部審計清單。)
A. 目的和必要性
- 商業目的和對勞動者的好處是什麼？
- 每個數據字段服務於什麼目的？
- 是否可以用更少的數據達到目標？
- 功能是否有更少侵入性的選擇？
- 數據是否被用於新的目的，如廣告/評分？
B. 來源、質量和透明度
- 數據來自哪裡，哪個來源是真實來源？
- 更新頻率是否合適？
- 勞動者被通知了什麼？
- 他們如何查看和要求更正錯誤數據？
- 是否能解釋為什麼可用金額變化？
C. 數據共享和轉移
- 哪些方接收每個數據組？
- 是否有子處理方？
- 哪些 API/文件將數據傳輸到外部？
- 是否有跨境數據處理/轉移？
- 合同如何規定目的、安全、刪除和事故？
D. 訪問權限和安全
- 誰可以查看身份證、GPS、工資和銀行賬戶？
- 權限是否按客戶/地點限制？
- 特權賬戶是否有 MFA 或強控制？
- 日誌是否包含完整或機密數據？
- 銀行鎖是否被分離、輪換和撤回？
E. 勞動者風險
- 錯誤數據是否會導致失去獲得權利或錯誤轉賬？
- 位置/照片是否可能被用於目的外監控？
- 是否有歧視或強制使用的風險？
- 賬戶被盜會造成什麼後果？
- 投訴流程是否易於訪問且不會報復？
F. 生命週期和應對
- 每個數據組保存多久，為什麼？
- 當勞動者離職時，哪些權限立即被撤回？
- 如何刪除備份和導出？
- 當數據洩露時，誰負責指揮？
- 控制措施已通過哪些證據進行測試？
每個問題應包括：所有者、答案、證據、風險級別、措施、剩餘風險、批准人和重新審查日期。
7. 風險–控制矩陣示例
| 風險 | 情況 | 建議控制措施 | 證據 |
|---|---|---|---|
| 身份錯誤 | 身份證/工號錯誤匹配 | 匹配鍵、重複檢查、修正流程 | 同步日誌、工單 |
| 代打卡 | 使用他人設備/賬戶 | 一人一設備、身份驗證、警告 | 設備日誌 |
| 過度監控 | 持續收集 GPS | 僅在必要事件收集，配置目的 | 配置、通知 |
| 工資洩露 | 管理員超範圍查看 | 按客戶分配權限、數據屏蔽 | 權限矩陣、日誌 |
| 賬戶錯誤 | 錯誤轉賬 | 核對名稱、鎖定賬戶 | 驗證證據 |
| 重複支付 | 超時後重發 | 穩定碼、鎖定、失敗關閉 | 交易日誌 |
| 支持洩露數據 | 通過私人聊天發送身份證 | 安全渠道、指導、適當的 DLP | 工單、培訓 |
| 保存過久 | 未刪除舊數據 | 保存計劃、刪除任務、定期檢查 | 刪除報告 |
8. 根據不同打卡方式的最小化原則
(另見：日薪預支的 6 種打卡方式和為什麼不應代打卡或使用假 GPS。)
自拍 + GPS
僅在打卡時收集足夠的數據以達到目的；避免持續位置跟踪。明確是否需要保存原始照片及保存時間。
地理圍欄
當不需要保存精確坐標歷史時，優先使用“在/不在區域”結果。半徑應符合實際場地。
動態 QR
管理碼的生命周期、班次窗口和拍攝/共享風險。避免直接在 QR 中嵌入個人數據。
信標和 WiFi
限制收集的設備/網絡數據。明確通知目的，並在設備不支持時進行處理。
上下班打卡
位置要求較低，但仍需保護工作日曆、班次和修改歷史。
沒有一種方法適合所有客戶。選擇最少數據但仍能滿足實際打卡風險的方法。
9. 建議的最小權限分配
| 角色 | 應該看到 | 不應默認看到 |
|---|---|---|
| 勞動者 | 自己的數據和交易 | 他人的數據 |
| 監督者 | 指定組的工時 | 完整身份證、賬戶、無需的工資 |
| 客戶 | 合同範圍內的工時/勞動者 | 其他客戶、銀行鎖 |
| 工資單 | 結算所需數據 | 如果不需要則不應看到 GPS/照片 |
| 客服 | 處理工單所需字段 | 默認不應看到完整檔案 |
| 超級管理員 | 需要的運營權限 | 無限制訪問且無日誌 |
| 審計 | 證據/按範圍閱讀 | 修改或發出命令的權限 |
特權權限應在適當時限時，需批准、記錄和定期審查。
10. 數據違規應對計劃
應急手冊至少應包括：
- 發現並記錄時間；
- 隔離但保留證據；
- 確定受影響的系統、數據和人員；
- 評估對勞動者的影響；
- 確定根據規定/合同的義務和期限；
- 法律、信息安全、人力資源、銀行和客戶之間的協作；
- 一致的溝通，不做推測；
- 安全恢復；
- 分析根本原因；
- 跟進補救行動直至結束。
不要在事故處理群聊中發送完整的個人數據。使用事件編號和有權限的證據庫。
11. 需要維持的證據集
- 系統圖和數據流；
- 數據處理清單；
- 接收方/子處理方清單；
- 通知和行使權利的證據；
- 權限矩陣和審查結果；
- 保存/刪除配置；
- 合同/數據附錄；
- 影響評估報告和剩餘風險批准；
- 漏洞報告、測試和補救；
- 事故日誌、演習和 RCA；
- 培訓證據；
- 終止/刪除數據的記錄。
僅有文件是不夠的；審計必須抽樣以證明控制措施正在運行。
12. 常見問題
EWA 是否必須獲取 GPS 和自拍？
不。這取決於打卡方式和實際風險。如果工時數據來自其他可靠來源，可能不需要這兩種數據來進行 EWA。
同意是否能解決所有數據問題？
不。企業還必須根據適用規定確定目的、必要性、角色、安全、保存期限、主體權利和其他義務。
是否應該讓客服查看完整的身份證和對賬單？
不應默認這樣做。僅提供情境所需的數據字段，適當屏蔽信息，並在必須查看完整時控制特殊訪問。
刪除賬戶是否意味著刪除所有數據？
不一定。數據可能存在於業務系統、日誌、導出和備份中；某些數據還必須根據義務保存。政策必須明確描述每個層次。
在上線前進行一次影響評估是否足夠？
不夠。當添加新數據類型、目的、打卡方式、銀行、子處理方、數據轉移、算法或發生重大事故時，需要重新審查。
官方法律來源
- 《個人數據保護法》第 91/2025/QH15 號，2026 年 1 月 1 日生效。
- 第 356/2025/NĐ-CP 號法令，詳細規定了法律的一些條款和執行措施，2026 年 1 月 1 日生效。
---
作者： Do Huy Le — Do Huy Le，Nhan Kiet Manpower Supply Co., Ltd.
企業日薪預支解決方案諮詢： 熱線 0937.022.655 · 電郵 info@nhankiet.vn · 企業日薪預支