内部監査チェックリスト：給与前払いの50の管理と証拠

内部監査チェックリスト：給与前払いの50の管理と証拠

給与前払いの内部監査は、正しい人、正しい仕事、正しい権限、正しい金額、正しいアカウント、正しい状態、正しい給与期間を確認する必要があります。各結論は、インタビューやインターフェースのスクリーンショットだけでなく、追跡可能な証拠に基づいている必要があります。以下の50の管理チェックリストは、企業が定期的な監査プログラムを構築するのに役立ちます。

> 要約: 10のグループごとに5つの管理を監査してください：ガバナンス、人事、勤怠、計算式/制限、取引、銀行、給与、個人データ、セキュリティ/インシデント、変更/事業継続。リスクに基づいてサンプルを選び、元データから最終結果まで再確認します。

> 警告: これは参考用のチェックリストであり、監査基準や法的意見ではありません。企業は規模、契約、ポリシー、システム、実際のリスク評価に応じて調整する必要があります。「コードにある」という状態は、管理が効果的に運用されていることを自動的に証明するものではありません。

1. 監査の目的

(詳細は：給与前払いの法的、セキュリティ、SLA、精算の審査書類を参照してください。)

プログラムは以下の質問に答えるべきです：

1. 資格のある人だけが使用できますか？
2. 承認された仕事だけが利用可能な数を生成しますか？
3. 計算式、制限、リザーブは正しく承認/適用されていますか？
4. 取引は重複、誤った人、または不明な状態を防いでいますか？
5. 銀行の明細書は取引台帳と一致していますか？
6. 受け取った金額は正しい給与に入り、累積されていませんか？
7. 個人データは目的/権限に従って処理されていますか？
8. インシデントと変更は管理されていますか？
9. 管理報告は完全で正確ですか？
10. 前回の推奨事項は修正されましたか？

2. 範囲と頻度

適用可能な場合：

• 稼働前のチェック；
• 30〜90日後のチェック；
• 四半期/年次の定期監査；
• インシデント後の突発的なチェック；
• 大口顧客を開く前のレビュー；
• 銀行、計算式、または給与の変更時のチェック。

範囲には、法人、顧客、期間、システム、銀行口座、仕事のソース、ソフトウェアバージョン、第三者を明確に記載する必要があります。

3. リスクに基づくサンプル選択

ランダムに選ぶだけではありません。サンプルには以下を含むべきです：

• 高価値/制限に近い取引；
• 1日/期間に多くの取引を持つ人；
• 保留、失敗後に成功した取引；
• 承認後に修正された仕事；
• 退職/異動した人；
• 多くの顧客で働く労働者；
• アカウント/デバイスの変更；
• 通常の営業時間外の取引；
• エラー率の高い顧客；
• 回収不能な金額；
• 予測できない偏差を発見するためのランダムサンプルも含む。

サンプルサイズは、監査が全体とリスクに基づいて決定する必要があり、すべての期間に固定された数を使用しないでください。

4. 発見の評価スケール

レベル	特徴	例
重大	大きな金銭/データリスクまたはコア管理の欠陥	重複支払い、誤った人、キーの漏洩
高	多くの人/期間に影響、または調整できない	計算式の誤り、給与のずれ
中	管理はあるが一貫して運用されていない	遅延承認、権限の未レビュー
低	記録/効率の改善が必要	トレーニング証拠の欠如

公式レベルは、金銭、人数、法的義務、修正期限に基づいて設定されるべきです。

5. グループ1 — ガバナンスとポリシー (管理1–5)

1. サービスオーナーが全体の責任を持つ。
2. 給与前払いの規則は有効で、承認権限とバージョン履歴がある。
3. RACIはシステム上の実際の権限と一致している。
4. KPIは労働者に取引を強制しない。
5. リスク、例外、アクションは定期的に報告される。

証拠: 任命決定、規則、権限マトリックス、会議記録、ダッシュボード、リスクログ。

テスト: 3つの役割を選び、文書上の権限と実際の権限を対比する；期限切れのアクションに責任者がいるか確認する。

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. 敏感なパラメータの変更は4つの目で確認され、ログに記録され、変更後にチェックされる。

証拠: ポリシー表、設定、変更ログ、承認、サンプル計算結果。

テスト: 承認された仕事×単価−受け取り済み−リザーブの計算式でサンプルを再計算し、1,000円未満の切り捨てと制限の境界を確認する。

コードのデフォルトは50,000円/回、300万円/命令、500万円/人/日を含む；監査は実際の適用レベルと比較し、これらの数字をポリシーと見なさないでください。

9. グループ5 — 取引の開始と処理 (21–25)

1. サーバーはすべての条件を再確認し、アプリのデータを信じるだけではない。
2. 労働者は各要求の内容を確認する。
3. 各要求には再実行防止のための安定した取引コードがある。
4. 同じ利用可能な数に対する2つの命令を防ぐ同時ロックがある。
5. 有効な応答のみが支払い済みの状態に移行する。

証拠: フローチャート、データを隠したログ、取引コード、自動テスト、コミットメント内容のサンプル。

テスト: ほぼ同時の2つの要求、制限を超えた要求、身分証明書の欠如、未承認の仕事、無効な銀行応答を許可されたテスト環境で試す。

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. データ侵害には検出、評価、通知のプロセスがある。

証拠: ポリシー、処理記録、影響評価、サブプロセッサーリスト、権限ログ、削除証拠、インシデント記録。

テスト: 収集から削除までのデータタイプを選び、3つの内部アカウントを選んで権限を確認し、データエクスポートログを確認する。

現在の法律フレームワークには、2026年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. 推奨データクエリ

• 同じ身分証明書で複数のアクティブアカウント；
• 1つの銀行口座で複数の人；
• 同額/同時刻/同人物の取引；
• 日制限を超える人の合計；
• 未来の日付の仕事が金額を生成；
• 成功した取引後に修正された仕事；
• 成功した取引に明細書がない；
• 内部取引がない支払い明細書；
• 失敗/保留の取引が給与に現れる；
• 退職者が要求を発生させ続ける；
• 変更設定に票がない；
• 長期間活動していない管理者が権限を持つ；
• 異常な時間にログが欠如している。

クエリは誤検知を避けるためにテストされ、データ権限の範囲内で実行されるべきです。

18. 監査発見の書き方

良い発見は5つの部分から成ります：

1. 基準: 規則/契約/管理が何を要求しているか。
2. 現状: 証拠が何を示しているか。
3. 原因: なぜ管理が機能していないのか。
4. 影響: 金銭、人、データ、法的、運用。
5. 推奨: 具体的なアクション、担当者、期限。

悪い例: 「管理を強化する必要があります。」
良い例: 「選ばれた25の制限変更のうち、4つは独立した承認者が欠如しています。システムでの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 · 企業向け給与前払い