月曜の朝 8 時、経理部から情報システム部に電話が入りました。「土曜日の売上データが会計システムに入っていません」。調べると、金曜深夜の売上連携ジョブが異常終了していました。ジョブ管理ツールは異常を検知し、通知メールも送っていました。ただし宛先は、半年前に異動した担当者の個人アドレスのままでした。
原因が分かった後も混乱は続きます。再実行してよいのか、手作業で登録した一部のデータと二重にならないか、誰が判断するのか。障害記録には「再実行済み」の一行だけが残り、翌月の内部監査で調書を開いた担当者は、その判断の経緯を誰からも説明してもらえませんでした（本記事の事例はすべて架空のモデルケースです）。
IT運用管理は、うまく回っているあいだは誰の目にも留まりません。けれども、ジョブ、バックアップ、障害対応のどこかが崩れると、財務データの欠落や業務停止として一気に表面化します。この記事では、IT全般統制の一領域である運用管理を、内部監査としてどう評価するかを手順に沿って整理します。
この記事の要点
- 金融庁の実施基準は、システムの運用・管理について「データ消失等に備えた保存と迅速な復旧の対策」と「障害等の把握・分析・解決」を留意点に挙げています
- ジョブ管理では、スケジュール変更の承認、実行結果の監視、異常終了後の再実行・データ補正の承認を確かめます
- バックアップは「取得しているか」ではなく「目標時間内に復元できるか」を、復元テストの記録で確かめます
- 障害管理では、記録の網羅性、財務影響の判断、根本原因への対処（問題管理）の 3 点を見ます
- クラウドや委託先に運用を任せている場合も、自社側で担う統制（相補的な統制）の監査は残ります
IT運用管理とは何か：なぜ監査の対象になるのか
実施基準の「運用・管理」
金融庁企業会計審議会の「財務報告に係る内部統制の評価及び監査に関する実施基準」は、ITに係る全般統制の例として、システムの開発・保守に係る管理、システムの運用・管理、内外からのアクセス管理などシステムの安全性の確保、外部委託に関する契約の管理を挙げています。監査人向けの記述では、システムの運用・管理について次の 2 点を留意点としています。一つは、重要なデータやソフトウェアについて、障害や故障等によるデータ消失等に備えて内容を保存し、迅速な復旧を図るための対策が取られていること。もう一つは、障害や故障等が発生した場合に、状況の把握、分析、解決等の対応が適切に行われていることです。
短い記述ですが、ここには運用管理の本質が表れています。IT運用は「平常時に処理を正しく回すこと」と「異常時に正しく戻すこと」の 2 つでできている、ということです。前者の代表がジョブ管理、後者の代表がバックアップと障害管理です。
業務処理統制との関係
運用管理がJ-SOXで問題になるのは、ITに組み込まれた業務処理統制（ITAC）の前提を支えているからです。たとえば「売上データを会計システムへ自動連携する」統制は、ジョブが毎日実行され、異常時に漏れなく検知・補正されてはじめて完全性を保てます。ジョブが止まったまま気づかなければ、どれほど正確な連携プログラムでも計上漏れが起きます。ITACとITGCの関係はITACとITGCの違いで詳しく解説しています。
財務報告以外の目的
運用管理の監査は、J-SOXのためだけのものではありません。バックアップと復旧はランサムウェア被害からの回復力そのものであり、障害対応は事業継続の土台です。そのため、監査の目的を最初に決めておくことが大切です。
| 監査の目的 | 主な対象 | 重視する観点 |
|---|---|---|
| 財務報告の信頼性（J-SOX） | 会計・販売・購買など財務報告に関連するシステム | ジョブの完全な実行、異常時のデータ補正の承認、復旧後のデータの正確性 |
| 事業継続 | 基幹業務・顧客向けサービスを支えるシステム | 復旧目標の設定と達成可能性、代替手段、連絡体制 |
| サイバーセキュリティ | ランサムウェア等の標的になりうる全システム | バックアップの隔離、復元テスト、ログと監視 |
財務報告を目的とする評価範囲の考え方はJ-SOXの評価範囲の決め方を、事業継続の観点はBCPの監査を参照してください。
ジョブ管理（バッチ処理）の監査
ジョブ管理で起きること
ジョブ管理とは、夜間の一括処理（バッチ）や定時処理を、決められた順序と時刻で実行し、その結果を監視する仕組みです。多くの企業ではジョブ管理ツールを使い、処理の依存関係（Aが終わったらBを実行する）を定義しています。リスクは大きく 3 つです。スケジュールや処理内容が承認なく変更されること、異常終了が検知されないこと、そして異常終了後の再実行やデータ補正が場当たり的に行われることです。
監査手続と証拠
| 確認する統制 | 主な監査手続 | 証拠の例 |
|---|---|---|
| ジョブ定義・スケジュールの変更承認 | ジョブ定義の変更履歴を抽出し、変更申請・承認と照合 | ジョブ管理ツールの変更履歴、変更申請書 |
| 実行結果の監視 | 監視手順と通知先を確認し、一定期間の実行結果一覧から異常終了を抽出 | 実行結果ログ、通知設定画面、監視日報 |
| 異常終了時の対応 | 抽出した異常終了について、原因、再実行の判断、データ補正の承認を確認 | 障害記録、再実行の承認記録、補正前後のデータ件数 |
| ジョブ管理ツールの権限 | ジョブ定義を変更できる者と、実行を指示できる者の一覧を確認 | 権限一覧、職務分掌表 |
ジョブ定義の変更は、プログラム変更と同じく変更管理の対象として扱うのが基本です。ジョブの実行順序や実行条件の変更は、プログラムに一行も手を加えなくても処理結果を変えてしまうからです。変更管理の監査手順は変更管理の監査手順で詳しく扱っています。
母集団とサンプルの選び方
ジョブの異常終了を検証する際は、まず評価期間中の実行結果の一覧をジョブ管理ツールから直接抽出してもらいます。IT部門が作成した「障害一覧」から選ぶと、記録されなかった異常終了が母集団から漏れてしまうからです。抽出した一覧については、抽出条件（期間、対象ジョブ、終了ステータス）を画面や出力条件で確認し、母集団が完全であることを調書に残します。
異常終了の件数が少なければ全件を確認し、多い場合は財務データの連携・計算に関わるジョブを優先して選びます。ジョブの実行監視は日次で行われる統制のため、定期的な監視の実施記録を検証する場合はサンプル数の目安も参考になります。サンプル数の考え方は内部監査のサンプル数はなぜ25件なのかで解説しています。
通知先の棚卸を忘れない
冒頭のモデルケースのように、監視の仕組みがあっても通知先が古いままという例は少なくありません。通知先を個人アドレスではなく共有の窓口にしているか、人事異動の際に通知先を見直す手順があるかを確認します。監査の場では、通知設定の画面を見せてもらい、宛先が現在の担当者や窓口と一致しているかをその場で確かめるのが確実です。
再実行とデータ補正の判断
異常終了後の再実行は、二重計上や計上漏れの原因になりやすい操作です。どこまで処理が進んでいたかを確認し、途中まで登録されたデータを取り消すのか、残りだけを処理するのかを判断する必要があります。監査では、この判断を誰が行い、業務部門がデータの件数や金額を確認したかを記録で確かめます。IT部門だけで判断し、業務部門が事後に知ったという状態は改善を求める対象になります。
バックアップと復旧の監査
「取得」ではなく「復元」を確かめる
バックアップの監査で最もよくある誤りは、取得の設定とログだけを見て終えることです。実施基準の留意点も、保存にとどまらず「迅速な復旧を図るための対策」までを求めています。国際規格 ISO/IEC 27001:2022 の附属書Aでも、管理策 8.13「情報のバックアップ」は、合意されたバックアップに関する方針に従ってバックアップを維持し、定期的に検査することを求めています。復元できないバックアップは、統制として機能していないのと同じです。
復旧目標の設定
復旧を評価するには、目標が必要です。一般に**RPO（目標復旧時点）**は、障害が起きたときにどの時点のデータまで戻せればよいかを示し、**RTO（目標復旧時間）**は、どれだけの時間で業務を再開すべきかを示します。たとえば日次バックアップであれば、最大で約 1 日分のデータを失う前提になります。監査では、これらの目標が業務部門と合意されているか、バックアップの取得頻度や方式が目標と整合しているかを確認します。目標がIT部門の内部で決まっているだけで、業務部門が知らない例は多く見られます。
ランサムウェアを前提にした保管
近年のランサムウェア攻撃では、本番データと一緒にネットワーク上のバックアップも暗号化・削除される被害が起きています。そのため、バックアップの少なくとも一部を本番環境から切り離して保管する（オフライン保管や、書き換え・削除ができない設定の保管）ことや、バックアップ環境の管理者権限を本番環境と分けることが重要になっています。監査では、保管場所の構成図と、バックアップを削除できる権限を持つ者の一覧を確認します。
バックアップ監査チェックリスト
- 対象システムごとにRPO・RTOが定められ、業務部門と合意されている
- バックアップの対象（データ、設定、ソフトウェア）と取得頻度・保存期間が文書化されている
- 取得結果が毎回監視され、失敗時の再取得と記録の手順がある
- 少なくとも一部のバックアップが本番環境から切り離され、容易に削除・改変できない
- バックアップの削除・設定変更ができる権限が限定され、本番環境の管理者と分離されている
- 復元テストが定期的に行われ、所要時間と復元データの確認結果が記録されている
- 復元テストの所要時間がRTOを満たしているか評価され、満たさない場合の対応が決まっている
- クラウドやSaaSのデータについて、事業者と自社の責任範囲が確認されている
SaaSとクラウドの落とし穴
SaaSの多くは事業者側でバックアップを取得していますが、それが「利用者の誤操作で消したデータを利用者の求めに応じて戻す」ためのものかどうかは、契約やサービス仕様によって異なります。監査では、利用規約やサービス仕様で、復元の可否、対象期間、依頼手順を確認し、不足があれば自社でのデータの書き出し（エクスポート）などの補完策が取られているかを確かめます。
障害管理・問題管理の監査
記録の網羅性
障害対応の監査の出発点は、障害が漏れなく記録されているかです。記録されない障害は、分析も再発防止もされません。監査では、障害記録の件数を、ジョブの異常終了件数、ヘルプデスクへの問合せ、監視ツールのアラートなどの別の情報源と照らし合わせ、記録漏れがないかを確かめます。
財務影響の判断とエスカレーション
障害が財務データに影響したかどうかを、IT部門だけで判断していないかを確認します。データ補正を伴う障害は、業務部門と経理部門に連絡し、補正内容の確認を受ける手順が必要です。重大な障害については、影響の大きさに応じて誰に、いつまでに報告するかというエスカレーション基準が定められているかも確認します。次は、障害記録をサンプルで検証した際の調書の記入例です。
| 障害番号 | 内容 | 財務影響の判断 | 補正の承認 | 根本原因対応 | 評価 |
|---|---|---|---|---|---|
| INC-0412 | 売上連携ジョブ異常終了（通知先誤り） | 経理部が当日分の売上計上漏れを確認 | 補正は経理課長が承認 | 通知先を共有窓口に変更済み。異動時の見直し手順は未整備 | 要改善 |
| INC-0437 | 会計システムの応答遅延 | 影響なし（処理完了を確認） | 該当なし | 容量増強を計画中 | 適切 |
| INC-0451 | 支払データ作成ジョブの二重実行 | 情報システム部のみで判断し、経理部への連絡なし | 補正の承認記録なし | 未着手 | 要是正 |
重要度の分類と経営への報告
障害には、利用者 1 人の画面が固まる程度のものから、全社の受注が止まるものまで幅があります。すべてを同じ手順で扱うと、重大な障害が埋もれるか、軽微な障害の処理に手間がかかりすぎます。そこで、業務への影響範囲と停止時間、財務データへの影響の有無などで重要度を分類し、重要度ごとに対応の優先度と報告先を決めるのが一般的です。
監査では、分類の基準が文書化されているか、実際の障害が基準どおりに分類されているかを確認します。重大な障害が「軽微」に分類され、経営層に報告されていない例がないかを、影響の大きかった障害から逆にたどると確かめやすくなります。また、障害の件数や復旧時間の推移が定期的に経営層や関係部門に報告されているかも見ます。報告がなければ、運用品質の低下や人員不足の兆候を経営が把握できません。
障害管理と問題管理
個々の障害を復旧させる活動（障害管理）と、同じ障害が繰り返される原因を突き止めて取り除く活動（問題管理）は、区別して管理するのが一般的です。同じ種類の障害が月に何度も起き、そのたびに再実行で済ませている場合、問題管理が機能していない兆候です。監査では、障害記録を原因別に集計し、繰り返し発生している障害に恒久対策が計画されているかを確認します。
監視・ログと委託先運用の監査
監視とログ
運用管理では、システムの稼働状況、容量、エラーを監視し、ログを保存します。ISO/IEC 27001:2022 の附属書Aでも、ログ取得（8.15）や監視活動（8.16）が管理策として示されています。監査では、監視の対象と閾値、アラートを受け取る担当と対応時間、ログの保存期間とアクセスできる者を確認します。ログを保存していても、改ざんできる権限を持つ者が限定されていなければ、証拠としての信頼性が下がります。セキュリティ監視の観点はサイバーセキュリティ監査の進め方も参照してください。
運用手順書と属人化
運用管理の弱点は、特定の担当者の経験に頼っていることです。夜間の異常終了にいつも同じベテランが対応し、判断の基準が本人の頭の中にしかない状態では、その人が不在のときに誤った再実行が起きます。監査では、主要なジョブの異常時の対応手順、バックアップからの復元手順、障害時の連絡網が文書化され、最新の構成に合わせて更新されているかを確認します。
手順書の有無だけでなく、実際に使われているかも確かめます。直近の障害対応の記録と手順書を読み比べ、手順どおりに対応したか、手順書にない判断が行われていないかを見ると、手順書が生きているかどうかが分かります。担当者の交代時に引継ぎの記録が残っているか、夜間・休日の当番体制と連絡手段が現実に機能しているかも、ヒアリングだけでなく当番表や連絡記録で確認します。
委託先・クラウドに任せている運用
運用業務をデータセンター事業者やクラウド事業者、運用委託先に任せている場合、実施基準の「外部委託に関する契約の管理」と組み合わせて評価します。委託先の統制は、SOC 1 報告書（Type 2）などで評価できる場合がありますが、報告書には通常、利用者側で実施すべき統制（相補的なユーザー統制）が記載されています。ジョブ結果の確認や、復元依頼の承認などが利用者側の責任とされていれば、その統制は自社で監査する必要があります。報告書の読み方はITGCとSOC報告書の見方で解説しています。
よくある失敗と対策
失敗1：バックアップの取得ログだけで「有効」と結論する
復元テストの記録がない場合、復元できるかどうかは分かりません。少なくとも重要なシステムについて、復元テストの実施と所要時間の記録を求めます。
失敗2：障害記録の中だけでサンプルを選ぶ
記録された障害だけを見ても、記録漏れは発見できません。ジョブの実行結果やアラートの一覧など、別の情報源から異常を抽出し、障害記録と突き合わせます。
失敗3：ジョブ定義の変更を変更管理の対象外にしている
ジョブのスケジュールや条件の変更は、処理結果を変える変更です。変更管理の対象に含まれているか、手続の定義を確認します。
失敗4：データ補正の承認をIT部門内で完結させている
補正の要否と内容は、データの持ち主である業務部門が確認すべきものです。業務部門の確認記録がない補正は、補正そのものが誤っていても検出されません。
失敗5：SaaSのバックアップを事業者任せと決めつける
事業者のバックアップが利用者の求めで復元できるとは限りません。契約とサービス仕様を確認し、必要に応じて自社側の補完策を求めます。
よくある質問
Q1. 復元テストはどのくらいの頻度で行うべきですか？
基準で一律の頻度が定められているわけではなく、システムの重要度や変更の頻度に応じて自社で決めます。重要なシステムでは少なくとも年 1 回、大きな構成変更の後にも実施する運用がよく見られます。監査では、頻度そのものより、方針で定めた頻度が守られ、結果が評価されているかを確認します。
Q2. J-SOXの評価では、運用管理のどこまでを見ればよいですか？
財務報告に関連するシステムのジョブ管理（特に財務データの連携・計算）、バックアップと復旧、障害時のデータ補正が中心になります。評価の範囲と方法は、自社の評価方針と監査人との協議で決めます。
Q3. 障害とセキュリティインシデントはどう区別すればよいですか？
原因が故障や設定誤りか、攻撃や不正かによって扱う窓口や報告経路が変わります。ただし発生直後には区別がつかないことも多いため、障害として受け付けた事象がセキュリティインシデントの疑いを持つ場合に、担当部署へ引き渡す基準を決めておくことが大切です。インシデント対応の監査はインシデント対応態勢の監査で扱います。
Q4. 小規模なIT部門で職務分離が難しい場合はどうすればよいですか？
ジョブ定義の変更や、バックアップの削除ができる担当者が 1 人しかいない場合は、変更履歴や操作ログを別の責任者が定期的に確認する発見的な統制で補う方法があります。自社の運用管理の成熟度はITGC簡易診断の運用管理領域（4 設問）で確認できます。
まとめ
IT運用管理の監査は、「平常時に処理を正しく回すこと」と「異常時に正しく戻すこと」の両方を確かめる作業です。ジョブ管理では変更の承認・結果の監視・異常後の判断を、バックアップでは復旧目標と復元テストを、障害管理では記録の網羅性・財務影響の判断・根本原因への対処を見ます。委託先やクラウドに任せている部分でも、自社側の統制は残ります。
次の一歩として、財務報告に関連するシステムを 1 つ選び、直近の復元テストの記録と、ジョブ異常終了の通知先を確認してみてください。ITGC全体の弱点はITGC簡易診断で把握できます。関連記事として変更管理の監査手順、アクセス管理の監査手順、システム開発・導入プロジェクトの監査もご覧ください。
IT運用管理の監査プログラムの整備について支援が必要な場合は、お問い合わせからご相談ください。
参考資料
- 金融庁 企業会計審議会「財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準の改訂について（意見書）」（2023年4月7日）https://www.fsa.go.jp/news/r4/sonota/20230407/20230407.html
- 経済産業省「システム管理基準」（2023年4月26日）
- 経済産業省「システム管理基準 追補版（財務報告に係るIT統制ガイダンス）」（2024年12月25日）
- ISO/IEC 27001:2022「Information security, cybersecurity and privacy protection — Information security management systems — Requirements」
- ISO/IEC 27002:2022「Information security, cybersecurity and privacy protection — Information security controls」
