EWA를 위한 개인 데이터 맵 및 영향 평가 (DPIA)
EWA에서의 개인 데이터 맵: 영향 평가 및 수명 주기 관리 체크리스트
EWA 시스템은 단순히 금액을 처리하는 것이 아닙니다. 올바른 사람과 접근 가능한 수입을 정확히 식별하기 위해, 시스템은 주민등록증, 사진, 위치, 장치, 근무 일정, 단가, 은행 계좌, 거래 및 급여 명세서를 사용할 수 있습니다. 따라서 데이터 보호는 수집부터 삭제까지 설계되어야 하며, 동의 화면에서 멈추지 않아야 합니다.
> 간단히 말해: 기업은 어떤 데이터를 → 어디서 가져오고 → 무엇을 위해 사용하며 → 누가 볼 수 있고 → 누구에게 전송하며 → 얼마나 오래 저장하고 → 어떻게 삭제하는지에 대한 지도를 작성해야 합니다. 이후 위험을 평가하고 통제를 선택합니다.
> 경고: 이는 관리 프레임워크 및 참고 자료로, 완전한 영향 평가 문서나 법적 의견이 아닙니다. 법적 역할, 처리 근거, 문서 및 구체적인 의무는 개인 데이터 보호법, 지침 및 실제 활동에 따라 결정되어야 합니다.
1. 왜 EWA는 별도의 데이터 맵이 필요한가?
일반 HR 시스템은 이미 노동자의 데이터를 보유하고 있습니다. EWA는 운영에 민감한 두 가지 요소를 추가합니다: 이미 수행한 작업에 대한 급여 접근 권한과 급여일 이전의 결제 거래. 주민등록증, 출근 코드 또는 은행 계좌의 오류는 동시에 다음을 초래할 수 있습니다:
- 개인 데이터 유출;
- 잘못된 수입 표시;
- 잘못된 가용 금액 계산;
- 잘못된 사람에게 송금;
- 잘못된 급여 정산;
- 불만 처리 및 책임 증명 어려움.
데이터 맵은 기업이 개별 애플리케이션을 검사하는 대신 전체 체인을 볼 수 있도록 도와줍니다.
2. 출판 시점에 업데이트해야 할 법적 프레임워크
(보안 프레임워크: EWA 구현 시 데이터 보안 및 개인 정보 보호 참조.)
이 글이 업데이트된 시점에서 검토 목록에 포함되어야 할 두 가지 공식 문서는 다음과 같습니다:
- 2025년 6월 26일에 발행되고 2026년 1월 1일부터 시행되는 개인 데이터 보호법 제91/2025/QH15호;
- 2025년 12월 31일에 발행되고 2026년 1월 1일부터 시행되는 법률의 일부 조항 및 시행 방법을 규정한 시행령 356/2025/NĐ-CP.
기업은 또한 노동, 전자 거래, 네트워크 안전/보안, 은행–결제, 세금, 회계 및 저장과 관련된 규정을 검토해야 합니다.
다른 프로젝트에서 문서를 복사하지 마십시오: 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 — 가용 금액 계산
서버는 승인된 근무, 단가, 수령 금액 및 예약에서 계산하며, 제한 및 반올림을 적용합니다.
투명성 필요: 어떤 데이터가 결정에 영향을 미치는지, 0/변경 이유, 불만 채널 및 소스 데이터 수정 권한.
단계 6 — 수신 계좌 확인
표준 프로세스는 VPBank 계좌 이름을 확인하고, 이름을 대조하며 인증 후 계좌 번호를 잠급니다.
통제: 화면/로그에서 계좌 번호 숨김, 계좌 잠금/변경 권한, 인증 증거 저장 및 쿼리 공급업체 관리.
단계 7 — 거래 생성 및 처리
시스템은 금액, 거래 코드, 시간, 응답 및 상태를 기록합니다. 송금 서비스는 업무 애플리케이션과 분리된 은행 키를 유지합니다.
통제: 중복 방지 코드, 전체 데이터 포함 로그 제한, 잠금/비밀 권한 및 불확실한 상태에서 대기 유지.
단계 8 — 대조 및 급여
T+1 명세서, 거래 기록 및 급여 데이터가 대조됩니다. 이미 포함된 근무일은 중복되지 않도록 표시됩니다.
통제: 연결 보고서, 급여 명세서 보기 권한, 내보내기 제한 및 차이 처리 절차.
단계 9 — 지원, 불만 및 사고
티켓은 추가 사진, 계좌, 근무 데이터 및 거래를 포함할 수 있습니다.
위험: 지원 직원이 승인되지 않은 채널을 통해 주민등록증/명세서를 요청하거나 개인 장치에 데이터를 복사할 수 있습니다.
단계 10 — 저장, 삭제 및 종료
각 데이터 그룹은 다른 저장 요구를 가질 수 있습니다. 기업은 저장 일정, 잠금/삭제/익명화 메커니즘, 법적 의무로 인한 예외 및 완료 증거를 설정해야 합니다.
5. 누가 데이터 처리에 참여할 수 있는가?
역할을 회사 이름으로만 라벨링하지 마십시오. 각 활동에 따라 표를 작성하십시오:
| 활동 | 참여 가능한 측 | 답변해야 할 질문 |
|---|---|---|
| 인사 관리 | Nhan Kiet/고객 | 목적과 데이터 필드를 누가 결정하는가? |
| 출근 | 노동자, 고객, 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. 데이터 위반 대응 계획
플레이북에는 최소한 다음이 포함되어야 합니다:
- 발견 및 시간 기록;
- 증거 보존을 위한 격리;
- 시스템, 데이터 및 영향을 받는 사람 식별;
- 노동자에 대한 결과 평가;
- 규정/계약에 따른 의무 및 기한 식별;
- 법무, 정보 보안, HR, 은행 및 고객 간 협력;
- 일관된 커뮤니케이션, 추측 금지;
- 안전한 복구;
- 근본 원인 분석;
- 조치 완료 시까지 수정 조치 추적.
사고 처리 그룹 채팅에 전체 개인 데이터를 보내지 마십시오. 사건 코드 및 권한이 있는 증거 저장소를 사용하십시오.
11. 유지해야 할 증거 세트
- 시스템 다이어그램 및 데이터 흐름;
- 데이터 처리 목록;
- 수신자/하위 처리자 목록;
- 알림 및 권리 실행 증거;
- 권한 매트릭스 및 검토 결과;
- 저장/삭제 구성;
- 데이터 계약/부록;
- 영향 평가 보고서 및 남은 위험 승인;
- 취약점 보고서, 테스트 및 수정;
- 사고 로그, 연습 및 RCA;
- 교육 증거;
- 데이터 종료/삭제 기록.
"문서가 있음" 상태는 충분하지 않습니다; 감사는 통제가 작동하고 있음을 증명하기 위해 샘플을 가져와야 합니다.
12. 자주 묻는 질문
EWA는 반드시 GPS와 셀피를 수집해야 하나요?
아닙니다. 이는 출근 방법과 실제 위험에 따라 다릅니다. 신뢰할 수 있는 다른 출처에서 근무 데이터가 제공된다면, EWA에 이 두 가지 데이터가 필요하지 않을 수 있습니다.
동의 요청이 모든 데이터 문제를 해결하나요?
아닙니다. 기업은 또한 목적, 필요성, 역할, 보안, 저장 기간, 주체의 권리 및 적용 규정에 따른 기타 의무를 결정해야 합니다.
고객 서비스가 전체 주민등록증과 명세서를 볼 수 있도록 해야 하나요?
기본적으로는 아닙니다. 상황에 필요한 데이터 필드만 제공하고, 적절히 정보를 숨기며, 전체를 봐야 할 때 특별 접근을 통제하십시오.
계정 삭제가 모든 데이터 삭제를 의미하나요?
반드시 그렇지는 않습니다. 데이터는 업무 시스템, 로그, 내보내기 및 백업에 있을 수 있으며, 일부 데이터는 의무적으로 저장해야 합니다. 정책은 각 계층을 명확히 설명해야 합니다.
라이브 이전에 한 번의 영향 평가가 충분한가요?
아닙니다. 데이터 유형, 목적, 출근 방법, 은행, 하위 처리자, 데이터 전송, 알고리즘 추가 또는 중요한 사고 발생 시 재검토가 필요합니다.
공식 법적 출처
- 개인 데이터 보호법 제91/2025/QH15호, 2026년 1월 1일 발효.
- 시행령 제356/2025/NĐ-CP, 법률의 일부 조항 및 시행 방법 규정, 2026년 1월 1일 발효.
---
저자: Nguyen Minh Khang — Chuyên viên ban chiến lược, Nhan Kiet Manpower Supply Co., Ltd.
기업을 위한 일당 선지급 솔루션 상담: 핫라인 0937.022.655 · 이메일 info@nhankiet.vn · 기업을 위한 일당 선지급