システム監査技術者 2012年 午後1 問03
システム障害の再発防止の監査に関する次の記述を読んで、設問1~4に答えよ。
ネット証券会社のE社では、近年、システム障害が多発している。中には、長時間、取引ができなくなるなど、顧客に大きな影響を与えたものもあった。E社は、これまでにも社長の指示で、システム障害の低減に向けて、設計段階及びテスト段階でのレビュー体制の強化など、ソフトウェアの品質向上に取り組んできた。しかし、システム障害の件数は期待ほどには減少していない上に、過去と同様のシステム障害も発生している。
このような状況を打開するために、社長は監査部に対してシステム障害の再発防止に向けたシステム監査を実施するよう指示した。監査部では、幾つかのチームに分けて監査を実施することになり、D君は、システム障害の記録・分析、及び分析結果に基づいた再発防止の取組みが適切に行われているかどうかを監査するチームのリーダに任命された。
〔予備調査〕
監査チームのメンバは、D君の指示を受けて、まず、システム障害の対応に関わる体制、手順などが記載された“システム障害管理要領”の内容を確認した。その結果は、次のとおりである。
(1) 利用部門の担当者がシステム障害を発見した場合は、ヘルプデスクに連絡する。ヘルプデスクは、過去の障害対応が記録されているデータベースを参照するなどして対応する。その結果、問題を解決できた場合は、そこで障害対応を完了する。
(2) ヘルプデスクで問題を解決できないが、システム障害の切分けができている場合は、ヘルプデスクから、ハードウェア、ネットワーク、アプリケーションなどの各保守チームのうち、該当する保守チームに対応を依頼する。一方、システム障害の切分けができていない場合は、障害の切分けを担当する監視チームに連絡する。
(3) 監視チームは、ヘルプデスクから依頼されたシステム障害の切分け、及び自らが行う監視業務において確認されたシステム障害の切分けを行い、該当する保守チームに対応を依頼する。
(4) 保守チームは、障害対応が完了すると、ヘルプデスク及び監視チームに対して、完了報告と、利用部門が行うべき措置などを連絡する。関係する利用部門には、ヘルプデスクを通じて同様の連絡が行われる。
(5) 保守チームは、システム障害の原因分析及び再発防止策の検討を行った後、“システム障害報告書”を作成する。システム障害報告書の内容は、システム運用責任者、ヘルプデスク及び保守チームのリーダ、ベンダなどが参加する月次ミーティングにおいて報告され、原因分析や再発防止策の適切性などについて協議される。再発防止策は、システム運用責任者が、当該ミーティングでの結果を受けて、システム障害報告書に承認者として署名した後、実施される。
(6) 再発防止策の実施状況や有効性の確認は、その後の月次ミーティングで行われる。
また、予備調査では、発生したシステム障害の原因、再発防止策などが記録されたシステム障害報告書をサンプリングで20件確認した。表1は、監査で確認されたシステム障害報告書の例である。
〔本調査に向けた監査チームの検討会〕
監査チームでは、予備調査の結果を受けて本調査に向けた検討会を開いた。検討会において、D君は今回の監査で設定した次の監査要点に基づいて、意見を述べた。
(1) 監査要点
(ア)システム障害が、漏れなくシステム障害報告書に記載されていること
(イ)システム障害報告書の記載項目及び記載内容が、必要かつ十分であること
(ウ)システム障害の原因分析の結果が、再発防止策を検討するために十分かつ妥当であること
(エ)システム障害の原因及び再発防止策が、関係者間で協議・決定されていること
(オ)再発防止策が権限者の承認後に実施されていること
(カ)実施した再発防止策の有効性が検証されていること
(2) D君の意見
① 監査要点(ア)について、予備調査の結果から、システム障害報告書に記載されないシステム障害が存在する可能性がある。本調査では、この点について確認する必要がある。
② 監査要点(イ)について、システム障害報告書の書式には、監査要点(オ)を確認するために必要な項目が抜けている。したがって、監査要点(オ)については、他の方法で確認する必要がある。
③ 監査要点(ウ)について、表1に記載されている障害の原因には、障害発生の根本原因が示されておらず、それに基づいた再発防止策だけでは不十分である。本調査では、根本原因が何かを調査する必要がある。
④ 監査要点(エ)及び(オ)について、システム障害管理要領に記載された手順では“対応できないケース”が発生する可能性がある。この点について、当該ケースが発生した場合の手順などを記載した文書が存在するかどうかを確認する必要がある。
設問1:
問題文を見るD君の意見①について、システム障害がシステム障害報告書に記載されない可能性があるケースを30字以内で述べよ。
模範解答
障害が保守チームに報告されず、対応が完了したケース
解説
解答の導き方
-
問われているのは、システム障害が発生していても、正式なシステム障害報告書に記載されない可能性があるケースです。障害対応の流れのうち、報告書の作成につながらない経路を探します。
-
手順(1)では、ヘルプデスクが過去の障害対応記録を参照するなどして問題を解決した場合、「そこで障害対応を完了する」とされています。この経路では、その後に保守チームへ対応を依頼する手順に進みません。
-
一方、手順(5)では、保守チームが原因分析と再発防止策の検討を行った後に、システム障害報告書を作成するとされています。つまり、ヘルプデスクだけで対応が完了し、保守チームに障害が伝わらない場合、報告書を作成する保守チームの手続に乗らない可能性があります。
-
したがって、障害が保守チームに報告されず、ヘルプデスクで対応が完了したケースが該当します。
誤りやすいポイント
- 「障害対応が完了した」ことだけに注目し、対応を完了したのがヘルプデスクか保守チームかを区別しないことです。
- ヘルプデスクが過去の対応記録を参照することと、今回の障害についてシステム障害報告書が作成されることを同じだと考えることです。
- 報告書を作成する主体が保守チームである点を見落とし、ヘルプデスクで解決した障害も必ず報告書に記載されると判断することです。
FAQ
Q: ヘルプデスクが障害対応を完了した場合、システム障害報告書は必ず作成されますか?
A: 本文の手順では、報告書を作成するのは原因分析などを行った保守チームです。ヘルプデスクだけで対応が完了し、保守チームに連絡されなければ、報告書作成につながらない可能性があります。
A: 本文の手順では、報告書を作成するのは原因分析などを行った保守チームです。ヘルプデスクだけで対応が完了し、保守チームに連絡されなければ、報告書作成につながらない可能性があります。
Q: 監視チームが切り分けを行う経路も、今回のケースに当たりますか?
A: 監視チームは切り分け後に該当する保守チームへ対応を依頼します。報告書作成につながらない可能性を示す中心的な経路は、ヘルプデスクで問題が解決し、その場で対応が完了する場合です。
A: 監視チームは切り分け後に該当する保守チームへ対応を依頼します。報告書作成につながらない可能性を示す中心的な経路は、ヘルプデスクで問題が解決し、その場で対応が完了する場合です。
関連キーワード: インシデント管理、ヘルプデスク、エスカレーション、障害報告書
設問2:D君の意見②について、(1)、(2)に答えよ。
設問2(1)
問題文を見る監査要点(オ)を確認するために、システム障害報告書に追加すべき項目を二つ挙げ、それぞれ20字以内で述べよ。
模範解答
①:承認者が承認を行った日付
②:再発防止策が実施された日付
解説
解答の導き方
監査要点(オ)で確認するのは、再発防止策が「権限者の承認後」に実施されたかどうかです。そのため、承認と実施の両方について、いつ行われたかを確認できる必要があります。
システム障害管理要領には、システム運用責任者がシステム障害報告書に承認者として署名した後に、再発防止策を実施するとあります。一方、表1の報告書には承認者の署名欄はありますが、承認した日付を記入する項目はありません。署名だけでは、実施より前に承認したかどうかを時系列で確認できないため、承認日を記録する項目が必要です。
また、表1には「実施予定日」がありますが、これは予定を示すもので、実際に実施した日付ではありません。予定日だけでは、再発防止策が実施されたことや、承認後に実施されたことを確認できません。したがって、実際の実施日を記録する項目も必要です。
誤りやすいポイント
- 承認者の署名があれば承認時期も分かる、と考えてしまうことです。署名欄だけでは、承認日と実施日の前後関係を確認できません。
- 「実施予定日」を実施日の記録として扱うことです。予定日と実際に実施した日は区別する必要があります。
- 承認日だけ、または実施日だけを追加すればよいと考えることです。承認後の実施を確かめるには、両方の日付が必要です。
FAQ
Q: 承認者の署名があるのに、なぜ承認日も必要なのですか?
A: 署名から承認者は確認できますが、承認された時期までは分かりません。承認日と実施日を比較することで、承認後に実施されたかを確認できます。
A: 署名から承認者は確認できますが、承認された時期までは分かりません。承認日と実施日を比較することで、承認後に実施されたかを確認できます。
Q: 実施予定日を記録していれば、実施日の項目は不要ですか?
A: 不要ではありません。予定日は実施の計画を示すものであり、実際に実施されたことを示す記録ではありません。
A: 不要ではありません。予定日は実施の計画を示すものであり、実際に実施されたことを示す記録ではありません。
Q: 日付を記録するだけで、承認が権限者によるものかも確認できますか?
A: 日付だけでは確認できません。承認者の記録と、承認者が権限者であることの確認を組み合わせて判断します。
A: 日付だけでは確認できません。承認者の記録と、承認者が権限者であることの確認を組み合わせて判断します。
関連キーワード: 内部統制、承認記録、実施記録、監査証跡、職務分掌
設問2(2)
問題文を見る表1において、監査要点(オ)を確認するための手続を45字以内で述べよ。
模範解答
月次ミーティングの議事録で開催日及び出席者を確認し、パッチ適用のシステム日付と比較する。
解説
解答の導き方
-
監査要点(オ)で確かめるのは、再発防止策が「権限者の承認後」に実施されたかどうかです。したがって、承認が行われた時期と、再発防止策を実施した時期の前後関係を確認する必要があります。
-
手順では、システム障害報告書の内容を月次ミーティングで協議し、その結果を受けてシステム運用責任者が承認者として署名した後、再発防止策を実施するとされています。この流れから、月次ミーティングの開催日と出席者を確認すれば、協議の時期や、承認権限をもつシステム運用責任者が出席していたかを確認できます。
-
一方、表1には再発防止策の実施予定日はありますが、実際にパッチを適用した日を示す項目はありません。予定日だけでは、実施済みであることや、実施時期を確認できません。そのため、パッチ適用のシステム日付を確認します。
-
月次ミーティングの議事録で開催日と出席者を確認し、パッチ適用のシステム日付と照合することで、協議後にパッチが適用されたかを確かめられます。監査手続では、このように議事録と実施記録を突き合わせます。
誤りやすいポイント
- 表1の実施予定日を、実際の実施日として扱わないようにします。予定と実績は別の証拠で確認します。
- 承認者の氏名や署名だけでは、承認と実施のどちらが先かは分かりません。時期の確認が必要です。
- 月次ミーティングの開催日だけでなく、出席者も確認します。承認権限をもつシステム運用責任者が出席していたかが、手順に沿った確認の手掛かりになります。
FAQ
Q: なぜ月次ミーティングの議事録を確認するのですか?
A: システム障害報告書の内容や再発防止策を協議した時期と出席者を確認できるからです。
A: システム障害報告書の内容や再発防止策を協議した時期と出席者を確認できるからです。
Q: なぜパッチ適用のシステム日付を確認するのですか?
A: 実施予定日ではなく、実際にパッチを適用した時期を確認するためです。
A: 実施予定日ではなく、実際にパッチを適用した時期を確認するためです。
Q: 何を照合すればよいですか?
A: 議事録に記録された開催日・出席者と、パッチ適用のシステム日付を照合し、実施の前後関係を確かめます。
A: 議事録に記録された開催日・出席者と、パッチ適用のシステム日付を照合し、実施の前後関係を確かめます。
関連キーワード: システム監査、監査証拠、承認統制、変更管理、監査証跡
設問3:
問題文を見るD君の意見③について、根本原因を調査するための手続を50字以内で述べよ。
模範解答
システム担当者にインタビューを行い、最新のパッチを適用しなかった理由を確認する。
解説
解答の導き方
-
設問は、表1に記載された障害について、再発防止策を考えるために「根本原因」を調査する手続を問うています。障害の直接的な原因だけを言い換えるのではなく、なぜその状況が生じたのかを確かめる必要があります。
-
表1には、障害の発生後にベンダが確認したところ、データベースに最新のパッチが適用されていなかったとあります。また、パッチ配布時には情報が通知されていたものの、システム担当者は「当社では同様の障害が発生していないので適用する必要がない」と判断していました。
-
したがって、パッチが未適用だったことだけでは、根本原因の調査として十分ではありません。なぜシステム担当者が適用不要と判断したのか、その判断理由を確認する必要があります。そのため、システム担当者にインタビューを行い、最新のパッチを適用しなかった理由を確認します。
誤りやすいポイント
- 「最新のパッチが適用されていなかった」とだけ述べることです。これは障害につながった状況であり、なぜその状況になったのかを調べる手続ではありません。
- データベースのエラー原因をベンダに再確認することです。表1ではエラーの原因は不明とされていますが、設問が求める根本原因の調査では、パッチを適用しなかった判断に注目します。
- パッチを適用することを調査手続として答えることです。パッチの適用は再発防止策であり、根本原因を明らかにするための調査とは異なります。
FAQ
Q: 「根本原因」と、表1に書かれた「障害の原因」はどう違いますか?
A: 「最新のパッチが適用されていなかった」は障害の発生に関わる状況です。根本原因を探るには、なぜ適用されなかったのか、その判断や対応の理由まで確認します。
A: 「最新のパッチが適用されていなかった」は障害の発生に関わる状況です。根本原因を探るには、なぜ適用されなかったのか、その判断や対応の理由まで確認します。
Q: なぜシステム担当者にインタビューするのですか?
A: 表1には、システム担当者がパッチを適用する必要はないと判断したことが記載されています。その判断に至った理由は、担当者に直接確認するのが適切です。
A: 表1には、システム担当者がパッチを適用する必要はないと判断したことが記載されています。その判断に至った理由は、担当者に直接確認するのが適切です。
Q: ベンダへの確認だけでは不十分なのですか?
A: ベンダへの確認は技術的な障害原因の調査に役立ちます。一方、この事例では、通知されたパッチを適用しなかった理由を確認する必要があるため、システム担当者へのインタビューが必要です。
A: ベンダへの確認は技術的な障害原因の調査に役立ちます。一方、この事例では、通知されたパッチを適用しなかった理由を確認する必要があるため、システム担当者へのインタビューが必要です。
関連キーワード: 根本原因分析、障害分析、パッチ管理、インタビュー、再発防止策
設問4:
問題文を見るD君の意見④について、“対応できないケース”を40字以内で述べよ。
模範解答
再発防止策を月次ミーティング前に実施しなければならないケース
解説
解答の導き方
-
まず、システム障害管理要領で、再発防止策をいつ実施することになっているかを確認します。原因分析と再発防止策の検討を行ってシステム障害報告書を作成し、その内容を月次ミーティングで協議する手順です。
-
さらに、要領には「当該ミーティングでの結果を受けて」システム運用責任者が承認し、「署名した後、実施される」とあります。つまり、定められた手順では、月次ミーティングでの協議と承認を終えてから、再発防止策を実施します。
-
したがって、月次ミーティングを待たずに再発防止策を実施しなければならない場合は、この手順の順序どおりには進められません。そのため、“対応できないケース”は、再発防止策を月次ミーティング前に実施する必要がある場合です。
誤りやすいポイント
- 障害発生後の復旧対応と、再発防止策の実施を混同しないようにします。ここで問われているのは、復旧を急ぐ場合ではなく、再発防止策を実施する時期です。
- 「月次ミーティングで協議する」だけでなく、協議後にシステム運用責任者が承認し、その後に実施するという順序まで読み取る必要があります。
- 再発防止策の有効性確認は、その後の月次ミーティングで行う手順です。今回問われている“対応できないケース”の根拠は、実施前の協議・承認の順序です。
FAQ
Q: 障害を復旧させる対応が月次ミーティング前に必要な場合も、このケースに当たりますか。
A: いいえ。問われているのは障害の復旧ではなく、再発防止策の実施時期です。
A: いいえ。問われているのは障害の復旧ではなく、再発防止策の実施時期です。
Q: なぜ月次ミーティング前の実施が手順に合わないのですか。
A: 要領では、月次ミーティングでの協議結果を受けて承認した後に、再発防止策を実施すると定めているためです。
A: 要領では、月次ミーティングでの協議結果を受けて承認した後に、再発防止策を実施すると定めているためです。
関連キーワード: 障害管理、原因分析、再発防止策、承認プロセス、実施状況確認




