SGの内部統制対策｜職務分掌・統制の限界・IT全般統制と業務処理統制を図解

SGシラバスVer.4.1には、職務分掌、内部統制の限界、ITに係る全般統制・業務処理統制などが挙がっています。内部統制を設けて業務を行うことと、その状況を監査で評価することは別です。システム監査の役割を学んだ後は、日々の業務側で何を組み込むかを考えてみましょう。

金融庁の基準が示す基本的枠組みでは、業務の有効性・効率性、報告の信頼性、法令等の遵守、資産の保全が目的として整理されています。報告は財務情報だけに限らない概念ですが、金融商品取引法上の内部統制報告制度の対象と、内部統制の一般的な考え方は混同しません。本記事はSG学習用の基礎説明で、個別企業への法的義務の当てはめは扱いません。

仕組みを継続して管理する学習としてはSGのSLA・サービスレベル管理で、合意・測定・改善の役割を整理できます。内部統制や監査と同じ用語として扱わないようにしましょう。 データ入力を支える制約の具体例はSGの主キー・外部キーと参照整合性で、DBで拒否できる誤りと、業務上の事実確認を分けて学べます。

架空の会社Tで、仕入先情報の登録、登録内容の承認、支払準備を同じ担当者が行えるとします。会社では本来、登録内容を別の担当者が確認してから使うルールですが、システムでは自分の申請も承認できる状態でした。「承認ボタンを押した記録がある」というだけで、求めている相互確認が機能しているとはいえません。

この例では、登録を申請する権限と、その申請を確認・承認する権限を整理します。規程上の役割を分けても、同じ人が両方の認証情報を使えば実効性が損なわれます。画面に二つの担当欄があることと、実際に異なる権限者が内容を確かめることを分けて考えます。

人数が少ない場合も、承認者の不在時に全員で認証情報を共有する、といった方法へ直結させないでください。責任者による確認や処理後の照合など、業務に合った補完策を検討し、できない範囲と残るリスクを明確にします。この例の役割数や手順は当サイトの設定で、全企業への一律の実施方法ではありません。

会社Tの仕入先登録画面に、必須項目の入力確認や、登録内容に応じた承認の仕組みを組み込むことは、その業務の処理に着目した対応です。一方で、その仕組みのプログラムを誰でも無断で変えられたり、運用管理が曖昧だったりすると、入力確認や承認が継続して機能する前提が崩れる可能性があります。

IT全般統制は、業務処理統制が働く環境を支える方針・手続として捉えます。業務処理統制は、個々の業務で承認された内容を漏れなく正確に処理するためのものとして考えます。二つは対立する代替案ではありません。「入力チェックがあるから変更管理は不要」とも、「基盤を管理しているから取引内容の確認は不要」ともいえません。

逆に、変更管理で一つ不備が見つかったというだけで、全取引の記録が必ず誤っていると結論を出すのも飛躍です。どの変更がどの業務処理に影響するか、対象の処理が実際に機能しているかを確認します。不備を小さく見せるのでも、関係を調べず全て無効とするのでもなく、影響する範囲と根拠をたどる姿勢が重要です。検証していない対象は未確認として残します。

金融庁の実施基準には、全般統制の例にも、業務処理統制の例にもアクセスに関する項目があります。したがって、アクセス管理という単語が見えたら必ず全般統制、と機械的に分類しないでください。対象がシステムを支える環境なのか、個々の業務における操作の範囲なのかを見る必要があります。

会社Tで、基盤の管理者がプログラムを変更できる権限を管理する話と、仕入先登録の申請者が自分の申請を承認できないようにする話は、確認する対象が違います。同じアカウントという言葉でも、権限の目的と使われる処理を一行で書けば、名前だけの分類から抜け出せます。

人の判断や確認には誤りがあり、役割を分けても複数人の共謀などで機能が損なわれる場合があります。想定していなかった業務の変化や、不当な指示による無効化も考慮が必要です。限界があることと、統制を整備・運用しなくてよいことは別です。事故を必ずゼロにする約束ではなく、リスクを抑える仕組みとして学びます。

会社Tで承認者が内容を読まずに毎回承認すれば、担当者を分けただけでは十分に機能しません。承認した内容が後から変更されても確認が及ばないなら、承認の後の処理も論点になります。人数やボタンの数を増やすことを目的にせず、何を確かめるための手続かを説明できるようにします。

費用や業務への負担も検討しますが、「対策は高い」という理由だけで、法令や契約の要求までなくなるものではありません。対応し切れない点は責任者へ伝え、リスク対応と残留リスクの考え方につなげます。架空例の補完策を、他社や本番業務で承認なく試すことは避けてください。

会社Tの弱点を復習ノートへ書くなら、「内部統制が弱い」という一文で終わらせません。役割の定義がないのか、定義はあるが設定が違うのか、設定は適切でも人が確認していないのかを分けます。原因が違えば、手順の作成、設定の見直し、教育や運用確認など、検討する対応も変わります。

下表は当サイトの学習用の確認表です。実在の取引情報や個人の認証情報を外部へ提出する指示ではありません。架空の担当名・案件名を使い、必要な根拠と未確認部分を説明する練習に使ってください。

システムの設定変更の手順はセキュリティの変更管理、異動・退職後の権限はアカウント停止と移管へ分けています。本記事の表を、それらの詳細手順を全て代替するものとして扱わないでください。

用語を確認したら、会社Tの条件を一つ変えて考えます。申請者は変わらず承認者だけが異動した場合、どの権限と引継ぎを確認するでしょうか。入力の必須項目は有効でも承認後に内容を変えられる場合、どこに確認が必要でしょうか。これは元の問題の正解を変更するのではなく、適用条件を理解するための独習です。

条件を読む方法は科目Bの読み方、範囲の整理はSGの学習目次へ。無料6問では教材の操作と解説を試せますが、内部統制分野すべての理解度を診断するものではありません。教材の対象範囲と条件はSGの教材・料金で確認できます。