내부 감사 체크리스트: 일당 선지급 50가지 통제 및 증거

내부 감사 체크리스트: 일당 선지급 50가지 통제 및 증거

내부 감사는 일당 선지급의 모든 체인을 확인해야 합니다: 올바른 사람 – 올바른 작업 – 올바른 권한 – 올바른 금액 – 올바른 계좌 – 올바른 상태 – 올바른 급여 기간. 각 결론은 추적 가능한 증거를 기반으로 해야 하며, 인터뷰나 인터페이스 스크린샷만으로는 충분하지 않습니다. 아래의 50가지 통제 체크리스트는 기업이 정기적인 검사 프로그램을 구축하는 데 도움을 줍니다.

> 간단히 말해서: 10개의 그룹으로 감사를 수행하십시오. 각 그룹은 다섯 가지 통제를 포함합니다: 관리; 인사; 출퇴근 기록; 공식/한도; 거래; 은행; 급여; 개인 데이터; 보안/사고; 변경/비즈니스 연속성. 위험에 따라 샘플을 선택하고 원본 데이터에서 최종 결과까지 다시 확인하십시오.

> 경고: 이것은 참고용 체크리스트이며, 감사 표준이나 법적 의견이 아닙니다. 기업은 규모, 계약, 정책, 시스템 및 실제 위험 평가에 따라 조정해야 합니다. 코드에 포함되어 있다고 해서 통제가 효과적으로 운영되고 있음을 증명하지 않습니다.

1. 감사 목표

(자세한 내용: 일당 선지급 법적, 보안, SLA, 조정 심사 파일.)

프로그램은 다음을 답해야 합니다:

1. 자격이 있는 사람만 사용할 수 있습니까?
2. 완료되고 승인된 작업만 가용성을 생성합니까?
3. 공식, 한도 및 예약이 올바르게 승인/적용되었습니까?
4. 거래가 중복, 잘못된 사람 및 불명확한 상태를 방지합니까?
5. 은행 명세서가 거래 기록과 일치합니까?
6. 수령한 금액이 올바른 급여에 포함되고 누적되지 않습니까?
7. 개인 데이터가 올바른 목적/권한으로 처리됩니까?
8. 사고 및 변경이 통제됩니까?
9. 관리 보고서가 완전하고 정확합니까?
10. 이전 권고 사항이 수정되었습니까?

2. 범위 및 빈도

다음에 적용할 수 있습니다:

• go-live 전 검사;
• 30–90일 후 검사;
• 분기/연간 정기 감사;
• 사고 후 갑작스러운 검사;
• 대형 고객 개설 전 검토;
• 은행, 공식 또는 급여 변경 시 검사.

범위에는 법인, 고객, 기간, 시스템, 은행 계좌, 작업 소스, 소프트웨어 버전 및 제3자가 명확히 기록되어야 합니다.

3. 위험 기반 샘플 선택

단순히 무작위로 선택하지 마십시오. 샘플에는 다음이 포함되어야 합니다:

• 큰 가치의 거래/한도 근처;
• 하루/기간 동안 많은 거래를 가진 사람;
• 대기, 실패 후 성공한 거래;
• 승인 후 수정된 작업;
• 퇴사/이동한 사람;
• 여러 고객을 위한 작업;
• 계좌/장비 변경;
• 일반 시간 외 거래;
• 높은 오류율을 가진 고객;
• 회수 불가능한 금액;
• 예측할 수 없는 편차를 발견하기 위한 무작위 샘플.

샘플 크기는 감사자가 전체 및 위험에 따라 결정해야 하며, 모든 기간에 대해 고정된 숫자를 사용하지 않아야 합니다.

4. 발견 평가 척도

수준	특징	예
심각	큰 금액/데이터 위험 또는 핵심 통제 오류	중복 지불, 잘못된 사람, 키 유출
높음	많은 사람/기간에 영향을 미치거나 조정 불가	잘못된 공식, 급여 불일치
중간	통제가 있지만 일관되게 운영되지 않음	지연 승인, 검토되지 않은 권한
낮음	문서/효율성 개선 필요	교육 증거 부족

공식 수준은 금액, 사람 수, 법적 의무 및 수정 기한과 연결되어야 합니다.

5. 그룹 1 — 관리 및 정책 (통제 1–5)

1. 서비스 소유자가 전체 책임을 집니다.
2. 일당 선지급 규정이 유효하며, 승인 권한 및 버전 기록이 있습니다.
3. RACI가 시스템의 실제 권한과 일치합니다.
4. KPI가 노동자에게 거래를 강요하지 않습니다.
5. 위험, 예외 및 조치가 정기적으로 보고됩니다.

증거: 임명 결정, 규정, 권한 매트릭스, 회의록, 대시보드, 위험 기록.

테스트: 세 가지 역할을 선택하고 문서의 권한과 실제 권한을 비교하십시오; 기한이 지난 조치에 책임자가 있는지 확인하십시오.

6. 그룹 2 — 노동자 목록 및 식별 (6–10)

1. 목록에는 현재 근무 중인 사람/올바른 고객만 포함됩니다.
2. 주민등록증이 식별 키로 사용되며 중복되지 않습니다.
3. 출퇴근 기록 코드가 올바른 고객/작업 장소에 연결됩니다.
4. VPBank 계좌가 이름으로 조회되고 사용 전에 소유자와 일치합니다.
5. 장비/계좌 변경 또는 예외가 승인되고 로그에 기록됩니다.

증거: 인사 소스 파일, 동기화 로그, 인증 결과, 변경 기록, 예외 승인 양식.

테스트: 신규, 퇴사, 이동 및 장비 변경된 사람을 샘플로 선택하십시오; 소스 파일에서 현재 사용 권한까지 추적하십시오.

7. 그룹 3 — 출퇴근 기록 및 승인 (11–15)

1. 작업 소스/연결 키/동기화 빈도가 문서화됩니다.
2. 미래 작업 및 확정되지 않은 날은 가용성을 생성하지 않습니다.
3. 권한이 있는 사람만 승인/거부/수정할 수 있습니다.
4. 승인된 작업 수정은 기록을 대기 상태로 되돌리고 이전/이후를 저장합니다.
5. 야간 근무, 초과 근무, 휴가 및 여러 작업 장소가 승인 규칙에 따라 처리됩니다.

증거: 소스 구성, 가져오기 로그, 권한 목록, 감사 추적, 근무/기호 사전.

테스트: 일반 근무, 자정 넘는 근무 및 수정된 기록을 재현하십시오; 가용성 결과를 확인하십시오.

8. 그룹 4 — 공식, 단가, 한도 및 예약 (16–20)

1. 시스템 공식이 승인된 정책과 일치합니다.
2. 단가/일이 올바른 고객 및 유효 기간에 연결됩니다.
3. 최소 한도, 각 명령, 각 날이 올바르게 구성됩니다.
4. 예약/N일 작업이 올바르게 계산되고 표시됩니다.
5. 민감한 매개변수 변경은 네 눈 원칙, 로그 및 변경 후 검토가 있습니다.

증거: 정책 표, 구성, 변경 로그, 승인, 샘플 계산 결과.

테스트: 승인된 작업 × 단가 − 수령 − 예약 공식으로 샘플을 다시 계산하십시오; 1,000원 단위로 내림하고 한도 경계를 확인하십시오.

기본 코드에는 50,000원/회, 300만원/명령 및 500만원/인/일이 포함되어 있습니다; 감사는 실제 적용 수준과 비교해야 하며, 이 숫자를 정책으로 간주하지 않아야 합니다.

9. 그룹 5 — 거래 생성 및 처리 (21–25)

1. 서버는 모든 조건을 다시 확인하며, 앱의 데이터만 신뢰하지 않습니다.
2. 노동자는 각 요청 전에 내용을 확인합니다.
3. 각 요청에는 재생 방지를 위한 안정적인 거래 코드가 있습니다.
4. 동일한 가용성에 대해 두 개의 명령을 방지하는 동시성 잠금이 있습니다.
5. 유효한 응답만이 지출 상태로 전환됩니다.

증거: 흐름 문서, 데이터가 숨겨진 로그, 거래 코드, 자동 테스트, 서약 내용 샘플.

테스트: 거의 동시에 두 개의 요청, 한도 초과 요청, 주민등록증 누락, 승인되지 않은 작업 및 은행의 유효하지 않은 응답을 테스트 환경에서 시도하십시오.

10. 그룹 6 — 은행 및 조정 (26–30)

(자세한 내용: 일당 선지급 거래와 급여 및 회계 조정.)

1. 은행 키 보관 서비스가 분리되고 접근이 제한됩니다.
2. 소스 계좌, 서명자/위임자 및 지출 한도가 관리됩니다.
3. 불명확한 상태는 대기 상태로 유지되며, 새로운 명령이 자동으로 발행되지 않습니다.
4. 보류 금액은 절차에 따라 조사되고 경고 연령이 있습니다.
5. T+1 명세서 조정이 수행되며, 차이가 있는 경우 담당자가 확인합니다.

증거: 자금 흐름 다이어그램, 권한 매트릭스, 조사 로그, 데이터가 숨겨진 명세서, 조정 보고서 및 확인 회의록.

테스트: 기간 내 모든 보류 거래 및 성공/실패 샘플을 선택하십시오; 시스템에서 명세서로, 명세서에서 시스템으로 양방향 대조하십시오.

현재 시스템은 5분 간격의 조사 일정과 08:00 T+1 명세서 읽기를 가지고 있습니다. 이것은 기술 사양입니다; 감사는 실제 실행 및 공식 SLA를 확인해야 합니다.

11. 그룹 7 — 급여 및 정산 (31–35)

1. 성공적으로 확인된 거래만 수령 총액에 포함됩니다.
2. 거래는 올바른 사람, 고객 및 급여 기간에 연결됩니다.
3. 작업일이 커버된 키가 있으며, 다음 기간에 누적되지 않습니다.
4. 총 거래가 급여/급여 명세서의 금액과 일치합니다.
5. 퇴사, 작업 감소, 환불 및 회수 불가능한 금액에 대한 절차가 있습니다.

증거: 거래 파일, 브리지 보고서, 급여, 급여 명세서 샘플, advancecovereddays, 회수 불가능한 금액 기록.

테스트: 사용자 샘플에 대한 조정을 다시 수행하십시오; 기간 시작/종료 컷오프 및 퇴사 사례를 확인하십시오.

소프트웨어 논리만으로 공제/회수 방법을 결론짓지 마십시오; 승인된 정책 및 법적 의견과 비교해야 합니다.

12. 그룹 8 — 개인 데이터 및 프라이버시 (36–40)

(전체 프레임워크: 일당 선지급 도입 시 데이터 보안 및 프라이버시.)

1. 처리 역할, 목적 및 데이터 카테고리가 문서화됩니다.
2. 알림/동의 및 데이터 주체 권리가 적용 시 수행됩니다.
3. 주민등록증, 사진, GPS, 계좌 및 급여 접근 권한이 제한됩니다.
4. 저장 기간, 삭제/익명화 및 하위 처리자가 관리됩니다.
5. 데이터 침해에 대한 탐지, 평가 및 알림 절차가 있습니다.

증거: 정책, 처리 문서, 영향 평가, 하위 처리자 목록, 권한 로그, 삭제 증거, 사고 보고서.

테스트: 수집부터 삭제까지의 데이터 유형을 선택하십시오; 세 개의 내부 계정을 선택하고 권한을 확인하십시오; 데이터 내보내기 로그를 검토하십시오.

현재 법적 프레임워크에는 2025년 1월 1일부터 발효되는 개인 데이터 보호법 91/2025/QH15 및 시행령 356/2025/NĐ-CP가 포함되어야 합니다.

13. 그룹 9 — 정보 보안 및 사고 처리 (41–45)

(자세한 내용: 일당 선지급 거래 보호 계층 및 일당 선지급 사고 발생 시 기업 처리 방법.)

1. 취약점 관리, 패치 및 보안 테스트가 있습니다.
2. 비밀/키가 안전하게 저장, 전환 및 회수됩니다.
3. 중요한 로그가 보호되고, 시간 동기화 및 경고가 있습니다.
4. P1–P4 사고에 대한 사고 지휘관, 에스컬레이션 및 RCA가 있습니다.
5. 비상 정지 스위치가 통제되고 연습됩니다.

증거: 스캔/펜테스트 보고서, 자산 기록, 키 정책, 경고, 사고 티켓, RCA, 연습 보고서.

테스트: 닫힌 사고를 선택하고 타임라인을 확인하십시오; RCA 조치가 완료되었는지 확인하십시오; 퇴사한 사람이 민감한 권한을 잃었는지 확인하십시오.

테스트 파일 수는 독립적인 보안 테스트 또는 운영 통제 증거를 대체하지 않습니다.

14. 그룹 10 — 변경, BCP/DR 및 서비스 종료 (46–50)

1. 모든 릴리스/구성이 요청, 승인, 테스트 및 롤백을 가지고 있습니다.
2. 개발자, 승인자 및 배포자 간의 업무 분리가 위험에 적합합니다.
3. 백업, RTO/RPO 및 복구가 테스트됩니다.
4. 은행/ERP/시트/VietQR 의존성에 대한 중단 계획이 있습니다.
5. 서비스 종료 시 데이터 내보내기/반환/삭제 및 권한 회수가 있습니다.

증거: 변경 티켓, 배포 로그, 백업 복원 보고서, BCP/DR 계획, 연습 결과, 공급업체 오프보딩 체크리스트.

테스트: 긴급 변경 및 일반 변경을 선택하십시오; 후속 검토가 있는지 확인하십시오. 백업을 선택하고 복구 증거를 확인하십시오, 단순히 "백업 성공" 상태만으로는 충분하지 않습니다.

15. 사용해야 할 감사 기술

워크스루

거래를 선택하고 작업에서 급여 명세서까지 프로세스 소유자와 함께 이동하십시오.

재수행

원본 데이터에서 가용성과 총 조정을 다시 계산하십시오.

검사

구성, 로그, 승인 및 문서를 확인하십시오.

관찰

사용자/예외 처리를 감독하십시오.

확인

은행 명세서와 같은 독립적인 출처와 잔액/상태를 확인하십시오.

데이터 분석

전체를 스캔하여 중복 코드, 한도 초과 사용자, 시간 외 거래, 지출 후 수정된 작업 또는 급여 불일치를 찾으십시오.

인터뷰는 프로세스가 어떻게 설명되는지를 알려줄 뿐입니다; 그것이 작동했음을 증명하기에는 충분하지 않습니다.

16. 감사 작업표 샘플

필드	내용
통제 코드	C01–C50
목표	어떤 위험이 통제되는가
소유자	책임자
설계	통제가 적절한가
운영	기간 내에 작동했는가
전체/샘플	규모 및 선택 방법
증거	경로 또는 파일 코드
예외	수량/가치/영향
결론	효과적/비효과적/부분적
조치	담당자 및 기한

17. 데이터 쿼리 제안

• 여러 활동 계정에 연결된 동일한 주민등록증;
• 여러 사람에 연결된 하나의 은행 계좌;
• 동일한 금액/시간/사람의 거래;
• 일일 한도를 초과하는 총계;
• 미래 날짜가 있는 작업이지만 금액 생성;
• 성공적인 거래 후 수정된 작업;
• 성공적인 거래에 대한 명세서 없음;
• 내부 거래 없는 지출 명세서;
• 실패/대기 거래가 급여에 나타남;
• 퇴사한 사람이 여전히 요청을 생성함;
• 변경 구성에 대한 티켓 없음;
• 장기간 활동하지 않은 관리자에게 여전히 권한 있음;
• 비정상적인 시간에 로그 누락.

쿼리는 false positive를 방지하기 위해 테스트되어야 하며 데이터 권한 범위 내에서 수행되어야 합니다.

18. 감사 발견 작성 방법

좋은 발견은 다섯 부분으로 구성됩니다:

1. 기준: 규정/계약/통제가 요구하는 것.
2. 현황: 증거가 보여주는 것.
3. 원인: 통제가 작동하지 않는 이유.
4. 영향: 금액, 사람, 데이터, 법적, 운영.
5. 권고: 구체적인 조치, 담당자 및 기한.

좋지 않은 예: “통제를 강화해야 합니다.”
더 나은 예: “선택된 25개의 한도 변경 중 4개는 독립적인 승인자가 없습니다. 시스템에 네 눈 원칙 승인을 추가하십시오, 기한은…”

익명화되지 않았거나 허가되지 않은 실제 예를 공개하지 마십시오.

19. 수정 추적

각 조치는 다음을 필요로 합니다:

• 소유자;
• 완료 기한;
• 우선 순위;
• 증거 요구;
• 재검토자;
• 상태;
• 연장 이유;
• 수정하지 않을 경우 적절한 권한에 의해 수용된 위험.

계획이 있다고 해서 발견을 닫지 마십시오; 배포 증거와 수정 후 효과를 확인해야 합니다.

20. 자주 묻는 질문

코드에 포함되어 있다고 해서 통제가 효과적이라는 의미인가요?

아닙니다. 구성, 실제 데이터, 운영자 및 기간 내 증거를 확인해야 합니다.

얼마나 많은 거래를 감사해야 하나요?

전체, 위험 및 목표에 따라 다릅니다. 위험 샘플, 무작위 샘플 및 가능한 경우 전체 데이터 분석을 결합하십시오.

운영하는 부분을 스스로 감사하지 말아야 할 사람은 누구인가요?

운영자는 1차 라인에서 자체 검사를 수행할 수 있습니다; 독립적인 평가는 2차/3차 라인 또는 충분한 독립성을 가진 감사가 수행해야 합니다.

보류 거래가 잘못된 것인가요?

아닙니다. 시스템이 안전하게 대기 상태를 유지하고, 적시에 조사하며, 중복 지출이 없는지 확인해야 합니다.

개인 데이터를 별도로 감사해야 하나요?

통합하거나 분리할 수 있지만, 현재 법률/정책에 따라 충분한 전문성과 범위를 가져야 합니다.

21. 결론

효과적인 일당 선지급 감사는 전체 체인을 통해 실제 데이터를 사용하여 재수행해야 합니다. 여러 보호 계층이 있는 시스템도 해당 계층이 활성화되고, 올바른 권한이 있으며, 기간 내에 작동하고 있음을 증명해야 합니다. 50가지 통제는 기업이 설명에 대한 신뢰에서 증거로 전환하는 데 도움을 줍니다: 누가 무엇을 했는지, 어떤 데이터에서, 결과는 어땠는지, 편차는 어떻게 처리되었는지.

공식 참조 자료

• 개인 데이터 보호법 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 · 기업을 위한 일당 선지급