監査対応などで、監査法人から「システム管理台帳を見せてください」と言われることがあります。ところが、社内にそれにあたる資料が見当たらない。IT全般統制の準備を始めると、こうした場面に出会います。
IT全般統制でいうシステム管理台帳とは、使っているシステムを洗い出し、その中から財務報告に関わるシステムを選んで、IT全般統制の対象範囲を決めるための一覧になります。これはすべてのシステムを載せることが目的ではなく、「財務報告に関わるか」と「IT基盤・管理部門」の2つの軸で整理することがポイントです。
この記事では、システム監査技術者であり公認会計士でもある筆者が、内部統制基準を根拠に台帳の考え方、書く項目、作り方の4ステップ、漏れやすいポイントを解説します。記事の最後に、そのまま使えるExcelのテンプレートも配布しています。
この記事を読んでわかること
- システム管理台帳とは何か、なぜIT全般統制で求められるのか
- 台帳の単位となる「IT基盤」と「評価単位」の考え方
- 台帳に書く項目と、作り方の4ステップ
- 台帳を作るときに漏れやすい3つのポイントと、Excelテンプレート
システム管理台帳とは：IT全般統制で求められる理由
まず、システム管理台帳が何のための資料なのかを整理します。
IT全般統制の対象範囲を決めるための一覧
システム管理台帳は、会社で使っているシステムを一覧にして、そのうちどれが財務報告に関わり、IT全般統制の評価対象になるのかを判断するための資料です。監査の準備では、利用しているシステムが分かる資料として提出を求められることがあります。
なぜ、この一覧が必要なのでしょうか。「財務報告に係る内部統制の評価及び監査に関する実施基準」では、次のように定義しています。
ITに係る全般統制とは、業務処理統制が有効に機能する環境を保証するための統制活動を意味しており、通常、複数の業務処理統制に関係する方針と手続をいう。
具体例として、次の4つが挙げられています。これが、IT全般統制の4つの領域です。
- システムの開発、保守に係る管理（変更管理）
- システムの運用・管理（運用管理）
- 内外からのアクセス管理などシステムの安全性の確保（アクセス管理）
- 外部委託に関する契約の管理（外部委託管理）
4つの領域の全体像は、IT全般統制（ITGC）とはで解説しています。ツールごとの見られ方は、IT全般統制の監査で見られるツールにまとめています。
この4つの領域を評価するには、その前に「どのシステムを評価するのか」が決まっている必要があります。対象が決まっていなければ、評価そのものを始められません。その対象を決めるために使うのが、システム管理台帳です。
全システムを載せる必要はない
よくある誤解ですが、IT全般統制の対象は、会社のすべてのシステムではありません。金融庁の実施基準は、ITの統制について、次のように書いています。
金融商品取引法による内部統制報告制度においては、ITの統制についても、財務報告の信頼性を確保するために整備するものであり、財務報告の信頼性以外の他の目的を達成するためのITの統制の整備及び運用を直接的に求めるものではない。
つまり、重点的に見られるのは、財務報告の信頼性に関わる範囲です。社内チャットや社内向けの情報共有ツールのように、財務報告に関わらないものは原則として対象外になります。だからこそ、台帳では「対象」と「対象外」を仕分けして、その理由を残すことが重要になります。
PCやソフトウェアの資産管理台帳とは別物
Google等で検索すると、「システム管理台帳」という名前で、PCやソフトウェアのライセンスを管理する資産管理台帳が多く出てきます。これは、機器やライセンスを管理することが目的の台帳です。一方、IT全般統制のシステム管理台帳は、財務報告に関わるシステムを洗い出し、範囲を決めることが目的です。
台帳の単位は「IT基盤」と「評価単位」
台帳を作るときに最初に迷うのが、「システム1つを1行にすればよいのか」「まとめて書いてよいのか」という点です。この答えも、内部統制基準にあります。
IT全般統制は、IT基盤を単位に構築する
実施基準において、IT全般統制を構築する単位を次のように説明しています。
ITに係る全般統制は、通常、業務を管理するシステムを支援するIT基盤（ハードウェア、ソフトウェア、ネットワーク等）を単位として構築することになる。
基準の例を用いて説明すると、購買・販売・流通の3つの業務管理システムが1つのホスト・コンピュータで管理され、同じIT基盤の上で動いている場合は、そのIT基盤に対して有効な全般統制を構築すれば、3つの業務の情報の信頼性を高められるとされています。
一方、3つのシステムがそれぞれ別のIT基盤の上で動いている場合は、基盤を管理する部門や運用方法が異なることが考えられるため、基盤ごとに全般統制を構築する必要がある、とされています。
評価は「評価単位」ごとに行う
評価のときは、IT基盤の概要をもとに、「評価単位」を識別します。
基準の例では、自社開発の販売・購買・物流のシステムをシステム部が管理し、会計システムは経理部が市販のパッケージを導入して管理している場合、評価単位を「システム部」と「経理部」の2つとして識別する、とされています。これを図にすると、次のようになります。
注意したいのは、IT全般統制はIT基盤（評価単位）ごとに行う一方で、業務処理統制の評価は、基本的に個々のシステムごとに行うことです。そのため、台帳には、システムごとの行に加えて、「IT基盤」と「管理部門（評価単位）」の項目が必要になります。同じ基盤・同じ部門のシステムを、あとでまとめて評価できるようにするためです。
なお、クラウドサービス（SaaS）の場合、IT基盤は提供会社が管理しています。この場合は、提供会社の統制が有効かどうかをSOC1レポートなどで確認することになります。詳しくは、SOC1レポートとはで解説しています。
ただし、実施基準の例は、部署と基盤がたまたま一致しているケースです。システム部は自社開発のシステムを、経理部は市販のパッケージを、それぞれ管理しています。そのため、部署で束ねても基盤で束ねても、同じ結果になります。
実は、「評価単位」の考え方は、基準によって少しずつ違います。金融庁の実施基準、経済産業省の「システム管理基準 追補版（財務報告に係るIT統制ガイダンス）」、日本公認会計士協会の監査基準報告書315を比べると、次のようになります。
| 実施基準（金融庁） | システム管理基準 追補版（経済産業省） | 監査基準報告書315（日本公認会計士協会） | |
|---|---|---|---|
| 誰の立場の基準か | 経営者による評価 | 経営者による評価の実務指針 | 監査人によるリスク評価 |
| 「評価単位」という言葉 | あり。IT基盤の概要をもとに識別する | あり。部署名、ITアプリケーション名が利用されることが多い | なし |
| 単位の例 | 「システム部」「経理部」（部署） | 部署名、またはITアプリケーション名 | ITアプリケーションと、それを支えるデータベース・OS・ネットワーク |
| IT基盤の定義 | 明確な定義はない（「ハードウェア、ソフトウェア、ネットワーク等」と例示） | 「ITに関与する組織の構成、ITに関する規程及び手順書等、ハードウェアの構成、ソフトウェアの構成、ネットワークの構成、関連する外部委託」と解釈する | 「ITインフラストラクチャー」として、ネットワーク、OS、データベースと、関連するハードウェア・ソフトウェアを挙げる |
| 範囲の決め方 | IT基盤の概要をもとに、評価単位を識別する | 業務処理統制が識別され、ITの利用から生じるリスクの影響を受けるアプリケーションを、評価対象とする | 内部統制 → 影響を受けるITアプリケーション → 関連するIT環境 → IT全般統制の順に識別する |
出典：金融庁「財務報告に係る内部統制の評価及び監査に関する実施基準」（令和5年4月7日改訂）、経済産業省「システム管理基準 追補版（財務報告に係るIT統制ガイダンス）」（令和6年12月25日）、日本公認会計士協会「監査基準報告書315 重要な虚偽表示リスクの識別と評価」をもとに筆者作成
追補版は、実施基準が「IT基盤」を明確に定義していないことを指摘したうえで、IT基盤に「組織の構成」まで含めて解釈しています。この解釈をとれば、部署を評価単位にしても矛盾しません。そのうえで、評価単位について次のように書いています。
評価単位は、部署名、ITアプリケーション名が利用されることが多い。
一方、監査人は、部署から範囲を考えるわけではありません。監査基準報告書315は、まず統制に関係するITアプリケーションを特定し、そのアプリケーションを支えるデータベースやOS、ネットワークへと範囲を広げていきます。追補版も、業務処理統制が識別され、ITの利用から生じるリスクの影響を受けるアプリケーションを評価対象にする、としています。
台帳に書く項目：17項目の考え方
台帳には何を書けばよいのでしょうか。ここでは、記事の最後で配布するテンプレートの17項目を例に、それぞれ何のために書くのかを説明します。項目は、監査人が最初に確認する「どんなシステムか」と、IT全般統制の4つの領域の現状に絞っています。
経済産業省の追補版には、本番環境への移送手段やユーザーIDの数、OS・データベース、他のシステムとの連携データまで尋ねる「IT基盤質問書」の例があります。このテンプレートでは、そのうち、対象範囲を決めるのに要る項目と、自社でシステムに手を入れられるか（アドオン・自社修正の可否）だけを残しています。
| 区分 | 項目 | 何のために書くか |
|---|---|---|
| ソフトウェア | ITアプリケーション名、主な用途、種別、開発元・提供元、製品名・バージョン、アドオン・カスタマイズ、自社修正の可否、IT基盤（サーバー・DB） | どんなシステムか。種別（自社開発・パッケージ・SaaS・ノーコード・スプレッドシートなど）と、自社で修正できるかによって、主に見られる領域が変わります。IT基盤は、同じ基盤のシステムをまとめるために書きます |
| 財務報告との関連 | 関連する業務・勘定科目、ITGC評価対象 | 財務報告に関わるか。対象か対象外か。ここが台帳の中心です |
| 管理部門・ユーザー | 管理部門（評価単位）、ユーザー部門／ユーザー数 | 評価単位をまとめるため |
| ① 変更管理 | 変更の実施者 | システムを誰が変更できるか（自社か、提供元のみか） |
| ② 運用管理 | バックアップ | データが保全される仕組みがあるか |
| ③ アクセス管理 | アクセス権の一覧（別紙の台帳の有無） | ユーザーと権限の一覧が、別に管理されているか |
| ④ 外部委託管理 | SOC1報告書 | 委託先やSaaSの統制を、報告書で確認できるか |
| 備考 | 備考・確認事項 | 対象／対象外にした理由と、まだ確認できていないこと・確認先を残します |
ポイントは、ユーザーや権限の一覧を台帳に入れないことです。ユーザーごとの権限は別紙のアクセス管理台帳で管理し、システム管理台帳には、その台帳があるかどうかだけを記録します。アカウント管理の進め方は、アカウント棚卸とはで解説しています。
実際の台帳は、次のような見た目になります（4システムの例です）。
| システム名 | 種別 | 評価対象 | 管理部門 | 変更の実施者 | SOC1 | 備考 |
|---|---|---|---|---|---|---|
| 会計システム | SaaS | 対象 | 経理部 | 提供元のみ | 未入手 | SOC1は提供元に問い合わせ中 |
| 販売管理システム | 自社開発 | 対象 | システム部 | 外注先が本番に反映 | N/A | 承認の記録が残っているか確認 |
| 原価計算Excel | スプレッドシート | 未判定 | 製造部 | 作成者本人のみ | N/A | 直せるのが1名だけ。対象にするなら変更管理のルールから |
| 受注管理アプリ（kintone） | ノーコード | 未判定 | 不明 | 営業部の担当者 | 不明 | システム部の台帳に載っていなかった。売上の根拠に使っているか確認 |
表は、テンプレートの一部の列を抜き出した、架空の例です。
作り方の4ステップ
台帳は次の4ステップで作ります。順番どおりに進めれば、判断に迷う場面が減ります。
| STEP1使っているシステムをすべて書き出す | → | STEP2財務報告との関連を書く | → | STEP3評価対象を判定し、理由を残す | → | STEP4対象システムの4領域を埋める |
STEP1：使っているシステムをすべて書き出す
最初は絞り込みを考えずに、使っているシステムをすべて書き出します。経理と情報システム部門が把握しているものだけでなく、各部門にも確認してください。PCやソフトウェアの資産管理台帳がある場合は、洗い出しの材料になります。経費精算やカードの明細から、契約中のサービスを拾う方法もあります。
STEP2：財務報告との関連を書く
次に、各システムがどの業務・勘定科目に関わるのかを書きます。金融庁の実施基準は、経営者がやるべきこととして、次のように述べています。
経営者は、財務諸表の勘定科目と取引、業務プロセス及びシステムとの関係を理解し、主要な取引等について、どの会計データがどのシステムに依存しているのかを把握する必要がある。
つまり、台帳の「関連する業務・勘定科目」の欄は、「どの会計データがどのシステムに依存しているか」を書く欄です。「売上」「売掛金」のように勘定科目まで書いておくと、対象かどうかを判断しやすくなります。
STEP3：評価対象を判定し、理由を残す
財務報告への関連をもとに、評価対象（対象・対象外・未判定）を決めます。ここで大切なのは、対象外にしたシステムにも理由を残すことです。理由がないと、「なぜ、このシステムは対象外なのですか」と聞かれたときに説明できなくなります。判断に迷うものは無理に決めず、「未判定」として残し、確認事項を備考に書いておきます。
STEP4：対象システムの4領域を埋める
対象と判定したシステムについて、変更管理・運用管理・アクセス管理・外部委託管理の欄を埋めます。「不明」や空欄のまま残さず、確認してください。確認するときは、自己点検用のIT全般統制チェックリストから始めると進めやすくなります。
台帳を作るときに漏れやすい3つのポイント
台帳は、作るだけなら難しくありません。難しいのは、漏れなく作ることです。筆者の実務でも、次の3つは特に漏れやすいと感じています。
現場が勝手に契約したサービス
経理や情報システム部門が把握していないサービスを、現場の担当者が契約して使っていることがあります。こうしたサービスに請求や経費、売上に関わるデータが入っていると、財務報告に関わるシステムに該当します。
現場が勝手に契約したサービスが台帳に載っていないと、対象かどうかの判断もされないまま、監査で指摘を受けることになります。
対策は、洗い出しを経理と情報システム部門だけで完結させないことです。各部門に、使っているサービスを確認する場を作ってください。また、これらはアカウント管理でも同じ問題が起きます。この点は、別記事のアカウント棚卸とはでも触れています。
スプレッドシートやノーコードで作られた集計
システムと呼ばれないために台帳から漏れやすいのが、スプレッドシートやノーコードツールで作られた仕組みです。こうした仕組みは、数式やマクロ、設定を業務部門の担当者が直接変更できるうえに、変更の履歴や承認が通常の開発プロセスの外にあることが多くあります。財務報告の計算に使われていれば、評価対象になりえます。
まずは台帳に載せて、「変更の実施者」の欄で、誰がどう変更できるかを確認します。統制が取れているかどうかは、実際に確認しないと分かりません。確認の観点は、IT全般統制の監査で見られるツールの「ノーコードツールで『統制は取れている』と言われたとき」にまとめています。
評価範囲の対象外にした理由が残っていない
3つ目は、そのシステムを評価範囲の対象外にした理由が残っていないことです。システムを洗い出して対象・対象外を分けた時点では、担当者の頭の中に理由があります。しかし、時間が経って担当者が変われば、なぜ対象外にしたのかを誰も説明できなくなります。
そうなると、証跡としての効果が薄れてしまうので、当時の判断理由を文章で残しておきましょう。この記録があるだけで、説明可能性が大きく上がります。
IT全般統制の対象範囲を決めたい方へ
どのシステムを対象にするか、どこまで整備すればよいかは、会社の状況によって変わります。IPO準備や上場企業の内部統制の現場で、IT全般統制の構築とシステム監査のご相談を承っています。
まとめ：テンプレートのダウンロード
システム管理台帳は、使っているシステムを洗い出して財務報告に関わるものを選び、IT全般統制の対象範囲を決めるための一覧です。内部統制基準では、IT全般統制はIT基盤を単位に構築し、評価は評価単位ごとに行います。そのため、台帳には「財務報告との関連」と「IT基盤・管理部門」の項目が欠かせません。
作り方は4つのステップです。使っているシステムをすべて書き出し、財務報告との関連を書き、評価対象を判定して理由を残し、対象のシステムの4領域を埋めます。漏れやすいのは、現場が契約したサービス、スプレッドシートやノーコード、対象外にした理由の3つです。
この記事で使った台帳のテンプレート（17項目）と、監査人に出す資料の棚卸に使える資料一覧を、Excelにまとめました。台帳は骨格だけを載せています。対象範囲の判断や評価の進め方は会社の状況によって変わるため、個別にご相談ください。
関連記事
資料をダウンロードする
