5.2運用・保守の統制評価

システムは稼働後こそ長期間運用され、日々のジョブ実行・プログラム変更・障害対応・バックアップが継続します。監査人は、これらの運用・保守プロセスにコントロールが整備され、記録（証跡）が残り、実際に運用されているかを評価します。特に、緊急対応の名のもとに承認や記録を省いた変更が横行していないか、バックアップが取得されるだけでなく復旧できることが検証されているかといった、運用現場で形骸化しやすい統制の実効性を、証跡を証拠として確かめる視点が問われます。

5.2.1運用・保守の主要統制

• 変更管理＝本番環境へのプログラム／設定変更を、要求→影響分析→承認→テスト→適用→記録という手順で統制する仕組み。監査人は変更要求書と承認証跡を証拠として査閲し、承認を経ない変更（無統制変更）が本番に反映されていないかを評価する。緊急変更についても、事後でよいので承認・記録の手続が定められ、実際に運用されているかを確かめる。
• 構成管理＝ハードウェア・ソフトウェア・設定の構成情報を正確に把握・維持する統制。監査人は構成情報が実態と一致しているか（台帳と現物の突合）を確かめ、不整合があれば発見統制の欠如や運用の形骸化を疑う。ジョブ管理＝バッチジョブの実行スケジュール・依存関係・異常終了時の再実行手順が定義され、実行結果（ログ）が監視されているか。
• インシデント管理＝障害の検知・記録・対応・再発防止を統制する仕組み。監査人はインシデント記録が漏れなく残り、重大度に応じたエスカレーションと恒久対策が実施されているかを評価する。バックアップ＝データの定期取得だけでなく、取得したバックアップから実際に復旧できることの検証（リストアテスト）と、遠隔地保管等の設計が重要。

あるシステム監査人が、基幹システムの運用部門を対象に変更管理統制の運用状況を評価しているとします。規程上は「本番プログラムの変更はすべて変更要求書を起票し、影響分析と責任者承認を経てから適用する」と定められており、整備（デザイン）は妥当に見えました。しかし監査人が、直近半年の本番反映記録と変更要求書を突合したところ、障害対応を理由とする「緊急変更」の多くが、変更要求書も事後承認の記録も残さないまま本番に反映されていたことが判明しました。監査人はこれを、規程は整備されているのに実際にはその通り運用されていない運用上の不備と診断します。ただし、緊急時に平時と同じ事前承認をすべて求めるのは障害復旧を遅らせ現実的でないため、監査人はデザインの否定ではなく、緊急変更に特化した統制の実効化を勧告します。具体的には、緊急変更は現場判断で先に適用してよいが、適用後一定時間内に必ず変更要求書を起票し、責任者の事後承認と影響の事後レビューを受けるという手順を明文化し、かつこの事後承認が漏れていないかを変更ログと承認記録の定期突合（発見統制）で監視することを提言します。あわせて、バックアップ統制についても「毎日取得している」という運用担当者の説明を鵜呑みにせず、監査人は実際にリストアテストの記録が残っているかを証拠として確かめ、取得ログはあるが復旧検証の証跡が無い場合は「復旧可能性が担保されていない運用上の不備」として指摘します。このように、規程の存在だけで有効と判断せず、証跡を証拠として運用の実効性を確かめ、緊急変更や復旧検証のように形骸化しやすい統制を実効化することが、運用・保守のコントロール評価における監査人の判断です。

5.2.2この節のまとめ

• 監査人は変更管理を変更要求書と承認証跡の突合で評価し、緊急変更で承認・記録が省かれる運用上の不備を診断する
• バックアップは取得だけでなくリストアテストで復旧可能性を検証していることを証跡で確かめる
• 構成管理は台帳と現物の突合で実態一致を確認し、乖離は発見統制の欠如や運用の形骸化として指摘する