章構成を新カリキュラムに刷新しました。旧構成との対応は移行ガイドをご覧ください。
ストーリー（冒頭プレビュー）
🦉 Episode 4: 直したのに、なぜ怒られる
登場: 🦉 カイロウ（新人）／💼 先輩（IT監査部門）／🏢 千葉部長（クライアントの情報システム部長）
週末に起きたこと
訪問先は、レンタカーの予約サイトを運営する会社だった。週末に予約画面へ誤った料金が表示されるトラブルがあり、原因を確認する打ち合わせに先輩と同席させてもらった。会議室のホワイトボードには、対応にあたった時系列がまだ消されずに残っていた。
千葉部長が経緯を説明してくれた。
🏢「金曜の夜、担当のエンジニアが料金計算の不具合に気づいたんです」
🦉「気づいてから、どうしたんですか」
🏢「その場で直して、すぐ本番の画面に反映させました」
🦉「その日のうちに直せたなら、対応としては早いですよね」
千葉部長は困った顔で首を振った。
🏢「早かったんですが、よかれと思って直したその修正に、別の間違いが混ざっていたんです。本来1,500円引きのはずが、15,000円引きと表示されてしまって、土曜の朝からそのままお客さまの画面に出ていました」
🦉「桁が一つ増えちゃったんですね。それでも、気づいてすぐ直したこと自体は早い対応じゃないんですか」
🏢「私もそう思っていました。でも、直したものを誰も見ないまま出してしまって、土曜の午前中だけで12件も予約が入ってしまったんです」
千葉部長はノートパソコンの画面を開き、修正を反映した記録を見せてくれた。「変更内容」「反映日時」「実施者」の3つの欄が並び、どちらも同じ名前、同じ時刻になっている。承認者の欄は空欄のままだった。
🦉「承認者の欄、何も入っていないんですね」
🏢「休日だったので、確認してくれる人が捕まらなくて。反映を待つより、直してすぐ出すほうが早いと思ったんです」
先輩の一言
先輩は週末の画面キャプチャをめくりながら言った。
💼「直したこと自体は悪くないよ。でも、誰も確かめないまま、そのままお客さんが見る画面に出したのがまずかったんだ」
🦉「一人で直して、一人でそのまま出しちゃったから、間違いに気づく人がいなかったんですね」
💼「そう。急いでいるときほど、一呼吸おいて誰かに見てもらう手順が要るんだよ」
千葉部長がうなずいた。
🏢「土曜の朝、『会員ページの割引表示がおかしいのでは』というお問い合わせが3件届いて、そこで初めて気づいたんです。もっと早く分かっていれば、こんなに広がらなかったのに」
カイロウは問い合わせ一覧の画面をのぞきこんだ。件名にはどれも「表示価格」という文字が並んでいる。
🦉「気づくまでの時間より、広がるスピードのほうが早かったんですね」
🏢「そうなんです。直すこと自体は30分もかからなかったんですけど」
インプット（冒頭プレビュー）
この章の試験での位置づけ
| 項目 | 内容 |
|---|---|
| 所属エリア | Area I：情報システムとデータ管理（Information Systems and Data Management） |
| Blueprint参照 | I-A 情報システム（Information systems） |
| エリア出題比率 | 35%〜45% |
⏱ 読了目安: 約151分（インプット教材のみ・個人差があります）。一度に読み切る必要はありません。キリのよいセクションで区切って進めてください。
Area IはISC試験で最も配点の大きいエリアであり、本章が扱うITガバナンス・変更管理・BCP/DR（事業継続計画・災害復旧計画）はその土台にあたる。
前提知識 --- この章に入る前に、分かっているとラクなこと
| 前提知識 | なぜ必要か |
|---|---|
| 内部統制の3つの目的（財務報告の信頼性・業務の有効性と効率性・法令等の遵守） | COSOの枠組み全体がこの3目的を軸に組み立てられているため |
| システム開発ライフサイクル（SDLC）のおおまかな流れ（要件定義→開発→テスト→本番移行） | 変更管理は「テスト→本番移行」の部分に統制をかける仕組みであるため |
| 「環境」という言葉の意味（開発環境・テスト環境・本番環境という区分） | 変更やパッチの影響範囲は、どの環境への作業かで大きく変わるため。詳細は後の章のアクセス管理で扱う |
| 統制の「整備状況」と「運用状況」という2段階の評価 | ITGCの評価は、規程の有無だけでなく実際に機能しているかまで見るため |
1. なぜこの論点が必要か（Why）
【ISC試験の全体構造とこの章の位置】
Area I：情報システムとデータ管理 ---> Area II：セキュリティ・機密性・プライバシー ---> Area III：SOC業務
（35-45%） （35-45%） （15-25%）
│
├─ I-A 情報システム
│ └─ ITガバナンス・変更管理・BCP/DR ← 今ここ
│
└─ I-B データ管理
架空の商社、アルバトロス商事株式会社で、こんなことがあった。金曜夜、担当者が現場の急ぎの要望を受け、いつもの申請書もテストも省いて会計システムに1行だけ手を加えた。週明け、一部の請求書で税額の端数がずれていることが分かった。悪意はない。むしろ「早く直したい」という善意が、統制の外側で実行されたことが問題だった。
本章が扱うのは、こうした事故を防ぐ仕組みである。誰がITの方向性を決め（ガバナンス）、変更はどう管理され（変更管理・パッチ管理・構成管理）、日々の運用は誰が見張り（IT運用）、最悪の事態にどう立て直すか（BCP/DR）。この4層は1本の線でつながっており、財務諸表の数値のほぼすべてがITシステムを通過する以上、ここが崩れれば後続のすべての統制の前提が揺らぐ。
2. ITガバナンスの土台 --- 誰が舵を切るかを決める仕組み
2-1. ITガバナンスとITマネジメントの違い
続きとアウトプット演習・整理ノートはISC教材（購入者限定）でご覧いただけます。