IT業務処理統制（ITAC）とは？情報処理統制との違いと、評価で見るポイントを公認会計士が解説

公開日：

受注・出荷・請求・売上計上の各処理に照合の統制が入り、その土台にIT全般統制がある構造を示したアイキャッチ画像

IT業務処理統制（ITAC）とは、内部統制基準（財務報告に係る内部統制の評価及び監査の基準、およびその実施基準）が、次のように定義している統制です。

ＩＴに係る業務処理統制とは、業務を管理するシステムにおいて、承認された業務が全て正確に処理、記録されることを確保するために業務プロセスに組み込まれたＩＴに係る内部統制である。

売上や仕入といった取引を、システムが正しく処理して記録する。その処理の流れの中に組み込まれた統制、と考えると分かりやすいと思います。

ところが、この統制には呼び名が3つあります。「IT業務処理統制」「ITAC」、そして、日本公認会計士協会の監査基準報告書（監基報）315が使う「情報処理統制」です。同じものなのか、別のものなのか。結論から言うと、ほぼ同じものを指しています。ただし「ほぼ」です。内部統制基準と監基報315とでは、手作業の扱いに少しだけずれがあります。ここを整理しないまま進めると、「どこまでが自社の評価対象なのか」が決まらず、監査法人とのやり取りだけが増えていきます。

この記事では、公認会計士でありシステム監査技術者でもある立場から、内部統制基準と、監基報315の実務ガイダンス（Q&A）という一次資料をもとに、呼び名の整理、具体例、評価の進め方を説明します。「IT業務処理統制と言われても、何をどこまで見ればよいのか分からない」という、経理・内部監査・情報システムの担当者に向けた記事です。

この記事を読んでわかること

  • IT業務処理統制・ITAC・情報処理統制の違いと、同じ部分がわかる
  • 製造業・卸売業の設例から、何を統制と呼ぶのかがわかる
  • AccessやスプレッドシートにまかせたITの計算が、統制の穴になった開示事例がわかる
  • 再実施・SQLの確認・過年度の結果の利用条件など、評価の進め方がわかる

IT業務処理統制（ITAC）とは｜3つの呼び名を整理する

内部統制基準は、IT業務処理統制の具体例として、次の4つを挙げています。

  • 入力情報の完全性、正確性、正当性等を確保する統制
  • 例外処理（エラー）の修正と再処理
  • マスタ・データの維持管理
  • システムの利用に関する認証、操作範囲の限定などアクセスの管理

同じく内部統制基準は、これらの統制は手作業でも実施できるが、システムに組み込むことで、より効率的かつ正確に処理できるようになる、と述べています。

ITAC・IT業務処理統制・情報処理統制の対応表

呼び名 使われる基準・場面 意味
IT業務処理統制（ITに係る業務処理統制）。略称はITAC 内部統制基準。経営者による評価の場面 冒頭に示した定義のとおり
情報処理統制 監基報315。監査人の用語 情報のインテグリティ（取引及びその他の情報の網羅性、正確性、正当性）のリスクに直接対応する内部統制。自動化されたものと、手作業のものがある

内部統制基準と監基報315の違い

なぜ呼び名が2つあるのでしょうか。監基報315の実務ガイダンス（Q&A）は、内部統制基準等が、監基報315の「自動化された情報処理統制」に相当するものを「ITに係る業務処理統制」という用語で説明していると述べ、この2つを「監査実務上はほぼ同義と考えられます」としています。

ずれが出るのは、手作業の扱いです。

監基報315の情報処理統制は、自動化されたもの（ITアプリケーションに組み込まれているもの）と、手作業のもの（たとえば、インプットやアウトプットに係る内部統制）の両方を含みます。手作業のものには、ITに関連しないものも含まれます。一方、内部統制基準は、IT業務処理統制について、「多くは自動化されたもの」だが、一部にITシステムに組み込まれていない手作業のものがある、と説明しています。

したがって、重なりの中心は「自動化されたIT業務処理統制」です。手作業の部分をどこまで含めるかは、内部統制基準の話なのか、監基報315（監査人）の話なのかで、確認する必要があります。

IT全般統制との違い｜土台と、個別の処理

IT業務処理統制と対になるのが、IT全般統制（ITGC）です。内部統制基準は、IT全般統制を次のように定義しています。

ＩＴに係る全般統制とは、業務処理統制が有効に機能する環境を保証するための統制活動を意味しており、通常、複数の業務処理統制に関係する方針と手続をいう。

具体例は、システムの開発・保守に係る管理、システムの運用・管理、内外からのアクセス管理などシステムの安全性の確保、外部委託に関する契約の管理の4つです。

内部統制の中にITへの対応があり、その下にIT全社統制・IT全般統制（土台）・IT業務処理統制（個別の処理）が並ぶ階層図。IT全般統制がIT業務処理統制の環境を支える
図1　IT統制の3種類の関係。IT全般統制は、IT業務処理統制が有効に機能する環境を支える

たとえば、売上を計算するプログラムがあるとします。計算そのものが正しく行われるための仕組みがIT業務処理統制です。そのプログラムが、誰にでも書き換えられたり、テストなしに変更されたりしない状態を保つのがIT全般統制です。計算が正しくても、そのプログラムを自由に書き換えられるなら、結果は信頼できません。

監基報315のQ&Aも、経営者が財務報告で依拠する内部統制が自動化されている程度が高いほど、自動化された情報処理統制の継続的な運用を支えるIT全般統制の重要性が増す、と説明しています。

「全般統制が有効なら、業務処理統制も有効」とは言えない

ここで、見落とされやすい点があります。内部統制基準は、IT全般統制が有効に機能していると評価されたとしても、それだけでIT業務処理統制も有効に機能しているという結論には至らない、という点に留意が必要だと述べています。

IT全般統制は、処理が動く「環境」を保証するものです。個々の処理が、意図したとおりに正確に行われているかは、IT業務処理統制自体を確認しなければ分かりません。

IT全般統制の4つの領域は、IT全般統制とはで、IT全社統制を含めた3種類の全体像は、内部統制とIT統制の違いで整理しています。

ITACの具体例｜6つの種類と、製造業・卸売業の3つの設例

監基報315が示す、自動化された統制の6つの種類

監基報315のQ&Aは、自動化された情報処理統制を、次の6つに分けて説明しています。業務の流れの中で、どの段階で働くかを添えて整理すると、次のようになります。

種類 働く段階 内容と、Q&Aが挙げる具体例
エディット・バリデーション・チェック 入力 入力内容が、予定した様式・内容と一致しているかを確認する。数字を入れるべき欄に文字を入れたらエラーにする、必須項目が空ならエラーにする、仕訳の貸借のバランスを確認する、値の上限・下限を確認する、など
マッチング 入力 入力内容を、あらかじめ登録されたマスター・データと照合する。得意先コードを入力したときに、得意先マスターに登録がないコードならエラーにする
自動計算等 処理 人手を介さずに自動で処理する。金額の自動計算、減価償却費の計上、外貨換算の処理など。結果が会計システムに連携されて、自動で仕訳が作られるものもある
コントロール・トータル・チェック 処理 処理の過程で、受け入れた情報の数値項目の合計を、出力した情報と照合する。入力データの合計額を記録しておき、処理後の合計額と一致しなければエラーリストを出す
レポート出力 出力 帳票を自動で作成する。明細レポート、集計レポート、入力内容をそのまま表示するプルーフ・リスト、エラーの内容を表示するエラーリストなど
アクセス・コントロール 全体 ユーザIDとパスワードなどで、プログラムやデータを利用できる人を制限する。ユーザIDごとに、使える機能を設定する

なお、「働く段階」の列は、Q&Aの分類を、業務の流れに沿って私が並べ替えたものです。

大切なのは、6つの名前を覚えることではありません。一つの業務が、複数の種類の統制の組み合わせで守られていると理解し、「この処理は、どの段階で、何を防いでいるのか」を言えるようにすることです。たとえば、外貨建ての売上を円換算して計上する処理は、入力の段階で必須項目を確認し、処理の段階で自動計算し、エラーが出れば出力の段階でエラーリストに出す、という形で、複数の統制が重なっています。

製造業・卸売業の3つの設例で考える

ここからは、製造業と卸売業を想定した設例で考えます。実在する会社の事例ではありません。3つの設例とも、システムが自動で行う部分と、人が行う部分に分けて見ます。

設例 システムが自動で行うこと 人が行うこと 防ぎたいリスク 情報のインテグリティ
① 製造業：部品の調達 発注書、検収記録、請求書の品目・数量・単価を自動で照合し、不一致の請求書は支払処理を止めて、例外一覧に出力する 例外一覧を確認し、原因を調べて是正する 未検収・数量違い・単価違いの支払い 正確性、正当性
② 卸売業：出荷から売上の計上 出荷登録を受けて、出荷数量と販売単価から売上金額を計算し、売上仕訳を自動で作成する 出荷を正しく登録する。単価を訂正する場合は承認を得る 売上金額の計算誤り、計上漏れ 正確性、網羅性
③ 卸売業：システム間の連携 会計システムに連携された件数と金額を照合し、不一致なら検知してエラー通知を出す エラー通知を受けて、連携漏れを是正する 連携漏れ、二重連携 網羅性

設例① 製造業：部品の調達（発注書・検収記録・請求書の自動照合）

製造業の会社が、部品を発注し、受入の担当者が検収し、仕入先から請求書が届く場面です。システムは、発注書、検収記録、請求書の3つを、品目・数量・単価で自動で突き合わせます。3つが一致すれば、請求書は支払処理に進みます。一致しなければ、その請求書は支払処理を止められ、例外一覧に出力されます。

この統制は、2層になっています。一致を確かめて止める部分は、システムが行います。しかし、止まった請求書の原因を調べ、仕入先や社内に確認して是正するのは人です。Q&Aは、エラーリストのように、ITから自動生成される情報を使って人が是正する統制も、情報処理統制を構成するものと考えられるとしています。

評価では、照合の条件（どの項目を、どの単位で突き合わせているか）が意図どおりか、不一致の請求書が本当に支払処理に進まないか、例外一覧への対応の記録が残っているかを確かめます。2つ目は、意図的に不一致のデータを流して確かめる方法が使えます（後述の「再実施」です）。

設例② 卸売業：出荷登録から売上仕訳を自動で作成する

卸売業の会社で、倉庫の担当者が出荷を登録すると、システムが出荷数量と販売単価から売上金額を計算して、売上仕訳を自動で作成する場面です。

Q&Aは、手作業の入力を基に自動で計上するこの形について、次のような点に留意するとしています。あらかじめ商品がマスター登録されていない商品の売上は、計上できない仕組みになっているか。あらかじめ登録された単価以外の金額で、売上を計上できない仕組みになっているか。単価の訂正が可能な場合は、適切な承認を得て行われているか、その履歴が残っているか。商品マスタは、適切にメンテナンスされ、最新の状態に保たれているか。

見るべきなのは、計算式の正しさだけではありません。計算のもとになるマスタ、そして例外的に単価を変えられる場面まで含めて、1つの統制です。あわせて、出荷の取消や訂正があったときに、売上が正しく修正されるかも確認しておくと安心です。

設例③ 卸売業：システム間の連携を件数と金額で照合する

販売システムから会計システムへ、売上を連携する場面です。仮に、販売システムでは100件・500万円の売上が確定していたのに、会計システムへ連携された売上が99件・495万円だったとします。このとき、システムが件数と金額の不一致を検知して、エラー通知を出す仕組みがあれば、連携漏れを、期末を待たずに見つけられます。

これは、Q&Aが網羅性の例として挙げている、「データ出力側で把握されているデータ件数等と、データ入力側で把握されるデータ件数等が整合していることを確認し、整合しない場合には入力されたデータ処理を中止する」機能にあたります。件数だけでなく金額（合計）も照合しているのは、Q&Aのいうコントロール・トータル・チェックの考え方です。

評価では、Q&Aが示す3つのアプローチが参考になります。送信データと受信データを突き合わせて、誤りなく受信されていることを確かめる方法。トータル・チェック等の、インターフェースの信頼性を担保する統制が有効に機能していることを確かめる方法。転送が異常終了した場合のリカバリー機能など、インターフェース自体の機能が実装されていることを確かめる方法です。

「システムが自動でやっているから大丈夫」は、本当に大丈夫か

月次決算・IPO準備・IT統制の実務知見を、月1回メールでお届けします

無料でメルマガを受け取る

スプレッドシートやAccessは、ITACに入るのか

システムの外で動くスプレッドシートやAccessも、重要な計算を担っていることがあります。監基報315のQ&Aは、これをEUC（エンドユーザー・コンピューティング）として説明しています。

比較的単純なスプレッドシートであれば、手作業による検算や、整合性チェックツールの利用といった補完的な統制で、信頼性を損なうリスクを下げられる場合があります。一方、自動化機能を多用している場合や、処理が複雑でブラックボックス化している場合は、自動化された情報処理統制と同様に、処理の一貫性を保つ統制が求められることがある、とされています。また、スプレッドシートは、仕様書や変更記録の作成、アクセス制限といった、全般的な管理体制を整えにくく、IT全般統制と同等の有効性を確保しにくいことがある、とも説明されています。

私は、AccessやスプレッドシートのようなEUCは、作った人にしか中身が分からない状態（属人化）になりやすく、実務では、かなり怖いツールだと感じています。次の開示事例が、その怖さをよく表しています。

開示事例：Accessで在庫単価を計算していた製造業の会社

ネポン株式会社は、2026年6月30日に、「財務報告に係る内部統制の開示すべき重要な不備及び内部統制報告書の訂正報告書の提出に関するお知らせ」を開示しました。開示によると、内容は次のとおりです。

  • 同社は、標準原価、生産数量、仕入金額、在庫単価の計算に関する基礎データを、すべて基幹システムに保存していました。そして、部品（原材料・仕掛品）在庫の総平均単価は、Accessを使って計算していました。基幹システムのデータを、Access内の「テーブル」へ更新登録し、集計を実行する「クエリ」へ、集計の対象期間を登録する仕組みです。
  • 2026年3月期に、在庫金額の過去の推移に疑義が生じたため、経理部門がAccessによる計算を検証したところ、2019年3月期から、基幹システムのデータがAccessのテーブルへ正しく更新登録されておらず、クエリへの集計対象期間の登録も正しく更新されていないことが分かりました。その結果、棚卸資産が過小に計上されていました。
  • 発生原因として、同社は、リスクの評価が不十分であったため、Accessを使った在庫単価の計算手順と計算結果に関する検証項目が、業務手順書や内部統制の文書に詳細かつ適切に記載されておらず、内部統制監査でも看過されてしまっていたことを挙げています。
  • 同社は、2019年3月期から2025年3月期の内部統制報告書に、開示すべき重要な不備があったとして、公衆縦覧期間にあたる第75期から第78期（2022年3月期から2025年3月期）の内部統制報告書の訂正報告書を提出しました。訂正後の記載は、財務報告に係る内部統制は「有効でない」というものです。財務諸表の監査意見は、無限定適正意見と開示されています。
  • 是正策として、経理部門が、Access内のデータ更新と期間登録、計算結果を検証し、その方法を業務手順書に詳細に記載することとしています。検証の一つは、Accessで算出した単価と、別に計算した理論値との差額を分析する方法です。

この事例の要点は、計算そのものを自動で行うAccessよりも、その入力にあたる「データの更新登録」と「集計期間の登録」が正しいか、結果が正しいかを確かめる検証が、統制として文書化されていなかったことにあります。基幹システムという入口と、財務諸表という出口の間にあるAccessの計算に対する検証が、統制として整理されていなかった、ということです。

自動化された統制と手作業の統制｜「ITAC＝自動」と決めつけない

「ITACは、システムが自動でやる統制のこと」と理解している方は多いと思います。しかし、監基報315のQ&Aは、「情報処理統制＝自動化された内部統制」と短絡的に理解しないように留意することが重要だ、と明記しています。

設例①がまさにその例です。システムが不一致を検知して止める部分は、自動化された統制です。ただし、止まった請求書を確認して是正する部分は、手作業です。Q&Aは、エラーリストを使って人が是正する統制を、自動化された統制と手作業の統制の「組み合わせ」の型として説明しています。インターフェースによるデータの受け渡しが想定どおりに行われなかった場合に、それを是正する内部統制は、重要な虚偽表示を防ぐために重要なものです。手作業であっても、評価の対象になります。

なお、監基報315の情報処理統制には、ITに関連しない手作業のものも含まれます。この記事で扱っているIT統制の話としては、「ITが作った情報（エラーリストなど）を使っているかどうか」が、線引きの目安になります。

自動化された統制を、過信しない

もう1つ、内部統制基準が2023年の改訂で加えた記述があります。自動化されたIT業務処理統制は、一般に、手作業のものより無効化が難しい。しかし、自動化されていても、過信せずに、内部統制の無効化のリスクを完全に防ぐことは難しいという視点を持つことが重要だ、というものです。さらに、電子記録は変更の痕跡が残りにくい場合があり、無効化が起きても発見が遅れることがある、とも述べています。

ネポンの事例も、突き詰めれば、Accessという自動化された計算に依拠していたことが背景にあります。その入力（更新登録、期間登録）が正しいかを確かめる検証が、手順書に載らないまま、誤りが2019年3月期から続いていました。「自動だから安全」ではなく、「自動だから、誤りが広く、長く続き、気づきにくい」と考えるほうが、実態に近いと思います。

ITACの評価方法｜何を、どう確かめるか

内部統制基準は、経営者が、識別したIT業務処理統制が適切に業務プロセスに組み込まれ、運用されているかを評価する、としています。評価の視点として、入力情報の完全性・正確性・正当性が確保されているか、エラーデータの修正と再処理の機能が確保されているか、マスタ・データの正確性が確保されているか、認証・操作範囲の限定など適切なアクセス管理がなされているか、という4つを挙げています。

では、実際にどう確かめるのでしょうか。監基報315のQ&Aは、自動化された情報処理統制の評価手続について、統制が期待される機能を果たしているかについて、合理的な心証を得ることが目的だとしています。必ずしも、プログラムの機能を完全に再現したり、プログラムの手順どおりに評価したりする必要はありません。入力された情報や状況に対して、あらかじめ設定された出力や処理が行われることを確かめることで、検証できる場合があります。

確かめる4つの方法

方法 内容 たとえば
サンプルテスト 依拠しようとする期間の運用結果からサンプルを抽出して確かめる 1つの外貨で、為替レートと外貨建ての売上金額から円建ての売上を再計算し、計上額と一致すれば、他の外貨も同様に正しく計算されると期待できる
再実施 実際に統制を再現して、同じ結果が得られるかを確かめる 権限のないIDで、データやプログラムにアクセスできないことを確かめる。本番環境に疑似データを流して、仕様どおりの結果になることを確かめる
ソース・プログラムのレビュー プログラムのソースコードを読み、正しく動くように書かれているかを確認する 技術的・時間的な制約があるため、必要に応じて実施する
システムクエリー（SQL）のレビュー SQLの内容を読み、正しいテーブルから、正しい条件で、データが抽出・更新される設定かを確認する 計算のロジックを担うSQLを確認する

サンプルテストが成り立つのは、自動化された統制の性質によります。プログラムの整備状況が適切で、処理のパターンが同じなら、抽出したサンプル以外も同様の信頼性が期待されるからです。ただし、この前提は「処理のパターンが同じ」場合に限られます。条件によって処理の流れが分かれるような統制では、パターンごとに確認が必要になると考えられます。

実際の確認の場面を考えてみます。

  • 計算のロジックを担うSQLがある場合に、SQLを読むだけでなく、実際にそのSQLでデータを出力してもらい、期待どおりの計算結果になっているかを確かめる。
  • 決済が、実際にシステム上に反映されているかを、ユーザーとしてシステムを操作して確かめる。
  • POSシステムに入力した売上が、売上データに反映されているかを確かめる。

1つ目はSQLのレビューに、あとの2つは再実施に、それぞれ位置づけられます。内容を「読む」だけでなく、「動かして確かめる」ことで、統制が意図どおりに機能している確からしさが高まります。

なお、期中にこれらの手続を実施した場合でも、その後プログラムが変更されていないことを、変更履歴などで確認できるIT全般統制があれば、期末に再び同じ手続を行う必要はなくなります。手続を本番環境以外で実施した場合は、本番環境と同じ動きになるという心証を得るために、環境の同一性を、プログラムのバージョンの比較などで確かめます。

データが簡単に変えられないか

もう1つ、見落とされやすい点があります。統制のプログラムが正しく機能していても、処理結果を記録したデータが簡単に変更できる状態では、十分な信頼性は得られません。Q&Aは、データが適切なアクセス・コントロールのもとで運用されていることを確かめる、としています。ここでも、ITACとIT全般統制（アクセス管理）は、つながっています。

過年度の評価結果を使える条件

自動化された統制は、一度設定されると、変更やエラーが発生しない限り、一貫して機能するという性質があります。内部統制基準は、この性質を踏まえ、次の3つを確認・評価できた場合に、過年度の評価結果を記録したうえで、継続して利用できるとしています。

  • 評価された時点から、統制が変更されていないこと
  • 障害・エラー等の不具合が発生していないこと
  • 関連する全般統制の整備・運用の状況を評価した結果、全般統制が有効に機能していると判断できること

注として、一定の複数会計期間に一度の頻度で、運用状況のテストを実施する方法も含まれる、とされています。ただし、この取扱いは、IT環境の変化を踏まえて慎重に判断し、必要に応じて監査人と協議して行うべきものであり、特定の年数を機械的に当てはめてはならない、と明記されています。

ここで注意したいのは、「IT全般統制が有効なら、IT業務処理統制の評価は要らない」という意味ではないことです。IT業務処理統制を含むIT利用の内部統制の評価は、原則として毎期実施する必要があります。過年度の結果を使えるのは、上の3つの条件を満たした場合です。

実務上の注意点｜「システムが自動でやっている」の先にあるもの

ここまでの内容を踏まえて、実務でつまずきやすい点を2つ挙げます。

マスタが誤っていれば、正しい計算も誤った結果になる

設例②で見たとおり、売上金額の計算が正しく行われるのは、計算のもとになる商品マスタの単価が正しいことが前提です。計算式は正しいのに、マスタの単価が古いままであれば、売上金額は、システムが自動で、誤った金額に計算します。誰も手を動かしていないので、気づきにくいのも問題です。

内部統制基準が、IT業務処理統制の例として「マスタ・データの維持管理」を挙げているのは、このためだと考えられます。計算のロジックに加えて、マスタを誰が、どんな承認で更新できるのかまで確認しないと、統制の全体像は見えません。

例外一覧が出ることと、是正されることは別

設例①のように、不一致の請求書が例外一覧に出力される仕組みがあっても、それだけでは統制が運用されているとは言えないと、私は考えています。一覧を、誰が、いつ確認して、どう是正したのかという記録が残っていなければ、「一覧が出ている」ことは示せても、「不一致が解消されている」ことは示せないからです。

この場合、支払処理が止まった請求書が、確認されないまま放置されることも起こり得ます。統制が作る例外を受け止める側の運用まで、あらかじめ設計しておく必要があります。

よくある質問（FAQ）

Q1. ITACとIT業務処理統制は、違うものですか？

同じものです。ITACは、IT業務処理統制（ITに係る業務処理統制）を指す略称として、実務で使われています。

Q2. 業務処理統制と情報処理統制は、同じですか？

監査実務上はほぼ同義とされています。内部統制基準は「ITに係る業務処理統制」、監基報315は「情報処理統制」という用語を使っており、内部統制基準等の「ITに係る業務処理統制」は、監基報315の「自動化された情報処理統制」に相当します。ただし、情報処理統制は、手作業のものも含む点で、範囲が少し広くなります。

Q3. IT全般統制とIT業務処理統制の違いは何ですか？

IT全般統制は、業務処理統制が有効に機能する「環境」を保証する統制です。IT業務処理統制は、業務プロセスに組み込まれ、承認された取引が正確に処理・記録されることを確保する統制です。IT全般統制が有効でも、それだけでIT業務処理統制が有効とは言えません。

Q4. IT全般統制が有効なら、業務処理統制の評価は省略できますか？

省略できるわけではありません。IT利用の内部統制の評価は、原則として毎期実施します。統制が変更されていない、障害・エラーが発生していない、関連する全般統制が有効と判断できる、という条件を満たした場合に限り、過年度の評価結果を継続して利用できます。

Q5. 手作業の統制も、ITACに含まれますか？

内部統制基準は、IT業務処理統制の多くは自動化されたものだが、一部、システムに組み込まれていない手作業のものも存在する、としています。また、監基報315のQ&Aは、ITが自動生成する情報（エラーリストなど）を使って行う手作業の統制も、情報処理統制を構成すると考えられる、としています。

まとめ｜呼び名が違っても、見るのは1点

IT業務処理統制、ITAC、情報処理統制。呼び名は違っても、見ているのは、自動で処理される統制が、意図したとおりに正確に処理・記録されているかという、1点です。

呼び名の違いに迷ったら、次の順で整理してください。内部統制基準の話なら「IT業務処理統制」、監査人（監基報315）の話なら「情報処理統制」であり、自動化された部分は両者が重なります。手作業の部分を含めるかどうかは、どちらの話かで確認する。このほうが、資料や打ち合わせの言葉の違いに振り回されずに済みます。

評価の面では、次の3点が大切です。統制の計算式だけでなく、もとになるマスタ、そして例外を受け止める運用まで含めて1つの統制と捉えること。SQLを読むだけでなく、実際に動かして確かめること。AccessやスプレッドシートのようなEUCに載った計算を、見落とさないこと。

明日からできる最初の一歩として、自社の基幹システムを1つ選び、「入力」「エラー処理」「マスタ」「アクセス」の4つの視点で、システムが自動で行っていることを書き出してみてください。あわせて、そのシステムの外で、AccessやスプレッドシートがITの計算を担っていないかも、確認してみてください。何を統制と呼ぶかが、具体的に見えてきます。書き出す際は、IT全般統制チェックリストもあわせて使うと、全般統制側の確認漏れを防げます。

IT統制の構築・評価をご検討の方へ

どのシステムのどの統制を評価対象にするか、監査対応をどこから整理すべきかなど、公認会計士・システム監査技術者の立場からご相談を承ります。

無料相談・お問い合わせ

関連記事

参考資料

おすすめ記事

一覧へ