
目次
はじめに:なぜIT監査の年間計画が重要なのか#
IT監査の年間計画は、組織のITリスクを体系的に評価し、限られたリソースを効果的に配分するための羅針盤です。「監査計画なんて形式的なもの」と思われがちですが、実際には経営層への説明責任を果たし、監査チームの活動を戦略的に導く重要なドキュメントです。
近年、DX(デジタルトランスフォーメーション)の加速、クラウドサービスの普及、サイバー攻撃の高度化により、IT監査の対象領域は急速に拡大しています。金融庁の調査によると、日本企業の約70%がサイバーセキュリティを経営課題として認識しており、IT監査への期待はかつてないほど高まっています。
本記事では、IT監査の実務担当者が明日から使える年間計画の作成方法を、具体的な手順とともに解説します。初めて年間計画を作成する方から、既存の計画を見直したい方まで、幅広く参考にしていただける内容となっています。
背景・概要:IT監査年間計画の基本的な考え方#
IT監査年間計画とは#
IT監査年間計画とは、1年間(または複数年)にわたって実施するIT監査の対象、範囲、スケジュール、リソース配分を定めた計画書です。英語では「IT Audit Annual Plan」や「IT Audit Universe」と呼ばれることもあります。
この計画は、以下の3つの観点から策定されます:
- リスクベース・アプローチ:組織が直面するITリスクの大きさに基づいて監査対象を優先順位付けする考え方
- 監査周期(サイクル):過去の監査実績や規制要件に基づく定期的な監査の考え方
- 経営ニーズ:経営層や監査委員会からの特別な要請に応える考え方
IT監査年間計画に含めるべき要素#
標準的なIT監査年間計画には、以下の要素が含まれます:
| 要素 | 説明 | 例 |
|---|---|---|
| 監査対象(Audit Universe) | 監査可能なすべての領域の一覧 | 基幹システム、クラウド環境、情報セキュリティ等 |
| リスク評価結果 | 各監査対象のリスクレベル | 高・中・低の3段階評価 |
| 監査テーマ | 年度内に実施する具体的な監査項目 | アクセス管理監査、変更管理監査等 |
| 実施時期 | 各監査の予定期間 | Q1、Q2などの四半期ベース |
| 必要工数 | 監査に必要な人日数 | 20人日、40人日等 |
| 担当者 | 主担当・副担当の割当 | 監査チームメンバー名 |
関連する基準・フレームワーク#
IT監査年間計画の策定にあたっては、以下の基準やフレームワークを参考にすることが推奨されます:
- IIA(内部監査人協会)の国際基準:2010「計画の策定」において、リスクベースの年間計画策定を要求
- ISACA COBIT 2019:ITガバナンスとマネジメントのフレームワークとして、監査対象領域の特定に活用
- ISO/IEC 27001:情報セキュリティマネジメントシステムの要求事項として、内部監査の計画的実施を規定
- 金融検査マニュアル(廃止後も参考資料として):金融機関におけるシステム監査の考え方
IT監査年間計画の作成手順:7つのステップ#
ここからは、実務で使える具体的な手順を7つのステップに分けて解説します。各ステップには、実践的なポイントと具体例を含めています。
ステップ1:監査対象領域(Audit Universe)の洗い出し#
目的:組織内のすべてのIT関連領域を網羅的に把握し、監査の「母集団」を作成する
IT監査年間計画の第一歩は、監査対象となりうるすべての領域を洗い出すことです。これを「監査対象領域」または「Audit Universe」と呼びます。
具体的な洗い出し方法:
システム台帳からの抽出
- 情報システム部門が管理するシステム一覧を入手
- 本番系システム、開発系システム、ネットワーク機器等を含める
- クラウドサービス(SaaS、IaaS、PaaS)も忘れずに追加
業務プロセスからの抽出
- 経理、人事、営業、製造等の主要業務プロセスを特定
- 各プロセスで使用されるITシステムを紐付け
- 外部委託先が関与するプロセスも対象に含める
規制要件からの抽出
- 業界固有の規制で求められる監査対象を確認
- 例:金融業であればFISC安全対策基準、医療業であれば医療情報システムの安全管理ガイドライン
実務で使えるポイント:
監査対象領域は、以下のようなカテゴリで整理すると管理しやすくなります:
【監査対象領域の分類例】
├── ITガバナンス
│ ├── IT戦略・計画
│ ├── IT組織・体制
│ └── IT投資管理
├── ITマネジメント
│ ├── プロジェクト管理
│ ├── ベンダー管理
│ └── ITサービス管理
├── IT運用
│ ├── 変更管理
│ ├── インシデント管理
│ └── バックアップ・リカバリ
├── 情報セキュリティ
│ ├── アクセス管理
│ ├── ネットワークセキュリティ
│ └── データ保護
└── 個別システム
├── 基幹システム(ERP等)
├── 顧客管理システム(CRM等)
└── その他業務システム
注意点:
監査対象領域は、最低でも年1回は見直しを行いましょう。新規システムの導入、組織再編、M&Aなどにより、対象領域は常に変化します。中堅企業でも50〜100程度の監査対象領域が存在することは珍しくありません。
ステップ2:リスク評価(Risk Assessment)の実施#
目的:各監査対象領域のリスクレベルを評価し、監査の優先順位付けの根拠とする
リスクベース・アプローチの核心となるステップです。すべての監査対象を同じ頻度で監査することは現実的ではないため、リスクの高い領域に監査リソースを集中させる必要があります。
リスク評価の方法:
一般的なリスク評価では、「影響度」と「発生可能性」の2軸でリスクを評価します。IT監査においては、以下の評価要素が用いられます。
影響度(Impact)の評価要素:
| 評価項目 | 高(3点) | 中(2点) | 低(1点) |
|---|---|---|---|
| 財務影響 | 1億円以上の損失可能性 | 1,000万〜1億円 | 1,000万円未満 |
| 規制・コンプライアンス | 業務停止命令のリスク | 改善命令のリスク | 指摘事項レベル |
| レピュテーション | 全国ニュースレベル | 業界内で話題に | 社内問題に留まる |
| 業務への影響 | 全社的な業務停止 | 部門レベルの影響 | 一部業務への影響 |
発生可能性(Likelihood)の評価要素:
| 評価項目 | 高(3点) | 中(2点) | 低(1点) |
|---|---|---|---|
| 前回監査からの経過期間 | 3年以上 | 1〜3年 | 1年以内 |
| 前回監査での指摘件数 | 重大な指摘あり | 中程度の指摘あり | 指摘なし/軽微 |
| 直近の変更状況 | 大規模な変更あり | 中程度の変更あり | 変更なし/軽微 |
| 過去のインシデント | 重大インシデント発生 | 軽微なインシデント | インシデントなし |
リスクスコアの算出例:
リスクスコア = 影響度スコア × 発生可能性スコア
【計算例:基幹システム(ERP)の場合】
・財務影響:高(3点)- 経理業務に直結
・規制影響:中(2点)- J-SOX対象システム
・レピュテーション:中(2点)
・業務影響:高(3点)- 全社で使用
→ 影響度スコア = (3+2+2+3)/4 = 2.5
・前回監査からの経過:中(2点)- 2年前に実施
・前回指摘件数:中(2点)- 改善勧告3件
・直近の変更:高(3点)- 大規模アップグレード実施
・過去インシデント:低(1点)
→ 発生可能性スコア = (2+2+3+1)/4 = 2.0
リスクスコア = 2.5 × 2.0 = 5.0(9点満点中)
リスクレベルの判定基準:
| リスクスコア | リスクレベル | 監査周期の目安 |
|---|---|---|
| 6.0以上 | 高 | 毎年実施 |
| 3.0〜5.9 | 中 | 2〜3年に1回 |
| 3.0未満 | 低 | 3〜5年に1回 |
実務で使えるポイント:
- リスク評価は、監査部門だけで行わず、IT部門や事業部門の意見も取り入れましょう
- 評価結果は必ず文書化し、翌年以降の計画策定時に参照できるようにしておきます
- 「なぜこの監査を実施するのか」を経営層に説明する際、リスク評価結果が強力な根拠になります
ステップ3:監査リソースの把握と制約条件の確認#
目的:利用可能な監査リソースを把握し、現実的な計画を策定するための制約条件を明確にする
どんなに理想的な監査計画を立てても、リソースが不足していれば実行できません。このステップでは、計画策定の前提条件を明確にします。
把握すべきリソース:
人的リソース
- 内部監査部門の人員数(正社員、派遣社員、パートタイム等)
- 各メンバーのスキルレベル(IT監査経験年数、保有資格等)
- 年間の稼働可能日数(休暇、研修、管理業務等を除く)
外部リソース
- 外部委託(コソーシング)の予算
- 協力会社との契約状況
- 専門家の活用可能性(セキュリティ診断、ペネトレーションテスト等)
ツール・インフラ
- 監査管理ソフトウェアの有無
- データ分析ツールの利用可能性
- リモート監査のための環境整備状況
稼働可能日数の算出例:
【IT監査チーム(4名)の年間稼働可能日数】
年間営業日:245日(土日祝日を除く)
1人あたりの控除日数:
・有給休暇取得:20日
・研修・教育:10日
・管理業務(計画、報告書レビュー等):30日
・その他(会議、採用活動等):15日
合計控除:75日
1人あたり監査実施可能日数 = 245 - 75 = 170日
チーム全体の監査実施可能日数 = 170 × 4名 = 680人日/年
制約条件の確認:
- 監査委員会・経営層からの指示事項:特定のテーマや領域の監査要請
- 外部監査人との調整:会計監査人によるIT統制評価との重複回避
- 規制要件:法令や規制で義務付けられている監査項目
- 被監査部門の繁忙期:決算期、システム更改時期等との調整
実務で使えるポイント:
- 監査リソースの20〜30%は、年度途中に発生する緊急案件や特別調査用にバッファとして確保しておきましょう
- 外部委託を活用する場合、早期(6ヶ月前程度)に予算確保と業者選定を進めることが重要です
- 新人監査人の育成も考慮し、適度な難易度の監査案件を配置します
ステップ4:監査テーマと優先順位の決定#
目的:当該年度に実施する具体的な監査テーマを選定し、優先順位を付ける
ステップ1〜3で収集した情報を基に、実際に年度内で実施する監査テーマを決定します。
監査テーマ選定の考慮要素:
- リスク評価結果:高リスク領域を優先的に選定
- 監査周期:前回監査からの経過期間に基づく選定
- 経営課題との連動:中期経営計画やIT戦略との整合性
- 外部環境の変化:新しい脅威やトレンドへの対応
- 規制要件:法令や業界基準で求められる監査
監査テーマ選定のマトリクス例:
| 優先度 | リスクレベル | 監査周期 | 経営要請 | 選定基準 |
|---|---|---|---|---|
| 最優先 | 高 | 期限到来 | あり | 必ず実施 |
| 優先 | 高 | 期限未到来 | あり | 可能な限り実施 |
| 優先 | 中 | 期限到来 | - | リソースに応じて実施 |
| 通常 | 中 | 期限未到来 | - | 余力があれば実施 |
| 次年度以降 | 低 | - | - | 今年度は見送り |
年間監査テーマの例(中堅製造業の場合):
【2026年度IT監査計画:監査テーマ一覧】
【第1四半期(4-6月)】
1. 特権アクセス管理監査(基幹システム)
- 優先度:最優先
- 理由:前回指摘の改善状況確認、高リスク領域
- 予定工数:30人日
2. クラウドサービス利用状況監査
- 優先度:優先
- 理由:シャドーIT増加への懸念、経営層からの要請
- 予定工数:25人日
【第2四半期(7-9月)】
3. 変更管理プロセス監査
- 優先度:優先
- 理由:システム更改後のプロセス有効性確認
- 予定工数:20人日
4. IT委託先管理監査
- 優先度:通常
- 理由:監査周期による定期監査
- 予定工数:35人日
【第3四半期(10-12月)】
5. 情報セキュリティ教育・意識向上施策の有効性評価
- 優先度:優先
- 理由:フィッシング被害増加を受けた経営要請
- 予定工数:15人日
6. バックアップ・リカバリ監査
- 優先度:通常
- 理由:監査周期による定期監査
- 予定工数:25人日
【第4四半期(1-3月)】
7. IT投資管理・プロジェクト監査
- 優先度:通常
- 理由:大型IT投資案件の進捗確認
- 予定工数:20人日
8. 予備枠(特別調査・フォローアップ用)
- 予定工数:30人日
年間合計:200人日
実務で使えるポイント:
- 年度当初に計画した監査テーマをすべて実施することが目的ではありません。環境変化に応じた柔軟な見直しが重要です
- 各監査テーマには、必ず「なぜ今年度実施するのか」の理由を明記しておきましょう
- フォローアップ監査(改善状況確認)の工数も計画に含めることを忘れずに
ステップ5:スケジュールの策定#
目的:年間を通じた監査実施スケジュールを策定し、リソースの平準化を図る
監査テーマが決まったら、具体的な実施時期を決定します。
スケジュール策定の考慮事項:
被監査部門の業務繁忙期を避ける
- 決算期(3月、9月等)の経理部門への監査は避ける
- 年末年始、大型連休前後のシステム凍結期間に注意
- 新システム稼働直後は安定期を待ってから監査
外部監査との連携
- 会計監査人のIT統制評価スケジュールを確認
- 必要に応じて監査結果の共有や立会いを調整
- 重複作業の排除によるリソース効率化
監査チーム内のリソース平準化
- 特定の時期に監査が集中しないよう分散
- メンバーの休暇予定も考慮
- 新人と経験者のペアリングによるOJT機会の確保
報告サイクルとの整合
- 監査委員会への報告時期に合わせた完了タイミング
- 四半期報告、半期報告、年次報告のスケジュール確認
年間スケジュール例(ガントチャート形式):
監査テーマ | Q1(4-6月) | Q2(7-9月) | Q3(10-12月) | Q4(1-3月)
-----------------------|-----------|-----------|-------------|----------
1.特権アクセス管理 | ████████ | | |
2.クラウドサービス | ██████ | | |
3.変更管理プロセス | | ██████ | |
4.IT委託先管理 | | █████████| |
5.セキュリティ教育 | | | ████ |
6.バックアップ | | | ███████ |
7.IT投資管理 | | | | ██████
8.予備枠 | ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ |
████ = 監査実施期間
░░░░ = 予備(必要に応じて使用)
実務で使えるポイント:
- 1つの監査テーマに対して、準備(計画)→実施(フィールドワーク)→報告(レポート作成)の各フェーズの期間を明確にしましょう
- 一般的な目安として、監査実施期間の前後に各1〜2週間の準備・報告期間を設けます
- Excelやプロジェクト管理ツール(MS Project、Asana等)でスケジュールを可視化し、関係者と共有します
ステップ6:計画書の作成と承認取得#
目的:年間計画を正式な文書として作成し、適切な承認を得る
ここまでのステップで検討した内容を、正式な「IT監査年間計画書」として取りまとめます。
IT監査年間計画書の構成例:
【IT監査年間計画書 目次】
1. エグゼクティブサマリー(1ページ)
- 計画の概要、主要な監査テーマ、リソース配分
2. 監査環境の分析(2〜3ページ)
- 外部環境(法規制、脅威動向、業界トレンド)
- 内部環境(組織変更、システム変更、経営課題)
3. リスク評価の概要(2〜3ページ)
- 評価方法の説明
- リスク評価結果のサマリー(高リスク領域の一覧)
4. 年度監査計画(3〜5ページ)
- 監査テーマ一覧と概要
- 実施スケジュール
- リソース配分計画
5. 各監査テーマの詳細(監査テーマ数×1ページ)
- 監査目的
- 監査範囲
- 主要な監査手続
- 予定工数と担当者
- 想定リスクと留意事項
6. 品質管理計画(1ページ)
- レビュー体制
- 外部評価の実施予定
7. 付録
- 監査対象領域(Audit Universe)一覧
- リスク評価詳細データ
- 過去3年間の監査実績
承認プロセス:
IT監査年間計画は、以下の順序で承認を取得することが一般的です:
- 監査部門長の承認:計画の妥当性、リソース配分の適切性
- CAE(最高監査責任者)の承認:全社監査計画との整合性
- 監査委員会(または取締役会)への報告・承認:経営レベルでの承認
実務で使えるポイント:
- 計画書は「読まれることを前提」に作成しましょう。特にエグゼクティブサマリーは経営層が読む重要な部分です
- 監査委員会への報告時は、「なぜこの監査を行うのか」「何を達成しようとしているのか」を明確に説明できるよう準備します
- 承認後の計画書は、社内の適切な場所に保管し、監査チームメンバーがいつでも参照できるようにします
ステップ7:計画の見直しと継続的改善#
目的:策定した年間計画を定期的に見直し、環境変化に対応する
年間計画は「策定して終わり」ではありません。年度中も継続的に見直しを行い、必要に応じて修正します。
定期見直しのタイミング:
| タイミング | 見直し内容 | 承認レベル |
|---|---|---|
| 四半期ごと | 進捗確認、軽微なスケジュール調整 | 監査部門長 |
| 半期ごと | 優先順位の見直し、リソース再配分 | CAE |
| 重大イベント発生時 | 緊急監査の追加、計画の大幅変更 | 監査委員会 |
見直しが必要となる主なトリガー:
- 外部環境の変化:新たなサイバー攻撃手法の出現、法規制の改正
- 内部環境の変化:組織再編、大規模システム導入、重大インシデントの発生
- 監査リソースの変動:監査人の退職・異動、予算の変更
- 経営層からの緊急要請:特定領域への追加監査指示
計画変更時の文書化:
計画を変更した場合は、以下の内容を文書化しておきましょう:
【年間計画変更記録】
変更日:2026年8月15日
変更内容:ランサムウェア対策監査の追加
変更理由:同業他社でのランサムウェア被害を受けた経営層からの緊急要請
影響:IT委託先管理監査を第4四半期に延期
承認者:監査部門長(8月15日)、監査委員会報告予定(9月定例会議)
次年度計画へのフィードバック:
年度終了時には、以下の観点で振り返りを行い、次年度計画に活かします:
- 計画通りに実施できた監査テーマの数と理由
- 計画変更が発生した件数とその原因分析
- 工数見積りの精度(計画vs実績)
- 監査品質に関するフィードバック(被監査部門、経営層から)
よくある質問(FAQ)#
Q1:IT監査の年間計画は何月頃に作成すべきですか?#
A:会計年度開始の2〜3ヶ月前に着手し、年度開始前に承認を得るのが理想的です。
例えば、4月始まりの企業であれば、1月頃からリスク評価を開始し、2月中に計画案を作成、3月の監査委員会で承認を得るスケジュールが一般的です。
ただし、リスク評価
IT監査 セキュリティ