日本公認会計士協会のIPO事前準備ガイドブックは、初めてショートレビューや会計監査を受ける会社にありがちな指摘の1つに「情報システムの内部統制」を挙げています。例示のケースに出てくるのは、システムの方針がない、プログラムの更新を担当者に任せきりにしている、ログインIDを部署で1つ共有していて誰が直したか分からない、無料のクラウドや外部の業者のサーバーにデータを置いている、という状態です。指摘は、IT全社統制(ITの方針や管理のルールなど会社全体の取り組み)と、IT全般統制(システムが正しく動き続けるように共通して行う管理)のどちらに当たるかで読めます。IT全般統制はさらに4つの領域に分かれます。担当者はショートレビューを受ける前に、設定やプログラムの変更とIDの発行について申請と承認の手順書を1枚と、システムの一覧・IDと権限の一覧・変更の記録・委託先の資料をそろえておきます。
この記事の要約

架空のA社(社員30人、経理2人、3月決算)は、会計はfreee会計のアドバンスプランで、経費精算と請求書の受け取りはバクラクで回しています。来月、監査法人のショートレビューを受けることになりました。CFOから「ITのところで何を聞かれるか、先に準備しておいて」と頼まれたのは、情報システムと経理の両方を見ている担当者です。
ショートレビューは上場までの課題を洗い出す調査で、ITも対象になりうる
CFOが決めることは、ショートレビューを誰に頼むかと、調査の範囲にITを入れるかの2つです。

JICPAの「株式新規上場(IPO)のための事前準備ガイドブック」は、ショートレビューを「監査法人やアドバイザーがIPOに向けての課題抽出を行うもの」と説明しています。呼び方は予備調査や短期調査など様々です(p.3)。標準的なスケジュールの図では、ショートレビューは直前々期より前の準備期間に置かれ、そのあとに監査契約が続きます(p.3・p.8)。つまり、受ける目的は、改善すべき事項の全体像をつかみ、準備の計画を立てやすくすることです(p.8)。
では、ITも見てもらえるのでしょうか。実は、調査の範囲は一律ではないんです。同じガイドブックは、会計面だけに限るものから、さらに範囲を広げるものまで、実務では様々な形で行われていると書いています(p.3)。そのため、ITを見てほしいなら、依頼の段階で範囲に入るかを確かめます。
頼む相手にも注意が要ります。ガイドブックは、監査を依頼する予定の監査法人がショートレビューとその後のアドバイザリーを行う場合、独立性の制約がある可能性に触れています(p.3)。監査契約後は、監査と同時並行でアドバイスを受けられない場合があるので、早めに確かめ、別のアドバイザーも検討するよう書いています(p.10)。
指摘はショートレビューの報告書で終わりません。東京証券取引所の新規上場ガイドブック(グロース市場編)の事前チェックリストは、経営管理体制の整備にあたって担当監査法人と主幹事証券会社から受けた改善要請の内容と、その対応の説明を会社に求めています(p.113)。独立役員との面談でも、東証は指摘事項への対応状況の評価を独立役員に確かめます(p.16)。あとで対応を説明するので、指摘を受けた日から直した経緯を残します。
JICPAの例示は、方針なし・更新が担当者任せ・IDの共有・外部委託を挙げている
担当者が最初に読む公表資料は、JICPAのガイドブックの「ありがちな指摘」です。CFOには、自社がどの例示に近いかを1枚で示せるようにします。
ガイドブックは、初めてショートレビューや会計監査を受ける際のありがちな指摘を13項目の例示で並べています(p.11)。その10番目が「情報システムの内部統制」です。ポイントの概要は2つで、情報システムに関連するIT全社統制とIT全般統制(ITGC)という内部管理体制が整っているかと、社外の業者が提供するITサービスの信頼性や安全性を確かめているかです。
では、例示のケースはどんな会社なのでしょうか(p.27)。情報システムには必要のたびに投資してきたので、基本方針や戦略がありません。会計はクラウドのパッケージを使い、販売や仕入のシステムは自社用にカスタマイズしています。そのうえ、プログラムの更新は担当者に任せきりで、指針がありません。会計処理も経理部門の全員が操作でき、月次決算のあとでも直しています。ログインIDは経理部門で1つなので、いつ誰がどう直したか分かりません。
もう1つのケースは外部委託です(p.28)。拠点間でデータを共有するために、無料のクラウドに顧客の個人情報や証憑のPDFを保存しています。販売データの加工にRPA(パソコンの定型作業を自動で行うソフト)を使い、データを外部の業者のサーバーに置いています。ガイドブックは、外部委託や社外のソフトウェアでも、委託先の管理体制やソフトウェアの信頼性を確かめる必要があるとし、その方法として、会社が外部の業者に報告を求めるか、担当者が信頼性を検討することを挙げています。
ケースの状態を、次の節の統制の区分に当てはめると、下の表になります(主な区分を1つ挙げています)。
| ケースに出てくる状態 | 対応する統制 |
|---|---|
| 基本方針や戦略がない | IT全社統制 |
| プログラムの更新を担当者に任せきり | 開発・保守(変更管理) |
| 経理全員が操作でき、締めたあとも直せる | アクセス管理など(締めたあとの修正の管理も) |
| ログインIDを部署で1つ共有 | アクセス管理など |
| 無料のクラウドや外部のサーバーに保存 | 外部委託の管理(データの安全な管理も) |
なお、どちらのケースも例示で、指摘の頻度を集計したものではありません。頻度や順位の公表資料は、編集部が調べた範囲では見つかりませんでした。
指摘は、IT全社統制か、IT全般統制の4つの領域のどれかに当てはめて読む
担当者が報告書を読むときの物差しは、実施基準のIT全般統制です。指摘がどの領域に偏っているかをCFOに示すと、直す人と直す順番を決めやすくなります。
実施基準は、IT全般統制の具体例として、システムの開発・保守に係る管理、システムの運用・管理、内外からのアクセス管理などシステムの安全性の確保、外部委託に関する契約の管理の4つを挙げています(I.2(6)②ロa。以下「4つの領域」)。経営者の評価でも、同じ4つの点で整備と運用を確かめるとしています(II.3(3)⑤ニa)。さらに、経済産業省の「システム管理基準 追補版(財務報告に係るIT統制ガイダンス)」(2024年12月25日改訂、以下 追補版)も、同じ4つの区分に統制の項目を並べています。
実は、4つの領域の前に、IT全社統制があるんです。ガイドブックは、情報システムの現状を把握し、方針・戦略・計画を定め、予算や人材を確保したうえで、管理のルールを整備するとしています(p.27)。現状の把握には、システムの一覧とデータの流れが要ります。実施基準も、勘定科目とシステムの関係やデータの流れを図や表で整理し、システムの一覧を作ることが有用だとしています(II.3(3)⑤ロa)。
| 領域 | SaaS中心の会社で聞かれやすいこと(編集部の見立て) |
|---|---|
| 開発・保守 | 承認経路や自動仕訳ルール、連携の設定の変更を、誰が承認し記録したか |
| 運用・管理 | 銀行明細などの連携が止まったときの監視と再送、データの退避をしているか |
| アクセス管理など | IDは1人1つか、退職者のIDを止めたか、管理者は誰か |
| 外部委託の管理 | 会計や経費のSaaSの信頼性を、どの資料で確かめたか |
なかでも具体的に問われやすいのが、アクセス管理です。監査基準報告書315の付録6は、その要素として、利用者が自分のログイン資格情報を使っていることを確かめる「認証」、退職や異動のときにアクセス権を削除する「デプロビジョニング」、付与している権限を随時見直す「利用者アクセスレビュー」などを挙げています。315実務ガイダンス第1号のQ27も、市販の簡易なパッケージで1つのユーザアカウントを複数の担当者で共有していると、ユーザを特定できないことがあるため、監査人は会社の管理方法を確かめると書いています。ガイドブックの「ログインIDは経理部門で1つ」の例示は、誰が操作したか特定できない点で同じ問題です。とはいえ、同じガイダンスは、クラウド会計を市販の簡易なパッケージと同列に評価しないよう求めています(Q27の4.、Q30)。
金融庁の内部統制報告制度Q&Aは、事業規模が小規模で比較的簡素な組織構造の会社で、市販のパッケージをそのまま使うような比較的簡易なシステムなら、個々のIT業務処理統制よりも、IT全般統制に重点を置く必要があるとしています。そこで、編集部の見立てでは、設定を大きく変えずにSaaSを使う会社も、まず4つの領域から固めると進めやすくなります。SaaSを使う会社でも自社で担うIT全般統制の中身はSaaSで経理を回す会社に残るITGCの記事で扱っています。
受ける前にそろえるのは、システム一覧・ID一覧・変更の記録・委託先の資料
CFOは、4つの記録それぞれに担当者と置き場所が決まっているかを確かめれば足ります。
編集部の整理では、ショートレビューの前にそろえる記録は4つです。その前提として、変更やIDの発行をどう申請し承認するかを決めた手順書が要ります。なぜ記録より手順書が先なのでしょうか。ガイドブックの例示で問われているのが、記録の有無より先に、プログラムの更新に「特段の指針」がないことだからです(p.27)。手順書がまだなければ、記録を始めるときに手順を1枚にまとめます。

1つ目は、システムの一覧とデータの流れです。会計・経費精算・請求・給与・販売管理などのシステムごとに、関係する勘定科目、使っている部署、管理者、ほかのシステムとのデータのつながりを1枚にまとめます。たとえばA社なら、バクラクからfreee会計への連携、銀行明細の取り込み、販売データをCSVで取り込む手作業まで書き込みます。手作業の連携やExcelの集計はExcelの集計やCSV連携の統制の記事も参考になります。
2つ目は、IDと権限の一覧です。システムごとに、利用者、権限、付与した日、承認した人を並べます。退職者のIDが残っていないか、管理者の権限が必要な人だけに付いているかも、一覧を作ると分かります。四半期ごとの見直しは権限の棚卸の進め方の記事で扱っています。
3つ目は、変更の記録です。SaaSでは、承認経路や自動仕訳ルール、権限セットの変更がこれに当たります。追補版は、財務報告に重要な影響を及ぼすパラメータの変更を含め、本番環境のすべての変更が変更管理手続に従って管理されることが望まれるとしています。また、自動仕訳の対象データや勘定科目を変える際は、変更前の承認と変更後のテストを実施するとも書いています。誰が、いつ、何を、なぜ変えたかの台帳がなければ、今日から始めます(SaaSの設定変更を記録に残す方法の記事)。
4つ目は、委託先の資料です。会計や経費精算のSaaSについて、SOC1レポート(委託先の統制を、委託先が頼んだ監査人が確かめた報告書)などの保証報告書を入手できるかを調べます。契約プランで入手の可否が変わることがあるので、担当営業に聞きます(SaaSで経理を回す会社に残るITGCの記事)。追補版は、委託先の統制を確かめる方法として、質問書や確認書を送る方式、直接訪問する方式、保証報告書を入手する方式を挙げています。報告書の読み方はSOC1レポートの読み方の記事で扱っています。
加えて、315実務ガイダンス第1号のQ27は、監査人が統制機能の有無だけでなく、企業がそれを実際に使っているかにも留意するとしています。仕訳の承認フローを使えるプランでも、承認者が入力者と同じなら、記録として説明しにくくなります。
指摘を受けたら、領域に振り分けてから直す順番を決める
報告書が届いたら、CFOが決めるのは、直す担当者と期限、外部の専門家に頼む範囲です。担当者は、指摘を領域ごとに並べ直すところから始めます。
指摘をIT全社統制と4つの領域に振り分けると、同じ原因から出ている指摘がまとまります。たとえば「管理者が多い」「退職者のIDが残っている」「誰が直したか分からない」は、どれもアクセス管理の指摘なので、IDと権限の一覧を起点にまとめて直せます。一覧で対象を洗い出し、管理者を減らし、退職者のIDを止め、共有IDを1人1つに分けます。なお、操作の履歴がプランの都合で残らないシステムなら、台帳とスクリーンショットで補います。

直す順番は、上場までの時間から考えます。上場の申請には、直前2期間の財務諸表について監査法人の監査証明が要ります。その監査で監査人は、識別した内部統制について、ITの利用から生じるリスクの影響を受けるITアプリケーションを識別し、そのリスクに対応するIT全般統制を識別します。どこまで見られるかは会社のIT環境と監査人の手続で変わります。また、上場後の内部統制報告制度(J-SOX)で最初の内部統制報告書の基準日になるのは、原則として上場した期の期末です。それでも、IT全般統制は直前々期の監査から見られる前提で準備するのが安全だと、編集部では見ています。期ごとの段取りはIPO準備のJ-SOXロードマップの記事にまとめています。
直した結果は、日付と中身が分かる形で残し、第1節の上場審査での説明に使います。直した手順が、あとで作る3点セット(業務記述書・フローチャート・リスクと統制の対応表)のどこに当たるかも記録しておくと、文書化のときに一から整理し直さずに済みます(3点セットの最初の1本の書き方の記事)。
監査法人に直す作業を頼めるかは、第1節の独立性の制約があるので、早めに確かめる論点です。ガイドブックは、専門家を活用して、監査法人の評価に堪えられる体制を整備・運用するよう求めています(p.27)。そこで編集部では、直す作業は社内の担当者が受け持ち、足りない部分を外部の専門家に補ってもらう形が無理なく進むと考えています。
読み違えやすいポイント
| ありがちな読み方 | 一次資料では |
|---|---|
| 東証の上場審査では、IT全般統制が審査項目として確認される | 新規上場ガイドブックの審査項目に、IT全般統制という項目はありません。東証は会計監査人にもヒアリングし(p.76〜77)、会社には改善要請への対応と内部統制報告制度の準備状況の説明を求めます(p.113、p.77)。 |
| IT全般統制の不備が見つかると、開示すべき重要な不備になる | 上場後の内部統制報告制度では、経営者が他の統制で目的が達成されているかを検討し、業務処理統制が有効と検証できていれば、監査人は直ちに開示すべき重要な不備とは評価しません(III.4(2)④ニ)。ただし、すみやかな改善は求められます。 |
明日からやること
- ショートレビューを依頼する前に、調査の範囲にITが入っているかを確かめる
- 監査を依頼する予定の監査法人に、ショートレビュー後のアドバイスをどこまで頼めるかを聞いておく
- JICPAのガイドブックの例示(p.27・p.28)と自社を見比べ、近い状態に印を付ける
- システムの一覧とデータの流れを1枚にまとめる
- システムごとにIDと権限の一覧を作り、共有のIDと退職者のIDを洗い出す
- 設定やプログラムの変更とIDの発行について、申請・承認の手順を1枚の手順書にする
- 設定とプログラムの変更の台帳を、今日の変更から始める
- 会計と経費精算のSaaSについて、SOC1レポートなどの保証報告書を入手できるかを調べる
- 指摘を受けたら、IT全社統制と4つの領域に振り分け、直した日と中身を記録する
IT統制・J-SOX対応の進め方をご相談ください
使っているSaaSの洗い出し、IDと権限・設定変更の記録の始め方、SOC1レポートの読み込み、監査法人との協議に出す案づくりまで、公認会計士とエンジニアが一緒に整理します。