IT統制の監査をしていると、毎回同じ場所に穴があります。
業種が違っても、規模が違っても、使っているシステムが違っても、指摘されるポイントはほぼ決まっています。10社見れば8社で同じ不備が出る。それくらいパターンが繰り返されるのです。
このリストは、IT監査・内部統制評価の現場で見てきた不備を、発生頻度と対応のしやすさを踏まえてまとめたものです。心当たりがある項目があれば、早めに手を打っていただければと思います。
この記事を読んでわかること
- 監査で繰り返し指摘されるIT統制不備トップ10
- それぞれの不備が発生する原因と、監査上問題になる理由
- 不備を改善するために最低限実施すべき対策
- 限られた人員でも進められる、対応の優先順位と3つのフェーズ
なぜIT統制の不備はパターン化するのか
会社のビジネスモデルや使っているシステムは、会社ごとに千差万別です。しかし、IT統制の不備が起きる根本原因は、だいたい3つに絞られます。
「誰がやるか」が決まっていない——ルールはあるものの、担当者が曖昧で誰も実行していないケース。システムが先行して管理が追いついていない——開発スピードが速いスタートアップに多いパターンです。証跡を残す習慣がない——作業自体はしているのに、記録が残らないケースもあります。
この構造を念頭に置いてリストを見ると、「うちも同じ構造かもしれない」と気づきやすくなります。
不備トップ10
順位は「発生頻度」だけでなく「発生した場合の影響度」もかけあわせて並べています。よくある不備でも影響が軽ければ順位は下がりますし、頻度が低くても影響が大きければ上位に来ます。
第1位：アカウント棚卸をしていない（または証跡がない）
発生頻度：★★★★★／影響度：★★★★☆
「誰がどのシステムにどんな権限でアクセスできるか」を定期的に確認していない状態です。アカウントが増える一方で、「本当に必要な権限か」の見直しがされていないケースが目立ちます。
よく見るのは、異動や兼務で役割が変わっても、権限が追加されるだけで削除されないパターンです。棚卸自体はしているものの、「やった」という記録が残っていないケースも少なくありません。記録がなければ、監査人にとっては「やっていない」のと同じ扱いになってしまいます。
対策：年1回以上の定期棚卸と、その実施記録(誰がいつ確認したかのExcelログ)を残しておきましょう。
第2位：退職者のアカウントが削除されていない
発生頻度：★★★★☆／影響度：★★★★☆
退職した社員、あるいは業務委託が終わった外部スタッフのアカウントが、システムに残り続けている状態です。人事が退職情報を情シスに連絡するルートがない、連絡ルートはあるが機能していない、クラウドSaaSのアカウントは把握すら漏れている——このどれかが原因になっていることがほとんどです。
なぜ問題か：退職者がシステムにアクセスできる状態が続いてしまいます。意図的であっても無意識であっても、財務データへの不正アクセスリスクになる点は変わりません。
対策：退職・契約終了の当日、または翌営業日までにアカウントを無効化するフローを、人事と情シスの間で明文化しましょう。フローチャートと実施記録もあわせて用意しておきます。
第3位：本番環境に直接アクセスして変更できる人が複数いる
発生頻度：★★★☆☆／影響度：★★★★★
本番データベースやサーバーに、権限を持つエンジニアが多すぎる状態です。「緊急時のため」という名目で特権IDが複数人に付与されたまま放置されているケースをよく見ます。
承認プロセスを経ずにデータを書き換えられる状態では、財務データの正確性を担保できません。意図的な改ざんだけでなく、ミスによるデータ破壊のリスクも抱えることになります。
対策：本番環境の変更権限は最小限の人数に絞りましょう。特権IDの利用は、申請・承認・ログ取得を必須にします。
第4位：変更管理が「なんとなく」で動いている
発生頻度：★★★☆☆／影響度：★★★★★
コードの変更プロセスが文書化されていない、あるいは文書はあっても実態と乖離している状態です。GitHubのPRをとりあえず使ってはいるものの、レビューが形骸化していることも多く見られます。
「急ぎの修正」として直接本番にデプロイすることが常態化していたり、PRのレビュアーが実質ゼロで自己承認になっていたりするケースもあります。プログラム変更のプロセスに牽制が効いていないと、不正なコード変更を防ぐ仕組みそのものがなくなってしまいます。
対策：GitHubのブランチ保護設定で「PR承認なしのmainへの直接pushを禁止」しましょう。緊急対応についても、事後に記録を残すルールにしておきます。
第5位：開発環境と本番環境が分離されていない
発生頻度：★★★☆☆／影響度：★★★★★
テストと本番が同じ環境で動いている、あるいは開発者が本番データを使ってテストしている状態です。スタートアップの初期フェーズによく見られます。
対策：開発・ステージング・本番の環境分離を行いましょう。本番データを開発環境に持ち込む場合は、マスキング処理を施します。
第6位：操作マニュアルが存在しない・古すぎる
発生頻度：★★★★★／影響度：★★★☆☆
システム操作のマニュアルがなく、業務が特定の担当者の記憶に依存している状態です。マニュアルがあっても、最終更新が数年前で現状と乖離していることも珍しくありません。
対策：少なくとも財務データに影響する操作については、スクリーンショットつきのマニュアルを整備・更新しておきましょう。
第7位：バッチ処理のエラーが誰にも通知されない
発生頻度：★★★☆☆／影響度：★★★★☆
売上データの夜間集計、請求データの連携など、定期的に動くバッチ処理が失敗しても、誰も気づかない状態です。財務計上に使うデータが欠損していても発見が遅れ、月次締め後に発覚すると修正コストが一気に跳ね上がります。
対策：AWSのCloudWatchアラートやSlack通知など、エラー時の自動通知設定を入れておきましょう。バッチの実行ログを定期確認するルールと、その記録もあわせて残します。
第8位：外部委託先の評価・選定基準が定められていない
発生頻度：★★★★☆／影響度：★★★☆☆
SaaSベンダーや業務委託先を選ぶとき、価格や過去の付き合いだけで決めていて、セキュリティやデータの取り扱いを評価する基準を持っていない状態です。契約更新のタイミングでも、同じ基準で見直されることはほとんどありません。
なぜ問題か：基準がないと、誰が選んでも「なんとなく良さそうだから」で契約が決まってしまいます。財務データや顧客データを扱う委託先であっても、セキュリティ体制を誰も確認しないまま契約が進むことになります。
対策：データの重要度に応じて、委託先に確認すべき項目(セキュリティ認証の有無、データの保管場所、契約終了時の返却・削除の取り扱いなど)をチェックリスト化しておきましょう。新規契約だけでなく、更新のタイミングでも同じ基準で見直します。
第9位：IT統制運用が特定の1人に依存している（属人化）
発生頻度：★★★★☆／影響度：★★★☆☆
IT統制の運用——申請の受付、承認、実際の作業——が、実質的に情シス担当者や経営者一人に集中している状態です。中小企業やスタートアップでは、人員の制約からある程度は仕方ない面もあります。
なぜ問題か：ただ、承認する人と実際にシステムを操作する人が同じだと、そもそも牽制という仕組みが成り立ちません。その人が意図的であっても、うっかりであっても、不正な変更が起きたときに誰も気づけない構造になってしまいます。
対策：完全に人を分けるのが難しい規模でも、最低限「実施記録を月次で別の人がレビューする」といった事後チェックの仕組みだけは入れておきましょう。承認者と実施者を分けられなくても、確認する人は分けられます。
第10位：二段階認証・VPNが設定されていない
発生頻度：★★★★☆／影響度：★★☆☆☆
重要システムへのログインに二段階認証が設定されていない、あるいはリモートアクセス時のVPNが整備されていない状態です。パスワードだけでは認証の強度が低く、財務システムやクラウドインフラへの不正ログインは、データ改ざんに直結しかねません。
対策：財務システム・会計クラウド・GitHubなど、主要ツールへの二段階認証を必須化しましょう。ここは比較的すぐに対処できる部分です。
ぶっちゃけ、優先順位はこうです
10個全部をいっぺんに直そうとすると、かえって動けなくなります。段階に分けて着手することをおすすめします。
フェーズ1（今すぐできる）
- 第2位：退職者アカウントの棚卸・削除
- 第4位：GitHubのブランチ保護設定
- 第10位：二段階認証の設定
フェーズ2（ルール・フローの整備）
- 第1位：アカウント棚卸ルールの策定
- 第3位：本番環境の権限者リスト整理
- 第7位：バッチエラーの通知設定
- 第9位：属人化の事後チェック導入
フェーズ3（文書化・継続運用）
- 第5位：環境分離の実施
- 第6位：マニュアル整備
- 第8位：委託先の評価・選定基準の策定
IT統制が100点の会社は、ほとんどありません。大事なのは、「穴がどこにあるか把握できているか」どうかです。
まとめ
- 監査で指摘されるIT統制不備には、パターンがあります
- 最多は「退職者アカウントの削除漏れ」と「アカウント棚卸未実施」です
- 次いで「本番環境の権限管理」「変更管理の形骸化」が多く見られます
- まずはフェーズ1(今すぐできること)から着手するのが現実的です
- 穴を全部塞ごうとするより、「穴がどこにあるか把握している」状態を目指しましょう
関連記事
- IT統制がわかりにくい本当の理由｜会計担当者とエンジニアの「すれ違い」を解説
- アカウント棚卸のやり方｜監査に通るExcel必須7項目と証跡付き手順
- GitHubを使った変更管理の完全ガイド｜Pull Requestが監査の証跡になる仕組み
- 入社・退社時のアカウント付与・削除フロー｜証跡設計のフローチャートつき解説
- SOCレポートの読み方｜委託先選定でISMS・SOC1・SOC2をどう使うか
参考資料
- 「財務報告に係る内部統制の評価及び監査の基準」（金融庁・企業会計審議会）
- 「財務報告に係る内部統制の評価及び監査に関する実施基準」（金融庁・企業会計審議会）
- 「監査基準委員会報告書315（改訂）」（日本公認会計士協会）
- 「システム管理基準」（経済産業省）
