サイバーセキュリティや情報管理のため、または取引先からの信用を得るために、いまやIT統制の整備は欠かせない課題です。
「IT統制が必要なのはわかるけれど、社内のリソースだけで本当にできるのか？」「何から手をつければいいのか？」「何を優先すべきか？」――
考えることも、やることも山積みで、とても手がつけられないと感じるのではないでしょうか。
できることなら、外部の専門家に依頼する前に、できる範囲は社内で済ませたい。
そんな悩みを持つ方に向けて、システム監査の経験のある公認会計士が、実務に役立つ視点でわかりやすく解説します。
この記事では、まず「IT統制を作るために知っておくべき基本」を整理し、
社内の力だけで進めるために必要な現状把握・最低限のルール整備のステップを紹介します。
さらに、チェックリスト形式で押さえるべきポイントを明示し、
「どこまで自社で対応し、どこから外部専門家に頼るべきか」という判断基準もわかりやすく解説します。
完璧を目指す必要はありません。大事なのは現実的にできるところから確実に動き出すこと。
それが、社内でIT統制を成功させる一番の近道です。
ぜひ最後までお読みください。
IT統制を構築するために、何を知って何を理解すればいいか
IT統制を構築するには、（1）IT統制の目的、（2）IT統制の分類、（3）自社に適した統制水準と実現手段の３点を理解することが必要です。
- IT統制の目的：業務に関する「情報の正確性・完全性・機密性・可用性」を確保し、業務リスクや不正リスクを低減するために実施します。これらは全て必要です。
「情報の正確性・完全性・機密性・可用性」の説明は次の章で解説します。
参照リンク：金融庁「内部統制報告制度 Q&A」
https://www.fsa.go.jp/news/r5/sonota/20230831-2/20230831-2.html
- IT統制の分類：一般的に「IT全般統制（ITGC）」と「IT業務処理統制（ITAC）」に分かれます。
-ITGC（ITGeneralControls）は、システム全体に関わる統制、ルール（例：アクセス管理、変更管理など）。
-ITAC（ITApplicationControls）は、業務システムに組み込まれた個別処理の統制（例：入力チェック、処理結果の自動照合など）。
IT統制をこれから作成する場合にはITGCを優先して作成すればよいでしょう。 - 自社に適した統制水準と実現手段：会社規模や業種、リスク特性に応じて、どの程度の統制をどのような方法（手動、システム化、自動化）で実装するかを判断します。
会社の現状だけでなく、今後どうするか・どうなるかを前提に含めると導入後の運用で失敗しなくなります。
IT統制の基本と、実務上押さえるべきポイント
IT統制の目的「情報の正確性・完全性・機密性・可用性」とは
IT統制の目的である「情報の正確性・完全性・機密性・可用性」は、企業が適切に業務を遂行するために守るべき情報の４つの基本的な性質です。
- 正確性（Accuracy）：
情報が誤りなく、事実に基づいていること。
具体例：売上入力時に、金額や日付が正しく記録される（例えば、100万円の売上を誤って1,000万円と記録しないようにする）。 - 完全性（Completeness）：
情報が欠落なく全て記録されていること。
具体例：全ての受注データが漏れなく販売管理システムに登録されている（例えば、一部の受注がシステムに未登録で請求漏れが発生しないようにする）。 - 機密性（Confidentiality）：
情報が許可された人だけにしかアクセスされないこと。
具体例：従業員の個人情報や給与データが、関係者以外には閲覧できないようにアクセス制御する。 - 可用性（Availability）：
必要なときに情報やシステムを利用できること。
具体例：営業担当者が外出先からも在庫システムにログインして在庫状況を確認できる状態を維持する。
サーバー障害などで業務が止まらないようにバックアップ体制を整備する。
参照リンク：金融庁「内部統制報告制度 Q&A」
https://www.fsa.go.jp/news/r5/sonota/20230831-2/20230831-2.html
この４つの観点は、内部統制報告制度（J-SOX）やISMS（情報セキュリティマネジメントシステム）など、幅広い基準でも重要視される基本です。
さらに、実務上「どの性質が特に重要か」は業務プロセスや情報の種類によって違いますので、それを整理することが統制設計の第一歩になります。
[用語解説]
内部統制報告制度（J-SOX）：上場企業に対して「財務報告の信頼性を確保するために、会社内部の統制がきちんと整備・運用されているか」をチェックし、結果を報告させる仕組み。
ISMS（情報セキュリティマネジメントシステム）：組織全体で「情報を守るための仕組み」を作り、運用・改善し続けるための国際的なルール体系のこと。
IT統制のルールがない。これはIT統制は無いと判断されるのか
上場企業はともかく、それ以外の会社ではIT統制のルールが必ずしも体系的に作られているとは限りません。
では、体系的なルールがない会社はIT統制がないのかと言われると、厳密には「体系立てていなくても、実態として何らかのIT統制は存在している可能性が高い」です。
- 例えば、
「ログインIDとパスワードを使って業務システムにアクセス制限をかけている」
「従業員の入社・退社に合わせてアカウントを手動で削除している」
「パッケージソフトのアップデートを年1回実施している」
このようなルールや手順が文書化・体系化されていなくても、現場で自然に運用されている統制活動はよくあります。 - ですが属人的（個人任せ）で、標準化・可視化されていないと、IT統制が「機能している」とは評価できず、監査や内部統制上もリスクが高いと判断されます。
つまり、
→「統制の種（たね）はあるが、体系化・標準化されていない」
→「このままでは『実効性あるIT統制』とはみなされない」
と捉えるのが正しい理解です。
取引先に説明するときには説明・納得させづらい状態と言えるでしょう。
必要に応じて、
- 統制の「ルール化・手順化」
- 責任者の明確化
- 記録（ログなど）の保存
を進めると、正式なIT統制と認められる基盤になります。
IT統制を作るのに社内の人員だけでできるのか
結論は、IT統制に詳しい人がいなくても基本的な土台作りは可能。
IT統制の必要性があると感じても専門家が必要、コストがかかる、ハードルが高いと感じるでしょう。
いざIT統制を構築しようとしたとき、ITをある程度知っていたとしても、IT統制に詳しい人は社内にはいない場合もありますよね。
ただ「高度なセキュリティ設計」までは難しいので、まずできる範囲で「ルールを見える化し、守れる仕組みを作る」ことを目指すべきです。
具体的には、以下の３つを段階的に進めます。
①【現状把握】
-どんなIT資産（システム、データ）があるかリストアップする
-誰が何を管理しているかを書き出す（責任者・担当者の整理）
②【最低限のルール作り】
-パスワード設定、アクセス権付与・削除の手順を書面にする（A4一枚でもOK）
-退職・異動時にアカウントを無効化する流れを明文化する
③【実行管理】
-ルールに沿って運用しているかを、年1回でもいいので確認・記録する
ポイントは、「完璧を目指さず、できることから順に可視化・共有する」ことです。
このやり方なら、ITに詳しい専門家がいなくても、総務・経理の方たちの手で進められます。
もしさらに進めるなら、必要に応じて
- 簡易なチェックリストの作成
- 役割ごとの権限一覧表の作成
- 情報漏洩発生時の初動マニュアル作成
なども段階的に足していけばよいです。
基本的な土台作り3ステップ、現状把握と最低限のルール
社内の人だけで始めるなら、これくらいシンプルで十分というテンプレートをつけて解説します。
土台作りの3ステップは次の通りであることは前の章で説明しました。
- システムに何があるかの現状把握
- 簡易なIT統制の有無の現状把握
- 現状把握の後に最低限のルール作り
それぞれ次のテンプレートを参照して作成してみてください。
- 「まず始めるための現状把握用テンプレート」例
社内にどんなシステムが有るのかを調べます。
| 項目 | 内容 | 記入例 |
| システム名 | 使用しているシステムの名前 | 販売管理システム（弥生販売） |
| 管理部門・責任者 | システムを管理する部署と責任者 | 情シス部門／◯◯マネージャー |
| 利用者 | 主に利用する部署・役職 | 営業部、営業担当者全員 |
| アクセス権限管理 | 誰が権限設定しているか | 情シス部門（部署長決裁で変更） |
| パスワード管理方法 | ルールがあるか （例：定期変更、複雑さ要件） | あり（年1回変更、英数字8文字以上） |
| 退職者対応方法 | 退職・異動時にアカウント削除しているか | 有（退職日に情シスが無効化） |
| バックアップ有無 | データのバックアップがあるか | あり （クラウド自動バックアップ） |
システムとは、使っているアプリ、購入したソフト、プログラミングされて動いているものと考えてください。（例：Windows、帳簿アプリ他、債権管理システム）
このテンプレートをシステムごとにざっくり整理するだけでも、全体像が一気に見えてきます。
経産省「システム管理基準（令和5年改訂）」
https://www.meti.go.jp/policy/netsecurity/sys-kansa/sys-kanri-2023.pdf
- IT統制簡易チェックリスト
次にシステム毎にIT統制簡易チェックリストで現状のIT統制の有無と課題を調査・記録します。
| チェック項目 | できている | コメント欄 （課題・補足） |
| 業務システムごとに責任者が決まっているか | Y／N | |
| アカウント発行・権限変更時に承認を得ているか | Y／N | |
| 退職・異動時のアカウント削除手順があるか | Y／N | |
| パスワードルール（複雑性、定期変更）があるか | Y／N | |
| データのバックアップ体制が整っているか | Y／N | |
| システム障害発生時の初動対応マニュアルがあるか | Y／N | |
| 外部からの不正アクセス対策（ファイアウォール等）があるか | Y／N | |
| ルールや手順を文書化しているか | Y／N | |
| ルールに沿った運用が行われているか年1回は確認しているか | Y／N | |
| 特権IDは誰が管理しているのか | Y／N |
この中でもIT統制で特に重要視されるのがアカウント管理です。
特に大事なのが、特権IDやスーパーユーザという特殊なアカウントの有無と管理なので、必ず確かめてください。
危険な状態は、特権IDが「誰でも使える」状態。これはIT統制では論外、一発エラーです。
- 「最低限のルール」例
「まずはこれだけ決めておこう」というルール案です。
A4一枚でOK、形式も自由で、箇条書きでまとめれば十分です。
【IT基本ルール（案）】
- 各業務システムの管理責任者を定める。
- パスワードは8文字以上、英数字混在とする。最低でも年1回変更する。
- 新規アカウント発行・権限変更は、所属長の承認を得る。
- 退職・異動時には、退職日当日までにアカウントを無効化する。
- バックアップは毎日自動取得し、復旧テストを年1回行う。
- システムの利用手順書・管理手順書は作成・保管する。
これらを「まずたたき台として作ってみる」→「現場の責任者とすり合わせる」→「徐々に育てる」というイメージで進めると、負担も少なく、自然とIT統制の土台が作れます。
生成AIが使用可能であれば、最初のたたき台を作成してもらうのも手ですね。（専門家の商売あがったりです）。
【使い方アドバイス】
- 最初は「全部Yをつけよう」と思わなくていいです！
- まず現状を把握→出来ていないところを「リスク認識」として一覧化→優先順位を決めて対策
- 「管理者を決める」「パスワードルールを決める」あたりから取り掛かるのがおすすめです。
IT統制を構築して、運用することが目的です。
現状把握が目的ですからダメ出しに注力してはいけません。
未整備で発生するインシデント例を紹介
ここまで読むと「やることが多い」と感じたかもしれません。
実際にやることは多いですし、IT統制の構築には内部統制という単語に縁が無い人にも協力してもらわなければなりません。
この章ではIT統制がなぜ必要なのかを、IT統制が無かったときに発生するインシデントの例でお伝えします。
【IT統制未整備時に起こり得るインシデント一覧】
| チェック項目 | 起こり得るインシデント例 |
| 業務システムごとに責任者が決まっていない | システム障害やトラブル発生時に対応が遅れ、業務停止する |
| アカウント発行・権限変更時に承認を得ていない | 権限の不正付与・情報漏洩・内部不正行為（データ持ち出しなど） |
| 退職・異動時のアカウント削除手順がない | 退職者がシステムにアクセスできる状態が続き、情報漏洩や不正アクセスが発生 |
| パスワードルール（複雑性、定期変更）がない | パスワード推測による不正ログイン、アカウント乗っ取り |
| データのバックアップ体制が整っていない | サーバ障害やサイバー攻撃（ランサムウェア）発生時にデータを復元できず、業務継続不可能 |
| システム障害発生時の初動対応マニュアルがない | 重大インシデント発生時に対応が後手に回り、損害拡大・信用失墜 |
| 外部からの不正アクセス対策（ファイアウォール等）がない | 第三者によるシステム侵入、情報改ざん・流出、ウイルス感染拡大 |
| ルールや手順を文書化していない | 組織的な継続運用ができず、属人化によるミスや業務停止 |
| ルールに沿った運用確認（年1回チェック）していない | 小さな統制漏れや違反が長期間放置され、重大な事故につながる |
| 特権ID（システム管理者権限）の管理者が不明確 | システム設定の不正変更、不正操作、全データの消去・改ざんなど重大な被害 |
なぜ必要なのかとIT統制を実際に作る段階で聞かれたら、この表が参考になるでしょう。
【IT統制リスク優先対策ランキング】
次に危険度が高い順＝優先して対処すべき順でIT統制をランキング付けした表をお見せします。
| ランキング | 項目 | 優先理由 |
| 1位 | 特権ID（管理者権限）の 管理体制整備 | 特権IDが悪用されると、全データ消去・改ざんなど壊滅的な被害が発生するため、最優先で管理・監視が必要。 |
| 2位 | 退職・異動時の アカウント削除手順 | 退職者による不正アクセス・情報漏洩は、実被害が大きく、発覚後の信用失墜リスクが極めて高いため。 |
| 3位 | パスワードルール （複雑性・定期変更） | パスワード推測や漏洩からの不正侵入リスクを直接防ぐ基本防御策。 |
| 4位 | 業務システムごとの 責任者設定 | システム障害や事故発生時の初動遅れ防止、統制強化のため。 |
| 5位 | データバックアップ体制の 整備 | サーバ障害やサイバー攻撃に備え、事業継続の命綱となるデータ保護が必須。 |
| 6位 | アカウント発行・ 権限変更時の承認手順 | 不正アクセスや過剰権限によるリスク防止。 |
| 7位 | システム障害発生時の 初動マニュアル | 重大インシデント発生時の損害拡大を防止するため。 |
| 8位 | 外部からの不正アクセス対策（ファイアウォール等） | 外部攻撃への対策。ただし初期構築負荷が高いため内部整備後に着手。 |
| 9位 | ルールや手順の文書化 | 長期的な統制継続のために必要。ただし優先順位は上記実態対策より後。 |
| 10位 | ルールに沿った運用確認 （年1回チェック） | 定期見直しは重要だが、まず運用ルール整備を優先。 |
どれもIT統制では重要とされますが、上位の統制の不備（機能していないこと）は優先的に対応しましょう。
参照リンク：IPA「情報セキュリティ10大脅威 2025」
https://www.ipa.go.jp/security/10threats/10threats2025.html
【ポイント】
- 最優先は「特権IDの管理体制整備」「退職者アカウント削除」「パスワード管理」
- 「責任者設定」と「バックアップ体制」は即対応対象
- 外部セキュリティ投資や年次チェックは、まず土台を整えてから着手
これらのリスクは、「普段問題ないから大丈夫」では防げないものです。
特権IDはいわゆる何でもできるアカウントです。特権IDの管理がずさんだと、どうにもなりません。
例えば外部委託先だけが特権IDを持っている場合には、委託先を変えることもできなくなり、人質を取られたような状態になってしまいます。
他には「退職者アカウント放置」や「バックアップ未実施」は、実際の情報漏洩・事業停止事故の大きな原因になっています。
優先度と優先する理由を理解してIT統制の構築に取り組んでください。
外部の専門家に依頼すべきか、判断する5つの視点
IT統制を社内で進めることは可能ですが、すべてを自力で完璧に対応するのは現実的ではありません。
重要なのは、社内対応で十分な範囲と、外部の専門家に頼るべき範囲を適切に見極めることです。
特に、重大なリスク管理や外部への説明責任が発生する場合には、早めに専門家の支援を検討すべきでしょう。
外部の専門家に依頼すべきかどうかは、主に次の５つの視点から判断します。
リスクの大きさに対して社内対応だけでは不安な場合
- 特権ID管理、退職者アカウント削除、システム障害対応など、一発で重大インシデントに直結する領域に整備不備がある。
- 社内に対応ノウハウがなく、想定外のミスが起こるリスクが高い。
例：「特権IDの管理記録を取れていない。もし情報漏洩が起きたら、被害額数千万円規模になりかねない」
自社に専門知識・実務経験が明確に不足している場合
- 「ITGC」「ITAC」「特権ID管理」「アクセス制御設計」などの専門用語の意味すら曖昧な状態。
- 調査・設計・ルール作成を社内だけでやろうとすると、かえって統制不備を招くリスクがある。
例：「アクセス権限設計をどう作ればよいかわからないが、感覚だけでルールを作り始めてしまった」
監査・取引先・第三者への説明責任が求められる場合
- 上場企業、上場準備企業、大手取引先がいる会社では、IT統制の説明責任が発生する。
- 社内独自基準だけでは監査法人・取引先チェックに耐えられない可能性がある。
例：「取引先からセキュリティ監査対応を求められたが、現状の管理体制をきちんと説明できない」
時間的制約がある場合
- 「数ヶ月以内に体制を整備しないといけない」など、期限付きで統制整備が求められる場合。
- 社内リソースだけでやると間に合わない、品質が担保できないと判断される。
例：「IPO準備で半年以内にIT統制の文書化と運用整備が必須」
客観的な第三者評価が必要な場合
- 「内部で作った仕組みが本当に通用するか」第三者視点でのレビューが求められる場合。
- 組織内評価（自己評価）だけでは、バイアスがかかるリスクが高い。
例：「一応社内でIT統制を整備したが、監査法人から『外部レビューを受けた方がいい』と指摘された」
結論：基本判断フロー
- リスクが高い
- 知識が不足
- 説明責任がある
- 時間がない
- 客観評価が必要
→一つでも該当すれば外部依頼を検討すべき
逆に、これらに該当せず、社内で「できることを少しずつ積み重ねる」段階なら、まず自社完結で問題ありません。
Q&A
よくある質問、状況のQ&Aです。
Q：パスワード管理や権限設定のときには利用部署長かその補佐が決めている。ほかもそういった感じですが、今まで情報漏洩や侵入はありませんでした。ルールとして明文化されていませんし、引継ぎは前責任者が引継ぎの一環としておこなっています。このままでも良いですか？
A:現状を「問題なし」とするにはリスクが高いです。今まで事故（情報漏洩・侵入）がなかったのは「運が良かった」側面もあり、今後も安全とは言い切れません。
理由は次の通りです。
- 属人的な管理は脆弱：責任者や担当者が異動・退職すると、暗黙のルールが失われたり、ミスが起こりやすくなります。
- 明文化されていないと内部不正も発見しづらい：万一問題が起きたときに、どこが悪かったか特定できず、再発防止策が取れません。
- 第三者（監査、顧客、取引先など）への説明責任を果たせない：取引規模が拡大すると、取引先からセキュリティや内部統制についての説明・証明を求められることが増えますが、文書がないと信頼されません。
今すぐ「完璧な仕組み」を作る必要はありませんが、少なくとも
- 「パスワード管理と権限設定は部署長が決める」
- 「引継ぎはどういう手順で行うか」
など、今あるルールを簡単に書き出して標準化することが大切です。
Q：ITにそこまで詳しくないが、社内だけでIT統制を作るのは本当に可能ですか？
A：基本的な土台作り（現状把握・最低限のルール整備）なら可能です。
ただし、暗黙のルールや属人化を排除するために、必ず「書き出して標準化する」ことを意識しましょう。
専門知識が必要なセキュリティ設計やシステム監査対応は、無理せず外部支援を検討すべきです。
Q：最低限のIT統制でも、運用が形骸化しないためのコツは？
A：年1回の簡易自己点検（セルフチェック）を必ず行うことです。
たとえば、
- 権限設定に漏れがないか
- 退職者アカウントが削除されているか
- 特権IDの利用記録が取られているか
など、チェックリストをもとに現状を確認し、改善するサイクルを回しましょう。
「運用を止めない仕組み」を作ることが、形骸化防止の鍵です。
Q：「どんなときに外部の専門家に頼るべきか、シンプルに教えてください」
A：次のうち一つでも該当すれば外部支援を検討すべきです。
- リスクが大きい領域（特権ID、退職者アカウント）が手薄
- 社内に専門知識がない、担当者が不安を感じている
- 監査法人や取引先に説明を求められている
- 内部統制の完成期限が迫っている（IPO準備など
- 客観的な第三者レビューが求められる
まとめ
IT統制は、社内のリソースだけでも基本的な土台を作ることが可能です。
本記事では、IT統制の目的や分類、自社に適した整備ステップについて整理し、「できるところから始める」現実的なアプローチをご紹介しました。
特に、特権ID管理、退職者アカウント削除、パスワード管理といった重大リスクに直結する領域は、優先的に整備すべきです。
現状把握、最低限のルール作成、簡単なチェック体制整備といった段階的な進め方であれば、短い期間で基本対応を進めることも可能でしょう。
すべてを完璧にやろうとするのではなく、リスクに応じて外部専門家の支援を検討する基準も持つことが重要です。
（例：説明責任が発生する、専門知識が不足している、時間制約が厳しい場合など）
まずは、社内で「現状を見える化し、小さな一歩を踏み出すこと」から始めてください。
適切なルール作りと日々の地道な取り組みこそが、情報資産を守り、会社の信頼を高める力になります。
この記事が、あなたの会社でIT統制を整備する第一歩となれば幸いです。
当記事は以上になります。
最後までお読みいただきありがとうございました。
記事を読んだ感想、質問、疑問点あるいはご指摘事項がありましたら質問フォームにご記載ください。
可能な限りご回答させていただきます。
コメント