IT Audit and Assurance Guidelines IT監査・保証ガイドライン 2012年7月1日発行 G1 本書の利用に際しては以下の点につき留意が必要である。 Quality Statement: This Work is translated into Japanese from the English language version of the IT Standards, Guidelines, and Tools and Techniques for Audit and Assurance and Control Professionals by the ISACA® Tokyo Chapter with the permission of ISACA®. The ISACA® Tokyo Chapter assumes sole responsibility for the accuracy and faithfulness of the translation. 品質にかかわる声明： 『情報システムの監査、保証とコントロールの専門家に係る基準、ガイドラインとツール、テクニック』は、 ISACAの許諾を得てＩＳＡCA東京支部が英語版から日本語版へ翻訳する。ＩＳＡCA東京支部が翻訳の 正確性と忠実性に責任を持つと考えられる。 Reservation of Rights: IT Standards, Guidelines, and Tools and Techniques for Audit and Assurance and Control Professionals © 2010 ISACA®. All rights reserved. No part of this publication may be used, copied, reproduced, modified, distributed, displayed, stored in a retrieval system, or transmitted in any form by any means (electronic, mechanical, photocopying, recording or otherwise), without the prior written authorization of ISACA®. 権利の留保： 『情報システムの監査、保証とコントロールの専門家に係る基準、ガイドラインとツール、テクニック』の 全ては、２０１０年にＩＳＡＣＡに留保された権利となる。ＩＳＡＣＡの事前の書面での許可なく、本書のい かなる部分の、使用、複製、再生、改変、配布、表示、検索システムへの組込、いかなる書式あるいはいかな る手段での（電磁的、機械的、写真複製、記録、その他の方法を問わず）送信も行うことができない。 Disclaimer: ISACA® created IT Standards, Guidelines, and Tools and Techniques for Audit and Assurance and Control Professionals (“ Work”) primarily as an educational resource for controls professionals. ISACA makes no claim that use of any of the Work will assure a successful outcome. The Work should not be considered inclusive of all proper information, procedures and tests or exclusive of other information, procedures and tests that are reasonably directed to obtaining the same results. In determining the propriety of any specific information, procedure or test, the controls professional should apply his or her own professional judgment to the specific circumstances presented by the particular systems or information technology environment. 免責事項： ISACAは、 『情報システムの監査、保証とコントロールの専門家に係る基準、ガイドラインとツール、テク ニック』を主にコントロール専門家の教育用として開発した。ISACAは、本書の利用がいかなる成功裡な 結果を保証するとは主張しない。本書には、全ての適切な情報、手続や試験が含まれていると考えられる べきではないし、同等の結果を合理的直接的に得られる他の情報、手続や試験を排除していると考えられ るべきではない。適切な特定情報、手続や試験を決定する際に、コントロール専門家は特定のシステムや 情報技術環境に基づく特定の環境に対しては自らの専門的判断を適用すべきである。 2 目次 目次 G1 他の専門家の作業を使用‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 5 G2 監査証拠の要求‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 9 G3 コンピュータ支援監査技法（CAAT）の使用‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 14 G4 他の組織への情報システム活動のアウトソーシング‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 21 G5 監査ポリシー‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 26 G6 情報システムの監査に係る重要性の概念‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 31 G7 しかるべき専門家としての注意‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 36 G8 監査調書‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 40 G9 例外処理および違法行為に対する監査の検討事項‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 44 G10 監査サンプリング‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 54 G11 広範情報システムコントロールの効果‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 59 G12 組織の関連と独立性‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 66 G13 監査計画におけるリスク評価の使用‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 70 G14 アプリケーションシステムレビュー‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 75 G15 監査計画策定‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 80 G16 企業のITコントロールに関わるサードパーティの影響‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 86 G17 IT監査・保証の専門家の独立性に対する非監査業務の影響‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 95 G18 ITガバナンス‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 102 G19 例外と違法行為 －2002年7月に削除され、G9に統合されたー‥‥‥‥‥‥‥‥‥‥‥‥ 110 G20 報告‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 111 G21 ERPシステムレビュー‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 118 G22 B2C イーコマースレビュー‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 132 G23 システム開発ライフサイクル‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 143 G24 インターネットバンキング‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥151 G25 仮想プライベートネットワークのレビュー‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 164 G26 ビジネスプロセスリエンジニアリング（BPR）プロジェクトレビュー‥ ‥‥‥‥‥‥‥‥‥ 177 G27 モバイルコンピューティング‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 188 G28 コンピュータ法科学‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 195 G29 導入後のレビュー（PIR）‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 204 3 目次 G30 能力‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥213 G31 プライバシー‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥219 G32 IT視点からのビジネス継続計画（BCP）レビュー‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 230 G33 インターネット使用における一般的考慮点‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 242 G34 責任、権限および説明責任‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 258 G35 フォローアップ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 266 G36 バイオメトリックス制御‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 272 G37 構成管理プロセス‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 283 G38 アクセスコントロール‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 290 G39 ＩＴ組織‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 303 G40 セキュリティ管理業務のレビュー‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥315 G41 セキュリティ投資利益率（ROSI）‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 327 G42 継続的保証‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 339 4 G1 他の専門家の作業を使用 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 6 2 監査ポリシー‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 6 3 計画策定‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 7 4 監査作業のパフォーマンス‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 7 5 フォローアップ活動‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 8 6 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 8 G1 他の専門家の作業を使用 1 背景 1.1 基準との関連 1.1.1 基準S13『他の専門家の作業を使用』は、 「情報システム監査人は、適切な場合には、監査のために他の 専門家の作業を使用することを考慮すべきである。」と述べている。 1.1.2 標準S6『監査業務のパフォーマンス』は、 「監査の過程で、情報システム監査人は、監査目的を達成する ために、充分、信頼性のある、関連付けられた証拠を取得すべきである。監査発見事項と結論は、適切な 分析と、この証拠の解釈で裏付けられることになっている。」と述べている。 1.2 COBITとの関連 1.2.1 ME2.5は、 「情報システム監査人は、必要に応じて、第三者レビューを通して内部統制の完全性と有効性 の更なる保証を取得すべきである。」と述べている。このようなレビューは、企業のコンプライアンス部門や、 マネジメントの要求によっては、内部監査により実施されたり、外部監査人やコンサルタントや認証機関に 委託されることもある。監査を実施する個人の資格、例えばCISAR認証、が確保されねばならない。 1.3 ガイドラインの必要性 1.3.1 顧客と供給者の処理の相互依存関係とノンコア活動の外注は、 （内外）情報システム監査人が、被監査環 境の部分が他の独立部門や組織によってコントロール・監査されているということを、しばしば見出すとい うことを意味している。本ガイドラインは、情報システム監査人がこのような状況で、上記基準に整合すべ き方法を設定する。本ガイドラインとの整合は必須ではないが、情報システム監査人は、それからの逸脱を 正当化する覚悟をすべきである。 1.3.2 情報システム監査人は、実施される監査業務や監査品質の潜在的利益を損ない得る制約がある場合は、 監査で他の専門家の作業を使用することを考慮するべきである。これらの例は、実施さるべき仕事の技 術的な性質によって必要な知識、乏しい監査資源、監査の特定分野に関する限られた知識である。 「専門 家」は、外部会計事務所の情報システム監査人、経営コンサルタント、IT専門家、トップマネジメントや情 報システム監査チームにより指定されてきた監査領域の専門家であろう。専門家は、独立性と客観性が維 持されている限り、組織内外を問わない。 2 監査ポリシー 2.1 他の専門家の作業へのアクセス権 2.1.1 情報システム監査人は、他の専門家の作業が情報システム監査目的に関連している場合、監査ポリシーや 監査契約が情報システム監査人のこの作業へのアクセス権を明細に記していることを検証すべきである。 6 G1 他の専門家の作業を使用 3 計画策定 3.1 計画策定の考慮事項 3.1.1 情報システム監査人が監査を実施するに必要な技量や他の力量をもたない場合には、情報システム監査 人は他の専門家からの有効な支援を求めるべきである。しかし、情報システム監査人は実施された作業に 対する充分な知識を持つべきであるが、その専門家と同等の知識水準を持つことまでは期待されるべきで はない。 3.1.2 情 報システム監 査 が 他の専 門 家の 作 業 の 使 用を含んでいる時、情 報システム監 査 人は 、情 報シ ステム監 査 作 業を計画する間、その活 動と情 報システム監 査目的への影 響を考慮すべきである。 計画プロセスが含むべきなのは、 • その他の専門家の独立性と客観性の評価 • 彼らの専門家としての能力と資格の評価 • 作業記録を創成する際に、然るべき注意を行ったかどうかの評価と彼らの作業の証拠の保持を含め、 作業範囲・取組み・時宜・品質管理プロセスの理解の取得 • 必要とされるレビュー水準の決定 3.2 独立性と客観性 3.2.1 選定と任命のプロセス、組織的地位、報告ルート、 マネジメント慣行に対する彼らの推奨事項の影響は、 他の専門家の独立性と客観性の指標である。 3.3 専門家としての能力 3.3.1 他の専門家の資格、経験、資源、成績証明書は、全て専門家としての能力を評価する際に考慮されるべき である。 3.4 作業範囲と取組み 3.4.1 作業範囲と取組みは、通例、その他の専門家の書面による監査ポリシー、参照条件、監査契約により証明 される。 3.5 必要とされるレビュー水準 3.5.1 必要とされる監査証拠の性格、時宜、程度はその他の専門家の作業の重要度と範囲次第である。情報シ ステム監査人の計画プロセスは、全体的情報システム監査目的を有効に達成するために充分、信頼性のあ る、関連付けられた、有用な監査証拠を提供するために必要なレビュー水準を識別すべきである。情報シ ステム監査人は、その他の専門家の最終報告書、監査プログラム、監査調書を見直すべきである。情報シ ステム監査人は、また、その他の専門家の作業の補完テストが必要かどうかを考慮すべきである。 4 監査作業のパフォーマンス 4.1 他の専門家の作業書類のレビュー 4.1.1 情報システム監査人は、アクセスしても法的問題を引き起こさない場合、他の専門家の調書と報告書を裏 付けている、専門家により生成された全作業書類にアクセスすべきである。 4.1.2 記録への専門家のアクセスが、法的な問題を引き起こし、それ故、そのアクセスが不可能な場合、情報シス テム監査人は専門家の作業の使用や信頼性の程度を適切に決定し、結論付けるべきである。 7 G1 他の専門家の作業を使用 4.1.3 他の専門家の作業書類をレビューする時、情報システム監査人は充分な監査作業を実施し、その他の専門 家の作業が適切に計画され、監督され、文書化され、レビューされていたことを確認し、専門家によって提 供された監査証拠の適切性、充分性を考慮し、専門家の作業の使用と信頼性の程度を決定すべきである。 関連する専門家の基準との整合もまた評価されるべきである。情報システム監査人は、他の専門家の作業 が、自分達が現在の監査目的を決定し、その決定を文書化できるだけ、充分であり、完全であるかどうか評 価すべきである。 4.1.4 他の専門家の作業書類の作業の評価に基づいて、情報システム監査人は、他の専門家の作業が充分かつ 適切な監査証拠を提供しない環境の下で、充分かつ適切な監査証拠を取得するための追加テスト手続き を適用すべきである。 4.1.5 実施された追加テスト手続きが充分かつ適切な監査証拠を提供しないならば、情報システム監査人は適 切な監査結論を提供し、必要な場合、範囲の限界を追加すべきである。 4.2 他の専門家の報告書のレビュー 4.2.1 情報システム監査人はその他の専門家の最終報告の充分なレビューを実施し、確認すべきなのは、監査ポ リシーで特定された範囲、参照条件や監査契約が合致していたこと、その他の専門家により使用されたい かなる重要な仮定も識別されていたこと、報告された発見事項、結論がマネジメントにより合意されてきた ことである。 4.2.2 マネジメントは、内部統制というシステムへの彼らの主要な責任を認識して、被監査組織に関する自分達 自身の報告を提供するのは適切かもしれない。この場合において、情報システム監査人はマネジメント報 告と専門家の報告を一緒に考慮すべきである。 4.2.3 情報システム監査人は、その他の専門家により発行された報告書の有用性と適切性を評価し、その他の専 門家により報告された、重要な発見事項を考慮すべきである。情報システム監査人の責任は、全体的な監 査目的に関するその他の専門家の発見事項と結論の効果を評価し、全体的監査目的を満足させるに必要 な追加作業が完了していることを検証することである。 4.2.4 専門家が組織の他部署に雇われたならば、その専門家の報告に信頼が置かれるかも知れない。たとえ情 報システム監査人が裏付けとなる調書や作業書類へのアクセスがなくとも、信頼が情報システム監査範囲 の必要性を減ずる場合がある。情報システム監査人は、このような場合に意見を提供する際には慎重であ るべきである。 4.2.5 専門家の報告書の採用可能性と関連性に関する情報システム監査人の見解／コメントは、専門家の報告 書が情報システム監査人の意見を形成するに当たり利用されるならば、情報システム監査人の報告書の一 部を形成すべきである。 5 フォローアップ活動 5.1 推奨事項の実施 5.1.1 適切な場合、情報システム監査人は、 マネジメントが他の専門家の推奨事項を実施してきた程度を考慮す べきである。これは、 マネジメントが、適切な時間枠の中で他の専門家により識別された問題の修正と、修 正の現状に関わってきたかどうかを評価することを加えるべきである。 6 適用開始日 6.1 本ガイドラインは、1998年6月1日以降に開始される全ての情報システム監査に適用される。 本ガイドラインは2008年3月1日にレビューされ、改訂された。 8 G2 監査証拠の要求 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥10 2 計画‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥10 3 監査作業の効率‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥12 4 報告‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥13 5 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥13 G2 監査証拠の要求 1 背景 1.1 基準との関係 1.1.1 基準S6『監査作業のパフォーマンス』は、 「監査の過程で情報システム監査人は監査の目的を達成するた めに、十分で信頼性のあるかつ適切な証拠を取得すべきである。監査の発見事項と結論は、適切な分析と、 証拠の解釈で裏付けられなければならない。」と述べている。 1.1.2 基準S9『例外処理および違法行為』は、 「情報システム監査人は、経営陣等が組織内で実際の、あるい は疑念のある、あるいは申し立てられた例外処理あるいは違法行為について、判断するために十分かつ適 切な証拠を入手すべきである。」と述べている。 1.1.3 基準S1『他の専門家の作業を利用』は、 「情報システム監査人は、必要な証拠が追加のテスト手続を通じ ても取得できていない対象範囲の制約を含め、適切な監査意見を提供すべきである。」と述べている。 1.1.4 基準S14『監査証拠』は、 「情報システム監査人は、監査結果の基となった合理的な結論を引き出すのに 十分かつ適切な証拠を入手すべきである。情報システム監査人は、監査期間に取得された充分な監査証 拠を評価すべきである。」と述べている。 1.1.5 手続P7『例外処理および違法行為』は、 「情報システム監査人は例外処理を発見し、防ぐことの明示的な 責任はないものの、例外処理が発生するリスクのレベルを評価すべきである。リスクアセスメントの結果と 計画中に実施するその他の手続は、監査業務実施中に行われる手続きの性質、程度および実施時期を決 定するために使用すべきである。」と述べている。 1.2 COBITとの関連 1.2.1 ME2.3『コントロールの例外』は、 「全てのコントロールの例外に関する情報を記録し、根本的な原因の 分析と是正措置につながることを確認すること。経営陣は、どの例外が機能に係る個人の責任へ周知され るべきか、どの例外がエスカレート報告されるべきかについて決定すべきである。」と述べている。 1.3 ガイドラインの必要性 1.3.1 本ガイドラインの目的は、情報システム監査人が十分かつ適切な監査証拠を入手して、監査結果を基に合 理的な結論を引き出すためのものとなる。 1.3.2 本ガイドラインは、情報システム監査基準を適用する際のガイダンスを提供している。情報システム監査人 は、どのように上記の基準の実装を達成するか、適用にあたり専門的な判断を用いるため、そしてガイドラ インからの逸脱を指摘するために備えるかを決めるにあたって、ガイドラインを考慮に入れるべきである。 2 計画 2.1 監査証拠の類型 2.1.1 信頼性の高い適切かつ十分な証拠については、基準S14の解説を参照すること。 2.1.2 情報監査作業を計画するにあたって、情報システム監査人は、収集する監査証拠の種類、監査の目的を満 たす監査証拠の使用と、信頼性のさまざまなレベルが変化することを考慮に入れるべきである。 考慮するものの中には監査証拠を提供するものの独立性と適性がある。例えば独立した第三者から補強 される監査証拠が、監査対象組織から提供される監査証拠よりも信頼性が高いことがある。物理的な監 査証拠は、一般的に個人の説明よりも信頼性が高い。 2.1.3 情報システム監査人は、コントロールのテストが独立した第三者機関によって完了し、認証されたかどうか、 そしてそのテストが信頼できるものかについても、考慮すべきである。 10 G2 監査証拠の要求 2.1.4 情報システム監査人が使用を検討すべき監査証拠の種類には以下のものがある。 • 観測されるプロセスと物理的に存在する項目 • 文書化された監査証拠 • 説明 • 分析 2.1.5 観察プロセスと物理的なアイテムの存在確認は、組織の活動、所有物、情報システム機能の観察に含める ことができる。例えば、 • オフサイト保管場所内のメディアの在庫確認 • 稼動中のコンピュータルームのセキュリティシステム 2.1.6 紙に記録されたあるいは他のメディアに文書化された監査証拠には以下のものを含むことができる。 • データ抽出の結果 • 取引の記録 • プログラムリスト • 請求書 • 活動とコントロールログ記録 • システム開発関連文書 2.1.7 監査を受ける人物からの以下のような説明陳述は、監査証拠とすることができる。 • 記述されたポリシーや手続き • システムのフローチャート • 書面または口頭による陳述 2.1.8 比較、シミュレーション、計算を介した情報分析の結果と推論についても、監査証拠として使用することが できる。例としては、以下を含む。 • 情報システムの他の組織や過去の期間との比較した情報システム能力ベンチマーク • アプリケーション、トランザクション、およびユーザー間のエラー率の比較 2.2 監査証拠の可用性 2.2.1 情報システム監査人は性質、タイミング、実質的なテストの程度と、該当する場合は、コンプライアンステス トを決定するにあたって、中にどのような情報が存在するか利用できるかどうかの時期を考慮すべきである。 例えば、 電子データ交換（EDI）で処理された監査証拠、文書画像処理（DIP）と表計算など動的システムによって 処理される監査証拠は、一定時間経過後、変更履歴の管理を行わない場合や、ファイルのバックアップを 行わない場合には、証拠の検索抽出は出来なくなる。企業の文書保存ポリシーによって、文書化の可用性 も影響を受けることがある。 2.3 監査証拠の選択 2.3.1 情報システム監査人は、最も適切で信頼性の高いかつ十分な監査証拠で、入手可能なもの、および監査目 的の重要性や監査証拠を入手する際の時間や努力に見合ったものを使うことを計画すべきである。 2.3.2 口頭による説明の形で入手した監査証拠が、監査意見や結論に重要なものとなる時は、情報システム監査 人は、紙や他のメディアの形で、説明されたものを文書による確認として入手することを考慮するべきであ る。情報システム監査人は、またその説明の信頼性を確保するためにこれらの説明を裏付ける代替の証拠 検討もすべきである。 11 G2 監査証拠の要求 3 監査作業の効率 3.1 監査証拠の性質 3.1.1 監査証拠は、情報システム監査人の監査発見事項と結論に対する支援意見を形成させるに足る充分で信 頼あるそして関連するものであるべきである。情報システム監査人の判断において、もし監査証跡がこれら の基準に合わない時には、追加の監査証跡を入手すべきである。たとえば、プログラム一覧は、他の監査 証跡が収集され稼働中プロセスで使われる実際のプログラムを表していない状況では、そのプログラム一 覧は正確な監査証跡になっていないと言っても差し支えない。 3.2 監査証拠の収集 3.2.1 監査証拠を収集する際に使われる手続きは、監査されている情報システムによって異なる。情報システム監 査人は、監査の目的に、最も適切で信頼性の高く充分な手続きを選択するべきである。次の手続きを考慮 すべきである。 • 照会 • 観測 • 検査 • 確認 • 再実施 • 監視 3.2.2 上記の手続きは、 マニュアルによる監査手続、コンピュータ支援監査技法、またはその両方の組み合わせ を使用して利用する場合のいずれも適用することができる。例えば、 • 手作業によるコントロールがデータエントリトータルをバランスさせるシステムは、コントロール手続が適 切に調整され報告書に注釈を付ける方法が実施されていることの監査証跡を提供するかもしれない。 • 詳細な取引記録は、情報システム監査人がコンピュータ支援監査技法に基づく監査証跡を入手するた めの機械的読み取り書式にのみ利用可能になっても差し支えない。 • 情報システム監査人は、使用するコンピュータ支援監査技法（CAAT）のバージョンやタイプの最新情 報とする必要があり、対象となる取引の詳細な記録に使われている形式と完全な互換性を確認すべきで ある。 3.2.3 収集された証拠が法的手続の一部として使われることになる可能性がある場合に、情報システム監査人は、 然るべき法律顧問に、証拠の収集、提示、および開示方法について、影響を与える特別な要件があるかど うかを判断するため、相談すべきである。 3.3 監査文書 3.3.1 情報システム監査人が収集する監査証拠は、適切に文書化され、情報システム監査人の発見事項や結論 に役立つよう整備されるべきである。 3.3.2 監査証拠の保全と維持に関しては、基準S14の解説を参照すること。 12 G2 監査証拠の要求 4 報告 4.1 報告対象範囲の制限 4.1.1 情報システム監査人が、十分な監査証拠が入手出来ないと考える場合には、情報システム監査人は、監査 結果の周知において永続的な方法でその事実を開示すべきである。 5 適用開始日 5.1 本ガイドラインは、1998年12月1日以降に開始される全ての情報システム監査に適用される。 本ガイドラインは、2008年5月1日にレビューされ、改訂された。 13 G3 コンピュータ支援監査技法（CAAT）の使用 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥15 2 計画策定‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥16 3 監査業務の実施‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥18 4 CAAT 関連文書‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥19 5 報告‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥20 6 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥20 G3 コンピュータ支援監査技法（CAAT）の使用 1 背景 1.1 基準との関連 1.1.1 基準S6『監査業務のパフォーマンス』は、 「監査の過程において、情報システム監査人は、監査目的を達 成するために、確実で妥当な証拠を十分得るべきである。監査の発見事項と監査の結論は、この証拠を 適切に分析し、解釈することにより裏付けられる」と述べている。 1.1.2 基準S5『計画策定』では、 「情報システム監査人は、監査の目的を満たし、関連諸法規と当該分野の諸 監査基準に準拠するよう、情報システム監査の範囲を定めた計画を策定すべきである」と述べている。 1.1.3 基準S3『専門家としての倫理と基準』では、 「情報システム監査人は、適用可能な専門の監査基準を遵 守することを始めとして、専門家としてのしかるべき注意を払うべきである」と述べている。 1.1.4 基準S7『報告』では、 「情報システム監査人は、報告書に記載した個々の監査結果を裏付けるために必要 な、充分かつ適切な監査証拠を保有しているべきである」と述べている。 1.1.5 基準S14『監査証拠』では、 「情報システム監査人は、監査結果の基となる合理的な結論を導き出すため に、十分かつ適切な監査証拠を入手すべきである」と述べている。 1.2 ガイドラインとの関係 1.2.1 ガイドラインG2『監査証拠の要求』は、情報システム監査人に対して、情報システム監査で用いる監査証 拠の種類と十分性に関するガイダンスを提供している。 1.2.2 ガイドラインG10『監査サンプリング』は、情報システム監査人に対して、監査サンプルのデザインと抽出、 およびサンプルテストの結果の評価に関するガイダンスを提供する。 1.3 COBITとの関連 1.3.1 ME2『内部統制のモニタリングと評価』では、IT関連アクティビティの内部統制プロセスのモニタリング と是正措置の特定に重点をおくことで、IT目標の達成の保証と、IT関連法ならびに規制の遵守という、IT に関するビジネス要件を満足している。 1.3.2 DS5『システムセキュリティの保証』では、ITセキュリティポリシー、手続および基準を定め、セキュリティ上 の脆弱性やインシデントをモニタリング、発見、報告、是正することに重点をおくことで、情報と情報処理 インフラストラクチャのインテグリティの維持と、セキュリティ上の脆弱性やインシデントによる影響を最 小限に抑えるという、ITに関するビジネス要件を満足している。 1.4 ガイドラインの必要性 1.4.1 企業がデータの記録や取引、処理のための情報システム使用を拡大するにつれ、情報システム監査人がリ スクの適切な評価のために情報システムツールを活用することが、監査上不可欠となっている。コントロー ル環境の評価を効率的で効果的に行ううえで、コンピュータ支援監査技法（CAAT）の使用は情報システ ム監査人にとって重要なツールとして機能する。CAATの使用は監査範囲を拡大し、より完全で一環した データ分析を推進し、リスクを低減することができる。 1.4.2 CAATには様々なツールや技法、例えば汎用的な監査ソフトウェア、専用のクエリやスクリプト、ユーティリ ティソフトウェア、アプリケーショントラッキングとマッピング、監査用エキスパートシステムなどが含まれる。 15 G3 コンピュータ支援監査技法（CAAT）の使用 1.4.3 CAATは次のような様々な監査手続を実施する際に使用できる。 • 取引と残高の詳細テスト • 分析的レビュー手続 • 情報システムの全般統制の準拠性テスト • 情報システムの業務処理統制の準拠性テスト • 侵入テスト 1.4.4 CAATは、情報システム監査で作成する多くの監査証拠を作成することができるため、情報システム監査 人はCAATの使用のために念入りに計画し、専門職としての正当な注意を示さなければならない。 1.4.5 このガイドラインは情報システム監査基準の適用に係るガイダンスを提供する。情報システム監査人は、ど のように当該基準の導入を達成し、専門家としての判断に基づいてガイダンスを適用し、またガイダンスか らの離脱を正当化するかの決定において、このガイダンスを検討しなければならない。 1.4.6 監査人が情報システム監査人であるか否かにかかわらず、CAATの使用に際してこのガイダンスを適用しな ければならない。 2 計画策定 2.1 CAAT使用の決定要素 2.1.1 監査計画立案に際して、情報システム監査人は手作業の技法とCAATの適切な組合せを検討しなければな らない。CAATを使用すべきかの決定における検討要素には次が含まれる。 • コンピュータの専門知識・スキルおよび情報システム監査人の経験 • 適切なCAATおよび情報システム設備の使用可否 • 手作業の技法と比較したCAAT使用の効率性および有効性 • 期間の制約 • 情報システムとIT環境におけるインテグリティ • 監査リスクの水準 2.2 CAAT計画策定手順 2.2.1 選択したCAATの適用準備において情報システム監査人が実施すべき主要な手順には次が含まれる。 • CAATの監査目的を設定する（通常業務指示書に記載される） • 組織の情報システム設備、プログラム、システム、データへのアクセスと使用について決定する • 対象データの量、タイプ、フォーマットおよびレイアウトなどの構成を明確に把握する • 実施する手続（例：統計的サンプリング、再計算、確認）を定義する • 出力要件を定義する • 資源要件、すなわち人材、CAAT、処理環境（組織の情報システム設備や監査に係る情報システム設備） を決定する • 組織の情報システム設備、プログラム／システムおよびデータ、ファイル定義へのアクセス権を取得する • 使用するCAATについて、目的、概要フローチャート、実行指示とともに文書化する 2.3 被監査者との準備 2.3.1 CAATを適切に設計し、データを理解するためには、データオーナやユーザに十分な時間をとってもらう必 要がある。加えて、被監査者はCAATの意義、スコープ、実施時期および目的について理解する必要がある。 CAATの実施に際して期待するところを明確に伝える必要がある。 16 G3 コンピュータ支援監査技法（CAAT）の使用 2.3.2 詳細な取引ファイルのようなデータファイルは短期間しか保存されていないことが多い。このため、情報シ ステム監査人は適切な期間をカバーするようにデータの保存について調整する必要がある。 2.3.3 組織の情報システム設備、プログラム／システムおよびデータへのアクセスは、できれば組織の本番環境 への影響を最小限にとどめるよう、必要な期間に十分に先立って調整する必要がある。 2.3.4 情報システム監査人はCAATの使用により本番プログラム／システムへもたらされるかもしれない変更の 影響について評価する必要がある。その際、情報システム監査人はこれらの変更がCAATのインテグリ ティと有用性に与える影響について、情報システム監査人が使用するプログラム・システムおよびデータの インテグリティ同様に検討する必要がある。 2.4 CAATのテスト 2.4.1 適切な計画、設計、テスト、処理および文書のレビューを通じて、CAATのインテグリティ、信頼性、有効 性およびセキュリティについて、情報システム監査人が合理的保証を得ることが重要である。これはCAAT に依拠する前に実施しておく必要がある。テストの内容、実施時期および範囲は使用するCAATの普及度 合いや安定性による。独自開発したCAATについては、期待通りに稼動するか確かめるために追加的なレ ビューとテストを実施する必要がある。 2.5 データおよびCAATのセキュリティ 2.5.1 データ分析のためにCAATを使用して情報を抽出する際には、情報システム監査人はデータを抽出する情 報システムおよびIT環境のインテグリティを検証する必要がある。 2.5.2 CAATは機密保持が必要なプログラム／システムの秘密情報や本番データを抽出することもできる。情報 システム監査人は、適切なレベルの機密性とセキュリティの下にプログラム／システム情報や本番データ を正しく保護するために設定された会社のデータの分類およびデータ取扱ポリシーを明確に理解する必 要がある。その際、情報システム監査人はデータを所有する組織が要求する機密性とセキュリティのレベ ル、ならびに関連法令を考慮する必要があり、かつ必要に応じて弁護士や経営者などと協議する必要があ る。 2.5.3 情報システム監査人はCAATの継続的なインテグリティ、信頼性、有効性、セキュリティのための適切な手 続の実施結果を使用し、文書化する必要がある。例えば、これには承認された変更のみがCAATに行われ たか判断するための、組み込み監査ソフトウェアのプログラム保守とプログラム変更に係るコントロールの レビューを含める必要がある。 2.5.4 CAATが情報システム監査人のコントロール下にない環境におかれている場合には、CAATの変更を識別 するため、適切なレベルのコントロールが実施される必要がある。CAATが変更された場合には、情報シス テム監査人はCAATに依拠する前に、適切な計画、設計、テスト、処理、文書のレビューにより、CAATのイ ンテグリティ、信頼性、有効性およびセキュリティについて保証を得る必要がある。 17 G3 コンピュータ支援監査技法（CAAT）の使用 3 監査業務の実施 3.1 監査証拠の収集 3.1.1 監査目的とCAATの詳細仕様が整合していることの合理的保証を得るために、CAATの使用は情報システ ム監査人がコントロールする必要がある。情報システム監査人は次のことをする必要がある。 • 該当する場合、コントロールトータルの照合の実施 • 結果の合理性のレビュー • CAATのロジック、パラメータあるいは他の特性のレビューの実施 • 組織の情報システムの全般統制のレビュー。これはCAATのインテグリティに貢献する（例：プログラム 変更に係るコントロール、およびシステム、プログラム、データへのアクセス） 3.1.2 テストデータを使用する場合、情報システム監査人はテストデータだけでは実際の本番データを評価して いないため、誤った処理となる可能性があることを認識する必要がある。また、処理する取引の数、テスト 対象のプログラムの数およびプログラム／システムの複雑性によっては、テストデータの分析は非常に複 雑で時間を要することがあるということも、情報システム監査人は認識する必要がある。情報システム監査 人はテストデータを使用する前に、テストデータが本番システムに恒久的に影響を及ぼさないことを確認し ておく必要がある。 3.2 汎用監査ソフトウェア 3.2.1 汎用監査ソフトウェアを使用して本番データにアクセスする場合には、情報システム監査人は組織のデー タインテグリティを保護するために適切な手順を踏む必要がある。組み込みソフトウェアを使用する場合 には、情報システム監査人はシステム設計に関与する必要があり、また適用技法は組織のアプリケーショ ンプログラム／システムとして開発、保守する必要がある。 3.3 ユーティリティソフトウェア 3.3.1 ユーティリティソフトウェアを用いる場合には、情報システム監査人は処理中に予期せぬ介入が発生しな いことと、使用するユーティリティソフトウェアが適切なシステムライブラリから入手されていることを確認 する必要がある。ユーティリティはシステムやファイルに簡単に損傷を与えてしまうことがあるため、情報シ ステム監査人は組織のシステムとファイルのインテグリティを保護するために適切な手順を踏む必要があ る。 3.4 専用のクエリやスクリプト 3.4.1 専用のクエリやスクリプトを作成することで情報システム監査人は分析に必要な情報に具体的に的を絞る ことができる。他のCAATは使用できないが、特定の技術スキルがあれば技法を構築できるような環境に おいては、専用のスクリプトは非常に便利である。そのため、情報システム監査人は、CAATに依拠する前 に適切な計画、設計およびテストによって、スクリプトのインテグリティ、信頼性、有効性およびセキュリ ティについて保証を得るとともに、適切なソースデータが使用されることと、スクリプトやクエリの出力が 適切な形式であることを確認する必要がある。専用のクエリやスクリプトコードは、無許可の変更を防止す るため、安全な場所に保管する必要がある。 3.5 アプリケーショントラッキングとマッピング 3.5.1 アプリケーショントラッキングとマッピングを使用する場合、情報システム監査人は、評価するソースコー ドが現在本番で使用されているオブジェクトプログラムを生成したものであることを確認する必要がある。 情報システム監査人はアプリケーショントラッキングとマッピングだけでは実際の本番データを評価してい ないため、誤った処理となる可能性があることを認識する必要がある。 18 G3 コンピュータ支援監査技法（CAAT）の使用 3.6 監査用エキスパートシステム 3.6.1 監査用エキスパートシステムは、アプリケーションソフトウェアの処理ロジックに従ってデータフローを分 析し、ロジック、パス、コントロール条件、処理順序を文書化する際に使用可能な専門ツールである。監査 用エキスパートシステムを使用する際には、情報システム監査人は、条件判断経路が対象の監査環境・状 況に適合していることを確認するために、システムのオペレーションに精通している必要がある。 3.7 継続的モニタリングと保証 3.7.1 継続的保証とは、経営者および情報システム監査人が継続的にコントロールをモニタし、コンピュータか ら監査証拠を収集することを可能とする不断のモニタリングアプローチをいう。これは情報システム監査 人による即時（あるいはそれに近い）報告に使用可能なプロセスであり、リスクが高く、大規模な環境にお いて有用なプロセスである。 （内部および外部監査人が適用する）現状の監査モデルにおいては、現場作 業の完了と関連する監査報告書の発行の間には一定の期間がかかっている。多くの場合、この発行の遅 延は、報告書に記載された情報を使用者にとって有用性の低い、役立たないものにしてしまっている。これ は、報告書に記載された情報が、識別された不備に対して被監査者が訂正を行ったり、識別されたコント ロールの欠陥や不備によりコントロール環境（あるいは関連する被監査者のデータ）が劣化していること などの問題に影響を受けて、経時変化してしまった結果である。 3.7.2 それゆえ継続的保証では、情報システム監査人が現状モデルよりもずっと短期間で主題について報告する ことを可能とすべくデザインされている。理論的には、ある種の環境においては、報告基幹をほぼ即時とす る、あるいは真に継続的保証を提供することが可能となる。 3.7.3 定義によれば、継続的保証は伝来的な監査において要求している以上に被監査者の情報システムへの依 拠を高めることを要請している。これは、監査のテストの基本として、システム生成情報と外部情報のいず れに依拠すべきかの結果である。それ故、監査人は被監査者のシステムの品質ならびに当該システムが生 成する情報について判断をしなければならない。高品質で信頼できる情報を生成するシステムに比べ、品 質が低かったり、信頼性の低い情報しか生成できないシステムは（、多くの手作業による介在を要するた め）、継続的保証には適していない。 3.7.4 高品質で信頼性の高い情報を生成する環境は、短期間ないし継続的な報告を行うのににより適している。 低品質あるいは生成される情報の信頼性が低い環境では、ユーザがシステムの処理した情報をレビューし、 承認あるいは訂正する時間がかかるため、報告までにより長い期間が必要となる。 4 CAAT関連文書 4.1 監査調書 4.1.1 適切な監査証拠を提供するためにCAATのプロセスは順を追って十分に文書化する必要がある。 4.1.2 特に監査調書には、以下の節で述べる詳細を含めてCAATのアプリケーションについて説明する十分な文 書を含める必要がある。 4.2 計画の策定 4.2.1 文書には次を含める必要がある。 • CAATの目的 • 使用するCAAT • 実施されるコントロール • 配員および実施時期 19 G3 コンピュータ支援監査技法（CAAT）の使用 4.3 実施 4.3.1 文書には次を含める必要がある。 • CAATの準備およびテスト手続とコントロール • CAATで実施するテストの詳細 • 入力（例：使用するデータ、ファイルレイアウト）、実施時期、処理（例：CAATの概要フローチャート、ロ ジック）、および出力（例：ログファイル、レポート）の詳細 • 関連するパラメータやソースコードの一覧 4.4 監査証拠 4.4.1 文書には次を含める必要がある。 • 生成した出力 • 出力について実施した監査上の分析作業の記述 • 監査検出事項 • 監査の結論 • 監査上の勧告 4.4.2 使用したデータとファイルは安全な場所に保管する必要がある。加えて、監査の一環で使用した一時的な 機密データは、企業のデータ取扱手続に従って適切に処分する必要がある。 5 報告 5.1 CAATの記述 5.1.1 目的、範囲および手法に係る報告書の節には使用したCAATに関する明確な記述を含める必要がある。こ の記述は過度に詳細なものとせず、読者が適切に概要を把握できるものとする必要がある。 5.1.2 使用したCAATの記述は、報告書の本文においてCAATの使用に関連する特定の発見事項について論じ る箇所にも含める必要がある。 5.1.3 使用したCAATの記述がいくつかの検出事項に関連する、あるいは記述が詳細すぎる場合には、報告書の 目的、範囲および手法の節で概説したうえで、詳細記述については報告書の付属書類を参照するようにす べきである。 6 適用開始日 6.1 本ガイドラインは、1998年12月1日以降に開始される全ての情報システム監査に適用される。 本ガイドラインは2008年3月1日にレビューされ、改訂された。 20 G4 他の組織への情報システム活動の アウトソーシング 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥22 2 監査ポリシー‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥22 3 計画策定‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥23 4 監査業務のパフォーマンス‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥24 5 報告‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥25 6 フォローアップ‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥25 7 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥25 G4 他の組織への情報システム活動のアウトソーシング 1 背景 1.1 基準との関連 1.1.1 基準S1『監査ポリシー』は、 「情報システム監査機能の目的、責任、権限、説明責任は、監査ポリシーまた は監査契約書に適切に文書化されている必要がある。」と述べている。 1.1.2 基準S5『計画策定』は、 「情報システム監査人は、監査の目的を満たし、適用可能な法規と専門の監査 基準に準拠するよう、情報システム監査の範囲を定めた計画を策定すべきである。」と述べている。 1.1.3 基準S6『監査業務のパフォーマンス』は、 「監査の過程において、情報システム監査人は、監査の目的を 達成するために、十分かつ確実で関連性のある証拠を入手すべきである。監査の発見事項と監査の結論 は、この証拠を適切に分析し、解釈することにより裏付けられる。」と述べている。 1.2 ガイドラインとの関連 1.2.1 ガイドラインG16は、組織の情報システムのコントロールおよび関連するコントロール目標にサードパー ティが及ぼす影響を評 価するにあたり、情報システム監査人がISACA情報システム監査基準および COBITへどのように準拠すべきかを示している。 1.3 COBITとの関連 1.3.1 DS2『サードパーティのサービスの管理』は、 「サードパーティの役割および実行責任が明確に定義され、 要件を継続的に満たすためにサービスユーザが整備しているビジネス要件に関連するコントロールを情報 システム監査人が確認すべきである。」と述べている。 1.4 ガイドラインの必要性 1.4.1 組織（サービスユーザ）は、情報システム活動の一部あるいはすべてを外部業者（サービスプロバイダ） に委託することがある。サービスプロバイダは、常駐してサービスユーザのシステムを使用する場合だけで なく、遠隔地において自社のシステムを使用する場合もある。アウトソースされる情報システム活動には、 データセンタ運用、セキュリティおよびアプリケーションシステムの開発や保守等の情報システムの機能 が含まれる。 1.4.2 契約、合意および規制へのコンプライアンスを確認する責任はサービスユーザに留まる。 1.4.3 監査権は不明確となっていることがある。コンプライアンス監査を実施する際の責任もまた明確となって いないことがある。本ガイドラインの目的は、情報システム監査人がこのような状況において基準S1、S5 およびS6へどのように準拠すべきかを詳述することである。 1.4.4 本ガイドラインは、情報システム監査基準を適用する際のガイダンスを提供する。情報システム監査人は、 上記基準の実施を実現する方法を検討する際に本ガイドラインを検討するとともに、その適用においては 専門家としての判断を用い、いかなる逸脱も正当化できるように準備しておかなければならない。 2 監査ポリシー 2.1 責任、職務権限および説明責任 2.1.1 情報システムの機能がサービスプロバイダにアウトソースされる場合、これらのサービスは監査ポリシーの 範囲に含められるべきである。 22 G4 他の組織への情報システム活動のアウトソーシング 2.1.2 監査ポリシーには、以下のような情報システム監査人の権限を明確に含めるべきである。 • サービスユーザとサービスプロバイダの間で締結された合意をレビュー（事前および事後）すること • アウトソースされた機能に関して、必要と考えられる監査業務を実施すること • 発見事項、結論および勧告事項をサービスユーザのマネジメントへ報告すること 3 計画策定 3.1 調査業務 3.1.1 情報システム監査人は、アウトソースされるサービスの種類・時期・程度を理解すべきである。 3.1.2 アウトソースされるサービスに関連するリスクは、特定され評価されるべきである。 3.1.3 情報システム監査人は、ビジネス目標が達成され、また、望ましくない事象が予防、あるいは発見および是 正されるとの合理的な保証をサービスユーザのコントロールがどの程度与えることができるのかを評価す べきである。 3.1.4 情報システム監査人は、サービスプロバイダ（あるいは再委託先のサードパーティ）の責任となるコント ロールおよびサービスユーザに責任が留まるコントロールを理解すべきである。 3.1.5 情報システム監査人は、サービスプロバイダの監査に関して、アウトソーシング契約にどこまで定められて いるのかを確認し、この条項が適切かどうかを検討すべきである。この検討には、サービスプロバイダの内 部監査人、あるいはサービスプロバイダが契約した独立したサードパーティのどちらかにより実施された情 報システム監査業務にどの程度依拠できるのかの評価も含まれる。 3.2 計画策定 3.2.1 情報システム監査人は、計画策定段階において、サービスプロバイダに対する監査権の程度および条件に 関して契約およびサービスレベルアグリーメント（SLA）をレビューする際には、専門家に法的助言を求め ることを検討すべきである。 3.2.2 情報システム監査人は、計画策定段階に入手した情報を考慮しながら、サービスプロバイダに向けた前回 の監査報告書を評価し、サービスプロバイダの環境に関連する監査目標に対応する情報システム監査業 務を計画すべきである。 3.2.3 情報システム監査人は、アウトソーシングの形態およびそれが監査アプローチに与える影響を検討すべき である。 • 労働力のアウトソーシング（一般的なオフショアモデル）： –– 労働力のみが提供される。サービスユーザの内部統制およびビジネスプロセスに変更はない。サービ スプロバイダは、サービスを提供するにあたり、サービスユーザのIT環境に完全に依存する。 –– 情報システム監査人は、サービスユーザの既存のITコントロールおよびSLAを補完する追加的なコン トロールのテストを計画すべきである。 • 労働力およびシステムのアウトソーシング：（一般的なオンショアモデル） –– サービスプロバイダは、自社のIT環境を利用してサービスを提供する（例えば、給与計算のアウトソー シング）。 –– 情報システム監査人は、資格要件を満たした独立したサードパーティにより実施されたコントロール のテストに関するドキュメント（例えば、SAS70 Type II 報告書）をサービスプロバイダが提供可能 か、また、サードパーティによるテストの対象となる目標が情報システム監査人の監査目標に適用可能 かを検討すべきである。 3.2.4 監査目標は、サービスプロバイダに通知される前にサービスユーザのマネジメントと合意されるべきである。 サービスプロバイダの依頼に基づくいかなる変更もサービスユーザのマネジメントと合意されるべきである。 23 G4 他の組織への情報システム活動のアウトソーシング 3.2.5 情報システム監査人は、業務の程度および目標を決定する際に、アウトソーシングに関連する国際認証、 あるいはフレームワークおよび国際標準化機構が定める要件を検討すべきである。この検討に基づき、情 報システム監査人はサービス組織が取得した国際認証にどの程度まで依拠できるのかを決定すべきであ る。 3.2.6 情報システム監査人は、サービスユーザの環境において実施されるかのように、適用可能な専門的な監査 基準に従って情報システム監査業務を計画すべきである。 4 監査業務のパフォーマンス 4.1 監査要件 4.1.1 監査は、サービスがサービスユーザの情報システム環境において提供されているかのように実施されるべ きである。 4.2 サービスプロバイダとの合意 4.2.1 情報システム監査人は、以下の事項を検討すべきである。 • サービスプロバイダとサービスユーザとの間で締結された正式な契約の存在 • アウトソーシング契約において、サービスプロバイダが自社の活動に適用されるすべての法的な要件を満 たし、また、サービスユーザの代理として実施する機能に関連する法規制を遵守する義務を負っているこ とを明確に定めた条項が含まれていること • アウトソーシング契約において、サービスプロバイダにより実施される活動がサービスユーザにより実施 されるかのようにコントロールおよび監査の対象となる旨の具体的かつ強制力のある条項が含まれてい ること • サービスプロバイダとの契約において、サービスユーザの内部監査メンバーおよびサービスユーザの監 査を実施するサードパーティの双方の監査権が含まれていること • SLAへのコンプライアンスをモニタリングすること、また、インシデント、あるいはコントロールの欠陥を 積極的に報告することをサービスプロバイダに要求する条項が含まれていること • パフォーマンスのモニタリング手続を含むSLAが存在すること • サービスユーザがセキュリティポリシーを遵守すること • サービスプロバイダの身元保証保険の付保が適切であること • 重要な業務の職務分離を含むサービスプロバイダの人事に関する方針や手続が適切であること • サードパーティへの業務の再委託およびSLAに対する再委託先のパフォーマンスのモニタリングに関す るサービスプロバイダの方針や手続が適切であること • 災害時におけるサービスプロバイダの業務継続能力が適切であること 4.3.1 情報システム監査人は、以下の事項を検証すべきである。 • SLAへのコンプライアンスをモニターするために利用される情報を生成するビジネスプロセスが適切に 管理されていること。サービスユーザがサービスプロバイダから提供されるサービスレベルへのコンプラ イアンスに関する標準的な情報を受け入れるべきであったのか、あるいはサービスプロバイダと同意した 追加的な報告要件を追加すべきであったのか。 • SLAが満たされていない場合には、サービスユーザが是正を要求し、双方で合意したサービスレベルを 達成するための是正処置を検討していること • 提供されるサービスのフォローアップおよびレビューを行う能力をサービスユーザが有していること 24 G4 他の組織への情報システム活動のアウトソーシング 4.4 監査範囲の制限 4.4.1 サービスプロバイダが情報システム監査人に対して協力的でない場合には、情報システム監査人は当該事 項をサービスユーザのマネジメントへ報告すべきである。これには、サービスプロバイダが契約上の監査権 が適用されないサードパーティに再委託している業務も含まれるかもしれない。 5 報告 5.1 報告書の発行と合意 5.1.1 情報システム監査人は、監査業務完了時に正規の受領者であるサービスユーザに適切な書式で報告書を 提出すべきである。 5.1.2 情報システム監査人は、提出前にサービスプロバイダと報告書について討議することを検討すべきである が、情報システム監査人には最終報告書をサービスプロバイダに提出する責任はない。サービスプロバイダ が報告書の複写を受け取る場合には、通常、サービスユーザのマネジメント経由で受け取るべきである。 5.1.3 報告書には、情報システム監査人、あるいはサービスユーザのマネジメントが合意した報告書の配布に関 する制限を明記すべきである。例えば、サービスプロバイダが報告書の複写を情報システム監査人の組織 および（適切な場合には）サービスユーザの同意なしにサービスプロバイダが提供するサービスの他の利 用者へ提供できないようにすべきである。情報システム監査人は、サードパーティに対する責任を除外する 文言を含めることも検討すべきである。 5.2 監査範囲の制限に関する報告 5.2.1 監査報告書には、監査権が否定された場合には、監査範囲の制限を明確に記載し、この制限が監査に及 ぼす影響を明らかにすべきである。 6 フォローアップ 6.1 前回の監査結果のフォローアップ 6.1.1 情報システム監査人は、監査がサービスユーザの環境で行われたかのように、前回の監査における関連す る発見事項、結論および勧告事項に関して、サービスユーザおよびサービスプロバイダの双方に対して適 切な情報を提供するよう依頼すべきである。情報システム監査人は、サービスプロバイダにより適時適切 に是正処置が講じられているかを確認すべきである。 7 適用開始日 7.1 本ガイドラインは、1999年9月1日以後に開始される全ての情報システム監査に適用される。 本ガイドラインは、2008年5月1日にレビューされ、改訂された。 25 G5 監査ポリシー 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥27 2 監査ポリシー‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥27 3 監査契約‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥29 4 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥30 G5 監査ポリシー 1 背景 1.1 基準との関連 1.1.1 基準S1『監査ポリシー』は、 「情報システム監査部門や情報監査業務の責任・権限・説明責任は監査ポリ シーや監査契約に適切に文書化されるべきである。」と述べている。 1.2 COBITとの関連 1.2.1 ME4.7『独立した保証』は、 「取締役会に、一般に受容される実践例同様、方針・基準・手続きとともにIT の準拠性に関し独立した保証を提供する。」と述べている。 1.2.2 ME2.5『内部統制の保証』は、 「必要に応じて、第三者監査を通じて内部統制の完全性や有効性に関す る更なる保証を得よ。」と述べている。 1.3 ガイドラインの必要性 1.3.1 本ガイドラインの目的は、情報システム監査人が、情報システム監査部門の責任・権限・説明責任を識別 すべく監査ポリシーを準備するのを補助することである。本ガイドラインは、主として、内部情報システム 監査部門に向けられている。しかし、側面は、他の事情を考慮することができる。 1.3.2 本ガイドラインは、情報システム監査基準を適用する際の手引きを提供する。情報システム監査人は、上 記基準の実装を達成し、適用にあたって専門家としての判断を利用し、いかなる逸脱をも正当化する覚悟 をする方法を決定するに当たり手引きを考慮すべきである。 2 監査ポリシー 2.1 権限 2.1.1 情報システム監査人は情報システム機能を実行するために、明確な権限を持っている必要がある。この権 限は、通常、正式に受け入れられるべき監査ポリシーに文書化されている。監査ポリシーが、全体として監 査機能のために存在する場合には、情報システム監査の権限が組み込まれるべきである。 2.2 監査ポリシーの内容 2.2.1 監査ポリシーは、明確に目的・責任・権限・責任の4つの側面に的を絞るべきである。考慮する側面は、次 の節に記載されている。 2.2.2 目的： • 役割 • 目的/目標 • 業務記述書 • 範囲 • 目的 27 G5 監査ポリシー 2.2.3 責任： • 運営方針 • 独立性 • 外部監査との関係 • 被監査人要件 • 重要成功要因 • 重要成果達成指標 • リスク評価 • パフォーマンスの他の測定 2.2.4 権限： • 監査パフォーマンスに関連した情報・人事・場所・システムへのアクセス権 • 範囲や範囲の制限 • 被監査部門 • 被監査人の期待 • 取締役会と上級マネジメントへの報告ルートを含めた組織構造 • 情報システム監査スタッフの格付け 2.2.5 説明責任： • 上級マネジメントへの報告ルート • 業務パフォーマンス評価 • 人員パフォーマンス評価 • スタッフィング/経歴開発 • 被監査人の権利 • 独立した品質レビュー • 基準への準拠の評価 • ベンチマークパフォーマンスと機能 • 監査計画の完了評価 • 予実比較 • 合意された行動、例、いずれの当事者も責任を果たせない場合の罰則 2.3 被監査人との意思疎通 2.3.1 被監査人との有効な意思疎通とは、 • 業務・業務範囲・業務可用性・配信の適時性について説明する • 入手可能な場合は費用の見積りや予算を提供する • 問題とそれらの可能な解決策を説明する • 効果的な意思疎通のため、充分かつ容易にアクセスできる設備を提供する • 提供される業務および被監査人の必要性との関係を決定する 28 G5 監査ポリシー 2.3.2 監査ポリシ－は被監査人との健全な意思疎通を形成し、次のようなサービスレベルアグリーメントへの参 照を含むべきである。 • 非計画作業のための可用性 • 報告の配信 • コスト • 被監査人の苦情への対応 • 業務の質 • パフォーマンスの評価 • 被監査人との意思疎通 • 必要性評価 • コントロールリスクセルフアセスメント • 監査の参照条件の合意 • 報告プロセス • 発見事項の合意 2.4 品質保証プロセス 2.4.1 情報システム監査人は、情報システム監査機能に関連する被監査人のニーズと期待を理解すべく品質保証 プロセス（例えば、面接・顧客満足度調査・業務パフォーマンス調査）を設立することを考慮すべきである。 これらのニーズは、業務を改善したり、必要に応じて業務の提供または監査ポリシーを変更するために監 査ポリシーに照らして評価されるべきである。 3 監査契約 3.1 目的 3.1.1 監査契約は、個々の業務のためや、外部情報システム監査と組織の間の関係の範囲や目標を設定するた めによく使用される。 3.2 内容 3.2.1 監査契約は明らかに責任・権限・説明責任の三側面に的を絞るべきである。考慮する側面は、次の項に記 載されている。 3.2.2 責任： • 範囲 • 目的 • 独立性 • リスク評価 • 特定被監査人要件 • 成果物 3.2.3 権限： • 業務パフォーマンスに関連する、情報・人事・場所・システムへのアクセス権 • 範囲や範囲の制限 • 監査業務の条件への合意の証拠 29 G5 監査ポリシー 3.2.4 説明責任： • 報告の正式受信者 • 被監査人の権利 • 品質レビュー • 合意の完了日 • 可能な場合、合意された予算/手数料 4 適用開始日 4.1 本ガイドラインは、1999年9月1日以降に開始される全ての情報システム監査に適用される。 本ガイドラインは、2008年2月1日にレビューされ、改訂された。 30 G6 情報システムの監査に係る重要性の概念 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥32 2 ガイドラインの必要性‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥33 3 計画策定‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥33 4 報告‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥35 5 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥35 G6 情報システムの監査に係る重要性の概念 1 背景 1.1 基準との関連 1.1.1 基準S5『計画策定』は、 「情報システム監査人は、監査目的に対処し、適用される法律および専門職とし ての監査基準に準拠する情報システム監査範囲を計画すべきである。」と述べている。 1.1.2 基準S10『ITガバナンス』は、 「情報システム監査人は、法律・環境・情報品質・受託者責任・セキュリティ に関わる要件への準拠状況をレビュー、評価すべきである。」と述べている。 1.1.3 基準S12『監査の重要性』は、 「情報システム監査人は、監査手続の種類・時期・範囲を決定する際に、 監査の重要性と監査リスクとの関係を考慮すべきである。監査を計画する際に、情報システム監査人は、 コントロールの潜在的な欠陥や欠如、そして、その種のコントロールの欠陥や欠如が情報システムにとって 重要な不備や重大な欠陥になりうるかどうかを考慮すべきである。情報システム監査人は、結果的に情報 システムの重要な不備や重大な欠陥に変化する小さなコントロールの不備や欠陥とコントロールの欠如の 累積的影響を考慮すべきである。」と述べている。 1.1.4 基準S19『例外処理と違法行為』は、 「もし情報システム監査人が、 マネジメントや内部統制上重要な役割 を果たしている従業員が絡む、重大な例外処理や違法行為を識別したり、重大な例外処理や違法行為が 存在するかも知れないという情報を入手している場合、情報システム監査人は、時宜を失わず、適切なマネ ジメントにこれらの事項を報告すべきである。」と述べている。 1.2 COBITとの関連 1.2.1 PO5『IT投資の管理』は、 「継続的かつ明白に改善しているITのコスト効率と、それが、効果的かつ効率的 なIT投資とポートフォリオの決定に焦点を当て、IT戦略と投資決定に沿ったIT予算を設定・追跡することに よって、エンドユーザの期待に応える統合・標準化された業務で事業収益に貢献する。」というITに関する ビジネス要件を満足している。 1.2.2 AI1『コンピュータ化対応策の明確化』は、 「技術的に実現可能で費用効率の良い施策の識別に焦点を当 てることにより、業務機能的要件・コントロール要件を、コンピュータ化対応策の効果的・効率的設計へ 変化させる。」というITに関するビジネス要件を満足している。 1.2.3 DS10『問題管理』は、 「運用上の問題を記録・追跡・解決することに焦点を当てることにより、施策と サービス提供の不備と手直しを削減したり、全ての重要問題の根本原因を調査したり、識別された運用上 の問題の施策を明確にする、サービス提供やサービスレベルによってエンドユーザの満足を確実にする。」 というITに関するビジネス要件を満足している。 1.2.4 DS13『オペレーション管理』は、 「データインテグリティを維持したり、予定されたデータ処理に対し運用 上のサービスレベルに合わせたり、機微情報の出力を保全したり、インフラストラクチャをモニタリング・保 守することに焦点を当て、ITインフラストラクチャが誤謬や破損に耐え、それらから回復しうることを確保す る。」というITに関するビジネス要件を満足している。 1.2.5 ME4『ITガバナンスの提供』は、 「IT戦略・パフォーマンス・リスクに関し、取締役会報告の準備に焦点を 当てて、法令遵守したり、取締役会の監督に沿ったガバナンスの要件に対応する、企業のガバナンス目標 にITガバナンスを統合する。」というITに関するビジネス要件を満足している。 1.2.6 個別の監査範囲に適用可能であるCOBITの中から最も関連する材料の選定は、特定のCOBIT『ITプロセ スとCOBITのコントロール目的と関連するマネジメントの実行の勘案』の選択に基づいている。情報システ ム監査人による情報システム監査の重要性の概念に合わせるべく、最も関連し、選定され、採用されそう なCOBITのプロセスが、次のように、主要・副次的なものに分類される。選定され、採用されるべきプロセ スとコントロール目的は、特定の範囲と任務の権限次第で変化するかもしれない。 32 G6 情報システムの監査に係る重要性の概念 1.2.7 副次的参照： • PO8 品質管理 • PO9 ITリスクの評価と管理 • AI2 アプリケーションソフトウェアの調達と保守 • AI3 技術インフラストラクチャの調達と保守 • AI4 運用と利用の促進 • AI5 IT資源の調達 • AI6 変更管理 • DS3 パフォーマンスとキャパシティの管理 • DS5 システムセキュリティの保証 • DS9 構成管理 • ME1 ITパフォーマンスのモニタリングと評価 • ME2 内部統制のモニタリングと評価 1.2.8 監査の重要性に最も関連する情報要請規準： • 主：機密性、インテグリティ、コンプライアンス、信頼性 • 副：有効性、効率性、可用性 2 ガイドラインの必要性 2.1 情報システム監査対会計監査 2.1.1 会計監査人と異なり、情報システム監査人は重要性を測定するため別の基準を必要とする。会計監査人 は、監査するものが、また、金額で測定・報告されるので、通常、重要性を、金額で測定する。情報システム 監査人は、通常、物理的アクセスコントロール、論理的アクセスコントロール、プログラム変更管理および、 人事管理・製造コントロール・設計・品質管理・パスワード生成・クレジットカードの作成・患者の世話の ためのシステムのような、非財務項目の監査を実行する。従って、情報システム監査人は、自らの監査を効 率的に計画するための重要性評価方法、高リスク分野に取組みを集中する方法、発見した誤謬や欠陥の 重大さを評価する方法に関する手引を必要とするかも知れない。 2.1.2 本ガイドラインは、情報システム監査基準を監査の重要性に適用する際も手引を提供する。情報システム 監査人は、上記基準の実施を達成する方法を考慮し、適用に当たっての専門職としての判断を用い、いか なる逸脱も正当化する覚悟をすべきである。 3 計画策定 3.1 重要性評価 3.1.1 何が重要であるかを評価するというのは、専門職の判断に関わる問題であり、監査される分野のコント ロールの欠陥の結果として出来するかも知れない誤謬・遺漏・例外処理・違法行為の場合にビジネス目標 に合致する事ができる組織の能力に及ぼす影響や潜在的影響を考慮することを含んでいる。 3.1.2 重要性を評価する際、情報システム監査人が考慮すべきなのは、 • マネジメント、情報システム監査人、適切な規制機関、他の利害関係者にとって許容可能な誤謬の合算 レベル • 軽微な誤謬や欠陥が累積することにより重大となる可能性 33 G6 情報システムの監査に係る重要性の概念 3.1.3 監査目標に合致させるために、情報システム監査人は関連するコントロール目標を識別すべきであり、リス ク許容率に基づき、検証すべきものを決定すべきである。特定のコントロール目標に関しては、重要なコン トロールとは、それがないと、コントロール手続が、コントロール目標が合致しているという合理的保証を 提供できないコントロールのことである。 3.1.4 情報システム監査目標が金融取引を処理するシステム・運用に関連する場合、情報システム監査を実施す る際に、会計監査人の重要性の評価基準が考慮されるべきである。 3.1.5 情報システム監査人は、機密性・可用性・インテグリティの観点からの情報資産の分類、権限管理に基づ くアクセスコントロール規則、重要度と暴露リスクに基づく情報の分類と同様、役割と責任の確立を決定 すべきである。評価が含めるべき検証は、 • 格納されている情報 • 情報システムハードウェア • 情報システムアーキテクチャとソフトウェア • 情報システムネットワークインフラストラクチャ • 情報システムオペレーション • 開発環境とテスト環境 3.1.6 情報システム監査人は、いかなるITの一般的不備も潜在的に重大となリ得るかどうかを決定するべきであ る。そのような不備のあるIT全般統制の重要性は、関連付けられている業務処理統制も有効ではないかど うか、と言った、業務処理統制への影響に関連して、評価されるべきである。もしアプリケーションの不備 が、IT全般統制によって引き起こされているならば、それらは重大である。たとえば、もしアプリケーション による税額計算に大きな誤りがあり、それが税率表に対する不充分な変更管理によって引き起こされたな らば、アプリケーションによるコントロール（計算）および全般統制（変更）は、大いに弱いものである。 3.1.7 情報システム監査人は、業務処理統制と、集約された時に他のコントロールの不備に対しての影響に関連 してIT全般統制の不備を評価すべきである。例えば、IT全般統制の不備と、統制環境に関する関連する反 映を是正しないというマネジメントの意思決定は統制環境に影響を及ぼす他のコントロールの不備と合算 された場合、重大になる可能性がある。 3.1.8 情報システム監査人は、また、不備を修正しないことが重大になりうるということにも留意すべきである。 3.1.9 情報システム監査人は、自分達が組織内で認識している現存する重大な欠陥を開示したということを認め る署名を適切な利害関係者から取得することを考慮するべきである。 34 G6 情報システムの監査に係る重要性の概念 3.1.10 以下は、重要性を評価する際に考慮すべき評価基準の例である。 • システムや運用によって支援されるビジネスプロセスの重要度 • システムや運用によって支援されている情報データベースの重要度 • 開発されたアプリケーションの数と種類 • 情報システムを利用するユーザの数 • 権限別に分類された情報システムを利用して仕事をする管理者と役員の数 • システムや運用によって支援されているネットワーク通信の重要度 • システムや運用（ハードウェア・ソフトウェア・スタッフ・サードパーティのサービス・間接費またはこれら の組合せ）の費用 • 誤謬による潜在的費用（逸失販売・保証請求・回収不能の開発費用・警告のために必要な広告費・改 修費用・衛生安全費用・不必要に高い生産費・高減耗等の観点） • 再生産するための金銭と時間という観点での重大かつ致命的な情報の損失費用 • 対応策の有効性 • 1期間に処理されるアクセス・トランザクション・引合いの数 • 準備されている報告書と維持されているファイルの種類・時期・程度 • 取扱品の種類・数量（在庫移動時に金額なしに記録される場合等） • サービスレベルアグリーメントの要件および潜在的な罰則金 • 法令・契約上の要件への不履行に対する罰則 • 公衆衛生安全の要件への不履行に対する罰則 3.1.11 コントロール不全は、企業イメージの低下だけでなく、金銭的損失・競争上の地位の低下・信頼喪失・評判 の喪失につながる可能性があるかもしれない。情報システム監査人は、対応策に対するリスクを評価すべ きである。 4 報告 4.1 報告すべき問題の識別 4.1.1 報告すべき発見事項、結論、勧告を決定する際に、情報システム監査人は、発見した誤謬の重大性と、コ ントロールの欠陥の結果引き起こされうる誤謬の潜在的重大性の両方を考慮すべきである。 4.1.2 監査が、 マネジメントにより情報システムのコントロールに関する保証書を得るために利用される場合、コ ントロールの妥当性に関する無限定適正意見は、コントロールが、コントロール目標に合致するために、一 般に受容されたコントロール慣行に従っており、重大なコントロールの欠陥がないということを意味するべ きである。 4.1.3 コントロールの欠如により、コントロール目標が達成されるという合理的な保証を提供することができな いならば、コントロールの欠陥は重大であり、それ故、報告されるべきものと考慮すべきである。監査作業 により、重大なコントロールの欠陥が識別された場合には、情報システム監査人は、監査目標に対し、限 定付適正意見や不適正意見を提出することを考慮すべきである。 4.1.4 監査目標によっては、情報システム監査人は、 マネジメントに対して、特にコントロール強化費用が低い場 合、重大でない欠陥を報告することを考慮すべきである。 5 適用開始日 5.1 本ガイドラインは、1999年9月1日以降に開始される全ての情報システム監査に適用される。 本ガイドラインは、2008年5月1日レビューされ、改訂された。 35 G7 しかるべき専門家としての注意 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥37 2 監査作業のパフォーマンス‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥38 3 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥39 G7 しかるべき専門家としての注意 1 背景 1.1 基準との関連 1.1.1 基準S3『専門家としての倫理と基準』は、 「情報システム監査人は監査業務を実施するに当たりISACA の職業倫理規定に固執すべきである」と述べている。 1.1.2 基準S3『専門家としての倫理と基準』は、 「情報システム監査人は適用さるべき専門家としての監査基準 の遵守を含め、しかるべき専門家としての注意を払うべきである」と述べている。 1.1.3 基準S2『独立性』は、 「監査に関連する全ての事項において、情報システム監査人は、態度でも外観でも 被監査人に対し、独立性を保つべきである」と述べている。 1.1.4 標準S4『専門家としての能力』は、 「情報システム監査人は、監査業務を遂行する技量と知識を有し、専 門家として能力を備え、適切な継続的専門教育および訓練を通じて専門家としての能力を維持すべきであ る」と述べている。 1.1.5 情報システム監査人は、追加の手引として上記基準の中にある解説部分を参照すべきである。 1.2 COBITとの関連 1.2.1 PO6『マネジメントの意図と手引の周知』は、 「正確で理解しうる承認された方針・手続・手引・ガイドライ ン・ITコントロールフレームワークに組み込まれた利害関係者への他の文書を提供することに重点を置く ことにより、現在および将来のIT業務・関連リスク・責任に関する正確で時宜を得た情報。」というITに関 するビジネス要件を満足している。 1.2.2 PO7『IT人材の管理』は、 「人材の雇用と訓練、明快な経歴経路を通じて動機付け、技量に相応しい役割 の割り振り、定義付けされたレビュープロセスの確立、職務記述書の生成、個人への依存の認識を確実に することに重点を置くことにより、IT業務を生成・提供すべく、能力があり動機付けされた人達。」というIT に関するビジネス要件を満足している。 1.2.3 PO9『ITリスクの評価と管理』は、 「ビジネスやオペレーショナルリスク管理フレームワーク・リスク評価・ リスク軽減・残存リスクの周知に統合されるリスク管理フレームワークの開発に重点を置くことにより、IT リスクとビジネスプロセスと目標に及ぼす潜在的影響を分析・周知する。」というITに関するビジネス要件 を満足している。 1.2.4 ME3『規制に対するコンプライアンスの保証』は、 「全ての法令・契約と対応するITコンプライアンスを 識別し、コンプライアンス違反のリスクを低減すべくITプロセスを最適化することに重点を置くことにより、 法令と契約要件に対するコンプライアンスの保証。」というITに関するビジネス要件を満足している。 1.2.5 ME4『ITガバナンスの提供』は、 「IT戦略・パフォーマンス・リスクに関する取締役会報告を準備したり、取 締役会の指示に沿ってガバナンスの要求事項に応えることに集中し、ITガバナンスをコーポレートガバナン スの目標に統合し、法令と契約の遵守。」というITに関するビジネス要件を満足している。 37 G7 しかるべき専門家としての注意 1.2.6 副次的参照： • PO1 IT戦略計画の策定 • PO5 IT投資の管理 • PO8 品質管理 • PO10 プロジェクト管理 • AI1 コンピュータ化施策の明確化 • AI6 変更管理 • DS3 パフォーマンスとキャパシティの管理 • DS7 ユーザの教育と研修 • DS9 構成管理 • DS10 問題管理 1.2.7 最も関連する情報要請規準： • 主：信頼性・機密性・インテグリティ・コンプライアンス・効率性 • 副：有効性・可用性 1.3 ガイドラインの必要性 1.3.1 本ガイドラインの目的は、情報システム監査基準の基準S3を遵守した監査のパフォーマンスに適用される ように、 「しかるべき専門家としての注意」という用語を明確にすることである。 1.3.2 メンバーとISACAの認定者は、ISACA職業倫理規定を遵守することが期待される；履行できない場合は、 メンバー／ISACA認定者の行動を調査することになり、必要に応じて、最終的には懲戒処分につながるか も知れない。 1.3.3 本ガイドラインは、情報システム監査基準を適用し、しかるべき専門家としての注意をもって、職務を遂行 する上で、ISACA職業倫理規定を遵守する際に手引を提供する。情報システム監査人は、上記基準の実 施を達成する方法を決定する際に、手引きを考慮し、適用する際に専門家としての判断を用い、いかなる 逸脱も正当化できるように準備するべきである。 2 監査作業のパフォーマンス 2.1 しかるべき専門家としての注意 2.1.1 しかるべき注意の基準は、慎重で能力のある専門家がある状況の下に行使するであろう努力のレベルであ る。しかるべき専門家としての注意は、情報システム監査のような特別な技量を行使することを職とする個 人に適用される。しかるべき専門家としての注意は、その個人がその専門分野の実務従事者が一般に保有 する水準までその技量を発揮することを求めている。 2.1.2 しかるべき専門家としての注意は、遂行される作業の実施過程において専門家としての判断の行使に適 用される。しかるべき専門家としての注意は、専門家は、適切な努力を払って専門家としての判断を必要と する事項に当たることを意味する。 38 G7 しかるべき専門家としての注意 2.1.3 しかるべき専門家としての注意は、監査リスクの評価ばかりでなく、監査業務・監査目的の公式化・監査 範囲の確立・監査計画・監査実施・監査への資源分配・監査テストの選択・テスト結果の評価・監査の文 書化・監査結論・報告・監査結果の配布を含め、監査のあらゆる側面へ拡大すべきである。これを行うに は、情報システム監査が決定・評価すべきなのは、 • －監査目的を満たすために必要とされる監査資源の種類・レベル・技量・能力 • 識別されたリスクの重要性とそのようなリスクが監査に与える潜在的影響 • 収集された監査証拠 • 情報システム監査人が依拠する作業を実施する人の能力・インテグリティ・結論 2.1.4 情報システム監査人はIT監査業務の遂行に関連する全ての事項に対し、精神的独立性と客観性の状態を 維持すべきである。監査人は、監査の論点に取組み、結論に到達する際には、外見的に誠実・公平・不偏 であるべきである。 2.1.5 情報システム監査人は、専門家としての基準と法令規制要求事項に固執しつつ、勤勉に監査を実施すべき である。情報システム監査人は、情報システム監査業務が確立された情報システム基準と他の適切な専門 家としてや、規制や産業の基準に従って完了され、結果として、情報システム監査が専門家としての意見を 述べることができるようになるとの合理的な期待を持つべきである。情報システム監査人は、監査結果の 報告と一貫したやり方により、いかなるコンプライアンス違反の状況も開示すべきである。 2.1.6 情報システム監査人は、 マネジメントが監査業務のパフォーマンスに必要とされる適切で、関連のある、時 宜に合った情報を供給するに当たり義務と責任を理解しているという満足な保証を得て、監査中に関連の ある人の協力を確保すべきである。 2.1.7 情報システム監査人は、高水準の行動と性格を維持しつつ、合法かつ誠実な方法で利害関係者の利益に 奉仕し、専門職への信用を傷つける行為に従事すべきでない。 2.1.8 情報システム監査人は、開示が法的権限により求められない限り、職務上知り得た情報の個人情報保護 と機密性を維持すべきである。このような情報は、個人利得のために利用されるべきではないし、不適切 な者へ公表されるべきでない。 2.1.9 情報システム監査人は、実施した作業の結果を適切な者に報告する際に、しかるべき専門家としての注意 を払うべきである。 2.1.10 監査報告書の正規の受領者は、情報システム監査人が、監査の過程を通じて、しかるべき専門家としての 注意を払ってきたという適切な期待を持っている。情報システム監査人は、充分な技量・知識・他の資源が、 専門家に期待された方法で作業を完了するために利用できない限り、業務を受けるべきではない。 3 適用開始日 3.1 本ガイドラインは、1999年9月1日以降に開始される全ての情報システム監査に適用される。 本ガイドラインは2008年3月1日にレビューされ、改訂された。 39 G8 監査調書 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥41 2 計画策定とパフォーマンス‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥42 3 調書‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥43 4 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥43 G8 監査調書 1 背景 1.1 基準との関連 1.1.1 基準S5『計画策定』は、 「情報システム監査人は、種類と目的・時宜と程度・目標と必要な資源を詳述し た監査を記録した監査計画を文書化する。」と述べている。 1.1.2 基準S6『監査パフォーマンスの成果』は、 「監査の過程において、情報システム監査人は監査目的を達成 するために、充分かつ信頼性のある、関連付けられた証拠を入手すべきである。監査発見事項と結論は、 この証拠の適切な分析と解釈により裏付けられているとされている。監査プロセスは、実施した監査業務 と情報システム監査人の発見事項と結論を裏付ける監査証拠を記述して文書化されるべきである。」と述 べている。 1.1.3 基準S7『報告』は、 「情報システム監査人は、監査完了時に適切な様式で報告書を提出すべきである。監 査報告書は、実施された監査作業の範囲、目的、適用の期間、性格、時宜、と程度を明記すべきである。 報告書は、情報システム監査人が、監査に関して持っている、発見事項、結論、勧告、保留事項・限定事 項・制限事項を記載すべきである。発行にあたり、情報システム監査人の報告書は、監査ポリシーや監査 契約の条件に従って、署名され、日付が入れられ、配布されるべきである。」と述べている。 1.1.4 基準S12『監査の重要性』は、 「情報システム監査人の報告書は、重要な不備や重大な欠陥になる、無 効なコントロールやコントロールの欠如、コントロールの不備の重要性と欠陥の可能性を開示すべきであ る。」と述べている。 1.1.5 基準S13『他の専門家の作業の使用』は、 「情報システム監査人は、他の専門家の作業が情報システム監 査人に現在の監査目的に関して結論を出せるほど充分であり完全であるか否か決定すべきである。そのよ うな結論は明確に文書化されるべきである。」と述べている。 1.2 COBITとの関連 1.2.1 PO1『IT戦略計画の策定』は、 「ビジネス要件から業務提供を実現したり、これら業務を透明性のある、効 果的な方法で提供するための戦略展開の際に、ITとビジネス管理の統合に重点を置くことにより、利益・ 費用・リスクに関わる透明性を高めるとともに、ビジネス戦略とガバナンス要件を維持・拡張する。」という ITに関するビジネス要件を満足している。 1.2.2 PO8『品質管理』は、 「品質マネジメントシステム（QMS)の定義、事前定義された目標に対する継続的な パフォーマンスモニタリング、IT業務の継続的改善プログラムの導入に重点を置くことにより提供されるIT 業務の継続的かつ測定可能な品質向上。」というITに関するビジネス要件を満足している。 1.2.3 AI6『変更管理』は、 「ITインフラ・アプリケーション・技術的施策への全変更の影響評価、認可、実施をコ ントロールし、不完全な要求仕様による誤謬を最小限に抑え、未承認の変更の実施を抑制することに重点 を置くことにより、施策と業務提供の不備と手戻りを削減するとともに、ビジネス戦略と共にあるビジネス 要件に対応する。」というITに関するビジネス要件を満足している。 1.2.4 DS1『サービスの定義と管理』は、 「業務要件の識別、サービスレベルの合意、サービスレベルの達成状 況のモニタリングに重点を置くことにより主要IT業務とビジネス戦略の連携を確実にする。」というITに関 するビジネス要件を満足している。 1.2.5 ME2『内部統制のモニタリングと評価』は、 「IT関連のアクティビティの内部統制プロセスをモニタリング し、改善処置を識別することに重点を置くことによりIT目標の達成を保護し、IT関連法規を遵守する。」と いうITに関するビジネス要件を満足している。 1.2.6 ME3『規制に対するコンプライアンスの保証』は、 「全ての適合法規とITコンプライアンスの相応水準を 識別し、コンプライアンス違反のリスクを低減するためにITプロセスを最適化することに重点を置くことに より、法規を遵守する。」というITに関するビジネス要件を満足している。 41 G8 監査調書 1.2.7 最も関連する情報要請規準： • 主：信頼性・可用性・効率性・インテグリティ • 副：有効性・機密性 1.3 ガイドラインの必要性 1.3.1 本ガイドラインの目的は、情報システム監査人が、監査を裏付けるために、準備し、保存すべき調書を記述 することにする。 1.3.2 本ガイドラインは、情報システム監査基準を適用する際の手引を提供している。情報システム監査人は、 上記基準の実装を達成する方法を決定する際に、本ガイドラインを考慮し、適用時に専門家としての判断 を用い、いかなる逸脱をも正当化できるように準備すべきである。 2 計画策定とパフォーマンス 2.1 調書内容 2.1.1 情報システム監査調書は、実施した監査作業の記録と情報システム監査人の発見事項、結論、勧告を裏 付ける監査証拠である。監査調書は、完全、明確、構造化され、索引が付され、レビュー者が使用・理解し 易いものであるべきである。調書の潜在的用途は、以下を含むがこれらに限定されない。 • 情報システム監査人が情報システム監査基準を遵守してきた程度の証明 • 監査ポリシー通りの要求事項を満たす監査パフォーマンスの証明 • 監査の計画策定、パフォーマンス、レビューの支援 • サードパーティレビューの促進 • 情報システム監査部門のQAプログラムの評価 • 保険請求、不正事件、紛争や訴訟のような環境での裏付け • スタッフの専門的能力の開発の支援 2.1.2 調書に含まれるべき最低限の記録は、 • 以前の監査調書のレビュー • 監査範囲と目的の計画策定と準備 情報システム監査人は、業界・事業領域・事業プロセス・製品・ベンダーによるサポート・レビューの対 象となる全体の環境を理解していなければならない。 • マネジメントレビュー会議・監査委員会会議・その他の監査関連会議の議事録 • 監査目的を満たす監査プログラムと監査手続 • コントロールの強みと弱みを評価するために実施した監査手続と入手した監査証拠 • 監査発見事項、結論、勧告 • 監査作業の結果として発行された全報告書 • 監督者レビュー 42 G8 監査調書 2.1.3 情報システム監査人の調書の程度は、監査の必要性次第であり、含むべきものは、 • 監査されるべき領域とその環境に対する情報システム監査人の理解 • 情報処理システムと次を含む内部統制環境に対する情報システム監査人の理解： –– 統制環境 –– 統制手続 –– 発見リスクの評価 –– 統制リスクの評価 –– 全リスクの同一視 • 監査調書の作成者と情報源、完了日付 • コントロールの充分性・コントロールの欠陥の存在・コントロールの欠如を評価し、補完的コントロール を識別するために使用される方法 • 監査証拠、監査調書の情報源、完了日付が含むのは、 –– テスト方針・手続・職務分離に基づく、準拠性テスト –– 分析的手続・勘定残高に対する詳細テスト・その他実証的監査手続に基づく、実証的テスト • 監査報告書と発見事項の正規の受領者からの受領確認 • 被監査人の勧告に対する対応 • 特に調書が電子媒体上にあるバージョン管理 2.1.4 調書は、法令・適用される専門家としての基準により求められる適切な情報を含むべきである。 2.1.5 調書は、そのレビューと承認のために監査委員会に提出されるべきである。 3 調書 3.1 保管・保存・取寄せ 3.1.1 方針と手続は、法的・専門的・組織的要件を満たすに充分な期間に亘り、監査発見事項と結論を裏付ける 調書の適切な保管・保存を検証し確かなものとするために有効であるべきである。 3.1.2 調書は、保存される媒体に相応しい方法により、整理・保管・確保され、上記で定義された方針と手続を 満足させるに充分な期間に亘って、取寄せ可能な状況であるべきである。 4 適用開始日 4.1 本ガイドラインは、1999年9月1日以降に開始される全ての情報システム監査に適用される。 本ガイドラインは2008年3月1日にレビューされ、改訂された。 43 G9 例外処理および違法行為に対する監査の検討事項 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥45 2 定義‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥46 3 責任‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥47 4 リスク評価‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥48 5 監査作業の計画‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥49 6 監査作業のパフォーマンス‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥50 7 報告‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥52 8 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥53 G9 例外処理および違法行為に対する監査の検討事項 1 背景 1.1 基準との関連 1.1.1 基準S3『専門家としての倫理と基準』は「情報システム監査人は、適用可能な専門の監査基準を遵守す ることを始めとして、専門家としてのしかるべき注意を払うべきである。」と述べている。 1.1.2 基準S5『計画策定』は「情報システム監査人は、監査の目的を満たし、適用可能な専門の監査基準に準 拠するよう、情報システム監査の範囲を定めた計画を策定すべきである。」と述べている。 1.1.3 基準S6『監査業務のパフォーマンス』は「監査の過程において、情報システム監査人は、監査の目的を達 成するために、十分かつ確実で関連性のある証拠を入手すべきである。監査の発見事項と監査の結論は、 この証拠を適切に分析し、解釈することにより裏付けられる。」と述べている。 1.1.4 基準S7『報告』は「情報システム監査人は、監査終了後直ちに、適切な様式の報告書を提出すべきである。 監査報告書には、監査範囲、監査目的、監査対象期間、実際に行われた監査作業の種類・時期・程度を 記載すべきである。報告書には、監査発見事項、監査の結論、勧告事項、情報システム監査人が当該監査 に関し述べておくべき留保事項・制限事項・監査対象範囲の制約を記載すべきである。」と述べている。 1.1.5 基準S9『例外処理および違法行為』は「違法行為・例外処理および違法行為に関して情報システム監査 人による必須事項と勘案を盛り込んでいる。」と述べている。 1.2 COBITとの関連 1.2.1 個々の監査範囲に適用可能であるCOBITの中から最も関連する材料の選択は、特定のCOBIT ITプロ セスを選択し、COBITのコントロール目標と関連するマネジメントの実行を勘案して行う。ここでは、情報 システム監査人としての責任、権限および説明責任の要件を満たすため、最も関連し、選択・採用される べきCOBITのプロセスを主要および副次的に分類している。選択・採用されるべきプロセスおよびコント ロール目標は、実施する監査の範囲および条件により異なるかもしれない。 1.2.2 主要な参照： • PO5 IT投資の管理 • PO7 IT人材の管理 • PO9 ITリスクの評価と管理 • PO10 プロジェクト管理 • AI1 コンピュータ化対応策の明確化 • AI5 IT資源の調達 • ME2 内部統制のモニタリングと評価 • ME3 外部要件に対するコンプライアンスの保証 • ME4 ITガバナンスの提供 1.2.3 副次的参照： • PO3 技術指針の決定 • PO4 ITプロセスと組織およびそのかかわりの定義 • PO8 品質管理 • DS7 利用者の教育と研修 • DS10 問題管理 • ME1 IT成果のモニタリングと評価 45 G9 例外処理および違法行為に対する監査の検討事項 1.2.4 最も関連する情報要請規準： • 主：コンプライエンス、機密性、インテグリティ、可用性 • 副：信頼性、効率性、有効性 1.3 ガイドラインの必要性 1.3.1 本ガイドラインの目的は、情報システム監査人が監査業務の実施時に直面する例外処理または違法行為 に対処するためのガイダンスを提供することである。 1.3.2 S9『例外処理および違法行為』は例外処理および違法行為に関して情報システム監査人による要件およ び検討事項を詳述している。本ガイドラインは情報システム監査基準を適用する際の手引を提供する。情 報システム監査人は、上記基準の実施を実現する方法を検討するとともに、その適用に関しては専門家と しての判断を用い、いかなる逸脱も正当化できるように準備しておくべきである。 2 定義 2.1 不正以外の例外処理 2.1.1 すべての例外処理が不正行為と見なされるべきではない。不正行為か否かは、監査が行われる場所の法 的管轄下での不正の法的定義に左右される。例外処理は少なくとも不正を隠蔽する目的での意図的なコ ントロールの回避、資産またはサービスの無権限の使用、そしてこれらの活動の隠蔽への加担を含む。不 正以外の例外処理には以下を含むかもしれない。 • 既存の経営ポリシーの意図的な違反行為 • 規制上の要件の意図的な違反行為 • 監査の対象となる分野または組織全体にかかわる情報の意図的な虚偽または脱漏 • 重過失 • 意図的ではない違法行為 2.2 例外処理および違法行為 2.2.1 例外処理および違法行為は少なくとも以下の活動を含むかもしれない。 • 不正―騙して違法に便益を得る行為ITシステムが適用される法律および規制を遵守できない場合を含 む、法律および規制へのコンプライアンス違反に係る行為銀行、サプライヤー、ベンダー、サービスプロ バイダや利害関係者などの第三者との合意および契約へのコンプライアンス違反に係る行為 • 記録または書類（電子または紙面のいずれの場合でも）の操作、改ざん、偽造または変更 • 記録または書類（電子または紙面のいずれの場合でも）からの取引の隠蔽または脱漏 • 機密情報の不適当または意図的な漏洩 • 実体がなく虚偽であることが知られている取引を財務またはその他の記録（電子または紙面のいずれの 場合でも）に記録すること • 情報システム資産やその他の資産の横領そして誤用 • 意図的か否かにかかわらず、著作権、商標権または特許権などの知的所有権に違反する行為 • 情報およびシステムへの無権限のアクセスの付与 • データおよびシステムへの無権限のアクセスにより生じる財務またはその他の記録の誤謬 2.2.2 特定の行為が違法か否かは、一般的には、弁護士としての資格を有する知識のある専門家の助言に基づ くかまたは、裁判所の最終決定を待たなければいけないこともある。情報システム監査人は、その行為が 疑われているのか、違法として証明されているかにかかわらず、例外処理の影響または潜在的な影響に主 点を置くべきである。 46 G9 例外処理および違法行為に対する監査の検討事項 3 責任 3.1 マネジメントの責任 3.1.1 例外処理および違法行為を予防および発見する責任は一義的にマネジメントにある。 3.1.2 マネジメントは、通常、例外処理および違法行為をタイムリーに予防または発見するという合理的な保証を 得るために、以下の方法を用いる。 • 例外処理または違法行為を予防および発見するための内部統制システムの設計、実装、および維持。内 部統制は、取引のレビューと承認、およびマネジメントによるレビューの手続を含む。 • 従業員の行動を管理するポリシーおよび手続 • コンプライアンスの検証およびモニタリングの手続 • 例外処理または違法行為に係る事件の報告、記録および管理のために適したシステムの設計、実装、お よび維持 3.1.3 マネジメントは、主張されているだけなのか、疑わしいのか、実際に証明されているのかにかかわらず、認 識している例外処理または違法行為、影響を受ける分野およびマネジメントが講じた対応策（該当する場 合）について、情報システム監査人に開示すべきである。 3.1.4 例外処理または違法行為の主張が出ていたり、疑惑があるかまたは見つかっていれば、 マネジメントは調査 および問い合わせのプロセスを支援すべきである。 3.2 情報システム監査人の責任 3.2.1 情報システム監査人は、例外処理の予防、発見および報告に関するマネジメントの責任および監査を監査 ポリシーまたは監査契約書の中に定義し、全ての監査作業に関してこれらが明確に理解されるようにする ことを検討すべきである。これらの責任が、すでに組織のポリシー、または同様の文書に記載されている場 合には、監査ポリシーにその旨を含めるべきである。 3.2.2 情報システム監査人は、コントロールメカニズムが例外処理または違法行為が発生する可能性を完全に排 除しないことを理解すべきである。情報システム監査人は、例外処理または違法行為のリスクの評価、発 見された例外処理の影響の評価、そして監査作業の種類に適したテストを設計し実施する責任がある。情 報システム監査人は、以下を合理的に検出できることを期待される。 • 監査対象の分野または組織全体に重大な影響を及ぼしうる例外処理または違法行為 • 重大な例外処理または違法行為を予防または発見できない内部統制の欠陥 3.2.3 情報システム監査人には、例外処理または違法行為を予防または発見できないことに対する職業上の責 任はない。監査は例外処理が発見できることを保証することはできない。たとえ監査が適切に計画および 実施されたとしても、例えば従業員間での共謀、従業員と外部者との共謀、 マネジメントによる例外処理へ の関与が行われる場合、例外処理は発見されない可能性がある。情報システム監査人は、この点を監査ポ リシーまたは監査契約書に盛り込むことをも検討すべきである。 3.2.4 情報システム監査人は、例外処理または違法行為の存在に関する特定の情報を持っている場合、それを検 出し、調査し、それを報告する手続を実施する義務を負う。 3.2.5 情報システム監査人は、たとえ何も発見されないとしても、例外処理または違法行為が潜在的に存在する リスクが高い状況を発見した場合には、監査委員会（またはそれに相当する）およびマネジメントに通知す べきである。 3.2.6 情報システム監査人は、例外処理または違法行為の発生原因となるかもしれないリスク要因を識別するこ とができる程度に監査対象に精通すべきである。 3.2.7 情報システム監査人は監査期間内を通して監査対象から独立していることを確認しなければいけない。 47 G9 例外処理および違法行為に対する監査の検討事項 3.2.7 情報システム監査人は情報システム監査人の責任の詳細な記述について基準9「例外処理および違法行 為」を参照することが義務付けられている。 4 リスク評価 4.1 リスク評価の計画 4.1.1 情報システム監査人は適切な方法論を使用して監査対象に関連する例外処理または違法行為の発生のリ スクを評価すべきである。この評価を準備する際には、情報システム監査人は、以下の要因を考慮すべき である。 • 組織の特性、例えば企業倫理、組織構造、監督の適切性、報酬および報奨、企業業績の圧力の度合い、 組織の方向性など • 組織の歴史、過去の例外処理の発生、 例外処理に関連する発見事項を軽減したり最小限に抑えるための事後の活動 • マネジメント、業務または情報システムにおける最近の変更および組織の現在の戦略的方向性 • 新たな戦略的パートナーシップに起因する影響 • 保有する資産または提供するサービスの種類およびそれらにおける例外処理の起こり易さ • 関連するコントロールの強度および確立されたコントロールを回避したり無視したりする脆弱性の評価 • 規制上のまたは法的な要件 • 内部告発に関するポリシー、インサイダー取引に関するポリシー、従業員およびマネジメントの倫理綱領 などの内部ポリシー • 利害関係者との関係および金融市場 • 人材能力 • 市場の重要な情報の機密性およびインテグリティ • 過去の監査からの監査発見事項の経緯 • 組織が活動する産業および競争環境 • コンサルタント、品質保証チームまたは特定のマネジメントによる調査における発見事項結果のような、 監査の範囲外で実施されたレビューの発見事項 • 日々の業務の過程において発生している発見事項 • プロセスの文書化と品質管理システム • 監査対象の分野をサポートする情報システムの技術的な精巧さと複雑さ • 基幹業務システムとしてパッケージソフトではなく自社にて開発/保守しているアプリケーションシステム の存在 • 従業員の不満の影響 • 解雇、アウトソース、売却または事業再構築の可能性 • 横領されやすい資産の存在 • 財務、業務のいずれかまたは両方における組織の業績不振 • 倫理に対するマネジメントの姿勢 • 特定の産業に共通するまたは同様の組織にて発生した例外処理および違法行為 48 G9 例外処理および違法行為に対する監査の検討事項 4.1.2 リスクアセスメントは、以下に関連するリスク要因を含む、組織および監査テーマに関連するリスク要因に 限定して考慮すべきである。 • 財務会計記録に影響を与える例外処理または違法行為 • 財務会計記録には影響を与えないが組織に影響を与える例外処理または違法行為 • 組織のコントロールの適切性に関連するその他の例外処理または違法行為 4.1.3 リスク評価の計画プロセスそして実施の一環として、情報システム監査人は下記の事項についてマネジメン トに問い合わせを行うべきである。 • 組織内の例外処理および違法行為のリスクレベルに関するマネジメントの認識 • マネジメントは組織内または組織に対して発生したまたは発生の可能性がある例外処理および違法行 為を認識しているかどうか • どのように例外処理または違法行為のリスクが監視され、または管理されているのか • 例外処理または違法行為のリスクの存在に関して適切な利害関係者へ伝達するためにどのようなプロ セスが整備されているか • 会社が活動を行う法的管轄に適用される国家および地域の法律、そして法務部門のリスク委員会およ び監査委員会との連携の程度 5 監査作業の計画 5.1 作業の計画 5.1.1 情報システム監査人には例外処理または違法行為を発見または予防する明示的な責任はないが、監査人 は違法行為または例外処理が発生するリスクの評価レベルに基づいて違法行為または例外処理を検出す るための手続を設計すべきである。 5.1.2 作業の計画時には、情報システム監査人は以下のような事項を理解すべきである。 • 組織の業務と目的の基礎的な理解 • 内部統制環境 • 就業規則と手順 • コンプライアンスの検証とモニタリングの手続 • 組織が活動を行う法的および規制環境 • 組織に影響する法律および規制へのコンプライアンスを入手、監視、そして確保するために組織が使用 する仕組み 5.2 作業手順 5.2.1 情報システム監査人は検出された例外処理および違法行為のリスクのレベルを考慮した監査手続を設計 すべきである。 5.2.2 計画の際のリスク評価そしてその他の手続の結果は監査中に行われる手続のの種類・程度・範囲を決定 するために使用されるべきである。 5.2.3 情報システム監査人は、法律および規制へのコンプライアンスに関して、ITマネジメント層およびユーザマ ネジメント層（必要に応じて）に問い合わせを行うべきである。 49 G9 例外処理および違法行為に対する監査の検討事項 5.2.4 情報システム監査人は、以下の事項に関する合理的な保証を得るために必要となるテストの種類・時期・ 範囲を決定するためにリスク評価の結果を利用すべきである。 • 監査対象の分野または組織全体に重大な影響を及ぼす例外処理が検出されていること • 重大な例外処理を予防ままたは発見できないコントロールの欠陥が検出されていること • ビジネスデータを記録、処理、要約そして報告する能力に潜在的に影響を及ぼす内部統制の整備およ び運用におけるすべての重要な不備が検出されていること 5.3 監査手続の結果の評価 5.3.1 情報システム監査人は、例外処理または違法行為の兆候が発生しているかを判断するため、監査手続の 結果をレビューすべきである。 5.3.2 この評価を行う際には、特定されたすべてのリスクに対応しているとの合理的な保証を提供するため、セク ション4において特定されたリスク要因を実施した監査手続と照らしてレビューすべきである。 5.3.3 評価には、文書化されていないリスク要因が存在するかを判断するため、手続の結果の評価も含めるべき である。 6 監査作業のパフォーマンス 6.1 違法の可能性のある行為への対応 6.1.1 監査中に、表示が不正や違法行為の存在の兆候が、情報システム監査人の気付くところとなるかもしれな い。違法行為の兆候が特定された場合、情報システム監査人は業務の内容、報告書および組織への潜在 的な影響を検討すべきである。 6.1.2 情報システム監査人は、違法の可能性のあるに関する情報に気が付いた場合、以下の手順を踏むことを検 討すべきである。 • 行為の種類を理解する • 発生した状況を理解する • 例外処理または違法行為の影響を評価す得うための十分な裏付け情報を入手する • 例外処理または違法行為の影響および更なる行為が存在するかどうかを決定するため、追加的な手続 を実施する 6.1.3 情報システム監査人は、例外処理または違法行為が発生したかどうか、また、その影響を決定するために、 マネジメント（可能であれば、関与者よりも上の適切なレベル）を含む、組織内の適切な要員（組織内のセ キュリティ要員等）と協力すべきである。 6.1.4 例外処理にマネジメントのメンバーが関与している場合、情報システム監査人はマネジメントによる確認書 の信頼性を再検討すべきである。前述のように、情報システム監査人は、通常、例外処理または違法行為 の関与者の上位レベルの適切なマネージメントと協力すべきである。 6.1.5 状況が明らかな場合を除き、情報システム監査人は、例外処理または違法行為を単独で発生していないと 仮定すべきである。 6.1.6 情報システム監査人は、例外処理または違法行為を防止または発見できなかった理由を決定するために、 組織の内部統制のうちの該当する部分のレビューも行うべきでがある。 6.1.7 情報システム監査人は、組織の内部統制の十分性、運用の有効性の事前評価を再考すべきである。 50 G9 例外処理および違法行為に対する監査の検討事項 6.1.8 情報システム監査人は、例外処理または違法行為が存在する（潜在的、実際かどうかにかかわらず）状況 を特定した場合、監査実施中に特定した問題を確認または解決するため、実施した監査手続を修正すべ きである。そのような修正または追加的手続の範囲は、以下に関する情報システム監査人の以下の判断に よって決まる。 • 発生した例外処理または違法行為の種類 • 発生の知覚リスク • 金額的影響または組織の評判を含めた組織への潜在的な影響 • 同様の例外処理または違法行為の再発の可能性 • マネジメントが例外処理または違法行為を認識または関与している可能性 • 統治機関、 マネジメントのいずれかおよび両方が講じている対応策（該当する場合） • 法律および規制に対するコンプライアンス違反が故意ではなく発生した可能性 • 重大な罰金または許可の取消し等のその他の処罰がコンプライアンス違反の結果として課される可能性. • 例外処理によって生じる公益への影響 6.2 例外処理発見の影響 6.2.1 例外処理が検出された場合、情報システム監査人は、監査の目的と収集した監査証拠の信頼性に対する これら活動の影響を検討すべきである。また、情報システム監査人は、以下の場合、監査を継続すべきかを 検討すべきである。 • 例外処理の影響が重要であり、十分かつ信頼できる監査証拠を入手することができないように思われる 場合 • マネジメントまたは内部統制に重要な役割を持っている従業員が、例外処理に関与または例外処理を容 認していることを監査証拠が示している場合 6.3 例外処理の兆候発見の影響 6.3.1 監査証拠が、例外処理が起こったかもしれないことを示すなら、情報システム監査人は以下を行うべきで ある。 • その件を詳細に調査する、または適切な対応を取ることをマネジメントに勧告する。情報システム監査人 がマネジメントがが例外処理に関与していることを疑うのなら、情報システム監査人は、これらの結論を 報告すべき、組織における適切かつ責任のある人物を特定すべきである。内部的に報告するのが不可能 であると判明するなら、情報システム監査人は、発見事項を外部へ報告することの可否およびリスクに 関して、監査委員会と弁護士に相談することを検討すべきである • 監査発見事項、結論、および勧告事項を裏付けるために適切な対応を行う 6.4 法的な検討事項 6.4.1 監査証拠が、例外処理が違法な行為にかかわる恐れがあることを示すなら、情報システム監査人は直接弁 護士の意見を求めるか、またはマネジメントに弁護士の意見を求めることを勧告すべきである。情報システ ム監査人は、監査ポリシーまたは監査契約書に法的コストに対する責任を定義するのも良策である。 51 G9 例外処理および違法行為に対する監査の検討事項 7 報告 7.1 内部報告 7.1.1 例外処理の検出は、組織で直ちに適切な人々に伝えられるべきである。通知は例外処理が起こったと疑わ れるレベルの上位のマネジメントに向けられるべきである。また、例外処理は、金額的な影響およびコント ロールの欠陥の兆候という観点から明らかに重要でない事項を除き、取締役会、取締役会の委員会また はこれに相当する機関に報告されるべきである。もし情報システム監査人がマネジメントのすべてのレベル が関与していると疑うなら、発見事項は、国内における規制および法律に従い、取締役会/理事会、評議 会または監査委員会等の組織の統治機関へ報告されるべきである。 7.1.2 例外処理または違法行為を報告するとき、情報システム監査人は、専門家としての判断を使用するべきで ある。情報システム監査人は、発見事項および追加で実施する手続の種類・時期・程度に関して、関与し ていると思われる人々の少なくとも1つ上位のレベルの適切なマネジメントと議論するべきである。この際、 情報システム監査人が独立性を保つことが一際重要である。例外処理または違法行為を誰に報告するか を決定する際、情報システム監査人はマネジメント層の関与の可能性を含むすべての関連事情を考えるべ きである。 7.1.3 例外処理に関する報告書の内部への配布は慎重に考えられるべきである。例外処理の発生と影響は慎重 に扱うべき問題であり、そして、それらの報告には以下を含むリスクを伴う。 • それらの詳細を公表することの結果としてのコントロールの欠陥の更なる悪用 • 外部への開示(認可または無認可)が行われた場合の顧客、サプライヤーおよび投資家の喪失 • マネジメントへの信頼および組織の将来が失われることによる、例外処理に関与していない者も含む、 主要なスタッフとマネジメントの喪失 7.1.4 情報システム監査人は、報告書の配布を管理するのに有用である場合には、例外処理を他の監査上の論 点とは別に報告することを検討すべきである。 7.1.5 情報システム監査人の報告書は、以下を含むべきである。 • 組織が採用している重要なポリシーおよび手続 • 一般に認められた基準からの逸脱が存在する場合のマネジメントの理由と監査人の意見 7.1.6 情報システム監査人は、証拠を破壊または隠蔽する可能性を低めるため、例外処理または違法行為に関与 しているかもしれない者に警告することを避けるようにすべきである。 7.2 外部への報告 7.2.1 外部への報告が法律または規制により義務付けられているかもしれない。その義務は組織のマネジメント、 例外処理を検出するのにかかわった人物、または両者に適応されるかもしれない。 例外処理または違法行為を報告する組織の責任にかかわらず、情報システム監査人は、組織に対する守 秘義務により、潜在的なまたは特定された例外処理または違法行為を報告することができない。しかし、 場合によっては、情報システム監査人は例外処理または違法行為を明らかにしなければならないかもしれ ない。以下は、そのような例である。 • 法的または規制上の要件へのコンプライアンス • 外部監査人の要求 • 召喚または裁判所の命令 • 政府の財政援助を受ける組織の監査の要件に準拠した資金提供機関または政府機関 52 G9 例外処理および違法行為に対する監査の検討事項 7.2.2 外部への報告が必要な場合、適応される規制や監査の特定の事情に問題でなければ、報告書は外部への 提出の前に適切なレベルの監査担当マネジメントによって承認されるべきであり、被監査側のマネジメント によっても事前にレビューされるべきである。特定の事情で、被監査側のマネジメントの合意入手を妨げる 例として以下を含む。 • 被監査側のマネジメントの例外処理への積極的な関与 • 被監査側のマネジメントの例外処理への消極的同意 7.2.3 被監査側マネジメントが報告書の外部への提出に合意しないなら、そして外部への報告が法律または規制 により義務付けられているならば、情報システム監査人は監査委員会と弁護士に発見事項を組織の外部 に報告することの可否およびリスクについて相談することを考慮すべきである。法的管轄によっては、情報 システム監査人は正規の特権によって保護されるかもしれない。例え情報システム監査人が適切な特権に よって保護されるかもしれないとしても、情報システム監査人が本当にそのような特権によって保護される か確認するために情報システム監査人はこのような開示をする前に弁護士の意見と助言を求めるべきでる。 7.2.4 情報システム監査人は、監査責任者の承諾の下、報告書を適切な監督機関へタイムリーに提出すべきであ る。もし組織が認知している例外処理または違法行為を明らかにしなかったり、情報システム監査人にそ のような報告事項を伏せるよう強要するなら、情報システム監査人は弁護士の意見と助言を求めるべきで る。 7.2.5 経営者が不正行為を組織外に報告しなければならないことを情報システム監査人が認識している場合、 情報システム監査人はこの責任に関しマネジメントに正式に助言しなければならない。 7.2.6 例外処理が外部監査チームの一員ではない情報システム監査人によって検出されたなら、情報システム監 査人はタイムリーに外部監査人にレポートを提出することを考慮すべきである。 7.3 監査範囲の制限 7.3.1 監査範囲が制限されている場合は、情報システム監査人は監査書の中にこの制限の種類および影響に関 する説明を入れるべきである。このような制限は以下の場合起こるかもしれない。 • 例えば、信憑性のない監査証拠、人材不足、または監査活動に関して経営者側によって課された制限な ど、情報システム監査人が本来の監査の目的を果たすためと監査結論を裏付けるために必要と考えられ る追加的な作業を進めることができない場合 • マネジメントが情報システム監査人により勧告された調査を行っていない場合 8 適用開始日 8.1 本ガイドラインは、2000年3月1日以降に開始されるすべての情報システム監査に適用される。 本ガイドラインは、2008年9月1日にレビューされ、改訂が行わわれ、G19『例外と違法行為』と統合、置 き換えが行われた。 53 G10 監査サンプリング 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥55 2 監査業務のパフォーマンス‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥56 3 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥58 G10 監査サンプリング 1 背景 1.1 監査基準との関連 1.1.1 基準S6『監査業務のパフォーマンス』は、 「監査の過程において、情報システム監査人は、監査の目的を 達成するために、十分かつ確実で関連性のある証拠を入手すべきである。監査の発見事項と監査の結論 は、この証拠を適切に分析し、解釈することにより裏付けられる。」と述べている。 1.2 COBITとの関連性 1.2.1 個々の監査範囲に適用可能であるCOBITの中から最も関連する材料の選択は、特定のCOBIT ITプロセ スを選択し、COBITのコントロール目標と関連するマネジメントの実行を勘案して行う。ここでは、情報シ ステム監査人としての監査サンプリングの要件を満たすため、最も関連し、選択・採用されるべきCOBIT のプロセスを主要および副次的に分類している。選択・採用されるべきプロセスおよびコントロール目標 は、実施する監査の範囲および条件により異なるかもしれない。 1.2.2 ME2『内部統制のモニタリングと評価』は、 「IT関連アクティビティの内部統制プロセスをモニタリングし、 是正措置を特定することに重点を置くことにより、IT目標の達成を保証し、IT関連法、規制および契約を 遵守する。」というITのビジネス要件を満たしている。 1.2.3 ME3『規制に対するコンプライアンスの保証』は、 「すべての関連法律、規制および対応するITのコンプラ イアンスレベルを特定し、ITプロセスを最適化して、コンプライアンス違反のリスクを低減することに重点 を置くことにより、法律および規制の遵守に対するコンプライアンスの保証。」というITのビジネス要件を 満たしている。 1.2.4 主要な参照： • PO8 品質管理 • PO9 ITリスクの評価と管理 • AI6 変更管理 • ME2 内部統制のモニタリングと評価 • ME3 規制に対するコンプライアンスの保証 1.2.5 最も関連する情報要請規準： • 主：有効性、インテグリティ、信頼性、コンプライアンス • 副：機密性、効率性、可用性 1.3 ガイドラインの必要性 1.3.1 本ガイドラインの目的は、監査サンプルを立案、抽出し、サンプル結果を評価するにあたっての指針を情報 システム監査人に提供することにある。適切なサンプリングおよび評価は、十分かつ確実で関連性のある 有益な証拠および適切な分析による裏付けという要件を満たす。 1.3.2 情報システム監査人は、コンプライアンスまたは実証性テストを実施するために統計に基づく代表サンプ ルの抽出を可能とする手法を検討すべきである。 1.3.3 サンプリングを検討するコントロールの準拠性テストの例には、ユーザアクセス権、プログラムの変更管理 手続、手続ドキュメント、プログラムドキュメント、例外事項へのフォローアップ、ログのレビューおよびソフ トウエアライセンスに関する監査が含まれる。 1.3.4 サンプリングを検討する実証性テストの例には、サンプル口座の複雑な計算（例えば利息）の再実施、サン プル取引の証憑突合等が含まれる。 55 G10 監査サンプリング 1.3.5 本ガイドラインは、情報システム監査基準を適用する際の指針を提供する。情報システム監査人は、基準 S6をどのように適用するかを決定する際に本ガイドラインを考慮すべきである。また、その適用に関しては 専門家としての判断を用い、基準からのいかなる逸脱も正当化できるように準備しておくべきである。 1.3.6 監査サンプリングについてのその他の有益な参照としては、国際会計士連盟（IFAC）が公表した国際監 査基準＃530監査サンプリングおよびその他の抽出テスト手法がある。 2 監査業務のパフォーマンス 2.1 監査サンプリング 2.1.1 統計的または非統計的サンプリング手法を使う場合、情報システム監査人は、十分かつ確実で関連性のあ る有益な監査証拠を入手するため、監査サンプルを立案、抽出し、監査手続を実施し、また、サンプル結果 を評価すべきである。 2.1.2 監査意見を形成するにあたり、情報システム監査人はしばしば入手可能なすべての情報を検証しないこと がある。これは、すべての情報を評価することが現実的ではないこと、また、監査サンプリングを用いるこ とにより妥当な結論を形成することが可能なためである。 2.1.3 監査サンプリングは、母集団の100％未満に対する監査手続の適用と定義され、これにより、情報システ ム監査人は母集団に関する結論を形成するまたはその形成に役立たせるために抽出された項目の何らか の特性についての監査証拠を評価することが可能となる。 2.1.4 統計的サンプリングは、母集団について数学的に結論を導き出す技法の利用を含んでいる。 2.1.5 非統計的サンプリングは、統計に基づいておらず、サンプルが母集団を代表するものではないため、結果か ら母集団を推定すべきではない。 2.2 サンプルの立案 2.2.1 監査サンプルの数および構造を立案する場合、情報システム監査人は特定の監査目的、母集団の特性、サ ンプリングおよび抽出手法を検討すべきである。 2.2.2 情報システム監査人はサンプルの立案および分析に適切な専門家を関与させる必要性について検討すべ きである。 2.2.3 サンプリング単位はサンプルの目的によって異なる。コントロールの準拠性テストにおいては、サンプリン グ単位が事象か取引（例えば請求書に対する承認のようなコントロール）の場合、通常、属性サンプリング が用いられる。実証性テストにおいては、サンプリング単位はしばしば金額であり、そのような場合、変数あ るいは推定サンプリングがよく用いられる。 2.2.4 情報システム監査人は達成すべき特定の監査目的およびその目的を最大に達成しうると思われる監査手 続を検討すべきである。加えて、監査サンプリングが適切な場合、求める監査証拠の種類および起こり得 る誤謬の状況についての検討がなされるべきである。 2.2.5 母集団とは、情報システム監査人が母集団に関する結論を形成するために抽出しようとするデータのすべ ての集合体である。そのため、サンプルを抽出する母集団は特定の監査目標のために適切であり、また、完 全であることが検証されなければならない。 2.2.6 効率的かつ効果的にサンプルを立案するためには階層化が適切かもしれない。階層化は、ある母集団を 類似する特性を有する複数の小さい集団に分割するプロセスのことであり、サンプリング単位はそれぞれひ とつの層に属する。 2.2.7 サンプル数を決定する場合、情報システム監査人はサンプリングリスク、許容可能な誤謬の大きさおよび 期待される誤謬の程度について考慮すべきである。 56 G10 監査サンプリング 2.2.8 サンプリングリスクは、情報システム監査人の結論が母集団の全部に同じ監査手続を実施した場合に得ら れたであろう結論と相違する可能性があることから生じる。 • サンプリング・リスクには2種類ある • 過誤受容によるリスク―実際には母集団に重要な虚偽表示が存在しているにもかかわらず、重要な虚 偽表示は存在しないと評価するリスク • 過誤棄却によるリスク―実際には母集団に重要な虚偽表示が存在していないにもかかわらず、重要な 虚偽表示が存在していると評価するリスク 2.2.9 サンプル数は情報システム監査人が許容可能なサンプリングリスクのレベルに影響を受ける。サンプリン グ・リスクは、監査リスク・モデルおよびその構成要素である固有リスク、コントロールリスクおよび発見リ スクとの関連においても検討されるべきである。 2.2.10 許容しうる誤謬は、情報システム監査人が積極的に許容できかつ監査目的が達成されたと結論付けるこ とが可能な母集団における最大限の誤謬である。実証性テストにおいては、許容しうる誤謬は情報システ ム監査人の重要性の判断に関係する。準拠性テストにおいては、許容しうる誤謬は、情報システム監査人 が受入可能な所定のコントロール手続からの最大乖離率である。 2.2.11 もし情報システム監査人が母集団に誤謬が存在していると期待する場合、母集団における実際の誤謬が 計画時の許容しうる誤謬よりも大きくないとの結論を導くためには、一般的に、誤謬が存在しないことを 期待する場合よりも多くのサンプルを検証されなければならない。母集団に誤謬が存在しないことを期待 する場合には、より少ないサンプル数が認められる。情報システム監査人は、ある母集団において期待さ れる誤謬を決定する際には、前回の監査における誤謬レベル、組織における手続の変更、内部統制システ ムの評価および分析的レビュー手続の結果から得られる証拠等を考慮すべきである。 2.3 サンプルの抽出 2.3.1 一般的に用いられるサンプリング手法には４種類ある。統計的サンプリング手法は以下の通りである。 • 無作為抽出法－母集団のサンプリング単位の全ての組み合わせに等しい抽出機会が与えられる • 系統的抽出法－抽出間隔を一定にしてサンプリング単位を抽出する手法であり、最初の間隔は無作為 に決定される。例としては、母集団のうち個々の金額的価値（例えば1ドル）に等しい抽出機会が与えら れる金額単位抽出法がある。個々の金額単位は通常分かれて検証されないので、金額単位を含む項目 が検証のために抽出される。この手法は、より大きな金額が抽出されるよう、抽出にあたって系統的に 重み付けをするが、それそれの金額的価値は均等な確率で抽出される。他の例としては何番目かごとの 項目を抽出するものがある。 非統計的サンプリング手法は以下の通りである。 • 任意抽出法－情報システム監査人は定型化した手法に従わずに意識的な偏向または予測を避けてサン プルを抽出する。しかしながら、任意抽出サンプルの分析は母集団についての結論を形成する際には依 拠されるべきでない。 • 判断サンプリング－情報システム監査人はサンプルに偏向りを置く（例えば、ある価値以上の全てのサ ンプリング単位、ある種類の全ての例外、全ての負数、全ての新規ユーザー）。判断サンプリングは非統 計的であり、サンプルが母集団を代表していないため、結果から母集団を推定すべきでないことに留意 すべきである。 2.3.2 情報システム監査人は、例えば統計的サンプリング手法を用いて検証しようとしている母集団の特性をサ ンプルが代表するように、サンプル項目を抽出すべきである。監査の独立性を維持するため、情報システム 監査人は母集団が完全であることを確実にし、サンプルの抽出をコントロールすべきである。 2.3.3 サンプルが母集団を代表するためには、例えば統計的サンプリングのように、母集団における全てのサン プリング単位に等しいまたは既知の確率で抽出されるべきである。 57 G10 監査サンプリング 2.3.4 抽出手法には一般的に2種類ある：記録に基づく抽出および数量（金額単位など）に基づく抽出。記録に 基づく抽出として一般的な手法は以下の通りである。 • 無作為サンプル（統計的サンプル） • 任意サンプル（非統計的） • 判断によるサンプル（非統計的；偏向した結論を導き出す可能性が高い） 数量に基づく抽出として一般的な手法は以下の通りである。 • 無作為サンプル（金額単位の統計的サンプル） • 均等間隔のサンプル（均等の間隔を使った統計的サンプル） • 升目サンプル（間隔をランダムにとった統計的サンプル） 2.4 文書化 2.4.1 監査調書にはサンプリングの目的および採用したサンプリングのプロセスについての十分に詳細な記述を 含むべきである。調書には、母集団の出所、採用したサンプリング手法、サンプリングのパラメータ（無作 為の始点となる番号あるいは無作為の始点を特定した方法、サンプルの間隔など）、抽出した項目、実施し た監査テストの詳細および形成された結論が含まれるべきである。 2.5 サンプル結果の評価 2.5.1 各サンプルについて特定の監査目的に適切な監査手続を実施した後、情報システム監査人は、サンプル中 に発見されたあらゆる誤謬を分析し、それらが実際に誤謬か否かについて、さらに適切な場合には誤謬の 種類および原因を決定すべきである。誤謬と評価された場合、誤謬は、採用されたサンプリング手法が統 計に基づくものである場合には、母集団にとって適切なものとして推定されるべきである。 2.5.2 サンプル中に発見されたあらゆる誤謬は実際に誤謬か否かを決定するためにレビューされるべきである。 情報システム監査人は誤謬の質的な側面を考慮すべきである。これらには、誤謬の種類および原因、監査 の他の段階への誤謬のありうべき影響が含まれる。自動化されたプロセスがにおける障害の結果により 生じる誤謬は、通常、人的な誤謬よりも誤謬率に対するより広範囲な影響がある。 2.5.3 ある特定のサンプル項目について期待された監査証拠が得られなかった場合、情報システム監査人は抽出 した項目に関する代替的な手続を実施することにより十分かつ適切な監査証拠を得ることが可能な場合 がある。 2.5.4 情報システム監査人は、サンプリング単位の抽出手法と一致する推定手法をもとに、サンプル結果からの 母集団の推定を検討すべきである。サンプルの推定には、母集団におけるありうべき誤謬を推定すること、 技法の不正確さおよび発見された誤謬の質的な側面のために発見されなかったさらなる誤謬を推定する ことが含まれる。 2.5.5 情報システム監査人は、監査目的に関連する他の監査手続の結果を考慮に入れた上で、推定される母集 団の誤謬と許容しうる誤謬を比較することにより、母集団における誤謬が許容しうる誤謬を超えているか 否かについて検討すべきである。推定された母集団の誤謬が許容しうる誤謬を超えている場合、情報シス テム監査人はサンプリングリスクを再評価し、もしリスクが許容しがたい場合には、監査手続の拡大また は代替的な監査手続を実施することを検討すべきである。 3 適用開始日 3.1 本ガイドラインは、2000年3月1日以降に開始される全ての情報システム監査に適用される。 本ガイドラインは2008年8月1日にレビューされ、改訂された。 58 G11 広範情報システムコントロールの効果 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥60 2 コントロールフレームワーク‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥61 3 計画策定‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥64 4 監査作業のパフォーマンス‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥65 5 報告‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥65 6 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥65 G11 広範情報システムコントロールの効果 1 背景 1.1 基準との関連 1.1.1 基準S6『監査業務のパフォーマンス』は、 「監査作業中、情報システム監査人は、監査目的を達成するた めに充分、信頼性がある、関連付けのある証拠を取得すべきである。監査発見事項と結論は、この証拠の 適切な分析と解釈で裏付けられることになっている。」と述べている。 1.2 COBITとの関連 1.2.1 個々の監査範囲に適用可能であるCOBITの中から最も関連する材料の選択は、特定のCOBIT ITプロセ スを選択し、COBITのコントロール目標と関連するマネジメントの実行を勘案して行う。情報システム監査 人の監査要求に合わせるべく、最も関連しており、選択、適用されるべきCOBITのプロセスが、ここで次の ように主要・副次的なものとして分類されている。 1.2.2 主要な参照： • PO4 ITプロセスと組織およびそのかかわりの定義 • AI4 運用と利用の促進 • AI6 変更管理 • AI7 ソリューションおよびその変更の導入と認定 1.2.3 副次的参照： • DS3 性能とキャパシティの管理 • DS5 システムセキュリティの保証 • ME2 内部統制のモニタリングと評価 1.2.4 最も関連付けられる情報要請規準： • 主：有効性、効率性、インテグリティ • 副：機密性、可用性、コンプライアンス、信頼性 1.3 ガイドラインの必要性 1.3.1 組織、部署、部門の管理とモニタリングは、組織、部署、部門が、コントロールを適用する方法を含め、取る やり方に影響がある。この原理は、情報システムの利用において、製造組織、出納課、財務部門と同じくら い多く適用されている。 1.3.2 組織内で運用される詳細な情報システムコントロールの有効性は、組織全体の情報システムの利用の管 理とモニタリングの有効性によって制限されている。これは、財務システムの「アプリケーション」コント ロールに関わる情報システム環境の「全般」コントロールの効果が認知される財務監査用のガイドライン の中にしばしば認められる。 1.3.3 ITガバナンス協会のCOBITフレームワークが、助力できる情報システム監査人の区別は、 • 情報システム監査範囲に直接関連付けられる詳細情報システムコントロールと • 保証に貢献し、それら詳細情報システムコントロールに関連して情報システム監査人により獲得されるか もしれない情報システム管理とモニタリングの特徴の違いである。 1.3.4 分離した全般／アプリケーションコントロールは、目的がデータプロセスインテグリティ、ビジネスユ－ザ へのシステム可用性、ビジネス情報機密性に関する意見を形成することになる、監査に特別に適用するよ うに設計された。 60 G11 広範情報システムコントロールの効果 1.3.5 内部監査人と独立系コンサルタントが情報システム監査を実施する時、監査目的と範囲は、通常、財務監 査を含むビジネスプロセスのとは異なる。使用中のシステムは手動とコンピュータプロセスの組合せであり、 コントロール目的は、会計情報記録を含むビジネスプロセスより広かろうが狭かろうが、プロセス全体用で あるに違いない。それ故、ビジネスプロセス監査に使用されるコントロールフレームワークは情報システム 監査には適切でないかもしれない。 1.3.6 監査済みの詳細コントロールの有効性に関する意見を形成するために情報システム監査人は、たとえそれ らが監査のために合意された範囲外であっても、情報システムの管理とモニタリングの有効性を評価する 必要性を考慮すべきである。その種の考慮の結果は合意された範囲の延長から適切に制限された報告に 及ぶかもしれない。 1.3.7 管理とモニタリングコントロールの全体は広く、これらのコントロールの一部は特定の監査目的には関連 していないかもしれない。監査リスクを評価し、適切な監査取組みを決定するために、情報システム監査 人が必要とする構造的方法が決定するのは、 • 監査範囲と目的に関連付けられる管理とモニタリングコントロール • テストされるべき管理とモニタリングコントロール • 監査意見に関する関連する管理とモニタリングコントロールの効果 情報システム監査人が監査済みの情報システムと運用に影響を及ぼす主コントロールに焦点を絞ることを 助けるかもしれない、情報システムおよび関連技術の利用に特有なコントロールのフレームワークを利用 して、これは達成されるかもしれない。 1.3.8 情報システム監査人は、上記基準の実装を達成し、適用にあたって専門的判断を利用し、いかなる逸脱を も正当化する覚悟をする方法を決定するに当たりそれを考慮すべきである。 2 コントロールフレームワーク 2.1 概観 2.1.1 COBITはコントロールを「ビジネス目的が達成され、望まない事象が防止、検知、是正される合理的な保 証を提供すべく設計された方針、手続、実践、組織構造」と定義付けしている。各々の情報システム監査に とって、情報システム監査人は、全情報システムと運用（広範情報システムコントロール）に影響を与えるそ れら全般統制と、情報システム監査目的に関連するリスク分野に監査労力を集中するために、もっと特定 の水準で稼働するそれら全般およびアプリケーションコントロール（詳細情報システムコントロール）を区 別すべきである。この項で述べられているコントロールフレームワークの目的は、情報システム監査人がこ れら焦点に到達するのを支援することである。 2.2 広範情報システムコントロール 2.2.1 用語「広範情報システムコントロール」はwww.isaca.org/glossaryにあるISACA用語集の中で定義付け されている。広範情報システムコントロールは全般コントロールの部分集合である；それらは、情報システ ムの管理とモニタリングに焦点をあてた全般コントロールである。 2.2.2 情報システム監査人の作業に対する広範情報システムコントロールの効果はビジネスプロセスシステムの 中のアプリケーションコントロールの信頼性に限らない。広範情報システムコントロールは、また、詳細情 報システムコントロールの信頼性に影響を与える。たとえば、 • アプリケーションプログラム開発 • システム実装 • セキュリティ管理 • バックアップ手続き 61 G11 広範情報システムコントロールの効果 2.2.3 情報システムの弱い管理とモニタリング（即ち、弱い広範情報システムコントロール）は、詳細水準で運用 すべく設計されたコントロールが有効でないかもしれないという高リスクの可能性について情報システム監 査人に注意を喚起すべきである。 2.2.4 広範コントロールは、重要なプロセスとコントロールが識別されているリスク評価を通じて最も有効に決 定される。例えば、組織によって、リスク評価は、テスト環境から本番プロセス環境へのプログラム変更の 評価の周辺のコントロール（即ち、職務分離）の格付けに帰結するかも知れない。とりわけ、プログラム開 発・変更環境を本番プロセス環境から分離するコントロールは広範コントロールと考えられるかも知れな い。このコントロール目的を完遂するための手段と方法は、新規または修正されたプログラムの高度化は、 通常本番プロセス環境に任命される個人によって実施されることを保証する。従って、広範コントロールは、 他の詳細コントロールに置かれる信頼にとって必須である。 2.3 詳細情報システムコントロール 2.3.1 用語「詳細情報システムコントロール」はwww.isaca.org/glossaryにあるISACA用語集の中で定義付け されている。それらは、アプリケーションコントロールと広範情報システムコントロールに含まれない全般 コントロールからなる。COBITフレームワークの中で、詳細情報システムコントロールは、情報システムのシ ステムとサービスの、調達、導入、サービス提供、サポートのコントロールである。 コントロールの例としては、 • ソフトウェアパッケージの実装 • システムセキュリティパラメータ • 災害復旧計画 • データインプット承認 • 例外報告書 • ユーザアカウント アプリケーションコントロールは詳細情報システムコントロールの部分集合である。例えば、データインプッ ト承認は詳細情報システムコントロールであり、アプリケーションコントロールである。AI7『ソリューション およびその変更の導入と認定』は、情報システムコントロールではあるが、アプリケーションコントロールで はない。 2.3.2 情報システムコントロール間の関係を示す概略としては、 情報システムコントロール • 全般統制 –– 広範情報システムコントロール –– 詳細情報システムコントロール • アプリケーションコントロール 加えて、情報システム監査人は範囲や監査手続に関する非情報システムコントロールの効果を考慮すべき である。 2.4 広範情報システム監査と詳細情報システムコントロールの相互作用 2.4.1 広範コントロールはCOBITの４ドメインに基づき分析されるべきである。 • 計画と組織（PO） • 調達と導入（AI） • サービス提供とサポート（DS） • モニタリングと評価（ME） 62 G11 広範情報システムコントロールの効果 2.4.2 広範コントロールはシステム可用性、データインテグリティ、情報の機密性の喪失に関連するリスクから識 別されるべきである。例えば、株式公開企業の財務または非財務報告に使用される、検出されないままと なる、本番データへの未承認で重大な更新を禁止するコントロールは、データインテグリティの観点から 広範コントロールとして解釈されるかも知れない。2.4の残りの部分は全ドメインの潜在的広範コントロー ルを更に例証している。 2.4.3 AIとDSドメインのコントロールの有効性は、POとMEドメインで運用されるコントロールの有効性により 影響される。不充分な計画、組織、 マネジメントによるモニタリングは調達、導入、サービス提供、サポート のコントロールの効果がないことを暗示する。反対に、強い計画、組織、モニタリングは調達、導入、サー ビス提供、サポートの無効なコントロールを識別し、修正し得る。 2.4.4 例えば、COBITプロセスのAI2『アプリケーションソフトウェアの調達と保守』の詳細情報システムコント ロールが含んでいるCOBITプロセスは、 • PO1 IT戦略計画の策定 • PO8 品質管理 • PO10 プロジェクト管理 • ME1 IT成果のモニタリングと評価 2.4.5 アプリケーションシステム調達の監査は情報システム戦略、プロジェクト管理取組み、品質管理、モニタリ ングへの取組みの効果の識別を含むべきである。例えば、プロジェクト管理が不充分な場合、情報システ ム監査人が考慮すべきなのは、 • 監査済の特定のプロジェクトが有効に管理されているという保証を提供するための追加作業の計画 • 広範情報システムコントロールの弱点のマネジメントへの報告 2.4.6 更なる例は、COBITプロセスDS5システムセキュリティの保証の有効な詳細情報システムコントロールが、 次のCOBITプロセスを含むプロセスの広範情報システムコントロールの適切性により影響されているとい うことである。 • PO4 ITプロセスと組織およびそのかかわりの定義 • PO6 マネジメントの意図と指針の周知 • PO9 ITリスクの評価と管理 • ME1 IT成果のモニタリングと評価 2.4.7 システムのセキュリティパラメータの適切性の監査は、 マネジメントのセキュリティ方針の考慮(PO6)、セ キュリティ責任の分担(PO4)、リスク評価手続き(PO9)、セキュリティ方針と整合したモニタリングの手続 き(ME1)の考慮を含むべきである。たとえパラメータが、ベストプラクティスに対する情報システム監査人 の見解と整合していなくても、取組まれるべきリスク水準を方向付けるマネジメントとマネジメント方針によ り識別されたリスクに照らし、適切であると評価されるかも知れない。改善のための監査推奨事項はどれ も、詳細パラメータ自身と同様、それゆえ、リスク管理へ方向付けられるべきである。 63 G11 広範情報システムコントロールの効果 3 計画策定 3.1 関連する広範情報システムコントロールへの取組み 3.1.1 情報システム監査ガイドラインG15『監査計画策定』は、 「情報システム監査人は監査済みの機能のコン トロールの予備評価を実施すべきである」と述べている。リスク評価は関連する広範情報システムコント ロールを識別、評価するに必須である。広範情報システムコントロールのテストは、その特質により、情報 システム利用の多くの異なる観点をカバーしているので、実施済みの特定の情報システム監査にとって異 なる周期で実施されるかも知れない。それゆえ、情報システム監査人は、この分野での過去の監査作業が、 これらコントロールを識別し、評価するために、信頼され得るかどうかを考慮すべきである。 3.1.2 監査作業が、広範情報システムコントロールが不満足であることを示唆している場合、情報システム監査 人は監査目的達成への計画的取組みに関するこの発見事項の影響を考慮すべきである。 • 強い広範情報システムコントロールは、詳細情報システムコントロールに関連して情報システム監査人 が得られるかもしれない保証に貢献し得る • 弱い広範情報システムコントロールは強い詳細情報システムコントロールを蝕んだり、詳細水準での弱 点を悪化させるかも知れない 3.2 充分な監査手続 3.2.1 広範情報システムコントロールが監査目的への重要な潜在的効果を持つ場合、詳細コントロールのみ監 査する計画は充分ではない。広範情報システムコントロールを監査することが可能でもなく、現実的でも ない場合、この範囲の制限は報告されるべきである。 3.2.2 情報システム監査人は、このテストが監査目的達成に貢献する場合は、関連する広範情報システムコント ロールをテストすることを計画すべきである。 3.3 関連コントロール 3.3.1 関連する広範情報システムコントロールは、この業務の特定の監査目的に効果を持つものである。例え ば、監査目的が特定のプログラム庫への変更の周囲のコントロールに関して報告することになっている場 合、セキュリティ方針(PO6)に関連する広範情報システムコントロールは関連付けられるが、技術的方向付 けの決定(PO3)に関連する広範情報システムコントロールは関連付けられないかも知れない。 3.3.2 監査を計画するに当たり、情報システム監査人は、全広範情報システムコントロールの内から、特定の監 査目的への効果があるものを識別し、監査範囲でこれを含めることを計画すべきである。PO、MEドメイン のCOBITのコントロール目的は情報システム監査人が関連する広範情報システムコントロールを識別する のを手助けするかも知れない。 3.4 監査証拠 3.4.1 情報システム監査人は関連するコントロールが有効に稼働しているという監査証拠を入手することを計画 すべきである。テストは監査作業の実施の4項で概説されている。 3.5 関連する詳細情報システムコントロールへの取組み 3.5.1 情報システム監査作業が、広範情報システムコントロールが申し分ないということを示唆している場合、情 報システム監査人は、強い情報システムコントロールの監査証拠が、詳細情報システムコントロールに関連 して、情報システム監査人が得られるかもしれない保証に貢献するので、詳細情報システムコントロールに 計画されているテスト水準の軽減を考慮するかも知れない。 64 G11 広範情報システムコントロールの効果 3.5.2 情報システム監査作業が、広範情報システムコントロールが不満足であることを示唆する場合、情報シス テム監査人は、関連する広範情報システムコントロールの弱点にも拘わらず、有効に稼働しているという監 査証拠を提供すべく詳細情報システムコントロールの充分なテストを実施すべきである。 4 監査作業のパフォーマンス 4.1 広範情報システムコントロールのテスト 4.1.1 情報システム監査人は関連する広範情報システムコントロールが監査期間中、または期間中の特定の時 間に有効に稼働していたという保証を提供するために充分なテストを実施すべきである。適切であるかも 知れないテスト手続は以下を含む。 • 観測 • 関連文書（例、方針、基準、議事録）のレビュー • 再パフォーマンス(例、CAATの利用) 4.1.2 関連する広範情報システムコントロールのテストが申し分ないことを示唆するならば、情報システム監査人 は直接的に監査目的に適用される詳細情報システムコントロールに関する、計画された監査で手続きす るべきである。そのテストの水準は、もし広範情報システムコントロールが申し分なく稼働しない場合には、 適切とはいえないかも知れない。 5 報告 5.1 広範情報システムコントロールの弱点 5.1.1 情報システム監査人が広範情報システムコントロールに弱点を識別していた場合、その分野の考慮が、合 意された業務範囲の中に特別に識別されなかったとしても、 マネジメントの注意を喚起すべきである。 5.2 範囲の制限 5.2.1 広範情報システムコントロールが詳細情報システムコントロールの有効性に重要な潜在的効果を持ち、そ れらが監査されていない場合、情報システム監査人は、監査発見事項、結論、推奨事項に関する潜在的効 果を記述するとともに、最終報告書で、この事実にマネジメントの注意を喚起すべきである。例えば、情報 システム監査人がパッケージソフトの調達の監査に関し報告しているが、組織の情報システム戦略を知ら なかった場合、情報システム監査人は、その情報システム戦略が利用可能になっていないか存在しないと いう記述を報告書に含むべきである。関連する場合、情報システム監査人は、例えば、パッケージソフトの 調達が情報システム戦略と整合していて、ビジネスの将来計画を支援するかどうかということを言うのは可 能ではないという記述を通して、監査発見事項、結論、推奨事項に与える潜在的効果を報告し続けるべき である。 6 適用開始日 6.1 本ガイドラインは2000年3月1日以降に開始される全ての情報システム監査に適用される。 本ガイドラインは2008年8月1日にレビューされ、改訂された。 65 G12 組織の関連と独立性 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥67 2 独立性‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥67 3 計画策定‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥68 4 監査業務のパフォーマンス‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥68 5 報告‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥69 6 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥69 G12 組織の関連と独立性 1 背景 1.1 基準との関連 1.1.1 基準S2『独立性』は、 「情報システム監査人は、監査に関するすべての点において、態度に於いても、外見 的にも、被監査人に対し、独立を保つべきである。」と述べている。 1.1.2 基準S2『独立性』は、 「情報システム監査機能は、監査業務の目的完遂を可能とするために、被監査分野 や被監査活動に対し、独立を保つべきである。」と述べている。 1.1.3 基準S3『専門家としての倫理と基準』は、 「情報システム監査人は、 「ISACAの職業倫理規定」を遵守す べきである。」と述べている。 1.2 COBITとの関連 1.2.1 個々の監査範囲に適用可能であるCOBITの中から最も関連する材料の選択は、特定のCOBIT ITプロセ スを選択し、COBITのコントロール目標と関連するマネジメントの実行を勘案して行う。情報システム監査 人の独立性要件に、最も関連しており、選択、適用されるべきCOBITプロセスは、主要および副次的なも のとして分類されている。 1.2.2 PO4『IT プロセスと組織およびそのかかわりの定義』は、 「透明性、柔軟性、即応性を有するIT組織構造 を確立し、ビジネスプロセスと意思決定プロセスに統合されたオーナ、役割および実行責任を含むITプロ セスを定義および導入することに重点をおくことによって、ガバナンス要件を遵守し、明確かつ有能な連絡 窓口を設けるとともに、ビジネス戦略に迅速に対応する。」というITに関わるビジネス要件を満たしている。 1.2.3 副次的参照： • ME2 内部統制のモニタリングと評価 • ME4 ITガバナンスの提供 1.2.4 最も関連する情報要請規準： • 主：有効性および効率性 • 副：機密性、インテグリティ、可用性、コンプライアンスおよび信頼性 1.3 ガイドラインの必要性 1.3.1 本ガイドラインの目的は、基準S2で用いられている「独立性」の意味を詳述し、情報システム監査におけ る情報システム監査人の態度と独立性について取り上げることにある。 1.3.2 本ガイドラインは情報システム監査基準の適用のためのガイダンスを提供する。情報システム監査人は、 基準の導入を達成する方法を決定する際にガイダンスを考慮し、その適用に際して専門家としての判断を 用いるとともに、ガイダンスからの逸脱に際して正当性を説明できるよう準備すべきである。 2 独立性 2.1 態度 2.1.1 情報システム監査人はすべての作業において適用される職業倫理規定および監査基準を遵守するよう努 めるべきである。 2.1.2 COBITによれば、監査ポリシーは、監査機能に関わる独立性、権限および説明責任が維持されること、お よびこれらが組織のマネジメントチームの適切なメンバによって確立されていることを保証すべきである。 67 G12 組織の関連と独立性 3 計画策定 3.1 スタッフィング 3.1.1 情報システム監査人は、監査活動に関与する人々との間に多くの関係を確立するとともに、しばしば組織 全体に及ぶ監査対象領域の深層について調査する機会を有する。情報システム監査人の態度はこのよう な役割を行ううえで常に適切であるべきである。計画策定に際しては既知のすべての関係について考慮す べきである。 3.1.2 情報システム監査人は、その独立性が損なわれる場合には監査に参加してはならない。例えば、情報シス テム監査人が監査の結果の影響によって金銭上の利益やその他の個人的利益を得ることを期待している 場合には、独立性は損なわれる。しかしながら、情報システム監査人の個人的取引が通常の事業の範囲で 発生する情報システムを対象とした監査を実施したとしても、独立性は必ずしも損なわれない。 3.1.3 監査の開始にあたって、情報システム監査人は独立性を宣言するため、利益相反に関するステートメントに サインを要求されることがある。 3.2 優先付けされた監査計画 3.2.1 COBITのプロセスME4は、 「マネジメントは独立監査を計画すべきである」と述べている。この目標を達成 するために監査計画を策定すべきである。監査計画により、セキュリティと内部統制手続の有効性、効率 性および経済性に関して定期的かつ独立した保証が得られていることを検証すべきである。 4 監査業務のパフォーマンス 4.1 組織 4.1.1 情報システム監査人は監査対象領域から組織的に独立しているべきである。情報システム監査人が監査 対象領域において直接的なコントロールを担っている場合、独立性は損なわれる。また、情報システム監 査人が監査対象領域において直接的なコントロールを有する人物に対して直接的な報告責任を有してい る場合にも、独立性は損なわれることがある。さらに、検証対象のコントロールに責任を有しているITグ ループで、結果を上級管理者や経営幹部に報告する人物が、監視目的で監査の進捗状況や問題点などと あわせて監査実施時間を報告するように情報システム監査人に要請する場合にも、独立性が損なわれる 可能性がある。これはITグループのプロジェクトが情報システム監査人を管理している結果、情報システム 監査人の独立性が損なわれると考えられる。加えて、情報システム監査人は、実施作業のスコープが、コン トロールプロセスオーナの事業上あるいは規制目的の要件に基づくものとなっていて、独立性が損なわれ ていないか考慮すべきである。 4.1.2 独立性は定期的に情報システム監査人およびマネジメントにより評価すべきである。評価においては、人 的関係の変化や金銭的利害関係、過去の担当業務と職責といった要素を考慮すべきである。情報システ ム監査人はこの継続的評価プロセスにおいてコントロールセルフアセスメント技法の利用を検討すべきで ある。 4.1.3 割り当てられた業務により、情報システム監査人は担当者へインタビュする、組織のプロセスの分析を行う、 組織のメンバーからの支援を得ることなどができる。このような状況において、情報システム監査人の態度 と外見における独立性は常に適正でなければならない。情報システム監査人は外見的独立性が監査人の 行動や他者との関係によって影響を受けることに留意すべきである。情報システム監査人の独立性がどの ように受け取られているかという点は、監査人が業務を受託するかに影響を与えることがある。 68 G12 組織の関連と独立性 4.2 情報収集 4.2.1 監査対象の組織について理解するために必要な様々な事項のうち、情報システム監査人がその独立性を 維持するうえで検討すべきものは次の通りである。 • 独立性保証プロセスに関わる組織のポリシーと手続 • 監査ポリシー、職務記述書、ポリシー、手続と基準、過去の報告書および監査計画 • 組織図 4.3 コントロールの評価 4.3.1 情報システム監査計画には、情報システム監査人の独立性が要求される活動を定義すべきである。これら の活動からの情報システム監査人の独立性は、定期的に上級管理者もしくは情報システム監査計画を決 定、承認する人物によってモニタリングされるべきである。このモニタリングには、個々の情報システム監 査人が独立性と十分なスキルを有することを保証していることを確かめるため、監査業務の割り当てを行 うプロセスの評価を含めるべきである。 4.3.2 情報システム監査人が、適用される専門家としての行動規範を遵守しているかという確認は、常に実行され るべきである。多くの場合、この確認は独立性の監査証拠として十分である。情報システム監査人の独立 性が危うくなる兆候が見られた際には、監査計画の改訂を検討すべきである。 5 報告 5.1 報告への影響 5.1.1 情報システム監査人の独立性が損なわれているにも拘わらず、情報システム監査人が監査に関与している 場合には、情報システム監査人の独立性の問題に関わる事実関係を適切なマネジメントに通知するととも に、報告書上に開示すべきである。 6 適用開始日 6.1 本ガイドラインは2000年9月1日以降に開始されるすべての情報システム監査に適用される。 本ガイドラインは2008年8月1日にレビューされ、改訂された。 69 G13 監査計画におけるリスク評価の使用 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥71 2 計画策定‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥72 3 監査作業パフォーマンス‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥74 4 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥74 G13 監査計画におけるリスク評価の使用 1 背景 1.1 基準との関連 1.1.1 基準S5『計画策定』は、 「情報システム監査人は、監査の目的を満たし、関係諸法規と当該分野の諸監 査基準に準拠するよう、情報システム監査の範囲を定めた計画を策定すべきである。」と述べている。 1.1.2 基準S6『監査業務のパフォーマンス』は、 「監査の過程において、情報システム監査人は、監査の目的を 達成するために、確実で妥当な証拠を充分得るべきである。監査の発見事項と監査の結論は、この証拠 を適切に分析し、解釈することにより裏付けられる。」と述べている。 1.1.3 情報システム監査ガイドラインG15『監査計画策定』の段落2.4.1は、 「リスクの評価は、重要な項目が監 査の作業中に十分にカバーされる合理的な保証が提供されるべきである。この評価は、重要な問題の存 在という比較的高いリスクの領域を識別するべきである。」と述べている。 1.2 手続との関連 1.2.1 本ガイドラインは、情報システム監査の手続P1『情報システムリスク評価測定』と組み合わせて使用する ことができる。 1.3 COBITとの関連 1.3.1 個々の監査範囲に適用可能であるCOBITの中から最も関連する材料の選択は、特定のCOBIT ITプロセ スを選択し、COBITのコントロール目標と関連するマネジメントの実行を勘案して行う。情報システム監査 人が必要とする監査文書に合わせるべく、最も関連し、選定され、採用されそうなCOBITのプロセスが、こ こで主要なものと副次的なものとして分類されている。 1.3.2 PO9『ITリスクの評価と管理』は、 「ビジネスや運用リスク管理フレームワーク、リスク評価、リスクの軽減 と残留リスクの報告に統合されているリスク管理のフレームワークの開発に注力することによるビジネスプ ロセスと目標に対するITリスクとその潜在的な影響を分析し周知する。」というITに関するビジネス要件を 満足している。 1.3.2 ME2『内部統制のモニタリングと評価』は、 「IT関連のアクティビティの内部統制プロセスのモニタリング することと改善アクションを識別することに注力することにより、IT目標の達成を保護し、IT関連の法律、 規制、契約に従う。」というITに関するビジネス要件を満足している。 1.3.5 副次的参照： • ME3 規制に対するコンプライアンスの保証 • ME4 ITガバナンスの提供 1.3.6 最も関連している情報規準は、 • 主：機密性、インテグリティ、可用性 • 副：有効性、効率性、コンプライアンス、信頼性 1.4 ガイドラインの必要性 1.4.1 特定の監査目的を満たすために必要な監査作業のレベルは、情報システム監査人の主観的判断である。 監査発見事項に基づく誤った結論に達するリスク（監査リスク）は、この決定の1つの側面である。もうひ とつは、監査される領域で発生するエラーのリスク（エラーリスク）である。会計監査を実施する際にリス ク評価のための推奨される業務は会計監査人に対する監査基準によく文書化されているが、情報システム 監査にこのような技法をどのように応用するかの手法が必要とされている。 71 G13 監査計画におけるリスク評価の使用 1.4.2 また、 マネジメントメンバーは、自分達が受容しうるリスク脅威の水準の評価にどれほどのコントロールが 適切かという意思決定に基づいている。例えば、ある期間のコンピュータアプリケーション未稼働は予期 しえぬ望ましくない事象（例えば、データセンター火災）から生じ得る一つの脅威である。脅威は適切に設 計されたコントロールの実装によって低減することができる。これらのコントロールは通常、有害事象の発 生確率の推定に基づいており、その確率を減らすためのものである。例えば、火災警報器は火災を防ぐこ とはないが、火災被害の程度を軽減するためのものである。 1.4.3 本ガイドラインは、情報システム監査基準を適用する手引きを提供している。情報システム監査人は、どの ように基準S5とS6の実装を達成するかを決定する際にそれを考慮し、その応用で専門的な判断を使用し、 いかなる逸脱をも正当化する覚悟をすべきである。 2 計画策定 2.1 リスク評価手法の選択 2.1.1 情報システム監査人が選択することができる多くのリスク評価手法がある。これらは、情報システム監査人 の判断に基づく高、中、低の単純な分類から、数値リスク評価を提供する複雑で明らかに科学的な計算ま である。情報システム監査人は、監査される組織に適切な複雑さや詳細さのレベルを考慮するべきである。 2.1.2 情報システム監査人は、システムの可用性、データインテグリティ、ビジネス情報の機密性をサポートする コントロールとそれらの損失に起因する企業へのリスクの、手法の範囲内での分析を、少なくとも含めるべ きである。 2.1.3 すべてのリスク評価手法は、プロセス（例えば、様々なパラメータに重み付けを割り当てるためにとか）のあ る点で主観的な判断に依存している。情報システム監査人は、特定の手法を使用するに必要な主観的な 意思決定を識別し、これらの判断がなされ、精度上適切なレベルで有効かどうかを考慮すべきである。 2.1.4 最も適切なリスク評価手法であるかを決めるうえで、監査人は、次のようなことを考慮するべきである。 • 収集されるに必要な情報の種類（あるシステムでは、唯一の対策として、金融の効果を使用する---これ は情報システム監査において必ずしも適切ではない） • 手法を使用するために必要なソフトウェアまたは他のライセンスのコスト • 必要な情報が既に提供されている程度 • 信頼性の高い出力入手の前に収集するために必要な追加情報の量、および、この情報を収集するため のコスト（収集活動に投資する必要な時間を含む） • 選んだ手法に対する他のユーザーの意見、および、監査の効率性、有効性を向上させる際にその方法が どのようによく支援するかの彼らの見識 • 実施される監査作業の種類とレベルを決定する手段として、その方法を受け入れるマネジメントの意欲 2.1.5 すべての状況において適切である単一のリスク評価手法があるとは期待できない。監査に影響を与える条 件は、時間の経過とともに変化するかもしれない。定期的に、情報システム監査人は、選択されたリスク評 価手法の妥当性を再評価するべきである。 2.2 リスク評価の使用 2.2.1 全体的な監査計画の開発と特定の監査を計画を行う際に、情報システム監査人は選択されたリスク評価 技法を使用するべきである。他の監査技法との組み合わせで、リスク評価は次のような計画決定をする際 に考慮されるべきである。 • 監査手続の種類、程度および時期 • 監査する領域あるいはビジネス機能 • 一監査に割り当てられる時間と資源の量 72 G13 監査計画におけるリスク評価の使用 2.2.2 情報システム監査人は、全体的なレベルを決定するために、次のようなリスクの種類それぞれを考慮すべ きである。 • 固有リスク • 統制リスク • 発見リスク 2.3 固有リスク 2.3.1 固有リスクは、関連する内部統制が存在しないと仮定した場合、重大であったり、個別であったり、他のエ ラーと組合わさったりする方法でのエラーに対する監査領域の敏感性である。例えば、オペレーティングシ ステムセキュリティに関連付けられる固有リスクは、オペレーティングシステムセキュリティの弱点を通して データやプログラムへの変更、あるいは開示が、事実に反するマネジメント情報あるいは競争上不利な立場 という結果になりうるので、通常は高い。これとは対照的に、スタンドアローンPCに対するセキュリティに 関連付けられる固有リスクは、適切な分析が、ビジネス上重要な目的のために使用されていないことを示し ている場合、通常低い。 2.3.2 たいていの情報システム監査領域に対する固有リスクは、エラーの潜在的な影響が複数のビジネスシステ ムと多くのユーザーに普通広がることから、通常は高い。 2.3.3 固有リスクを評価する際には、情報システム監査人は広範かつ詳細な情報システム管理策を考慮すべきで ある。このことは、情報システム監査人の任務が広範な情報システム管理策にのみ関連する状況には適用 されない。 2.3.4 広範な情報システムコントロールレベルにおいて、情報システム監査人は、質問する際に監査領域の適切 なレベルまで、以下を考慮すべきである。 • 情報システム管理と情報システム管理の経験と知識のインテグリティ • 情報システム管理における変更 • 情報を隠すか誤らせる素因となりえる情報システム管理への圧力（例えば、大規模なビジネス上重要な プロジェクトの超過やハッカーのアクティビティ） • 組織のビジネスやシステムの種類（例えば、Eコマースの計画、システムの複雑さ、統合システムの欠如） • 組織の業界全体に影響を与える要因（例えば、技術の変化、情報システムスタッフの空状況） • 監査対象システムのコントロールに与えるサードパーティの影響力のレベル（例えば、サプライチェーン の統合、アウトソーシングした情報システムプロセス、共同事業、および顧客からの直接アクセスを原因 とする） • 過去の監査からの発見事項およびその監査日 2.3.5 詳細な情報システムコントロールレベルにおいて、情報システム監査人は、質問する際に監査領域の適切 なレベルまで、以下を考慮すべきである。 • この領域における、過去の監査からの発見事項とその監査日 • 関与するシステムの複雑さ • 必要な手動の介入のレベル • システム（例えば、在庫管理、給与計算）によって制御される資産の損失や不正に対する敏感性 • 監査期間中、ある時間帯でのアクティビティピークの可能性 • 情報システム処理の日々のルーチン以外のアクティビティ（例えば、データを修正するためにオペレー ティングシステムのユーティリティの使用） • 情報システムコントロールを実施する際に関与しているマネジメントとスタッフのインテグリティ、経験、 スキル 73 G13 監査計画におけるリスク評価の使用 2.4 コントロールリスク 2.4.1 コントロールリスクとは、監査領域で発生し、重大か個別かまたは他のエラーとの組合わされる可能性の あるエラーが、内部統制システムによって適時に防御、検出、修正することができないリスクである。例え ば、コンピュータログのマニュアルレビューに関連付けられるコントロールリスクは、リスクが高い可能性が ある。これは、調査を必要とするアクティビティがログに残る情報量によりしばしば簡単に見逃されてしま うからである。コンピュータ化されたデータの検証手続に関連付けられた統制リスクは、そのプロセスが一 貫して適用されていることから、通常リスクが低い。 2.4.2 関連する内部統制が次に該当しない限り、情報システム監査人は、コントロールリスクが高いと評価するべ きである。 • 識別されている • 有効としての評価されている • テスト済みで適切に稼働しているとわかっている 2.5 発見リスク 2.5.1 発見リスクとは、情報システム監査人の実質的な手続が重大か個別かあるいは他のエラーと組合わされる エラーを発見しないリスクである。 例えば、アプリケーションシステムのセキュリティ障害を識別することに関連付けられる発見リスクは、監 査の全期間に亘るログが監査の時に利用できないため、通常リスクが高い。災害復旧計画の欠如を識別 することに関連付けられる発見リスクは、存在が容易に確認されるため、通常リスクが低い。 2.5.2 必要とされる実質的なテストのレベルを決定する際に、情報システム監査人は、次の両方を考慮するべき である。 • 固有リスクの評価 • コンプライアンステストに続くコントロールリスクに関して達した結論 2.5.3 固有リスクとコントロールリスクの評価が高くなればなるほど、通常、情報システム監査人はより多くの監 査証拠を実質的な監査手続を実施して入手すべきである。 3 監査作業パフォーマンス 3.1 文書の作成 3.1.1 情報システム監査人は、特定の監査に使用されるリスク評価技法や手法を文書化することを考慮すべきで ある。文書化には、通常、次の事項を含めるべきである。 • 使用されるリスク評価手法の説明 • 重要な脅威の識別と対応するリスク • 監査が対処するためのリスクとその脅威 • 情報システム監査人のリスク評価を支援するために使用される監査証拠 4 適用開始日 4.1 本ガイドラインは、2000年9月1日以降に開始されるすべての情報システム監査に適用される。 本ガイドラインは、2008年8月1日にレビューされ、改訂された。 74 G14 アプリケーションシステムレビュー 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥76 2 計画‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥77 3 監査作業のパフォーマンス‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥78 4 報告‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥79 5 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥79 G14 アプリケーションシステムレビュー 1 背景 1.1 基準との関連 1.1.1 基準S６『監査作業のパフォーマンス』は「監査の過程において、情報システム監査人は、監査目標を達成 するために、充分、信頼性があり、関連付けられる証拠を入手すべきである。監査の発見事項と監査の結論 は、この証拠を適切に分析し、解釈することにより裏付けられる。」と述べている。 1.2 COBITとの関連 1.2.1 個々の監査範囲に適用可能であるCOBITの中から最も関連する材料の選択は、特定のCOBIT ITプロセ スを選択し、COBITのコントロール目標と関連するマネジメントの実行を勘案して行う。情報システム監査 人が必要とするG14『アプリケーションシステムレビュー』の要件に合わせるべく、最も関連し、選定され、 採用されそうなCOBITのプロセスが、ここで主要および副次的なものとして分類されている。選定され、採 用されるべきプロセスとコントロール目的は、特定の範囲と任務の権限次第で変化するかもしれない。 1.2.2 主要な参照： • PO9 ITリスクの評価と管理 • AI2 アプリケーションソフトウェアの調達と保守 • DS5 システムセキュリティの保証 • ME2 内部統制のモニタリングと評価 1.2.3 副次的参照： • PO7 IT人材の管理 • PO8 品質管理 • AI6 変更管理 • DS3 性能とキャパシティの管理 • DS10 問題管理 • DS11 データ管理 1.2.4 アプリケーションシステムレビューに最も関連する情報要請規準： • 主：可用性、信頼性、インテグリティ、機密性 • 副：コンプライアンス、有効性、効率性 1.3 ガイドラインの必要性 1.3.1 本ガイドラインの目的は、 アプリケーションシステムレビューを行う上で推奨される慣行を説明することである。 1.3.2 アプリケーションシステムレビューの目的は、 関連するコントロール目標を達成するために組織によって実装されているアプリケーションへのコントロー ルを識別・文書化・テスト・評価することである。 76 G14 アプリケーションシステムレビュー 2 計画 2.1 計画の考慮事項 2.1.1 計画の不可欠な部分は、情報システム監査人がシステムの規模・複雑さと組織の情報システムへの依存度 を見極めるのに充分な組織の情報システム環境の理解である。情報システム監査人は企業の使命・ビジネ ス目標、企業を支援するための情報技術と情報システムの使用されるレベルと方法、そして組織の目標と その情報システムに関連するリスクと発現の理解を得るべきである。そして、主な情報システムスタッフとア プリケーションシステムの業務プロセスオーナの役割・責任を含む組織構造の理解を得るべきである。 2.1.2 計画の主な目的は、アプリケーションレベルのリスクを識別することである。リスクの相対的なレベルが必 要な監査証拠のレベルに影響を与える。 2.1.3 システムとデータのレベルでアプリケーションレベルのリスクは以下のような事項を含む。 • システムの運用能力の欠如に関連するシステムの可用性リスク • システムおよびデータへの未承認アクセスに関連するシステムセキュリティリスク • 不完全・不正確・時宜を得ていない・未承認データ処理に関連するシステムのインテグリティリスク • システムの可用性・セキュリティ・インテグリティのために提供し続けるように要求されるシステムを更新 することができないことに関連するシステムの保守性リスク • 網羅性・インテグリティ・機密性・個人情報・正確性に関連するデータリスク 2.1.4 アプリケーションレベルのリスクに対処するためのアプリケーションコントロールは、システムに組み込ま れているコンピュータ化されたコントロール・手動で実行されるコントロール・その両方の組合わせという 形かも知れない。例としては、文書（発注書、請求書、受領書など）のコンピュータ突合・コンピュータ生成 小切手の確認・署名・上級マネジメントによる例外レポートのレビューを含んでいる。 2.1.5 プログラムされたコントロールに依存する選択した場合、関連するIT全般統制が監査目標に具体的に関連 するコントロール同様考慮さるべきである。IT全般統制が、物理的コントロール・システムレベルのセキュ リティ・ネットワーク管理・データバックアップ・緊急事態対応計画などを含む別々のレビューを受けること がある。レビューの統制目的によっては、情報システム監査人はアプリケーションシステムが取得の対象と して評価されている場合などは全般統制をレビューする必要はないかも知れない。 2.1.6 アプリケーションシステムレビューは、パッケージアプリケーションのシステムが取得の対象として評価さ れているときにアプリケーションシステムが本番稼働する前（導入前）とアプリケーションシステムが本番 稼働した後（導入後）に行われることがある。導入前のアプリケーションシステムのレビュー範囲は、アプ リケーションレベルのセキュリティアーキテクチャ・セキュリティ実装のための計画・システム・ユーザーマ ニュアルの妥当性・実行済みあるいは計画されているユーザ受入れテストの妥当性を含んでいる。 導入後レビュー範囲は、導入後のアプリケーションレベルのセキュリティと旧システムから新しいシステム へのデータとマスターファイル情報の転送が行われてある場合システム変換を含んでいる。 77 G14 アプリケーションシステムレビュー 2.1.7 アプリケーションシステムレビューの目的と範囲は通常、委任事項の一部を形成する。委任事項の形式と 内容は、変化し得るが以下を含むべきである。 • レビューの目標と範囲 • レビューを行う情報システム監査人 • 情報システム監査人がプロジェクトから独立しているという記述 • レビューが開始される日付 • レビューの時間枠 • レポートの準備 • 最終打合せの準備 • 目的は７つのCOBITの情報規準に対処するために開発され、組織により合意されるべきである。７つの COBITの情報規準は以下である。 –– 有効性 –– 効率性 –– 機密性 –– インテグリティ –– 可用性 –– コンプライアンス –– 情報の信頼性 2.1.8 情報システム監査人が以前にアプリケーションシステムの開発、取得、導入、または保守に関与していて 監査業務に任命された場合、情報システム監査人の独立性が損なわれる可能性がある。情報システム監査 人は、そのような状況に対処するために適切なガイドラインを参照すべきである。 3 監査作業のパフォーマンス 3.1 業務フローの文書化 3.1.1 収集した情報は、システムのコンピュータ化された側面と手動の側面の両方を含むべきである。焦点は、 監査目的に重要であるデータ入力（電子的または手動であれ）、処理、保管、そして出力に当てるべきであ る。情報システム監査人は、業務プロセスと技術の用途によっては、業務フローを文書化するのを実用的 ではないことがわかるかも知れない。その場合、情報システム監査人は、大まかなデータフロー図・概要 を作成・提供されていれば、システム図を使用すべきである。また、他のシステムとのアプリケーションイン ターフェースを文書化することを考慮すべきである。 3.1.2 情報システム監査人は、ウォークスルーテストのような手続を実行することによって文書化を確認すべきで ある。 3.2 アプリケーションシステムコントロールの識別とテスト 3.2.1 コントロールが意図しているように機能しているという保証を得れるように、情報システム監査人はアプリ ケーションのリスクを軽減するための特定のコントロールを識別し、そして十分な監査証拠を得ることがで きる。それを実現するには以下のような手続で行われる。 • 照会と観察 • 文書のレビュー • プログラムされたコントロールがテストされているアプリケーションシステムコントロールのテスト。コン ピュータ支援監査技法の使用(CAAT)を考慮すべきである 78 G14 アプリケーションシステムレビュー 3.2.2 テストの種類・時期・程度はレビューされる領域のリスクのレベルと監査目標に基づくべきである。強力な IT全般統制がない場合、情報システム監査人はこの欠陥によるコンピュータ化されたアプリケーションコン トロールの信頼性への影響を評価をすることがある。 3.2.3 情報システム監査人が、コンピュータ化されたアプリケーションコントロールの中での重大な欠陥を見つけ た場合、 （監査の目的に応じて）可能であれば、手動で実行されるプロセスコントロールから保証を取得す るべきである。 3.2.4 コンピュータ化されたコントロールの有効性は、強いIT全般統制に依存している。そのため、IT全般統制が 検討されていない場合アプリケーションコントロールへの依存することは著しく限られ、監査人は、代替の 手続を考慮する必要がある。 4 報告 4.1 欠陥 4.1.1 アプリケーションレビューで識別されたコントロールの欠如かコンプライアンス違反による欠陥は、業務プ ロセスオーナとアプリケーション支援に責任のある情報システムのマネジメントの注意を喚起するべきで ある。アプリケーションシステムレビュー中に識別された欠陥が、重要・重大と考えられる場合、適切なレ ベルのマネジメントは即座に是正処置を実施するよう勧告されるべきである。 4.1.2 効果的なコンピュータ化されたアプリケーションコントロールは、IT全般統制に依存しているため、この領 域の欠陥も報告されるべきである。IT全般統制がレビューされなかった場合、その事実は報告書に含まれ るべきである。 4.1.3 情報システム監査人は、報告書の中にコントロールを強化するための適切な勧告を含めるべきである。 5 適用開始日 5.1 本ガイドラインは、2001年11月1日以降に開始される全ての情報システム監査に適用される。 本ガイドラインは、2008年12月1日にレビューされ、改訂された。 79 G15 監査計画策定 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥81 2 予備業務アクティビティ‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥82 3 計画策定‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥82 4 監査過程中における変更‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥84 5 監督‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥84 6 文書化‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥84 7 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥85 G15 監査計画策定 1 背景 1.1 基準との関連 1.1.1 基準S5『計画策定』は、次のように述べている。 「IT監査・保証の専門家は、監査の目的を満たし、関係諸法規と当該分野の諸監査基準に準拠するよう、 情報システム監査の範囲を計画すべきである。IT監査・保証の専門家は、以下を導入・構築し、文書化す べきである。 • リスクベースの監査手法 • 種類、目的、時期と程度、対象、必要な資源を詳述した監査計画 • 監査を完遂するに必要な監査手続の種類、時期、程度を詳述する監査プログラムあるいは計画」 1.1.2 基準S11『監査計画立案時のリスク評価の使用』は、IT監査・保証の専門家は次のことを行うべきである と述べている。 • 包括的なIT監査計画を開発し、IT監査のための資源の効果的な配分のための優先順位を決めるに当た り、適切なリスク評価手法を使用する • 個別分野のレビューを計画するに当たり、レビュー対象と他の監査すべき領域との関係に関連するリス クを識別し、評価する 1.1.3 基準S12『監査の重要性』は、IT監査・保証の専門家は次のことを考慮すべきであると述べている。 • 監査手続の種類、時期、程度を決定する際に、監査の重要性および監査リスクとの関連性 • 監査計画の策定において、潜在的なコントロールの欠陥、欠如を考慮し、さらに、コントロールの欠陥ま たは欠如が情報システムの重要な不備または重大な欠陥になりうること • 軽微なコントロールの不備またはコントロールの欠陥と欠如が累積することにより、情報システムにとっ て重要な不備や重大な欠陥となりうること 1.2 COBITとの関連 1.2.1 個々の監査範囲に適用可能であるCOBITの中から最も関連する材料の選択は、特定のCOBIT ITプロセ スを選択し、COBITのコントロール目標と関連するマネジメントの実行を勘案して行う。IT監査・保証の専 門家が必要とするITガバナンスに合わせるべく、最も関連し、選定され、採用されそうなCOBITのプロセ スが、ここで主要および副次的なものとして分類されている。選定され、採用されるべきプロセスとコント ロール目的は、特定の範囲と任務の権限次第で変化するかもしれない。 1.2.2 主要な参照： • ME1 IT成果のモニタリングと評価 • ME2 内部統制のモニタリングと評価 • ME3 外部要件に対するコンプライアンスの保証 1.2.3 副次的参照： • ME4 ITガバナンスの提供 1.2.4 最も関連する情報要請規準： • 主：有効性、効率性、可用性、コンプライアンス • 副：機密性、インテグリティ、信頼性 81 G15 監査計画策定 1.3 ガイドラインの必要性 1.3.1 本ガイドラインの目的は、ITAF（IT保証に関する専門家としての実践フレームワーク）の基準S5に述べら れているような計画プロセスの構成要素を定義することである。 1.3.2 本ガイドラインはまた、COBITが据えた対象に合わすべく監査プロセスの中で計画策定のため提供する。 2 予備業務アクティビティ 2.1 目的 2.1.1 これらの予備業務アクティビティを実施する目的は、IT監査・保証の専門家が、監査業務を計画・実行す る自分達の能力に悪影響を与えるかもしれないあらゆる事象や状況を考慮したことを保証し、監査リスク を許容可能な低いレベルまで軽減することを支援することである。これらの予備業務アクティビティの実 施は、業務計画が以下を含むことを保証することを支援する。 • IT監査・保証の専門家は業務を実施するために必要な独立性と能力を維持する • IT監査・保証の専門家の業務を継続する意欲に影響を与える可能性があるマネジメントインテグリティ に問題がない • 業務の条件に関して、クライアントと齟齬がない 2.2 アクティビティ 2.2.1 IT監査・保証の専門家は、クライアントとの関係、特定の監査業務の継続性に関する手続を実行すべきで ある。監査契約を継続するために、このような初期手続が、多くの場合、前回の監査の直後（あるいは続け て）に発生する。 2.2.2 IT監査・保証の専門家は、独立性を含む倫理要件の遵守を評価するべきである。クライアントの継続性と 倫理要件（独立性を含む）の評価の両方に関する、IT監査・保証の専門家の初期手続は、現在の監査業 務のための他の重要なアクティビティを実行する前に実行される。 2.2.3 IT監査・保証の専門家は、業務用語の理解を確立するべきである。 3 計画策定 3.1 監査戦略 3.1.1 IT監査・保証の専門家は、効果的な方法で実行されるように業務を計画し、監査の全体的な監査戦略を 確立すべきである。十分な計画策定は、適切な注意が監査の重要な領域に向けられ、潜在的な問題が識 別され、適時に解決され、そして、監査業務が、効果的かつ効率的な方法で実施されるべく、適切に組織化 され管理されていることを保証するに役立つ。 3.1.2 明確なプロジェクトの定義は、プロジェクトの有効性と効率性を保証するために重要成功要因である。監 査プロジェクトは、委任事項として次の項目を含むべきである。 • 監査される領域 • 計画された作業の種類 • ハイレベルな目的と作業範囲 • テーマ、例えば、予算、資源配分、日程、報告書の種類、正規の報告書受領者 • 該当する場合は、作業のその他の一般的な側面 3.1.3 内部監査部門にとっては、包括的なリスクベースの監査計画がアクティビティ進行中に少なくとも年に一 度、開発／更新されるべきである。このハイレベルの計画は、監査アクティビティの為のフレームワークの 役目を果たし、監査ポリシーが定めた責任に対処するのに役立つべきである。 82 G15 監査計画策定 3.1.4 計画は、通常、監査任務ごとに準備されるべきである。その計画は監査の目的を文書にするべきである。 3.1.5 各監査プロジェクトは、全体監査計画に、あるいは、特定の任務、目標、実施される作業の他の関連する 側面の状況のいずれかに参照されるべきである。 3.1.6 IT監査・保証の専門家は、監査領域に関連する被監査人の目標と関連技術インフラストラクチャを考慮し た監査計画を開発すべきである。必要に応じて、彼らはまた、被監査人に関係するIT戦略計画と他の関連 文書を含め、レビュー中の領域とその領域の企業との関係（戦略的、財政的、または運用）を考慮し、戦 略計画に関する情報を入手するべきである。 3.1.7 IT監査・保証の専門家は、被監査人の情報アーキテクチャや、被監査人の現在の、必要に応じて将来の 技術に適切な計画を設計できる技術的な方向を理解するべきである。 3.2 対象企業体の知識 3.2.1 被監査人のビジネスと被監査人が直面するリスクを理解することは、詐欺的な、不正確な慣行に対して もっとも敏感な領域に焦点を当てた効果ある監査計画を開発する重要なステップである。 3.2.2 監査プロジェクトを開始する前に、IT監査・保証の専門家の作業が監査目標を満足するに適した方法で 計画されるべきである。計画策定プロセスの一部として、企業とそのプロセスを理解するべきである。IT監 査・保証の専門家にその企業の運営とそのIT要求事項を理解させることに加えて、彼らが企業の目標に関 連しているとしてレビューされるIT資源の重要性を決定する際に、企業とそのプロセスの理解は支援する。 IT監査・保証の専門家は、また、監査作業の範囲を確立し、レビューされている部門に関わる内部統制に 対する予備評価を実施すべきである。 3.2.3 IT監査・保証の専門家によって必要とされる企業とそのプロセスの知識の程度は、その企業の性質と監査 作業が実施されている項目レベルによって決定されるだろう。稀なまたは複雑な作業を扱う際に、IT監査・ 保証の専門家は特別な知識を必要とするかもも知れない。監査目的が限られた機能に対するときよりも、 IT機能の広い範囲に関わるとき、企業とそのプロセスに関するさらに広範な知識が通常必要とされるだろ う。例えば、企業の給与システムのコントロールを評価することを目的としたレビューは、通常、特定のプロ グラムライブラリシステムに関わるコントロールをテストすることを目的としたレビューよりも、より徹底し た企業の理解が必要になる。 3.2.4 IT監査・保証の専門家は、監査プロジェクトの主題である特定の企業、機能、プロセス、あるいはデータ に重要な影響を持ちえる、人材、事象、取引、慣行の種類を理解すべきである。対象企業体の知識は、その 企業が存在する市場の状況と、その企業がその目標を達成するためにアウトソーシングに依存している程 度同様、その企業に立ちはだかるビジネスリスク、財政リスク、固有リスクを含めるべきである。IT監査・保 証の専門家は、潜在的な問題を識別し、作業の目的と範囲を策定し、作業を実施し、警戒すべきマネジメン トのアクションを考慮する際に、この情報を使用するべきである。 3.3 重要性 3.3.1 計画プロセスにおいて、IT監査・保証の専門家は通常、監査作業が監査の目的を充分に満たし、効率的に 監査資源を使用するような計画策定の重要性のレベルを確立するべきである。例えば、実在するシステム のレビューにおいて、IT監査・保証の専門家は、実行される作業のための監査プログラムを計画する際に システムのさまざまなコンポーネントの重要性を評価する。定性面、定量面の双方が、重要性を決定する 際には、考慮されるべきである。 3.4 リスク評価 3.4.1 IT監査・保証の専門家は、監査が監査リスクを許容レベルまで軽減するための監査計画を開発するべき である。 3.4.2 リスク評価は、すべての重要な項目が適切に監査作業中にカバーされるという合理的な保証を提供するた めに実施されるべきである。この評価は、重要な問題の比較的高い確率の領域を識別するべきである。 83 G15 監査計画策定 3.4.3 レビュー中の領域と対象企業体のIT環境に対する識別されたリスクのリスク評価と優先順位付けは、必 要な程度まで実行されるべきである。 3.5 内部統制評価 3.5.1 監査と保証のプロジェクトは、直接的にプロジェクト目的の一部としてか、プロジェクトの一部として集め られた情報に依存するための基礎としてか、内部統制の考慮を含めるべきである。その目的が内部統制の 評価である場合、IT監査・保証の専門家はそのようなコントロールをレビューする必要がある程度を考え るべきである。目的が一定期間のコントロールの有効性を評価することになっているときは、監査計画は、 監査目的を充足するに適切な手続を含めるべきであり、これらの手続は、コントロールのコンプライアンス テストを含めるべきである。目的が、一定期間のコントロールの有効性を評価するのではなく、どちらかと 言うと、一時点のコントロール手続を識別することになっているときは、コンプライアンステストが除外され るかもしれない。 3.5.2 IT監査・保証の専門家は、監査の一部として集められた情報の支援の中でコントロール手続に依存する目 的のために内部統制を評価するとき、通常、コントロールの予備評価をし、この評価に基づく監査計画を 開発すべきである。レビュー期間中には、IT監査・保証の専門家は、テスト期間中に依存できるコントロー ルの程度を決定する際に、この評価の妥当性を考慮すべきである。例えば、データファイルをテストするた めにコンピュータプログラムを使う際に、IT監査・保証の専門家は、プログラムが無許可の変更から保護 される程度を決定する監査目的に対して使用されたプログラムを含むプログラムライブラリに関わるコント ロールを評価すべきである。 4 監査過程中における変更 4.1 戦略と計画策定 4.1.1 全体監査戦略と監査計画は、監査過程中必要に応じ更新・変更されるべきである。 4.1.2 監査の計画策定は、反復的で双方向のプロセスである。予期せぬ事象、条件変更、監査手続の結果から 得られる監査証拠の結果として、IT監査・保証の専門家は、監査戦略とその結果として全体監査戦略と、 さらなる監査手続の計画された種類、時期、程度を修正する必要があるかも知れない。 4.1.3 監査計画策定は、対象企業体にとっての高リスクに関係する予期せぬ事象の可能性を考慮すべきである。 したがって、監査計画は、リスクに適切な方法で監査と保証のプロセスのなかでこのような事象を優先順 位付けすることができなければならない。 5 監督 5.1 契約チームメンバー 5.1.1 IT監査・保証の専門家は、契約チームメンバーの方向付けと監督の種類、時期、程度を計画し、彼らの作 業をレビューすべきである。その計画策定は、企業の規模と複雑性、監査の領域、重要な虚偽表示のリス ク、監査作業を行う要員の能力と力量、重要な虚偽表示の評価されたリスクに基づく監査チームメンバー の方向付けと監督の程度を含む多くの要因次第である。 6 文書化 6.1 計画策定文書の作成 6.1.1 IT監査・保証の専門家の作業文書は監査計画とプログラムを含むべきである。 6.1.2 監査計画は、書面、あるいは、他の適切で取り出し可能なフォームで文書化されてよい。 84 G15 監査計画策定 6.2 計画保証 6.2.1 適切な程度までは、監査計画、監査プログラムとそれ以降の変更は、監査マネジメントによって承認され るべきである。 6.3 監査プログラム 6.3.1 レビューの予備プログラムは、通常、作業に入る前にIT監査・保証の専門家によって確立されるべきであ る。この監査プログラムは、IT監査・保証の専門家が監査作業の完了を記録し、未了の作業を識別するこ とを許すような方法で文書化されるべきである。作業進捗として、IT監査・保証の専門家は、監査期間中 に集めた情報に基づく監査プログラムの充分性を評価すべきである。IT監査・保証の専門家が計画され た手続が充分でないと決定するときは、監査プログラムをしかるべく修正すべきである。 6.3.2 要求される監査資源によって、IT監査・保証の専門家は、監査計画のなかで必要とされる要員のマネジメ ントを含めるべきである。 6.3.3 監査計画は、ITAFで定義されるような基準に加えて適切な外部要求事項と一致するように準備されるべ きである。 6.3.4 完了すべき作業の表作成に加えて、IT監査・保証の専門家は、実施可能な程度まで、作業・作業スケ ジュール・予算を完了するために必要な要員と他の資源の表を準備すべきである。 6.3.5 監査中に発生する問題（新リスク、不適切な仮定、あるいは、既に実施した手続での発見事項）に取組む 監査過程の中で監査プログラム・計画は調整されるべきである。 7 適用開始日 7.1 本ガイドラインは、2010年5月1日以降に開始されるすべてのIT監査に適用される。 85 G16 企業のITコントロールに関わる サードパーティの影響 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥87 2 サードパーティサービスプロバイダーの役割‥ ‥‥‥‥‥‥‥‥‥‥88 3 コントロールの有効性‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥88 4 情報システム監査人により実施される手続‥ ‥‥‥‥‥‥‥‥‥‥‥89 5 サードパーティプロバイダーに関するリスク‥ ‥‥‥‥‥‥‥‥‥‥90 6 サードパーティプロバイダーとの契約‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥90 7 サードパーティプロバイダーに関するコントロールのレビュー‥ ‥‥92 8 サードパーティの再委託先‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥94 9 報告‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥94 10 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥94 G16 企業のITコントロールに関わるサードパーティの影響 1 背景 1.1 基準との関連 1.1.1 基準S5『計画策定』は、 「情報システム監査人は、監査の目的を満たし、適用可能な専門の監査基準に 準拠するよう、情報システム監査の範囲を定めた計画を策定すべきである。」と述べている。 1.1.2 基準S6『監査業務のパフォーマンス』は、 「監査の過程において、情報システム監査人は、監査の目的を 達成するために、十分かつ確実で関連性のある証拠を入手すべきである。監査の発見事項と監査の結論 は、この証拠を適切に分析し、解釈することにより裏付けられる。」と述べている。 1.2 COBITとの関連 1.2.1 個々の監査範囲に適用可能であるCOBITの中から最も関連する材料の選択は、特定のCOBIT ITプロセ スを選択し、COBITのコントロール目標と関連するマネジメントの実行を勘案して行う。情報システム監査 人としての責任、権限および説明責任の要件を満たすため、ここでは、最も関連し、選択・採用されるべき COBITのプロセスを主要および副次的なものに分類している。選択・採用されるべきプロセスおよびコン トロール目標は、実施する監査の範囲および条件により異なるかもしれない。 1.2.2 主要な参照： • PO4 ITプロセスと組織およびそのかかわりの定義 • PO7 IT人材の管理 • AI5 IT資源の調達 • DS1 サービスレベルの定義と管理 • DS2 サードパーティのサービスの管理 • DS5 システムセキュリティの保証 • ME2 内部統制のモニタリングと評価 1.2.3 副次的参照： • PO1 IT戦略計画の策定 • PO2 情報アーキテクチャの定義 • PO8 品質管理 • AI3 技術インフラストラクチャの調達と保守 • DS12 物理的環境の管理 • ME4 ITガバナンスの提供 1.2.4 責任、権限および説明責任に最も関連する情報要請規準： • 主：有効性、可用性、インテグリティ、信頼性 • 副：効率性、機密性 1.3 定義 1.3.1 インターネットサービスプロバイダー（ISP）：インターネットおよびインターネットに関連する様々なサービ スを企業に対して提供するサードパーティ 1.3.2 ア プ リケ ーション サ ービ スプ ロ バ イダー/ マネージド サ ービ スプ ロ バ イダー（ A S P / M S P ）： セキュリティサービスを 含 む、アプリケーションおよびコンピュータサービスをインターネット、 あるいはプライベートネットワークを経由して複数のユーザに対して提供・管理するサードパーティ 1.3.3 ビジネスサービスプロバイダー（BSP）：支払処理、発注処理およびアプリケーション開発のようなビジネ スプロセスのアウトソーシンサービスも提供するASP 87 G16 企業のITコントロールに関わるサードパーティの影響 1.3.4 本ガイドラインにおいては、I S P、A S P/ M S Pおよび B S Pを一括してサードパーティとしている。 本ガイドラインで対象となるサードパーティには、法的に独立しているか否かにかかわらず、 （シェアード サービスのような）企業から独立したあらゆる組織が含まれている。 1.4 ガイドラインの適用 1.4.1 本ガイドラインを適用するにあたり、情報システム監査人は本ガイドラインを他の関連するISACAガイドラ インと関連付けて検討すべきである。 1.5 ガイドラインの必要性 1.5.1 本ガイドラインは、企業の情報システムのコントロールおよび関連するコントロール目標にサードパーティ が及ぼす影響を評価するにあたり、情報システム監査人がISACA情報システム監査基準およびCOBITへ どのように準拠すべきかを詳述している。 1.5.2 本ガイドラインは、情報システム監査人の報告書がサードパーティプロバイダーのコントロールに関して他 の基準設定機関に準拠してどのように作成されるのかに関する手引きを提供することを意図したものでは ない。 2 サードパーティサービスプロバイダーの役割 2.1 サードパーティプロバイダーのサービス 2.1.1 企業は、様々な形でサードパーティのサービスを利用している。これらのプロバイダは、しばしば企業にとっ て重要かつ重大な役割を担うため、しばしば機密性の高い情報、アプリケーションおよびシステムへのアク セスが必要となる。 2.1.2 サードパーティは、以下のようなサービスを提供する。 • ビジネスアドバイザリーサービスおよびコンサルティングサービス • 企業のパートナー、サプライヤーや顧客への接続サービスおよびユーティリティサービス • セキュリティサービス • ハードウェアの設置場所の提供（コロケーション） • システムおよびアプリケーションへのアクセスに対する監視 • バックアップおよび復旧サービス • アプリケーション開発、保守およびホスティング（enterprise resource planning（ERP）システム、電子 商取引システム、ウェブサイト等） • 買掛金、固定資産、人事/給与、総勘定元帳作成、報告書作成のような事務部門の取引処理サービスの 他、資金管理、クレジットカードサービス、受注処理、コールセンターサービスのような業務サービス 3 コントロールの有効性 3.1 サードパーティプロバイダーのコントロールの有効性 3.1.1 企業がサードパーティを利用する場合、サードパーティは企業のコントロールおよび関連するコントロール 目標の達成において重要な構成要素となり得る。 3.1.2 情報システム監査人は、IT環境、関連するコントロールおよびコントロール目標と関連付けてサードパー ティが担う役割を評価すべきである。 88 G16 企業のITコントロールに関わるサードパーティの影響 3.1.3 コロケーションサービスのようにサードパーティプロバイダーを限定的な目的にしか利用しない企業は、コ ントロール目標の達成において、サードパーティに限定的な目的にしか依存していないかもしれない。しか しながら、財務会計システムや電子商取引のホスティングのような他の目的のためにプロバイダを利用す る企業は、コントロール目標を達成するために、サードパーティプロバイダのコントロールを全面的に、ある いは自社のコントロールと併せて利用している。 3.1.4 サードパーティのコントロールが有効である場合、企業はコントロール目標を達成する能力を強めことがで きる。反対に、サードパーティのコントロールが有効でない場合には、企業はコントロール目標を達成する 能力を弱めてしまう。これらコントロールの欠陥は、以下を含む様々な原因から生じる。 • サードパーティにアウトソーシングすることにより生じる統制環境のギャップ • 有効でないコントロールの運用を引き起こす不十分なコントロールの設計 • コントロール機能に対し責任のある要員の知識不足および/あるいは経験不足 • （企業内に補完的なコントロールが存在しない場合）サードパーティのコントロールへの過度の依存 4 情報システム監査人により実施される手続 4.1 理解 4.1.1 計画プロセスの一環として、情報システム監査人はサードパーティが提供するサービスと企業の統制環境 の関係を理解し、文書化すべきである。情報システム監査人は、契約書、サービスレベルアグリーメントお よびサードパーティと企業の間で取り決められた方針や手続等をレビューすることを考慮すべきである。 4.1.2 情報システム監査人は、企業のプロセスやコントロール目標に直接的な影響を及ぼすサードパーティのプ ロセスおよびコントロールを文書化すべきである。 4.1.3 情報システム監査人は、プロセスに関連するリスクおよびそれらリスクが企業とサードパーティプロバイ ダーのどちらに、あるいは双方に存在するのかを十分に考慮、特定すべきである。 4.1.4 情報システム監査人は、各コントロールと各コントロールが結合した統制環境下での所在（内部、あるいは 外部）、種類、その機能（予防的、発見的、修正的）およびリスクを相殺、あるいは補完する機能を果たす 組織（内部、あるいは外部）を特定すべきである。 4.1.5 情報システム監査人は、サードパーティが企業に提供するサービスのリスク、そのコントロールおよびコント ロール目標を評価し、企業がコントロール目標を満たす能力に対するサードパーティのコントロールの重 要性を判断すべきである。 4.2 理解の確認 4.2.1 情報システム監査人は、統制環境に対する自らの理解を確認すべきである。 4.2.2 情報システム監査人は、質問、観察、ウォークスルーを含む様々な手法を用いることにより、統制環境に対 する自らの理解を確認することができる。 4.3 サードパーティプロバイダーのコントロールの役割の評価 4.3.1 サードパーティが企業のコントロール目標に対して重要な役割を担う、あるいは重要な影響を及ぼす場合 には、情報システム監査人はサードパーティのコントロールが記載通りに機能しているか、有効に運用され ているか、また、企業のコントロール目標の達成に寄与しているかを判断するためにサードパーティのコン トロールを評価すべきである。サードパーティのコントロールのテスト手法については、セクション7 サード パーティプロバイダーに関するコントロールのレビューを参照のこと。 89 G16 企業のITコントロールに関わるサードパーティの影響 5 サードパーティプロバイダーに関するリスク 5.1 企業に与えるサードパーティプロバイダーの影響 5.1.1 サードパーティプロバイダーは、企業（企業のパートナーを含む）、企業のプロセス、コントロールおよびコ ントロール目標に対して様々な、また、異なったレベルで影響を与え得る。これには、以下の事項から生じ る影響が含まれる。 • サードパーティプロバイダーの事業継続性 • 自らの通信システムおよびアプリケーションを経由して伝達される情報へのサードパーティプロバイダー のアクセス • システムおよびアプリケーションの可用性 • 処理のインテグリティ • アプリケーション開発プロセスおよび変更管理プロセス • バックアップリカバリ、緊急事態対応計画および冗長化によるシステムおよび情報資産の保護 5.1.2 コントロールの欠如および/あるいはコントロールの設計、運用、あるいは有効性に係わる欠陥は、以下の ような事項をもたらす。 • 情報機密性とプライバシーに係わる損失 • 可用性が損なわれたシステム • システム、アプリケーション、あるいはデータに対する未承認のアクセスおよび変更 • システム、あるいはセキュリティの障害が発生する、データが消失する、データのインテグリティが担保 されなくなる、データが保護されなくなる、あるいはシステムが利用できなくなるという結果をもたらすシ ステム、アプリケーション、あるいはデータの変更 • システム資源および情報資産の損失 • 上記の結果として発生する追加的なコスト 5.2 特定されたコントロールの欠陥の評価 5.2.1 情報システム監査人は、コントロールの設計、あるいは運用の欠陥がIT環境に存在する可能性（あるいは 統制リスク）を評価すべきである。情報システム監査人は、コントロールの欠陥がどこに存在しているのか を特定すべきである。 5.2.2 情報システム監査人は、コントロールリスクが重要なものなのか、また、コントロールリスクがコントロール 環境にどのような影響を及ぼすのかを評価すべきである。 5.2.3 欠陥が検出された場合、情報システム監査人は補完的なコントロールが存在するのか、また、補完的なコ ントロールがどの程度まで検出された欠陥の影響を緩和させるか（補完的なコントロールは企業とサード パーティプロバイダーのどちらか、あるいは双方に存在する可能性がある）も判断すべきである。補完的な コントロールが存在する場合、情報システム監査人は補完的なコントロールが検出されたコントロールの 欠陥が及ぼす影響を軽減しているかを判断すべきである。 6 サードパーティプロバイダーとの契約 6.1 役割と責任 6.1.1 企業とサードパーティプロバイダーの関係は、正式な契約書の形で文書化されるべきである。契約は、企 業とサービスプロバイダーの関係において重要な要素である。契約には、各当事者のアクションおよび責 任を定めた複数の条項が盛り込まれる。 90 G16 企業のITコントロールに関わるサードパーティの影響 6.1.2 情報システム監査人は、企業とサードパーティの間で締結された契約書をレビューすべきである。 6.1.3 本ガイドラインに従う場合、情報システム監査人は企業がコントロール目標を達成する上でのサードパー ティの支援の役割と責任を判断するために（場合によっては企業の顧問弁護士の支援を受けながら）契約 書をレビューすべきである。契約書をどのようにレビューすべきかに関する手引きは本ガイドラインの範囲 対象外ではあるが、情報システム監査人が契約書をレビューする際に検討すべき事項の例を以下に挙げる。 • サードパーティによって（企業または企業のパートナー、あるいはその双方に）提供されるべきサービス のレベル • サードパーティの請求金額の妥当性 • コントロールの設計、導入、実施およびモニタリングに対する責任 • データおよびアプリケーションのプライバシーおよび機密性に対する責任 • システム、通信、オペレーティングシステム、ユーティリティソフトウェア、データおよびアプリケーション ソフトウェアのアクセスコントロールおよび管理に対する責任 • 資産や関連するデータのモニタリングおよび対応手続（企業およびサードパーティ）や報告手続（定例 およびインシデント時） • データおよびドメイン名を含む情報資産の所有権の特定 • 変更ドキュメント、ソースコードおよびエスクロー契約を含むサードパーティが企業のために開発した特 注プログラムの所有権 • バックアップおよびリカバリ、緊急事態対応計画、冗長化を含むシステムやデータの保護条項 • 監査条項（サードパーティの内部監査要員との会議、サードパーティの内部監査要員の作成した監査調 書および監査報告書のレビューを含む） • 契約書および関連する文書（サービスレベルアグリーメント、手続等）の変更に関する交渉、レビュー、 承認のプロセス 6.1.4 情報システム監査人は、最低限、サードパーティが企業のために実施するコントロールの責任範囲を判断 するために契約書をレビューすべきである。このプロセスでは、特定されたコントロールモニタリング/報告 の十分性、コントロールの設計、運用の有効性を評価すべきである。 6.2 コーポレートガバナンス 6.2.1 サードパーティプロバイダーへの委託を行っている場合においても、 マネジメントには関連するコントロー ル目標の達成に対する責任が残る。この責任の一環として、 マネジメントはサードパーティプロバイダーと の関係およびサードパーティプロバイダのパフォーマンスを管理するプロセスを構築すべきである。情報シ ステム監査人は、このプロセスの構成要素を特定し、レビューすべきである。情報システム監査人は、 マネ ジメントがサードパーティプロバイダーに関連するリスクを認識するために用いているプロセス管理、サード パーティが提供するサービスおよびマネジメントがサードパーティと企業の関係をどのように管理している のかをレビューすべきである。 6.2.2 ガバナンスプロセスをレビューする場合、情報システム監査人はマネジメントが契約書で定められているパ フォーマンス基準および規制機関が定める基準と照らしてサードパーティプロバイダーをレビューしている か等を確認すべきである。ガバナンスプロセスにおいては、以下の事項がレビューされるべきである。 • サードパーティプロバイダーの財務実績 • 契約条件の遵守性 • サードパーティ、サードパーティの監査人および監督機関からの要請による統制環境の変更 • サードパーティの監査人、コンサルタント等を含む他者により実施されるコントロールレビューの結果 • 適切なレベルでの付保の維持 91 G16 企業のITコントロールに関わるサードパーティの影響 7 サードパーティプロバイダーに関するコントロールのレビュー 7.1 契約上の制限 7.1.1 サードパーティプロバイダーのコントロールを評価する場合、情報システム監査人は企業とサードパーティ プロバイダーの契約関係およびコントロールに関するサードパーティプロバイダーの評価や報告を考慮す べきである。 7.1.2 情報システム監査人は、監査条項のような契約上の制限のためにサードパーティプロバイダーのコント ロールをレビューできないことがあるかもしれない。このような場合、情報システム監査人は範囲の制限が 情報システムのコントロール環境の評価に及ぼす影響を評価すべきである。 7.2 独立した第三者による報告 7.2.1 サードパーティプロバイダーのコントロールに関する独立した第三者による報告書がサードパーティプロバ イダーから提供されるかもしれない。独立した第三者による報告書は、サービス機関による監査報告書、あ るいは他のコントロールに関する報告書の形をとるかもしれない。独立した第三者により発行される報告 書の例としては、サービス監査人の保証報告書がある。情報システム監査人は、情報システムコントロール 環境のコントロールに依拠することの根拠として独立した第三者による報告書を利用することができる。 7.2.2 サードパーティプロバイダーにおける情報システムのコントロールに依拠することの根拠として独立した第 三者による報告書を利用する場合、情報システム監査人は報告書をレビューし、以下の事項を確認すべき である。 • 独立した第三者が資格要件を満たしているか。これには、独立した第三者がしかるべき専門的な資格や ライセンスを有しているか、関連する経験を有しているか、また、関連する専門機関および規制当局（該 当する場合）と良好な関係を構築しているが含まれ得る • 独立した第三者がサードパーティとの間で独立性や客観性を損なうような関係を有していないか • 報告書の対象期間 • 報告書が十分なものであるか（報告書において、対象とすべきシステムやコントロールが対象となってい るか、また、情報システム監査人が監査を実施した場合に対象となるべき領域のテストが含まれている か） • 独立した第三者による作業が情報システム監査人が依拠可能なほど十分であるか（コントロールのテス トが手続の種類、実施時期、範囲の観点から十分であるか） • テストおける例外事項が独立した第三者により検出されているか • 報告書において、サービスプロバイダの責任とユーザ企業の責任が明確になっているか • ユーザ企業が適切なコントロールの構築に関して自らの責任を果たそうとしているか 7.2.3 テストにおける例外事項が検出されている場合、情報システム監査人は例外事項がコントロール目標へ及 ぼす影響を判断し、例外事項の是正状況をフォローアップし、また、コントロール目標を満たすために追加 的なテストが必要かどうかを評価すべきである。 92 G16 企業のITコントロールに関わるサードパーティの影響 7.3 サードパーティのコントロールのテスト 7.3.1 情報システム監査人自らがサードパーティプロバイダーのコントロールをレビューし、テストする場合、情報 システム監査人は以下の事項を実施すべきである。 • 監査計画の作成や監査目標およびレビュー範囲の決定を行うため、 マネジメントおよび該当するか適切 と考えられる場合には企業、サードパーティプロバイダーの双方の内部監査人と作業を行う • 監査の実施時期・スタッフィング・その他の事項を決定するため、 マネジメントおよび該当するか適切と 考えられる場合には企業、サードパーティプロバイダーの双方の内部監査部門およびそのメンバーと作 業を行う • サードパーティのシステムや資産へのアクセスおよび機密性等の課題を検討する • 監査プログラム、予算および監査計画を作成する • コントロール目標の妥当性を確認する 7.3.2 情報システム監査人は、監査の範囲および目標を設定する際に、以下の領域を検討すべきである。 • サードパーティによるサービスが実施される場所および環境。遠隔地の場合には、セキュリティに影響 が及ぶような例外的なアクセスが必要となるかもしれない • サードパーティプロバイダーの規模および安定性。サードパーティプロバイダーの従業員数および規模 が、従業員によるアクセスの妥当性と同様、部署間の職務分離にも悪影響を与えるかもしれない • データの保管および取扱い。サードパーティプロバイダーが機密データあるいは複数の顧客の資産を取 り扱うか、保管している場合、プライバシー、職務の分離および従業員と顧客のアクセスコントロールが レビューされるべきである 7.3.3 現場作業の完了後に、テストを実施したコントロールの運用の有効性に関する結論を出すべきである。情 報システム監査人は、各組織内におけるコントロールの有効性および企業とサードパーティの間における コントロールの相互関係をレビューすべきである。 7.3.4 ほとんどの場合において、企業およびサードパーティのコントロールは一部重なり合う。情報システム監査 人は、企業およびサードパーティのコントロールが連携して実施される場合と個別に実施される場合の運 用の有効性を評価すべきである。 7.3.5 企業とサードパーティのどちらかにおいて、ある目標に対するコントロールが存在しない、あるいは有効に 機能していないこともあるかもしれない。そのような場合には、情報システム監査人は、この欠陥がコント ロール環境全体および手続の範囲に及ぼす影響を評価すべきである。 7.3.6 ある企業でのコントロールの強度が他の企業におけるコントロールの欠陥により部分的あるいは完全にな くなる、こともあるかもしれない。情報システム監査人は、この状況がコントロール環境全体に対して及ぼ す影響を評価する責任がある。 7.4 サードパーティプロバイダーの内部監査人 7.4.1 情報システム監査人は、サードパーティプロバイダーが内部監査部門を有しているかどうかも考慮すべきで ある。サードパーティプロバイダーが内部監査人を有している場合には、サードパーティプロバイダーのコン トロール環境はより良好なものとなり得る。 7.4.2 内部監査部門が存在している場合、情報システム監査人は企業に影響を及ぼすシステムおよびコントロー ルに関する内部監査人の活動の範囲を確認すべきである。 7.4.3 可能な場合には、情報システム監査人は関連するサードパーティプロバイダーの内部監査報告書をレ ビューすべきである。 7.4.4 サードパーティプロバイダーの内部監査報告書をレビューすることが困難な場合には、情報システム監査 人はレビューの範囲を討議し、レビューの対象となったシステムやコントロールを特定し、また重要な課題 や欠陥を特定すべきである。 93 G16 企業のITコントロールに関わるサードパーティの影響 7.4.5 サードパーティプロバイダーが報告書の開示、あるいは内部監査人との接触を拒む場合には、情報システ ム監査人は監査手続の範囲の制限に関し評価をすべきである。 7.4.6 情報システム監査人は、サードパーティプロバイダーの内部監査人の技能および専門知識を評価すること も検討すべきである。これは、内部監査人との討議、監査計画、監査調書および報告書のレビューのよう な追加的な手続を実施することにより可能となる。 8 サードパーティの再委託先 8.1 コントロールの有効性 8.1.1 情報システム監査人は、サードパーティがシステムおよびサービスを提供するために再委託先を利用してい るかを確認すべきである。 8.1.2 再委託先を利用している場合には、情報システム監査人は再委託先がサードパーティの実施する企業に関 連する主要なコントロールに及ぼす影響を判断するため、再委託先の重要性をレビューすべきである。 8.2 契約の有効性 8.2.1 再委託先が企業に関連するコントロールに重要な影響を及ぼさない場合には、情報システム監査人はその 旨を監査調書へ文書化すべきである。 8.2.2 再委託先が企業に関連するコントロールに重要な影響を及ぼす場合には、情報システム監査人は再委託 先との関係を管理・監視するためにサードパーティが構築しているプロセスを評価すべきである。情報シス テム監査人は、サードパーティの再委託先に対するコントロールを評価するにあたり、本ガイドラインのセ クション6および7を考慮すべきである。 9 報告 9.1 欠陥 9.1.1 情報システム監査人の報告書には、企業内のコントロールおよびサードパーティに存在するコントロール が監査対象であることを記載すべきである。加えて、情報システム監査人は、各企業に存在するコントロー ル、コントロールの欠陥および補完的なコントロールを特定することを検討すべきである。 9.1.2 報告する結論および勧告事項が通知される範囲は参照できるよう文書化されるべきである。勧告事項を 実施したがらない、あるいは実施することができないサードパーティがあるかもしれない。これらの場合に は、情報システム監査人はサードパーティのコントロールの欠陥に対して企業が導入可能な補完的なコン トロールを勧告すべきである。重要な課題が存在し続ける場合には、 マネジメントと適切な対応を決定する ため、企業は契約書の文面にまで立ち返らなければならない場合もあるかもしれない。 10 適用開始日 10.1 本ガイドラインは、2002年3月1日以降に開始される全ての情報システム監査に適用される。 本ガイドラインは、2009年3月1日にレビューされ、改訂された。 94 G17 IT監査・保証の専門家の独立性に対する 非監査業務の影響 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥96 2 監査ポリシー‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥98 3 監査以外のサービスのタイプ‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥98 4 独立性‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥99 5 計画策定‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 100 6 監査作業のパフォーマンス‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 101 7 報告‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 101 8 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 101 G17 IT監査・保証の専門家の独立性に対する非監査業務の影響 1 背景 1.1 基準との関連 1.1.1 基準S2『独立性』の中で、 「IT監査・保証の専門家は、監査に関連するすべての点において態度に於いて も、外見的にも、被監査人に対し、独立を保つ。」と述べている。 1.1.2 基準S2『独立性』の中で、 「IT監査・保証の機能は、監査業務の目的完遂を可能とするために、被監査分 野や被監査活動に対し、独立を保つべきである。」と述べている。 1.1.3 基準S3『専門家としての倫理と基準』の中で、 「IT監査・保証の専門家は、適用可能な専門の監査基準を 遵守することを始めとして、専門家としてのしかるべき注意を払うべきである。」と述べている。 1.2 COBITとの関連 1.2.1 個々の監査範囲に適用可能であるCOBITの中から最も関連する材料の選択は、特定のCOBIT ITプロセ スを選択し、COBITのコントロール目標と関連するマネジメントの実行を勘案して行う。IT監査・保証の専 門家の独立性に対する非監査業務の影響を適用するには、主要および副次的として選択もしくは適応さ れる最も関連するCOBITのITプロセスを採用する必要がある。選択もしくは適応されるITプロセスおよび そのコントロール目標は、特定の監査範囲や監査すべき対象によって異なる。 1.2.2 主要な参照： • PO6 マネジメントの意図と指針の周知 • PO9 ITリスクの評価と管理 • PO10 プロジェクト管理 • DS2 サードパーティのサービスの管理 • DS7 利用者の教育と研修 • ME2 内部統制のモニタリングと評価 • ME3 外部要件に対するコンプライアンスの保証管理 • ME4 ITガバナンスの提供 1.2.3 副次的参照： • PO7 IT人材の管理 • DS10 問題管理 1.2.4 最も関連する情報要請規準： • 主：信頼性、機密性、コンプライアンス、効率性 • 副：有効性、インテグリティ、可用性 96 G17 IT監査・保証の専門家の独立性に対する非監査業務の影響 1.3 ガイドラインの必要性 1.3.1 多くの企業において、 マネジメント、ITメンバーおよび内部監査人は、IT監査・保証の専門家に対して、下記 のような監査以外の業務に関与することを期待している。 • 技術、アプリケーションおよびリソースに関連する情報システム戦略の定義 • 技術の選定および導入のための評価 • サードパーティ製の情報システムアプリケーションおよびソリューションの選定、カスタマイズおよび導 入 • 特注の情報システムアプリケーションおよびソリューションの設計、開発および導入 • 様々なIT部門に関するグットプラクティス、方針、手順の規定 • セキュリティおよびコントロールの設計、開発、テストおよび導入 • ITプロジェクトの管理 1.3.2 一般的に監査以外の業務の役割とは、フルタイムもしくはパートタイムで働いている際に助言もしくは顧 問的な立場の中でITイニシアティブやITプロジェクトメンバーとして従事していることをさす。IT監査・保証 の専門家は下記のような活動を監査以外の業務として実施することもある。 • フルタイムで行なう一時的な業務やIT監査・保証のスタッフを情報システムプロジェクトチーム・メン バーとして貸し出す • プロジェクト運営グループ、プロジェクト作業部会、評価チーム、交渉および渉外チーム、導入チーム、 品質保証チームおよび問題解決チームといった、様々なプロジェクトのメンバーとして与えられた、IT監 査・保証のスタッフメンバーに関連するパートタイムで行なう業務 • 特定の目的のために、独立した立場で助言やレビューを行なう活動 1.3.3 企業の他のメンバーを教育、研修するような監査以外の業務の役割は、IT監査・保証の専門家が貢献す る役割の重要な一部である。それらは、IT監査・保証の専門家が企業におけるITへの投資が効果的、効率 的であるかなどの独自の価値ある貢献し、彼らのもつ企業の専門性や知識を利用できるようにする。また、 それらは、IT監査・保証の部門の特徴を明らかにし、IT監査・保証のスタッフに価値ある実践的な経験を 与える機会を提供する。 1.3.4 IT監査・保証の専門家が情報システムイニシアティブにおける監査以外の業務の役割や情報システムイニ シアティブおよび関連する部門を後で、もしくは同時に関与すると、監査から生じた推奨案や結論が監査 目的に合致しないことを、受領者が認める場合もある。この状況では、IT監査・保証の専門家が監査以外 の業務の役割によって、彼らの独立性や客観性を害されているとされる可能性もある。 1.3.5 IT監査・保証の専門家は、監査以外の業務の役割に関与する際は、それらの役割が監査の独立性を事実 上もしくは外観上害する可能性がないか評価すべきである。IT監査・保証の専門家は、コントロールが十 分であるか評価する際にどのような考慮事項に基づいて情報システムの意思決定がされているかを理解し、 助言を行なうべきである。また、監査以外の業務の役割に関与するIT監査・保証の専門家は、有効なコン トロールが設計されているかどうかに関する承認はすべきでない。 1.3.6 本ガイドラインの目的は、IT監査・保証の専門家に以下のような場合に、フレームワークを提供することを 可能にする。 • 監査の独立性を害する、もしくは害する可能性のある要求をされた際 • 監査の独立性を害する、もしくは害する可能性のある要求をされた際にその監査プロセスに対して可能 性のある代替アプローチを考慮する際 • 監査以外の業務の役割、部門やサービスにおいて、IT監査・保証の専門家への影響を低減もしくは排 除する際 • 開示する要求事項を決定する際 97 G17 IT監査・保証の専門家の独立性に対する非監査業務の影響 2 監査ポリシー 2.1 IT監査・保証の専門家が関与する監査以外の関与に対する条件 2.1.1 IT監査ポリシーは、監査以外の業務の役割に関与するIT監査・保証の専門家の任務、および広義の監査 の種類、時期、程度やIT監査・保証の専門家が監査する可能性のあるシステムの独立性を害さないといっ た役割を定めている。これは、ケースバイケースで特定の任務を得る必要性を避けるためである。 2.1.2 IT監査・保証の専門家は、特定の監査以外の業務の役割のための配慮すべき条項（TOR）が監査ポリ シーに則っているという合理的な保証を提供すべきである。多くの逸脱があった場合、同じように配慮すべ き条項（TOR）として明示的に説明すべきである。 2.1.3 監査ポリシーが監査以外の業務の役割について定めていない場合、監査ポリシーそのものがない場合、も しくは監査以外の業務の役割に関与したことがひとつでもあれば、IT監査・保証の専門家はマネジメント や監査委員会へ報告すべきである。IT監査・保証の専門家が関与している情報システムプロジェクトの監 査時期や程度は、組織の長、もしくは監査委員会によって承認された個別の配慮すべき条項（TOR）に従 うべきである。 3 監査以外のサービスのタイプ 3.1 監査の独立性を害さない関与 3.1.1 コミッション、委員会、タスクフォースやパネルといった技術的な知識や専門性を元に、技術的な助言を提 供しているIT監査・保証の専門家は、監査の独立性を害さない監査以外の業務に対する関与といえる。し かしながら、IT監査・保証の専門家の独立性は、監査人の与えた助言の程度や種類によって、 マネジメント の決定やマネジメント部門の実行に関する結果次第で、害される虞もある。 3.1.2 監査以外の業務の役割に対する関与は、情報技術に関する助言、システム設計、システム実装やシステム セキュリティに関する限られた助言を与えるような、補足的な対応策を実施する場合、情報技術の助言を 与えることも含めて、監査の独立性を害さないこともある。企業の取締役会と管理者は、新システムの導 入、新システムの設計の妥当性、既存システムのメジャーな設計変更の妥当性、規制要件や他の要求事項 に準拠しているかの妥当性に関する主要な判断としてIT監査・保証の専門家の助言を信頼すべきである。 3.2 監査の独立性を害する関与 3.2.1 独立性や客観性を害する監査以外の業務の役割は、情報システムのコントロール設計が監査対象に重大 もしくは意義があるということと同様に、情報システムの設計、開発、テスト、実装、コンフィグレーションも しくは運用のプロセスにおいて、IT監査・保証の専門家が大きく関与することを含んでいる。 3.2.2 監査以外の業務の役割は、IT監査・保証の専門家が独立して、もしくは共同して、 マネジメントの決定や方 針、基準の承認に責務を負うといった、ガバナンスの役割を果たすことも含んでいる。 3.2.3 監査以外の業務の役割に関与している期間に、IT監査・保証の専門家によって選定されたアプリケーショ ンシステムのコントロールをテストすることを情報システムの評価が意味する場合、IT監査・保証の専門家 の独立性は害される恐れがある。 3.2.4 IT監査・保証の専門家の独立性は、IT監査・保証の専門家の与えた助言の程度や種類によって、 マネジメ ントの決定やマネジメント部門の実行に関する結果次第で、害される虞もある。 98 G17 IT監査・保証の専門家の独立性に対する非監査業務の影響 4 独立性 4.1 監査以外の業務の役割における独立性の適切さ 4.1.1 IT監査・保証の専門家は、監査に関連するすべての事柄から独立しているべきである。ただし、他の外部 の標準によって禁止されている場合、もしくはIT監査・保証の専門家が、監査以外の業務の役割のひとつ である情報システムイニシアティブのような独立性に関与する、もしくは関与しているようにみなされる要求 がある場合を除く。 4.1.2 監査以外の業務の役割に関連するタスクを実行する際に、IT監査・保証の専門家が独立している必要が ないが、専門家としての要求事項である客観性は必要である。IT監査・保証の専門家は、監査以外の業務 の役割に従事する場合は客観性と専門家としてのマナーをもって、それらを実行すべきである。 4.1.3 IT監査・保証の専門家が情報システムイニシアティブにおける監査以外の業務の役割に従事している間に、 独立性に関する要求事項があるなしにかかわらず、IT監査・保証の専門家は、情報システムイニシアティブ やそれに関連する部門にアサインされるといった独立性を害するような役割とならないかどうか、熟考すべ きである。 もしそのような予測できる矛盾があった場合、監査以外の業務の役割に着手する前にIT監査・保証の専 門家は監査委員会もしくは同等なガバナンス組織と議論すべきである。 （予測できるとは、IT監査・保証の専門家が監査以外の業務の役割とそれに続く監査を実行することが 可能なただ一人であり、独立した監査が後から要求されるような場合である。） 4.1.4 情報システムイニシアティブ、情報システムイニシアティブの独立した監査、あるいはそれらに関連した部門 といった監査以外の業務の役割へのIT監査・保証の専門家の参加を決定する際は、監査委員会もしくは 同等なガバナンス組織の決定に従うべきである。また、リスク分析は実施されるべきである。それらの決定 に影響を与えるような観点として、 • それぞれの役割のための可能性のある代替リソース • 矛盾する活動によって付加される相対的価値の理解 • 将来イニシアティブが利益を得られるである情報システムチームの育成の可能性 • キャリア開発の機会とIT監査・保証の専門家からの引継ぎ計画 • 監査以外の業務の役割に付随するリスクのレベル • 情報システム監査に関連する部門のビジブリティ、プロファイル、イメージ等の影響 • 外部監査人や調整役からの要求に対する決定の影響（もしあれば） • IT監査ポリシーの条項 4.2 次回監査における監査以外の業務の役割への影響 4.2.1 情報システムイニシアティブもしくは部門が、法令どおりの監査およびマネジメントの要求による監査を行 なった際は、IT監査・保証の専門家はISチームとそのマネジメントの独立性が保たれている、および保たれ ているように見えるようにすべできである。 4.2.2 IT監査・保証の専門家は、自身の業務について監査すべきでない。また、監査以外の業務が監査において 重大あるいは重要である場合、監査以外のサービスを提供すべきでない。情報システムイニシアティブにお ける監査以外の業務を行なっているIT監査・保証の専門家は、情報システムイニシアティブおよび関連す る部門に従事することによって独立性を害する可能性がある。IT監査・保証の専門家は自身の意見として、 監査を実施している、もしくは監査以外の業務の役割によって独立性が害されることがないことを明示す べきである。また、監査委員会もしくは同等なガバナンス組織に書面でその意見に対して同意することを 求めるべきである。 99 G17 IT監査・保証の専門家の独立性に対する非監査業務の影響 4.2.3 監査以外の業務の役割によって監査に対する、IT監査・保証の専門家の独立性が害されるかどうかを決 めるための重要な要素としては、以下のような観点が含まれる。 • 情報システムイニシアティブの監査以外の業務の役割およびそれに関連する部門を検討する際のITイニ シアティブにおける監査の種類、時期や監査以外の業務の役割の程度。監査以外の業務の役割の決 定権の重大さや独立性に対する侵害度のレベルの高さ • 独立性を侵すかもしれない事実の存在。これには監査以外の業務の役割に関連する賞与や罰則が含ま れる • 監査以外の業務の役割を行なったにもかかわらず、脆弱性やエラーを報告する際に、公平かつ不偏的で あるIT監査・保証の専門家のコミットメントおよびそれを実行できる能力 • 監査以外の業務の役割を行なったにもかかわらず、監査範囲を決め、監査を実施できるIT監査・保証の 専門家の自主性 • IT監査・保証の専門家によって行なわれた監査以外の業務の役割の公表。受け入れた役割のレベルや 重大な事実への関与のレベル • 監査以外の業務の役割の行なっている際に、監査に関わる重要な人物との関係（肯定的もしくは否定 的も含め）があるか。特にマネジメント職に関わる人 • IT監査・保証の専門家の意思決定権に関わらず、監査以外の業務の役割におけるIT監査・保証の専門 家の影響力および説得力 • 情報資源の臨界点（リスク度合いに関する優先度） 監査の題材になる可能性のある情報資源、および既に同じスタッフによって実施された監査以外の業務の 題材になる可能性のある情報資源が想定される 5 計画策定 5.1 独立性の影響 5.1.1 IT監査・保証の専門家が近い将来もしくは同時に実施する情報システムイニシアティブもしくは関連する 部門の監査に言及する、監査以外の業務の役割が独立性に与える影響は、監査以外の業務の役割を計 画する際に、評価されるべきである。 5.1.2 IT監査・保証の専門家が、以前に実施した、もしくは現在実施中の情報システムイニシアティブにおける監 査以外の業務の役割が独立性に与える潜在的な影響は、ITイニシアティブもしくは関連する部門の計画す る際に、評価されるべきである。 5.1.3 監査委員会もしくは同等なガバナンス組織は、独立性が害される可能性だけでなく、独立性が害されるこ とで現れる可能性のある実害についても知らせるべきである。 5.1.4 IT監査・保証の専門家は、独立性や客観性の合理的な保証を提供する監査マネジメント／委員会による 行動や補填するコントロールを推奨すべきである。これは以下を含む。 • 追加のマネジメントを割り当てる、および／または監査以外の業務の役割に関わらなかったIT監査・保証 の部門内の誰か、もしくは監査以外の業務の役割に関わらなかったIT監査・保証の専門家を配置する • 追加のマネジメントを割り当てるか、IT監査・保証の部門外から誰かを配置する。例えば、他の部門、部 署、外部組織からスタッフを借りる。もしくは監査以外の業務の役割に関わらなかったIT監査・保証の 専門家を配置する • IT監査・保証の部門内の独立したスタッフを割り当てる、もしくはその他の査読（Peer Review）を行 なったスタッフや監査の計画、現場作業、報告期間中に独立して活動してしたスタッフを割り当てる 5.1.5 IT監査・保証の専門家が監査以外の業務の役割に従事した程度が非常に大きいときは、IT監査・保証の 専門家は監査委員会に監査行動を推奨すべきでない、また既に大きく関わった／参加した、監査領域の 題材に対するレビューを直接的に行なうべきでない。 100 G17 IT監査・保証の専門家の独立性に対する非監査業務の影響 6 監査作業のパフォーマンス 6.1 監査業務のモニタリング 6.1.1 監査以外の業務とのかかわりによって監査の独立性が害されてしまう可能性がある場合、IT監査・保証 のマネジメントは監査業務を適切にモニタリングすべきである。監査以外の業務の外で起こった独立性を 危うくする題材があった場合、IT監査・保証のマネジメントは批判的にその題材を評価すべきである。また、 必要な是正処置を講じるべきである。そのような事実があった場合は、速やかに監査委員会もしくは同等 なガバナンス組織へ知らせるべきである。 6.1.2 IT監査・保証の専門家によって実施された監査が、監査以外の業務の役割によって重大な、もしくは実質 的な影響を受けたかどうかを考慮するにあたって、監査委員会もしくは同等なガバナンス組織は現在進行 中の監査、計画された監査、監査の要求事項およびコミットメントを評価すべきである。その際、法律、法 令、ルール、契約書、その他の同意書、ポリシー、監査以外の業務の役割にIT監査・保証の専門家が関わ ることの責任に関する決定事項を含むべきである。 6.1.3 ガバナンス組織は事前に可能性のある矛盾が起こることに気づくことができ、またそのような矛盾を最小 化し、十分な管理をするよう、監査マネジメントからの依頼されているガバナンス組織は、監査以外の業務 の役割のための監査資源を割り当てることを含むべきである。 7 報告 7.1 開示要求 7.1.1 情報システムイニシアティブおよび／または関連する部門の監査に従事するIT監査・保証のマネジメントお よびスタッフの独立性は、情報システムイニシアティブにおける監査以外の業務の役割によって害される、 もしくは害が明らかにされる虞がある場合、IT監査・保証の専門家は監査報告書に、監査以外の業務の 役割だけでなく、独立性および客観性の合理的な保障を提供する行動について、十分な情報を開示すべき である。これは監査報告書の利用者に、監査に対する侵害があった場合、その侵害の程度を理解するため の助けとなる。また、なんらかの処置によって影響を抑えることができるようになる。IT監査・保証の専門 家が開示を考慮する情報には、以下のような観点が含まれる。 • ITイニシアティブにおける監査以外の業務の役割に関わった、IT監査のマネジメントおよびスタッフの名 前および年功 • 情報システムイニシアティブにおける監査以外の業務の種類、時期、程度 • 情報システムイニシアティブにおける監査以外の業務の役割だけでなく、情報システムイニシアティブの 監査もしくは関連する部門へ関与した理由 • 独立性および客観性に対して、監査業務および報告プロセスにおける重大な侵害がなかったという保 証を提供するための取られた手順 • 可能性のある独立性の侵害に対して、監査以外の業務の役割が実施される前に、監査委員会もしくは 同等なガバナンス組織および彼らから得られた合意書にハイライトされていたという事実 • 監査業務のパフォーマンスにおける信頼性のレベルが受け入れ可能であることを保証するレビューの存 在と程度 8 適用開始日 本ガイドラインは、2010年5月1日にレビューされ、改訂された。 101 G18 ITガバナンス 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 103 2 監査ポリシー‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 103 3 独立性‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 104 4 計画策定‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 104 5 監査業務のパフォーマンス‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 105 6 報告‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 107 7 フォローアップ活動‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 108 8 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 108 G18 ITガバナンス 1 背景 1.1 基準との関連 1.1.1 基準S6『監査業務のパフォーマンス』は、 「監査の過程において、情報システム監査人は、監査の目的を 達成するために、確実で妥当な証拠を充分得るべきである。監査の発見事項と監査の結論は、この証拠 を適切に分析し、解釈することにより裏付けられる。」と述べている。 1.2 ガイドラインの必要性 1.2.1 COBITエグゼクティブサマリーは、 「組織は、他のすべての資産と同様、情報資産に対しても、その品質、 受託者としての責任、セキュリティにかかわる要求事項を満たさなければならない。また、 マネジメント層は、 データ、アプリケーションシステム、テクノロジー、施設、要員といった、利用可能な資源の利用を最適化し なければならない。これらの責務を果たし、組織の目標を達成するために、 マネジメント層は、適正な内部 統制の仕組みを定めなければならない。｣と述べている。 1.2.2 経済および社会面の活動のあらゆる点でテクノロジーが利用されるようになり、経済取引や情報、知識の すべてにおいて、その開始、記録、移転、管理が情報テクノロジーへ決定的に依存する状態が引き起こされ てきた結果、企業のガバナンスにおいてITガバナンスが極めて重要な位置を占めることとなっている。 1.2.3 様々な公共部門や民間部門でウイルス攻撃によるシステム障害や、ウェブサイトハッキングによる信頼ある いはシステムの可用性の喪失といった問題が話題となっており、企業ガバナンスの課題に注目が集まってき ている。組織の事業および財務活動における有効な内部統制システムを確立するという責任を果たすた めに経営者が用いる正式の手法は、世間から厳しく監視されることがあり、また情報システムの内部監査 人および外部監査人の監査範囲に含まれることが多い。 1.2.4 本ガイドラインの目的は、情報システム監査人がITガバナンスに関する監査にどのように臨むべきかについ て、関与する情報システム監査人が組織上どのような立場であるのが適切かという点や、監査計画時に考 慮すべき事項、監査実施時にレビューすべき証拠を含めて、情報を提供することである。 2 監査ポリシー 2.1 権限 2.1.1 企業ガバナンスの一領域として、ITガバナンスは、企業におけるITの適用を検討する際に取り組むべき一連 の課題から構成されている。今やITは企業の他の部分から取り残された独立した機能ではなく、企業にお いて極めて重要な基礎をなしており、広範に普及している。企業におけるITの利用は、企業がその使命、ビ ジョンあるいは戦略目標を達成するかどうかに非常に大きな影響をもっている。このため、企業ガバナンス 全体の中でITガバナンスがますます重要な部分を占めてくるにつれ、企業がITガバナンスを評価することが 必要となっている。ITガバナンスに関する報告には組織の最上位レベルの監査が含まれ、事業部・機能・ 部門の境界を越えて行われることがある。情報システム監査人は業務指示書に次の点が述べられているこ とを確認すべきである。 • 対象とすべき機能領域と課題を含む業務範囲 • ITガバナンスの課題が組織の最上位レベルにかかわる場合の報告ライン • 情報システム監査人の情報アクセス権 103 G18 ITガバナンス 3 独立性 3.1 組織上の地位 3.1.1 情報システム監査人は、計画された監査の性質に照らして自らの組織上の地位が適切であるか検討すべ きである。もし不適当と考えられる場合には、適切なレベルのマネジメントが、当該監査の管理あるいは実 施のために独立第三者を雇用することを検討すべきである。 4 計画策定 4.1 事実調査 4.1.1 情報システム監査人は、次の各項に責任を有するレベルを含むITガバナンスの構造について情報収集すべ きである。 • 企業のガバナンス • 企業戦略方針の決定 • 企業戦略導入時のCEO・経営者のパフォーマンスの評価 • （関連する知識、情報および技術を含め、）実行中の戦略について報告を行う、経営上層部および部下 のパフォーマンスの評価 • 企業が設定された戦略目標の達成に必要となる技能およびITインフラストラクチャを開発しているかの 決定 • 企業が現在の業務を維持するための能力を有しているかの評価 4.1.2 情報システム監査人は、下位レベルに対して達成目標を設定するためのコミュニケーションルート（トップ ダウン）、およびコンプライアンス状況をモニタリングするための情報（ボトムアップ）を含め、ITガバナン ス構造において4.1.1項に記載された機能を実行可能としているプロセスを識別し、その全般的理解を得る べきである。 4.1.3 情報システム監査人は、 （文書化されている・いないにかかわらず）以下の事項を含む組織の情報システム 戦略に関する情報を入手すべきである。 • 組織の使命と目標を実現するための長期および短期計画 • これらの計画を支援するための、ITおよびシステムに関する長期および短期の戦略と計画 • IT戦略および開発計画と進捗のモニタリングの設定に関するアプローチ • IT戦略と計画の変更管理に関するアプローチ • ITに関する任務記述書およびIT関連活動に対する合意された達成目標 • 現行のIT関連活動とシステムに対する評価 4.2 情報システム監査の目的 4.2.1 ITガバナンスの監査目的は、報告を受ける人のニーズと公開範囲により影響を受けることがある。情報シス テム監査人は、監査の全般的な目的を定める際に次の選択肢を考慮すべきである。 • ガバナンスシステムとその有効性のいずれか、あるいは両方を報告対象とするか • 会計情報システムを含めるか否か • 会計情報システム以外のシステムを含めるか否か 4.2.2 ITガバナンスに関する情報システム監査の詳細目的は、通常、経営幹部層が適用する内部統制のフレーム ワークによって決まる。フレームワークが定められていない場合、詳細目的を設定する際の最小限の基準と してCOBITフレームワークを利用すべきである。 104 G18 ITガバナンス 4.3 監査範囲 4.3.1 情報システム監査人は、ITアクティビティの計画と準備に関するプロセス、およびITアクティビティのモニ タリングに関するプロセスを監査範囲に含めるべきである。 4.3.2 監査範囲には COBITフレームワークに定義されているすべてのIT資源の使用と保護に関するコントロールシステムを含 めるべきである。これには次のものが含まれる。 • データ • アプリケーションシステム • 技術 • 施設 • 要員 4.4 スタッフィング 4.4.1 情報システム監査人は、当該レビューの実施メンバーに適切な経験と能力を有する人々を含めることに合 理的な保証を提供すべきである。 5 監査業務のパフォーマンス 5.1 経営幹部層の活動のレビュー 5.1.1 企業ガバナンスの一部としてのITガバナンスは、ビジネス達成目標に基づいて推進されるべきである。情報 システム監査人は、次の点を検討のうえ、ビジネス戦略計画プロセスが整備されているか評価すべきであ る。 • ビジネスのビジョンと使命が明確に定義されているか • ビジネス戦略計画の方法論が用いられているか • 当該プロセスに関与する人々のレベルが適切か • 当該計画は定期的に更新されているか 5.1.2 IT戦略計画プロセスのレビューにおいて、情報システム監査人は次の点を考慮すべきである。 • ITの使命とビジョンが明確に定義されているか • 戦略的IT計画の方法論が整備されているか • 方法論はビジネス達成目標をITビジネス達成目標と関連付けているか • 当該計画プロセスは定期的に（少なくとも年1回）更新されているか • 当該計画において主要なIT構想と必要な資源が識別されているか • 当該プロセスに関与する人々のレベルが適切か 5.1.3 IT施策計画のレビューにおいて、情報システム監査人は次の点を考慮のうえ、プロジェクト管理が実践され ているか考慮すべきである。 • プロジェクト管理方法論の適用範囲 • プロジェクト管理において適用されるコントロール • 使用されるプロジェクト管理ツール • プロジェクトの様々な段階におけるIT担当者とビジネス担当者の協業 • 組織の重要な変更を伴う大規模プロジェクトで用いられる変更管理方法論 105 G18 ITガバナンス 5.1.4 サービス提供プロセスのレビューにおいて情報システム監査人が考慮すべき点は次の通り。 • 整備されている業務処理統制（アプリケーション開発に関するCOBIT目標） • 開発・保守プロセス • プロジェクト管理プロセス（上記5.1.3項） 5.1.5 アプリケーション開発の方法論と実践、および開発プロセスに適用されるコントロールに重点を置き、情 報システム監査人はレビューに次の点を含めることがある。 • アプリケーション開発方法論（例えば高度に構造化されており、アウトソーシングや分散システムといっ た環境の特徴を考慮した開発ライフサイクルのすべての局面をカバーしているといった観点で、方法論 の品質を検討） • プロジェクトの規模見積や進捗の評価に用いられる開発指標 • テストにおける課題から学び、将来のプロジェクトに向けて方法論やコントロールを強化するため、テス ト課題の検証に用いられる技法 5.1.6 現行システムのポートフォリオ管理プロセスのレビューにおいて、情報システム監査人は現行システムが組 織の戦略支援領域をカバーしているか検討すべきである。情報システム監査人は次の点をレビューに含め ることがある。 • ビジネス戦略計画プロセスで定めた戦略領域について規定したポリシーの全般的対象範囲 • 経営幹部層により監視される、ポリシーへのコンプライアンスに関する入念な検討・周知・実施・モニタ リングのプロセス • 以下に関する適切な文書化されたポリシー セキュリティ、人的資源、データのオーナシップ、エンドユーザコンピューティング、知的財産、データ保 持、システムの調達と導入、アウトソーシング、独立した保証、継続計画、保険、プライバシー • レビュー対象プロセスに関わる人々（例えばデータオーナ、IT管理者、経営管理者）の役割と責任の定 義、およびそれらがレビュー対象プロセスを適切に支援しているかの評価 • レビュー対象プロセスに関わる人々が役割を果たすに足る技能、経験および資質を有しているか • 適切なレベルの内部監査の関与が定められているか（組織が内部監査要員を有している場合） • 組織がビジネス目標の達成にITを最大限に活用できるようにするため、IT専門家メンバー・部門の組織 における位置付けが適切なものとなっているかの評価 • IT専門家メンバーおよびIT専門家以外でITに責任を有する人々の組織およびマネジメントが、組織に対 する誤謬・遺漏・例外処理・違法行為のリスクに対処する能力があるかの評価 106 G18 ITガバナンス 5.1.7 情報システム監査人は、上述のレビューで入手した監査証拠が適切な領域をカバーしているか検討すべ きである。検討すべきトピックはCOBITのITガバナンスマネジメントガイドラインで規定されている。本ガ イドラインには、ITガバナンスをその達成へと推進するための、重要目標達成指標（KGI）、主要成功要因 （CSF）および重要成果達成指標（KPI）が含まれている。検討すべき事項の例として次があげられる。 • ITに関する任務記述書およびITのアクティビティに対する合意された達成目標と目標 • 組織のIT資源の利用に伴うリスクの評価および当該リスクの管理アプローチ • IT戦略導入のためのIT戦略計画および計画比進捗のモニタリング • IT予算と差異のモニタリング • ITの利用と保護に関する上位レベルのポリシーおよび当該ポリシーへのコンプライアンスのモニタリン グ • 同様の組織・機能・適切な国際標準・成熟度モデル・広く認められているベストプラクティスとのベンチ マーキングといった、ITに関連する成果達成指標の比較 • 合意した成果達成指標に対する達成状況の定期的なモニタリング • ガバナンス部門によるITの定期的レビューの証拠。これには識別され、割り当てられ、解決され、フォ ローアップされるアクションアイテムを含む • 上記5.1.1項から5.1.5項に記載したプロセス間の有効かつ有意の連携の証拠 5.1.8 情報システム監査人は、経営幹部層がITに関して適切な管理活動を開始しているか、およびこれらの活動 が適切にモニタリングされているかについて検討すべきである。 6 報告 6.1 受取人 6.1.1 情報システム監査人はITガバナンスに関する報告を監査委員会および経営幹部層に行うべきである。 6.1.2 ITガバナンスにおいて不適切な点が識別された場合には、監査ポリシーに規定された適切な者またはグ ループに速やかに報告すべきである。 6.2 内容 6.2.1 報告に関する他のISACA基準へのコンプライアンスに加え、業務指示書に従って、ITガバナンスに関する 監査報告には次を含めるべきである。 • 経営幹部層が組織の内部統制システムに責任を有するとした記述書 • 内部統制システムが重要な虚偽表示あるいは損失に対して合理的だが絶対的ではない保証を与えるに 過ぎないとした記述書 • 経営幹部層が有効なITガバナンスシステムと関連する支援文書を提供するために定めた重要な手続の 記述 • 組織のポリシー、関連法令あるいは企業ガバナンスに関する業界の行動基準に対する違反情報 • コントロールが存在しない主要なリスクに関する情報 • 有効でない、もしくは効率的でないコントロール構造・コントロール・手続・改善に関する情報システム 監査人の勧告事項の情報 • 業務指示書に規定されている、ITガバナンスに関する情報システム監査人の全般的な結論 107 G18 ITガバナンス 7 フォローアップ活動 7.1 適時性 7.1.1 企業ガバナンスシステムにおける脆弱性の影響は通常広範囲におよび、かつ高リスクである。したがって、 脆弱性に対するマネジメントの対応が遅滞なく実施されているか確認するため、情報システム監査人は必 要に応じて十分かつ適時のフォローアップ作業を実施すべきである。 8 適用開始日 8.1 本ガイドラインは2002年7月1日以降に開始するすべての情報システム監査に適用される。 付録－用語集 COCO－コントロール基準（criteria of control）。カナダ勅許会計士協会1995年発行。 コーポレートガバナンス統合規範(Combined Code on Corporate Governance）－キャドベリー報告、グ リーンベリー報告およびハンペル報告を1998年に整理統合したもの。委員長の名前が付いたこれらの報 告書は、英国財務報告委員会（FRC）、ロンドン証券取引所、英国産業連盟（CBI）、英国ディレクター協 会（IoD）、会計団体諮問委員会（CCAB）、英国全国年金基金協会（NAPF）、英国保険業協会（ABI）の 後援を受けて、コーポレートガバナンスの財務的側面、役員報酬およびキャドベリーとグリーンベリー勧告 の導入に取り組んだもの。 企業ガバナンスのためのコントロール目標（Control Objectives for Enterprise Governance）－良好な企 業ガバナンスを促進する企業のビジネス目標と情報テクノロジーの実現要因に重点をおいた「企業ガバナ ンスモデル」について発表した討議資料。情報システムコントロール財団、1999年発行。 コーポレートガバナンス（Corporate Governance）－"… [T]he structure through which the objectives of an organisation are set, and the means of attaining those objectives, and determines monitoring performance guidelines. Good corporate governance should provide proper incentives for board and management to pursue objectives that are in the interests of the company and stakeholders and should facilitate effective monitoring, thereby encouraging firms to use resources more efficiently." （ISACA東京支部訳：「組織の目標設定の仕組み、それら目標の達成手段、ならびにパフォーマンスモニ タリングガイドラインを決定する。良好なコーポレートガバナンスとは、取締役会およびマネジメントに対 して会社とその利害関係者の利益目標の達成に向けた適切なインセンティブを提供するものでなければ ならず、かつ有効なモニタリングを促進することで資源のより効率的な利用を促すものでなければならな い。」 （出典：OECDコーポレートガバナンス原則、OECD、1999年） COSOレポート（COSO Report）－米国トレッドウェイ委員会組織委員会が1992年に公表した“Internal Control - An Integrated Framework” （「内部統制の統合的枠組み」）に関する報告書。全ての組織に対 する内部統制のガイダンスおよび包括的フレームワークを提供している。 企業ガバナンス（Enterprise Governance）－グローバル戦略提携パートナーなど関連組織もカバーし た、コーポレートガバナンスに関する一般的かつ広範な概念。 （出典： Control Objectives for Enterprise Governance Discussion Document、情報システムコントロール財団、1999年） 108 G18 ITガバナンス 内部統制（Internal Control）－「事業目標の達成、および望ましくないイベントの阻止または発見と是正 を合理的に保証するように設計されたポリシー、計画、手続、および組織構造。」 （出典：COBITフレーム ワーク） ITガバナンス（IT Governance）－ITとそのプロセスにおけるリスクとリターンの均衡をとりつつ、付加価値 によって企業の目標を達成していくために企業の方向付けを行い、コントロールするための関係とプロセス の構造。 成果達成指標（Performance Indicators）－パフォーマンス目標の達成度合いを継続的に測定するために 設定された一連の測定指標。サービスレベルアグリーメント、重要性項要因、顧客満足度、内部あるいは 外部ベンチマーク・業界のベストプラクティス・国際基準などが含まれる。 合理的な保証（Reasonable Assurance）－絶対的に保証するには至らないが、コントロールに要する費用 と得られるであろう便益を考慮したうえで十分であるとの心証が得られる状態。 業務指示書（Terms of Reference）－依頼人と情報システム監査人のレビュー業務受諾確認文書。 経営幹部層（Top-Level Management）－組織全体の方向付けとコントロールに責任を有する、組織の最 上位のマネジメント（例えば、取締役、総支配人、共同経営者、最高責任者）。 109 G19 例外と違法行為 －2002年7月に削除され、G9に統合されたー G20 報告 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 112 2 はじめに‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 113 3 保証‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 113 4 情報システム監査意見‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 115 5 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 117 G20 報告 1 背景 1.1 基準との関連 1.1.1 基準S7『報告』は、 「情報システム監査人は、監査終了後直ちに、適切な様式の報告書を提出すべきであ る。この報告書には、報告書提出先の組織、具体的な宛先（受領者)、回覧上の制限を明記（識別）してお くべきである。監査報告書には、監査適用範囲、監査目的、監査対象期間、実際に行われた監査作業の 種類・時期・程度を記載すべきである。報告書には、監査発見事項、監査の結論、勧告事項、情報システ ム監査人が当該監査に関し述べておくべき留保事項・制限事項・監査対象範囲の制約を記載すべきであ る。」と述べている。 1.2 定義 1.2.1 アクティビティの主題または領域は、IT監査・保証の専門家の報告書と関連の手続に固有の情報の対象 となる。それは、内部統制や、プライバシー保護、基準、または特定の法令の遵守の整備あるいは運用のよ うなものを含めることができる。 1.2.2 証明される報告契約は、IT監査・保証の専門家が特定の主題についてマネジメントの主張を検証するか、 直接主題に関する契約である。IT監査・保証の専門家の報告書は次の一つの意見からなる。 • 主題。これらの報告書は主張よりも主題に直接関係する。特定の状況において、 マネジメントは契約の 主題を超えて主張をすることができなくなる。このような状況の例は、ITサービスがサードパーティへア ウトソースされているときである。マネジメントは通常サードパーティの責任を超えてコントロールの主張 をすることはできない。従ってIT監査・保証の専門家は主張よりも主題を直接報告する。 • コントロール手続の有効性ついてのマネジメントの主張 • IT監査・保証の専門家が特定の主題について意見を提出する調査報告契約。これらの契約はマネジメ ントによって導入されたコントロールとその運用の有効性の報告書を含んでいる。 本ガイドラインは意見の最初のタイプに向けられている。参照の観点が意見の後者のタイプに要求されて いるのであれば、報告要求は調整される必要があってよい。 1.2.3 コントロール目標は、コントロール（コントロール手続）の開発と導入のフレームワークとして使われるマネ ジメントの目標である。 1.2.4 コントロールあるいはコントロール手続とは、関連するコントロール目標を成すための政策と手続を意味 する。 1.2.5 コントロールの欠陥とは、コントロール手続の整備あるいは運用における不備を意味する。コントロール の欠陥は、潜在的に受容できるレベルを減少させないアクティビティの領域に関係するリスクの結果であ る（関係するリスクとは、試験されるアクティビティの領域に関する目標達成を脅かすリスク）。一つあるい は複数のコントロール手続の整備あるいは運用が、比較的低レベルまで、リスクを減少しないとき、コント ロールの欠陥は重要になる。このリスクとは、不正行為あるいは例外処理が発生するかもしれず、関係する コントロール手続によって発見されないかもしれないことである。 1.2.6 規準は、測定し、主題を提示する、そして、IT監査・保証の専門家が評価する主題に対して提示する標準と ベンチマークである。 規準は、次のとおりである。 • 要件—偏向からの解放 • 測定可能—一定の物差しの提供 • 完全—結果に至るすべての関係する要因を含む • 関係—主題に関連 112 G20 報告 1.2.7 ダイレクトレポーティング契約は、コントロール手続の有効性について記載された主張をマネジメントが作 らない、そして、IT監査・保証の専門家が主題について、コントロール手続の有効性のような意見を直接提 供する契約である。 1.2.8 内部統制構造（内部統制）は、運営組織、 マネジメント、他のスタッフによる影響を受けるダイナミックで統 合されたプロセスである。 そして、次のような一般目的の達成に関して合理的な保証を与えることが設計されている。 • 運用の有効性、効率性、経済性 • マネジメントの信頼性 • 適用される法律、規則、内部ポリシーに準拠 1.2.9 これら一般目的を達成するためのマネジメントの戦略は、次の成分の整備と運用によって影響を受ける。 • コントロール環境 • 情報システム • コントロール手続 1.3 ガイドラインの必要性 1.3.1 本ガイドラインは、企業の情報システムコントロールと、関連するコントロール目標に報告するとき、IT監 査・保証の専門家は、ISACAのIT監査や保証基準とCOBITに準拠すべき方法を設定する。 2 はじめに 2.1 本ガイドラインの目的 2.1.1 本ガイドラインの目的は、報告にとりくむIT監査・保証の専門家に対してアクティビティの特定領域に対す るコントロール手続が次のどちらかに有効である方向性を提供することである。 • 運営組織、運用レベルにおける一企業のマネジメント • 特定のサードパーティ、例えば監督機関あるいは他の監査人 2.1.2 IT監査・保証の専門家は、整備の有効性あるいは運用の有効性を報告することに従事してもよい。 3 保証 3.1 サービスのタイプ 3.1.1 IT監査・保証の専門家は、次のどれかを実施する。 • 監査（直接あるいは証明） • レビュー（直接あるいは証明） • 合意手続 3.2 監査とレビュー 3.2.1 ひとつの監査は、コントロール手続の有効性について、絶対ではないが、保証の高いレベルを提供する。 これは通常、判断、テスティングの利用、内部統制の継承する制限の必要性などの要因のため、絶対的な 保証が、めったに達成可能でない事実の認識のなかで、合理的な保証として表現される。そして、それはIT 監査・保証の専門家にとって、種類の中で決定的よりむしろ説得力のある入手可能な証拠が多いからであ る。 113 G20 報告 3.2.2 レビューは、コントロール手続の有効性について適度なレベルの保証を提供する。提供される保証レベル は、監査の中で提供されるより少ない。というのは、作業の範囲が監査の適用範囲より広くなく、実施され た（監査）手続の種類、時期、程度は、IT監査・保証の専門家が積極的な意見を表明しえる、十分で適切 な監査の証拠を提供しないからである。レビューの目的は、手続の基礎に基づいて、IT監査・保証の専門 家はコントロール手続が識別された規準（否定的な保証の表現）に基づいてIT監査・保証の専門家が有 効でないと信じてしまうことに注意を与えるかどうかを言えるようにすることである。 3.2.3 コントロール手続の監査とレビューの両方は次の事項を含む。 • 契約の計画策定 • コントロール手続の整備有効性の評価 • コントロール手続の運用有効性のテスティング（テスティングの種類、時期、程度は監査とレビューの間 で様々となる） • 次の識別された規準に基づいたコントロール手続の整備と運用の有効性評価について、結論を形成し、 報告する。 –– 監査の結論は、意見の積極的な表明と高レベルな保証の提供として表明される –– レビューの結論は、否定的な保証の声明と保証の適度なレベルのみを提供するとして、表明される 3.3 合意した手続 3.3.1 合意した手続の契約は、IT監査・保証の専門家によるどのような保証の表現中にも結論づけない。IT監 査・保証の専門家は、実施されるべき合意した手続を持つ関係者の情報ニーズに合わせた特別な手続を 行うことに従事する。IT監査・保証の専門家は、合意した手続を持つ関係者の事実認定の報告書を提出 する。IT監査・保証の専門家は、どのような保証を表明することができる手続の種類、時期、程度を持た ないので、受領者はこの報告書から独自の結論を形成する。報告書は、他者は手続の理由を知らないと結 果を誤って解釈することがありうるので、実際に行われるべき手続に合意した関係者（例えば、規制機関） に限定される 3.4 合意した手続の報告 3.4.1 合意した手続の報告書は、手続と発見事項の形式の中にあるべきである。報告書は次の要素を持つべき である。 • 独立した用語を含むタイトル • 特別な関係者の識別 • 主題（あるいはこれらに関する書かれた主張）の識別と契約の種類 • 責任を担う関係者の識別 • 主題が責任を担う関係者に対する責任の記述 • 実際に行われる手続が、報告書の中で、識別された関係者によって合意されたという記述 • 手続の十分性は、単に特定の関係者の責任であり、これら手続の十分性に責任の免責であるという記述 • 実際に行われる（あるいはこれらに関連する）手続と関係する発見事項のリスト • IT監査・保証の専門家が従事せず、主題の調査をしなかったという記述 • もしIT監査・保証の専門家が追加の手続を実施したら、他の事柄はIT監査・保証の専門家の注意する ところとなり、報告されるだろうという記述 • 単に特定の関係者によって使用されるつもりであるので、報告書の使用には制限があるという記述 114 G20 報告 3.5 契約権限 3.5.1 契約が規制または同様に課される要件を満たすために行われるものである場合は、契約の種類が関連す る法律や契約権限のほかの情報源からも明らかであることに、IT監査・保証の専門家が満足することが 重要である。不確実性がある場合、IT監査・保証の専門家、指名された関係者は、関連する監督機関、確 立や要求を規制する責任をもつ関係者に照会し、契約の種類と提供される保証に同意することが推奨さ れる。 3.5.2 契約の完了前に、監査からレビューまでの契約、合意された手続の契約の変更を要求されるIT監査・保証 の専門家は、そうすることの適切性を考慮する必要があり、その変更に合理的な正当化がない場合は変更 に同意できない。例えば、変更は修正報告書を回避するのに適切でない。 4 情報システム監査意見 4.1 制限 4.1.1 IT監査・保証の専門家の意見は、十分な適切な証拠（種類の中で決定的であるよりむしろ説得性のある 証拠）の収集に必要であることを決定する手続に基づいている。保証は、IT監査・保証の専門家により提 供される。しかし、内部統制の性質と内部統制とその運用のいかなる集合の継承する制限のため、限定さ れた内部統制の有効性に基づいている。 これらの制限は、次の事項を含む。 • 内部統制のコストがそれから得られる利益を超えてはならないことは、 マネジメントの通常の要求である • ほとんどの内部統制はルーチンでないトランザクション、事象よりもルーチンに向かう傾向にある • 人間の不注意、注意散漫、疲労に起因するエラー、指示の誤解、そして判断ミスの可能性 • 互いの、または外部企業の関係者と社員の衝突を通して、内部統制の回避の可能性 • 内部統制を行使する責任者が、その責任、例えば、コントロールの手続を無視するマネジメントのメン バーを乱用する可能性 • マネジメントは、他の職員に適用されるのと同じ内部統制の対象ではないかもしれないという可能性 • 条件の変化による内部統制が十分でなくなることと、手続のコンプライアンスが悪化することという可 能性 4.1.2 習慣、文化、 （会社とITの）システムガバナンスは、 マネジメントによる不正を抑制することがあるが、絶対確 実の抑止力ではない。効果的なコントロール環境は、このような不正の確率を軽減することがある。そのよ うな効果的な運営団体、監査委員会、内部監査機能のようなコントロール環境の要因は、 マネジメントが 不正行為を抑止するかもしれない。一方で、効果的でないコントロール環境は、内部統制構造の中でコン トロール手続の効果を阻害するかもしれない。例えば、企業は環境規制に従って関連した十分なITコント ロール手続を持っているけれども、 マネジメントは企業の一般的なイメージに悪影響を反映する、検出され た違反に関する情報を抑制する強力な偏向があるかもしれない。内部統制の有効性や妥当性はまた、所 有権またはコントロールの変更、 マネジメントまたはその他の職員の変更、企業の市場や業界の発展など の要因によって影響を受ける可能性がある。 4.2 後発事象 4.2.1 主題がテストされたものの、IT監査・保証の専門家の報告書の日付の前の時または期間に続いて、主題に 重要な影響を与え、従って主題または主張のプレゼンテーションの調整または開示を求める事象が、時々 発生する。この発生は後発事象として参照される。証明業務に従事する中で、IT監査・保証の専門家は自 分の注意するように後発事象についての情報を考えるべきである。しかし、IT監査・保証の専門家は後発 事象を発見する責任はない。 115 G20 報告 4.2.2 マネジメントが主題の事象か主張に重要な影響を持つ後発事象を知っているかどうか、IT監査・保証の専 門家の報告書の日付まで、IT監査・保証の専門家はマネジメントに問い合わせるべきである。 4.3 結果と報告 4.3.1 IT監査・保証の専門家は、十分適切な証拠が報告書の中における結論を支援するために得られたかどう かを結論付けるべきである。報告書を作成する際、すべての関係する獲得証拠が、それが主題情報を裏付 けるか矛盾として現れるかどうかに関係なく、考慮されるべきである。一つの意見がある場合、それは識別 された規準に基づいたコントロール手続の結果によって支援されるべきである。 4.3.2 コントロール手続の有効性についてのIT監査・保証の専門家の報告書は、次の事項を含むべきである。 • 表題 • 受取人 • 監査の適用範囲、主題が関連する事象、または、次の事項を含んだ主題に関係する事象のコンポーネン トの名前： –– アクティビティの領域の識別または記述 –– IT監査・保証の専門家の結論に対する基礎として使用された規準 –– 関係する主題が関連する作業、評価、測定のための時または期間の時点 –– アクティビティの領域に対する内部統制コントロール手続を含み、有効な内部統制構造の保守はマネ ジメントの責任であるという記述 • 契約が証明された契約である場合、コントロール手続の有効性について、 マネジメントの表現の源を識 別する記述 • IT監査・保証の専門家がコントロール手続の有効性に対する意見を表明する契約を実施しているとい う記述 • IT監査・保証の専門家の報告書が準備され、報告書が信頼に足る権利が与えられている目的、および、 他の目的のために、或いは他の人による使用に対する責任の免責事項の識別 • 規準、または規準の源の免責事項の記述 • ISACA「情報システム監査基準」 （IT Audit and Assurance Standards）または他の適用可能な専門の 標準によって監査が行われたという記述 • 提供される保証と適切な他の情報に影響する変数についての更なる説明詳細 • 適切な場合、個別のレポートが是正措置の勧告事項が含まれており、 マネジメントの対応を含めるべきで ある。 • 任意の内部統制の固有の限界のため、エラーのために虚偽や不正の記述は発生し、検出されない場合 があると、ひとつのパラグラフは示している。さらに、その段落は、将来の期間の財務報告に係る内部統 制の任意の評価の予測には、状況の変化の内部統制が不十分となるかもしれないか、方針や手続きに 応じたレベルが低下するかもしれないリスクを伴うということを述べるべきである。監査は、期間を通じ て継続的に実施し、そのコントロール手続で行われるテストはサンプルベースで実施されないように、コ ントロール手続ですべての弱点を検出するように設計されてはいない。IT監査・保証の専門家の意見が 認められているときは、資格を記述するひとつのパラグラフが含まれるべきである。 • すべての重要な点において、アクティビティの領域との関係でコントロール手続の整備と運用が効果的 だったかどうかについての意見の表現 • IT監査・保証の専門家の署名 • IT監査・保証の専門家の住所 • IT監査・保証の専門家の報告書の日付。ほとんどの実例では、レポートの日付は、該当する専門的な基 準に基づいている。他の実例では、レポートの日付はフィールドワークの結論に基づいているべきである。 116 G20 報告 4.3.3 ダイレクトレポーティング契約において、IT監査・保証の専門家は主張よりむしろ主題で直接的に報告す る。その報告書は、契約の主題に関してのみ参照を行うべきであり、主題に関するマネジメントの主張へ の参照を含めるべきではない。 4.3.4 IT監査・保証の専門家がレビューの契約を引き受ける場合に、報告書は、結論が整備上および運用上の 有効性に関連していること、そして、運用上の有効性に関連するIT監査・保証の専門家の作業が、主に問 い合わせ、検査、観察、内部統制の運用の最小限のテストに制限されることを示す。報告書は、ある監査 が実施されない、引き受けられた手続きはある監査よりも少ない保証を提供する、そして、監査意見が表 明されないという文を含む。消極的保証の状態の表現は、企業のコントロール手続が、あらゆる材料の点 で、識別された規準に基づいて、アクティビティの領域との関係で無効となったと信じる原因であったこと がIT監査・保証の専門家の注意を引いていないことを述べる。 4.3.5 契約の過程でIT監査・保証の専門家は、コントロールの欠陥を意識するようになるかもしれない。IT監 査・保証の専門家は、適時に、適切なレベルのマネジメントに、識別されたコントロールの欠陥を報告する べきである。契約手続は、婚約の条件に従って結論を形成するのに十分かつ適切な証拠を収集するよう に設計されている。 契約の条件で特定の要件がない場合には、IT監査・保証の専門家は、 マネジメントに報告するために適切 かもしれない事項を識別する手続を設計する責任を持っていない。 5 適用開始日 5.1 本ガイドラインは、2000年9月16日以降に開始されるすべてのIT監査に適用される。 117 G21 ERPシステムレビュー 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 119 2 ERP システム‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 121 3 情報システム監査基準で効果的なコンプライアンスの達成‥ ‥‥‥ 124 4 有効日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 130 G21 ERPシステムレビュー 1 背景 1.1 ISACA基準との関連 1.1.1 ISACA IT監査・保証ガイドラインと同じように、情報システム監査基準は、エンタープライズリソースプ ランニング（ERP）システムやERPシステム導入プロジェクト上の情報システム監査の監査業務に直接関 連性を持っている。 1.1.2 例えば、基準S6『監査業務の成果』は、 「情報システム監査のための付随する情報システムか他の監査ス タッフによる監査業務に関連したERP関連の成果の管理は、IT監査・保証の専門家による十分かつ適切 な管理がなされる必要がある。」と述べている。 1.1.3 さらに、IT監査・保証の専門家がERPシステムや導入プロジェクトに関連付けられている非監査または非 保証の役割に関与することが要求されるような状況においては、S2『独立性』とG12『組織の関係と独立 性』に関連する情報システム監査基準とガイドラインに加えて、IT監査・保証の専門家は、ISコントロール 専門家のためにISACA基準の適用可能性を適切に考慮し、レビューする必要がある。 1.1.4 ERPアプリケーションがスコープになる場合は、ISACAのIT監査・保証ガイドラインG14『アプリケーショ ンシステムレビュー』を検討する必要がある。 1.1.5 IT監査・保証の専門家は、ERPシステムの導入および使用に関連するビジネスプロセスリエンジニアリン グ（BPR）の活動における監査または非監査または非保証の観点から関与することが求められている場 合、ISACAのIT監査・保証ガイドラインG26『ビジネスプロセスリエンジニアリング（BPR）プロジェクト レビュー』を検討する必要がある。 1.1.6 ERPシステムのいずれかのコンポーネントが第三者にアウトソーシングされる場合は、ISACAのIT監査・保 証ガイドラインのG4『他の組織への情報システム活動のアウトソーシング』、G16『企業のITコントロール に関わるサードパーティの影響』を検討する必要がある。 1.1.7 ISACAの専門基準委員会の公式見解に加えて、そのリサーチボードは、ISACAのウェブサイト（www. isaca.org）を介して利用できるか、特定のERP製品と使用されている他のリソースに応じて興味深いと思 われる多数のプロジェクトや成果物を持っている。 1.2 COBITへのリンケージ 1.2.1 個々の監査範囲に適用可能であるCOBITの中から最も関連する材料の選択は、特定のCOBIT ITプロセ スを選択し、COBITのコントロール目標と関連するマネジメントの実行を勘案して行う。選択もしくは適応 されるITプロセスおよびそのコントロール目標は、特定の監査範囲や監査すべき対象によって異なる。 1.2.2 本ガイドラインは、特定のブランドのERPへの適応を制限することを避けるために起草されている。また、 企業内でのERPの利用のあらゆる側面をカバーするために起草されている。したがって、ガイドラインは、 全ての4つのCOBITのドメイン、計画と組織、調達と導入、サービス提供とサポート、およびモニタリングと 評価、と関連付けされる。特定の監査プロジェクトは、特定のビジネスエンティティの特定のERPの一局 面にそのプロジェクト憲章によって制限されるべきであるし、当然、適用されるCOBITのドメインとビジネ スプロセスは、それに応じて制限される。これを説明するために、次の2つの例が用意されている。これら は網羅的に意図されておらず、監査の特定のスコープには、合理的にどのプロセスが含まれるか変更され ることがある。 119 G21 ERPシステムレビュー 例1。ERPの計画と買収の監査/レビュー 計画と組織： PO1 IT戦略計画の策定 PO2 情報アーキテクチャの定義 PO3 技術的指針の決定 PO4 ITプロセスと組織およびそのかかわりの定義 PO5 IT投資の管理 PO6 マネジメントの意図と指針の周知 PO7 IT人材の管理 PO8 品質の管理 PO9 ITリスクの評価と管理 PO10 プロジェクト管理 調達と導入： AI1 コンピュータ化対応策の明確化 AI2 アプリケーションソフトウェアの調達と保守 AI3 技術インフラストラクチャの調達と保守 AI4 運用と利用の促進 モニタリングと評価： ME3 外部要件に対するコンプライアンスの保証 例2。古いERPシステムの監査/レビュー 計画と整理： PO4 ITプロセスと組織およびかかわりの定義 PO5 IT投資の管理 PO7 IT人材の管理 PO8 品質の管理 PO9 ITリスクの評価と管理 調達と導入： AI2 アプリケーションソフトウェアの調達と保守 AI3 技術インフラストラクチャの調達と保守 AI4 運用と利用の促進 AI6 変更管理 サービス提供とサポート： DS1 サービスレベルの定義と管理 DS2 第三者のサービスの管理 DS3 性能とキャパシティの管理 120 G21 ERPシステムレビュー DS4 継続的なサービスの保証 DS5 システムのセキュリティの保証 DS6 費用の捕捉と配布 DS7 利用者の教育と研修 DS8 サービスデスクとインシデントの管理 DS9 構成管理 DS10 問題管理 DS11 データ管理 DS12 物理的環境の管理 DS13 オペレーション管理 モニタリングと評価： ME1 IT成果のモニタリングと評価 ME2 内部統制のモニタリングと評価 ME3 外部要件に対するコンプライアンスの保証 1.3 ガイドラインの必要性 1.3.1 製造業の製造資源計画システムから発展したERPシステムは、部門横断的管理とプロセスの情報を提供 する事業領域の広い範囲からデータを使用する。"ERP"という用語は、単に計画についてだけでなく、むし ろそれは、企業の中核、重要なビジネスプロセスを指す。コンセプトの主な有用性にもかかわらず、ERPシ ステムの導入は、適切に管理およびコントロールされていない場合は予想される結果を提供することに失 敗する。さらに、ERPシステムの利用の拡大（例えば、Web対応の顧客インターフェース）に発展するトレン ドや変化する技術がある。それらは、ERPのセキュリティとコントロールを考慮することの重要性を増加す るであろう。 1.3.2 ERPシステムの監査は、特定のベンダー製品の導入の成功、使用およびコントロールのためにビルトイン され、要求された特定の知識や複雑な機能と統合されたプロセスの理解を持つIT監査・保証の専門家を 必要とする。 1.4 ガイドラインの適用 1.4.1 このガイドラインを適用する場合、IT監査・保証の専門家は、他のISACAの基準と関連するガイドライン との関係で、そのガイダンスを考慮するべきである。ガイドラインは、製品固有のではなく、一般的なガイダ ンスとして書かれている。IT監査・保証の専門家は、ERPシステムと使用されている他の製品/手続きに応 じてガイダンスを考慮して適応する必要がある。 1.4.2 本ガイドラインは、ERPシステムやERPシステム導入プロジェクトの監査やレビューに参加するときにどの ようにIT監査・保証の専門家がISACA基準とCOBITを遵守すべきであるかの情報を示唆し、提案する。 2 ERPシステム 2.1 定義 2.1.1 ERPは、第1に企業内のリソースの計画と管理を示すために、使用される。第二に、それは、全体のビジネ スプロセス、統合された購買、在庫、人事、顧客サービス、出荷、財務管理とビジネスの他の側面、全てを 管理するために使用できるソフトウェアシステムを示す。ERPシステムは、通常、共通データベース、様々な 統合されたビジネスプロセスアプリケーションのモジュールとビジネス分析ツールに基づいている。 121 G21 ERPシステムレビュー 2.2 ERPシステムの導入におけるリスクとコントロールの課題 2.2.1 ERPシステムは企業の業務をサポートするために導入されている。そして、成功するためには、企業が効果 的に行動できるようにする全ての重要なプロセスと手順に統合する必要がある。ERPシステムの統合され た性質を考えると、それらは、さらに関連する企業のリスクや課題に追加することができる。 • 業界とビジネス環境 • ユーザーまたは管理行動 • ビジネスプロセスと手順 • システムの機能 • アプリケーションセキュリティ • 基盤となるインフラ • データ変換と整合性 • 継続的なメンテナンス/ビジネス継続性 2.2.2 ERPシステムの導入と継続的な使用に関連付けられているリスクは、アプリケーションまたは隔離された 技術的なリスクのレビューで決定またはコントロールされることはできない。しかし、提供されている企業 のビジネスプロセスのコントロール目標と併せて考慮されなければならない。IT監査・保証の専門家への 挑戦は、事業が行われているビジネスと規制環境の理解を得ること、定量化可能なアプリケーションや技 術的なリスクと定量化されにくい手続きや行動のリスクを識別するというスキルが存在することである。 2.2.3 通常、ERPシステムによって処理されるデータの量が非常に膨大である大規模な企業で、パターンや傾向 の分析は、業務の効率と効果を確かめるに極めて有用であることが分かる。ほとんどのERPシステムは、 そのような抽出および分析のための特定のツールなどの機会を提供している。ERPシステム内のデータ分 析ツールの使用はERPシステムのライフサイクル全体を通して（すなわち、導入の前後）、IT監査・保証の 専門家を支援することができる。 2.3 BPRとERP導入 2.3.1 BPRとERP導入プロジェクトは、独立したイニシアチブであると考えることができる。理論的には、各プロ ジェクトは企業外ではなく、企業内に存在することができる。実際に、それらは企業内、プロセス内の両方 で存在する。そして、主要なビジネスプロセスのための共通のデザインを含む無数の複雑な関係において、 互いに影響し、依存している。ERPは、既存のシステムを置き換えるために選択される場合がある。そして、 BPRの実行は遅れる可能性がある。BPRが初めにあり、完了前に終了し、ERPの導入は継続してもかまわ ない。 2.3.2 BPRとERPの導入は、開発の異なるステージになる。BPRプロジェクトが始まり、ERPが新しいプロセスと 開始されたプロジェクトをサポートするためには数ヶ月が必要である。同様に、ビジネスの意思決定は、新し いITシステムを獲得するために、ERPシステムを選択することがなされる場合もある。導入プロセスの間に、 ERPは、ビジネスのリエンジニアリングとBPRのイニシアティブの開始を可能とすることが認識される。 122 G21 ERPシステムレビュー 2.3.3 IT監査・保証の専門家の主な焦点は、ERPの導入になければならない。しかし、同時に行われるBPRは、 導入プロセスへの新たなリスクを導くことがあるし、多くの場合、既存のリスクを変化させる。 すなわち、 • BPRによって引き起こされた変更が人々に異なる方法で業務遂行することを要求するかもしれない、そして、 企業内のサポート、懸念、対立を生む場合がある。これは、ERP導入プロジェクトに伝達する場合がある。 • BPRは、ERP導入から企業の資源を奪うことがある。 • 上記の2つのリスクがERP導入に影響しない場合でも、BPRによって導入された新しいプロセスへの不 慣れは、不適切なプロセスの記述とERPシステムの準最適な設定につながる可能性がある。 • BPRとERPは、次善の成果と不必要な経費を残して、うまく統合できない場合がある。 • "チェンジレバー"としてERPを使用すると、BPRから注意をそらすことができる。新しい、より強力な技 術と、それが最適なビジネスプロセスであるというよりもむしろ、新しい技術がそれを行うことができる ので、単純にプロセスを採用する誘惑がある。 2.3.4 ITは強力な効果を持つことができるステップに特別な注意を払いながら、BPRを実行する一般的な手順は 次のとおりである。 分析フェーズ―既存のプロセス、情報と使用中のITシステムが分析され、再設計する必要があるプロセス が識別される。情報とITの利用は、企業のプロセスの劇的な変化のためのレバーになることができると同 時に、IT監査・保証の専門家は、BPRプロセスの初期段階で有用な貢献を提供することができる。 再設計フェーズ―新しいプロセスが再設計され、既存の情報を使用するための新しい情報や新しい方法 が検索され、そして新たなビジネスシステムの青写真が定義される。いかに新しい情報が、ビジネスの機能 領域と新しいITシステムの仕様間で共有されるべきかにおいて、新たなワークフローのモデルは、情報シス テム監査範囲の領域になる。 移行フェーズ―移行戦略が開発され、移行アクションプランが作成され、実行される。ITシステムの移行、 新たな情報や新技術の導入、および古い情報とITシステムの廃棄は、情報システム監査・保証の範囲領域 になる。 2.4 COBITの適用と利用 2.4.1 ERPシステムをレビューすることにおいて、COBITは、様々な方法で適用することができる。様々なコン トロール目標の妥当性は、企業ごとに、また同時に企業のコントロール構造のニーズにより異なる。しか しレビュー中にCOBITを適用することへの良いスタートは、エンタープライズパッケージソリューション （ISACAの出版物の ITガバナンスの導入と継続的改善 を参照）に関するIT管理に対処することであ る。Gartner Groupは、以下を含めてERPシステムに関する管理のいくつかの懸念を特定している。 • ユーザーの要件を満たすことの失敗 • 統合の失敗 • 技術的なインフラとの非互換性 • ベンダーのサポートの問題 • 高価で複雑なインストール 2.4.2 ISACAによって識別されている関連するコントロール目標は、前述の懸念に対処するために使用すること ができる。さらに、IT監査・保証の専門家はまた統合された固有のコントロール目標と、これらの特定のコ ントロール目標のための統合された固有の監査と保証手続を策定することができる。 123 G21 ERPシステムレビュー 3 情報システム監査基準で効果的なコンプライアンスの達成 3.1 導入コメント 3.1.1 IT監査・保証の専門家の初期の導出、またはERPシステムやERPシステムの導入プロジェクト、ISACAの 情報システム監査基準およびガイドラインの役割は非常に関連し、IT監査・保証の専門家によって検討し、 適切に遵守されるべきである。IT監査・保証の専門家は、よくERPシステムおよび関連イニシアチブの計画 的な役割や仕事の内容の中でこれらの基準やガイドラインのレビューと分析を完了するために従事される。 3.1.2 このガイドラインの目的のために、唯一の、より関連性の高い特定のIT監査・保証ガイドラインが具体的 に参照される。ERPシステムは、IT監査・保証の専門家のための様々な機会を提供し、注意と計画して対 処する必要がある管理のためのリスクを提供している。ERPシステムまたは導入のレビューのための計画 段階は監査の成功に非常に重要である。 3.1.3 ERPシステムや導入の監査は、IT監査・保証の専門家による戦略的に異なるアプローチを引き起こす。 ERPシステムは、多様なビジネスプロセスを統合し、それに応じて、BPRプロジェクトの実施と併せて導入 することができる。このリエンジニアリングの一環として、一度、企業の財政および運用を保護するために 使用される重要な統制手続きは、完全に新しいコントロール構造/手続きと関連するリスクの結果、変更さ れ、または除去される場合がある。 3.1.4 ERPシステムまたは導入プロジェクトのために、IT監査・保証の専門家はまた、監査が実行される方法を 再設計しなければならない。リスクは、度合い、多様性とそれらが発生する可能性がある手段に関して変 化を遂げているだろう。これらのリスクは、ERPソフトウェア製品に固有の統合されたプログラムロジック とビジネスプロセスの機能のために、ある程度、発生する。さらに、従来のコントロールの多くは、もはや 適用できなくなる。たとえば、IT監査・保証の専門家は、新しいコントロール構造を識別する必要がある。 3.1.5 ERPシステムのIT監査の計画において、IT監査・保証の専門家は、セクション内部の監査の分割と順次に セクションの監査を行うことに重要な検討を行う必要がある。全体のERPシステムの監査は、かなりの作 業であり、ITやその他の監査のリソースに負担をかける。 3.2 監査ポリシー 3.2.1 IT監査機能の監査ポリシーは、ERPシステムを導入するために、企業の意思決定の結果として変更する必 要がある。例えば、ERPシステムの効果的な導入に関連付けられているBPRの考慮事項は、IT監査・保証 の専門家の作業範囲を拡大し、より密接に統合される（例えば、ジョイントまたは共同監査イニシアチブを 介して）他の監査機能との関係（例えば、財務、運用）を必要とすることができる。 3.2.2 IT監査・保証の専門家による監査の計画範囲は、IT監査ポリシーに従って定義する必要がある。 124 G21 ERPシステムレビュー 3.2.3 企業の上級管理者とシステム管理者が完全に理解し、ERPシステムや導入プロジェクトに関連するIT監 査・保証の専門家の役割をサポートすることが不可欠である。IT監査・保証ガイドラインG5『監査ポリ シー』は、次の図に示されるように、ERPシステムと企業の関連イニシアチブのコンテキスト内でレビューさ れ、考慮されるべきである。 IT監査・保証の専門家のERPへの関与 監査 初期導入 例：以下をカバーする ・導入前のコントロールレビュー ・データインテグリティと移行 ・プロジェクト管理 ・セキュリティ管理 ・BPR ・テスト 3.3 非監査 既存システム レビュー・テスト・評価 管理・ビジネスプロセス テストの変化 例：直接参加、導入 ・データインテグリティと移行 ・セキュリティとコントロールのコン サルティング ・BPRの役割 ・テスト 独立性 3.3.1 もし、IT監査・保証の専門家が、ERPシステムやERPシステム導入プロジェクトに関連付けられている非監 査と非保証の役割を担当する場合は、IT監査・保証ガイドラインG17『IT監査・保証の専門家の独立性に 対する非監査業務の影響』をレビューし、適切に遵守すべきである。 3.3.2 IT監査・保証の専門家は、ERPシステムや関連する取り組みの非監査と非保証な役割を持つ場合は、ISコ ントロール専門家のためのISACA基準をレビューし、適切に従うべきである。 3.4 能力 3.4.1 IT監査・保証の専門家の長期的な監査および保証の戦略とERPシステムを使用する企業の計画には、 ERPに関連するITの監査やIT監査・保証の専門家の能力の継続的な開発と保守、をサポートする側面を 含める必要がある。これは、スキルと知識と継続的専門教育（S4）のレベルの機能強化を含む。 3.4.2 IT監査・保証の専門家が、ERPシステムや導入プロジェクトのIT監査、情報システム監査を行うために必 要なスキルを持っていない場合は、IT監査・保証の専門家は、資格を持つIT監査・保証の専門家に監査を 委託することを検討すべきである。契約に知識移転のための要件を含めることが適切である。 3.4.3 ERPシステムの導入の監査のためのスキルは、ERPの監査や仕事上の製品のトレーニングやERP領域ま たは監査と保証グループへの参加を介して取得することができる。 3.4.4 特定の製品関連のトレーニングと経験（すなわち、特定のERP製品の用語が異なる場合、または別の意味 を示す場合）は、ハンズオンの使用や、照会や体験を通して取得することができる。背景のインタビューや ITマネジメントによる説明会、技術スタッフとシステムを担当するユーザーは、セキュリティ、コントロールと 処理機能や、特定のERPシステムのリスクを理解する上でIT監査・保証の専門家を支援することができる。 3.4.5 このガイドラインの付録では、能力のギャップに対処する方法に関するガイダンスを提供する。 125 G21 ERPシステムレビュー 3.5 計画 3.5.1 ERPシステムやERPシステムの導入プロジェクトのIT監査の冒頭で、IT監査・保証の専門家は企業の既存/ 計画中の展開の背景知識と理解の獲得とERPシステムと関連するリソースの取得に十分な時間と労力を投 資すべきである。IT監査・保証の専門家は、製品の研究、管理およびその他の職員の直接の問い合わせ、お よび文書の審査手続を通してこれを達成するであろう。 3.5.2 具体的には、付録ではIT監査・保証の専門家が考慮する必要があるかもしれないERPシステムの導入の 要素の一般的な概要、および基本的な質問が用意されている。 3.5.3 ERPシステムの導入は、IT監査・保証の専門家がこれまでに出会った他のビジネスシステムに比べて、より 統合され、複雑になる可能性があるが、それらはより伝統的なシステムと導入プロジェクトと同じく、多くの 組織管理、環境、アプリケーション、コントロールの考慮事項とリスクを伴う。 3.5.4 それは、企業の業務のあらゆる側面をカバーするERPプロジェクトの監査時にIT監査・保証の専門家が 関与している領域は、特に注目される。したがって、ERPシステムの完全な監査は、一人または1つの監査お よび保証の規律で満たされる可能性のない広範なスキルセットが必要になる。それは、ERPの監査または レビューに関与している監査および保証能力の正しい組み合わせは、極めて重要である。監査スキル、財 務、業務および規制領域からのリソースはIT監査・保証の専門家のスキルを補完するために必要な場合が ある。 3.5.5 計画中に、 （もしあれば）Webに拡張されているERPのプロセスを検討することは重要である。ERPシス テムが、新しいモバイルコンピューティングツールで、エンタープライズポータルとWebベースのアプリケー ションを介してWeb上でビジネスを拡張する多くの企業で、IT監査・保証の専門家は、このカテゴリ（すな わち、イントラネット、エクストラネットまたはインターネット）に適合した監査をするかどうかを、決定する 必要がある。これは、監査および保証業務の成果に影響し、ERPシステムの境界を延長するかもしれない。 3.5.6 IT監査・保証の専門家は、実行される監査と保証業務の範囲を経営者が認識して、満足していることの合 理的な保証を取得する必要がある。 3.6 作業成果 3.6.1 IT監査・保証の専門家は、全集団に対応し、潜在的なリスクに対処し、効率的にレビューを行うために ERP環境を監査するフラグための様々なツールやテクニックを使用することができる。多くの場合、ERP システムのコントロールの初期設計は、時間の経過とともに弱まる。非ERPシステムへのインタフェースだ けでなく、プロセスの境界がERPシステム自体を超えて拡張し、Web対応の環境として機能することがで きるERPシステムにおける環境変化とこれを組み合わせるだけでなく、ツールと技術を考慮する必要があ る。 • データマイニングと分析－ERP製品は、通常、堅牢な監査および保証関連のレポートが付属しており、 これらが存在しないところでは、第三者製のツールが重要なデータやサンプルを識別し、分析するため に使用されることがある • 業務分析/承認分析－情報は、異なる部門システムではなく、セキュリティやアクセス権限周りのリスク の高いレベルでのERPシステムの結果の統合された性質に限定されるものではない。ビジネスルールは、 潜在的なセキュリティ上の懸念にレビューのフラグが立っているケースを識別するために使用することが できる • ワークフロー/レポート配信－ERPシステム内のワークフローは、分析やレビューのための重要な個人に、 例外レポートを配信するために利用することができる。情報はリアルタイムで利用可能であることを考え ると、根本原因の分析はそれほど複雑でなく、是正されるビジネスメジャーが開始される 126 G21 ERPシステムレビュー • アップグレード/コントロールインテリジェンス－ERP製品の供給者は、既存の機能への継続的な修正 はもちろんのこと、新機能や拡張機能につながる研究開発への投資を継続する。それはERPシステムの 最新の機能、容量の管理およびコントロール能力を現在備えている、IT監査・保証の専門家を含め、重 要な企業である。ツールは、それが元の導入またはアップグレードの一部であるかどうか、ERPシステム 内で利用可能な技術的なコントロールの設定を常に把握するために存在する 3.6.2 ERPシステムの監査は、プロセスの整合性の領域をカバーする保証を提供することができる。 以下、考慮すべき固有の事項： • 導入されているプロセスのコントロール目標を識別する • 導入されているプロセスの潜在的なビジネスリスクや財務リスクを特定し、評価する • これらのリスクをコントロールする最も効果的かつ効率的な方法を（その導入者は、一般的に集中しな いか、または開発するための専門知識を持っていない）開発し、設計する • 先進の手法と推奨プロセスの改善への企業のプロセスを比較し、主要な事業活動の独立した分析を行う • ERPシステム内のコントロールが適切かつ効果的であるという保証を提供する • 非ERPシステム（レガシー、Webベースおよびモバイルコンピューティングのアプリケーションを含む）か らERPシステムへのインタフェースをレビューする • 業務プロセスと内部統制に焦点を当てた監査と保証のテストを実行する。ERP導入時に多くの企業は ビジネスプロセスをリエンジニアリングする • 事業継続計画をレビューし、それらがテストされていることの合理的な保証を提供する 3.6.3 ERPの監査は、アプリケーションのセキュリティの領域をカバーする保証を提供することができる。 以下、考慮すべき固有の事項： • アプリケーションコントロール、権限および標準的なセキュリティ設定を含む標準的なERPのパラメー タをレビューする • 貴重なデータを保護しながら、効率的かつコントロールされた方法で処理を可能にするアプリケーショ ンのセキュリティを評価する • ビジネスプロセスとアプリケーションのセキュリティの整合性の合理的な保証を提供するために、構成 の決定を評価する • 適切なセキュリティとコントロールのための設計のドキュメントをレビューする • 付与されるアクセス権が適切に、識別され、評価され、および承認されていることの合理的な保証を提 供するために、セキュリティ管理プロセスを評価する • 多くのビジネスプロセスは、イントラネット、エクストラネットまたはインターネットを介して拡張すること ができる。セキュリティプロセスが適切にこれらのリスクに対処することの合理的な保証を提供する 3.6.4 ERPシステムの監査は、インフラストラクチャの整合性の領域をカバーする保証を提供することができる。 以下、考慮すべき固有の事項： • アプリケーションソフトウェアパッケージをサポートするインフラストラクチャコンポーネント（すなわち、 ハードウェア、オペレーティングシステム、データベース管理ソフトウェア、ネットワークハードウェア、イン ターネット、イントラネット）のための潜在的な構成とセキュリティリスクを識別する • その実践と今後の運用目標をサポートするために、企業のITインフラストラクチャの能力をレビューする • 成果、可用性やデータ整合性の問題を引き起こす可能性のある内部システムのアーキテクチャの問題を 特定する • ビジネスの復旧計画をレビューし、それらがテストされていることの合理的な保証を提供する 127 G21 ERPシステムレビュー 3.6.5 ERPシステムの監査は、導入の整合性の領域をカバーする保証を提供することができる。 以下、考慮すべき固有の事項： • 従業員に対する影響を最小限に抑えながら、データの整合性、セキュリティと正確性の信頼の損なうこ となく、新たなERPの環境へのスムーズな移行の合理的な保証を提供する • 新しい本番環境と他のシステムとのインタフェースにレガシーシステムからのデータの転送で接続されて いる潜在的なリスクを識別する • 本稼動前に、機能性、コントロールと準備状態をテストし、評価する • データの品質を評価する • データの変換と整合性の戦略と管理手順を評価する • 完全を期すため、適切なセキュリティと整合性のための試験計画を評価する • そのテストが目的のユーザーコミュニティに関与しており、新たなERPの所有者がユーザーの受け入れが 完了したことを満たしていることを確認する • ビジネスプロセスおよびセキュリティに関する考慮事項の完全性のためのトレーニングの独立したレ ビューを提供している • 導入後のコントロールとセキュリティ環境の有効性のレビューと実施プロセスの全体的な管理を提供する 例外レポートを評価する 3.6.6 ERP導入の監査は、その時まで何が起こっているのかと将来のために計画されているかを監査することに より、プロジェクトのライフサイクルでいつでも行うことができる。理想的には監査は、継続的にまたはプ ロジェクトのライフサイクル中のいくつかのポイントのいずれかでレビューを伴うだろう。この目的のため に、IT監査・保証の専門家はしばしば主要なリスクが隠れている最も重要な導入領域に対応する監査と保 証フレームワークを必要とする。たとえば、 • プロジェクト管理 • 品質管理 • 利害管理 • リスク管理 • 変更管理 3.6.7 プロジェクトマネジメントは、次の4つのフェーズで構成されている。 管理計画－プロジェクトが開始されるとき、管理計画を開発し、提案され、利益が合意される、そして、プロ ジェクトの範囲と構造が再定義される。 プロジェクトの実施―プロジェクトの過程を通じて、重要なプロジェクト管理活動－ワークプランニング、 リソース管理、プロジェクト管理、プロジェクトのレポートと伝達－は、実行される プロジェクトの完了―プロジェクトは、導入段階に続く本番運用のためにERPシステムを稼動するための あらかじめ定義された識別エンドポイントが必要である 成果の導出―導入後、性格の変化し、ユーザーの動作に必要な変更を確保する責任があるビジネス所有 者への転送されるプロジェクト管理が導入され、利益が得られる 3.6.8 ERPシステムのプロジェクト管理は、他の大規模なソフトウェアプロジェクトの管理とは大きくか根本的に 異なることはない。同じ概念は、ERPシステムの導入の管理の監査に適用される。 • エグゼクティブスポンサーシップと経営トップのサポートの評価を行いる • プロジェクト管理の活動の独立したレビューと分析を行いる • 独立してプロジェクトの計画とコントロールだけでなく、品質保証を評価する • 管理の時間や予算超過など、プロジェクトの問題、機能性のギャップ、およびスタッフィングとスキル要 件の不一致だけでなく、プロジェクトの管理に関連するその他の問題の解決に関する調査結果を提供 する 128 G21 ERPシステムレビュー 3.6.9 全てのソフトウェアプロジェクトの不可欠な部分でなければならない品質管理は、単にプロジェクトの成果 物の品質にだけ留意するべきではなく、たとえばプロジェクトの計画、設計文書、仕様、手順、トレーニン グ教材や実施計画などのERPプロジェクトの全てのアクティビティと成果物をカバーする必要がある。プ ロジェクトの組織内の独立した機能として実施する必要がある品質保証は、監査および保証活動を考慮 すべきではない。一方、ERPシステムの導入時に、品質管理と品質保証の有効性を監査することが不可欠 である。 3.6.10 ビジネスケースと関連する利益の実現計画は、利益管理の監査のための重要な焦点である。それらは特定 する必要がある。 • プロジェクトのビジネス目標と達成することが期待される利益。その利益は、 （定量的および非定量的 両方）の利益レジスタで明確に指定する必要がある。定量化の利点は、識別可能かつ測定可能な要素 に分解する必要がある • ビジネスプロセスの変更管理と利益との相関関係を実現するための計画 • 利益の成就の道理的保証を供給するコントロール手順 3.6.11 ERPシステム導入の開始前になされる利益管理は、成功するERPプロジェクトの重要な利点を実現するため に有力である。利益実現のレビューは、プロジェクトの完成後〔一般には18ヶ月〕に実行されるべきである。 3.6.12 リスク管理は、ただのプロジェクトリスクの管理以上のものである。それは、ERPプロジェクトがビジネス 上に位置づけられるリスク管理でもある。IT監査・保証の専門家は、リスク管理の様々なタイプを考慮すべ きである。 • リエンジニアされるビジネスプロセスに関連するリスク管理 • プロジェクト管理に関連するリスク管理：プロジェクトリスクとは以下にあげられる –– プロジェクト目標と範囲から出される固有のもの –– プロジェクトとリスク管理に適用される選択された方法論、ツール、テクニック、スキル、経験からなさ れて要求されるもの –– システム導入中の情報セキュリティ管理 –– 導入後、すなわちシステム運用中に計画された情報セキュリティ管理 • ERPプロジェクトの範囲外システムにより導き出されたリスクと第三者により実行されたERPプロジェク トのリスクの管理。IT監査・保証の専門家は、特別なERPプロジェクトへ狭くフォーカスした統合アプ ローチを持つべきである 3.6.13 組織の再編、伝達、プロジェクトマーケティングとパーソナルトレーニングは、成功するプロジェクト管理 のキーアクティビティである。IT監査・保証の専門家は、以前触れられたアクティビティに加えて、特に利 益管理（成し遂げるべき利益に関する）とリスク管理（変化への抵抗と新しく定義された役割によるスタッ フの権利に関する情報セキュリティに関する）などの他の重要な導入範囲への変更管理を評価すべきであ る。ERP導入から導出される利点は、通常、導入前には、アプリケーションによって供給される機能におい て設計された新しいプロセスを、導入後は、新しくデザインされたプロセスにあったユーザーの行動の変化 を要求する。ビジネス上の利点の導出の監査は、典型的なERPプロジェクトがクローズされた後も継続さ れるであろう。 129 G21 ERPシステムレビュー 3.7 報告 3.7.1 ERPプロジェクト上に置かれた監査意見と監査コメントを供給する報告プロセスは、いくつかの監査と保 証の報告プロセスとは異ならない。いくつか、または全ての次のレポートメカニズムが該当するかもしれな い。 • ERPプロジェクト管理ミーティングとステアリングコミッティへの規則的なサマリー報告 • プロジェクトログ、明確化のためにトラックしている監査と保証の論点、またはコントロールポイントのメ ンテナンス • プロジェクトのライフサイクルにおいて定義されたステージで監査と保障の意見に関する正式な報告書 4 有効日 4.1 このガイドラインは、2010年9月16日から全てのIT監査に適用される。 別表 ERPの知識とスキル要件 ERPシステム 会計と経営管理とリスク管理の理解 専門的なIT監査・保証の基準適用の完全な理解 ITに関連したコントロールと次の領域のリスク管理への 完全な理解 IT環境、アプリケーションプロセス、クライアント／サー IT監査・保証の バーアーキテクチャの理解 専門家の背景知識 オペレーティングシステムとデータベース管理システムの 理解 監査証跡への影響を含むERPシステムとそれらの設計、 開発思想の一般的な理解 ERPモジュールとそれらの構成、統合、分散方法への理解 ERPのセットにおけるセキュリティ、権限概念の理解 導入プロジェクト プロジェクト管理の実行とコント ロールの理解 IT領域におけるプロジェクト管理の 実行とコントロールの理解 変更管理を含むITに関連したシステ ムの開発方法論と基準の理解 ビジネスプロセスリエンジニアリン グの原理と適用の理解 ERPのセットにおけるリスク管理上の主要領域に集中で きるIT監査・保証の専門家 I T監 査・保証の コンピュータ関連の監査技術（CAAT）とERPセットにお 導 入プ ロジェクト のレ ビューと 専門家のスキル けるそれらの適用の理解 評価の経験 追加的なスキルや経験（たとえば、会計や法令）が要求 さているかを認識する能力 スキル獲得方法 監査専門家の資格 IT監査・保証の専門家の資格（例：CISA） ERPシステムの監査・保証と同じようにERPシステムの 管理と使用に集中した特別なトレーニング 実践的なオンザジョブの経験 自身の勉強、研究、インターネットなど 同様のプロジェクトにおけるIT監 査・保証の役割に集中した特別な トレーニング 実践的なオンザジョブの経験 自身の勉強、研究、インターネット など 130 G21 ERPシステムレビュー ERPシステム導入上の一般的な要素と質問 次の図は、ERPシステム導入の一般的な要素を図示している。 ERPアプリケーションモジュール ERPシステムと構造 DBMシステム オペレーティングシステム 外部関連システム 他の内部関連システム • どのERP製品とモジュールが使われているか？ • どのようにモジュールは関連付けられているか（たとえば、モジュール間のデータフロー）？ • どのデータベース管理製品が使われているか？ • どのようにERPシステムはデータベース管理システム（DBMS）と構成されているか？ • どのオペレーティングシステム製品が使われているか？ • どのようにそれぞれは構成され、導入され、コントロールされているか？ • ERPシステムのwebはどのレベルに強化されているか？ • どのプロセスがwebに拡張されているか？ • どのインターフェースやリンクがERP以外の企業の内部システムや外部システムに存在しているか？ • どのようにそれぞれの機能はコントロールされているか？ • どの範囲で、ERPの機能、コントロール、権限が集中されているか、あるいは、非集中化されているか？ • どのようにデータインテグリティが、ERP導入の間に古いまたはERP以外のシステムからのデータ移行 中に管理者によりコントロールされ、テストされているか？ • どの範囲で、ビジネスプロセスリエンジニアリングがERP導入プロジェクト中に実行されているか？ • もし、実行されていないのなら、なぜ実行されていないのか？そしていつ実行されるのか？ • もし、実行されているのなら、どんな改革が実行されるのか、なぜ？ • どのように、ERPとBPRプロジェクトは同意され、通常のプロセスはデザインされているのか？ • どのITハードウェアとネットワーク資源が使われ、どのようにそれらは構成され、管理されているのか？ • どの範囲で、ERP管理と技術サポートの役割と責任が統合され、あるいはほかの関連したITサポート （たとえば、データベース管理、運用など）から分離さているのか？ • 変更管理プロセス上、コントロールは何のためになされているのか？ • ERPアプリケーションモジュール、ERPコアシステム、DBMS、オペレーティングシステムは何か？ • どんな変更がBPRに対処するためになされるのか？ • 他のERP以外のシステムへのリンクとインターフェース • アクセスセキュリティポリシーと基準は何か？、誰が経営コントロールとサポートに責任があるのか？ • ERPシステムの許可とユーザ管理への責任の移行が完成される論理的な保障を供給することに、どの プロセスが関与しているか？ 131 G22 B2C イーコマースレビュー 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 133 2 B2C イーコマース‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 134 3 ポリシー‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 136 4 独立性‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 136 5 能力‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 136 6 計画策定‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 137 7 B2C イーコマースレビューのパフォーマンス‥‥‥‥‥‥‥‥‥‥ 137 8 報告‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 142 9 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 142 G22 B2C イーコマースレビュー 1 背景 1.1 基準との関連 1.1.1 基準S6『監査業務のパフォーマンス』は、 「監査の過程において、情報システム監査人は監査の目的を達 成するために、充分であり、信頼できる、関連する証拠を得るべきである。」と述べている。監査の発見事 項と監査の結論は、この証拠を適切に分析し、解釈することにより裏付けられるものである。 1.2 ガイドラインとの関連 1.2.1 ガイドラインG14『アプリケーションシステムレビュー』が、指針を提供している。 1.2.2 ガイドラインG16『企業のITコントロールに関わるサードパーティの影響』が、指針を提供している。 1.2.3 ガイドラインG17『IT監査・保証の専門家の独立性に対する非監査業務の影響』が、指針を提供している。 1.3 COBITとの関連 1.3.1 個々の監査範囲に適用可能であるCOBITの中から最も関連する材料の選定は、特定のCOBIT ITプロセ スおよびCOBITのコントロール目的と関連するマネジメントの実行の勘案の選択に基づいている。B2C イーコマースレビューをIT監査人が必要とする要件に合わせるべく、最も関連し、選定され、採用されるべ きCOBITのプロセスが、ここで主要なものとして分類される。選択と適応させるプロセスとコントロール目 標は、特定のスコープおよび割り当ての基準の条件によって異なる。 1.3.2 B2CイーコマースとITをベースとしたビジネスにとって、COBITドメイン～計画と企業（PO）、調達と導入 （AI）、サービス提供とサポート（DS）、モニタリングと評価（ME）～に関連した全てのITプロセスが関連 している。 主要な参照項目： • P01 IT戦略計画の策定 • P02 情報アーキテクチャの定義 • P03 技術指針の決定 • P09 ITリスクの評価と管理 • AI2 アプリケーションソフトウェアの調達と保守 • AI3 技術インフラストラクチャの調達と保守 • AI4 運用と利用の促進 • AI6 変更管理 • AI7 ソリューションおよびその変更の導入と決定 • DS1 サービスレベルの定義と管理 • DS2 第三者のサービスの管理 • DS3 性能とキャパシティの管理 • DS4 継続的なサービスの保証 • DS5 システムセキュリティの確保 • ME2 内部統制のモニタリングと評価 • ME3 外部要件に対するコンプライアンスの保証 1.3.3 最も関連する情報要請規準： • 主：可用性、コンプライアンス、機密性、有効性、インテグリティ • 副：効率性、信頼性 133 G22 B2C イーコマースレビュー 1.4 ガイドラインの目的 1.4.1 このガイドラインは、B2Cイーコマースのイニシアチブとアプリケーションのレビューにおける推薦された 実施を記述している。 2 B2Cイーコマース 2.1 定義 2.1.1 イーコマースという用語は、異なる団体では異なる意味で使われている。ISACAは、イーコマースを有効な 技術としてのインターネットを使い、ある企業が彼らの顧客、仕入先、他の外部のビジネスパートナーと電 子的にビジネスを推進するプロセスとして定義している。それゆえ、ビジネスTOビジネス（B2B）とビジネ スTO消費者（B2C）イーコマースモデルの両方を包含しているが、たとえば、EDIやSWIFTnetなどプライ ベートネットワークに基づいたノンインターネットイーコマース手段は含まれていない。 2.1.2 このガイドラインの目的のために、イーコマースのISACAの定義は、次のB2Cイーコマースの定義に合う基 礎として使われている。B2Cイーコマースは、有効な技術としてのインターネットを使い、顧客、および一般 大衆と企業が電子的にビジネスを推進する上のプロセスを言及している。 2.2 B2Cイーコマースモデル 2.2.1 多くの企業が、B2Cの関係においてはインターネット技術を使用するビジネスへと移行させている。B2C の関係において企業の中でインターネット技術が使用される範囲は、その企業のインターネットに対する 成熟度、顧客、その地理的市場におけるインターネットの使用状況、その企業の製品･サービスの性質、そ して競争優位性を構築するか、競争に追いつくためにインターネットを使うことの緊急性との関連しだいで ある。それに応じて、企業は次のイーコマースの活動のひとつ以上をカバーするB2Cイーコマースモデルを 用いるかもしれない。 • 情報（公開）―企業や製品情報にアクセスしたい人達のためにインターネット上に有効な情報を掲載す ること • 顧客サービス（情報の）―企業の顧客のためにインターネット上にたとえば、製品･サービスと価格情報 を掲載すること • 顧客サービス（支払い以外の取引）－インターネット上に有効な情報を掲載することに加えて、たとえば、 注文、キャンセル、などの取引を可能にすること、ただし、支払いは便利な手段を通して行われる • 顧客サービス（支払い）－インターネットを通して支払いや（銀行の場合には）ファンドの移行などの取 引を顧客に許可すること • 顧客報告口座情報や顧客の注文状況をオンラインで報告を供給すること • 相互のサービスーウェブサイトを通じてリクエストや質問に対する返答をイーメールを通じて行うこと • ダイレクト販売－インターネットを通じて買い手に直接製品やサービスを販売すること • オークション－オンラインで製品をオークションすること 2.3 B2Cイーコマースレビューにおいて特に要求される注力点 2.3.1 B2Cイーコマースの初動の場合において、ビジネスと情報システムは密接に連結されている。それゆえ、一 般的にB2Cイーコマースのレビューは、ISリスクと同じようにビジネスリスクも扱うべきである。 134 G22 B2C イーコマースレビュー 2.3.2 COBITは情報システムによって保有されるべき7つの情報要請規準を決めている。これらの要請規準と共 により良いコンプライアンスも情報システムリスクを軽減することに役立ち、又、ビジネスリスクを最小化す ることにも寄与する。これらの情報要請規準は、 • 有効性 • 効率性 • 機密性 • インテグリティ • 有効性 • コンプライアンス • 信頼性 である。 これらの関連は、企業によって実行されたイーコマース活動（2.2.1セクションで記述）の範囲によって、 B2Cイーコマースの場合にはより強くなるかもしれない。それ故に、B2Cイーコマースのレビューは、いかに COBITの情報要請規準がB2Cイーコマースのアプリケーションで実現されているか、いかに関連するリス クが軽減されているかを取扱うべきである。 2.3.3 インターネットに接続されるとき、B2Cイーコマースアプリケーションは固有の外部、たとえば、ハッカー、 ビールス、あるいは成りすましなどのB2Cイーコマースアプリケーションの信頼性、インテグリティ、有効性 に影響する恐怖にさらされている。もし、B2Cイーコマースアプリケーションがバックエンドのシステムと結 合されているならば、これらのバックエンドシステムにも影響するリスクが存在する。このような攻撃により 企業のB2Cイーコマースアプリケーションが被害をこうむった場合には、企業の名声とイメージが著しく損 傷される。このことにより、B2Cイーコマースレビューは、このような恐怖に対する防御の適切さに大きな 注意を払うべきである。 2.3.4 取引の否認防止は、B2Cイーコマースの本質的な要件である。COBITの7つの情報要請規準を参照すると、 要請基準のひとつにインテグリティがある。B2Cイーコマースが取引と支払いを引き起こす場合には、ソー スの信憑性と通信のインテグリティが確立されることが必要である。ゆえに、その結果生じる取引の否認 もありえない。このようなケースにおけるB2Cイーコマースのレビューは、否認防止を確立するB2Cイーコ マースアプリケーションの有効性を扱うべきである。 2.3.5 一般的にB2Cイーコマースは、B2Cイーコマースアプリケーションを通じて使用された、または取引された 顧客と見込み客についての詳細な情報を得ることが可能である。このような詳細データの防御が確立され るべきである。言い換えれば、集められた詳細情報は情報を供給する個人との同意内容においての目的に だけ使われるべきである。この内容において、B2Cイーコマースのレビューは、プライバシーとデータ防御 に関するベストプラクティスと同じく、関連した国の法的手順に沿ったコンプライアンスも取り扱うべきで ある。 2.3.6 アプリケーションの監査証跡は、B2Cイーコマース環境では、取引と支払いのための紙の証跡がないこと により、より重要である。この内容により、B2Cイーコマースのレビューは、監査証跡をレビューするプロセ スと同じように監査証跡の適切さを取り扱うべきである。このことは、取引の信憑性とインテグリティ（否 認防止を含む）を確認するポイントからも重要である。 2.3.7 ビジネスのほかのチャネルに対して、B2Cイーコマースはアプリケーションとインターネットへのアクセスの 有効性に大きく依存している。この内容により、システムと通信リンクにおける災害回復手順と同じく、適 切な容量計画プロセス、冗長度、フォールバックオプションが存在すべきである。これらは、B2Cイーコ マースアプリケーションの有効性の観点を評価する間に注意を付与されるべきである。 2.3.8 B2Cイーコマースアプリケーションと関係するバックエンドアプリケーション間のデータのインテグリティと、 プロセス（配送･発送、非電子支払いのレシートなどのマニュアルプロセスを含む）は、重要な視点である。こ のようなインテグリティを確立するために自動化されたアプリケーションとマニュアル間の適合性は、B2C イーコマースレビューの本質的なパートになるべきである。 135 G22 B2C イーコマースレビュー 2.3.9 B2Cイーコマースにおいてオンライン支払いの受け取りが引き起こされるときには、支払いの信憑性を得 るプロセスとその根拠が十分に受け取れることを確立するプロセスが適切であるべきである。このような ケースでは、コントロールの妥当性と適切性がB2Cイーコマースレビューの一部として評価されることが 必要である。 2.3.10 しばしば、B2Cイーコマースは、アプリケーション開発と保守、ウェブサイトと関連するデータベースの管理 などのいろいろな観点から第三者サービスプロバイダーの使用を引き起こす。このようなケースでは、サー ビスの業と適切なレベルと企業とその顧客に関する情報の防御を確立するコントロールと契約上の防御 の適切性と妥当性が、B2Cイーコマースレビューの一部として評価される必要がある。 2.3.11 B2Cイーコマース活動により引き起こされたデータの取り扱い、格納、保有、消去は、全てではないが、電 子的にデータを創生し、終了させることとほとんど同じがそれ以上に重要な注意点になる。 2.3.12 いくつかのB2Cイーコマースは、クレジットカードか他の支払い形態を使用し、これらの供給者とプロセサ による基準セットに関係するかもしれない。これらの基準の認識と遵守は、B2Cイーコマースが有効にな るときには重要である。 3 ポリシー 3.1 権限 3.1.1 B2Cイーコマースのレビューを始める前に、情報システム監査人は予見されたレビューを実行するために、 情報システム監査人の位置づけや組織によって供給された文書の指図書により、必要な指示の理屈に 添った保障をすべきである。 4 独立性 4.1 プロフェッショナルとしての客観性 4.1.1 任命を受ける前に、情報システム監査人は、レビューされるB2Cイーコマースのアプリケーションシステムに おいて、情報システム監査人の利害がレビューの客観性を弱めないような理屈に添った保障をすべきである。 衝突する利害が存在する場合には、このことを会社に対して明白に伝達すべきであり、また、利害の衝突に 対する会社が考慮した文書を、任命を受ける前に得ておくべきである。 4.1.2 情報システム監査人が、レビューされるB2Cイーコマースのアプリケーションシステムにおいて監査以外の 役割がある場合には、情報システム監査人は、ガイドラインG17『IT監査・保証の専門家の独立性に対す る非監査業務の影響』を熟慮すべきである。 5 能力 5.1 スキルと知識 5.1.1 情報システム監査人は、B2Cイーコマースアプリケーションをレビューするための必要なビジネス知識の保 持を合理的に保障すべきである。B2Cイーコマースのアプリケーションを構築するためにビジネスを理解す ることは、B2Cイーコマースアプリケーション、または、B2Cイーコマース構想を評価するために重要である。 136 G22 B2C イーコマースレビュー 5.1.2 情報システム監査人は、また、B2Cイーコマースのアプリケーションをレビューを実行するために関連した 技術的スキルと知識にアクセスできる合理的な保障をすべきである。このようなレビューは、暗号化技術、 ファイアーウォールのようなネットワークセキュリティアーキテクチャとセキュリティ技術、不法侵入の検出 とビールスの防御などを含む特徴を評価するための技術的スキルを要求する。情報システム監査人は、こ れらの特徴を評価するための適切な知識を持つべきである。専門家のインプットが必要な場合には、適切 なインプットが外部の専門家のリソースから得られるべきである。外部の専門家のリソースが使われたとい う事実は、会社に文書により伝達されるべきである。 6 計画策定 6.1 ハイレベルリスクアセスメント 6.1.1 情報システム監査人は、一般的な産業（B2Cイーコマースのリスクが、産業により異なるため）、会社の B2Cイーコマースの目的とポリシー、目的を達成するための戦略、B2Cイーコマースシステムの範囲、システ ムを使用する範囲、B2Cイーコマースソリューションを構築するために使われた開発プロセスに関する情報 を収集すべきである。収集された情報はCOBITの情報要請規準に関するリスクと2.3章に定義された視点 と同じようにビジネスリスクのハイレベルアセスメントを実行することの手助けにすべきである。このハイ レベルリスクアセスメントは、レビュー範囲とカバー度を決定することに役立つであろう。 6.2 レビューの範囲と目的 6.2.1 会社のコンサルテーションにおいて、情報システム監査人は、B2Cイーコマースのレビュー範囲と目的を明 確に定義すべきである。レビューによりカバーされる視点は、レビュー範囲の一部として明確に位置づけら れるべきである。6.1.1に参照されるハイレベルリスクアセスメントは、レビューされることの必要な視点と レビューの範囲と深さに影響する。 6.2.2 レビューの目的のために、B2Cイーコマースソリューションにおける利害関係者もまた、会社によって認知 され、承認されるべきである。 6.3 アプローチ 6.3.1 情報システム監査人は、アプローチを公式化すべきである。これにより、レビューの範囲と目的が客観的、 かつプロフェッショナルなやり方において実行されることができる。フォローされるアプローチは、レビュー が導入前か、導入後のレビューかにより決められるべきである。このアプローチは、適切に文書化されるべ きである。外部の専門化のインプットが使われた時間と場所はアプローチの一部として特定されるべきで ある。 6.4 計画に対する非公式な承認 6.4.1 組織の慣習により、情報システム監査人は計画とアプローチのための組織の同意を得ても良い。 7 B2Cイーコマースレビューのパフォーマンス 7.1 総論 7.1.1 このセクションは、B2Cイーコマースレビューの実行の間に位置づけられる広い範囲の視点を定義してい る。特別なB2Cイーコマースレビューのために、レビューに関連した視点は、レビューの予見された範囲と 目的により広い範囲の視点から認知されるべきである。 7.1.2 B2Cイーコマースレビューは、 （適切に改良された）定義されたアプローチにより実行されるべきである。そ のことにより、レビューの予見された目的が実行される。 137 G22 B2C イーコマースレビュー 7.1.3 一般的に、有効な文書の研究（たとえば、ビジネスケース、システム文書、契約書、サービスレベルアグリー メント、ログなど）、利害者との討議、B2Cイーコマースアプリケーションと記録の使用は、データを収集し、 解析し、解釈するために、適切に使用されるべきである。必要に応じて、情報システム監査人は、そのプロ セスが要求されたとおりに機能しているか（たとえば、購買のテスト、イーコマースシステムを使った発注テ スト、伝達テストを使ったセキュリティのテストなど）を検証するためにテスト、および開発環境における重 要なプロセスをテストすべきである。 7.1.4 会社により必要とされ、又同意された場合には、データの収集、解析、解釈において、外部の専門家のイ ンプットを適切に使用するべきである。 7.1.5 推測と勧告は、データの客観的な解析と解釈に基づいて行われるべきである。 7.1.6 適切な監査証跡は、収集されたデータ、なされた解析、解釈、勧告された強制的なアクションのために保 持されるべきである。 7.2 ビジネス的な観点の評価 7.2.1 情報システム監査人は、イーコマースの目的、戦略、ビジネスモデルを注意深く評価すべきである。すでに 存在し、拡大している競争環境は、会社のビジネスの関連する位置づけの評価において考慮されるべき である。このことは、B2Cイーコマースの目的と戦略の実行において、これらの目的、戦略の適切さ、B2C イーコマースアプリケーションの有効性、効率性を評価するうえで、本質的なことである。 7.2.2 情報システム監査人は、B2Cイーコマースが新しいビジネスか、既存のビジネスラインへの追加チャネルか、 そして、レビューされるB2Cイーコマースの組織が成功の可能性と財務的な実現性に余裕があるかどうか を評価すべきである。 7.2.3 情報システム監査人は、B2Cイーコマースのコストと利益が客観的なやり方で反映されているかどうかを 評価するためにビジネスケースをレビューすべきである。巨大で、常に拡大しているインタネットユーザを考 慮すると、同時にビジネスの潜在力と大きさが実践的になされるレベルを超えて計画されている。もし、情 報システム監査人が潜在的な前提条件に関心があるならば、適切な経営を明らかにすべきである。 7.3 詳細なリスクアセスメント 7.3.1 情報システム監査人は、容易に有効ではない場合に、 マニュアルプロセスと同じく、自動化されたB2Cイー コマースアプリケーションに関するキープロセスを調査すべきである。 7.3.2 情報システム監査人は、上記のプロセスに付随する起こりそうなリスク（ビジネスとITリスク）と、起こりそ うな影響を評価すべきである。そしてリスクを和らげる視点に沿ってこれらの評価を文書化すべきである。 残ったリスクの重要な部分もまた、評価されるべきである。 7.3.3 リスクの重要性によって、情報システム監査人は、よりレビューされるべき視点とレビューの深さを決定す べきである。 7.3.4 情報システム監査人は、認識されたリスクを和らげるために効力のあるコントロールを認識すべきである。 もし、複数のコントロールがリスクを和らげるために認識できるならば、これらのコンロトールは、有効性の 順にランク付けされることができる。主要な、またはキーとなるコントロールは、2番目のコントロールより も前にテストされるべきである。 7.4 開発プロセス 7.4.1 情報システム監査人は、B2Cイーコマースアプリケーションの中に適切なコントロールが構築されているか どうか決定するために開発プロセスの適切性をレビューしなければならない。 7.4.2 B2Cイーコマースアプリケーションと使用されるツールを開発し、保持するチームの有効性は、それらの適 切性を評価するためとB2Cイーコマースアプリケーションにおける適切なコントロールを確かめるためにレ ビューされるべきである。 138 G22 B2C イーコマースレビュー 7.4.3 この項では、情報システム監査人は、ガイドラインのG23『システム開発ライフサイクル』を実行されるレ ビューの適切な範囲として考慮すべきである。 7.5 変更管理プロセス 7.5.1 B2Cイーコマースアプリケーションの管理されていない変更は計画されていないサービスの停止を引き起こ し、また、データとプロセスのインテグリティに影響する。この項では、情報システム監査人は、B2Cイーコ マースアプリケーション環境にコントロールされた変更の保障においてその適切さを評価するために変更 管理プロセスの適切性をレビューすべきである。変更管理プロセスのテストの一部として、情報システム監 査人は、プロセスが要求されているように機能しているかを確かめるために適当な数の変更をレビューすべ きである。適切さは、期間内に作られた変化の数と変化の複雑さに基づいている。 7.5.2 情報システム監査人は、開発、テスト、計画、製造環境が、変更から引き起こされるリスクを最小化するた めに適切に分離されているかどうかを確かめるべきである。 7.6 コンテンツ管理プロセス 7.6.1 B2Cイーコマースウェブサイトに現れるコンテンツ－取引に関連したコンテンツと同じく、まれに情報を 供給するコンテンツ－は、言語、表現、情報の正確さ、公表データの適切な承認、特に提供される製品や サービス、価格、契約上の制約、法的事項などの適切さを保証するために管理されたコンテンツ管理プロ セスを通して公表されるべきである。情報システム監査人は、このプロセスとレビューの適切性を理解すべ きである。 7.6.2 情報システム監査人は、キーコンテンツ（たとえば、条項や価格）に関する監査証跡がデータのインテグリ ティと正確性を確認するために保持され、レビューされているかどうか、確認すべきである。 7.6.3 情報システム監査人は、B2Cイーコマースアプリケーションで使用される条項が、会社の個人情報保護ポ リシーと同じく、サイトに公表されるものとして、法的コントロールと契約上の保護に入っている適切な考慮 を確認するために法律家に綿密に調査してもらったかを確かめるべきである。 7.7 認識と確認 7.7.1 B2Cイーコマースアプリケーション－特に、取引と支払いプロセスがなされている－によって許可された イーコマース活動に応じて、ユーザは、否認防止の保証と機密性の確保を独自に認識され、確認されるべ きである。情報システム監査人は、認識と確認に関して展開されたコントロール/メカニズム/技術（たとえ ば、ID、パスワード、応答手順、トークン、デジタル認証、デジタルサインなど）が、B2Cイーコマースアプリ ケーションの意図された使用にふさわしいものかどうかを評価すべきである。 7.8 データの有効性と権限 7.8.1 もし、B2Cイーコマースアプリケーションが、取引か情報の形においてユーザからのデータを許諾するな らば、情報システム監査人は、適切な有効性の確認が、入力されたデータの妥当性を確かめるアプリケー ションの中に構築されているか、また、そのような有効性の確認がなされているかどうかを確認するべきで ある。 7.8.2 もし、B2Cイーコマースアプリケーションが電子支払い（たとえば、クレジットカードなど）を許諾している ならば、情報システム監査人は、支払いの実際のレシートと同じように妥当性を確かめるための適切な有 効性の確認と支払いの権限プロセスが存在するかどうかを確認すべきである。 139 G22 B2C イーコマースレビュー 7.9 通信のコントロール 7.9.1 もともと機密的な（たとえば、口座明細など）個人情報を許諾し、かつ表示するような取引と支払いのプロ セスを行うB2Cイーコマースアプリケーションの場合には、情報システム監査人は、適当な暗号化技術/メ カニズム（たとえば、Secure Socket LayerやIPsec）がユーザとアプリケーションの間の伝達を暗号化す るために使われているかどうかを確認すべきである。 7.9.2 適切な、必要な場合にはいつでも、情報システム監査人はネットワークを通じた通信がVPNや関連した暗 号化を使って安全になされているかどうかを確認すべきである。 7.10 プロセス管理 7.10.1 取引と支払いをプロセスするB2Cイーコマースアプリケーションの場合には、情報システム監査人は、プロ セスのインテグリティと正確性を保証するために適切なアプリケーション管理が存在するかどうかを確認 すべきである。 7.11 バックエンドプロセスとアプリケーションの統合 7.11.1 B2Cイーコマースアプリケーションのいくつかは、受注処理の実行、金銭の授受、取引のための口座のた めのバックエンドプロセスを備えている。これらのいくつかはアプリケーションかマニュアルプロセスを通 して扱われている間に、B2Cイーコマースアプリケーションと他のアプリケーションとの統合が要求されて いるかもしれない。このような場合には、情報システム監査人は、関連したアプリケーションとプロセス（マ ニュアルプロセスを含む）を通る元データのインテグリティを保証する調和したプロセスを含む十分な管 理が存在していることを確認すべきである。 7.12 データ記憶に関するインテグリティ 7.12.1 いくつかのB2Cイーコマースアプリケーションの後ろには、データベースが存在しているゆえに、インテグ リティと機密性は、きわめて重要である。情報システム監査人は、意図的か不注意によるデータのダメージ、 破壊、変更を防ぐための適切なチェック・バランスが存在していることを確認するためにデータベース上の コントロールを評価すべきである。 7.12.2 情報システム監査人は、また、機密性とインテグリティが適切に守られていることの合理的な保証を供給 するために構築されたデータ上のコントロールをレビューすべきである。 7.13 監査証跡とそのレビュー 7.13.1 前項で指摘したように、紙の証跡の欠如において、B2Cイーコマースアプリケーションにおける自動化され た監査証跡の役割は重要である。情報システム監査人は、支払いを含む取引、重要なマスターデータ（た とえば、レート、価格、アクションなど）の変更、システムアドミニストレーションスタッフが持つ特権を使い なされた変更に関する監査証跡の適切性をレビューすべきである。 7.13.2 監査証跡の有効性だけでは、十分ではない。監査証跡に反映されるアクションが有効で、適切に承認され ていることの合理的な保証を供給するために監査証跡をレビューするプロセスが存在するべきである。 7.14 外部のIS脅威（恐怖）に対する防御 7.14.1 情報システム監査人は、会社のビジネスの性質を考慮して、B2Cイーコマース環境への外部のIS脅威を評 価すべきである。認識されるべき外部の脅威は、サービスの拒絶、データへの承認されていないアクセス、 コンピュータ機器の承認されていない使用を含めるべきである。これらは、様々なソース（たとえば、カジュ アルなハッカー、競争相手、海外の政府、テロリストなど）から引き起こされる。会社のビジネスの性質（た とえば、競争の激しさ、 マーケットシェア、自然、技術の使用タイミングを範囲、革新的/戦略的製品、サー ビスなど）は、このような脅威の可能性のあるソースを決定するために使用されるべきである。これらの脅 威に関連して起こるであろうダメージはビジネスのイーコマースプロセスへの依存状態に関連づけられる。 140 G22 B2C イーコマースレビュー 7.14.2 情報システム監査人は、外部の脅威に出会う場所において防御手段が評価されたリスクと同等のレベル にあるかどうかを評価すべきである。このプロセスにおいて、情報システム監査人は、以下をレビューすべ きである。 • プロトコルの選択を含む、アプリケーションの技術的アーキテクチャ • アプリケーションのセキュリティアーキテクチャ • ビールス防御のメカニズム • ファイアーウォールの導入、ファイアーウォールソリューションの適切性、ファイアーウォールの場所、 ファイアーウォールのポリシー、ファイアーウォールへの接続とファイアーウォールを通過する外部接続 • 不法侵入の防御と予防のメカニズム • 有能なスタッフによるレビューが行われている関連したログの存在 • たとえば、侵入、脆弱性のテストなど、考察されたアーキテクチャ、ポリシー、手順で、コントロールを評 価するプロセス 7.15 規制によるコントロールとベストプラクティス 7.15.1 情報システム監査人は、プライバシーとデータ防御に関する法律とベストプラクティスにより賦課されたプ ライバシーとデータ収集要件が、会社により資料として編集されているかどうかを評価すべきである。前に 指摘したように、情報システム監査人は、プライバシーとデータ防御ポリシーとプラクティスがウェブサイト に適切に表示されているかどうかを確認すべきである。 7.15.2 情報システム監査人は、B2Cイーコマース活動が政府の法律と規則にしたがっているか、コントロールを保 証するためにプロセスとコントロールを一致させているかどうか評価すべきである。たとえば、 マネーロンダ リング、税金、PCIのような業界の規制/標準など、地方のあるいは司法による有効な法律を固守するため に適切な方法を採用しているかを評価すべきである。情報システム監査人は、B2C活動に売られた商品や グッズが輸出法を破っていないかどうかを評価すべきである。暗号化技術、または兵器は輸出禁止のきっ かけとなるグッズの例である。 7.16 B2Cイーコマースアプリケーションとビジネスの継続の有効性 7.16.1 B2Cイーコマースはアプリケーションとインターネットへのアクセスの有効性に大きく依存しているので、 情報システム監査人は適切な容量計画プロセス、冗長度、フォールバックオプション、オフサイトの記憶、 媒体のローテーション、システムと通信インクの双方における災害修復手順が存在するかどうかを評価す べきである。 7.16.2 関連があればどこでも、情報システム監査人は、混乱の中でもビジネスの継続と早期の回復を保証する適 応性を確かめるための自動化か、あるいは関連するマニュアルプロセスに関したフォールバック計画をレ ビューすべきである。 7.17 有効性と効率性 7.17.1 情報システム監査人は、イニシアチブの意図された目的にかんするB2Cイーコマースアプリケーションの有 効性を評価すべきである。たとえば、取引量、ビジネスの価値、顧客/見込み客/訪問者の数、リピートビジ ネスの量と価値、顧客の減少などの視点は、システムの効率性を評価することに役立つであろう。 7.17.2 情報システム監査人は、関連するところではどこでも、予想されたコストと効果と実際を比較すべきであり、 又、B2Cイーコマースアプリケーションが十分にコスト効果があるかどうかを確認すべきである。プロセス の効率、顧客のフィードバック、 （システムの使用を指摘したように）アプリケーションの使いやすさもまた、 B2Cイーコマースアプリケーションの効率性を評価することに役立つであろう。 141 G22 B2C イーコマースレビュー 7.17.3 情報システム監査人は、進行中のベース上のB2Cイーコマースの有効性と効率性をモニターする適切なメ カニズムがあるかどうかを確かめるべきである。このことは、エラーや不正を防ぐものとして例外事項を見 抜き、報告するプロセスも含まれるべきである。 7.18 第三者サービス 7.18.1 B2Cイーコマースソリューションが第三者サービス、たとえば、インターネットサービスプロバイダー（ISP）、 認証機関（CA）、登録機関（RA）、ウェブホスト代理店など、に依頼しているときには、情報システム監査 人は、彼らの全てのセキュリティ手順が適切であるかどうか確かめるべきである。 7.18.2 このような第三者サービスが使われているときには、情報システム監査人は、会社の利害が適切に守 られているかどうかを確認するために、関係する契約とSLA報告のようなサービスレベルアグリーメント （SLAs）をレビューすべきである。 7.18.3 この項では、情報システム監査人は、ガイドラインG16『企業のITコントロールに関わるサードパーティの 影響』が適切なガイダンスを供給していることも考慮すべきである。 7.18.4 第三者がB2Cにおける認証に使われているときには、情報システム監査人はどのように情報が収集され、 コントロールの証明（ベタービジネスやウェブトラストなど）に使われているかをレビューするためにデュー デリを行うべきである。 7.19 否認防止 7.19.1 B2Cイーコマースソリューションが取引と支払いのプロセスを引き起こす場合には、情報システム監査人は、 認証、通信、プロセス、否認防止の確立に関する前の（セクション7.7、7.9、7.10）で言及された関連するコ ントロールを評価すべきである。 8 報告 8.1 報告の内容 8.1.1 B2Cイーコマースレビューの報告は、その適用範囲の目的により次の視点を含めるべきである。 • 意図、目的、使われた方法、前提 • キーとなる強みと弱みに関するソリューションの概要的な評価 • 弱みを克服し、ソリューションを改善するための提案 • COBITの情報要請規準とB2Cイーコマースの特別な要請基準（たとえば、否認防止）のコントロールの 範囲とコントロール外の影響 • 同様な将来のソリューションかイニシアチブを改良するために使える経験に関する提案 8.1.2 意見と提案は、報告を最終化する前に利害関係者と会社によって承認されるべきである。 9 適用開始日 9.1.1 本ガイドラインは2003年8月1日以降の全ての情報システム監査に適用される。 本ガイドラインは、2008年12月1日にレビューされ、改訂された。 参照 ISACA, E-commerce Security Series publications, 2000-2002 Australian Accounting Research Foundation, Auditing Guidance Statement AGS1056 E-commerce: Audit Risk Assessments and Control Considerations 142 G23 システム開発ライフサイクル 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 144 2 システム開発ライフサイクル（ＳＤＬＣ） ‥‥‥‥‥‥‥‥‥‥‥‥ 145 3 計画‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 147 4 能力‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 147 5 独立性‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 148 6 レビュー業務の成果‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 148 7 報告‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 150 8 フォローアップ‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 150 9 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 150 G23 システム開発ライフサイクル 1 背景 1.1 基準との関連 1.1.1 基準Ｓ６『監査業務のパフォーマンス』では、 「監査実施中において、情報システム監査人は監査目的を遂 行するための十分で、信頼できる適切な証拠を入手しなければならないと規定している。監査の発見事項 や結論はこの証拠をもとに適切な分析や解釈に裏付けられる必要がある。」と述べている。 1.1.2 ガイドラインＧ１４『アプリケーションシステムレビュー』はガイダンスを規定している。 1.1.3 ガイドラインＧ１７『IT監査・保証の専門家の独立性に対する非監査業務の影響』はガイダンスを規定して いる。 1.1.4 ガイドラインＧ２０『報告』はガイダンスを規定している。 １.２ COBITとの関連 1.2.1 ＣＯＢＩＴのフレームワークは、 「事業体の資産を安全に保全することは経営陣の責任となる。この責任を 果たすため、および期待どおりの成果を上げるため、経営陣は十分な内部統制システムを構築すべきであ る。」と述べている。 1.2.2 COBITマネジメントガイドラインは、経営陣用に以下の点の継続的で積極的な自己評価に特別の力点を おいたフレームワークを提供している。 • 成果評価基準－ＩＴが事業の必要とする事項をどの程度支援できるか。 • ITコントロールプロファイリング－どのITプロセスが重要か。コントロールのための重要な成功要因は何か。 • 認識－目標を達成しないリスクは何か。 • ベンチマーキング－他者がどのようにしているか。成果をどのように評価し比較できるか。 1.2.3 マネジメントガイドラインは、事業におけるＩＴの成果を評価することができる例示的な指標を提供して いる。重要な目標となる指標はＩＴのプロセスの結果を明らかにし評価するものであり、プロセスを支え る人々を評価することでプロセスがうまく機能しているかを評価する。成熟度モデルおよび成熟度属性は、 達成度評価やベンチマーキングを提供し、経営陣が達成度をコントロールしたり、コントロールにおける 欠陥を明らかにしたり、改善のための方策を見出すことに役立つ。 1.2.4 マネジメントガイドラインは、自己評価ワークショップを支援することに使え、またＩＴガバナンスの一部と して経営陣による継続的なモニタリングや改善の手順の実施を支援する場合にも使える。 1.2.5 COBITはコントロールに関する詳細一式や情報システム経営環境にコントロール技術を提供している。特 定の監査のスコープに適用されるCOBITの中で最適なものの選定は、特定のCOBIT ITプロセスの選択 と、COBITの情報要請規準に基づく。 1.2.6 本ガイダンスで示された項目をレビューする場合は、特定の目的やＣＯＢＩＴの手順として本文の付表に示 されたCOBITレファレンスを参照すること。 1.3 ガイドラインの必要性 1.3.1 事業遂行を支援するため、組織はアプリケーションシステムを設定する。アプリケーションシステムを定義 したり、調達したり、実装したりするプロセスは、要求事項を特定したり、アプリケーションシステムを実際 に構築したりするいくつかの段階があり、これらは一般的にはシステム開発ライフサイクル(SDLC)と呼ば れている。 1.3.2 本ガイドラインは、アプリケーションシステムのＳＤＬＣのレビューを実施する情報システム監査人に対し 必要なガイダンスを提供している。 144 G23 システム開発ライフサイクル 2 システム開発ライフサイクル（ＳＤＬＣ） 2.1 定義 ２.１.１ このＳＤＬＣはいくつかの段階（実現可能性の検討から導入後のレビュー実施）を含む手順であり、経営 陣のニーズを、自社開発あるいは他社からの購入、あるいはその両方の手法でアプリケーションシステムに 置き換えることに使われる。 2.2 ＳＤＬＣに影響を与える事項 2.2.1 アプリケーションシステムのためのＳＤＬＣは選択する取得あるいは開発モードに依存する。アプリケー ションシステムは以下のようないくつかのモードにより取得あるいは開発することができる。 • 社内の資源を使った自社開発 • 社内あるいは社外（国内あるいは海外）に所在する外部資源を全面的あるいは部分的に使っての自社 開発 • 自社向けに修正しないままベンダーが開発したソフトウェアパッケージ • 特定の要求事項に合わせて修正されたベンダーが開発したソフトウェアパッケージ • 時に大規模で複雑なアプリケーションには上記を組み合わせることになる。 2.2.2 ある組織では自社開発あるいはベンダー開発の特定のＳＤＬＣの方法やプロセスが使われる。これらは一 般的に、特定のアプリケーションシステム用にデザインされたプロセスを自社用に修正するための設備を 取得する異なるモードのための標準プロセスと規定されている。これらはＳＤＬＣを運営する適切なツール が使われる。そうした場合ＳＤＬＣは手法やツールに依存する。 2.2.3 アプリケーションシステムが、パッケージとして購入されず開発される場合、ＳＤＬＣは使われるウォータ フォール開発、プロトタイピング、高速アプリケーション開発、ＣＡＳＥおよびオブジェクト指向開発などの 開発手法に依存することになる。 145 G23 システム開発ライフサイクル 2.3 ＳＤＬＣに係るリスク 2.3.1 アプリケーションシステムのＳＤＬＣ中は以下のようないくつかのリスクに直面する。 • アプリケーションシステムに不適切なＳＤＬＣの採用 • ＳＤＬＣプロセスの不十分なコントロール • ユーザーの要求事項や目的に合致していないアプリケーションシステム • 不適切なステークホルダー（内部監査を含む）の関与 • 経営陣の支援欠如 • 不十分なプロジェクトマネジメント • 不適切な技術やアーキテクチﾔー • 範囲の変動 • 時間超過 • コスト超過 • アプリケーションシステムの不十分な品質 • アプリケーションシステムのセキュリティやコントロール（確認や監査証跡を含む）への不十分な注意 • 合致しない成果規準 • モデルマネジメントの資源やスタッフィングが不適切 • スタッフィングのスキルが不十分 • 文書化が不十分 • 不十分な契約上の保護 • 選択したＳＤＬＣや開発手法の支持が不適切 • 他のアプリケーションやプロセスからの独立性が不十分 • 不適切な構成管理 • データ変換やデータ移動や本番移行の計画が不十分 • 本番移行後の業務処理中断 146 G23 システム開発ライフサイクル 3 計画 3.1 計画時に考慮すべき事項 3.1.1 情報システム監査人はアプリケーションシステムのＳＤＬＣをレビューする計画を策定する場合には以下の 事項を考慮すべきである。 • 取得あるいは開発モード、技術、規模、目標、アプリケーションシステムの意図した用途 • 入手と導入のプロジェクト構造 • プロジェクトチームの技術と経験に関するプロファイル • 選択したＳＤＬＣモデル • 正式なＳＤＬＣ手続きと独自に適用したプロセス • ＳＤＬＣに影響しそうなリスク • 適切な経営陣が認識する懸念あるいは課題 • 現在のＳＤＬＣの状況 • アプリケーションプロセスのＳＤＬＣ初期段階以前のレビュー • 同種のアプリケーションシステムの事前ＳＤＬＣレビュー • 情報システム監査人あるいは計画されたレビューに関連するＩＴなどのリスク評価やレビュー • 利用可能な情報システム監査人の技術や経験と、必要時に外部の支援が得られる可能性 3.2 委任事項 3.2.1 上記を踏まえ情報システム監査人は計画されたＳＤＬＣレビューについて以下の委任事項を決定すべきで ある。 • レビューの目的 • レビューの対象となるＳＤＬＣの各段階におけるレビューの範囲 • レビューの種類－ＳＤＬＣの導入前レビュー、ＳＤＬＣの段階ごとの実施途中の平行/同時のレビューあ るいはＳＤＬＣ完成後の段階における完成後レビューによる • レビューの時期－予定されるその始期終期 • 観察および勧告事項の報告プロセス • 合意した行動のフォローアッププロセス 3.2.2 情報システム監査人は選択したアプリケーションシステムのＳＤＬＣについて計画されたレビューについて の適切な経営陣の合意を取得すべきある。 4 能力 4.1 スキルと経験 4.1.1 ＳＤＬＣのレビューを委任された情報システム監査人は、レビューを経済的かつ効率的に遂行する必要と なるスキルと経験を有しているべきである。特定のＳＤＬＣの方法やツールが使われる場合は、情報シス テム監査人はそうした方法やツールと関連するリスクについての十分な知識と経験を持っているべきある。 同様に、アプリケーションシステムを業者から購入するのではなく自社で開発する場合は、情報システム監 査人は使われる開発方法やツール（例えばウォータフォール開発、プロトタイピング、高速アプリケーショ ン開発、ＣＡＳＥおよびオブジェクト指向開発）についての十分な知識と経験を有するべきである。事情が 許すならば、情報システム監査人は内部で利用可能な技術の補完として外部の資源（適用される方針、手 続き、許可により）を求めるべきである。 147 G23 システム開発ライフサイクル 5 独立性 5.1 独立性 5.1.1 アプリケーションシステムのＳＤＬＣをレビューする際、情報システム監査人はアプリケーションシステムの 入手や導入への係わりにはプロジェクトチームから独立して存在し、かつ独立しているように見られるべき ある。この意味から非監査業務における情報システム監査人の独立性について規定しているガイドライン Ｇ１７を参照すべきである。 6 レビュー業務の成果 6.1 レビューの種類 6.1.1 情報システム監査人は然るべき経営陣との間で結ばれた委任契約によりＳＤＬＣのレビューや監査を遂行 すべきである。 • レビューが導入前レビューである場合、情報システム監査人は潜在リスクと同様に適切性の評価と適切 な経営陣への必要なリスク軽減策の提供のために提案されたＳＤＬＣモデルをスタディすべきである • 同時並行したレビューの場合は、情報システム監査人は然るべきＳＤＬＣの段階について、現に起こりつ つあるリスクや問題点を明確にするためレビューし、然るべき経営陣に対し必要なリスク削減の提案を 行うべきである • 導入後のレビューの場合は、情報システム監査人は完成後の然るべきＳＤＬＣの段階にについて、直面 する問題点を明らかにし、その改善に役立つ（可能ならば）また将来の学習材料に使える提案を行うべ きである 148 G23 システム開発ライフサイクル 6.2 レビューされるべき事項 6.2.1 情報システム監査人はリスクや問題点とその影響を評価するにあたって、以下の点について学び見極める べきである。このなかのいくつかは、レビューの種類にかかわらず（導入前、同時並行あるいは導入後）全 てのＳＤＬＣレビューに当てはまり、いくつかは特定のタイプのレビューにのみ当てはまる。情報システム監 査人は計画するレビューの目的や範囲に応じたこうした項目を学び見極めるべきである。そうすることで情 報システム監査人はリスクや問題点の適切な評価や影響を軽減ための指摘をすることができる。 • アプリケーションシステムのプロジェクト趣意書 （プロジェクト計画書、納品物、スケジュール）およびアプリケーションシステムのビジネスケース（費用 対効果に着目） • 作業グループ、推進機関、および関連する役割と責任を含むプロジェクト構造 • 適用する正式なプロジェクトマネジメントの手法（例えばＰＲＩＮＣＥ２）および自社用に適合するよう 修正した手法 • 開発やアプリケーション開発方法、例えばウォータフォール開発、プロトタイピング、高速アプリケー ション開発、ＣＡＳＥおよびオブジェクト指向開発およびアプリケーションシステムのための方法論 • アプリケーションシステムの購入に関する業者との契約 • 自社用修正や開発の外部委託に関する業者との契約 • ＳＤＬＣモデル内のコントロール要領－レビュー中のＳＤＬＣの段階に応じた特にレビュー、認証、承認 および署名 • レビュー中のＳＤＬＣの段階に応じた納品物の構造 • 作業グループや運営委員会等の打ち合わせの議事録 • 実際の納品物とレビューの監査証跡や署名 • プロジェクトの報告や進行状況の記録（工数、所要時間と経費） • 資源管理 • 継続的なリスク管理 • 品質管理や保証 • 変更管理 • SLA,業務委託契約を含む成果や課題管理 • 構成管理 • データコンバージョンやマイグレーション • テストを含むプロジェクト過程のレビューに関する文書化 • プロジェクト内部および業者とのコミュニケーション • アプリケーションシステムのＳＤＬＣ初期段階のレビュー（もしあれば） • 同様のアプリケーションについてのＳＤＬＣ初期段階のレビュー（もしあれば） • 遵守すべき関連法令、規約や方針（もしあれば） 6.2.2 ＣＯＢＩＴはコンピュータ化対応策の明確化（ＡＩ１）とアプリケーションソフトウェアの調達と保守（ＡＩ ２）を含むアプリケーションシステムの調達に関する高次元でのコントロール目標について定義している。 同様にプロジェクト管理（ＰＯ１０）、品質管理（ＰＯ１１）とシステムセキュリティの保証（ＤＳ５）にいての 高次元のコントロール目標がある。ＣＯＢＩＴにはより詳細なコントロール目標についての拡張がある。レ ビューの一部として、情報システム監査人はコントロール目標（レビュー対象のＳＤＬＣの段階に応じた） の程度が合致しているか、目標を達成するために採用されたメカニズムと手続きが効果的かについて評価 すべきである。 149 G23 システム開発ライフサイクル 6.2.3 ＣＯＢＩＴはまたアプリケーションシステムが準拠すべき７つの情報要請規準（有効性、効率性、機密性、 インテグリティ、可用性、コンプライアンス、および信頼性）を定義している。アプリケーションシステムの ＳＤＬＣのレビューの一部として、情報システム監査人はこれらの情報要請規準を適切に満たすことに寄 与するべく、レビュー中のＳＤＬＣのプロセスや段階が効率的がどうかも評価しなければならない。アプ リケーションシステムのこれらの規準に対するコンプライアンスについての実質的な評価は、アプリケー ションシステムのレビューの一部を構成している。 （Ｇ１４『アプリケーションシステムレビュー』を参照のこ と。） 7 報告 7.1 情報システム監査人の報告 7.1.1 アプリケーションシステムのＳＤＬＣレビューのため、しばしば報告はリスクや問題点が発見された都度段 階的に行われる。経営陣がとるべき適切なアクションが対処される報告となる。レビューを通じて提起され た全ての課題を記載した最終報告となる。 7.1.2 レビューの種類に応じて、以下の観点から報告が行われる。 • ＳＤＬＣモデルと開発手法の適切性 • リスクと課題、その原因と影響 • ＳＤＬＣの段階ごとの可能なリスク軽減策－レビュー中あるいは今後の開発段階において。例えばデザ イン段階での問題点のいくつかは後の開発やテスト検証の段階でのリスク軽減策を必要とする。 8 フォローアップ 8.1 タイムリーなフォローアップ 8.1.1 アプリケーションシステムのＳＤＬＣレビューについては、特に導入前や同時平行レビューにおいて、リスク 軽減策がタイムリーに行われるよう妥当な評価を行うための適切なフォローアップが行われるべきである。 導入後レビューの場合は、フォローアップは開発の終盤の段階や将来に実施される同種プロジェクトにタ イムリーな是正策が実施されることを目指して行われるべきである。 9 適用開始日 9.1 本ガイドラインは2003年8月1日以降に開始する全ての情報システム監査に適用される。 用語集についてはＩＳＡＣＡのホームページwww.isaca.org/glossary.htm.を参照のこと。 150 G24 インターネットバンキング 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 152 2 インターネットバンキング‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 153 3 インターネットバンキングのレビュー‥ ‥‥‥‥‥‥‥‥‥‥‥‥ 154 4 独立性‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 156 5 能力‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 156 6 計画策定‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 156 7 インターネットバンキングレビューのパフォーマンス‥ ‥‥‥‥‥ 158 8 報告‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 161 9 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 162 G24 インターネットバンキング 1 背景 1.1 ISACA基準との関連 1.1.1 ISACA基準S2『独立性』は、 「情報システム監査部署は、監査任務の目標完了を可能ならしめるため、レ ビューされる領域や部署から独立しているべきである。」と述べている。 1.1.2 基準S4『専門家としての能力』は、 「情報システム監査人は、監査任務を実施する技量と知識を持ち、技 術的に能力があるべきである。」と述べている。 1.1.3 基準S5『計画策定』は、 「情報システム監査人は監査目的に取り組み、適用法令と専門家としての監査基 準に合致する情報システム監査範囲を計画策定すべきである。」と述べている。 1.1.4 基準S6『監査作業のパフォーマンス』は、 「監査期間中、情報システム監査人は、監査目的を達成するに 充分で、信頼性があり、関連付けられる証拠を取得すべきである。」と述べている。監査発見事項と結論は、 本証拠の、適切な分析と解釈によりで裏付けられることになっている。 1.1.5 ガイドラインG22『B2C イーコマースレビュー』は手引きを提供している。 1.1.6 手続P3『侵入検知システムレビュー』は手引きを提供している。 1.1.7 手続P2『電子署名とキー管理』は手引きを提供している。 1.2 COBITとの関連 1.2.1 COBITフレームワークは、 「企業の全資産を保全するのは、 マネジメントの責任である。」と述べている。 期待を達成するのと同様、この責任を果たすために、 マネジメントは内部統制の充分なシステムを確立しな ければならない。 1.2.2 COBIT マネジメントガイドラインが、 マネジメント指向のフレームワークを提供する継続的かつ事前対策と なるコントロール自己評価が特に焦点を当てているのは、 • パフォーマンス測定－IT部門がビジネス要件をいかに上手く支援しているか？ • IT統制プロファイリング－いかなるITプロセスが重要であるか？コントロールのための重要成功要因は 何か？ • 認識－目的を達成できないリスクは何か？ • ベンチマーキング－他者は何をしているか？結果はどのように測定/比較することができるか？ 1.2.3 マネジメントガイドラインはビジネス用語におけるITパフォーマンスの評価を促進する測定基準例を提供し ている。重要目標達成指標は、ITプロセスの成果を識別・測定し、重要成果達成指標は、プロセスを稼働 させるものを測定することにより、プロセスがどれだけ上手く効果をあげているかを評価する。成熟度モデ ルと成熟度属性は、 マネジメントがコントロール能力を測定し、コントロールギャップと改善戦略を識別す るのを助け、能力評価とベンチマーキングを提供する。 1.2.4 マネジメントガイドラインは、自己評価ワークショップを支援するために使用することができ、また、ITガバ ナンスのスキームの一部として継続的モニタリングと改善手続を管理することによって、実装を支援するた めに使用することができる。 1.2.5 COBITは、情報システム管理環境のためのコントロールとコントロール技術の詳細な組合せを提供する。 特定の監査の範囲に適用されるCOBITで最も関連性の高い材料の選別は、特定のCOBIT『ITプロセス とCOBITの情報要請規準の考察』の選択に基づいている。 1.2.6 本手引きによって言及されている領域をレビューする際に、考慮されるべきCOBITの特定の目的やプロセ スのために、本文書の付録にあるCOBIT参照を参照する。 152 G24 インターネットバンキング 1.3 ガイドラインに必要なもの 1.3.1 本ガイドラインの目的は、関連する情報システム監査基準がレビュー過程で遵守されるように、インター ネットバンキング構想・アプリケーション・実装と関連のあるリスクを識別しコントロールするのを支援する ことになっているのと同様、そのレビューを実行するために、勧告された実践を説明することになっている。 2 インターネットバンキング 2.1 定義 2.1.1 用語インターネットバンキングは、銀行業務の遠隔サービス提供経路としてのインターネットの利用を表し ている。業務は、口座開設や他口座への送金と言った、従来の業務と（顧客が銀行のウェッブサイト上で 手形の授受ができる）電子オンライン支払のような新しい銀行業務を含んでいる。 2.2 インターネットバンキングアクティビティ 2.2.1 顧客との関係を開発・拡大するためにインターネット技術を利用してビジネス形態を変化させている銀行 が益々増えている。銀行内でインターネットが利用される程度は、インターネット技術に関して銀行の相対 的成熟度次第である。銀行は、インターネットバンキングを二つの主要な方法で提供する。形ある事務所 を持つ、既存の銀行、通常、レンガとモルタルの銀行は、ウェッブサイトを確立し、顧客に、従来のサービス 提供経路に加え、インターネットバンキングを提供することができる。 もう一つは、仮想、無支店、インターネットだけの銀行を設立することである。仮想銀行の心臓部にあるコ ンピュータサーバや銀行データベースが、その銀行の登記上の住所となる事務所や他の場所に保管されて いるかもしれない。仮想銀行は、顧客に自動支払機(ATM)や他の組織が所有している遠隔サービス提供 経路を通じて預金したり、引き出したりする能力を提供する。インターネットバンキングの特徴は、技術的 な、顧客サービス革新、インターネットの普遍的、世界的性格、インターネットバンキングアプリケーション の伝統的コンピュータシステムとの統合、必要な情報技術を提供するサードパーティへの銀行の依存度の 増加を含んでいる。それゆえ、銀行は、インターネットアクティビティを次のやり方で実施できる。 • 情報的－これはインターネットバンキングの基礎レベルである。典型的に、銀行は独立サーバ上に銀行 の製品、業務に関するマーケッティング情報を持っている。これら運用に関連するリスクは、情報システ ムが、通常、そのサーバと銀行の内部ネットワーク間に経路がないので、比較的低い。このレベルのイン ターネットバンキングは銀行によって提供されるか、アウトソ－スされ得る。銀行へのリスクが相対的に 低い間は、そのサーバ上のデータやウェッブサイトは変更に対して弱い。それ故、適切なコントロールは、 銀行のサーバやウェッブサイトのデータの無許可変更を防止するように適切に配置していなければなら ない。 • 会話的－この種のインターネットバンキングシステムは、銀行のシステムと顧客間の双方向のやり取りを 可能にする。双方向のやり取りは電子メール、口座引合い、貸付申込み、静的ファイル更新（名前、住所 変更）に限定されるかも知れない。これらサーバは、通常、銀行の内部ネットワークに対して直接経路を 持っているので、運用リスクは、この設定において、情報システムより高い。コントロールは、銀行の内部 ネットワークやコンピュータシステムにアクセスしようとする無許可の試みを防止、モニター、警告するよ うに適切に配置しているべきである。ウィルス検知と防止コントロールもまたこの環境に重要である。 153 G24 インターネットバンキング • 取引的－このレベルのインターネットバンキングは顧客に直接金銭の取引を実行せしめる。異なるリス ク側面を持つ二つのレベルの取引的インターネットバンキングがある。基本取引サイトは、一顧客の口 座と銀行間の金銭の移動を可能ならしめる。上級取引サイトは、銀行外の第三者への直接的支払実行 方法を提供する。これは、銀行小切手や電子送金／自動的登録承認を経由した手形支払の形態を取り 得る。多くの銀行は、また、顧客から、上記いずれかの支払方法を使用する消費者同士の支払を提供し ている。送金が銀行外の場所へ認められている場合、運用リスクは増加する。この環境下、未承認アク セスは、不正を導いたり、引き起こし得る。通信経路が概して複雑で、いくつかの公共サーバ、回線、顧 客と銀行の夫々の内部ネットワーク経由を含むかも知れないので、これは最も高いリスクアーキテク チャであり、最強度のコントロールがなければならない。 3 インターネットバンキングのレビュー 3.1 範囲 3.1.1 銀行サービスは、その当然の性格により、ハイリスクビジネスである。銀行業に関連する主たるリスクは： 戦略、風評、 （セキュリティ－時々取引的と呼ばれる－法的リスクを含む）運用、信用、価格、外国為替、金 利、流動性。インターネットバンキング業は、従来の銀行サービスで識別されていなかったリスクを引き起 こしていないが、これら伝統的リスクの一部を増加させ、変化させている。コアビジネスと情報技術環境は 緊密に結び付いており、それによってインターネットバンキングの全リスク側面に影響を与えている。特に、 情報システム監査人の観点から、主たる論点は戦略的、運用上、風評リスクであり、これらは直接に信頼 できるデータフローに関連し、インターネットバンキングの迅速なる導入と背後にある技術的複雑性によっ て高められているからである。銀行は、自分達が技術的リスク発現を識別し、モニターし、コントロールでき るようなリスク管理プロセスを持つべきである。新技術のリスク管理は三つの必須要素を持っている。 • リスク管理は取締役会と上級マネジメントの責任である。彼らは、銀行のビジネス戦略の開発と有効な リスク管理方法の確立に責任がある。彼らは、銀行のインターナットバンキング利用とその関連リスク を管理する知識と技量を持つ必要がある。取締役会は、銀行がインターネットバンキング業務を提供す べきか否か、如何にすべきかに関して、明確、周知され、文書化された戦略的決定をなすべきである。最 初の決定は、境界横断の文脈に現れるものも含め、リスクに取組む、明確な説明責任、ポリシ、コント ロールを含むべきである。取締役会は、銀行のリスク側面に重大な影響を持つ、インターネットバンキン グ技術関連のプロジェクトをレビュー・承認・モニターし、充分なコントロールが識別・計画・実装されて いることを確認すべきである。 • 実装技術は、情報技術上級マネジメントの責任である。彼らは、インターネットバンキング技術と製品を 有効に評価し、それらが適切にインストールされ文書化されていることを確認する技量を持っているべき である。もし銀行がこの責任を内部的に履行する専門性を持たないならば、この種のビジネスに専門性 のある納入業者に連絡をとったり、補完技術や専門性のある別のサードパーティと提携を組むことを考 慮すべきである。 • リスクの測定・モニタリングは、執行マネジメントの責任である。彼らは、インターネットバンキングに関 連するリスクを有効に識別・測定・モニター・コントロールする技量を持つべきである。取締役会は、使 用技術、想定リスク、リスク管理方法に関する、定期報告を受領すべきである。 154 G24 インターネットバンキング 3.1.2 インターネットバンキングシステムの内部統制は、銀行が提供するリスクレベル、実装に関わるリスクレ ベル、銀行のリスク許容レベルに相応であるべきである。インターネットバンキング環境の内部統制のレ ビューは、情報システム監査人が、コントロールが適切であり、適切に機能しているという合理的保証を提 供するのを支援しなければならない。個々の銀行のインターネットバンキング技術と製品のコントロール目 標が焦点を当てるのは、 • 運用の有効性・効率性・経済性と、会社方針・法的要求事項への準拠を含む、計画された技術と戦略 的目標の一貫性 • 事業復旧計画を含めた、データ・サービスの可用性 • 資産保全・取引の適切な権限・データフローの信頼性を含めた、データインテグリティ • 従業員・顧客によるアクセスに対するコントロールを含めた、データ機密性と個人情報要請規準 • 管理報告の信頼性 3.1.3 内部統制とその妥当性を適切に評価するために、情報システム監査人は銀行の運用環境を理解すべきで ある。2000年にITガバナンス協会発行の、COBIT第3版は情報システムに相応しい七つの情報要請規準 を置いている。 • 有効性 • 効率性 • 機密性 • インテグリティ • 可用性 • 準拠性 • 信頼性 3.1.4 本文書の3.1.3にリストされている情報要請規準はインターネットバンキングの場合に密接な関連がある。 それ故、インターネットバンキングのレビューは、COBITの情報要請規準が、インターネットバンキング構 想／アプリケーション／実装によって合致する方法に取組むべきである。 3.1.5 銀行業の他の形態／経路と比較して、インターネットバンキングはインテグリティや顧客データの機密性 への信頼とシステムの可用性に大いに依存している。これに関連して、障害復旧手続同様、多重性と後退 選択が適切に配置されるべきである。支払や送金を含むインターネットバンキングの場合、取引の否認不 可とインテグリティは必須な属性である。そういう場合、インターネットバンキングのレビューは、否認不可 とインテグリティを保証する際のインターネットバンキングシステムコントロールの有効性に取組むべきで ある。インターネットバンキング施策の可用性を評価する際、特にその継続性が境界横断プロセスに基づ いているなら、規制を破ったり、銀行規制の準拠に反するかも知れないので、しかるべき注意がなされるべ きである。 3.1.6 インターネットバンキングにとって、いかなる通信・取引・アクセス要求も正当であることを確認することが 必須である。それ故、銀行は、電子取引の開始を求める固定客の識別・許可を認証するのと同様、新顧客 の識別・許可を確証するに当たり、信頼できる方法を使用すべきである。口座開設中の顧客確証は窃盗・ 不正取引・マネーロンダリングのリスクを削減するのに重要である。強度のある顧客識別・認証プロセス は、成り済ましのリスクと潜在的顧客に関する有効な信用チェックを実施する困難を含め、国内境界や国 境を越える顧客と電子的にビジネスを行うことから発生するかもしれない困難を与える境界横断状況にお いて、特に重要である。 3.1.7 可監査性は、取引の重要な割合がペーパーレス環境内で発生しているので、インターネットバンキング環 境においては、一層重要である。 155 G24 インターネットバンキング 4 独立性 4.1 専門家としての客観性 4.1.1 任務を受入れる前に、情報システム監査人は、レビュー中、インターネットバンキングに持っている関心がレ ビューの客観性を損なうことでは決してないという合理的保証を提供すべきである。いかなる利益相反の 場合でも、これらははっきりと銀行のマネジメントに報告されるべきであり、銀行マネジメントの書面の承 認が任務受入れ前に取得されるべきである。 5 能力 5.1 技量と知識 5.1.1 情報システム監査人は、使用している技術とインターネットバンキングに関連するリスクのレビューを実施 するに必要な技術的・運用上の技量と知識を持つべきである。情報システム監査人は、技術と製品が銀行 の戦略的目標に一致しているかどうかを判定すべきである。とりわけ、その種のレビューは、銀行運営の知 識と関連リスク、ウェッブ管理／ウェッブ保管技術・暗号化技術・ネットワークセキュリティアーキテクチャ のような側面を評価するに必要な技術的知識を伴った銀行法令の知識、ファイアウォール・侵入検知・ ウィルス防御のようなセキュリティ技術を必要とする。専門的アドバイスや専門的情報が必要な場合は、 適切な利用が外部の専門家的人的資源からなされるべきである。外部の専門的人的資源が利用されるか もしれないと言う事実は、銀行のマネジメントに書面で報告されるべきである。 6 計画策定 6.1 ハイレベルリスク評価 6.1.1 情報システム監査人は、銀行のインターネットバンキング目標、目標達成に使用される戦略、銀行が顧客 との関係でインターネット技術を使用する方法（2.1.1で述べた情報的、報告的、取引的のいずれでも）に 関する情報を収集すべきである。こうして収集された情報は、COBITの情報要請規準に附属するリスク同 様、銀行サービスリスクのハイレベル評価を実施するにあたり役に立つようなものであるべきである。この ハイレベルリスク評価は、レビューの範囲を決定するに役立つ。もし銀行が企業リスクフレームワークを持 つなら、これは使用され得る。 6.1.2 情報システム監査人は、インターネットバンキングの実装・表明・銀行への潜在的影響・発生可能性・リス ク防止のために実装され得るリスク管理方法に関連する主たる潜在的一般かつ固有の脅威を分析・評価 するリスク評価手法に従うべきである。次の戦略的リスクが評価されるべきである。 • 戦略的評価とリスク分析 • 企業の戦略的目標内の統合 • 技術的インフラストラクチャの選別と管理 • サードパーティプロバイダとのアウトソース関係を管理する包括的プロセス 156 G24 インターネットバンキング 6.1.3 次のセキュリティリスクが評価されるべきである。 • 顧客のセキュリティ慣行 • 顧客の認証 • 取引の否認不可と説明責任 • 職務分離 • システム・データベース・アプリケーション内の許可コントロール • 内外部不正 • 取引・データベース・レコードのデータインテグリティ • 取引の監査証跡 • 転送中のデータ機密性 • サードパーティセキュリティリスク 6.1.4 次の法的リスクが評価されるべきである。 • 顧客への情報開示 • 個人情報 • 法規・規制者・監督者の表明に対する準拠 • 海外司法へのエクスポージャ 6.1.5 次の風評リスクが評価されるべきである。 • サービスレベルの実現 • 顧客関与のレベル • 事業継続と緊急事態対応計画 6.2 レビューの範囲と目的 6.2.1 情報システム監査人は、適切であれば銀行マネジメントに相談して、インターネットバンキングのレビューの 範囲と目的を明確に策定すべきである。レビューでカバーされるべき側面は、範囲の一部として明示的に 記述されるべきである。銀行のインターネット活動の性格と（2.2.で述べた）インターネットバンキング活 動と関連するリスクの量は、ハイレベルリスク評価で識別されたように、どの側面がレビューの程度・深度 同様にレビューされるべきかを指示している。 6.2.2 レビューの目的のために、コントロール目標は銀行法令に従っているべきである。インターネットは国境が ないので、インターネットベースのサービス提供経路を利用する銀行にとって、複数の州、それどころか多 国籍環境で運用することが容易である。銀行は、銀行が物理的に存在する場所と言うより、顧客が存在す る場所の法令、慣習に縛られていると思うかも知れない。それ故、情報システム監査人は、銀行の現在の 拠点と計画している顧客の所在地の地理的広がりを確定すべきである。情報システム監査人は、インター ネットバンキング運営に法規制を持つ司法権の数を識別し、インターネット銀行がこのリスクを管理する方 法を確定すべきである。 6.3 アプローチ 6.3.1 情報システム監査人は、レビューの範囲と目的が客観的かつ専門的な方法で履行されうるような方法でア プローチを策定すべきである。次のアプローチは、レビューが実装前レビューなのか、実装後レビューである かどうかによるべきである。アプローチは適切に文書化されるべきである。もし外部の専門家の情報やアド バイスが利用されることになっているならば、これもまたアプローチの一部として特定されるべきである。 157 G24 インターネットバンキング 6.4 計画のためのサインオフ 6.4.1 組織の慣行に応じて、情報システム監査人にとって、レビュー計画とアプローチのために銀行マネジメント の同意を得るのは適切かもしれない。 7 インターネットバンキングレビューのパフォーマンス 7.1 執行 7.1.1 レビューされるべき側面とレビュープロセスは、計画プロセスの一部としてのアプローチ同様、レビューの 意図された範囲と目標を考慮することにより選択されるべきである。 7.1.2 一般に、インターネットバンキング環境を収集・分析・解釈する際に、調査は、インターネットバンキングに 関する銀行法規・インターネット法・個人情報保護法・ウェッブバンキングシステム文書・インターネットバ ンキング施策の利用のような、入手可能な文書からなっているべきである。 7.1.3 従来から判明しており、フォローアップを必要とする可能性のある、インターネットバンキング領域に関連 する問題を識別するために、情報システム監査人は次の文書をレビューするべきである。 • 過去の検査報告書 • フォローアップ活動 • 過去の検査からの調書 • 内外監査報告書 7.1.4 情報システム監査人は、インターネットバンキング構想／システムに関連して手動同様自動化されたキープ ロセスを図表化すべきである。 7.1.5 (6.1で述べた）コアビジネスリスクの評価はインターネットバンキング目標・戦略・ビジネスモデルの批判的 評価を含むべきである。 7.1.6 こうして情報システム監査人は、これらプロセスに属すると識別されたリスク（情報システムリスクとビジネ スリスク）がありそうな効果を伴って実現し、これらリスクを軽減するコントロールとともにリスクを文書化 するという可能性を評価すべきである。 7.1.7 情報システムリスク評価の一部として、外部の情報システム脅威は、銀行が提供する製品の性格と取組む べき外部の脅威次第で評価されるべきである。これら脅威は、サービス拒否、データへの未承認アクセス、 コンピュータ機器の未承認使用を含んでおり、それは気まぐれなハッカー・同業者・外国政府・テロリス ト・不満のある従業員のような、種々の出所から引き起こされ得る。 7.1.8 実装前後レビューの性格次第で、情報システム監査人は、プロセスが意図されたように機能していることを 実証するために、テスト・本番環境での重要なプロセスをテストすべきである。これらテストは、残高照会の テスト・形提示と支払のテスト・ペネトレーションテストを使用してのセキュリティメカニズムのテストを含 んでいる。 7.1.9 実装後レビューにおいて、情報システム監査人は、少なくとも、ネットワーク図の理解・ネットワークルート 付け・システムとネットワークセキュリティ評価・内外侵入を取得すべきである。 7.1.10 インターネットバンキング施策は広く情報技術施策であるので、業界の他の関連基準や規制と同様、 COBITに確立されている情報要請規準に合致しているべきである。情報要請規準、標準、規制への準拠 の程度と非準拠の効果が分析されるべきである。 158 G24 インターネットバンキング 7.2 レビューすべき側面 7.2.1 有無がレビューされるべき組織的側面： • 精査とリスク分析は銀行がインターネットバンキング業を行う前に実施されている • 精査とリスク分析は境界横断活動が行われる所で実施されている • インターネットバンキングは、銀行の全使命、戦略的目標、運営計画と一致している • インターネットアプリケーションは識別・承認されたビジネスモデルに追従している • インターネットバンキングシステム・業務は自家管理化、サードパーティに外部委託されている • 組織のマネジメントと人員はインターネットバンキングを管理するに相応しい知識と技術的技量を発揮 している • 職務分離を確保する方法が適切に配置されている。 • 管理報告書はインターネットバンキング取引と支払業務活動を適切に管理するに充分である 7.2.2 有無がレビューされるべきポリシー側面： • 顧客獲得・供給者との契約・顧客認証・顧客／供給者データの個人情報・監査証跡・使用ログのレ ビュー・銀行がインターネットバンキングに関連する法的展開に追従しているかどうかに関して、適切な ポリシが識別・実装されてきていた • 銀行はインターネットバンキング製品群に関連する正確な個人情報開示を提供している • 顧客がインターネットバンキングサービス（銀行名と本店所在地・主要銀行監督官庁・顧客サービス・他 の関連情報への接続方法）に入る前に、彼らが銀行の身元と法的地位に関して、情報に基づく判定がで きるように、情報がウェッブサイト上に提供されている。 • 銀行は、顧客が銀行製品と非銀行製品を明確に区別できるような、また、銀行のウェッブサイトを出る 時に連絡されるようなハイパーテクストリンクの使用を支配するポリシを確立してきた。 • 変更コントロール・監査証跡のレビュー・使用ログ（ファイアウォールログやその他報告書）のレビュー ／分析に関する適切な手続が適切に配置している。 • 個人情報とデータインテグリティを確実にし、ベストプラクティス同様適用法令への準拠を確実にする 適切で充分な手続が適切に配置している。 7.2.3 有無がレビューされるべき計画側面： • 計画された情報システム技術アーキテクチャが企業化可能であり、安全で健全な運営に帰結されている • 内外攻撃を含む予想外の事象から引き起こされる問題を管理・抑制・最小化するべく、適切な事故対応 計画が適切に配置されている • 「インターネット製品ライフサイクル」が存在し、インターネットアプリケーションを開発・保守・更新の ために追従している • 重要なインターネットバンキングプロセス／サービス提供システムの事業継続／緊急事態対応計画が適 切に配置し、定期的にテストされている 159 G24 インターネットバンキング 7.2.4 有無がレビューされるべき情報システムインフラストラクチャ側面： • インフラストラクチャとシステムが提案された事業計画を収容するための拡張能力がある • 情報セキュリティアーキテクチャは策定され、インターネットバンキングモデルの性格にとって適切であ る • 銀行はインターネットバンキングシステムに関連する、ハードウェア・ソフトウェア・データ通信機器の物 理的セキュリティに取組む充分なプロセスとコントロールを持っている • 銀行は、ウェッブサイトと銀行の内部ネットワークやコンピュータシステム間の経路への充分なコント ロールと、内部コントロールが適切なファイアウォール技術を使うことにより外部環境から適切に保護 されているかどうかを確実にする健全なプロセスを持っている • データベースとデータフローは未承認／不適切アクセスから保護されている • アクセスポイントと脆弱性のある領域の識別を確実にする適切かつ充分な手続が適切に配置されてい る • 適切な手動均衡コントロールがあるが、そこでは自動化されたコントロールが不充分である • 顧客取引のレコードは、もしコントロール目的やマーケッティングのような他のビジネス機能のために保 管・保存されているならば、顧客識別・取引番号・取引種別・取引金額・その他関連情報を含んでいる 7.2.5 有無がレビューされるべき遠距離通信インフラストラクチャ側面： • ネットワークア－キテクチャは、インターネットバンキング運営の性格・時宜・程度にとり、適切である • 使用されているネットワークプロトコールは意図された使用（例えば、もし支払や送金がインターネットバ ンキングシステムを通して受諾されるならば、セキュリティプロトコールが使用されるべきである）にとっ て適切である • 銀行は、ファイアウォールサーバやコンポーネントへのアクセスを制限するために適切に配置されている 物理的コントロールの充分性を評価する有効なプロセスを持っている • 侵入検知システムとウィルスコントロールシステム／手続が適切に配置している • 内外ネットワークの充分なペネトレーションテストがある • ネットワーク通信は仮想プライベートネットワーク(VPN)と適切で必要なら関連する暗号化技術を使用 して安全を確保している • 充分かつ強度のある暗号化アルゴリズムはネットワーク通信中のデータを保護するために選別されてい る 7.2.6 有無がレビューされるべき認証側面： • コントロール特徴は、新たな銀行ローン／預金口座を申込むためにインターネットを使う際に、見込み 客の識別を検証するのに適切に配置されている • コントロール特徴は既存顧客の認証・データインテグリティ・取引の機密性を確保するめにシステムに 組込まれている • 認証手続は、電子文書と、必要ならば電子署名を使って、一意かつ積極的に取引相手を識別するために 使われる • 否認不可は、将来起こり得るビジネスや取引がインターネットバンキングシステムを使ってなされる法的 使用のために確保されている • インタネーットバンキングシステムの耐不正特徴はシステムの性格・量・重要性に相応している 7.2.7 有無がレビューされるべきサードパーティサービスプロバイダの側面： • 能力と財政力の精査レビューはサードパーティサービスプロバイダとの契約締結前に実施されている • サードパーティサービスプロバイダとの契約は銀行と銀行の顧客の利益と、銀行組織が、どの組織の責 任も適切に識別・定義付けされていることを確実にするために納入業者契約をレビューしたかどうかを 保護している 160 G24 インターネットバンキング • 銀行組織は、納入業者管理システムや情報システムと技術に関連する特定の納入業者との関係、と外 部委託されたシステムと運用全部が、リスク管理・セキュリティ・銀行の固有の基準に合致する個人情 報保護ポリシに従属しているかどうかを評価しながら、サードパーティプロバイダの内外監査報告書を 取得し、レビューしている • 銀行組織は、セキュリティ・内部統制・サードパーティプロバイダの事業継続・緊急事態対応計画の独立 したレビュー／監査を行う権利を有している • サードパーティのセキュリティ手続は、インターネットバンキング策がインターネットプロバイダ(ISP)，認 証局(CA)、登録局(RA)、ウェッブ管理／保管会社のようなサードパーティサービスプロバイダに依存す る場合、適切かつ充分である • サードパーティサービスプロバイダは、重要なインターネットバンキングプロセス／サービス提供システ ムが適切に配置され、定期的にテストされ、銀行がテスト結果報告書を受領しているかどうか、の適切な 事業継続、緊急事態対応計画を持っている • 銀行は、納入業者により保守されているソフトウェアがソフトウェアエスクロー契約下にあり、銀行が納 入業者からソフトウェア製品を取得する場合、そのソフトウェアが定期的に最新であると確認されるとい うことを確実にする充分なプロセスを持っている • サードパーティの意見は、開発・設定されるセキュリティアーキテクチャ施策を評価するためのインター ネットアプリケーションの実装前段階で求めらている 7.2.8 必要であり、銀行と合意された場合、外部専門家の情報とアドバイスは、データの収集・分析・解釈に合わ せ使用されるべきである。 7.2.9 推論と勧告は、目標分析とデータ解釈に基づくべきである。 7.2.10 適切な監査証跡は、勧告された是正措置同様、収集されたデータ・なされた分析・到達した結論のために 維持・保護されるべきである。 7.2.11 報告書完成前に、観察と勧告が、必要なら、利害関係者・取締役会・銀行のマネジメントと確認されるべき である。 8 報告 8.1 報告内容 8.1.2 情報システム監査人は、使用技術・想定リスク・リスク管理方法に関する、定期報告を受領すべきである。 モニタリングシステムパフォーマンスは主要成功要因である。そのカバー範囲により、実施されるインター ネットバンキングレビューに関する報告書は必要に応じ、次のものに取組むべきである。 • 範囲・目的・追従する方法論・前提条件 • 短所の想定される効果同様、主要な長所と短所という意味でのインターネットバンキングプロセス／シ ステム施策の総合的な評価 • 重要な短所を克服し、インターネットバンキングプロセス／システムを改善する勧告 • 銀行法令への準拠の程度、および非準拠の影響に関する宣言 • COBIT情報要請規準への準拠の程度、および非準拠の影響に関する宣言 • 経験が同様な将来の施策や構想を改善するためのレビューの教訓の利用方法に関する勧告事項 161 G24 インターネットバンキング 9 適用開始日 9.1 本ガイドラインは、2003年8月1日以降に開始される全ての情報システム監査に適用される。 付録 COBITリファレンス 個々の監査範囲に適用可能であるCOBITの中から最も関連する材料の選択は、特定のCOBIT ITプロセ スを選択し、COBITのコントロール目標と関連するマネジメントの実行を勘案して行う。この特定の監査領 域、 『インターネットバンキングのレビュー』の場合、最も関連しそうなCOBITのプロセスは：選別されたIT プロセスの計画策定・組織化、選別されたITプロセスの導入と実装、選別されたサービス提供と支援、選 別されたモニタリングである。それ故、次のプロセスのCOBITの手引きが監査を実施する時考慮されるべ きである： • PO1 IT戦略計画の策定 • PO3 技術指針の決定 • PO8 外部要求との整合 • PO9 リスク評価 • AI2 アプリケーションソフトウェアの調達と保守 • AI3 技術インフラストラクチャの調達と保守 • AI4 開発・保守手続 • AI5 システムインスト－ル・認可 • AI6 変更管理 • DS1 サービスレベルの定義と管理 • DS2 サードパーティのサービスの管理 • DS3 性能とキャパシティの管理 • DS4 継続的なサービスの保証 • DS5 システムセキュリティの保証 • DS8 顧客支援とアドバイス • DS10 問題管理 • DS11 データ管理 • M1 プロセスモニタリング • M2 内部統制の充分性の評価 インターネットバンキング監査に最も関連性の高い情報要請規準： • 主：機密性・インテグリティ・法令遵守・信頼性 • 副：有効性・効率性。 参照 インターネットバンキング入門、シカゴ連邦貯蓄銀行、米国 バーゼル指令82、電子バンキングのリスク管理原理、銀行監督に関するバーゼル委員会、2001年8月、スイス バーゼル指令86、運用リスクの管理監督の健全な慣行、銀行監督に関するバーゼル委員会、2001年5月、 スイス バーゼル指令91、電子バンキングのリスク管理原理、銀行監督に関するバーゼル委員会、2002年7月、スイス BIS文書 7. 電子金融：新たな将来像と挑戦、金融経済部、国際決済銀行、2001年11月、スイス 162 G24 インターネットバンキング クローニン、メアリ J、インターネット上のバンキングと金融、ジョン ウィリ＆サン、ISBN 0 -47129219-2、米国 エッシンガ、ジェームス、仮想銀行サービス革命、トムソンビジネス新聞、ISBN 1-86152-343-2、英国 インターネットバンキング検査官の手引き、ナショナル銀行の貨幣行政官の検査官、1999年10月、米国 フルスト、カレン、ウィリアムW. ラング、ダニエルE. ノーレ、インターネットバンキング：開発と見込、経済と 方針分析調書2000-9、通貨検査官事務所、2000年9月、米国 インターネットとナショナル銀行憲章、ナショナル銀行の通貨行政官の検査官、2001年1月、米国 英国にアクセス可能であるが、英国内の投資家を意図していない海外インターネットワールドワイドウェッ ブサイトの材料取扱い、金融サービス局、英国 163 G25 仮想プライベートネットワークのレビュー 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 165 2 仮想プライベートネットワーク (VPN)‥ ‥‥‥‥‥‥‥‥‥‥‥‥ 166 3 VPN 関連リスク‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 168 4 綱領‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 170 5 独立性‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 170 6 能力‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 170 7 計画‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 171 8 VPN レビューのパフォーマンス‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 171 9 報告書‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 175 10 フォローアップ‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 175 11 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 175 G25 仮想プライベートネットワークのレビュー 1 背景 1.1 基準との関連 1.1.1 基準S6『監査作業のパフォーマンス』は、 「監査過程において、情報システム監査人は監査目的を達成す るに、充分、信頼性のある、関連性付けられた証拠を入手すべきである。監査発見事項および結論は、こ の証拠の適切な分析や解釈によって立証されることになっている。」と述べている。 1.1.2 ガイドラインG16『企業のITコントロールに関わるサードパーティの影響』は手引きを提供している。 1.1.3 ガイドラインG17『IT監査・保証の専門家の独立性に対する非監査業務の影響』は手引きを提供している。 1.2 COBITとの関連 1.2.1 COBITフレームワークは、 「企業の全資産を守ることは経営陣の責任である。期待を達成するためと同様、 この責任を果たすために、経営陣は内部統制の適切なシステムを確立しなければならない。」と述べてい る。 1.2.2 COBITマネジメントガイドラインがマネジメント志向のフレームワークを提供している継続的かつ事前対応 のコントロールセルフアセスメントが特別に焦点を当てているのは、 • パフォーマンス測定。IT部門がビジネス要件をいかに上手く支援しているか？ • ITコントロールプロファイリング。いかなるITプロセスが重要であるか？コントロールのための重要成功 要因は何か？ • 認識。何が目的を達成しないリスクか？ • ベンチマーキング。他人は何をしているか？結果は、どのように測定し、比較することができるか？ 1.2.3 マネジメントガイドラインは、ビジネス用語でITパフォーマンスの評価を可能にする例となる測定基準を提 供している。重要目標達成指標は、ITプロセスのパフォーマンスを識別・測定し、主要業績評価指標は、プ ロセスを稼働させるものを測定することにより、プロセスがどれだけ上手く効果をあげているかを評価する。 成熟度モデルと成熟度属性は、 マネジメントがコントロール能力を測定し、コントロールギャップと改善戦 略を識別するのを助け、能力評価とベンチマーキングを提供する。 1.2.4 マネジメントガイドラインは、自己評価ワークショップを支援するために使用することができ、また、ITガバ ナンスのスキームの一部として継続的なモニタリングと改善手続きを管理することによって、実装を支援す るために使用することができる。 1.2.5 COBITは、情報システム管理環境のためのコントロールと管理技法の詳細な組合せを提供する。個々の監 査範囲に適用可能であるCOBITの中から最も関連する材料の選定は、特定のCOBIT ITプロセスおよび COBITの情報要請規準の勘案の選択に基づいている。 1.2.6 本文書の付録にあるCOBITの参照は、本手引きによって言及されている領域をレビューする際に、特定の 目的と考慮すべきCOBITのプロセスを提供する。 1.3 ガイドラインに必要なもの 1.3.1 本ガイドラインの目的は、関連する情報システム監査基準がレビュー過程で遵守されるように、仮想プライ ベートネットワーク(VPN)実施のレビューを実施する際に、推奨さるべき実践を説明することになっている。 165 G25 仮想プライベートネットワークのレビュー 2 仮想プライベートネットワーク(VPN) 2.1 定義 2.1.1 仮想プライベートネットワーク網。ITガバナンス協会が出版している、ネットワークセキュリティの新しい問 題は、VPNを「インターネットやネットワークサービスプロバイダ（NSPs)が提供するネットワークのような 公共または共用ネットワークを通して非公開の通信を伝送する仮想回線のネットワーク」と定義している。 本ガイドラインの目的のため、VPNのこの定義が使用される。 2.1.2 VPNの関連文脈では、用語"トンネル"と"トンネリング"がしばしば使用される。データが別の方法でデータ を送信しないという経路経由で転送できるように、ある型のパケットを別のパケット型にカプセル化する プロセスは、トンネリングと呼ばれている。カプセル化されたパケットがインターネットVPNの中で経由す る経路はトンネルと呼ばれる。 2.2 VPNモデル 2.2.1 3つの一般的なVPN展開モデルがある。モデル間の主な違いは、そのサービスやトンネルの終端、必要な 管理水準、サービスの品質、および直接サービスプロバイダの関与への依存にある。3つの最も一般的な モデルは、 • 純粋プロバイダモデル • ハイブリッドプロバイダモデル • ユーザモデル 2.2.2 純粋プロバイダモデルでは、たいていのVPN機能はサービスプロバイダのインフラに組込まれ、組織の ネットワークにはない。このモデルは、多くの場合、１サービスプロバイダのネットワーク上で展開される。 組織のネットワークとサービスプロバイダのネットワークとの間に区別の明確な線がある。組織のネット ワークへのリモートアクセスは、通常、専用の回線（例えばT1、T3など）、ATM接続または専用のフレーム リレー接続によって提供される。顧客がネットワーク内のリモートアクセスVPN関連機器およびソフトウェ アを所有運営し、サービスプロバイダが、物理的な回路の出力から、サービスプロバイダのネットワーク内 の機器とソフトウェアを、所有運営している。サービスプロバイダは、ネットワークの終端からのVPNトンネ ルを開始し、セキュリティに関して両端にある専用回線に依存する。このモデルでは、サービスプロバイダ はネットワーク上に高度なコントロールを有し、キャパシティプランニング、設計、設定、診断およびトラブ ルシューティングに責任を持っている。 2.2.3 ハイブリッドプロバイダモデルは、サービスプロバイダと組織との両方のネットワークが含まれる。VPNト ンネルは、サービスプロバイダのネットワーク内部から開始され、トンネルは、組織のネットワークで終了す る。このモデルでは、サービスプロバイダは、ユーザが認証された後、リモートユーザ用のVPNトンネルの 開始に責任がある。リモートユーザが組織のネットワークに到達すると、2番目の認証は、プライベートネッ トワークへのアクセス権を許可される前に2番目の認証が必要となる場合がある。ユーザは、一旦認証され るや、あたかも直接企業のLANに接続されているかのように、ネットワーク設備にアクセスできる。 2.2.4 ユーザモデルでは、サービスプロバイダは、VPNデータの伝送としてのみ奉仕する。サービスの終端または トンネリングは、デスクトップの場合もあろうし、複数のデスクトップのためのプロキシとして機能するVPN 装置の場合もあろう。両方のサービス終端は、サービスプロバイダのネットワーク外にある。このモデルは、 リモートアクセス、即ち、複数サイトへの接続に使用され得る。 166 G25 仮想プライベートネットワークのレビュー 2.3 VPN使用 2.3.1 使用されるモデルに応じて、VPNを使用するために様々な方法がある。最も一般的なのは、 • サイト間、接続可能性 • リモートアクセス接続可能性 • 拡張企業エクストラネット接続可能性 2.3.2 サイト間、接続可能性は、効果的に大規模なイントラネットを形成し、安全に接続するための独立したイン トラネットを提供する。サイト間VPNは、多くの場合、単一の論理ネットワークを作成する地理的に分散し た組織により使用される。 2.3.3 リモートアクセス接続可能性は、モバイル使用の従業員が、保護されたネットワーク通信を使用して、イン ターネット経由で、組織のイントラネットにアクセスするのを許可する。これは、グローバルダイヤルアップ、 無線、ブロードバンドインターネットサービスプロバイダと組み合わせて使用される。多くの組織では、従業 員に低コストのネットワークアクセス可能性を提供するためにリモートアクセスVPNを使用している。 2.3.4 拡張企業エクストラネット接続可能性は、企業外部のネットワークへの接続を提供する。ビジネス、研究、 マーケティングの共同経営者達は、多くの場合、保護された接続を通して通信を高速化するためにこれら を使用している。一般的に、エクストラネットは、ネットワーク間の伝送クを、適切に許可、管理、モニタリン グする、より強力なコントロールを持っている、そして、内部ネットワークはファイアウォールを経由してエク ストラネットから保護されることもある。 2.4 VPNアークテクチャ 2.4.1 VPNをインストールするには、沢山の選択肢がある。ネットワークサービスプロバイダから提供されたVPN は、インターネットに組織を接続する最も一般的な手法の一つである。すべての組織でのVPNアークテク チャは、以下のどれかか、その組合わせであろう。 • ファイアウォールVPN • ルータVPN • リモートアクセスVPN • ハードウェア（ブラックボックス）VPN • ソフトウェアVPN 2.4.2 ファイアウォールVPNは、最も一般的な実装形式である。たいていの組織がすでにインターネットに接続 するためにファイアウォールを使っているので、暗号化ソフトウェアとある種の認証ソフトウェアを追加す る必要がある。 2.4.3 2種類のルータVPNがある。ひとつは、ルータが暗号生成を許可するようにソフトウェアが追加されている。 第二の型では、外部納入業者が提供する外部カードは、ルータのCPUから暗号化プロセスをカードに落 とし込むルータと同じ筺体に挿入されねばならない。 2.4.4 リモートアクセスVPNでは、遠隔地の人、暗号化されたパケットストリームや、組織のネットワーク機器へ のトンネルを生成することができる。 2.4.5 ハードウェア（ブラックボックス）VPNでは、VPNを生成するために、納入業者が、ブラックボックス、即ち、 暗号化ソフトウェアの入った機器を提供する。ブラックボックスVPN機器は、普通は、データを保護する ためにファイアウォールの背後またはファイアウォールの側にあるが、実際にはVPNシステムは、ファイア ウォールから完全に独立している可能性がある。 2.4.6 ソフトウェアVPNの中では、ソフトウェアは別のクライアントへのトンネリングやパケットの暗号化を処理 する。ソフトウェアは、クライアントとサーバに搭載される。通信は、組織内の特定のクライアントから開始 し、遠隔サイトにあるサーバへの接続を行う。クライアントから送信される通信は暗号化またはカプセル化 され、その宛先に仕向けられる。同じことが内部ネットワークに接続しようとしている人のために適用される。 167 G25 仮想プライベートネットワークのレビュー 2.5 VPN設定／トポロジ 2.5.1 VPNを設定する場合、パラメータは、鍵長、認証サーバ、接続タイムアウトとアイドルタイムアウト、証明書 の生成と鍵の生成、および配布メカニズムを設定しなければならない。VPNアークテクチャを設定、実装 し、VPNトポロジのアークテクチャを配置するための数多くの方法がある。組織は、VPN設定において、次の もっともよく使用されるトポロジのひとつか組合せを使用するだろう。 • ファイアウォール／クライアント間 • LAN同士 • ファイアウォール／イントラネット・エクストラネット間 • ハードウェア／ソフトウェアVPN 2.5.2 ファイアウォール／クライアント間は、最も一般的に使用されるトポロジであり、それは内部ネットワークに ダイヤルインするリモートユーザに適用される。 2.5.3 LAN同士は、2番目によく使用されるトポロジである。それは、VPNトンネルが2サイト間で生成されると、 ファイアウォール／クライアント間トポロジを、別の遠隔事務所と事務所同士、共同経営者、納入者へと拡 張する。 2.5.4 ファイアウォール／イントラネット・エクストラネット間トポロジでは、イントラネットは従業員に使用され、エ クストラネットは顧客、共同経営者、納入者により外部で使用される。リモートユーザがエクストラネットや イントラネット上のサーバにアクセスしようとする時、そのサーバにアクセスできるかを決定しなければなら ない。 2.5.5 ハードウェア／ソフトウェアVPNは、VPN技術のアルゴリズムを実装するために設計された独立機器であ る。VPN機器は、通常内部ネットワーク上のファイアウォールの背後にある。データパケットはファイア ウォールとVPN機器を通して流れる。パケットがこれらの機器を通過する際、暗号化され得る。一般的に SSLプロトコルのようなソフトウェア暗号化モデルでは、特殊な機器（認証）が必要とされておらず、パケッ トの流れはソフトウェアによって暗号化される。 2.5.6 VPN技術やプロトコルに入っているのは、 • PPTP（拠点間トンネリングプロトコル） • L2TP（レイヤ2トンネリングプロトコル） • IPSecの（インターネットプロトコルセキュリティ） • SSL（セキュアソケットレイヤー） 3 VPN関連リスク 3.1 リスク型 3.1.1 VPNは外部のサービスを使用する事業にとっての通信インフラなので、VPNに関連するリスクが分類され うるのは、 • セキュリティリスク • 外部業者リスク • 事業リスク • 実装リスク • 運営リスク 168 G25 仮想プライベートネットワークのレビュー 3.2 セキュリティと法務リスク 3.2.1 VPNに関連するセキュリティリスクは、 • セキュリティの不充分な評価とVPN使用から生じる法的リスク • VPNから生じる情報資産に対するリスクを軽減するに不充分なセキュリティプログラム • VPN進入前、VPN離脱点到着時のデータの不充分な保護 • 指定されたネットワークパ経路（暗号化装置の前の内部ネットワークや復号装置の後の外部ネットワー ク）上で暗号化されない間の情報保護失敗 • 機密性、インテグリティ、否認防止、可用性の問題に帰結し得る実装の欠如 3.3 外部業者リスク 3.3.1 外部サービスプロバイダへの依存がリスクとなり得るのは、 • 不適切なサービスプロバイダの選択 • 不適切な関係管理 • サービスレベルアグリーメント（SLA）と測定基準の不備 • 不適切なガバナンスと管理プロセス • SLAと測定基準の不充分な測定とモニタリング • 不適切なバックアップ／冗長化戦略 • 関係やサービスの不充分なベンチマーク • VPN上のデータへのアクセス乱用 3.4 ビジネスリスク 3.4.1 経営やビジネスの期待の不履行につながる可能性があるリスクは、 • ビジネス戦略との不充分な連携 • 不適切なコスト削減 • セキュリティ要件の達成失敗 • 不充分な使いやすさ • ユーザニーズの範囲および期間への対応失敗 • 組織やプロセスの他分野のサービスの欠如／低下 3.5 実装リスク 3.5.1 効果がないと非効率的な施策の実装につながる可能性があるリスクは、 • 率直な設計への不充分な注意と投資 • 組織にとってVPNモデルの不適切な選択 • 適切な第三者の不充分な使用 • セキュリティ設計への不充分な注意 • 不適切な復旧プロセス • サービスレベルの期待と測定の設計失敗 • 不適切な統合戦略 • 効果のない変更、プロジェクトまたは実装管理プロセス • VPNクライアントリスク（同じインターフェイスがインターネットとVPN伝送を受け入れる） 169 G25 仮想プライベートネットワークのレビュー 3.6 運用リスク 3.6.1 VPNの効果がなく非効率的な利用/運用に帰結するようなリスクは、 • 効果的に運用するために不充分な資源 • 信頼性の欠如 • サービス品質の悪化 • 相互運用性の欠如 • カプセル化失敗 • 不充分な能力 • 冗長性やバックアップ提供失敗 • ビジネス目的のために個人的な機器（家庭用コンピューティング）使用（セキュリティ設定、ウイルス対 策ソフトウェア、パーソナルファイアウォールの欠如） • オペレーションパラメータやデータに関する機密性欠如 4 綱領 4.1 権限 4.1.1 VPNレビューを開始する前に、情報システム監査人は、想定レビューを実施するために、情報システム監 査人の立場や組織が提供する必要な権限書により必要な権限の合理的な保証を提供するべきである。レ ビューが、組織によって開始される場合には、情報システム監査人はまた、組織がレビューを任命する適切 な権限を持っているという合理的な保証を得るべきである。 5 独立性 5.1 専門家としての客観性 5.1.1 業務を受入れる前に、情報システム監査人は、VPN施策のレビューにおける情報システム監査人の利益は、 レビューの客観性を損なうことでは決してないという合理的保証を提供すべきである。いかなる利益相反 の場合でも、それははっきりと組織に伝達されるべきであり、業務受け入れ前に利益相反に関する組織の 認識を書面で取得すべきである。 5.1.2 情報システム監査人がVPNレビューで非監査業務を果たす、あるいは果たした場合は、情報システム監査 人はガイドラインG17『IT監査・保証の専門家の独立性に対する非監査業務の影響』を考慮すべきである。 6 能力 6.1 技量と知識 6.1.1 情報システムは監査人、VPNをレビューするに当たり、必要な技術的知識の合理的な保証を提供すべきで ある。組織内のVPNの実装をレビューする際には、ビジネス要件およびVPNの技術的側面の明確な理解 が必要である。 6.1.2 情報システム監査人はまた、VPNのレビューを実施するために関連する技術的な技量と知識へのアクセス の合理的な保証を提供すべきである。VPNのレビューは、使用されている暗号化技術、ネットワークセキュ リティアークテクチャ、セキュリティ技術のような側面を評価するに相応しい技術的知識を呼び出す。情報 システム監査人は、これらの側面をレビューするに充分な知識を持っているべきである。専門家の入力が必 要な場合、適切な入力は、外部の専門的な資源から入手されるべきである。外部専門家の資源が使用され るという事実は、書面で組織に伝達されるべきである。 170 G25 仮想プライベートネットワークのレビュー 7 計画 7.1 高度リスク評価 7.1.1 情報システム監査人は高度リスク評価を実施するためにビジネスおよびVPNのためのビジネス要件に関す る情報を収集すべきである。 7.1.2 セクション3で参照されるVPNに関連するリスクは、設計中（実装前）、実装段階または実装後のように、 レビューが実施されている段階に応じて考慮されるべきである。 7.1.3 レビューされ、確認される必要がある、関連するCOBIT情報要請規準である、有効性、効率性、機密性、イ ンテグリティ、可用性、コンプライアンス、信頼性は識別されるべきである。 7.1.4 これらは、VPNが支持するようなネットワーク中心の環境へのCOBIT基準の拡張であるので、ネット中心 技術（CONCT）のコントロール目標の関連側面も、この文脈において考慮されるべきである。 7.1.5 この高度リスク評価は、レビュー範囲と期間を決定するのに役立つ。 7.2 レビュー範囲と期間 7.2.1 情報システム監査人は適切な組織と協議して、VPNのレビュー範囲と目的を明確に定義すべきである。レ ビューとされる側面は、範囲の一部として明示的に記述されるべきである。セクション7.1.1で参照される高 度リスク評価は、レビューされるべき側面、レビューの程度と深さを指示することになる。 7.2.2 レビュー目的のために、施策の利害関係者も識別され、組織と合意する必要がある。 7.2.3 利害関係者のいかなる主要懸案事項についても、レビュー範囲と目標に、必要に応じて、含まれるべきで ある。 7.2.4 レビュー範囲が第三者プロバイダを含む場合は、情報システム監査人は監査条項が契約に入っていたとい うことを確認しなければならない。 7.3 アプローチ 7.3.1 情報システム監査人は、レビュー範囲と目的が客観的かつ専門的な方法で履行され得るような方法でアプ ローチを策定すべきである。次のアプローチは、レビューが実装前であるか、実装段階または実装後である かどうかによるべきである。アプローチは適切に文書化されるべきである。外部専門家の入力が使われる 時期と場所は、アプローチの一部として特定されるべきである。テスト/モニタリングツールの計画的な使 用もまた、アプローチの一部として記述されるべきである。 7.4 計画のためのサインオフ 7.4.1 組織的な慣習に応じて、情報システム監査人は、計画とアプローチのための組織の同意を得てもよい。 8 VPNレビューのパフォーマンス 8.1 一般 8.1.1 本節は、VPNレビュー実行中に対処すべき側面に幅広く対応している。特定のVPNレビューについては、 レビューの予想される範囲と目的に応じて、レビューに関連する側面が、この幅広い側面から識別されるべ きである。 8.1.2 VPNレビューは、 （必要に応じて微調整付きで）定義されたアプローチごとに実施されるべきであるので、 レビューの想定目標が履行される。 171 G25 仮想プライベートネットワークのレビュー 8.1.3 一般的には、入手可能な文書（例えば、ビジネス事例、システム文書、契約書、サービスレベルアグリーメン ト、ログ）の研究、利害関係者やサービスプロバイダとの討議、観察は、データ収集、分析、解釈に当たり 適切に使用されるべきである。必要に応じて、情報システム監査人は、プロセス/機能が意図したとおりに 実行されていることを実証するために、VPN環境の重要なプロセス/機能をテストすべきである。 8.1.4 必要に応じ、組織と合意され、外部専門家の入力は、データの収集、分析、解釈にうまく使用され得る。 8.1.5 推論と勧告は、データの客観的分析と解釈に基づくべきである。 8.1.6 適切な監査証跡は、収集されたデータ、実施された分析、到達した推論、推奨された是正処置のために保 持されるべきである。 8.2 実装前レビュー 8.2.1 VPN施策が実装（設計段階）される前に実施されるべき、実装前レビューが対処すべき妥当性は、 • VPN施策の要件 • 提案された施策の費用便益 • VPNモデル、VPNアークテクチャ、VPNの設定/トポロジ、VPN使用状況のような提案されたVPN技術 • 提案された暗号化技術を含む、提案されたセキュリティアークテクチャと特徴 • 計画された冗長性とバックアップ施設 • マネジメントの承認 • 提案されたプロジェクト管理構造とモニタリング機構 • サービスプロバイダ選択のための選定プロセス • 提案された契約、SLAと測定基準 • 履行されるべき法的要求 8.2.2 これら側面に対処するために、情報システム監査人がなすべきなことは、 • VPN要件の検討。技術面同様ビジネス面も • ビジネス事例（費用と便益）とその承認の検討 • 技術的側面を概説したVPN設計文書のレビュー • 提案された施策が、PPTP、L2TPとIPSecプロトコルのいずれかに適合するかどうかのレビュー • 提案されたセキュリティアークテクチャと暗号化技術のレビュー • 代替案の技術的、商業的評価とサービスプロバイダの究極の選択を含む入札プロセスのレビュー • 提案されたプロジェクト管理体制の検討 • 提案された契約、SLAと測定基準の検討 • 履行されるべき法的要求の検討 • 提案された冗長性とバックアップの評価 • アプリケーションを使ったVPNを統合するために提案された戦略のレビュー • 技術とセキュリティの側面の妥当性を評価するための、必要に応じた外部専門家の使用 • 提案された訓練計画の検討 • 関連するすべてのレビュー報告書の検討 • セキュリティリスク、第三者リスク、ビジネスリスク、実装リスク、運用リスク、リスク軽減の妥当性と同様、 適切性に関連して上記の結果の評価 • COBITとCONCT基準が履行されている方法の評価 • 必要な是正処置のレビューから生じるリスクや問題の強調表示 172 G25 仮想プライベートネットワークのレビュー 8.3 実装レビュー 8.3.1 実装レビューが、実装中に発生し、それに応じて、対処すべきことは、 • 実装は、承認された計画ごとに、合意された時間枠と費用内で進んでいる • VPN技術。VPNモデル、VPNアークテクチャ、VPN設定/トポロジ、VPN使用、が意図したとおりに実装 されている • セキュリティ方式と使用される暗号化技術は強固であり、設計通りである • 計画的な冗長性とバックアップ機能が実装されている • 実際の契約、SLAと測定基準が、組織の要件に対処する • 法定要件は、もしあれば、対処される 8.3.2 上記参照される側面に対処すべく、情報システム監査人がなすべきことは、 • プロジェクト進捗報告と議事録の検討 • 計画に対する技術の実際の実装を評価し、もしあれば、逸脱を識別 • 施策がPPTP、L2TPとIPSecのプロトコルのいずれかに適合していることが認定されているかどうかの 確認 • 承認された設計に適合すべく実装された実際のセキュリティアークテクチャと暗号化技術の評価 • 合意された、実際の契約、SLA、測定基準の検討 • 確立された冗長性とバックアップの評価 • アプリケーションを使ったVPNの実際の統合レビュー • 実際に実装された技術とセキュリティ側面の妥当性を評価するために、必要に応じた、外部専門家の使用 • 彼らがあらゆるユーザに対応し、適切な方法で、容量、帯域幅、アクセス制御や暗号化などをカバーする かどうかを評価するための、テストと移行のプロセスの妥当性の評価 • 組込み中の課金の仕組みの評価 • 旧システムとの接続が外されているか、課金が継続していないか、VPNの実装に従い設備が配置されて いるかどうかの評価 • 早期に推奨されたリスク軽減処置が実装されているかどうかを評価する為に、あれば早期実装前監査 報告と、その他関連するレビュー報告の検討 • セキュリティリスク、第三者リスク、ビジネスリスク、実装リスク、運用リスク、リスク軽減の妥当性と同様、 適切性に関連して上記の結果の評価 • COBITとCONCT基準が履行される方法の評価 • 必要な是正処置のレビューから生じるリスクと問題の強調表示 173 G25 仮想プライベートネットワークのレビュー 8.4 実装後レビュー 8.4.1 実装後レビューはVPN実装後に発生する。従って対処すべきことは、 • 想定される利点が達成されているかどうか • 1回のコストは、計画通りでかつ合理的かどうか • 継続的な請求額が合理的であり、合意通りかどうか • VPN技術は意図通り使用されているかどうか • VPNとその使用は、データ分類を含み、セキュリティ方針と手続きに適合しているかどうか • エクストラネットを経由してVPNにアクセスする第三者は、関連するセキュリティと機密保持契約に署名 し、遵守しているかどうか • リモート接続を通してアクセスし、ラップトップを使用するユーザは、適切な場合、クライアント実装の ファイアウォールを含め必要なセキュリティ機能を使用しているかどうか • デジタル証明書の管理のための適切なプロセスがあるかどうか • サービスの品質（QoS）を含むSLAと測定基準は、時宜を得た処置にとり、定期的に測定され、モニタリ ングされ、拡大されているかどうか • データは、適切な手続きを使用する暗号化されていないリンク上と同様、入口と出口で充分に保護され ているかどうか • 適切なセキュリティツールとプロセスは、ウイルスチェックと侵入検知のようなもののための場所にある かどうか • サービスと費用は同種であり、競争力があるかどうか • 冗長性とバックアップ施設は適切に機能しているかどうか • 法定要件は、もしあれば、対処されているかどうか 8.4.2 上記参照される側面に対処するために、情報システム監査人がなすべきことは、 • プロジェクト完了報告書の検討 • 承認された設計との適合性について、実際に使用されているVPN技術のレビュー • 施策がPPTP、L2TPとIPSecのプロトコルのいずれかに適合していることが認定されているかどうかの確認 • サンプルに基づく継続的な請求額のレビュー • セキュリティ方針と手続きの遵守に関するサンプルチェックの実施 • エクストラネットでのアクセスに関して、第三者により署名された協定と同様、第三者アクセスのチェック。 • 適切なセキュリティ設定のためのラップトップ同様、リモートおよびラップトップのアクセスのプロセス のチェック • 実際のSLAとQoSを含む測定基準とそれらをモニタリングする実際のプロセスのレビュー • ネットワーク全体のセキュリティの実装の確認 • バックアップと冗長機能のテスト • 料金とサービス品質の継続的合理性の合理的な保証を提供するための定期的なベンチマーキング実施 • 有効な技術とセキュリティ側面の妥当性を評価するための、必要に応じた、外部専門家の使用 • VPN施策の関連する側面をテストするための適切なツール使用 • VPNをサポートするヘルプデスクプロセスのレビュー • セキュリティリスク、第三者リスク、ビジネスリスク、実装リスク、運用リスクといった、リスク軽減の妥当 性同様、適切性に関して上記結果の評価 • COBITとCONCT基準が履行される方法の評価 • 必要な是正処置のレビューから生じるリスクと問題の強調表示 174 G25 仮想プライベートネットワークのレビュー 9 報告書 9.1 報告内容 9.11 VPNレビューに関する報告は、その対象範囲に応じて、対処すべき側面は、 • 適用範囲、目的、追従する方法論、前提条件 • 短所の想定される効果同様、重要な長所と短所という意味での施策の総合的な評価 • 重大な弱点を克服し、施策を改善させるための推奨事項 • COBIT情報要請規準とCONCT基準への準拠の程度、および非準拠の影響 • 経験が同様な将来の施策や取組みを改善するのに使用され得る方法に関する推奨事項 9.1.2 観察と推奨事項は、報告を完成する前に、適切ならば利害関係者と組織とともに検証されるべきである。 10 フォローアップ 10.1 同意された追跡処置 10.1.1 VPNレビューの最後に同意される処置は、締切日を割当て、完了のため追跡されるべきである。未解決の 問題は、必要な処置のための適切な管理まで拡大されるべきである。 11 適用開始日 11.1 本ガイドラインは、2004年7月1日以降に開始される全ての情報システム監査に適用される。 付録 COBIT参照 個々の監査範囲に適用可能であるCOBITの中から最も関連する材料の選択は、特定のCOBIT ITプロセ スを選択し、COBITのコントロール目標と関連するマネジメントの実行を勘案して行う。 VPN、通信インフラでは、以下の側面がより関連している。 • PO1 IT戦略計画の策定 • PO3 技術手引きの決定 • PO5 IT投資の管理 • PO8 外部要件への準拠 • PO9 リスク評価 • PO10 プロジェクト管理 • A13 技術インフラストラクチャの調達と保守 • AI4 運用と利用の促進 • AI5 システムのインストールと認定 • AI6 変更管理 • DS1 サービスレベルの定義と管理 • DS2 サードパーティのサービスの管理 • DS3 性能とキャパシティの管理継続的なサービスの保証 • DS4 継続的サービスの保証 175 G25 仮想プライベートネットワークのレビュー • DS5 システムセキュリティの保証 • DS9 構成管理 • DS12 設備管理 • DS13 オペレーション管理 • M1 プロセスモニタリング VPNレビューに最も関連する情報要請規準： • 主：可用性、機密性、有効性、インテグリティ • 副：効率性、コンプライアンス、信頼性 参照 仮想プライベートネットワーキング。ネットワークセキュリティのための新問題、ITガバナンス協会、米国、 2001年 ネット中心技術（CONCT）のコントロール目標、ITガバナンス協会、米国、1999年 176 G26 ビジネスプロセスリエンジニアリング（BPR） プロジェクトレビュー 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 178 2 ビジネスプロセスリエンジニアリングプロジェクト‥ ‥‥‥‥‥‥ 179 3 監査ポリシー‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 184 4 独立性‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 184 5 能力‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 185 6 計画策定‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 185 7 監査業務のパフォーマンス‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 186 8 報告‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 186 9 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 186 G26 ビジネスプロセスリエンジニアリング（BPR）プロジェクトレビュー 1 背景 1.1 基準との関連 1.1.1 基準S6『監査業務のパフォーマンス』は、 「監査の過程において、情報システム監査人は、監査の目的を 達成するために、十分かつ確実で関連性のある証拠を入手すべきである。監査の発見事項と監査の結論 は、この証拠を適切に分析し、解釈することにより裏付けられる。」と述べている。 1.1.2 ガイドラインG17『IT監査・保証の専門家の独立性に対する非監査業務の影響』は、ガイダンスを提供し ている。 1.1.3 ガイドラインG21『ERPシステムレビュー』は、ガイダンスを提供している。 1.2 COBITとの関連 1.2.1 COBITフレームワークは「企業のすべての財産を保全することはマネジメントの責任である。マネジメント は、この責任を果たし、また、その期待に応えるために、適切な内部統制の仕組みを確立しなければならな い。」と述べている。 1.2.2 COBITマネジメントガイドラインは、特に以下の事項に焦点を当てた継続的かつ事前対応のコントロール セルフアセスメントのためのマネジメント主導のフレームワークを提供している。 • パフォーマンス測定—IT部門がビジネス要件をどのくらい効果的にサポートしているか。 • ITコントロールプロファイリング—どのITプロセスが重要なのか。コントロールの重要成功要因は何か。 • 認識—目的を達成できないリスクは何か。 • ベンチマーク評価—他社の動向はどうなのか。結果をどのように測定し比較することができるのか。 1.2.3 マネジメントガイドラインは、IT成果の評価を可能にする、ビジネス用語での指標例を提供している。重要 目標達成指標は、ITプロセスの成果を把握・測定し、また、重要成果達成指標は、プロセスの成功要因を 測定することにより、プロセスがどのくらい効果的に実施されているのかを評価する。成熟度モデルおよび 成熟度属性は、能力評価とベンチマーク評価を可能とし、 マネジメントがコントロール能力を測定しコント ロールギャップと改善のための戦略を特定するために役立つ。 1.2.4 マネジメントガイドラインは、セルフ評価におけるワークショップをサポートするために、また、ITガバナンス 体系の一環としてのマネジメントによる継続的モニタリングおよび改善手続の実装をサポートするために 利用することができる。 1.2.5 COBITは、情報システム管理環境のための一連の詳細なコントロールおよびコントロール技法を提供して いる。個別の監査の範囲に適用すべき、最も関連したCOBITの文書は、特定のCOBITのITプロセスの選 択およびCOBITの情報要請規準の検討に基づいて選択する。 1.2.6 当ガイドラインの対象となる領域をレビューする際に検討すべきCOBITの特定の目標、あるいはプロセス は、COBITへの参照として、当ドキュメントの付録に記載している。 1.3 ガイドラインの必要性 1.3.1 製造組織およびサービス組織は、動的でかつ急速に変化するビジネス環境における自らの発展をサポー トするために、ビジネスプロセスリエンジニアリング（BPR）への関心を高めている。BPRは、大きなビジネ ス成果を挙げるための貴重な機会を提供する一方、例えば、リエンジニアリングの選択を誤る、考案された 変更を不適切に実装する場合にはリスクも招く。 178 G26 ビジネスプロセスリエンジニアリング（BPR）プロジェクトレビュー 1.3.2 リエンジニアリングは、ビジネスプロセスだけなく、 マネジメントと支援体制、スタッフィングと組織、技術 と情報システム、ポリシーと規制に対する、広範囲の変更を伴う。それは、BPRプロジェクトがBPRを導入 する組織のコントロールシステムに対して大きな影響を与えることを意味する。特に、必要不可欠なコント ロールがビジネス取引を効率的に処理するために設計し直され、プロセスに組み込まれなくなるリスクが 高まる。従って、情報システム監査人は、コントロールが、処理を遅延させているように見えるが、容易に管 理できない、あるいは発生可能性か影響度のいずれかを測定できないリスクを回避するために不可欠であ ることをよく理解し、 マネジメントを納得させるべきである。 1.3.3 当ガイドラインの目的は、特に情報システムの観点から、BPRプロジェクトに関連する主要な作業やリスク を評価するためのフレームワークとして、基本的なリエンジニアリングに関する論点を情報システム監査人 に提供することである。 2 ビジネスプロセスリエンジニアリングプロジェクト 2.1 定義 2.1.1 一般的に広く認められたビジネスプロセスリエンジニアリングの定義はないが、最も頻繁に引用される定 義はハマーとチャンピーによるものであり、 「コスト、品質、サービス、スピードのような重大で現代的なパ フォーマンス基準を劇的に改善するために、ビジネスプロセスを根本的に考え直し、抜本的にそれを再設 計すること。」である。¹ 2.1.2 BPRは、ビジネスプロセスの構造を大幅に見直し、また、ビジネスプロセスが管理、実行される方法を劇的 に変更することにより、ビジネスプロセスを改善することを目的としている。これにより、通常、関係者、作 業の実践方法や支援技術（特に情報技術）に対して多大な影響が及ぶ。 ¹ ハマー&チャンピー「リエンジニアリング革命」 （1993） 2.2 BPRの主要な成果 2.2.1 BPRプロジェクトは極めて広範囲にわたる。組織のすべてのプロセスや関係が大幅に変更される。BPRプ ロジェクトの主要な成果は、以下のように要約される。 • 戦略的な考え方 • 製品、サービスおよび収益性を改善する手段として、プロセスに重点を置いた（主要なビジネスプロセス の重視）、価値および顧客の要件に基づく（顧客主義、アウトプット重視）、新規ビジネスの優先順位 • 企業内外の要員を団結させ、動機付けることに対する新たなアプローチ • 商品やサービスの開発・生産・提供における技術の利用に対する新たなアプローチ • アウトソーシング、共同開発、速やかな対応、かんばん方式、サポートを含む再定義されたサプライヤー の役割 • クライアントおよび顧客を企業のビジネスプロセスにより直接的かつ積極的に関与させるための再定 義されたクライアントおよび顧客の役割 2.3 BPRの原則とアクティビティ 2.3.1 原則は、プロセスの構造を変更するために必要となる革新的な思考に役立つ。原則は、通常、BPRプロ ジェクトのうちで最も困難な段階、つまりはプロセス変更のための選択肢を検討する際に主として有用で ある。 179 G26 ビジネスプロセスリエンジニアリング（BPR）プロジェクトレビュー 2.3.2 ハマーが提唱するBPRの原則は、以下の通りである。 • 複数の仕事をひとつにまとめる • 従業員が意思決定を行う • プロセス内のステップを自然な順序で行う • プロセスには複数のパターンを用意する • 業務は最も適切と思われる場所で行う • チェックとコントロールを減らす（ただし、導入時のコントロールは重要である） • 調整は最小限に抑えられる • ケース・マネジャーが顧客との接点になる • 仕事の集権化と分権化を組み合わせると効果的である 2.3.3 カーターとハンドフィールドを含む他者は、BPRアクティビティを1）単純化（非付加価値アクティビティの 排除を含む）、2）標準化、3）統合化、4）並列化、5）差異管理、6）資源配分、7）自動化の順で実施すべ きであると提唱している。彼らは、BPRプロジェクトでは厳格な順序で1から7までのステップに取り組むべ きであると述べている。例えば、単純化を最初に検討することなく、ITアプリケーションを利用したプロセ スの自動化を行おうとすることは、単純化により自動化が不要となるかもしれないだけでなく、自動化の便 益を十分に享受できないかもしれないため、適切ではない。しかしながら、厳格な順序に固執し過ぎること は危険である。例えば、異なる資源を必要とする複数のアクティビティをひとりの個人により実施されるひ とつのアクティビティへ統合することは、自動化によってのみ可能となることもあるかもしれない。 2.3.4 広範囲な視野を持つことが最善のアプローチとなることがある。 2.4 BPRの方法論 2.4.1 リエンジニアリングは、本質的に極めて状況的かつ創造的である。一般的に、BPRに対する2つの異なる アプローチが文献において紹介されている。 2.4.2 ハマーとチャンピーにより最初に考案された方法論はトップダウンアプローチであり、BPRチームは現状の プロセスに固執せずにどのように組織の戦略目標を達成することができるのかを検討することに重点を置 くべきであると提唱している。将来のあるべきプロセスが強調され、それは著者が提起する変革の哲学と 一致している。 2.4.3 ハリントンによるより漸進的な変革の方法論はボトムアップアプローチであり、現状のプロセスを理解する ために現状のプロセスをモデル化し、その後、戦略目標を達成するために、それを適切に合理化することを 推奨している。現状のプロセスの改善機会を特定することにより、現状のプロセスを変更することに重点 を置いている。 2.4.4 実務においては、BPRチームは混成アプローチを採用する必要があるであろう。トップダウンの方法論を ベースとした場合においても、現状の機能性を理解し、現状のプロセスからあるべき将来のプロセスへの 移行パスを注意深く定義付ける必要がある。ボトムアップの方法論の場合においては、BPRチームは現 状のプロセスの詳細部分に多大な時間を費やし、革新的な思考を失うことがありうる。混成アプローチは、 チームが現状のプロセスの詳細部分に注力し過ぎることなく、高い視点での変革を検討することを促すで あろう。 2.4.5 BPRに関する初期研究においては、サブプロセスの改善に関する数多くのより詳細なプロジェクトが推奨 されているかもしれないが、それらは（おそらくいくつかのボトルネックを取り除くための）相対的に小さな 変更しかもたらさないことを認識しておくことは重要である。 180 G26 ビジネスプロセスリエンジニアリング（BPR）プロジェクトレビュー 2.5 複数のBPRの方法論における6つの基本ステップ 2.5.1 構想—この段階においては、通常、幹部経営層の支援を引き出すBPRプロジェクトの推進者の関与を伴 う。マネジメント層と企業のプロセスに精通した個人を含むタスクフォースは、企業の全体的なパフォーマ ンスを改善するために、ビジネス戦略とIT機会のレビューに基づき改善の対象となるビジネスプロセスを 選定する権限を与えられる。 2.5.2 開始—この段階においては、リエンジニアリングプロジェクトチームの立ち上げ、パフォーマンス目標の設 定、プロジェクト計画策定、利害関係者/従業員への通知と彼らの積極的な参加が含まれる。これは、ベン チマーク評価を用いたリエンジニアリング、外部顧客のニーズ把握や費用対効果分析のビジネスケースを 作成することによりしばしば実現される。 2.5.3 診断—この段階は、アクティビティ、資源、コミュニケーション、役割、情報システム、費用等のプロセスの 属性の観点における、現状のプロセスおよびそのサブプロセスの文書化として分類される。プロセスの要 件の特定および顧客への価値の割り当てを行う際に、問題の根本原因が表面化し、非付加価値アクティ ビティが特定される。 2.5.4 再設計—再設計段階においては、新プロセスの設計が行われる。これは、ブレインストーミングや創造技 術を通してプロセスの設計案を作成することにより実現される。新設計のプロセスは、戦略目標を満たし、 人材および情報システムアーキテクチャとも整合すべきである。通常、新プロセスの文書化とプロトタイピ ングが行われ、新プロセスを支援する新情報システムの設計が完了する。 2.5.5 再構築—この段階は、新プロセスにおける責任や人材の役割への円滑な移行を合理的に保証するために、 チェンジマネジメント技法に大きく依存する。この段階において、ITプラットフォームやシステムが実装され、 ユーザに対する研修や移行が行われる。 2.5.6 評価—BPRの方法論の最終段階においては、新プロセスが目標を達成しているかを判断するために、新 プロセスのモニタリングが必要となる。また、全社的品質管理プログラムとの連携を伴うこともある。 2.6 BPRツール 2.6.1 BPRリスクの減少に役立つ適切なBPRツールを利用することにより、BPRに取り組む組織は大きな便益 を享受することができる。現状の、あるいは新しいビジネスプロセスを前提とした場合、標準的なツールは、 モデル化、分析および評価、想定されるプロセスの行動のシミュレーションを支援する。 2.6.2 診断フェーズ（2.5.3）がパフォーマンス改善の機会や障害を特定する鍵と考えられているように、BPR ツールはBPRプロジェクトにおいて重要な役割を果たす。情報システム監査人によるBPRツールのレ ビューも行われるべきである。 2.7 BPRにおける情報システムの役割 2.7.1 情報システムは、ツールを提供し、BPRプロジェクトにおいて4つの異なる役割を果たす。 2.7.2 情報システムは新しいプロセスを可能とする。情報システムは、情報システムでなければ達成できない、革 新的なビジネスプロセスを考案するのに役立つかもしれない。情報システムは、BPR成功への鍵になりう る。ITの利用は、現代のITアプリケーションの出現以前から長く存在している業務プロセスに内在する仮 定に挑戦する。BPRは、情報システム管理に端を発するが、主としてビジネス主導であり、それは、顧客や 組織の他の関係者のニーズを満たすという観点から、広範囲な影響をもたらす。 2.7.3 ITツールはプロジェクト管理を容易にすることに役立つ。プロジェクト管理ツールは、プロセスの分析およ び新プロセスの定義付けに役立つ。それらは、プロセス指向のアプリケーションソフトウェアパッケージの 導入を定義するために利用することも可能である。 2.7.4 情報システムは、要員をより密接に連携させる。電子メール、グループウェア、ワークフロー管理、テレコン のような特別なソフトウェアシステムは、情報システムが担う広範囲の役割の要素である。 181 G26 ビジネスプロセスリエンジニアリング（BPR）プロジェクトレビュー 2.7.5 情報システムは、ビジネスの統合に役立つ。ビジネスのプロセス概観には、組織内およびビジネスパートナー 間におけるビジネスプロセスの統合が含まれる。ERPシステムは、BPRの導入プロセスに重きを置くことに より、全面的に統合され、リエンジニアリングのプロセスを強化するのに役立つ。 2.8 BPRプロジェクトのリスク 2.8.1 ビジネスプロセスが根本的に改善されることにより、顧客の要求が以前よりも満たされ、また、組織の業績 が劇的に改善されるかもしれない。しかしながら、劇的な改善には、リスクや高い失敗率が伴う。リエンジ ニアリングの便益は、いずれ必ず享受されるものではない。それは、BPRプロジェクトがライフサイクルにわ たって注意深くモニタリングされなければならないことを意味している。 2.8.2 変革プロセスの各ステップ（設計、導入、運用/展開）において、支援、範囲、組織文化、リーダーシップ、ス キル、人材およびマネジメントに関連する問題が生じることがある。種類ごとの問題例は、以下のように要 約される。 2.8.3 設計リスクには、以下の論点が含まれる。 • 支援に関する論点 –– 不十分なCEOの協力 –– 不十分な幹部経営層の関与 –– マネジメントの懐疑心 –– 指揮する経営幹部の不適切性 –– 設計チームメンバーの不適切性 –– 重要性の不十分な周知 • 範囲に関する論点 –– 戦略的構想との非関連 –– 狭過ぎる、あるいは曖昧過ぎる範囲 –– 聖域に対する執着 –– 既存の仕事に対する執着 –– 分析機能の麻痺 • スキルに関する論点 –– 新しいアイディアへの不十分な探究心 –– 独創的な思考の欠如 –– 新しいアイディアに対する了見の狭さ –– 設計上の誤解 –– 組織に合わない文化の変化 –– 人材の問題に対する不十分な検討 –– 能力を超えた情報システム部門のサポート • 政治的な論点 –– 権限を失うマネジャーによる妨害行為 –– 中傷合戦 –– 風評 –– 変革に対する恐怖 –– 文化的な抵抗 182 G26 ビジネスプロセスリエンジニアリング（BPR）プロジェクトレビュー 2.8.4 導入リスクには、以下の論点が含まれる。 • リーダーシップに関する論点 –– 幹部経営層による不十分な関心、関与、あるいは影響力 –– オーナーシップに関する争い –– CEO/スポンサーの政治的な意志の放棄、あるいはためらい –– CEO/スポンサーの交代 –– 不十分な資源 –– 説得力のある構想の周知の失敗 –– CEOによるマネジメントの結束化の失敗 • 技術的な論点 –– 能力を超えたIT開発 –– ソフトウェアの実装の遅延 –– パッケージソフトウェアの不十分な機能 –– 機能と設計の要件上の問題 –– 当初における主要な課題の非特定 –– 複雑性の過小評価 –– 予想されていなかった範囲の変更 –– 多大な時間、あるいは費用を要する開発戦略 • 移行に関する論点 –– 設計段階からの主要な要員の流失 –– 推進力の欠如 –– メンバーの極度の疲労 • 範囲に関する論点 –– 期待された成果の遅延 –– 予算超過 –– 非現実的なタイムフレーム –– 当初の範囲の縮小化 –– 人材の問題の無視 –– 多大な労力 183 G26 ビジネスプロセスリエンジニアリング（BPR）プロジェクトレビュー 2.8.5 運用/展開リスクには、以下の論点が含まれる。 • 文化的な/人材に関する論点 –– 文化的な抵抗の増加 –– 減少しない秩序を乱す行為 –– 積極的な参加の欠如による予測された便益の減少 –– 不十分、あるいは不成功の研修 –– 約束通りの、あるいは一般的に理解されているような成果の未達成 • マネジメントに関する論点 –– 新しいマネジメントスキルの導入の失敗 –– 継続的な改善アクティビティへの無支援 –– 満足に解決しないオーナーシップ/縄張り/権限に関する課題 –– 直面した問題を克服しようとする意思の不十分さ –– 不十分な周知 –– 従業員およびマネジャーによる能動的、あるいは受動的な妨害行為 • 技術的な課題 –– 遅いサポート、適切ではないサポートのいずれかおよび全て –– システム/ソフトウェアのバグによる業務上の問題 –– ユーザのニーズ/期待を満たさないシステム –– 不十分なテスト –– データのインテグリティに関する問題の発生による信頼の喪失 3 監査ポリシー 3.1 BPRプロジェクトのための修正 3.1.1 情報システム監査部門の監査ポリシーは、BPRプロジェクトを導入するという組織の決定の結果、修正が 必要となるかもしれない。BPRを考慮した場合、情報システム監査人の業務範囲、あるいは他の監査部門 （財務、業務等）との関係を拡大し、より密接に統合することが必要になる。 3.1.2 情報システム監査人の役割はBPRプロジェクトに関連しているため、組織のマネジメント層およびシステム マネジメントが情報システム監査人の役割を十分に理解・支援することは必須である。BPRプロジェクト および関連する組織の取り組みの枠組みの中で、情報システム監査指針G5『監査ポリシー』をレビュー、 検討すべきである。 4 独立性 4.1 BPRプロジェクトにおける情報システム監査の役割 4.1.1 情報システム監査人は、BPRプロジェクトに関連して非監査業務を行う、あるいは非監査業務に責任を有 する場合、情報システム監査基準G17『IT監査・保証の専門家の独立性に対する非監査業務の影響』をレ ビューし、適切に遵守すべきである。 4.1.2 情報システム監査人は、BPRプロジェクトにおいて非監査業務の役割を担う場合、ISACA情報システム監 査基準もレビューし、適切に遵守すべきである。 184 G26 ビジネスプロセスリエンジニアリング（BPR）プロジェクトレビュー 4.1.3 この理由は、情報システム監査人の独立性が損なわれる可能性が十分にあるためである。具体的には、情 報システム監査人は、自らがBPRチームの一員である場合、BPRの対象であるシステム、手続、あるいはプ ロセスのレビューを拒否すべきである。 5 能力 5.1 必要とされるビジネスの知識および技術的スキル 5.1.1 情報システム監査人は、BPRによる劇的な変革により、ビジネスプロセスにおいて既知の多くのことが影 響を受ける、あるいは存在しなくなるため、自らのスキルと監査アプローチを再構築しなければならないも のの、システムおよびコントロールに対する知識により、主要なビジネスプロセスのリエンジニアリングに おいて重要な役割を果たすことができる。 5.1.2 BPRプロジェクトの監査においては、情報システム監査人は、通常、監査チームの一員となり、情報システ ムの領域における自らのスキルにより、財務、業務および規制の領域を専門とする他の監査人のスキルを 補完する。しかしながら、情報システム監査人は、自らがBPRプロジェクトのレビューに必要となるビジネ スに関する知識を有するように努めるべきである。また、情報システム監査人は、自らがBPRプロジェクト のレビューを実施するための関連する技術的スキルおよび知識を入手できるとの合理的な保証も示すべき である。 6 計画策定 6.1 BPRプロジェクトのレビュー時に情報システム監査人が検討すべきフレームワーク 6.1.1 開始フェーズおよび診断フェーズにおいては、現状のプロセス、現在利用されている情報およびITシステ ムが分析され、ベンチマーク評価を通してその他のシステムとの比較が行われる。この時点において、情 報システム監査人は、調査対象として選定された各プロセスについて、パフォーマンスの変動を測定し、パ フォーマンスギャップを特定することができる。情報とITの利用は組織のプロセスにおける劇的な革新の ための手段となるため、情報システム監査人は、BPRプロセスの初期段階から有益な貢献をすることがで きる。 6.1.2 再設計フェーズでは、以下の事項が行われる。 • 新プロセスが再設計される • 新情報、あるいは既存情報の新たな利用方法が調査される • 新ビジネスシステムの青写真が定義付けされる • 移行戦略が作成される • 移行計画が作成される 6.1.3 情報システム監査人は、以下の事項をレビューすることができる。 • 新しい業務フローの将来のあるべきモデル、新しい情報が部門間でどのように共有されることになるの か、ITシステムの変容、新しい情報と技術がどのように導入されるのか、また、旧来の情報とITシステム がどのように廃棄されるのか、新コントロールシステムがどのくらい信頼できるのか。 6.1.4 評価フェーズにおいては、新プロセスと情報システムが稼働している。BPRプロジェクトが目標を達成して いるか、新しい仕組みへの移行が効果的かつ信頼できるか、また、全社的品質管理プログラムが稼働して いるかを判断することは、情報システム監査人に固有の職務である。 185 G26 ビジネスプロセスリエンジニアリング（BPR）プロジェクトレビュー 7 監査業務のパフォーマンス 7.1 リスク管理の評価 7.1.1 リエンジニアリングは、本質的に非常に状況的かつ創造性に富んだものであり、正しいやり方はなく、文 献においても複数のBPRに関する手続が紹介されている。BPRプロジェクトの監査は、ある方法論への 準拠性の監査はなく、むしろリスクマネジメントの評価であり、顧客と利害関係者にとって重要な、結果と しての収益改善がどのように実現されるかの評価である。 8 報告 8.1 報告書の内容 8.1.1 BPRのレビューにおいては、リスクおよび論点が検出された時点で随時報告が行われるべきである。これ らの報告書は、必要なアクションを講じるために、適切なマネジメントに向けられるべきである。レビュー の過程において検出されたすべての論点を記載した最終報告書を発行することもある。 8.1.2 レビューの種類に応じて、報告書には以下の事項を盛り込むべきである。 • BPRアプローチモデルおよび方法論の適切性 • リスクと論点、それらの原因と結果 • 実行可能なリスク低減策 • 費用対効果の比較および組織環境への影響 9 適用開始日 9.1 本ガイドラインは、2004年年7月1日以降に開始される全ての情報システム監査に適用される。 全ての用語集は、ISACAのWebサイト、www.isaca.org/glossaryに掲載されている。 付録 参考文献 • Carter, M.; R. Handfield; Identifying Sources of Cycle-time Reduction, Reengineering for Timebased Competition, Quorum Books, 1994 • Hammer, M.; J. Champy; Reengineering the Corporation: A Manifesto for Business Revolution, Harper-Collins, USA, 1993 • Harrington, H.J.; Business Process Improvement, McGraw-Hill, USA, 1991 BPRツールおよび技法 • 数多くのツールと技法がプロセスの知識を獲得・提示するために特別に開発されてきている一方、リエ ンジニアリングの研究において有用と考えられている既存のツールおよび技法も存在する。同一のプロ セスに対する異なった見方は、プロセスの理解には役立つかもしれないが、通常、必要となる革新的な 思考はもたらさない。ツールと技法は、以下のように大きく分類される。 • ソフトシステム方法論—思考プロセスを正式化するための定性的な/ブレインストーミング技法であり、 以下の場合にしばしば利用される。 –– プロセス/システムの目標設定 –– 問題分析（例えば、プロセスの失敗原因を特定するため（特性要因図等）） 186 G26 ビジネスプロセスリエンジニアリング（BPR）プロジェクトレビュー –– リスク分析 • プレゼンテーションツール—現状のプロセス、あるいは将来のプロセス案を理解・伝達するためにプロ セスの概観を提示するための技法である。以下は、例示である。 –– プロセス内における個人/チーム/部門の依存関係を捉えるためのロールアクティビティ図 –– アクティビティの依存関係を捉えるためのプロセスフロー図 –– 情報の依存関係を捉えるために有用な機能分割モデル –– プロセスの様々な段階における、プロセスのリードタイムの付加価値と非付加価値の要素への分解を 提示するための時間ベースのプロセスマッピング • 分析ツール—時系列によりプロセスの行動を分析するために利用可能なツールが存在する。PERT/ CPM、ペトリネットおよび離散イベントシミュレーションのような、異なったレベルのモデリング能力を 持つ様々なツールが存在する。情報システム監査人は、現状のプロセスのモデル化を強調し過ぎること により、適切な判断を行うことができなくなるリスクを認識すべきである。 COBITへの参照 個々の監査範囲に適用可能であるCOBITの中から最も関連する材料の選択は、特定のCOBIT ITプロセ スを選択し、COBITのコントロール目標と関連するマネジメントの実行を勘案して行う。 手続は、以下の主要なCOBITプロセスと関連する。 • M1 プロセスのモニタリング • M2 内部統制の適切性の評価 • DS1 サービスレベルの定義と管理 • DS10 問題と事故の管理 • AI6 変更管理 • PO1 IT戦略計画の策定 • PO9 リスク評価 • PO10 プロジェクト管理 手続は、以下のCOBITプロセスと副次的に関連する。 • PO4 IT組織とそのかかわりの定義 • PO5 IT投資の管理 • PO6 マネジメントの意図と指針の周知 • PO7 人的資源の管理 • PO11 品質管理 • DS3 成果と能力（キャパシティ）の管理 • DS7 利用者の教育と研修 • DS13 オペレーション管理 BPR監査に最も関連する情報要請規準は、以下の通りである。 • 有効性 • 効率性 • 準拠性 • 情報の信頼性 187 G27 モバイルコンピューティング 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 189 2 用語の定義‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 190 3 付託事項‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 191 4 計画‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 191 5 監査作業の成果‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 193 6 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 194 G27 モバイルコンピューティング 1 背景 1.1 ISACA基準との関連 1.1.1 基準S1『監査ポリシー』は、 「情報システム監査機能や情報システム監査業務の目的、責任、権限、説明 責任は、監査ポリシーや監査契約書により適切に文書化されている必要がある。」と述べている。 1.1.2 基準S4『専門家としての能力』は、 「情報システム監査人は、監査業務を遂行するための技能と知識を有 し、専門家としての能力を備えているべきである。」と述べている。 1.1.3 基準S5『計画策定』は、 「情報システム監査人は、監査の目的を満たし、関連諸法規と当該分野の諸監 査基準に準拠するよう、情報システムの監査の範囲を定めた計画を策定すべきである。」と述べている。 1.1.4 基準S6『監査業務のパフォーマンス』は、 「情報システム監査のメンバーは、監査の目的が達成され、当 該分野の諸監査基準が満たされていることについての合理的な保証を確保するため、監督されるべきであ る。」と述べている。 1.1.5 手続P8『セキュリティアセスメント』は、 「侵入テストや脆弱性分析は、特定のテストを実行する際に詳細 な手順が含まれている。」と述べている。 1.2 COBITとの関連 1.2.1 COBITフレームワークは、 「企業のすべての資産を守ることは経営陣の責任である。この責任を果たすだ けでなく、その期待を達成するために、経営陣は内部統制の適切なシステムを確立する必要がある。」と述 べている。 1.2.2 COBITマネジメントガイドラインは、自己評価、特に焦点を当てた継続的かつ積極的な制御のための管理 指向のフレームワークを提供している。 • パフォーマンスの測定―どのようにIT機能がビジネス要件をサポートするか？ • ITコントロールプロファイリング―どのITプロセスが重要か？コントロールのための重要な成功要因は 何か？ • 意識―何が目的を達成できない場合のリスクか？ • ベンチマーキング―他に何を行うのか？どのように結果を、測定し、比較することができるか？ 1.2.3 マネジメントガイドラインは、ビジネス用語でITの評価パフォーマンスを可能にする例となるメトリックを提 供する。重要な目標指標は、識別し、ITプロセスの成果を測定する。そして主要業績評価指標は、プロセ スのイネーブラを測定することによってそのプロセスがどの程度実行されているかを評価する。成熟度モデ ルと成熟度の属性は、コントロール能力を測定するためと、コントロールギャップや改善のための戦略を 識別するために経営陣を手助けし、能力評価とベンチマーキングを提供する。 1.2.4 マネジメントガイドラインは、自己評価のワークショップをサポートするために使用することができる、そし て、それらはまた、ITガバナンスのスキームの一部として継続的なモニタリングと改善の手順を管理するこ とによって、実装をサポートするために使用することができる。 1.2.5 COBITは、情報システム管理環境のためのコントロールおよびコントロール技法の詳細なセットを提供す る。個々の監査範囲に適用可能であるCOBITの中から最も関連する材料の選択は、特定のCOBIT ITプ ロセスを選択し、COBITのコントロール目標と関連するマネジメントの実行を勘案して行う。 1.2.6 このガイダンスで対処される範囲を検討する際に考慮すべき具体的な目標やCOBITのプロセスは、このド キュメントの付録にあるCOBITリファレンスを参照する。 189 G27 モバイルコンピューティング 1.3 ガイドラインの必要性 1.3.1 モバイルとワイヤレスコンピューティングは、世界的なビジネス運営で大きな注目を集めるために始めら れている現象である。モバイルとワイヤレスコンピューティングは、さまざまなモバイルデバイスからネット ワークベースのアプリケーションや情報にアクセスするための無線通信技術の使用を示す。インターネッ ト閲覧機能を持つこの技術と新たなポータブル機器の普及の使用の増加は、組織の物理的なフロンティ アを展開し、関連するリスクを識別するためにこの技術を理解することが情報システム監査人に必要とさ れる。 1.3.2 本ガイドラインは、モバイルコンピューティングのセキュリティが監査の割り当ての一部として、または独立 したレビューとしてレビューされるときに適用される情報システム監査基準S1、S4およびS5にガイダンス を提供している。情報システム監査人は、以下に上記の基準の実施を達成するか、そのアプリケーション の専門的な判断を使用するか、また任意の逸脱を正当化するために準備するかを決定する際にこのガイド ラインを考慮する必要がある。 2 用語の定義 2.1 ワイヤレスコンピューティング 2.1.1 用語ワイヤレスコンピューティングは、インフラ（無線）をケーブル接続することなくローカルエリアネット ワークを確立する形で通信するためのコンピューティングデバイスの能力を意味し、モバイルデバイスで使 用されているIEEE 802.11および他の無線規格や無線帯域のサービスを収束する技術に関係する。 2.2 モバイルコンピューティング 2.2.1 用語モバイルコンピューティングは、このコンセプトをアプリケーションの新しい種類を有効にするデバイ スに広げ、企業のネットワークを他の手段によって行われていない場所に到達するために拡張している。そ れは、PDA、携帯電話、ラップトップや他のモバイルとモバイル対応の技術で構成されている。 2.3 使用法 2.3.1 コンピューティングとストレージの機能を持つデバイスとして、モバイルデバイスは、プロセスおよびアプリ ケーションにアクセスし、様々な方法でデータを格納するために使用することができる。それらは独立した 形で、定期的にプロセスのデータが中央システムまたは他のシステムとデータを交換またはアプリケーショ ンにネットワーク接続する半独立したデバイスとして使用することも、リアルタイムで別のリモートシステム （それらは階層内だけでなく、ピアとして機能することがある）に格納されているデータへのアクセス・アッ プデートのクライアントノードとして使用することもできる。 2.4 アプローチ 2.4.1 モバイルデバイスは最終的に共通コンポーネントによって形成されているコンピュータである。たとえば、 ハードウェア、オペレーティングシステム、アプリケーション、および通信/接続リンクなど。この文書では、 モバイルコンピューティングの目的のためにデバイスの使用の監査/レビューに関連付けられた特定のト ピックについて説明する。機器と残りの部分の環境に関連する固有のリスクについては、このドキュメント に記載されていない。 （カバーされないリスク分野の例としては、ファイアウォール設定、ウイルスやプログ ラムのメンテナンスである。） 190 G27 モバイルコンピューティング 3 付託事項 3.1 範囲 3.1.1 情報システム監査人は通常契約書に記載されているモバイルコンピューティングに関して実行される監査 の目的と範囲の明確な記述を保有するべきである。 4 計画 4.1 情報収集 4.1.1 情報システム監査人は、モバイル機器の使用許可をルールとするセキュリティポリシーを取得する必要が ある。 4.1.2 情報システム監査人は、それらがビジネストランザクションとデータ処理・個人の生産性の目的（すなわち、 インターネットブラウジング、メール、カレンダー、アドレス帳、To-doリスト）のために使われると認識された 場合に、および使用するハードウェアおよびソフトウェア技術についてのモバイル機器の使用目的に関す る情報を取得すべきである。自動化と手動の主要なプロセスは文書化されるべきである。 4.1.3 情報システム監査人は、そのモバイルコンピューティング環境の影響を評価するエンティティによって実行 されたイベントの発生と考えられる影響の可能性とともに、リスク分析に関する十分な情報を取得する必 要がある。 4.1.4 情報システム監査人は、データセキュリティ、システムのソフトウェアとセキュリティソフトウェア、通信、 ハードウェア、アプリケーションソフトウェアなどの側面の展開、運用、保守に関連するモバイルコンピュー ティングを管理するために使われているポリシーや手続きに関する十分な情報を入手するべきである。カ バーする分野の例としては、デバイス構成、物理的な制御、承認済みのソフトウェアおよびツール、アプリ ケーションセキュリティ、ネットワークセキュリティ、緊急時対応計画、バックアップとリカバリである。 4.1.5 個人へのインタビュー、ドキュメントの解析（ビジネスケースおよびプロトコルのドキュメントなど）および 無線インフラのテストは、データの収集、分析および解析に適切に使用する必要がある。 4.1.6 第三者機関が情報システムまたはビジネス機能を外部委託するために使用されているときには、情報シス テム監査人は、契約書の条項、監査されたセキュリティの妥当性の評価、提供するサービスに関係する第 三者の環境を定期的に検討する組織の権利を確認するべきである。 4.1.7 情報システム監査人はまた、以前の検査報告書をレビューし、計画プロセスでそれらの結果を考慮する必 要がある。 191 G27 モバイルコンピューティング 4.2 リスク分析 4.2.1 情報システム監査人は、モバイルデバイスの使用に伴うリスクを考慮し、ビジネス、法律や規制の観点から、 蓄積され、アクセスされる情報の重要度や処理するトランザクションにそれらを関連付ける必要がある。 4.2.2 モバイルデバイスのポータビリティ、性能、接続性と手頃な価格は、アプリケーションを処理する時に以下 のようなリスクを増加させる。 • 損傷、紛失や盗難（そのポータビリティのために） • モバイルデバイスからのウイルス、ワーム、等の伝達によるネットワーク資産へのダメージ。 • 企業のデバイスまたはネットワークからデータをダウンロードすることによるデータへの不正アクセス （その接続のために） • 企業のデバイスまたはネットワークにデータをアップロードすることによるデータへの不正な変更または 追加 • デバイスに存在するデータ/アプリケーションへの不正アクセス（通常、非常に基本的なセキュリティ機 能だけを含む、オペレーティングシステムのシンプルさのために） 4.2.3 リスク分析を実行する際に考慮するトピックは次のとおりである。 • プライバシー―敏感な情報（例えばクレジットカード番号、財務情報と患者記録、など）が送信される 重要なコンポーネント。無線伝送が他の手段（例えば物理的なアクセスコントロールなど）によってハッ カーのアクセスから保護することができないようにプライバシープロトコルと関連する手順は非常に重 要である。 • 認証―認定された証明機関（CA）によって検証できるトークンまたは証明書を使用することによって確 保されることができる。 • 2要素認証―セキュリティで保護されたトランザクション（すなわち、デバイスとユーザの両方が許可さ れた代理人であることを確認）中に、デバイスとエンドユーザのIDの両方を検証するために使用される。 2要素認証は、盗難に遭ったり紛失したデバイスからのネットワークアクセスを拒否するために使用され る。 • データの整合性―送信またはモバイルデバイスに格納されている間のメッセージの内容変更の検出に 関係する。 • 否認防止―トランザクションを処理する否定からユーザを防止するためのシステム。否認防止は、ユー ザ認証の成功を必要とし、トランザクションを開始したユーザの信頼性と法的強制力のあるレコードを 確立する。 • 機密性と暗号化―最終的にそれを読んで理解できる権限のないユーザやデバイスを回避するための アルゴリズムを使用してデータの変換を行う（IS監査手続P9『暗号化の方法論上の管理コントロール の評価』を参照）。暗号化技術は、伝送中のデータの部分のエンコードと解読のキーに依存している。 キーの配布と保管のための手続きも考慮する必要がある。 • 第三者のネットワークに侵入するためにインターネットへの不正アクセスを使用してのリスクを含む機器 および通信の不正使用、 （潜在的な法的責任にエンティティを施す） 4.2.4 情報システム監査人は、識別されたリスクがありそうな効果とともに具現化する確率を評価すべきであり、 これらのリスクを軽減するコントロールと共にリスクを文書化するべきである。レビューの範囲に応じて、 情報システム監査人は、内部だけでなく外部の情報源 – たとえばハッカー、競合他社や外国政府などの 可能性が最も高い脅威の情報源を含める必要がある。 192 G27 モバイルコンピューティング 4.3 監査の目的 4.3.1 監査の目的と範囲によると、情報システム監査人は、彼/彼女のレビューのセキュリティ分野のレビューを 含める必要がある。たとえば、 • 通信（などスニッフィングやサービス拒否、およびそのような暗号化技術と耐障害性などのプロトコルな どのリスクをカバーする） • ネットワークアーキテクチャ • 仮想プライベートネットワーク • アプリケーションの配信 • セキュリティ意識 • ユーザ管理 • ユーザとセッション管理（たとえばデータの整合性のハイジャック、なりすまし、損失などのリスクをカ バーする） • 物理的なセキュリティ • 公開鍵インフラストラクチャ • バックアップとリカバリの手順 • 操作（たとえばインシデントの対応およびバックオフィスの処理など） • 技術アーキテクチャ（たとえば、実行可能なビジネスニーズに対応するための拡張、使用可能など） • セキュリティアーキテクチャ • セキュリティソフトウェア（IDS、ファイアウォールやアンチウイルスなど） • セキュリティ管理 • パッチの展開 • ビジネス緊急対応計画 4.4 作業計画 4.4.1 得られた情報と業務の範囲と目的に基づき、情報システム監査人は、それらのリスクを軽減する識別された リスクとコントロールの影響を受けるビジネス、セキュリティおよび（該当する）情報システムの目的を文書 化しなければならない。 4.4.2 このプロセスではで、情報システム監査人は、弱点や強化を必要とする脆弱性の領域を評価する必要があ る。考えられるリスクを軽減するとして認識された新しいコントロールは、テスト目的のため、作業計画に含 まれるべきである。 5 監査作業の成果 5.1 実行 5.1.1 コントロールの欠如するイベントでは、それらが監査の目的に影響していない場合、情報システム監査人は、 環境とテストの実際の脆弱性を識別するために、計画された手順の拡張（ペネトレーションテストを含む など）を考慮する必要がある。 5.2 報告 5.2.1 情報システム監査人は、監査作業の完了時に、意図したサービスのユーザ受信者へ適切な形式で報告を 提供する必要がある。 5.2.2 情報システム監査人は、リリースする前に適切なステークホルダーと、報告書を議論する必要がある。 193 G27 モバイルコンピューティング 5.2.3 報告書は、情報システム監査人やマネジメントが課すことに同意する配布に関する制限を指定する必要が ある。情報システム監査人は、第三者に対する債務を除いた記述を含めて考慮する必要がある。 6 適用開始日 6.1 このガイドラインは、2004年9月1日以降のすべての情報システムの監査に適用される。 用語の完全な用語集は、ISACAのウェブサイトwww.isaca.org/grossaryで見つけることができる。 付録 COBITリファレンス 個々の監査範囲に適用可能であるCOBITの中から最も関連する材料の選択は、特定のCOBIT ITプロセ スを選択し、COBITのコントロール目標と関連するマネジメントの実行を勘案して行う。 主要な参照： • PO9 ITリスクの評価 • AI3 技術アーキテクチャの開発と保守 • AI4 ITの手続きの開発と保守 • AI5 インストールと認定するシステム • AI6 変更管理 • DS5 システムセキュリティの保証 • DS9 構成管理 • ME2 内部統制の妥当性評価 副次的参照： • AI2 アプリケーションソフトウェアの調達と保守 • DS8 IT顧客のアシストとアドバイス COBIT情報要請規準は、機密性、完全性、可用性、効率性と信頼性である。 194 G28 コンピュータ法科学 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 196 2 定義付け‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 198 3 監査ポリシー‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 198 4 独立性‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 198 5 監査考察‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 199 6 監査計画のためのコンピュータ法科学の主要素‥ ‥‥‥‥‥‥‥‥ 200 7 報告‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 202 8 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 203 G28 コンピュータ法科学 1 背景 1.1 ISACA基準との関連 1.1.1 基準S3『専門家としての倫理と基準』は、 「情報システム監査人は、監査業務を遂行するに当たり、 ISACAの職業倫理規程を遵守すべきである。」と述べている。 1.1.2 基準S3『専門家としての倫理と基準』は、 「情報システム監査人は、適用可能な専門の監査基準を遵守す ることを始めとして、専門家としてのしかるべき注意を払うべきである。」と述べている。 1.1.3 基準S4『専門家としての能力』は、 「情報システム監査人は、監査業務を遂行するための技能と知識を有 し、専門家としての能力を備えているべきである。」と述べている。 1.1.4 基準S5『計画策定』は、 「情報システム監査人は、監査の目的を満たし、諸法規と当該分野の諸監査基 準に準拠するよう、情報システム監査の範囲を定めた計画を策定すべきである。」と述べている。 1.1.5 基準S6『監査業務のパフォーマンス』は、 「監査の過程において、情報システム監査人は、監査の目的を 達成するために、確実で妥当な証拠を充分得るべきである。監査の発見事項と監査の結論は、この証拠 を適切に分析し、解釈することにより裏付けられる。」と述べている。 1.2 COBITとの関連 1.2.1 COBITフレームワークは、 「会社の全資産を保護することはマネジメントの責任である。期待を達成する のと同様、この責任から解放されるために、 マネジメントは適切な内部統制システムを構築すべきである。」 と述べている。 1.2.2 COBITマネジメントガイドラインが、 マネジメント指向のフレームワークを提供する、継続的かつ事前のコン トロール自己評価が特に焦点を当てられているのは、 • パフォーマンス測定―IT機能がビジネス要求をどれだけうまく支援しているか？ • ITコントロールプロファイリング－いかなるITプロセスが重要か？コントロールのための重要成功要因は 何か？ • 認識－目的達成できないリスクは何か？ • ベンチマーキング－他人は何をしているか？結果はいかに測定され比較され得るか？ 1.2.3 マネジメントガイドラインは、ビジネス用語におけるIT成果の評価を可能ならしめる測定基準の例を提供 する。重要目標達成指標はITプロセスの結果を識別、測定し、重要成果達成指標は、プロセスのイネーブ ラを測定することにより、当該プロセスがどれほどうまく実行しているかを評価する。成熟度モデルと成熟 度属性は、能力評価とベンチマーキングのためにマネジメントがコントロール能力を測定し、コントロール 差異と改善のための戦略を識別するのを手助けを提供する。 1.2.4 マネジメントガイドラインは、自己評価勉強会を支援するのに利用され、また、ITガバナンス体系の一部と しての継続的モニタリングや改善手続をマネジメントが実装するのを支援するのに利用され得る。 1.2.5 COBITは、情報システムマネジメント環境のために詳細コントロールとコントロール技術を提供する。個々 の監査の範囲に適用可能であるCOBITの中から最も関連する材料の選定は、特定のCOBIT、ITプロセス、 コントロール目的の選択、関連するマネジメントコントロール実行、関連するCOBIT情報要請規準の勘案 に基づいている。 1.2.6 本ガイドラインにより取組まれた分野をレビューする時考慮されるべきCOBITの特定の目標やプロセスの ために本文書の付録にあるCOBIT参照を参照する。 196 G28 コンピュータ法科学 1.3 ガイドラインに必要なもの 1.3.1 情報システム監査人は、コンピュータや遠距離通信システムを利用してなされる不正や例外処理（コン ピュータ犯罪）に関し助言したり、組織のコンピュータ関連法規との準拠性を確認することがしばしば求 められる。コンピュータ法科学の基本的理解は、組織がその種の例外処理を検知し、防止するのを手助け するために必要である。本文書は、情報システム監査人が、この目的を達成する際に、助力することを意図 している。 1.3.2 コンピュータ法科学の第一目的は、攻撃者を識別すべく直ちにデータを捕捉することにより個々の状況 の背後の真実を確立し、法執行を援護するために犯罪の進行の証拠を確立することである。それは、また、 組織が、将来の攻撃から情報資産を保護し、攻撃者と攻撃に関する理解を獲得するのを助力する。主たる 特徴は、 • 証拠が消失もしくは変質されないように、直ちに対応する必要性の強調 • できるだけ攻撃された場所の近くのデータの捕捉・保存 • 法廷で承認され得るような証拠の法科学的保存 • ビジネス活動を破壊しない、最小侵入データ捕捉プロセス • 攻撃者の識別と証拠の確保 1.3.3 コンピュータ調査実施中、機密性が維持され、収集された、データと情報のために、インテグリティが確保 され、しかるべき当局だけが利用できることは、極めて重要である。情報システム監査人は、そのような訴 訟で、決定的な役割を果たし、法的助言が有効か否か、情報システム環境のどの技術的観点が適切な調 査を必要としているかを指示することによって組織を支援するかもしれない。訴訟では、情報システム監査 人は疑惑の例外処理や違法行為に関する情報を与えられるかもしれないし、更なる情報を収集するために データ分析能力を使うように要求されるかも知れない。 1.3.4 コンピュータ法科学は、不正・スパイ活動・殺人・恐喝・コンピュータの誤用・技術の悪用・名誉棄損・悪 意あるメール・情報漏洩・知的財産窃取・ポルノ・スパムメール・ハッキング・不正な資金の違法移動や、そ の他の多くの分野で適用されてきた。コンピュータ法科学はサイバースペースでの事象の詳細分析や証拠 収集を含んでいる。本ガイドラインは、情報システム監査人が、業務実施中、状況によって保証されたその 観点を考慮するに当たり、手助けする目的でコンピュータ法科学の要素を簡単に説明している。情報シス テム監査人は、また、内部調査のためのコンピュータ法科学のために必要なものを通知すべきであり、その 内部調査がそれなりの部分となる法科学調査（対、外部攻撃）は、 • 不服申立て • HR調査 • 不正調査 • コンプライアンス調査－コンプライアンスを種々の法的や業界ガイドライン命令に強要する（例、サーベ イオックスレイ.1、NIST, FISMA） 1.3.5 本ガイドラインは、コンピュータ法科学レビュー実施中に、情報システム監査基準S3『専門家としての倫 理と基準』、S4『専門家としての能力』、S5『計画策定』、S6『監査業務のパフォーマンス』を適用する際 に手引きを提供する。情報システム監査人は上記基準の履行を達成し、その適用に専門家としての判断を 用い、いかなる逸脱をも正当化する覚悟をする方法を決定する際に考慮すべきである。 1.4 ガイドラインの適用 1.4.1 本ガイドラインを適用する時、情報システム監査人は他の関連するISACAガイドラインに関連してその手 引きを考慮すべきである。 1.4.2 情報システム監査人はコンピュータ法科学業務の間、適用できるなら、管轄の法的調査ガイドラインを考 慮し、適用すべきである。 197 G28 コンピュータ法科学 2 定義付け 2.1 コンピュータ法科学 2.1.1 コンピュータ法科学は、法廷で有効なツールと技術、および証拠と同様、報告目的のために正確性かつ信 頼性を確立するために立証済みの法科学で最良の実践方法を使用してコンピュータ記録媒体から情報と データを抽出するプロセスと定義付けされ得る。 2.1.2 コンピュータ法科学への要求は、実際に、このデータを発見し、収集し、保存し、法廷で容認される、見読 性のあるやり方で提供することである。 2.1.3 コンピュータ法科学は主として、次の主張を支持する電子証拠を収集、加工、解釈、利用する科学的に立 証済みの方法の探究、適用を含んでいる。 • 完全な攻撃証明の目的と会社の極めて重要なインフラストラクチャー情報修復のために全アクティビ ティの決定的調査の提供 • 敵対者の行動と計画済みの運用に与える効果の関連付け・解釈・予測 • 電子データを犯罪調査プロセスに導入するに適した、説得力のあるものへの加工 2.1.4 コンピュータ法科学は、悪用や侵入が発生したかどうか、いかに発生したか、何時発生し、誰が侵入者か を決定するために、コンピュータからデータを抽出し、収集ための技術であり、科学である。良いセキュリ ティ習慣を使用し、適切なログを維持している組織は、目的を容易に達成し得る。しかしながら、正しい知 識とツールがあれば、法科学的証拠は例え、火災にあったり、浸水したり、物理的に破壊されたりしたコン ピュータシステムからも抽出され得る。 3 監査ポリシー 3.1 業務権限 3.1.1 コンピュータ法科学に直接関係がある業務開始前に、情報システム監査人は、業務を指揮する適切な権 威者から明確な書面に認めた権限を取得すべきである。 3.1.2 権限は、業務の責任、権限、制約を特定し、業務遂行するに当たり、情報システム監査人の独立性を保証 する。それは、また、監査人が関連システムやデータにアクセスする法的権威を持って行動していることを 明確にすべきである。 3.1.3 権限は、また、情報システム監査人が業務遂行するに当たり、外部の専門家を利用する時、範囲と責任を 特定すべきである。 4 独立性 4.1 独立性の考慮 4.1.1 コンピュータ法科学に直接関係がある、業務開始前に、情報システム監査人はいかなる利害相反がないと いう合理的補償を提供すべきである。 4.1.2 コンピュータ法科学業務が、政府、法定団体、当局により手がけられた場合、情報システム監査人は、はっ きりと、独立性と、職務遂行の権威を通知し、入手した情報に関する機密性を維持し、先入観を持つこと なく、適切な法組織に報告書を提出しなければならない。 198 G28 コンピュータ法科学 5 監査考察 5.1 電子取引の法的有効性 5.1.1 有効であると考えられるために、販売する製品やサービスが関わる契約書は、署名されるべきである。電 子契約の場合、これは電子署名で達成され得る。 5.1.2 電子署名が司法適合性の目的を達成し得るのは、 • 認証－データ起源の証拠がある • インテグリティ－実証プロセスは、メッセージが全く変更されなかった場合のみ継続する • 否認不可または起源－どの鍵ユーザも自らの鍵を保護する法的責任がある。それ故、鍵ユ－ザは否認で きないし、署名文書の内容を一方的に修正できない。秘密鍵を保護するのに使用される有効なシステム は、多分スマートカードのような安全な個人デバイスに収納するかも知れない。誰かの特有の電子署名 を拒否することは可能であろうか？例え、受入れ可能と考えても、その否定は全く価値がない。相手方が 契約が署名されれば署名は有効だったということを主張しさえすればよい。これは、鍵所有者が、契約 が署名される前に、自分の秘密鍵は盗まれたか、未承認使用されたということを立証しなければならな い、と言うことである。公証人により認証された電子署名は、否定され得ない。 • 機密性－署名文書に機密性を付加するために、名宛人の公開鍵を使って暗号化することだけが必要で ある。 5.2 当事者と取引内容の識別 5.2.1 法定年齢（大抵の地域で通常18際以上）の人々だけが、契約締結の能力を持つ。 5.2.2 商人は、相手方が、法的に商取引をする資格があるが認められているということを自分達に証明するいかな る方法も利用できる。いかなる種類の証拠も要求でき、自らのアーカイブに買手のデータを保管すること ができる。誤謬や誤用の場合、納入業者は、契約の適切な履行に最終的に責任がある。電子署名システム を利用する時は、責任は、電子署名を発行した機関に存在する。この機関は認証局(CA)と呼ばれている。 もし異議を唱えられた場合、電子証明書の所有者は秘密鍵が盗まれたか誤用されたかどうかを主張すべき である。 5.2.3 同じ考えが取引（インテグリティ）内容に適用される。それは、電子署名システムを利用する時、保存される。 そうでない場合、商人は、事実と反する、不完全な、あいまいな、間違ったデータに責任があることになる。 5.2.4 商人はいつもクレジットカード不正や個人情報保護違反に責任がある。 5.3 契約締結場所 5.3.1 電子商取引に関する最大の問題は、正確な契約締結場所を決定していることであり、その契約書が法的 管轄地域と準拠法を決定している。 5.3.2 契約に適用される特定の法律が欠如している場合、唯一の選択肢は、国際法に付託することである。現代 技術は、誰でも、世界中のほぼどこからでもサービスプロバイダに接続できる。このことは正確な契約締結 場所を確定するのを不可能にしている。 5.3.3 施策は、国際法の適切な適用とそれに続く国際協定の適用である。 5.3.4 最も受容される取組が述べているのは、 • もし当事者が特定の法律を選択したならば、これは適用される唯一の法律である。 • もし当事者がいかなる法律体系も選択しなかったならば、契約に最も近い関係（例えば、サービスプロ バイダの所在地）のある法律か、製品販売の場合、消費者の国の法律が適用される。 5.3.5 どの場合でも、商人の場所を決定（そして証明）することは極めて困難なので、できるだけ慎重に実施する ことが必須である。 199 G28 コンピュータ法科学 5.4 カテゴリー区分 5.4.1 契約締結の形式に拘わらず、情報科学の固有の性格からして、何処の国でも法律は消費者を保護するとい うことから、取得者は消費者としての充分な資格がある。この理由により、会社－対－会社、と会社－対― 消費者の電子商取引の間に区分がある。 5.5 不正防止 5.5.1 経済システムは、一方からは、提案／受諾の識別、否認不可に基づき設立され、他方からは、買う時（サー ビスや商品を受領したいことを意味する）でも売る時（支払いを受納したいことを意味する）でも合理的に 安全な資金移動を確保することに基づき設立されている。電子署名システムは、今日、支払いオンラインの 唯一の法定形態に見える。 5.6 インターネット上のクレジットカード使用 5.6.1 今日、クレジットカードはインターネット取引の最も利用されている支払い道具である。不幸にも、 （これら のオンラインデータの再生を容認するような）クレジットカードデータの悪用には多くの可能性がある。例 えば、取引の領収書は未承認の人々により読み取られるという可能性がある。 5.6.2 オンライン取引にとって、クレジットカードを持つ必要はなく、データさえあればいい。無権限でカードデー タを使用するだけでクレジットカード犯罪となる。クレジットカード犯罪の3形式は、 • カードデータの悪用 • 偽造と虚偽のクレジットカードの保有 • 違法カードの売買 5.6.3 インターネット上のクレジットカード違法使用は、カードデータ使用により不正に金品、サービスを得る目 的のいかなる行動も含んでいる。例え、所有者が期限切れのカードを使っても、犯罪となる。 6 監査計画のためのコンピュータ法科学の主要素 6.1 データ保護 6.1.1 対策が、求める情報を破壊・破損・不用化から防ぐために適切であることは極めて重要である。 6.1.2 全当事者が電子証拠を保存し、情報を破壊するいかなる手段へ簡単に行かないように要求する特定のプ ロトコールに着手して、電子証拠が、コンピュータシステムからの発見を通じて捜索されるということを適切 な関係者に通知することも、また、重要である。 6.1.3 反応と法科学調査能力は、事件や事象の前に、適切になっているべきである。これは、事件対応や取扱の ためのインフラストラクチャやプロセスを含んでいる。 1ローマ会議、1980欧州法、 www.rome-convention.org/instruments/i_conv_cons_it.htm とウィーン会議、1980年に署名された商 品の輸出入に関する国際協定www.cisg.law.pace.edu/cisg/biblio/volken.html. 6.2 データ入手 6.2.1 これは情報とデータを管理された場所へ移動するプロセスを含んでいる。 6.2.2 これはディスクドライブ、テープドライブ、フロッピーディスク、バックアップテープ、ZIPドライブ、他の移動 可能な媒体のような、全電子媒体の収集を含んでいる。全ての媒体は、承認された方法で、別の媒体に移 動される内容（画像）で保護すべきである。加えて、媒体にウィルスがなく、書込み保護となっていることを 確認することが重要である。 200 G28 コンピュータ法科学 6.2.3 データと情報は、また、立会人や他の関係団体の記録された記述を通し、入手される。 6.2.4 開かれたポート、公開されているファイル、活動中のプロセス、ユーザログオン、RAMの他のデータを含む、 揮発性のデータの捕捉は多くの場合、極めて重要である。揮発性のデータは一時的であり、コンピュータ をシャットダウンすると失われる。揮発性のデータの捕捉は、目下システム上で起こっていることを決定す る際に、調査者を手助けする。 6.3 画像作成 6.3.1 これは、多様の分析がオリジナルデータや情報を損傷する恐れなく実施されるために、インクが消えない ファックスを提供する目的での、蓄積されたデータのビット対ビットのコピーを含んでいる。 6.3.2 画像作成は、目標ドライブの残余データを捕捉するためになされる。画像コピーは、残余データを捕捉し ないファイル対ファイルコピーに対立するものとして、セクターごとにディスク表面を複製する。残余データ は、削除されたファイル、削除されたファイルの断片、ディスク表面になお存在している別のデータを含んで いる。破壊されたデータ（消失、媒体初期化による場合でも）も、適切なツールを使えば、ディスク表面か ら回復され得る。 6.4 抽出 6.4.1 これは、画像化されたデータセットからの、潜在的に有益なデータの識別、分離を含んでいる。これは、損 傷・破損・破壊されたデータや、検知防止のために変形されたデータの発見を含んでいる。 6.4.2 画像作成や抽出の全プロセスは、品質、インテグリティ、信頼性の基準に合致していなければならない。こ れは、画像創成のたまに使用されたソフトウェアと、画像が作成された媒体を含んでいる。良いベンチマー クは、ソフトウェアが、法的機関に使用され、信頼され、法的機関から認定されているかどうかであろう。コ ピーと証拠は、独立した検証能力がねければならない。即ち、相手と法廷はデータの正確性と信頼性、 データが耐変形性であるということに関して説得されねばならない。 6.4.3 抽出は、システムログ、ファイアウォールログ、侵入検知システムログ、監査証跡、ネットワーク管理情報の ような、多くのデータの検査を含んでいる。 6.5 審問 6.5.1 これは、個人の、電話番号・IPアドレス・名前のような、事前にわかる手引きや、関係がデータ内に存在す るかどうかを決定するために、抽出されたデータを疑うことを含んでいる。 6.5.2 抽出されたデータの正確な分析は、法的機関の前に、推奨事項を作成し、適切な証拠の根拠を準備する ために必須である。 6.6 摂取／標準化 6.6.1 これは、適切な技術を使って、調査者により容易に理解されるフォーマットの中に抽出されたデータの移 動・保管を含んでいる。これは、16進法や2進法の情報の見読可能な文字への変換、データの別のASCII 言語セットへの変換、データ分析ツールに適合したフォーマットへの変換を含んでいるかも知れない。 6.6.2 データ内の関係は、調査用の仮説を開発するために、例えば融合・相関・グラフ化・作図・時間軸のような、 技術を通して推定される。 201 G28 コンピュータ法科学 7 報告 7.1 法律にとって受容しうる 7.1.1 前述のように、コンピュータ法科学への要求は、データを見つけ出し、収集し、保存し、法廷で受容される やり方で提供することである。情報システム監査人は、正規の受領者に関する完全な情報と明確さと報告 目的を持つべきである。 7.1.2 報告書は、適切な形式であるべきであり、実施された調査の範囲・目的・種類・時期・度合を記述すべきで ある。 7.1.3 報告書は、組織、正規の受領者、配布制限（もしあれば）を識別すべきである。報告書は、情報システム監 査人が業務に関して持っている留保事項や限定事項とともに、発見事項、結論、推奨事項をはっきりと通 知すべきである。 7.2 証拠 7.2.1 電子証拠は、メインフレームコンピュータ、ポケットサイズPDAからフロッピーディスク、CD、テープ、最小 電子チップデバイスにすら及んでいる。 7.2.2 証拠は改変されず、破壊されてもいないという合理的な保証を提供するために、業界特有のベストプラク ティスは、尊重されるべきであり、立証済みのツールは利用されるべきであり、企業調査は公開されるべき である。証拠のインテグリティ、信頼性、機密性は、法執行機関の公正な判断に到達するために絶対必要 である。また、証拠は、当局にとって適切な時期に作成され、有用となることが極めて重要である。 7.2.3 インターネットＥ-メールの追跡例： • インターネットＥ-メールメッセージを送信する時、ユーザは一般的に受領者行（ToとBcc）と主題行のみ をコントロールする。 • メールソフトは、コンピュータ処理により、ヘッダ情報の残りを追加する。E-メールヘッダの例は、 (1) 返送経路：<[email protected]> (2) 受信:o199632.cc.navy.gov by nps.gov.org (5.1/SMI-5.1) id AAO979O; Fri, 7 Nov 2003 18:51:49 PST (3) 受信:localhost byo199632.gov.org (5.1/SMI-5.1) id AA41651; Fri 7 Nov 2003 18:50:53 PST (4) メッセージ-ID: <[email protected]> (5) 日にち: Fri, 7 Nov 2003 18:50:53 -0800 (PST) (6) 発信者: "Susan Rock" <[email protected]> (7)受信者: Mott Thick <[email protected]> (8) 写し: Jokey [email protected] • 1行目は、受領コンピュータに、誰がメッセージを送ったか、エラーメッセージの送付先（返送と警告）を 伝える。 • 2行目と3行目は、送信から配布までにメッセージが通った経路を示す。このメッセージを受け取るコン ピュータはどれも、受領領域に、完全なアドレスとタイムスタンプを追加する；これは、配布問題を追跡 する助けとなる。 • 4行目は、メッセージID、この特定のメッセージの一意の識別子である。このIDはログされ、メールを追 跡する必要がある場合、メッセージ経路上のコンピュータを通して追跡され得る。 • 5行目は、メッセージが送信された、日にち、時間、標準時を示す。 • 6行目は、メッセージ作成者（送信者）の名前とＥ-メールアドレスを伝える。 202 G28 コンピュータ法科学 • 7行目は、主たる受信者の名前とＥ-メールアドレスを示す；そのアドレスは以下のためかも知れない。 –– 送付表 –– システム上の別名 –– 個人ユーザ名 • 8行目は、メッセージの写し(Cc)受信者の名前とＥ-メールアドレスを羅列する。同様にブラインドコピー (Bcc)受領者もあるかもしれない；これらBcc受領者は、メッセージのコピーを受けるが、名前もアドレス もヘッダには出てこない。 8 適用開始日 8.1 本ガイドラインは2004年9月1日以降に開始される全ての情報システム監査に適用される。 付録 COBIT参照 個々の監査範囲に適用可能であるCOBITの中から最も関連する材料の選択は、特定のCOBIT ITプロセ スを選択し、COBITのコントロール目標と関連するマネジメントの実行を勘案して行う。 コンピュータ法科学の観点で、最も関連しそうなCOBITプロセスは下記のように、主要、副次的なものに に分類される。選定され、採用されるべきプロセスとコントロール目的は、特定の範囲と任務の権限次第 で変化するかもしれない。 主要な参照： • PO8 外部要求に対するコンプライアンスの保証 • AI1 コンピュータ化対応策の明確化 • DS1 サービスレベルの定義と管理 • DS2 サードパーティのサービス管理 • DS5 システムセキュリティの保証 • DS10 問題管理 • DS11 データ管理 • M1 プロセスモニタリング • M3 独立保証の獲得 副次的参照： • PO1 IT戦略計画の策定 • PO4 ITプロセスと組織およびそのかかわりの定義 • DS6 費用の捕捉と配賦 • DS12 物理的環境の管理 • DS13 オペレーション管理 • M2 内部統制のモニタリングと評価 コンピュータ法科学レビューに最も関連のある情報要請規準： • 主：信頼性、インテグリティ、コンプライアンス • 副：機密性、可用性 203 G29 導入後のレビュー（PIR） 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 205 2 監査ポリシー‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 208 3 独立性‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 208 4 専門家としての倫理と基準‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 208 5 能力‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 209 6 計画立案‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 209 7 監査業務のパフォーマンス‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 209 8 利益実現のレビュー‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 211 9 アウトソーシング‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 211 10 報告‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 212 11 フォローアップ活動‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 212 12 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 212 G29 導入後のレビュー（PIR） 1 背景 1.1 ISACA基準へのリンケージ 1.1.1 情報システム監査基準S6『監査業務のパフォーマンス』は、 「監査期間中に、情報システム監査人は監査 目的を達成するための十分かつ関連のある証拠を得るべきである」と述べている。監査の発見事項およ び結果は、適切な分析およびこれらの解釈によってサポートされている必要がある。 1.1.2 情報システム監査基準S8『フォローアップ』は、 「発見事項および勧告事項の報告の後で、情報システム 監査人は適切なタイミングでマネジメントによって適切な行動がとられているかどうかの結果に関する情報 を要求および評価すべきである」と述べている。 1.2 COBITへのリンケージ 1.2.1 ハイレベルのコントロール目標M4『独立監査の実施』は、 「信頼性レベルの向上のためのビジネス要件 やベストプラクティスの助言から得られるベネフィットといった監査の独立性を提供するITプロセスのコン トロールは、一定の間隔で独立した監査を実行することによって可能になる。また、以下の考慮事項を検 討することで可能になる。」と述べている。 • 監査の独立性 • 事前対応の監査への関与 • 権限を与えられたスタッフによる監査パフォーマンス • 発見事項および勧告事項の点検 • 監査勧告事項のインパクト・アセスメント（コスト、ベネフィット、リスク） 1.2.2 詳細なコントロール目標M4.6『監査業務のパフォーマンス』は、 「監査目的が達成され、適切な監査基準 が適応されるといった保証を提供するために、監査が適切に監督されるべきである」と述べている。監査 人は監査目的を効率的に達成するために、彼らが十分かつ信頼でき、関連性があり、有用な証拠を得られ ることを確実にすべきである。監査の発見事項および結果は、適切な分析および証拠の解釈によってサ ポートされるべきである。 1.3 COBITの参照 1.3.1 COBITの参照は、このガイダンスによって言及されている領域をレビューする際に、特定の目的やCOBIT プロセスを考慮することを提案している。特定の監査範囲に適応できるCOBITの最も関連する材料の選 択は、特定のCOBITのITプロセスおよび情報要請規準の考慮事項の選択に基づいている。 1.3.2 導入後のレビュー（PIR）において、IT施策の導入後の最初のレビューは、以下のプロセスが最も関連して いる。 • PO2 情報アーキテクチャの定義 • PO4 IT組織とそのかかわりの定義 • PO5 IT投資の管理 • PO8 外部要求事項の遵守の保証 • PO9 リスク評価 • PO10 プロジェクト管理 • PO11 品質管理 • AI1 コンピュータ化対応策の明確化 • AI2 アプリケーションソフトウェアの調達と保守 • AI3 技術インフラの調達と保守 205 G29 導入後のレビュー（PIR） • AI5 システムの導入と受入信認 • AI6 変更管理 • DS7 利用者の教育と研修 • DS11 データ管理 • M1 プロセスのモニタリング 1.3.3 導入後のレビュー（PIR）に最も関連する情報要請規準： • 主：有効性、効率性 • 副：可用性、コンプライアンス、機密性、信頼性、完全性 1.3.4 国際会計士連盟（IFCA）のIT諮問委員会（ITC）ガイドラインに以下が含まれる： • IT施策の導入 • 事業へ影響を与えるIT計画立案の管理 1.4 ガイドラインの目的 1.4.1 ガイドラインの目的は、IT施策の導入後のレビューを実行するための推奨される施策について言及するこ とである。それは、情報システムの監査に関する関連した基準に対し、一連のレビューを準拠されるためで もある。 1.4.2 組織は、自身のビジネス要件を満たすため様々なIT施策を導入する。 施策が導入されると、一般的に導入後のレビューが情報システム監査人によって実施される。その目的は、 IT施策およびそれらの導入の有効性および効率性を評価するためであり、また（必要であれば）施策が改 善されるための行動を導くことであり、将来のための学習ツールとして役立つこともある。 1.4.3 このガイドラインで推奨された確かな施策はまた、不成功に終わった導入や以前の導入が中断されたプロ ジェクトのレビューを適切にする可能性もある。 1.4.4 このガイドラインは、情報システム監査基準S6「監査業務のパフォーマンス」およびS8「フォローアップ」 に適用するための手引き、および導入後のレビューを導く手引きを提供する。情報システム監査人は、アプ リケーションの専門的な判断の利用や逸脱を正当化するための準備等のために、どうやって基準の導入を 達成するかを決定するために、このレビューを考慮すべできである。 1.5 ガイドラインの適用 1.5.1 ガイドラインを適用する際は、情報システム監査人は他のISACAガイドラインに関連する手引きを考慮す べきである。 206 G29 導入後のレビュー（PIR） 1.6 定義および一般的な適用範囲 1.6.1 最初もしくはそれに続くIT施策および／またはその導入のレビューが、このガイドラインの目的である導入 後のレビューとして定義している。導入後のレビューは以下のいずれか、もしくはすべてを評価するために 導入後に実行される。 • 意図した施策の目的が成功したかどうか • 実際のコストと利益が予算に対して対比されているかどうか • 導入されたプロセスの有効性および妥当性 • もしあれば、時間、コスト、品質の超過、および／またはパフォーマンスに関する課題 • その施策から得られた生産性およびパフォーマンスの改善 • ビジネス・プロセスおよび内部統制が導入されたかどうか • ユーザのアクセスコントロールが組織のポリシーに沿って導入されたかどうか • ユーザが適切にトレーニングされたかどうか • システムが維持しやすくできていて、将来に向けて有効かつ効率的に開発がされているかどうか • 関連する利用可能な機能および手順が導入されているかどうか • 関連する法的要件および組織のポリシーといったコンプライアンス • 関連するCOBITコントロール目標およびマネジメントガイドラインといったコンプライアンス • 将来の改善に対する施策や導入されるプロセスといった機会 1.6.2 導入後のレビューの目的は、以下を含む可能性がある。 • 意図したIT施策導入の目的が、組織のビジネス目標を満たす、もしくは適合するよう確実にする • 収集した情報が完全かつ正確であり、処理した情報がビジネスルールに準拠していて、かつ生成した情 報が正確で信頼でき、タイムリーであることを確実にするインプット、プロセスおよびアウトプットといっ た手順およびコントロールが十分にあるか評価する • IT施策によって作られた経営証跡の維持および監視といった手順とコントロールが十分にあるか評価 する • IT施策によって生成された財務およびマネジメント報告書の正確性を検討する • IT施策によって、強化されたアプリケーションの十分なアクセスコントロールが行えるよう確実にする • 予期せぬシャットダウンおよびデータの完全性の欠如から復旧するためのIT施策に備わっている利用可 能な機能が十分にあるかを検証する • 開発および導入のための特定の人材が不足した際に、IT施策が効率的かつ効果的にサポートされてい るよう確実にする。 • リスクの低減およびコントロールの強化のための施策を提供すると同時に、コントロールにおける可能 性のあるリスクおよび弱点を特定する 1.6.3 導入後のレビューは、基本的にIT施策が価値ある（組織によって決定、測定される）投資であるかどうか、 やIT施策が十分に管理およびコントロールされた状態で提供されているかどうかを決定するために使われ る。これらの投資効果は、8.1章で言及する利益実現のレビューと呼ばれる、固有かつ別のレビューによっ てカバーされる。導入後のレビューの適用範囲は以下のように点を考慮すべきである。 • IT施策の性質 • 意図したIT施策の利用方法（目的、誰によって、いつ、どこで利用されるか、） • ビジネス目標を達成する上でのIT施策の最重要項目 • （組織の）監査委員会と合意したレビューの適用範囲 • IT施策が立ち上げ、開発、およびテスト段階で監査レビューによって影響を受けたかどうか • プロジェクト導入期間に、情報システム監査人の監査以外の業務の役割 207 G29 導入後のレビュー（PIR） 2 監査ポリシー 2.1 権限 2.1.1 導入後のレビューを開始する前に、情報システム監査人はレビューを実行するために必要不可欠な権限を 持つべきである。レビューが第三者によって主導される場合、情報システム監査人はレビューを第三者に委 託するにあたり、適切な権限を持たせるという合理的な保証を得るべきである。 3 独立性 3.1 専門的な客観性 3.1.1 業務を受け入れる前に、情報システム監査人は、彼らの関心のあるIT施策における導入後のレビューがレ ビュー自体の客観性を害さないといった合理的な保証を提供すべきである。それらの関心事に矛盾が起こ りそうであれば、明示的に組織に伝達されるべきであり、可能であれば業務を受け入れる前に組織がそれ らの矛盾に気づいていることを公式な声明書として残しておくべきである。 3.1.2 情報システム監査人がレビューを行なうIT施策の導入における監査以外の業務の役割を担った場合、情 報システム監査人はG17『IT監査・保証の専門家の独立性に対する非監査業務の影響』によって提供され ているガイダンスを考慮すべきである。 4 専門家としての倫理と基準 4.1 導入前および導入後のレビュー 4.1.1 導入前のレビューと比較すると、IT施策が合理的期間（通常の月数もしくはプロセス・サイクル）で、導入さ れたアプリケーションのセキュリティ・レベルと同様なユーザの手順で運用されているとき、通常どおりの 導入後のレビューが実行される。 4.1.2 導入前のレビューは、コントロール、経営証跡やテスト環境上での運用方法といった概念的な設計を考察 することである。導入後レビューは、一度IT施策が本番環境で導入され、構成され、運用された後で、コン トロール、経営証跡や運用方法を考察することである。導入前のレビューが満足のいくような形で実施さ れた場合、情報システム監査人は導入後のレビューにも限界があるので本番環境における実際の運用が 考察できたかどうかを慎重に判断すべきである。 4.1.3 人的資源が利用できる場合、土壇場での変更が実際のIT施策の導入へ影響する可能性があるので、導入 前および導入後のレビューの両方を実行することが望ましい。 4.1.4 導入後のレビューを実行する際、情報システム監査人はIT施策を導入するためのプロジェクトオーナーの 実行責任について合理的な保証を提供すべきであり、プロジェクトチームをレビュープロセスに関わらせる べきである。一般的に以下のようなレビューの一部がチームメンバーに含まる。 • IT施策の設計、開発および展開に関連がある人 • レビュー領域、現在および提案されたビジネスプロセス領域において知識を供出した人 • 技術的な知識に関連した人 • 組織のビジネス戦略に関する知識を供出した人、およびその戦略を達成するためのIT施策提案に寄与 した人 • 組織の利益を具現化するためのプロセスにおける測定とモニタリングに関与した人 208 G29 導入後のレビュー（PIR） 5 能力 5.1 スキルおよび知識 5.1.1 情報システム監査人は、IT施策の導入後のレビューを実施するための関連するスキルおよび知識を保持し ているという合理的な保証も提供すべきである。専門家のインプットが必要な場合、適切なインプットを入 手すべきである。 6 計画立案 6.1 レビューの適用範囲および目的 6.1.1 必要に応じて組織と協議しながら、情報システム監査人は導入後のレビューの適用範囲および目的を明 確に定義すべきである。レビューによってカバーされるべき観点は、適用範囲の一部として明示的に記載さ れるべきである。 6.1.2 レビュー目的のために、導入に関わる利害関係者は特定されるべきである。 6.1.3 導入前もしくは同時にレビューされた、IT施策もしくは導入プロセスに関する発見事項および結論は、適 用範囲の決定および監査計画立案の際に考慮されるべきである。 6.2 配慮すべき事項の承認 6.2.1 組織の施策によって、情報システム監査人は組織内の配慮すべき事項やアプローチについて関連する部 署の合意を得ておくべきである。 もしレビューが第三者によって主導される場合、彼らも配慮すべき事項に合意すべきである。 6.3 アプローチ 6.3.1 情報システム監査人は、レビューの適用範囲および目的が、監査目的を満たし、かつ専門的な方法で実施 されるといった、合理的な保証を提供するためのアプローチを策定すべきである。また、そのアプローチは 文書化されるべきである。専門家のインプットの活用は、アプローチの一部として明記すべきである。導入 後のレビューは、IT施策の導入後の一回目のレビューに限ったことではない。複数のレビューが導入され た施策の改善点を特定するために実行されることもある。 7 監査業務のパフォーマンス 7.1 導入後のレビューの実行 7.1.1 導入後のレビューは、IT施策が導入されてから合理的な期間内にスケジュールされるべきである。施策のタ イプおよび環境によって異なるが、一般的な期間は4週間から6ヶ月とされている。 7.1.2 導入後のレビューは、最終化したIT施策の評価およびレビューを意図している。適切なレビューを実施す るために少なくとも1回の全導入および報告サイクルが完了した時点でレビューが実施されるのが、理想的 である。初期の課題や困難が起こっている間、もしくはユーザを訓練および教育している間は、レビューを 実施すべきでない。しかしながら、最終的な改善が組み入れられている間でも、IT施策から得られる利益が 最もよいと判断されれば、レビューを実施すべきである。 209 G29 導入後のレビュー（PIR） 7.1.3 レビューの手順には、 （ビジネスケース、ビジネスコントロールを含むビジネス要求、実行可能性の検討、シ ステム、運用上文書、ユーザ文書、進捗報告書、議事録、費用対効果の報告書、テスト計画、トレーニング 計画、応対マニュアル等といった）利用可能な文書、利害関係者との討議内容、実際に行なったIT施策の 実験や訓練、観察結果、ビジネスからの引き合い、プロジェクト人員、運用テストおよびコントロール文書 などを含むべきである。 7.1.4 導入後のレビューを実施すための適切な資源が特定され、割り当てられるべきであり、レビューの実施は、 関連する被監査人と共同して計画立案すべきである。 7.1.5 合意書は、書式、内容、報告先、タイミングについて記述すべきであり、可能であれば、導入後のレビュー の結果についても報告すべきである。 7.1.6 言及されたIT施策、コストおよび利益の目的は、細部に渡って考え抜くべきである。目的の達成度合いや 実際のコストおよび利益は、パフォーマンス、コストおよび利益を捕捉し、モニタリングし、報告するために 利用されたプロセスおよびシステムと一緒に評価されるべきである。これらの一部として、IT施策によって もたらされた生産性およびパフォーマンスの改善点もまた検討すべきである。適切な測定基準は、これら の前後関係を考えた上で利用されるべきである。もしあれば、コストおよび／または時間の超過は、それら の原因および影響を参照することによって分析すべきである。また、コントロール可能およびコントロール 不可能な原因は別途特定されるべきである。 7.1.7 IT施策を定義および導入するためのプロセスは、有効性と同様に妥当性についても言及することで評価さ れるべきである。 7.1.8 IT施策をサポートするユーザおよびスタッフに提供される教育やトレーニングの妥当性および有効性は、 レビューされるべきである。 7.1.9 導入前もしくは、導入プロセスと平行して、内部もしくは、外部のレビュー実施者によって実施された以前 のレビューに関する報告書を注意深く確認するべきである。また、推奨事項およびとられた活動の現状を 検証すべきである。 7.1.10 導入後のレビューは、一般的にIT施策を試験するために実施するので、IT施策が適切なCOBITのコント ロール目標に対して満足すべきである。また、関連するコントロール目標に準拠する程度や非準拠による 影響は分析され、報告されるべきである。さらに、COBITマネジメントガイドラインにある重要成功要因、 重要目標指標、重要成果達成指標および成熟度モデルは、IT施策およびレビューされる導入プロセスに 適切に適応されるべきである。 7.1.11 適切な経営証跡は、推奨された是正処置と同様に、データの収集、分析の実施および導かれる推論のた め維持されるべきである。 7.1.12 法令、法的要求事項、組織のポリシー、IT施策および導入プロセスの標準に準拠する程度は、レビューさ れるべきである。 7.1.13 適切であれば、自動テストツールおよびCAATは、IT施策に関連するテストの観点として利用できるかもし れない。 7.1.14 レビューは、コントロールを改善する、もしくは導入プロセスの有効性を高める機会を与えるとともに、リス ク、課題および必要となる是正処置をハイライトすべきである。 7.1.15 報告された発見事項、結論および推奨事項は、導入後のレビューの期間中に得られた客観的な分析、情 報の解釈および証拠に基づいているべきである。 210 G29 導入後のレビュー（PIR） 8 利益実現のレビュー 8.1 利益実現のレビュー 8.1.1 すべてのITプロジェクトは、現実のビジネスプロジェクトであり、着手時からビジネスの論理的根拠を持つ べきである。それらの成功もしくは失敗は、金銭面もしくは戦略的なビジネスプランの達成にどれだけ貢献 したかのいずれかで測定されるべきである。利益実現のレビューは、何が達成できたかだけでなく、今後す べきこととして何が残されているかについても焦点を当てるべきである。組織が次のプロジェクトを引き受 ける際は、利益実現のレビューをより洗練するために、以前のプロジェクトから得られたベストプラクティ スおよび教訓を活用して調整すべきである。 8.2 利益実現のレビューの目的 8.2.1 利益実現のレビューの目的は、新しいIT施策の運用上の成功を評価すること、および実際のコスト、利益 や予定されていた予算に対するコストの消費度合いについて評価することである。レビューはまた、IT施 策を提供、および導入する際に利用されたプロセスの有効性を試験することもある。重要な考慮事項は、 元々のシステムの目的およびスケジュールが達成されたかどうかである。これは、現状とあるべきプロセス の姿の詳細を理解しているということを要求しており、プロセスのあるべき姿の目的が達成されたかどうか を評価することにもつながる。 8.2.2 導入後のレビュー報告書の構成要素である利益実現は、以下の内容を含んでいる。 • 予定された予算に対する実際のコスト • 予定された利益に対する実際の利益 • 投資収益率 • 予定されていた予算に対するコストの消費度合 • 計画されたプロジェクト終了日と実際のプロジェクト終了日 • 元の目的に対する達成された目的 • 経営証跡を含む、文書およびコントロールの妥当および品質の評価 • 予測されていたパフォーマンスに対する実際のIT施策のパフォーマンス • すべてのユーザの満足度および新しいIT施策・システムへの理解 • 将来のIT施策導入プロジェクトへの改善提案の実施 9 アウトソーシング 9.1 ITアウトソーシング 9.1.1 組織は、IT施策の導入のすべて、もしくは一部を外部サービスプロバイダへ部分的、もしくはすべて任せる 場合、情報システム監査人はそのような割り振りを行なうことの影響を評価すべきであり、コンフォーマン ス／コンプライアンスの妥当性があるか、サービスプロバイダとの契約、合意や規定の妥当性があるかレ ビューするべきである。 9.1.2 情報システム監査人は、アウトソーシングサービスの性質、時期および程度について理解すべきである。ま た、情報システム監査人は、サービスユーザがビジネス要求および組織によって要求されているコントロー ル（G4『他の組織への情報システム活動のアウトソーシング』参照）に対処できるように必要なコントロー ルを整備すべきである。 211 G29 導入後のレビュー（PIR） 10 報告 10.1 報告内容 10.1.1 導入後のレビューにおける報告書は、レビューの目的および適用範囲によって以下の側面を言及すべきである。 • 適用範囲、目的、活用した手法および仮定 • 導入されたIT施策が意図された目的に合致しているかどうか、およびIT施策がビジネス目標に合致して いるかの評価 • 起こりうる脆弱性の影響と同様に、導入プロセスに関する主要な強みおよび脆弱性のすべての評価 • 重大な脆弱性を克服するため、および導入プロセスを改善するための推奨事項 • 可能性のあるリスク、およびそのようなリスクを低減する手法 • COBIT情報要請規準への準拠の程度 • 将来のIT施策および導入プロセスの改善のための推奨事項 • 導入されたIT施策を利用するユーザのトレーニング • 組織全体を通してのIT施策の受け入れ度、および適用度 10.1.2 観察結果および推奨事項は、必要に応じて利害関係者および組織（もし適用されるならば、サービスプロ バイダも）によって妥当であることを確認されるべきであり、報告書を最終化する前に返答を得ておくべき である。 10.2 脆弱性 10.2.1 導入後のレビュー中に特定されたコントロールの欠如、導入プロセスの弱さ、および受け入れ可能なレベ ルのリスクへ軽減できないことによる脆弱性については、ビジネスプロセス・オーナおよびIT施策の導入に 責任のある情報システム管理者へも注意喚起すべきである。導入後のレビュー中に特定された重大、もし くは重要と考えられる脆弱性があった場合、適切なマネジメントレベルに対して、早期是正処置を可能にす るために、早急に助言されるべきである。 10.2.2 IT施策に対する有効なコントロールは、全般ITコントロールによって異なるため、これらの領域におけるい かなる脆弱性も報告されるべきである。全般ITコントロールが試験されていないという事象があれば、その 事実を報告書に含むべきである。 10.2.3 情報システム監査人は、報告書の中に関連するリスクを低減し、コントロールを強固にするための適切な 推奨事項を含むべきである。 11 フォローアップ活動 11.1 適時性 11.1.1 導入後のレビューによって特定された脆弱性の影響は、広範囲かつ高リスクになるかもしれない。それゆえ 情報システム監査人は、必要に応じて脆弱性を言及し、効果的にリスクを管理するためのマネジメント活動 を検証するフォローアップを適宜行なうべきである。 12 適用開始日 このガイドラインは、2010年5月1日から全てのIT監査に適用される。 すべての用語集は、ISACAのWebサイト、www.isaca.org/glossary.に掲載されている。 IT監査・保証ガイドラインG23『システム開発ライフサイクル』参照。 212 G30 能力 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 214 2 責任‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 215 3 継続的専門家教育‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 217 4 記録‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 218 5 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 218 G30 能力 1 背景 1.1 基準との関連 1.1.1 基準Ｓ４『専門家としての能力』は、 「情報システム監査人は委任された監査を遂行するためのスキルと知 識を有することにより、専門家としての能力を備えているべきである。情報システム監査人は継続的な教育 や研修によって、専門家としての能力を維持すべきである。」と述べている。 1.2 ＣＯＢＩＴとの関係 1.2.1 専門的なコントロール目標Ｍ３『独立した保証の取得』は、 「組織、顧客、第三者である業者間の信頼性 と信用を高めるため独立した保証を得ること。」と述べている。 1.2.2 専門的なコントロール目標Ｍ４『独立した監査の提供』は、 「ベストプラクティスによるアドバイスの信頼 性の水準と便益を高めるための独立した監査の提供」と述べている。 1.2.3 詳細なコントロール目標Ｍ３． ７『独立した評価機能の能力』は、 「マネジメントは独立した評価機能がレ ビューを有効に、効率的に、経済的に遂行するのに必要な技術的能力、スキル、知識を有していることを 確認すべきである。」と述べている。 1.2.4 詳細なコントロール目標Ｍ４．４『能力』は、 「マネジメントは組織のＩＴ活動をレビューする責任を有する 監査人が技術的に有能であり、レビューを有効に、効果的に経済的に遂行するのに（ＣＩＳＡ資格の対象 範囲）必要なスキルや知識を有していることを確認すべきである。マネジメントは情報システム監査業務に 携わるスタッフが、然るべき継続専門家教育を通じて技術的能力を有していることを確認すべきである。」 と述べている。 1.3 COBITの参照 1.3.1 ＣＯＢＩＴの参照は本ガイドラインが取り組む分野をレビューする場合に考慮するＣＯＢＩＴの特定の目的 やプロセスを提供している。個々の監査範囲に適用可能であるCOBITの中から最も関連する材料の選択 は、特定のCOBIT ITプロセスを選択し、COBITのコントロール目標と関連するマネジメントの実行を勘案 して行う。必要を満たすため、ＣＯＢＩＴのプロセスは然るべき選択と適用がなされ、以下のように主要お よび副次的に分類される。プロセスと選択され適用されるコントロール目標は、委任される特定の範囲や 条件により異なる。 1.3.2 主要な参照： • ＰＯ 人的資源の管理 • Ｍ２ 内部統制の十分性評価 • Ｍ３ 独立した保証の取得 • Ｍ４ 独立した監査の提供 1.3.3 副次的参照： • ＤＳ１ サービスレベルの定義と管理 • ＤＳ２第三者による業務提供の管理 • ＤＳ３パフォーマンスと能力の管理 • ＤＳ７ユーザー教育と研修 • Ｍ１ プロセスの監視 1.3.4 最も能力に関連する情報要請規準： • 主：効率性、有効性、可用性 • 副：秘密性、インテグリティ、コンプライアンス、信頼性 214 G30 能力 1.4 ガイドラインの目的 1.4.1 情報システム監査人は非常に有能であることが期待される。この目標に合致するため、情報システム監査 人は委任された業務を遂行するために必要なスキルと知識を身につける必要がある。更なる課題は継続的 な知識とスキルの向上によって能力を維持することである。 1.4.2 専門的なサービスを提供することを約束することにより、情報システム監査人は専門的なサービスを遂行 する際に必要とされる能力の望ましい水準の可用性を示唆し、情報システム監査人の知識やスキルは細心 の注意と勤勉さが求められる。 1.4.3 高度な有能さを期待することについて、情報システム監査人は、サービスが満足のいくように遂行されるに 足る合理的保証が得られるアドバイスや助言が為されない限り、どのようなサービスも有能ではなく、そう したサービスを提供することを控えるべきである。 1.4.4 情報システム監査人は、専門的なサービスを提供するにあたり、細心の注意、能力、勤勉さをもって行う必 要があり、合理的保証を提供するために必要な水準の専門的な知識やスキルを有する継続的な義務を負 うべきである。その合理的保証は専門的監査基準の要求事項を満たし、被監査組織が最新のプラクティ ス、法律、技術に基づく有能な専門的サービスを利用する立場を享受することができることを意味してい る。 1.4.5 ＩＳＡＣＡが表明したビジョンはＩＴガバナンス、コントロールや保証において、世界的なリーダーと一般に 認められている。ビジョンの序文ではＩＳＡＣＡにより提供される専門職の将来における成功はＣＩＳＡ資 格で要求されるスキルや能力に補足して必要とされるスキルや能力を明確に詳述している。ＩＳＡＣＡはそ うしたスキルや能力を特定することにおいて最先端に位置しておりこれらの定量化と評価を行う方法を考 案している。この意味でガイドラインは、情報システム監査人が必要なスキルと知識を身につけ、監査業務 を遂行する際に能力を維持するためのガイダンスを提供している。 1.4.6 本ガイドラインは情報システム監査人が情報システム監査基準Ｓ４『専門家としての能力』を適用する際 のガイダンスを提供している。情報システム監査人は上記の基準をどのように適用するか、適用にあたって の専門家としての判断、基準からの逸脱を判断する用意があるときに本ガイドラインを考慮に入れるべき である。 1.5 ガイドラインの適用 1.5.1 本ガイドラインを適用する場合、情報システム監査人は他の然るべきＩＳＡＣＡの基準やガイドラインと本 ガイドラインとの関連を考慮に入れるべきである。 2 責任 2.1 スキルと知識 2.1.1 主に情報システム監査人は委任されることを合意した情報システム監査業務に必要な専門的および技術 的なスキルと知識に責任を持つべきである。 2.1.2 監査業務のマネジメントは情報システム監査人が任務を遂行するために必要な専門的および技術的なス キルと知識を有していることを確認した上で、監査業務を委任する副次的責任がある。 2.1.3 監査業務のマネジメントは監査業務を遂行する監査チームメンバーが必要なスキルと知識を有しているこ とを確認する責任がある。 2.1.4 スキルと知識は情報システム監査人の監査業務における立場や役割により異なる。マネジメントが有すべ きスキルや知識は責任の程度につり合ったものであるべきである。 2.1.5 スキルや知識にはリスクやコントロールを特定したり管理したりする技量と、監査ツールや監査テクニック が含まれる。情報システム監査人はインタビューしたり、人と接したり、発表するスキルと分析的で技術的 な知識を有するべきである。 215 G30 能力 2.2 能力 2.2.1 能力はスキルと知識を有することと、相応しい教育や経験のレベルを通じて得た専門性を含む。 2.2.2 情報システム監査人は求められる能力のレベルを得るために必要なスキルと知識を有することの合理的な 保証を与えるべきである。 2.2.3 情報システム監査人は適切なベンチマーキングでそれを定期的にレビューしたり更新した上で求められ、あ るいは期待される能力の水準をデザインすべきである。 2.2.4 情報システム監査人と、監査業務マネジメントは監査業務を引き受ける前に監査業務を遂行するために必 要な能力資源の可用性についての合理的保証を与え、監査業務の開始前に能力資源の可用性を確認すべ きである。 2.2.5 監査業務マネジメントは監査チームメンバーが委任された監査を遂行する能力を有していることを確認す る責任がある。監査チームメンバーの主要な能力を特定することは可用な人的資源の効率的な利用に役 立つ。 2.2.6 情報システム監査人にとって、人的資源能力を向上させるため、監査チームメンバー同士の経験、使われる ベストプラクティス、教訓や会得した知識を共有することは有益だと考える。監査チームメンバーの能力は 共同作業、ワークショップ、会議、セミナー、研修やその他のインタラクションを通じても向上される。 2.3 継続的メンテナンス 2.3.1 情報システム監査人は認められる能力のレベルを維持するためにスキルと知識を継続的にモニタリングす べきである。 2.3.2 継続的専門教育（ＣＰＥ）を通じたメンテナンスは、研修、教育コース、資格取得、大学教育、会議、セミ ナー、ワークショップ、電話会議、ウェブ上の掲示、円卓会議などが含まれてもよい。 2.3.3 スキルと技術の習得と能力レベルのメンテナンスは継続的にモニターされる必要があり、スキルや知識や 能力は定期的に評価されるべきである。 2.4 評価 2.4.1 評価は公平、明白、分かり易い、明快、偏りのない、然るべき雇用環境で一般に受け入れられている方法で 行われるべきである。 2.4.2 評価基準と手続きは明確に定義される必要があるが、地理上の場所、政治状況、委任の性質、文化やそ の他の類似環境により異なることがある。 2.4.3 監査法人や監査人チームの場合、評価は内部的に機能横断的なチームあるいは個人について行われるべ きである。 2.4.4 独立した個人の情報システム監査人の場合、評価は可能な範囲で同等の専門家により実施されるべきで ある。 2.4.5 情報システム監査人のパフォーマンスおよび外部の情報システム監査人については然るべき必要性に応じ てそのパフォーマンスを評価するため然るべき水準のマネジメントが必要とされるべきである。 2.4.6 評価にあたり発見されたギャップは然るべく対応されるべきである。 216 G30 能力 2.5 ギャップ分析と研修 2.5.1 期待される能力と実際に身につけている能力の間の不一致として発見されるギャップは記録し、分析され るべきである。不充分性がいずれかの資源に存在している場合は、その資源は、不充分性さを埋める手当 てがなされない限り、委任される監査に利用されるべきではない。しかしながら、不充分性さが委任された 監査業務を開始した後に発見された場合は、情報システム監査人あるいは監査業務マネジメントは不充分 な資源を取り出し、有能な資源に置き換えることを検討すべきである。しかしながら強制的な理由により、 その資源を使って委任された監査業務を継続することを求められた場合は、ギャップの存在について被監 査組織へその旨を伝えるべきである。不充分な資源を引き続き使うことについて、被監査組織の合意を得 ておくべきである。その場合でも、情報システム監査人は監査の品質について合理的保証ができることが 条件となる。 2.5.2 ギャップが生じた理由を明確にするため根本原因の分析を行うことが重要となる。また遅滞なく研修など の適切な是正措置を実施することが重要となる。 2.5.3 監査業務に必要な研修は合理的な期限内で監査業務の開始前に完了すべきである。 2.5.4 研修の効果は研修が完了してから合理的な時間後に計測されるべきである。 2.6 能力を備えた人的資源の可用性 2.6.1 情報システム監査人あるいは監査業務マネジメントは、提案要求に回答する前に、委任を受ける監査業務 に必要とされるスキルや知識を理解し分析すべきである。 2.6.2 情報システム監査人あるいは監査業務マネジメントは委任を受けた監査業務を開始する前に必要とされる スキル、知識、必要とされる能力水準が利用可能かの合理的保証を提供すべきである。 2.6.3 情報システム監査人は保有していない専門的知識、能力、経験をあたかも有しているように見せかけるべ きでない。 2.7 外部委託 2.7.1 委任を受けた監査業務のある部分が外部委託され、また専門家の支援を受けた場合は、外部の専門家あ るいは委託された業者が必要な能力を有することの合理的な保証を提供しなければならない。本ガイドラ インは外部の専門家の選定にも適用される。 2.7.2 専門家の支援が継続的に行われる場合、その外部専門家の能力を定期的に測定し、モニターし、レビュー すべきである。 3 継続的専門家教育 3.1 専門家団体の要求事項 3.1.1 継続的専門家教育（以下ＣＰＥ）は能力を維持しスキルと知識を向上させるための手法となる。 3.1.2 情報システム監査人は所属する然るべき専門家団体が設定するＣＰＥ方針の要求事項を遵守すべきであ る。 3.2 認定プログラム 3.2.1 ＣＰＥプログラムはスキルと知識の向上に役立つ必要があり、情報システムの保証、セキュリティとガバナ ンスの専門的および技術的要求事項に関連しているべきである。 3.2.2 専門家団体は一般にＣＰＥ認定に適したプログラムを用意している。情報システム監査人は専門家団体が 規定した規範を遵守すべきである。 217 G30 能力 3.3 ＣＰＥクレジット取得 3.3.1 専門家団体は一般に団体が要求する定期的に獲得すべきＣＰＥクレジットと最低限のクレジットの取得方 法を規定している。情報システム監査人は然るべき専門家団体が規定した規範を遵守しなければならない。 3.3.2 情報システム監査人が最低限のクレジットを取得するためひとつ以上の専門家団体に関与している場合、 情報システム監査人は、それぞれの専門家団体が制定する規則やガイドラインに沿った形で同様に提供さ れる参加可能なプログラムから共通の要領でＣＰＥクレジットが取得可能かを判断してもかまわない。 3.4 ＩＳＡＣＡのＣＰＥ方針 3.4.1 ＩＳＡＣＡはその会員やＣＩＳＡ資格保有者に適用される継続的専門家教育についての詳細な方針を有し ている。ＣＩＳＡ資格を有する情報システム監査人は、ＩＳＡＣＡのＣＰＥ方針を遵守しなければならない。 方針の詳細はＩＳＡＣＡのウェブサイトwww.isaca.org/CISAcpePolicyで見ることができる。方針は以下 の規準を説明している。 • 資格要件 • 参加メンバの確認 • 専門家としての倫理規範 • 継続的専門家教育を受けた時間の監査 • 資格取り消し、再認定、アピール • 引退や無職の場合のＣＩＳＡ資格の取り扱い • 教育的活動の認定 • ＣＰＥの時間計算 4 記録 4.1 スキルマトリックスおよび研修記録 4.1.1 スキル、知識と委任された種々の業務に必要とされる能力を記載したスキルマトリックスを制定すべきで ある。このマトリックスは可用な人的資源と各人のスキルと知識の組み合わせとなる。このマトリックスは ギャップと必要な研修を明らかにすることに役立つ。 4.1.2 研修のフィードバックや研修の効果を含む形で提供された研修記録は、維持し、分析し、将来利用する際 の参考とすべきである。 4.2 CPE記録 4.2.1 ＩＳＡＣＡを含む然るべき専門家団体が規定しているように、情報システム監査人は適切なＣＰＥプログラ ムの記録を維持し、一定の期間保管し、求められた場合は監査に示すことができるようにすべきである。 5 適用開始日 5.1 本ガイドラインは2005年6月1日から始まる全ての情報システム監査に適用される。 用語集はＩＳＡＣＡのウェブサイトwww.isaca.org/glossaryで見ることができる。 218 G31 プライバシー 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 220 2 監査ポリシー‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 222 3 独立性‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 222 4 職業倫理および基準‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 223 5 能力‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 223 6 計画策定‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 224 7 監査作業のパフォーマンス‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 227 8 報告‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 228 9 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 229 G31 プライバシー 1 背景 1.1 基準との関連 1.1.1 基準S1『監査ポリシー』は、 「情報システム監査機能ないし情報システム監査業務の目的・責任・権限・説 明責任は、監査ポリシーまたは監査契約書に適切に文書化されているべきである。」と述べている。 1.1.2 基準S5『計画策定』は、 「情報システム監査人は、監査の目的を満たし、適用可能な法規と専門の監査 基準に準拠するよう、情報システム監査の範囲を定めた計画を策定すべきである。」と述べている。 1.1.3 基準S6『監査業務のパフォーマンス』は、 「監査の過程において、情報システム監査人は、監査の目的を 達成するために、十分かつ確実で関連性のある証拠を入手すべきである。監査の発見事項と監査の結論 は、この証拠を適切に分析し、解釈することにより裏付けられる。」と述べている。 1.2 COBITとの関連 1.2.1 高レベルコントロール目標PO8『外部要件事項の遵守と保証』は、次のように述べている。 「法律、規制、 および契約上の義務を果たすためのビジネス要件を満たす外部要件の遵守を保証するＩＴプロセスに関 するコントロールは、外部要件を特定・分析し、また、それらを遵守するための適切な対策を講じることに より機能し、また、以下の事項を考慮する。 • 法律、規制、契約 • 法律および規制の改正に対するモニタリング • 遵守状況に対する定期的なモニタリング • 安全性および人間工学 • プライバシー • 知的財産 1.2.2 詳細コントロール目標PO8.4『プライバシー・、知的財産・データフロー』は、 「マネジメントは、企業のIT 業務に適用される、プライバシー、知的財産、国際的なデータフローおよび暗号に関する規制への遵守状 況を確認すべきである。」と述べている。 1.3 COBITへの参照 1.3.1 本手引きの対象領域をレビューする際に考慮されるべきCOBITの特定の目標、あるいはプロセスに関する COBITへの参照。 個別の監査の範囲に適用すべき、最も関連したCOBITの文書は、特定のCOBITのプロセスの選択および COBITのコントロール目標や関連するベストプラクティスの検討に基づいて選択する。プライバシーの問 題においては、最も関連し、選択・採用されるべきCOBITのプロセスを主要および副次的に分類し、以下 に記載している。選択・採用されるべきプロセスおよびコントロール目標は、実施する監査の範囲および 条件による異なるかもしれない。 1.3.2 主要な参照： • PO8 外部要求事項の順守と保証 • DS5 システムセキュリティの保証 220 G31 プライバシー 1.3.3 副次的参照： • PO7 人的資源の管理 • DS1 サービスレベルの定義と管理 • DS2 サードパーティのサービスの管理 • DS10 問題と事故の管理 • DS11 データ管理 • DS13 オペレーション管理 • M1 プロセスのモニタリング • M2 内部統制の十分性の評価 • M3 独立した第三者の保証の獲得 • M4 独立監査の実施 1.3.4 プライバシーのレビューに最も関連する情報要請規準： • 主：有効性、遵守性、機密性、インテグリティ • 副：信頼性、可用性 1.4 ガイドラインの目的 1.4.1 本ガイドラインの目的は、情報システム監査人がプライバシーを理解し、情報システム監査を実施する際に プライバシーに関する問題に適切に取り組むことを支援するものである。本ガイドラインは、情報システム 監査を主たる対象としているが、他の状況においても考慮され得るものである。 1.4.2 本ガイドラインは、情報システム監査基準を適用する際の手引きを提供する。情報システム監査人は、上 記基準の実施を実現する方法を決定する際に本ガイドラインを検討するとともに、その適用においては専 門家としての判断を用い、いかなる乖離も正当化できるように準備しておくべきである。 1.5 ガイドラインの適用 1.5.1 本ガイドラインを適用するにあたり、情報システム監査人は、当ガイドラインを他の関連するISACA基準お よびガイドラインと関連付けて検討すべきである。 1.6 情報システム監査におけるプライバシーの定義—限界と責任 1.6.1 プライバシーとは、特定した、あるいは特定できる個人（データ主体）に関連するあらゆる情報に関する信 頼および責務への遵守を意味する。マネジメントには、プライバシーポリシー、あるいは適用されるプライバ シーに関する法律や規制に従ってプライバシーを遵守する責任がある。 1.6.2 個人データは、特定した、あるいは特定できる個人に関するあらゆる情報である。 1.6.3 情報システム監査人は、何が個人データベースに保存されているかへの責任は有しておらず、個人データが、 正しいセキュリティ対策を講じることにより、法的要件を満たした上で正しく管理されているかを確認すべ きである。 1.6.4 情報システム監査人は、 マネジメントの定めるプライバシーポリシーをレビューし、セーフハーバーやOECD により公表された『プライバシー保護と個人データの国際流通についてのガイドライン』 （参考文献セク ションを参照）のような、国際流通するデータフローに関する要件を含む、プライバシーに関する法律およ び規制の要件を考慮していることを確認する。 221 G31 プライバシー 1.6.5 情報システム監査人は、 マネジメントが実施するプライバシーに関する影響度分析、あるいは評価をレ ビューすべきである。そのような評価では以下のことをすべきである。 • 業務プロセスに関連する、個人を特定できる情報を特定する • 個人を特定できる情報の収集、利用、開示および破壊について文書化する • マネジメントに対して、プライバシーリスクに対する理解およびプライバシーリスクの低減に利用可能な選 択肢に基づき、詳細なポリシー、業務およびシステムデザインに関する決定を行うためのツールを提供する • プライバシーに関する問題に対する説明責任が存在することを合理的に保証する • 関連する規制への技術的および法的な遵守状況の両方を分析するための一貫して組織化されたプロセ スを整備する • プライバシー遵守のために情報システムの変更を少なくし、また、補強する • プライバシーが概念的な要件分析の段階から最終的なデザインの承認、資金確保、導入およびコミュニ ケーションの段階において考慮されていることを保証するフレームワークを提供する 1.6.6 情報システム監査人は、これらの評価が初めてのプライバシーレビューの一環として、また、下記のような 変更管理プロジェクトとして継続的に行われているかを確認すべきである。 • 技術の変革 • 新しいプログラム、あるいは既存のプログラムの大きな変更 • 追加されたシステム連携 • 強化されたアクセスの容易性 • ビジネスプロセスリエンジニアリング • データウェアハウス化 • 新しい製品、サービス、システム、業務、納入業者およびビジネスパートナー 1.6.7 あらゆる組織、特に世界中の異なる地域で事業を行っている組織が遵守する必要があるプライバシーに関す る法規制を評価する際に、法規制の要件に関して専門家の意見を求め、また、そのような法規制への遵守に 関する意見形成および報告のために必要となるコンプライアンスおよび実証テストを実施すべきである。 1.6.8 データ管理者とは、個人データがデータ管理者、あるいはデータ管理者の代理人により収集、保存、処理、 あるいは公開されるかに関係なく、個人データの内容および利用について決定することのできる者である。 2 監査ポリシー 2.1 ネットワーク世界におけるプライバシー 2.1.1 ワールドワイド・ウェブや電子メール等の通信技術の発展により、地球規模での情報の効率的なやり取り が可能となっている。通信技術の倫理的な使用並びに電子化/デジタル化された個人情報およびハードコ ピーでの個人情報の保護を保証するためのコントロールが整備されているべきである。さらに、組織が個 人のプライバシーを保護するためのコントロールを導入することを求める法律が世界的に制定されている。 本ガイドラインは、情報システム監査人が個人のプライバシーを保証するために設計されたセキュリティコ ントロールの有効性を評価するために適用する一連の共通した基準を提供する。 3 独立性 3.1 情報源 3.1.1 監査人は、企業が採用するプライバシーに関する国内の規制、次に国際的な規制を検討すべきである。組 織が国際的に活動をしている場合には、国内の規制が企業の方針に優先されるが、この場合には、組織は 両方を遵守しなければならない（EEUU会社に対するUS-SOX（サーベンスオクスレー法等）。 222 G31 プライバシー 4 職業倫理および基準 4.1 個人データ保護の必要性 4.1.1 内部および外部のレジストリ/データ源間における接続およびインターネットの利用の増加により、国有企 業、民間企業ともに、プライバシー保護の必要性が強まっている。生命、健康、財産状況、性的嗜好、宗教、 政治的見解等に関する情報は、権利のない人々に開示された場合、個人にとって取り返しのつかない害を 及ぼすかもしれない。 4.1.2 プライバシーに関する法律および規制は多くの国において存在しているが、周知されていない、あるいは十 分に具体的でないこともしばしばである。従って、情報システム監査人は、プライバシーの問題に関する基 本的な知識を有し、必要な場合には、企業における個人情報の保護レベルを評価するために各国の規制 における基本的な違いについても認識していなければならない。 5 能力 5.1 個人データの保護への取り組み 5.1.1 個人情報の機密性、インテグリティおよび可用性を保証するために、デジタル化された個人情報および ハードコピーでの個人情報の扱いに関する要件およびルールが存在しなければならない。あらゆる組織は、 いかなる種類や形式での個人情報も保護するための方法を有していなければならず、以下のことを検討す べきである。 • プライバシー管理—最高経営責任者、あるいは組織の責任者は、プライバシーに対する一義的な責任 を有している。個人情報を利用する目的および上位のガイドラインは、セキュリティ目標/ポリシーおよ び戦略に盛り込まれるべきである。個人情報の利用が企業の必要性や公的なルールや規制に合致して いることを合理的に保証するための定期的な評価に関する正式に定められた手続が存在すべきである。 評価結果は文書化され、セキュリティポリシーやセキュリティ戦略の将来の変更のための根拠として使 用されるべきである。 • リスク評価—組織は利用されている様々な種類の個人情報に関する概要を把握しているべきである。ま た、組織は、個人情報の扱いに関連して許容可能なリスクの基準を決定すべきである。個人情報の責任 は「データ管理者」に委譲されるべきである。データ管理者は、セキュリティ事故の発生可能性や結果を 特定するためのリスク評価の実施に責任を有している。情報セキュリティの重要性の変更に応じて、新 たなリスク評価が実施されるべきである。リスク評価の結果は文書化されるべきである。 • セキュリティ監査—情報システムの利用に関するセキュリティ監査は定期的に実施されるべきである。 セキュリティ監査には、組織、セキュリティへの取り組みおよびパートナーや納入業者との協力関係も含 められるべきである。結果は文書化されるべきである。 • 逸脱—正式に定められた手続に準拠しておらず、セキュリティ違反を引き起こすかもしれないあらゆる情 報システムの利用は逸脱として扱われるべきである。逸脱への対応の目的は、正常な状態の再構築、逸 脱を招いた原因の除去および再発防止である。逸脱が未承認の機密情報の開示に起因する場合には、 国内の当局に報告を行う必要があるかもしれない。結果は文書化されるべきである。 • 組織—情報システムの利用に対する責任が定められ文書化されるべきである。責任は、適切なマネジメ ントからの許可なしに変更できないようにすべきである。情報システムは十分な情報セキュリティを実現 するように設定されるべきである。設定は文書化され、適切なマネジメントからの承認がある場合にの み変更可能とすべきである。 • スタッフ—従業員は、自らの業務に従って個人情報を利用し、必要な許可を得るべきである。更に、従業 員は、定められた手続に従って情報システムを利用するために必要な知識を有すべきである。情報システ ムの利用許可は登録されるべきである。 223 G31 プライバシー • 守秘義務—従業員は、機密性が必要となるいかなる種類の個人情報も開示しないとの正式な合意書に 署名すべきである。守秘義務には情報セキュリティに関するその他の重要な情報も含むべきである。 • 物理的セキュリティ—組織は個人情報を処理するために利用されている技術的な機器への未承認のア クセスを防止するための対策を講じるべきである。セキュリティ対策には情報セキュリティに関するその 他の重要な機器も含むべきである。機器は、個人情報の扱いに影響を与えないような方法で導入される べきである。 • 機密性—企業は機密性が必要となる個人情報への未承認のアクセスを防止するための対策を講じるべ きである。セキュリティ対策には情報セキュリティに関するその他の重要な情報も含むべきである。外部 のパートナーへ電子的に転送される機密性のある個人情報は暗号化されるか、あるいはその他の方法 により安全性を確保されるべきである。機密性のある個人情報を含む、保存情報は適切に区別される べきである。 • インテグリティ—インテグリティに関する合理的な保証を提供するために、個人情報の未承認の変更に 対する対策が講じられるべきである。セキュリティ対策は、情報セキュリティに関するその他の重要な情 報に対する未承認の変更も防止すべきである。更に、悪意あるソフトウェアに対する対策も講じられる べきである。 • 可用性—個人情報へのアクセスに関する合理的な保証を提供するための対策が講じられるべきである。 セキュリティ対策には情報セキュリティに係わるその他の重要な情報も含むべきである。通常の業務を 遂行できなくなった状況下での情報へのアクセスについて合理的な保証を提供するためにバックアップ および復旧に関する定められた手続が存在すべきである。 • セキュリティ対策—情報システムの未承認の利用を防止し、未承認のアクセスを発見することを可能に するためのセキュリティ対策が講じられるべきである。セキュリティ対策には、スタッフによって影響され ない、あるいは承認を得ずに実行できない対策を含むべきであり、また、個人に対する訴訟に限定すべ きではない。セキュリティ対策は文書化されるべきである。 • 外部パートナーに対するセキュリティ—データ管理者は外部パートナーや納入業者に対する責任および 権限を明確にする責任を有している。責任および権限は書面にて正式化されるべきである。データ管理 者は、パートナーや納入業者のセキュリティ戦略に関する適切な知識を有し、また、セキュリティ戦略に より十分な情報セキュリティが確保されていることを定期的に確認しなければならない。 • 文書化—情報システムの利用および情報セキュリティに関連するその他の情報に関する手続は文書化 されるべきである。文書は、国内の法律や規制に従って保存されるべきである。情報システムからのイン シデントログは少なくとも3カ月は保存されるべきである。ポリシー、基準および手続は、個人情報の承 認された利用を特定するために整備されるべきである。 • 周知徹底および研修会—これらは、プライバシーポリシーを従業員やプロバイダ、特に顧客の個人情報 を取り扱う者（カスタマーサービス等）に伝達するために実施されるべきである。 6 計画策定 6.1 様々な国におけるプライバシー法の概要および主要な相違点 6.1.1 ほとんどの国では、独自のプライバシーに関する規制を既に制定している。原則は基本的に同じであるが、 個人データの定義、採用すべき基本的なセキュリティ対策等の観点において著しい相違点が存在してい る。これらの相違点は、特に業務の対象が1国以上となる場合および/あるいはデータの保存場所が他の 地域となる場合には、情報システム監査人の役割に影響を与え得る。 224 G31 プライバシー 6.1.2 表1は、1980年および2002年に経済開発協力機構（OECD）により公表された『プライバシー保護と個 人データの国際流通についてのOECDガイドライン』における一般原則を記載している。 表1 一般原則 番号 原則 説明 1 収集制限 個人データの収集は、データ主体の（明示的な）同意と認識がある場合、可能である。 2 データ品質 個人データは、それが利用される目的に関連付けられるものであり、この目的に必要となる 程度において、正確かつ完全であり、最新のものに維持されている。 3 目的特定 個人データの収集目的は、データ収集時より前に特定され、また、その後の利用については、 これらの目的やこれらの目的と矛盾せず、かつ、目的を変更する度に特定される他の目的の 達成に限定される。 4 利用制限 個人データは、上記の諸原則以外の目的のために開示、利用されてはならない（データ主 体の同意がある場合、または、法律に基づく場合を除く）。 5 安全保護 個人データは、その紛失や未承認のアクセス、破壊、利用、変更、開示のようなリスクから 合理的なセキュリティ保護措置によって保護されるべきである。 6 公開 個人データに関する開発、実務、方針については全般的に開示方針を有すべきである。個 人データの存在と性質、その主な利用目的、データ管理者の身元と通常の住所を知ること のできる手段を容易に利用できるようにすべきである。 7 個人参加1 個人は、データ管理者、又はその他の者に、データ管理者が自分に関するデータを持ってい るかどうかを確認する権利を有している。 8 個人参加2 個人は、自分に関するデータを以下のような方法で自分に伝えてもらう権利を有している： ・合理的な期間内 ・かかるとしても、過度にならない費用 ・合理的な方法 ・自分に分かりやすい形 9 個人参加3 個人は原則7および8の要求が拒否された場合にはその理由を知らされ、そうした拒否に異 義申し立てできる権利を有している。 10 個人参加4 個人は、自分に関するデータに異議を申し立て、その異議が認められた場合には、そのデー タを消去、修正、完全化、変更してもらう権利を有している。 11 個人参加5 個人が自分の個人情報の利用および破棄に関して考えを変えた場合に企業へそれを伝達 するための具体的な手続が定められ、また、これらの変更はその個人に関するデータが利 用されているあらゆるシステムやプラットフォーム上で反映されなければならない。 12 データ管理者 データ管理者には、上記の諸原則の実施措置を遵守することに対する説明責任がある。 の説明責任 225 G31 プライバシー 6.1.3 上記の原則に基づく表2のチェックリストは、各国の規制を比較するのに役立つとともに、原則が実際に どのように適用されるかのおおよその指標となる。 「参照」欄は表1に記載されている原則に対する参照番 号である。 表2 チェックリスト 番号 参照 質問 1 個人に関する個人データの収集は、いかなる種類の処理のためであっても、個人の明確な同意、個 人との間で締結された契約の履行、あるいは法律により明確に認められている他の条件なしには不 可能か。ただし、法の権限により実行され、また、収集者とは異なる主体により承認される公共や国 家の安全等の特殊な場合を除く。 2 1 （例えば、アウトソーシングで）個人データのアクセス/取り扱いが必要となるサードパーティにとっ て、個人データを収集および/あるいは処理することへの同意は必要か。また、同意は、元請業者へ の同意書とは異なる書面での合意により、データ主体によりなされなければならないか（言い換え れば、データ管理者はデータ主体の明快、明確な承認なしにサードパーティにデータへのアクセスを 行わせることはできないようになっているか）。 3 2 データ管理者は、データの正確性を定期的に検証するようになっているか。また、 （処理範囲に関 し）関連のない/過剰な/古くなった情報を更新、あるいは削除するようになっているか。 4 3 データ管理者は、データ収集の範囲についてデータ主体に伝達するようになっているか。 5 3 データ管理者は、データの利用をデータ収集時にデータ主体に伝達したものに限定するようになっ ているか。 6 3 データ管理者は、データの収集/処理の目的におけるいかなる変更もデータ主体に伝達し、承認を得 るようになっているか。 7 4 データ主体が明確に承認していない利用/開示を禁止するデータ利用の制約があるか。 8 5 未承認開示/利用からデータを保護するためにデータ管理者が要求する最低限のセキュリティ保護 措置に関する要件があるか。 9 5 データ管理者はセキュリティ計画を作成し、定期的に更新しなければならないか。 10 5 データ管理者はリスク評価を定期的に実施しなければならないか。 11 5 （データ管理者の組織に属する）個人を一意に特定でき、また、主体のデータへのアクセスを説明 できる要件があるか。 12 6 （個人、あるいは組織として）データ管理者の身元は、収集/処理されるデータの性質と同様、必ず データ主体に伝達されるか。 13 6 スタッフに個人情報の保護の要件を注意喚起するための研修、あるいは認識向上プログラムがある か。 14 7 データ主体は自分に関するデータの存在、あるいは性質に関する情報の提供をデータ管理者に依 頼することができるか。 15 7 データ主体は自分に関するデータをデータ管理者から入手、検証することができるか。 16 8 質問14および15への最長の回答期限が取り決められているか。 17 9 データ主体は自分に関するデータの存在/処理を自分に伝達することへのデータ管理者による拒否 に異義を申し立てることができるか。 18 10 データ主体は自分に関するデータをデータ管理者により消去してもらうことができるか。 19 11 データ主体は自分に関するデータを収集することに対する同意を（以前に同意していたとしても）い つでもいかなる人に対しても否定することができるか。 20 12 上記の諸原則を遵守しないデータ管理者に対する処罰はあるのか。 21 12 データ管理者が上記の諸原則を遵守していることを検証する義務のある組織はあるか。 226 G31 プライバシー 7 監査作業のパフォーマンス 7.1 組織におけるプライバシーの実務および手続のレビュー 7.1.1 情報システム監査人は、監査計画プロセスを十分に理解しているべきである。監査の範囲、目的および実 施時期を含む監査プログラムが作成されるべきである。監査プログラムには、報告に関する事項も明確に 記載されるべきである。 7.1.2 組織の特性や規模および利害関係者についても考慮すべきである。 越境関係（国内および国際の両方）に関する知識は重要であり、監査で要求される範囲や実施時期を決 定する際に役立つ。 7.1.3 情報システム監査人は、企業のミッション、事業目標、企業により収集、利用されるデータの種類およびプ ライバシーに関する要件を含む組織に適用される法律を理解すべきである。主要なスタッフの役割や責任 を含む、企業の組織構造への理解も必要である。 7.1.4 監査計画段階における第一の目的は、プライバシーに関する法律/規制を遵守しなかった場合の組織に対 するリスクを理解することである。 7.2 実施手順 7.2.1 情報システム監査人は、関連するプライバシーに関する法律を遵守しなかった場合の組織への影響を明ら かにするのに役立つプライバシーに関する予備的な評価を実施すべきである。これは、レビュー範囲の決 定に役立ち、また、組織内で様々な用途のために収集、保存および利用される情報の種類のような要素を 考慮すべきである。 7.2.2 情報システム監査人は、組織において以下の事項が整備されているかを確認すべきである。 • プライバシーポリシー • プライバシーオフィサー • データ管理者 • プライバシーに関する研修および周知に関する計画 • プライバシーに関する苦情管理プロセス • プライバシーに関する法律に関して実施されるプライバシー監査の体制 • 外部委託先および請負業者に対するプライバシーに関する要件 上記の事項のうち、存在するものについては、関連するプライバシーに関する法律および/あるいは規制に 沿っていることを確認するために、情報システム監査人によって評価されるべきである。 7.2.3 情報システム監査人は、プライバシーに関する影響度分析を実施すべきである。これには以下の事項が含 められるべきである。 • プライバシーに関する法律に遵守しないことのリスクの特定、分析および優先順位付け • 組織において現在整備されている様々なプライバシー対策の理解 • 弱みと強みの評価 • 改善のための戦略の勧告 7.2.4 プライバシーレビューの結果を記載した報告書は、情報システム監査人によって文書化されるべきである。 報告書には、目的・範囲の概要を含み、組織によって収集、保存および使用されるデータや情報の種類に 関する要約を提供すべきである。 7.2.5 報告書には、企業が抱えるプライバシーに関連するリスクの情報および存在するリスク低減策、あるいは プライバシー保護策の要約が含まれるべきである。 227 G31 プライバシー 7.2.6 リスク低減策の欠如、あるいは不適切な対策のためにプライバシーレビュー時に特定された欠陥について、 情報オーナおよびプライバシーポリシーに責任を持つマネジメントの注意を引くようにすべきである。 7.2.7 プライバシーレビュー時に特定された欠陥が、重要あるいは重大であると考えられる場合には、適切なレ ベルのマネジメントに対して、早急に是正措置を講じるように助言されるべきである。 7.2.8 情報システム監査人は、組織のプライバシーに関するコントロールを強化するための機会をマネジメントに 提供するため、適切な勧告事項を監査報告書に含めるべきである。 8 報告 8.1 セキュリティ対策に関する規制 8.1.1 国内におけるプライバシーに関する規制により、未承認のアクセス、不適切な開示、変更および/あるいは 紛失に関するリスクに対して個人データが適切に保護されていることを保証するためのいくつかのセキュリ ティ対策が実施されていることを求められるかもしれない。 8.1.2 以下は、国内においてプライバシーに関して求められる要件が満たされているという合理的な保証を提供 するのに役立つ主要なコントロールの一覧である。国内における法律、あるいは規制により、さらなる対策 を求められ得ることに留意すべきである。情報システム監査人は、監査を実施する前に、セクション6.1.3 の表2に記載したように、本表の適用可能性や網羅性を確認すべきである。 8.2 メディアの再利用 8.2.1 個人データを含むメディアや文書を保管するすべての従業員が正当な注意を払っているという合理的な保 証を提供する正式な手続が存在し、確認されるべきである。 8.2.2 以前個人データを含んでいたメディア（例えば、電子化/デジタル化されたもの、あるいは紙面）を再利用す る前に、すべての情報が削除済みであるという合理的な保証が提供されるべきである。データの機密度や メディアの種類により、メディア自体の破壊が必要となることもある。 8.3 研修 8.3.1 セキュリティ研修は、個人データを取り扱うすべての要員を対象として定期的に計画されるべきである。 8.4 アクセスコントロール 8.4.1 一般原則として、 「知る必要性」の原理が適用されなければならない（すなわち、誰でも自らの作業の遂行 に必要となるファイルおよびアーカイブのみへアクセス権が付与されるべきである）。 8.4.2 アクセス権限およびユーザIDは、本ポリシーに従って割り当てられるべきである。 8.4.3 従業員の退職、あるいは他部門への異動時にユーザIDを即時に変更/削除するための文書化された手続 が存在し、確認されるべきである。 8.4.4 パーソナルコンピュータの使用に関する適切な指示が出され、確認されるべきである。指示には、定期的 なバックアップの実施の必要性、ワークステーションを放置しないこと等、個々人のデータセキュリティに 関するあらゆる観点を含まなければならない。 8.4.5 内部ネットワークはファイアウォールのようなセキュリティ機器を使用することにより適切に保護されるべ きである。 8.4.6 個人データアーカイブを定められた時間内に復旧させるための緊急時対応計画が存在することが確認さ れるべきである。 228 G31 プライバシー 8.5 メンテナンスおよびサポート 8.5.1 メンテナンスおよびサポートのために行われるすべてのアクセスについて、ログが残され、モニタリングが行 われるべきである。 8.6 データインテグリティ 8.6.1 ウイルス対策ソフトがすべてのワークステーションにインストールされ、ソフトウェア会社から定期的に更新 されるという合理的な保証が提供されるべきである。 8.6.2 OSおよび適用されるすべてのソフトウェアのベンダに対して、パッチ/更新状況を定期的に確認すべきである。 8.6.3 データバックアップは、サーバ、メインフレームおよびパーソナルコンピュータに関して定期的に予定される べきである。 8.7 施設に対するアクセスコントロール 8.7.1 組織の施設に立ち入るすべての者は登録されるべきである。時間外勤務に来る従業員は管理簿に署名す べきである。 8.8 リスク分析 8.8.1 個人データに関するリスクおよび脅威を特定することを目的としたリスク分析が定期的に実施されるべきである。 9 適用開始日 9.1 本ガイドラインは、2005年年6月1日以降に開始される全ての情報システム監査に適用される。 全ての用語集は、ISACAのWebサイト、www.isaca.org/glossaryに掲載されている。 付録 参考文献 “AICPA/CICA Privacy Framework,” American Institute of Certified Public Accountants (AICPA) and Canadian Institute of Certified Accountants (CICA), 2003 “Guidelines for the Regulation of Computerized Personal Data Files,” Office of the United Nations High Commissioner for Human Rights, 1990 “The International E-commerce Standard for Security, Privacy and Service (Business to Business),” International Standards Accreditation Board (ISAB), IES: 2000 (B2B), 2000 “The International E-commerce Standard for Security, Privacy and Service (Business to Consumer),” International Standards Accreditation Board (ISAB), IES: 2000 (B2C), 2000 “OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data,” Organisation for Economic Co-operation and Development (OECD), 2002, 1980 “Privacy : Assessing the Risk,” The Institute of Internal Auditors (IIA) Research Foundation, April 2003 “Safe Harbor Privacy Principles,” US Department of Commerce, USA, 21 July 2000 “US Department of Commerce Safe Harbor,” US Department of Commerce, USA, www.export. gov/safeharbor 229 G32 IT視点からのビジネス継続計画（BCP） レビュー 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 231 2 IT の観点からの BCP の概要‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 233 3 独立性‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 235 4 能力‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 235 5 計画‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 235 6 IT の観点からの BCP レビューの成果‥ ‥‥‥‥‥‥‥‥‥‥‥‥ 236 7 報告‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 240 8 フォローアップ活動‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 241 9 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 241 G32 IT視点からのビジネス継続計画（BCP）レビュー 1 背景 1.1 基準との関連 1.1.1 基準S6『監査業務のパフォーマンス』は、 「監査の過程において、情報システム監査人は、監査の目的を 達成するために、確実で妥当な証拠を十分得るべきである。監査の発見事項と監査の結論は、この証拠 を適切に分析し、解釈することにより裏付けられる。」と述べている。 1.2 COBITとの関連 1.2.1 高レベルのコントロール目標DS4『継続的なサービスの保証』は、 「ITサービスの中断発生時のビジネス に対する影響を最小限に抑えることを、ビジネス要件とし、継続的なサービスの保証のITプロセスをコント ロールする。」と述べている。 1.3 COBITの参照 1.3.1 個々の監査範囲に適用可能であるCOBITの中から最も関連する材料の選択は、特定のCOBIT ITプロセ スを選択し、COBITのコントロール目標と関連するマネジメントの実行を勘案して行う。ITの観点からBCP のレビューでは、COBITに最も関連性の高いプロセスは、主要および副として以下に分類される。選択と 適応させるプロセスとコントロール目標は、特定のスコープおよび割り当ての基準の条件によって異なる。 1.3.2 主要な参照： PO9 リスク評価 AI6 DS1 サービスレベルの定義と管理 DS4 継続的なサービスの保証 DS10 問題管理とインシデント DS11 データ管理 DS12 物理的環境の管理 DS13 オペレーション管理 変更管理 1.3.3 副次的参照 PO4 IT組織とその関わりの定義 PO8 外部要件とコンプライアンスの保証 PO7 人材管理 AI5 DS2 サードパーティのサービスの管理 DS5 システムセキュリティの保証 DS9 構成管理 M1 インストールと認定するシステム プロセスのモニタリング 1.3.4 BCPのレビューに最も関連する情報要請規準： 主：有効性、効率性、可用性、およびコンプライアンス 副：機密性、インテグリティと信頼性 231 G32 IT視点からのビジネス継続計画（BCP）レビュー 1.4 ガイドラインの目的 1.4.1 今日の相互接続された経済では、組織はビジネスを中断させる技術的な問題の可能性にこれまで以上に 脆弱である。洪水や火災からウイルスやサイバーテロといったあらゆる災害は、ビジネスに不可欠な情報の 可用性、完全性と機密性に影響を与える可能性がある。 1.4.2 BCPの主な目的は、すべてまたはその業務・情報システムサービスの一部が使用不能の状態にされた場合 に組織のリスクを管理し、そのような事象の影響から回復するために組織を支援することである。 1.4.3 本ガイドラインの目的は、ITの観点から事業継続計画（BCP）のレビューの実践において推奨されるプラ クティスを記述することである。 1.4.4 ガイドラインの目的は、主と副の両方から、関連するコントロール目標を達成するために組織に導入され た、ITの観点、から、BCPのプロセスに関連するコントロールと関連するリスクを特定し、文書化し、テスト し、評価することである。 1.4.5 本ガイドラインは、ITの観点から事業継続計画のレビュー中に十分な、信頼性、関連性の高い有益な監 査証拠を入手するために情報システム監査基準S6『監査業務のパフォーマンス』におけるガイダンスを提 供する。情報システム監査人は、上記の基準の導入の実現、そのアプリケーションの専門的な判断の使用、 いくつかのずれを正当化するために準備する方法を決定する上で、それを考慮する必要がある。 1.5 ガイドラインの適用 1.5.1 組織におけるITの観点からBCPのレビューを行う際に本ガイドラインが適用される。 1.5.2 本ガイドラインを適用する場合、情報システム監査人は、他の関連するISACAの基準およびガイドライン との関係で、そのガイダンスを考慮する必要がある。 1.6 用語 1.6.1 略語： 事業継続計画（BCP） ビジネスインパクト分析（BIA） 災害復旧計画（DRP） 1.6.2 事業継続計画は、事前の手配を拡張するプロセスや、重要なビジネス機能を中断または本質的な変更の計 画されたレベルで続行するような方法で組織が中断に対応できる手順を指す。単純な用語では、BCPは積 極的に事業が影響を吸収できる程度に影響を制限しながら、災害の影響を防ぐか、可能であれば、管理す る方法を戦略的に行う行為である。 1.6.3 用語BCPは、事業継続計画の完全なプロセスを指し、それは特にビジネス、技術、人間と規制的側面が含 まれている。 1.6.4 BCPは、役割と責任を定義し、ビジネスインパクト分析に基づく高可用性とシステムの信頼性を確保する ために必要な重要な情報技術のアプリケーションプログラム、オペレーティングシステム、ネットワーク、人 材、施設、データファイル、ハードウェアと時間枠を識別する。BCPは、災害前、災害時や災害後に、取ら れる一貫性のある行動の包括的な記述である。理想的には、BCPは、混乱の事象の中で事業を継続し、ク リティカルな情報システムへの破滅的な中断から生き残ることが可能になる。 1.6.5 BIAは、重要なビジネス機能とワークフローを一致させ、混乱の定性的および定量的影響度を決定し、目 標復旧時間（RTO）を優先順位をつける。 232 G32 IT視点からのビジネス継続計画（BCP）レビュー 1.6.6 BCPの重要な構成要素であるDRPは、BCPの技術的側面を示す。災害の発生時に損失を最小限に抑え、 重要なビジネス機能の継続性を確保するために必要な事前準備の計画である。DRPは、災害中、災害後、 一貫性のあるアクションを実施するために構成されている。DRPは、エンタープライズビジネスプロセスの すべてを含む、包括的な計画プロセスから作成される。災害回復戦略は、代替のサイト（ホット、ウォームと コールドサイト）、冗長なデータセンター、相互協定、通信リンク、災害保険、ビジネスインパクト分析と法 的責任の使用を含む。 2 ITの観点からのBCPの概要 2.1 ITの観点からのBCPのコンポーネント 2.1.1 BCPのITコンポーネントは、IT運用の可用性を保証する応答と回復のプロセス、ビジネスプロセスをサ ポートする上で重要な手順、アプリケーション、オペレーション、システム、データストレージ、ネットワーク および施設の再統合を定義している。 2.1.2 BCPのコンポーネントは次のとおりである。 • 識別－事業の潜在的な脅威やリスクを識別する。 • 予防－防止または事故の可能性を防止、または、最小限に抑える • 検出－組織が不測の状況に入ることを決定する状況を識別する • 宣言－不測の事態が宣言されている条件を指定し、それを宣言することができる者達を識別する • エスカレーションー不測の事態がエスカレートされている条件を指定し、不測の事態が発生した場合の 個人とエスカレーションの順序を特定する。 • 抑制－顧客、サプライヤー、サービスプロバイダ、利害関係者、従業員、資産、公務やビジネスプロセスへ の影響を抑制するか、最小限に抑えるのに必要な即座の行動を指定する。 • 実装－不測の状態を宣言するために従うべき行動の完全なリストを指定する。 （このようなオフサイト 処理、バックアップ、リカバリ、オフサイトのメディアとマニュアル、従業員の交通、および物流とプロバイ ダ契約など） • 回復－回復はビジネスへの不利な影響（たとえば金銭的損失やイメージの破損など）が最小限に抑え、 迅速なリカバリを容易にし、許容可能な時間枠内に災害発生時の組織の重要なビジネス機能をサポー トするコアの技術資産の継続性を確保するために必要な事前の計画と準備である。レビューされる主要 な要素は以下のとおりである。 –– 再開－中断した後に、宣言された故障平均時間（MTBF）の前にクリティカルで時間に敏感なプロセ スの再開 –– リバイバル－重要な、より少ない時間に依存するプロセスの復活は、重要なプロセスの再開に関連し ている –– 修復－修復し、元の状態にサイトを復元し、全体で事業を再開、または所定の位置に完全に新しいサ イトを入れること –– 再配置－一時的または永続的に中断することに応じて別のサイトに移転。移転は、すべての種類の 中断には必要とされていない可能性がある。 –– 危機管理－組織の収益性、評判、または運用能力への損害を回避または最小限に抑えることを目的 とした効果の高い、タイムリーに危機に対する組織の対応の総合調整 233 G32 IT視点からのビジネス継続計画（BCP）レビュー 2.2 BCPの要素 2.2.1 BCPの重要な要素は、ソースを含む潜在的な脆弱性および脅威を、識別と分析のタスクを含むリスクア セスメントである。リスクアセスメントは、組織への潜在的なリスクを識別し、事業を継続するため組織の ために必要な重要な機能を評価し、リスクを軽減するためにコントロールを定義し、そのようなコントロー ルのコストを評価するプロセスが含まれます。リスクアセスメントの結果となるリスク便益分析は、必要な コンティンジェンシーおよび緩和行動と一緒に潜在的な脅威と関連する脅威を詳しく説明し、リスクをカ バーすることから生ずる利益を記述することにより結論付ける。 2.2.2 BIAに続くリスクアセスメントは、全体的な財務脅威および事業活動の中断に起因する運用上の影響を 評価するために実行する必要がある。BIAは、識別し、情報システムインフラを含め、これらに限定されな い、さまざまな混乱のシナリオ内のコントロールの費用便益分析によりサポートされる重要なビジネスプロ セスの優先順位付けに役立つはずである。 2.3 BCPの主な要因 2.3.1 BCPは、下記を満足する必要がある。 • 理解可能であり、使用および保守が容易である。 • 通常のシステム処理の中断、および効果的なBCPを開発し、維持するために必要な総作業に起因する ビジネスへの悪影響の包括的な理解と管理を提供する。 • 努力の支援と参加ために幹部管理レベルのコミットメントを取得する。 • コアビジネスプロセスに関連する重要な情報リソースを識別する。 • データの機密性と整合性を維持するためのメソッドを識別する。 • その重要度を決定するために、各ビジネスプロセスを評価する。重要度の兆候は、次のとおりである。 –– プロセスは、生活や人々の健康と安全をサポートしている。 –– プロセスは、法的または法定の要件を満たすことが必要である。 –– プロセスの破壊は、収益に影響を与える。 –– 顧客のことを含む業務上の信用への潜在的な影響がある。 • 計画への注意を以下に集中する。 –– 災害管理 –– 災害が管理できない不測の事態で、災害の影響を最小限に抑えること –– 整然とした回復 –– 運用とキーサービスの継続性 • 様々なシステムとビジネス目標への適合性のためのRTOとリカバリポイント目標（RPO）を検証する。 • コンティンジェンシープランをアクティブにする条件を識別する。 • どのリソースが、不測の事態の段階と、それらが回復される順序で利用できるようになるかを識別する。 • リカバリに必要なイネーブラ（人と資源を）識別する。 • 計画を開発するためのコアとの重要な機能領域の妥当な表現を提供するために、技術とビジネス環境 に準拠したプロジェクトチームを選択する。 • イネーブラ、サポートスタッフと社員間のコミュニケーションの方法を識別する。 • オペレーションのリカバリに関連する地理的条件を特定する。 • ビジネス機能の観点からリカバリ要件を定義する。 • BCPの考慮事項が、時間をかけて実行可能な計画のために継続的な事業計画やシステムの開発プロセ スにいかに統合されているかを定義する。 234 G32 IT視点からのビジネス継続計画（BCP）レビュー • 技術やプロセスの変化がある場合に特に、法的またはビジネス要件文書のタイムリーなアップデートと 同じようにBCPの継続的な適合性の定期的なレビューのためのプロセスを実装する。BCP戦略はまた、 リスク評価と脆弱性評価の結果に基づいて変更されることがある。 • 管理、運用および技術的試験を含む包括的なBCPのテストアプローチを開発する。 • 保守を容易にする変更管理と適切なバージョン管理のプロセスを実装する。 • 当初の計画と比較して、追加のまたはより少ない数のリソースに起因する回復の優先順位を変更するた めの機構や意思決定者を識別する。 • 正式なトレーニングのアプローチを文書化する。 3 独立性 3.1 プロフェッショナルの独立性 3.1.1 情報システム監査人が、組織内のBCPに関連するプロセスの設計、開発、実装や保守に以前関わっていて、 監査業務に割り当てられている場合には、監査の独立性が損なわれる可能性がある。利害の衝突が起き る可能性のある場合には、同じことが明示的に組織に伝達される必要があるし、組織の同意は、割り当て を受け入れる前に書面で取得する必要がある。情報システム監査人は、このような状況に対処するための 適切なガイドラインを参照する必要がある。 4 能力 4.1 スキルと知識 4.1.1 情報システム監査人は、監査人がBCPとそのコンポーネントのレビューを行うために必要な知識とスキル を持っている合理的な保証を提供する必要がある。 4.1.2 情報システム監査人は、BCPは、組織のニーズに沿ったものであるかどうかを判断するための能力を持っ ているべきである。 4.1.3 情報システム監査人は、BCPに関連した側面を検討する十分な知識が必要である。専門家のインプットが 必要な場合、適切なインプットは、外部の専門的なリソースから入手する必要がある。外部専門家のリソー スが使用されるという事実は、書面で、組織に伝達される必要がある。 4.1.4 BCPのレビューは、基本的に企業に固有である。有効であるレビューのために、情報システム監査人は、 最初に、組織の使命の理解、組織に固有の法定または規制の要件、ビジネスの目的、関連するビジネスプ ロセス、これらのプロセスのための情報要件、情報システムの戦略的価値と企業/組織の全体的な戦略と 整合する範囲を含むビジネス環境の全体的な理解を得なければなりません、 4.1.5 情報システム監査人が必要な知識、能力、スキル、リソースを持っている場合にのみ、情報システム監査人 はBCPやポリシーの開発、テストおよび復旧計画を実施する必要がある。情報システム監査人は、このよ うな状況に対処するための適切なガイドラインを参照する必要がある。 5 計画 5.1 範囲とレビューの目的 5.1.1 情報システム監査人は、組織とし適切な協議の上、明確にBCPのレビューの範囲と目的を定義する必要が ある。レビューの対象とする観点が明示的に範囲の一部として記述されるべきである。 5.1.2 レビューの目的のためには、レポートのソリューションと受信者の利害関係者も認知され、組織と合意す る必要がある。 235 G32 IT視点からのビジネス継続計画（BCP）レビュー 5.2 アプローチ 5.2.1 情報システム監査人はレビューの範囲と目的が客観的かつ専門的な方法で満たすことができるような方法 で監査アプローチを策定する必要がある。 5.2.2 監査のアプローチは、組織におけるBCPのフェーズに依存する。 5.2.3 アプローチでは、BCPのレビューがアクティブで安定したメンバーだけでなく、ユーザグループとの議論を 含むチームの努力であることを考慮する必要がある。 5.2.4 アプローチは適切に文書化され、必要に応じて、外部専門家のインプットの要求事項を特定する必要がある。 5.2.5 たとえば、ビジネスプロセスや技術とリスク評価の結果の優先順位付けなど、重要な領域は、必要に応じ て計画が効果的に実装されている合理的な保証を提供する必要がある。 5.2.6 組織的な慣習に応じて情報システム監査人は、BCPの監査計画とアプローチのための組織の同意を得る ことができる。 6 ITの観点からのBCPレビューの成果 6.1 実行 6.1.1 計画プロセスの一部として定義されたアプローと同じようにレビューの意図する範囲と客観性を考慮して、 レビューする観点と、レビュープロセスは決定されるべきである。 6.1.2 一般的には、利用可能なドキュメント（例えば、BCP、DRP、BIA、ビジネスリスクの分析と企業のリスク管 理のフレームワークなど）の研究は、データを分析、解釈、収集に適切に使用する必要がある。この情報の すべてが容易に入手できないかもしれないが、最低限のITベースのリスクと一緒に重要なビジネスプロセス を定義する基本的なリスク評価の分析が必要になる。 6.1.3 BCPのリスクの主な分野は、以前に検出されたBCPの弱点と最後のBCPのテスト以来、システム環境（た とえばアプリケーション、機器、通信、プロセスや人々など）に導入された変更が含まれている必要がある。 6.1.4 以前に指摘されており、フォローアップが必要な場合があるBCPに関連する問題を識別するには、情報シ ステム監査人は以下の書類を確認する必要がある。 • インシデントのレポート • 前回の審査報告 • フォローアップ活動 • 前回の検査からの監査調書 • 内部および外部の監査報告書 • 内部の試験報告書と是正措置の計画 • 公表された業界の情報と参照 6.1.5 システム環境の変更を識別するには、情報システム監査人は、組織の要員やサービスプロバイダへのイン タビューだけでなく、支出の記録とレポートを分析し、IT施設検査し、ハードウェアとソフトウェアのインベ ントリをレビューし、適切なデータを分析するための特殊なソフトウェアを使用すべである。 6.1.6 情報システム監査人は、テストの次のフェーズのそれぞれをレビューで考慮する必要がある。 • 予備テスト―実際のテストのための段階を設定するために必要なアクションのセット • テスト―BCPのテストの実際の行動 • 事後テスト―集団活動のクリーンアップ • 実施後のレビュー―プランの実際の実践の次のアクションのレビュー 6.1.7 テスト計画の目的は、テスト計画が次のことが実現するかどうかを確認するためにレビューされるべきである。 • BCPの完全性と精度を検証する • BCPに携わる担当者のパフォーマンスを評価する 236 G32 IT視点からのビジネス継続計画（BCP）レビュー • チームの訓練と意識を評価する • BCPチーム、DRPチーム、外部ベンダーやサービスプロバイダとの連携を評価する • 組織の要件を満たすバックアップサイトの能力とキャパシティを測定する • 重要なレコードの検索能力を評価する • リカバリサイトに再配置された状態と機器および消耗品の量を評価する • 組織の運用および処理活動の全体的なパフォーマンスを測定する 6.1.8 BCPのテストは、ビジネスプロセスに混乱を避けるために注意深く設計する必要がある。BCPのテストの 適切な領域は、リスクの年次レビューの一環として特定されるべきであり、取り組みの重複は避けるべきで ある。BCPのテストの計画のレビューにおいて、情報システム監査人が確認する必要がある事項。 • テスト計画の範囲と目標 • 頻度、方法論とテスト計画の改訂 • テストの種類、適切性および十分性 • アプリケーション • データのボリューム • ビジネスエリア • ネットワークの再ルーティング • システムの脆弱性、浸入および発生率の応答 • 変更、構成、およびパッチ管理 • 監査証拠の基準と要件 • テスト環境は運用環境の代表であり、例外は文書化されている • テストの有効性とリスクアセスメントとビジネスインパクトの結論との関係 6.1.9 事後シナリオの見直しにおいて、情報システム監査人が確認する必要がある事項。 • 混乱の原因と性質 • 人員、インフラや装置の損傷の程度 • 影響の重大度 • 進行中である代償措置 • 影響を受けたサービス • 損傷したレコード • 修復可能なアイテム • 修復、復元および/または置き換え可能な項目 • 保険の請求 • 影響を受けたプロセス • ITプロセスを復元するための時間 • 行動計画、復旧チーム、役割と責任 6.1.10 推論や勧告は、データの客観的な分析と解釈に基づいている必要がある。 6.1.11 適切な監査証跡が収集されたデータ、行われた分析、結論付けられた推論、推奨された是正措置のために 維持されるべきである。 6.1.12 観察と提言は、終了報告をする前に、必要に応じて、組織で検証する必要がある。 237 G32 IT視点からのビジネス継続計画（BCP）レビュー 6.2 レビューの観点 6.2.1 一般的に、BCPは、次のような重要な問題に対処する必要がある。 • なぜそれが行われる必要があるか？ • それはどのようにすればよいか？ • 誰がそれをする必要があるのか？ • 策はあるのか？ • いつそれをすればよいのか？ • どこにすればよいか？ • どのような方針、ルールや基準のもとでそれをすればよいか？ • 誰が計画を変更し、どのような状況下でできるか？ • どのような条件の下で、災害は、'終了'は宣言されるか？ 6.2.2 以下の組織的な観点が考慮されていることをレビューされるべきである。 • BCPは、組織全体のミッション、戦略目標と事業計画と整合的である • BCPは、定期的に更新され、現状を考えられている • BCPは、継続した適合性のために、定期的にテストされ、レビューされ、確認される • 予算配分は、BCPのテスト、実装とメンテナンスのため有効である • リスク分析は定期的に行われている • 正式な手続きは、定期的にITとテレコムのインベントリを更新するために配備されている • 組織の管理と人員がBCPを適用するために必要なスキルを持ち、適切なトレーニングプログラムが実 施されている • 有事の場合には適切なコントロール環境を（たとえばデータとメディアへのアクセスの義務とコントロー ルの分離など）を維持するための措置が適切に配置されてりる • イネーブラは、識別され、個人の役割と責任が適切に定義されて、公表され、伝達されている。通常、こ のような緊急のアクションチーム、損害評価チームと緊急事態管理チームなどのコアチームが構成され ている。コアチームは、オフサイトストレージのチーム、ソフトチーム、アプリケーションチームおよびセ キュリティチームによってサポートされる。緊急運用チーム、ネットワークの復旧チーム、通信チーム、輸 送チーム、ユーザのハードウェアチーム、データの準備や記録のチーム、事務サポートチーム、物資供給 のチーム、救助チーム、および移転のチームがある • 通信チャネルは完全に組織内に記載して公表されている • 組織内のインタフェースおよび部署/部門間の影響が理解されている • 外部のサービスプロバイダの役割と責任は、特定され、文書化され、伝達されている • 外部のサービスプロバイダと顧客との調整の手続きは文書化し、伝達されている • BCPチームは、様々なBCPのタスク、明確に確立している役割と責任と説明責任を定義する管理報告 のために確認されている • 法定や規制要件の遵守が維持されている 238 G32 IT視点からのビジネス継続計画（BCP）レビュー 6.2.3 以下の計画の観点が考慮されていることがレビューされるべきである。 • 各プロセスを構成するアクティビティを決定する方法論は、主要なビジネスプロセス分析の一環として整 備されている。 • BCPための計画されたIS技術アーキテクチャが実現可能であり、ビジネスの中断が主要なITプロセスに 影響を与える場合、安全かつ健全な業務になる。 • リスクアセスメントとBIAは、BCPの実施前に行われている • BIAは、リスクの変化やBCPの対応する効果が含まれている • BIAは、重要なビジネスプロセスのキーリカバリの時間枠を識別している • リスクの定期的なレビューがある • 内部または外部のイベントを含んで、予期せぬ出来事から生じる問題を、管理し、包含し、、最小限に抑 えるための適切なインシデント対応計画がある。 • 適切なスケジュールが、BCPのテストと保守のために配備されている • イベントとその潜在的影響のオンサイトテスト、シミュレーション、トリガが実行される必要がある • BCPのライフサイクルが存在し、それが開発、保守およびアップグレード中に続いているかどうか • BCPは、組織への継続的な適合性を確認するために定期的に見直される 6.2.4 以下の手続きの観点が考慮されていることがレビューされるべきである。 • トップマネジメントは、BCPの実装における重要な原動力である。 • 最優先順位が、従業員、職員および重要なリソースの安全のために提供されている • リソースとその回復が優先され、復旧チームに伝達されている • 意識付けは、災害時に事業への影響を、組織全体に作成される • 適切な緊急時の対応手順が適切に配置され、テストされている • 災害査定/回復過程に関与する人々は明確に識別され、役割と責任は、組織全体で区分けされている • 訓練の適切なレベルが、模擬テストの訓練を含めて実施している • 避難計画が適切に配置され、定期的にテストされている • バックアップ人的資源が特定されており、利用可能になっている • 携帯電話、電話または他のそのような通信手段は、レビューされ、テストされ、定期的に更新される。 • 代替コミュニケーション戦略が認知されている • バックアップおよびリカバリの手順は、BCPの一部になっている • バックアップが回復可能である。 • 適切なバックアップローテーションの練習が実施されている • オフサイトの場所（ホット、ウォームまたはコールドサイト）が可用性と信頼性のテストをされている • 適切なオフサイトの記録は維持される • データと情報の機密性と整合性が維持されている • 適切なメディアリエゾン戦略が配備されている • BCPは、定期的にテストされ、テスト結果が文書化されている • テストの結果に基づいて是正処置が開始されている • 適切な保険の保護がある 239 G32 IT視点からのビジネス継続計画（BCP）レビュー 6.3 情報システムのアウトソーシング 6.3.1 サービスプロバイダのビジネスへの悪影響や混乱は、組織とその顧客に直接影響する。組織は、IS活動の 部分的または完全にその中の一部または全部をBCPのプロセスに影響を与えるようなサービスの外部プ ロバイダ（サービスプロバイダ）に委任している場合には、情報システム監査人は、サービスプロバイダの BCPプロセスが組織のBCPや文書化された契約や合意、サービスのユーザに残る規制と適合するかどう かを確認すべきである。 6.3.2 レビューはまた、アウトソーシングサービスプロバイダとの契約には、情報システムサービスと製品の提供 を伴う手段、方法、プロセスおよび構造の記述だけでなく、品質のコントロールが含まれていることを確認 する必要がある。 6.3.3 情報システム監査人は、アウトソーシングサービスの内容、時期および範囲の理解を得る必要がある。情 報システム監査人は、は、サービスプロバイダのビジネス継続性BCPのビジネス要件に対処するために配 備されたサービスのユーザのコントロールを確立する必要がある。情報システム監査人は上記のほかに、 外注活動のレビューに以下のすべての監査の要件を考慮する必要がある。 • 合意は、組織が必要と認めたとして、サービスプロバイダを監査するために、オープンで妨げられること のない権利を提供するかどうか • 契約は、サービスプロバイダの業務を中断した場合の組織のために適切な保護を提供するかどうか • 協定は、災害時にサービスの継続性を提供するかどうか • サービスプロバイダと組織のデータの整合性、機密性と可用性 • アウトソーシング契約/アウトソーシングによる忠誠心の欠如以上の不満を抱いた組織の担当者 • サービスプロバイダの施設内での制御/セキュリティの管理にアクセスする • サービスプロバイダによる違反報告とフォローアップ • ネットワーク制御、変更管理およびサービスプロバイダの施設内でのテスト 7 報告 7.1 報告の内容 7.1.1 情報システム監査人は、BCP、想定されたリスクに関連するプロセス、設備や技術に関するレポートと、不 測の事態の場合にはいかにそれらのリスクが管理されているか作成すべきである。レビューのパフォーマン スのモニタリングは、重要な成功要因である。BCPレビューの結果として生成されるレポートは、以下の観 点を含める必要がある。 • 対象範囲、目的、期間、方法論と仮定 • 主要な長所と短所の面でのソリューションだけでなく、弱点の可能性影響の総合的な評価 • 重大な弱点を克服すし、ソリューションを向上させるための勧告、 • あらゆる不適合の影響に沿ってCOBITのコントロール目標、関連する管理のコントロールプラクティス とCOBIT情報要請規準の遵守の程度 • ITシステムが中断した場合でも許容される時間枠内に回復できることを保証するためにBCPのプロセス と関連する内部コントロールについての合理的な保証。報告書は結論、推薦や任意予約や資格要件を 明記すべきである。 • いかに経験が同じような将来のソリューションや取り組みを改善するために使用できるかに関する推奨事項 • 割り当ての範囲に応じて、他のトピック 7.1.2 報告書は、いずれかが確立されている場合、管理と監査委員会の適切なレベルに提出する必要がある。 240 G32 IT視点からのビジネス継続計画（BCP）レビュー 7.2 欠点 7.2.1 コントロールの欠如か、貧弱な実装や合意できるレベルに関連するリスクの代償措置がないによりBCPの レビューで識別された欠点は、ビジネスプロセスの所有者とBCPの実装に責任がある情報システムマネジメ ントが注目すべきである。BCPのレビュー中に識別された欠点が重大または影響が強いと見なされる場合 には、経営陣の適切なレベルは、直ちに是正措置を実施することを進めるべきである。 7.2.2 効果的なBCPのコントロールは、ビジネス継続計画のプロセスと関連するコントロールに依存しているの で、関連するコントロールの欠点も報告されるべきである。 7.2.3 情報システム監査人は関連するリスクを軽減するためのコントロールを強化するために、レポートの適切な 勧告を含める必要がある。 8 フォローアップ活動 8.1 適時性 8.1.1 BCPの弱点の影響は通常広範囲であり、ハイリスクである。したがって、情報システム監査人は、必要に応 じて、その弱点に対処するための管理アクションが速やかに取られるかどうかを確認するのに十分な、タイ ムリーなフォローアップ作業を実施すべきである。 8.2 有効性 8.2.1 レビューの有効性の合理的な保証を提供するために、情報システム監査人は、勧告が実施されていること を監督し、実装された是正措置の有効性を検証するためのフォローアップレビューを実施すべきである。 9 適用開始日 9.1 本ガイドラインは、2005年9月1日からすべての情報システムの監査に適用される。 用語の完全な用語集は、www.isaca.org/用語集でISACAのウェブサイトで見つけることができる。 241 G33 インターネット使用における一般的考慮点 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 243 2 インターネット接続の一般的考慮点‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥ 245 3 セキュリティの測定‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 249 4 企業を表現するためのチャネルとしてのインターネット利用‥ ‥‥ 252 5 監査業務 / 安全性レビューのパフォーマンス‥ ‥‥‥‥‥‥‥‥‥ 253 6 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 257 G33 インターネット使用における一般的考慮点 1 背景 1.1 基準との関連 1.1.1 基準S４『専門家としての能力』では、 「情報システム監査人は、監査業務を遂行するための技能と知識を 有し、専門家としての能力を備えているべきである。」と述べている。 1.1.2 基準S5『計画策定』では、 「監査の目的を満たし、関係諸法規と当該分野の諸監査基準に準拠するよう、 情報システム監査の範囲を定めた計画を策定すべきである。」と述べている。 1.1.3 基準S6『監査業務のパフォーマンス』では、 「監査プロセスは、監査用と監査発見事項と監査の結論を 裏付ける監査証拠を記述するために、文書化されるべきである。」と述べている。 1.2 補完的ガイドラインと手続との関連 1.2.1 ガイドライン • G22 B2C イーコマースレビュー • G24 インターネットバンキング 1.2.1 手続き • P2 デジタル署名とキー管理 • P３ IDSレビュー • P6 ファイアーウォール • P8 セキュリティ評価- 侵入テストと脆弱性分析 • P9 暗号化方法論におけるマネジメントコントロールの評価 1.3 COBITの参照 1.3.1 COBIT適用における最も関連する特定の監査範囲項目の選択は、特定のCOBIT ITプロセスとCOBITの コントロール目標、および関係するマネジメント実践項目の選択に基づいている。情報システム監査人の責 任、権威、説明責任の要求事項に合致するために、COBITに最も関連し、選択され、適用されるプロセス は下記記載の主項目と副次項目に層別される。選択され、適用されるプロセスとコントロールの目標は特 定の範囲と適用の参照項目に従って異なってもよい。 1.3.2 主： • M2 内部統制の精確な評価 • M3 独立保証の獲得 • M4 独立監査への提供 1.3.3 副： • PO６ マネジメントの意図と指針の周知 • PO7 人材の管理 • PO8 外部要求への準拠性確立 • DS1 サービスレベルの定義と管理 • DS2 サードパーティのサービスの管理 • DS10 問題管理 • Ｍ１ プロセスをモニタリングする 243 G33 インターネット使用における一般的考慮点 1.3.4 インターネット利用に最も関連する情報要請規準： • 主：有効性、効率性、機密性 • 副：有用性、インテグリティ、信頼性 1.4 ガイドラインの必要性と目的 1.4.1 情報システム監査人は迅速に変化する情報技術、それが関連する脆弱性と潜在的な脅威への対応とい う重要な役割を演じている。このガイドラインの目的はインターネット利用、およびそれへのアクセスのレ ビューにおける推奨される実践規範を記述するものである。情報システム監査人は組織の資産を防御する ために関連するコントロール目的を実現させるコントロールと関連するリスクを識別し、文書化し、テスト し、評価する事が出来るべきである。 1.4.2 このガイドラインは情報システム監査標準S6『監査業務のパフォーマンス』への適用としてのインターネッ ト接続のレビュー時の充分で信頼ある、および関連し有益な監査証跡の取得ガイダンスを提供する。情報 システム監査人は、上記の標準の実装を達成する方法を決定するアプリケーションにおいて専門的な判断 を下し、逸脱を調整する準備をする際において考慮すべきである。 1.4.3 インターネットは、企業において益々インフラストラクチャの一部になってきており、しばしば複数の目的に 利用される。一般的に、インターネットの利用は次の様に、４つの部分に分けることができる。 • 情報の収集と共有の資源として • コミュニケーションチャネルとして • 企業、組織あるいは個人の表現の窓として • 商取引の場として このガイドラインはインターネットのコンミュニケーションチャネルとして、および企業や組織の情報資源と しての利用を主に方向づける。ガイドラインはある程度ではあるが、インターネットの表現と商取引として の扱いも行う。 1.4.4 企業は、インターネット接続により多くの脅威にさらされている。それらの脅威に対応するためには、リスク 分析を実施し、必要となる安全性の事前注意措置を行うことが重要となる。また、インターネットが静的な ものではないことに注意することも重要となる。頻繁に変化するため、脅威に対して安全性測定の必要性 がある。 1.4.5 全てのサービスや異なる脅威に関する事例が言及される。それら包括的にも簡単な文書でもリスク構造を 完全にカバーすることができない。新たなハッカーツールが出現し、ＩＴシステムにおける新たな安全性上 の弱点が継続的に公開されている。従って、インターネット接続の前に脅威や安全性測定対応する更新さ れた情報を入手することが重要となる。 1.4.6 インターネット利用の接続における包括的あるいは国際的に中央制御されたものは無い。必要となる事前 のセキュリティへの配慮は、どの企業にとっても課題となっている。 1.5 ガイドライン適用 1.5.1 このガイドラインを適用する場合、情報システム監査人は関連するＩＳＡＣＡの標準、ガイドライン、手続き を考慮すべきである。このガイドラインは、必ずしも完全なものではなく、適時更新されているものではな い。 244 G33 インターネット使用における一般的考慮点 2 インターネット接続の一般的考慮点 2.1 インターネット接続方法 2.1.1 数種類の接続方法があり、それぞれ異なる安全性測定の必要性がある。下記はいくつかの例。 • インターネットサービスプロバイダー（ＩＳＰ）を通してモデムに接続されたＰＣの取り外し • ＩＳＰを通してモデム接続されているローカルネットワーク上のＰＣ • モバイルデータ通信に接続されているＰＣの取り外し • モバイルデータ通信に接続しているローカルネットワーク上のＰＣ • ルーターを通してインターネットに接続されたローカルネットワーク • ファイアーウォールを通してインターネットに接続されたローカルネットワーク • ２つの分離されたネットワーク、つまり組織活動に利用されるＰＣが接続されるローカルネットワークとイ ンターネットコミュニケーションのためのＰＣが接続されるネットワーク 2.1.2 これらの接続のいくつかは、サービスデリバリーあるいは情報チャネルとしてのインターネット利用におい て結合されることができる。例えば、 • ローカルネットワークにおかれたサーバから内部/外部のサービスを提供するインターネットに接続され たローカルネットワーク • ＤＭＺに位置付けられるサーバから内部/外部サービスが提供されるインターネットへ接続されるローカ ルネットワーク • コミュニケーションチャネルとしてインターネットを使い同一の企業内で接続される２つのローカルネッ トワーク • インターネットがコミュニケーションチャネル（エクストラネット）として利用されるパートナーのネット ワークとの組織的コラボレーションとして接続されるローカルネットワーク 2.2 脅威 2.2.1 外部接続がないクローズなネットワークにおける脅威は、一般的に技術的失敗、ユーザエラー、システムの 誤った利用、忠誠心の無い従業員が機密情報を拡散させる事を含むことになる。このリスク図は企業がイ ンターネットへ常時接続されている状況で変化する。 245 G33 インターネット使用における一般的考慮点 2.2.2 アタックは次のグループに分類することができる。 • 受動的攻撃の例。 –– ネットワークモニタリング 盗聴ソフトウエア利用によりインターネット上を通過しているユーザ名、 パスワードを読むこと –– データの傍受 イーメイルの入出力を読んだり、コピーしたりして機密情報を取得すること –– スパイウエアの使用 広義の悪意あるソフトウエアを使用し、ユーザへ通達された同意事項なしにコ ンピュータ操作の部分的コントロールへ途中介入したり取得すること。通常、ユーザは訪問先となる ウェブサイトにより影響を受けている • 能動的攻撃の例。 –– 安全性測定の弱点を通してアクセス試行する 安全性測定が適切に実装されていない状況で認証な しにローカルネットワークと内部のＩＴシステムにアクセスすること –– パスワードを取得する フリーウエアを使用してパスワードファイルにアクセスすること –– マスキング 機密情報へのアクセスを取得するための信頼できるネットワークアドレスにあるコン ピュータの構成を行うこと –– ウィルス感染 ＩＴシステムの中に自分自身を悪意あるコードで蔓延させること、そして稼働中の他の システムとコンピュータに蔓延させること –– トロイの木馬 有用な機能を持ちそうに見える悪意あるプログラムを使用する、しかしウィルスを運び そしてパスワードを捕まえて承認されないシステムへのアクセスに利用する操作をすること –– 虫（ウォーム）を紹介する ひとつのＩＴシステムからもうひとつのシステムへユーザからのアクション 無しに悪意あるコードを蔓延させること –– オペレーティングシステムとアプリケーションに欠陥と弱点を開拓する ほとんどのシステムに存在す る欠陥や弱点を利用して承認されない行動を起こさせること –– 誤って構成されたＩＴシステムとコミュニケーション ユニットの開拓- システム管理者がシステム構 成を誤って構成したシステムや新たなソフトウエアあるいはハードウエアのインストール時の更新を失 敗したシステムへアクセスすること • サービスアタックの例。 –– サービスを停止したり妨げるための試行 サービスが準備されている量よりも多量のデータを引き継 ぐデータストリームにおけるエラーの開拓 –– システム容量を占有 システム容量の削減のためには適正に構成されていないオンラインサービス用 コンピュータへ永続的な要求を送り続けること –– ＩＴシステムの強制終了 データクラッシュ原因へ対処するためにデザインされたよりも多量のデー タを送りコンピュータに過剰負荷をかけること。予期せぬシステム終了を起こさせる方法は多くある、 サービス拒否（ＤｏS）と呼ばれるものも –– トランザクションのリ・ルーティング サービスプロバイダーから離れたサーバへホームページをコ ピーする。この離れたサーバは、イービジネス用のトランザクションからクレジットカードナンバーを取 得するために、そのサービスプロバイダーのネットワークアドレスが構成されている –– ソーシャルエンジニアリング 機密ビジネス情報やユーザ、パスワードに関する情報へアクセスするた めに承認された関係者を装い疑似的振る舞いをすること 246 G33 インターネット使用における一般的考慮点 2.3 インターネットサービス 2.3.1 インターネット上にいくつかのサービスが利用でき、しばしば新たなサービスは出現する。現時点で最も 一般的なものとしては、下記。 • イーメイル • ワールドワイドウェブ（ＷＷＷ） • ファイルトランスファープロトコル（ＦＴＰ） • ニュース • テルネット(Telnet)/リモートインタラクティブアクセス • インターネットリレイチャット(IRC)/インスタントメッセージング 2.3.2 イーメイルは、インターネット上では最も頻繁に利用されるサービスである。このサービスは、そのスピード や安価であることやユーザへの親しみ易さから、既存の手紙やファックスのサービスに更に置き換えられ ている。イーメイルは安全なサービスとしてデザインされたものではなく、いくつかの安全上の弱点を持って いる。その弱点として最も要を得ているポイントは、下記。 • 送り手 イーメイルの送り手は、それが本当の送り手か誰もわからない。名前を変更することは簡単であ り、送り手が識別できるコントロールは無い。この弱点はしばしばビジネス上で連携されるデジタル署名 で取り除くことができる。然しながら、この特徴はたまたまパートナーになった間柄でのイーメイル交換 では稀である • 平文でのメッセージ インターネットを通じて送られるメッセージは平文で送られる。この事から全ての インターネットユーザがメッセージを読み、そしてメッセージを変更することを可能にしている。変更され ずにインターネット上を通って来たメッセージであるかどうか、確証を持つ人は居ない。この弱点は、メー セージを暗号化することにより取り除くことができる • メッセージデリバリー もうひとつのイーメイルの弱点は、安全に送られる保証が無いことである。メッ セージは通常数秒から数分の時間で送られる。しかし、ある場合には全てが送られ終わるまでに数時間 かかることがある。配送チェーン上に存在する、ひとつのサーバが何かの理由で利用できない場合では、 そのサーバがオンライン可能なるまでメッセージがそのサーバに留まることになる。そのイーメイルシステ ムがどのように構成されたかによって、送り手がメッセージ送付の失敗を受信するまでに時間がかかるこ とがよくある。ほとんどのイーメイルシステムは送付証明機能を持っている。然しながら、異なるイーメイ ルシステム間の互換性の欠如がそのフィードバックの失敗につながることがある • 添付ファイル インターネットを介したイーメイルシステムを利用しているほとんどの企業は、イーメイル に添付ファイルを許している。それらの添付ファイルが大きい場合、それらの添付ファイルがイーメイルシ ステムとサーバをいっぱいにし、イーメイルユーザが他のメイルを受信することを妨げてしまう。この状況 を避けるために企業は、添付ファイルの大きさを制限し受信できる様にするためにイーメイルの保存と 削除のガイドラインを設けている • スパム 増殖している問題は、望まれないスパムと呼ばれるイーメイルである。これは困らせる様な製品 提供を含む望まれない広告とサービス提供になっているかもしれない。このスパムはサーバをいっぱい にし、サーバとしての器が持つべき時間を無駄にさせている。スパムは単に安全性の問題として考慮され ていなく、ＩＴシステムの可用性を低下させる結果にも成りえる 247 G33 インターネット使用における一般的考慮点 2.3.3 ＷＷＷは、平文、音声、図の情報を提供する世界規模のサーバネットワークである。金融情報用サーバ、取 引用サーバなどの異なる種類のサービスが国際的コミュニティで利用可能となっている。ＷＷＷへのアク セスはインターネットエクスプローラ、オペラの様なブラウザを通して行われる。ＷＷＷの特徴は、下記。 • 情報の質 ＷＷＷは膨大な量の情報を含んでいる、しかしその質は様々である。ＷＷＷ上に置かれた 情報を優先的にコントロールするものが欠如している。ＷＷＷへ情報を移そうとするそれぞれの人は、そ の品質の保証に責を持っている。誰もが責任を持っている事が逆に、情報が最新のものであることの信 頼性と正確性を保証するものが無い • 証跡 インターネットユーザは、ウェブサイトへ訪問し、主にネットワークアドレス、しかしある場合には ユーザ名をも、いくつかの証跡を残している。組織のコンピュータから証跡を残しながらインターネット で不適切なサイトにアクセスすることにより、組織はポルノグラフィー、極端な政治的活動などの様な ウェブサイトに連携することができる。なので、多くの企業は、そのようなウェブサイトへのアドレスをブ ロックすることを選択する • ブラウザ 異なる機能性、強弱で利用できる多くのブラウザが存在する。ブラウザにおける新たな安全 上の弱点は、しばしば露呈している。これら弱点のいくつかは企業へゆゆしき問題を引き起こす原因とな る。データ犯罪者は完全性の弱点を開拓し組織のＰＣに承認されない仕事を実行させ、悪意のあるコー ドを含ませたホームページを作成することができる • プラグイン 利用されるほとんどのブラウザにおいて、小規模な追加プログラム（つまり、プラグイン）を インストールすることができる。それらプラグインは、改善された音声、拡張されたビデオ機能、ゲームな どの様な機能拡張を提供する。いくつかのプラグインにおけるプログラミングエラーは、侵入者にとって ＩＴシステムにあるデータへのアクセスを可能にしている • クッキー ブラウザとログ、文書化目的でハードディスクへ伝えられる情報の小さな単位、たとえばＷ ＷＷへ最後に訪れたデータとか、どのホームページに訪れて何の製品が購入されたなど（イーマケットプ レイスに訪れた場合）。イーマーケットプレイスは、しばしばクッキーの使用に基づいている。クッキーは パスワードも保存することができる。しかし、クッキーの利用は未知の安全面での脅威にさらされるが、 ウェブサイトがユーザとユーザの動向に係る情報を保存する限りプライバシー侵害との係わりとして考 慮される。クッキーの利用が許可されるかどうかは、ポリシー要件となる。ほとんどのブラウザでは、クッ キーの許諾は選択することが可能である。インターネットサーフィングの間クッキー利用の機会を与える フリ-ウエアも利用可能だが、ログオフの際にユーザ情報を取り去ってしまう 2.3.4 ＦＴＰは、コンピュータ間でデータ転送を実現するサービスである。これは、しばしばＷＷＷ.ＦＴＰから ファイルをダウンロードするために用いられるが、基本的にセキュリティは確保されていない。利用する際 には、サービスを正確に構成しておくことが重要となる。ＦＴＰサービスは特徴的に、次の事項を含む。 • 匿名のＦＴＰ 外部へ企業サーバからデータやプログラムをダウンロードする事を許すサービスとなる。 このサービスを提供したいと思っている企業にとって、システムを正確に構成しておくことが非常に重要 となる。仮にそうでない場合には、侵入者が企業のデータにアクセスできてしまう。このサービスは非合 法なデータやプログラムを保存することにも使用される。その様な場合に、ユーザはユーザ名（匿名であ るいはＦＴＰで）とパスワードでログインする。しかし、通常イーメイルアドレスのユーザとパスワードが 正確かどうかのコントロールをしているシステムは少ない • 能動的/受動的コミュニケーション 他のサービスと違ってＦＴＰは、２つのゲートウェイをコミュニケー ションのために使用する。加えて、接続も２つの方法でなされる、つまり能動的なものか受動的なものか。 能動的モードでは、ユーザはどのゲートウェイを使うか決める。このモードでは受信データを制御する、 フィルターをかけることが可能である。受動的モードを使う場合では、接続されたサーバがどのゲート ウェイを使うか決める。受動的モードでは多くのファイアウォールを安全に対処することは困難がある 248 G33 インターネット使用における一般的考慮点 2.3.5 ニュースはユーザがいろいろな事を討議するある種のブレティンボードである。レターがニュースに送付さ れた際に、それは著作者の名前とアドレスと共にブレティンボードに置かれる。しばしばレターは世界中に ある異なるニュースサーバに拡散される。このことが一旦ニュースとして送付された後ではレターを取り除 く事がほとんど不可能にしている。組織のコンピュータから送られたレターは、その組織の公式の見解と 解釈できる。従業員が組織の秘密を露呈させてしまうというリスクも存在する。ニュースへのアクセスをブ ロックすることは可能である。組織のポリシーとして扱うことになる。 2.3.6 Ｔｅｌｎｅｔ（テルネット）は、ネットワークに存在する他のコンピュータへログオンする事を可能にするサー ビスである。Ｔｅｌｎｅｔはユーザに文字ベースの仮想ターミナルを提供する。ログインの際にユーザ名とパ スワードが平文で送られる。侵入者にとってはユーザ情報を読んだり、そしてそれを承認されていないアク セスに使用することは、かなり簡単となっている。これを避けるためにワンタイムパスワードや暗号化を利 用することができる。ハッカーにとっては、ターミナル接続を途中侵入すること（セッションハイジャック）も 可能となる。ハッカーは、ユーザログオンののち、ユーザのアクセスでセッションを取得する。これは暗号 化を使用することで避けることができる。ＳＳＨ、リモートXウィンドウＶＮＣ、リモートデスクトップによる リモートからのインタラクティブなアクセスは、遠隔地からのアクセスのＴｅｌｎｅｔデファクトのメソッドと して役割を引き継ぐ事を期待されている。 2.3.7 ＩＲＣとインスタントメッセージングはリアルタイム会議システムである。ユーザは通常エリアのチャネルを 利用して会話する。そこでは、全てのユーザが討議に参加できる。多くのＩＲＣ／インスタンスメッセージン グプログラムは、安全上の弱点があり、侵入者による組織のファイルへの非合法アクセスを可能にしてい る。また、侵入者にとって、これらのチャネルを使いウィルスを拡散させたり、ソーシャルエンジニアリングを 介してアクセスを獲得することも可能にしている。 3 セキュリティの測定 3.1 ポリシー、製品およびフォローアップ 3.1.1 安全なインターネット接続は、企業の情報セキュリティポリシーにより構築されるべきである。インターネッ ト利用を安全にし、適正さが確実になる様なガイドライン、そしてセキュリティへの関心がリーダーシップに おいてメジャーな焦点になる事は重要なことである。従業員がセキュリティガイドラインに従わない状況で は、セキュリティの測定は期待された様に働かない。承認のための手続きと適切な変更管理があるべきで ある。更に、セキュリティガイドラインはインターネット利用の倫理的振る舞いを方向づけるべきである。 3.1.2 インターネットセキュリティを改善することができる製品がマーケットに多く存在する。適切なレベルのセ キュリティを達成するためには、いくつかの補完的製品を実装する必要がある。製品の選択は、リスク評価 に基づくべきである。 3.1.3 セキュリティ測定はフォローアップされる事がとても重要である。ガイドラインの効率性と準拠性を確実に するためのセキュリティ測定にとって、モニタリングとフォローアップのための操作指導は、適切になってい るべきである。 3.2 ファイアーウォール 3.2.1 ファイアーウォールはローカルネットワークからインターネットへの接続を確立する時に用いられる最も普 通のセキュリティ測定となる。ファイアウォールは違法な侵入を防ぐハードウエアとソフトウエアの組合せ である。ファイアウォールは企業のセキュリティポリシーを反映するべきである。承認されたサービスのみ がファイアウォールを通過すべきである。 249 G33 インターネット使用における一般的考慮点 3.2.2 ファイアウォールは以下のひとつに成り得る。 • パケットフィルタリングルーター データが入ってくるあるいはネットワークから離れるパケットを検査する • アプリケーションゲートウェイ ＦＴＰやＴｅｌnetの様なアプリケーションを特定するセキュリティメカ ニズムに適用する • サーキットレベルゲイトウェイ ＴＣＰやＵＤＰとの接続が確立された時にセキュリティメカニズムを提 供する • プロキシサーバ 本当のＩＰアドレスを隠す様にするためにネットワークへの入りと出を途中介入する。 展開されているファイアウォールの種類はソフトウエアベースあるいはハードウエアベースあり、後者は 主に商環境で設計される。ファイアウォールは、既に言及してきた多くのテクニックを取り入れてもかま わない 3.2.3 これらのファイアウォールは異なる種類のセキュリティを提供し、そしてフォローアップと維持管理を要求 する。 3.2.4 ファイアウォールを通じたデータ制御には２つのセキュリティコンセプトが存在する。 • 全てのものが完全に制限される。 マネジメントが許可したサービスのみ通過する。 • 一般的な制限というものは無い。 管理者がハイリスクと考えたサービスのみが防がれる。 3.2.5 ファイアウォールソリューションを選択する時に、企業のセキュリティニーズ、ＩＴ部門におけるユーザ融 和性と容量への要求が考慮されるべきである。ユーザがインターネットへアクセスできる前に、ファイア ウォール構成は修正されセキュリティポリシーに準拠しているべきある。 3.3 ワンタイムパスワード 3.3.1 パスワードを隠匿するために用いることができるプログラムは多く存在する。そのようなプログラムはデー タ犯罪とハッカーにより利用される。しばしばユーザは簡単に類推され、承認されない目的に利用される パスワードを作ってしまう。しかし、類推されにくいよいパスワードでさえ隠匿されることができる。今日の コンピュータはかなり強力なので最も複雑なパスワードでさえ隠匿することができる。企業システムへのア クセス介入を防ぐために用いられる可能なソリューションは、ワンタイムパスワードを使用することである。 パスワードジェネレータによるかチャレンジ／レスポンスシステムにより生成することができる。それは、計 算機同様の数字の打鍵に基づいている。ワンタイムパスワードは、安全なソリュ-ｼｮﾝを作る暗号化ソフトウ エアと組み合わされることが好ましい。 3.4 侵入テストとテストソフトウエア 3.4.1 増加する複雑性とゆゆしき脆弱性により知られるウェブアプリケーションの現状を調査することを勧める。 商用とフリーウェアとの両方において異なる種類の脆弱性/安全上の弱点をＩＴシステムに対してテストす る事が出来るソフトウエアが存在する。これらのいくつかは、より安全なインターネットへの貢献を願う厳 格な個人や会社によって開発されたものである。しかし、これらプログラムの大多数は企業システムを破ろ うとするデータ犯罪者により開発されている。信頼できる侵入テストソフトウエアを使用することで企業の インターネット接続におけるセキュリティ測定の品質をテストすることが可能になっている。 3.5 侵入検出とシステムの防御 3.5.1 侵入検出システム（ＩＤSs）は、ローカルネットワークとビジネスシステムへのダメージが発生する前に違法 な攻撃を開示するための分析に用いられる。IDSは進行中の攻撃を防御したり、セキュリティ測定を効率 的に行っているセキュリティマネージャーや企業のIT利用者個々人へメッセージを送ることになる。IDSは、 新たな脅威と攻撃を発見したのちに迅速に更新されるべきである。 250 G33 インターネット使用における一般的考慮点 3.5.2 侵入防御システム（ＩＰＳs）は、他のセキュリティツールとは異なる概念である。他のセキュリティツールは 攻撃が起きている（あるいは起きた後）に攻撃を特定する署名ファイルに頼っている。侵入防御ソフトウエ アはそれが有効になる前に攻撃を予測する。コンピュータシステムのキーエリアをモニタリングすることに より実現させている。そして、それは虫、トロイの木馬、スパイウエア、悪意のあるもの、ハッカーなどの様な 悪しき振る舞いを捜査している。そして、ファイアウォール、アンチウィルス、アンチスパイウエアツールから の緊急的な脅威から完全に防御するものとして補完している。脅威の署名やパッチを特定したり配布した りすることに頼っていないので、伝統的なセキュリティ測定を迂回する新たな脅威（未だ対応策が講じられ ていない脅威）をブロックすることができる。 3.6 暗号化 3.6.1 インターネット上のデータ伝送は、原則全ての人に開かれている。このことは、防御されない機微のデータ は捕捉され違法に利用されることを意味している。システムのインテグリティと機密性を確実にするための 方法に暗号化がある。暗号化は異なるレベルで利用することができる。最も安全なソリューションとしては、 アプリケーションのレベルで暗号化することであり、このことは機密性とインテグリティはエンドユーザに 至るまで維持されることを意味している。然しながら、このソリューションはユーザ間で準拠性のあるソフ トウエアが存在することに依存している。 3.7 デジタル署名 3.7.1 デジタル署名を使うことによりメッセージのインテグリティが維持できる。このことは特にインターネット を使った商取引に有用である。デジタル署名は、ひとつはプライベート、そしてひとつはパブリックキーとい うペアのキーに基づいている。送り手はプライベートな暗号キーと受け手のパブリックキーを合わせて暗 号化するメッセージの指紋（複製）を作る。受け手は送り手のパブリックキーと固有のプライベートキーを 暗号化するプロセスの反対を行う。これで送り手の指紋と比較する事が出来る新しい指紋を生成する。も しそれらが同じものであれば、何も変わっていないことになる。 3.8 ＶＰＮ（バーチャル プラーベート ネットワーク） 3.8.1 ＶＰＮは２つあるいはそれ以上で共有され、安全にはなっていない、物理的ネットワークあるいは複数の ネットワークにおいて安全なコミュニケーションチャネルを確立する手段である。コンピュータは物理的に ネットワークに接続することができるが、同一の仮想ネットワーク上のメンバーのみデータを交換すること ができる。コミュニケーションチャネルは暗号化により安全にすることができる。 3.9 アンティウィルスプログラム 3.9.1 データのウィルスは、特にマクロウィルスが紹介された後、増加続ける問題となっている。データのウィルス は、イーメイル、ゲームの海賊版コピー、インターネットからダウンロードされたプログラムを含むいくつかの 資源を通して拡散されている。イーメイル受信に添付付きで、あるいはインターネットからのダウンロードを 従業員に許可している企業の全ては、サーバあるいは/およびＰＣにアンティウィルスソフトウエアを持たせ るべきである。アンティウィルスソフトウエアの更新を維持する適当なルーチンが非常に重要である。 3.10 アンティスパイウエア プログラム 3.10.1 スパイウエアは通常それ自体複製しない。ウィルスや虫とは異なる。最近の多くのウィルス同様に商業的 利得にために感染したコンピュータで展開する様に設計されている。この目的を進める典型的な戦術には、 望んでいないポップアップ広告の伝送、個人情報の泥棒（例えば、クレジットカードナンバーの様な金融情 報を含む）、 マーケッティング目的のウェブブラウジングのモニタリング、広告サイトへのHTTPルーティン グ要求が含まれる。この脅威を避けるために、企業はスパイウエアをブロックしたり取り除く様に設計され たアンティスパイウエアプログラムを導入すべきである。 251 G33 インターネット使用における一般的考慮点 3.11 ロギングとモニタリング 3.11.1 インターネット通過事態のロギングとモニタリングは、セキュリティ測定ではなく、ネットワークとビジネス システムへの攻撃の検出と安全性維持のための前提事項となる。効率的にするためには、ロギングとモニ タリングはファイアウォールの様なコミュニケーションノードで実行されるべきである。フォローアップを要 求するイベントはリスク評価と企業ポリシーに基づくべきである。ロギングは、手作業でのフォローアップ が厳しい大量のデータに有効と成る。従って、関連するログデータをフィルタリングする、分析し表現する ためのツールやソフトウエアを入手することは現実的である。 4 企業を表現するためのチャネルとしてのインターネット利用 4.1 窓としてのインターネット利用 4.1.1 WWWが紹介されて以来、インターネットは企業にとって窓として利用されている。このガイドラインは企業 をどのように表現するかを取り扱うことはしないがWWWへ情報伝達される前、あるいはされた後に考慮す るものに関してのいくつかの影響を提供する。 4.2 情報をWWWへ伝送する前に 4.2.1 WWWで表現される前にほとんどの企業は、確認すべき事項があると思われる。しばしば情報が安全性へ の配慮なしにホームページに載せられる。ビジネスと従業員についての詳細情報を与えることによって企業 はデータ犯罪者により犯されるソーシャルエンジニアリングにさらされている。ホームページのコンテンツ を書き替えようとウェブサーバに侵入するデータ犯罪者の事例もある。 4.2.2 企業がホームページを開発する前に、どのような種類の情報が企業のデータ表現として表現されるべきか、 リスクレベルを決定するかについて背景となる材料を分析する必要がある。 4.3 情報をWWWへ伝送した後に 4.3.1 直ぐに更新されないホームページは一般の方の関心を失う。維持管理と開発は重要である。更にサーバは 潜在的違法性や承認されない活動を検出する日々の基準でフォローアップされるべきである。データ犯罪 者がアクセスした場合に、ホームページのコンテンツは異なる方式により変更する事ができる。例えば、競 合会社の電話番号の変更はホームページ所有者の売上を損なう結果になり得る。WWWへのアクセスを 通して、海賊版ソフトウエアのコピーを交換したり、サーバを違法な情報の格納庫として使用することも可 能となる。 4.4 商取引チャネルとしてのインターネット 4.4.1 インターネットを通した商品取引（イービジネス）は、世界規模で成長しているサービスである。支払いを含 むこの取引活動は、厳格なセキュリティ測定を要求している。消費者がベンダーに提供するクレジットカー ドナンバーには、誤利用されない機密を有して提供することができる。一方、ベンダーには、注文時に不必 要なコストを避けたり、誤使用時の経済的責任が伴っている事の機密性が帰属されなければならない。 4.4.2 インターネットを通した安全な取引のためのいくつかのソリューションが存在する。最も一般的なソリュー ションのなかには、セキュアソケットレイヤ（SSL）やセキュア電子取引（SET）プロトコルがある。 252 G33 インターネット使用における一般的考慮点 4.5 電子マネー 4.5.1 インターネットを経由した商取引には、安全な電子マネートランザクションへの要求が増加している。多く の人は彼らのクレジットカードナンバーが露呈されることは不本意に思っている。小額が送られる時に、ク レジットカード利用は不適切である。拠って、いくつかのイーコマース会社は電子マネーを取り扱うソリュー ションを開発した。イーコマースの商取引チェーンは３つの集団から構成される。消費者、ベンダー、および 銀行となる。消費者がイーマネーを利用できる前に、銀行から電子財布をダウンロードしなければならない。 この財布は、PC、PDA、あるいはスマートカードにインストールできる。ダウンロードの後に、お金が利用 できる様になる。デジタル署名は取引を安全にする事ができる。 4.6 信頼した第３者（Trusted Third Party） 4.6.1 インターネットベースの商取引や企業の重要なデータや情報の交換は、通常トレーサビリティが要求され る。トレースのインテグリティを安全にするために、第３者機関は取引の認証を立証するために利用されて いる。これらは通常PKIと呼ばれる技術を利用するITビジネスでの大規模なプロバイダーである。主な機能 は、認証、暗号化とデジタル署名となる。 4.6.2 ここ数年においては、第３者機関に係わること無しに企業のセキュリティ管理を確実にするソリューション が進行している。 5 監査業務/安全性レビューのパフォーマンス 5.1 計画策定 5.1.1 情報システム監査人は組織のアクセスとインターネット利用への理解を得るべきである。情報システム監 査人は、インターネットアクセスのリスク分析と組織の、およびその責務の各々の利用を統括すべきである。 5.1.2 監査プログラムは範囲、目的、および監査のタイミングを含めて開発されるべきである。報告書の作成は 監査プログラムにより明確に記述されるべきである。組織と組織のステークホルダの性質とサイズへ配慮 されるべきである。情報システム監査人は組織の責務、ビジネス目的、技術的インフラ、およびビジネスの 重要なデータへの理解を得るべきである。 5.1.3 更に、組織構造への理解が要求される。特に情報管理者と所有者を含むキースタッフの役割と責任につい ても。 5.1.4 監査計画策定局面での第１の目的は、組織がインターネット接続する際の脅威とリスクを理解することで ある。 5.2 達成ステップ 5.2.1 情報システム監査人は、インターネットへ接続することが全体として企業ニースの評価に基づいているかど うかを考慮すべきである。経営会議とマネジメントはリスクとインターネット利用に係る正しい判断をする ために脅威の変化が意味するものに留意すべきである。レビュー範囲を定義する際に、情報システム監査 人は組織における様々な目的のために収集され、格納され、利用される情報の種類の要素を考慮すべきで ある。 5.2.2 情報システム監査人は、次の項目を実行しているかどうか判断すべきである。 • インターネットポリシー • ファイアーウォール等へのネットワーク接続のモニタリングとフォローアップのガイダンス • インシデント報告手続き • 教育訓練プログラム もし可能ならば、これらはインターネット利用がポリシーと手続きに合致していることの合理的保証を提供 するために、情報システム監査人により評価されるべきである。 253 G33 インターネット使用における一般的考慮点 5.3 詳細レビューの実施 5.3.1 情報システム監査人は次の管理者的観点で評価すべきである。 • マネジメント責任 • インターネットアクセスをさせる目的 • インターネット接続が制限されるべきか、許可されるべきかを意味する機密データ／プライバシーデータ を企業が持っているかどうか • 接続のタイプ • 従業員アクセスのための基本事項の必要性評価があるかどうか • アクセスがある一定の時間・時刻、 １日あるいは１週間の制限があるかどうか • 従業員が情報の閲覧/収集が許可されているところでの制限があるかどうか • 企業がインターネットを通して製品やサービスを販売しているか、インターネットを経由して支払いが行 われているかどうか • 企業がインターネット接続をインストール、フォローアップ、そして維持管理するために必要な力量、時間 と容量を持っているか 5.3.2 リスク評価には少なくとも次をカバーしているべきである。 • 脅威 • インターネット接続する際の脅威の変化 • 存在する情報セキュリティポリシーがインターネット利用をカバーしているかどうか • 企業がデータ犯罪者あるいは産業スパイターゲットに関心をもっているかどうか • 内部/機密の情報が侵入者にさらされていることの結果 • セキュリティインシデントが発生した時のコスト • セキュリティインシデントが発生する可能性 • インターネット接続を安全にするために遂行すべきセキュリティ測定 5.3.3 インターネット利用のガイダンスには少なくとも次の事項を包含するべきである。 • セキュリティポリシーとのつながり • 許可されたサービスの文書化 • それらサービスと許可の利用時にルールが破られた時の許容できる規則 • 法律と規則に準拠するネットワークモニタリングのための手続き書 • 倫理的態度の文書化 • イーメイルの送信と保存の規則 • ユーザ訓練への要求事項 • 協業するパートナーとの潜在的同意事項 • インターネット通信のロギングとモニタリングに係る法律への潜在的な違反を避けるために重要となる 同意書となるが、ガイダンスを読み、理解し、それに従うという事を全ての従業員が署名していること 5.3.4 インターネット運用の文書化には、少なくとも次を含むべきである。 • 全ての技術的な装置とインフラ • ロギングとモニタリングの規則 • アラームのセットアップ • ロギングとインシデントフォローアップのためのルーチン 254 G33 インターネット使用における一般的考慮点 5.3.5 インターネット接続の文書化には、少なくとも次を含むべきである。 • ネットワークペリメータの記述 • アクセスポイントの記述 • 全てのモデム接続の記述 • ルーターと潜在的なプロキシサーバの構成情報 • ファイアーウォールの構成情報 • 暗号化とデジタル署名などの様な他のセキュリティ測定の構成情報 • 例えばWORM（ライト ワンス リード メニィ）の様なログファイル、外部ディスク、テープの様な安 全なストレージの記述 • ログファイルを再作成するための手続きの記述 5.3.6 モニタリングのためのルーチンの文書化には、少なくとも次を含むべきである。 • バックアップ資源を含むインターネット接続の管理と維持に係る責任の記述 • ファイアーウォールからのログファイルのレビュー • 現行サーバからのトランザクションのレビュー • ユーザアクティビティからのログファイルのレビュー • ネットワーク統計のレビュー • 潜在的セキュリティインシデントあるいは試行についてのフォローアップ 5.4 責任 5.4.1 ユーザ責任には次を含む。 • 情報システムポリシー、ガイダンス、倫理的標準への準拠 • 情報が収集された国における法律と規則の尊重 • 電話やイーメイルにパスワードを与えないこと • 知らない人物からの電話やイーメイルを通したパスワード変更要求時に変更しないこと • ローカルネットワークとして利用されているインターネット上で同一のユーザ名、パスワードを使用しないこと • ビジネス上の判断、商取引あるいは支払の基本としてインターネットを利用する前にインターネットから のデータダウンロードを検証すること 5.4.2 ＩＴマネジメントの責任には次を含む。 • インターネットファイアウォール、ルーター、サーバと他のＩＴ装置利用における維持管理とフォローアッ プ。これには適正なバージョンのシステムソフトウエアとアプリケーションが正確にインストールされ維 持されていることを確実にする責任を含んでいる。更に、ＩＴマネジメントはファイアーウォールログが毎 日のベースでフォローアップされ、構成情報は記載されたガイドラインに合致したものであることを確実 にするべきである。 • システムとアプリケーション利用、セキュリティレベルの適正な維持管理の前提条件へ脅威と脆弱性が 関連づけられ更新されていること。 255 G33 インターネット使用における一般的考慮点 5.4.3 セキュリティ管理の責任には次を含む。 • ＩＴのオペレータ、システムアナリストやプログラマーの様に追加的な機能を持っている人物には、情報 セキュリティ業務への制限を設けること • インターネットとアクセス可能でユーザへの倫理的利用をする情報提供のためのガイドラインを仕上げ ること。それは、情報セキュリティマネジャーの主な仕事となる。 • 情報セキュリティにおけるトップマネジメントにとっての資源としての役割を担うこと • ファイアーウォールからのログをレビューすること • セキュリティシステムからの報告書をレビューすること • セキュリティ測定は規則通りテストされていることを確実にすること • 企業サービスに係る災害対策事業継続計画を確実にすること • セキュリティインシデントと試行をフォローアップすること • 管理者への重大なセキュリティインシデントを報告すること • ＩＴマネジャーとして、利用中のシステムとアプリケーションと結びついた脅威と脆弱性を更新すること 5.4.4 上級管理者の責任には次を含む。 • 全てのインターネットポリシーの公式化 • ポリシーとそれに関連するプロセスのモニタリング • 正確な資源の提供 • ポリシー実装のためにＩＴマネジメントへ権限移譲すること 5.5 技術的課題とセキュリティ測定 5.5.1 技術的問題には次を含む • セキュリティアラームと承認されていないインシデントのログは、システムソフトウエアにより活性化され るべきである • ローカルネットワークとインターネットの接続はファイアウォールを介してプロテクトされるべきである • 管理者により許可されているそれらのサービスのみファイアウォールを通過するべきである • ファイアウォールは許可されていないネットワークプロトコルの全てを遮断すべきである • 製品に起因するシステムエラーや故障が起きた時、ファイアウォールは全てのアクセスを遮断すべきである 256 G33 インターネット使用における一般的考慮点 5.5.2 サービスに関連する測定には次を含む。 • イーメイルでは、 –– 重要なメッセージは暗号化されるべき –– 時間的に緊急を要するメッセージは、手作業でフォローされるべき –– パスワードはイーメイルで送られるべきでない • ＷＷＷでは、 –– インターネットサービスを使うとき、ローカルネットワークで使われるユーザ名とパスワードとは異なる ものを使用すべきである –– WWWからのダウンロードされた情報は、利用する前に検証されコントロールされるべきである。 –– 是認されたインターネットブラウザのみ使用され、そしてプラグインの構成、インストール情報の変更 は許可されるべきでない –– インターネットからダウンロードされた全てのファイルは、ウィルスおよび類似するスパイウエアの様な 悪意のあるコードを目的としてスキャンされるべきである • FTPでは、 –– インターネットからダウンロードされた全てのファイルは、ウィルスおよび類似するスパイウエアの様な 悪意のあるコードを目的としてスキャンされるべきである • ニュースでは、 –– ユーザは「フレーム戦争」に参加することを許可されるべきでない –– 企業、従業員、協業パートナー、ベンダーや競合会社のネガティブなイメージを与えかねない記事を 書くことを利用者に許可すべきでない –– ニュースから収集された情報は、利用する前に検証し、コントロールされるべきである • Telnet（テルネット）では、 –– 可能であればワンタイムパスワードを使用するべきである • IRC/インスタントメッセージング –– ＩＲＣとインスタントメッセージングは、スタンドアロンＰＣからのみ許可されるべきである –– IRCとインスタントメッセージングは、企業内部の情報を与える目的で許可されるべきでない 5.5.3 他のセキュリティ測定には次を含む。 • ホームオフィスあるいは外部からのログオンロギングでは、例えばワンタイムパスワードの様にセキュリ ティ面で認証された接続としてＶＰＮを利用すべきある • 外部のユーザに提供されるサーバはＤＭＺの中にインストールされるべきである • インターネットからデータを受信するＣＧＩスクリプトと他のコードは、エラーと弱点のために品質保証さ れ、そしてテストされているべきである 6 適用開始日 6.1 本ガイドラインは、2006年3月1日以降に開始するすべての情報システム監査に適用される。 257 G34 責任、権限および説明責任 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 259 2 責任‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 260 3 権限‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 263 4 説明責任‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 264 5 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 265 G34 責任、権限および説明責任 1 背景 1.1 基準との関連 1.1.1 基準S1『監査ポリシー』は「情報システム監査機能ないし情報システム監査業務の目的、責任、権限、説 明責任は、監査ポリシーまたは監査契約書により適切に文書化されている必要がある」と述べている。 1.1.2 基準S3『専門家としての倫理と基準』は「情報システム監査人は、 『ISACAの職業倫理規定』を遵守すべ きである」と述べている。 1.2 COBITとの関連 1.2.1 ハイレベルコントロール対象M3『独立した保証を得る』は、 「...組織、顧客やサードパーティプロバイダの 間で信頼と信用を高めるために独立保証を得ること」と述べている。 1.2.2 ハイレベルコントロール対象M4『独立監査に備える』は、 「...自信のレベルを高め、ベストプラクティスの アドバイスの恩恵を受けるように独立監査に備えること」と述べている。 1.2.3 詳細なコントロール対象M4.1『監査ポリシー』は、 「監査機能のためのポリシーは、組織の上級マネジメン トによって確立されるべきである。この文書では、監査機能の責任、権限、説明責任の概要を説明すべき である。ポリシーは、監査機能の独立性、権限、責任が維持されることを保証するために定期的に見直さ れるべきである」と述べている。 1.3 COBITの参照 1.3.1 個々の監査範囲に適用可能であるCOBITの中から最も関連する材料の選択は、特定のCOBIT ITプロセ スを選択し、COBITのコントロール目標と関連するマネジメントの実行を勘案して行う。IT監査・保証の専 門家が必要とするITガバナンスに合わせるべく、最も関連し、選定され、採用されそうなCOBITのプロセス が、ここで主要なものとして分類されている。選定され、採用されるべきプロセスとコントロール目的は、特 定の範囲と担当業務の権限次第で変化するかもしれない。 1.3.2 主要な参照： • M2 内部統制十分性の評価 • M3 独立した保証の取得 • M4 独立した監査に対する提供 1.3.3 副次的参照： • PO6 マネジメントの意図と指針の周知 • PO7 人材の管理 • PO8 外部要件へのコンプライアンスの確認 • DS1 サービスレベルの定義と管理. • DS2 サードパーティサービスの管理 • DS10 問題と障害の管理 • M1 プロセスのモニタリング 1.3.4 責任、権限、説明責任に最も関連する情報要請規準： • 主：有効性、効率性と機密性 • 副：可用性、インテグリティと信頼性 259 G34 責任、権限および説明責任 1.4 ガイドラインの目的 1.4.1 システムの複雑さそれに応じた巧妙なサイバー脅威の継続的な増加とともに、組織は、システムリスクと脆 弱性を軽減するためのソリューションを識別し評価し推奨できる、実証されたスキル、専門知識、知識を持 つ専門家をますます当てにしている。情報システム監査人は、急速に変化する情報技術への対応に重要な 役割を果たしている。そして、その情報技術は、組織の資産を保護するための弱みや潜在的な脅威に関連 している。情報システム監査人は、技術的なITスキルと監査機能の専門知識を―内部か外部かに―提供 する。そして、財務および業務環境の増加における技術高度化などのIT専門性のスキルと知識の十分なレ ベルを維持する必要性が高まっている。現代においては、技術は、主要なビジネスを推進する、あるいは、 ビジネスプロセス、組織、ステークホルダーが、 マネジメントがコミットされるかどうか決定するために、情 報システム監査人に頼ることの支援を可能にするキーとなっている。そのコミットメントとは、資産の保全、 データインテグリティ、有効性と効率性、企業ポリシーの固守、法律、規制および法的義務の遵守、を保証 することである。 1.4.2 ISACAの情報システム監査基準とCOBITは、監査ポリシーが監査を行うにあたっては情報システム監査 人の責任、権限、説明責任を正確に確立すべきであると、明確に強調している。 1.4.3 担当業務の監査を行うために受け入れるうえで情報システム監査人の責任、権限、説明責任について、情 報システム監査人への手引きを提供するためのガイドラインが必要であると述べられている。 1.4.4 本ガイドラインは、情報システム監査基準S1『監査ポリシー』とS3『専門家としての倫理と基準』を適用 する手引きを提供する。情報システム監査人は、上記の基準の実施を如何に成すかを決定する中でガイド ラインを考慮すべきであり、それを適用する際に専門的な判断を使用すべきであり、さらに、いかなる開始 も正当化するよう準備されるべきである。 1.5 ガイドラインの応用 1.5.1 本ガイドラインを適用する際に、情報システム監査人は、他の関連ISACAの基準およびガイドラインとの 関係でその手引きを考慮すべきである。 2 責任 2.1 専門家へ 2.1.1 情報システム監査人は、専門である仕事へのアプローチにおいて、単純明快、正直、誠実であるべきである。 2.1.2 情報システム監査人は、その態度や外見において被監査者とは独立であるべきである。 2.1.3 情報システム監査人は、ISACAの職業倫理規範のような、所属するそれぞれの専門機関が定めた職業倫 理規範に従うべきである。 2.1.4 情報システム監査人は、ISACAの情報システム監査基準・ガイドライン・手続のような、情報システム監査 の専門職にとって適用できると監査実践で一般に公正妥当と認められる監査基準に準拠してアクティビ ティを行うべきである。 2.1.5 監査の環境の状況によりコンプライアンスが達成できない場合、情報システム監査人は、その理由を含む ような不遵守の事実と、監査報告書に適用される監査基準などの非遵守の監査に与える影響を開示すべ きである 2.1.6 情報システム監査人は、常に専門家の品位を維持すべきである。 2.1.7 情報システム監査人は適用される規制や法的要件に従うべきである。 2.1.8 情報システム監査人は、担当業務を行うのに必要な知識、能力、スキルを持つべきである。 2.1.9 情報システム監査人は、情報システム監査に割り当てられたすべての監査スタッフを監督し、品質を保証し、 適用される基準に従い、スタッフの開発を促進すべきである。 260 G34 責任、権限および説明責任 2.1.10 情報システム監査人は、結論と勧告事項のサポートに十分で的確な監査証拠を入手し、維持すべきである。 情報システム環境の監査では、監査証拠の一部は電子的な形式でもよい。情報システム監査人は、このよ うな監査証拠が十分であると安全に保管し、必要な場合にはその全体が取り出し可能である、と合理的な 保証を提供すべきである。 2.2 被監査部門（組織）に対して 2.2.1 情報システム監査人は、被監査部門のビジネス対象、目標、ミッションを認識し、理解すべきである。 2.2.2 情報システム監査人は、被監査部門に課せられたすべての独立した要求事項を制限なく含めて情報システ ム監査人の専門的な要求事項を理解すべきである。 2.2.3 適切である場合はいつでも、情報システム監査人と被監査部門は、監査の担当業務においての範囲、目的、 参照の条件に十分に同意するべきである。 2.2.4 情報システム監査人は、内部統制に関するマネジメントの態度、意識、行動と、内部統制環境の適切性を 評価する重要性について十分な理解を得るべきである。 2.2.5 情報システム監査人は、レビューに基づくアクティビティに関連する統制リスクの予備評価を実施すべきで ある。監査の目的には、この評価の結果を反映すべきである。情報システム監査人は、組織のコントロール システムから得られる理解し統制リスクの評価をその作業調書の中で、文書化するべきである。 2.2.6 情報システム監査人は、全体的な監査計画を策定する際に適切なリスク評価技法を使用すべきである。 情報システム監査人は、コントロールリスクがより低いレベルである評価されるときは、結論の根拠も文書 化すべきである。このような場合には、情報システム監査人は、コントロールリスクの評価をサポートするた めコントロールのテストを通して監査証拠を取得すべきである。コントロールリスクを低く評価すればする ほど、情報システム監査人は、情報システム／内部統制システムが適切に整備され、効果的に運用してい る多くの監査証拠を取得すべきである。 2.2.7 コントロールのテスト結果に基づいて、情報システム監査人は、内部統制が整備され、コントロールリス クの予備評価で意図されたように運用しているかどうかを評価すべきである。情報システム監査人は、許 容可能な低いレベルに監査リスクを軽減するために必要な実証手続の種類、時期、程度を決定する際に、 内在するコントロールリスクの評価レベルを考慮すべきである。 2.2.8 情報システム監査人は、実質的な手続と、監査の実施中に得られた他の監査証拠の結果に基づいて、コ ントロールリスクの評価を確認すべきである。所定のコントロールシステムから逸脱する場合には、情報シ ステム監査人は、その影響を考慮した特定の照会をすべきである。このような照会に基づいて、逸脱がコン トロールリスクの予備評価をサポートしていないと情報システム監査人が結論する場合、コントロールの 他のテストから得られる監査証拠がその評価をサポートしていない限り、手続を修正すべきである。コント ロールリスクの評価レベルは修正する必要があると情報システム監査人が結論した場合、情報システム監 査人は、計画的な実証手続の種類、時期、程度を変更すべきである。 2.2.9 情報システム監査人は、監査マネジメントと話し合い、担当業務の監査計画、監査方法論、資源、時間枠、 報告要件について、合意すべきである。情報システム環境によって影響を受ける可能性のある監査の部分 を計画する際に、情報システム監査人は、情報システムアクティビティの重要性と複雑さ、記述されたコン トロールの妥当性、監査で使用するデータの可用性と信頼性について理解を得るべきである。このような 理解には、次のような事項が含まれる。 • 情報システムのインフラストラクチャ［ハードウェア、組織で使用されているオペレーティングシステム、 アプリケーションソフトウェア、もしあれば、前回の監査以降の変更を含む］ • それぞれの重要なアプリケーションの重要性と処理の複雑さ • 組織の情報システムアクティビティ、および、職務分離に影響を与える可能性があるかもしれないような 組織全体の処理の分散・集中の程度の組織構造の決定 261 G34 責任、権限および説明責任 • 情報システム監査人が必要とするかもしれないか、短期間あるいは機械可読形式だけで存在するかもし れない、データ、利用可能なデータの信頼性、ソースドキュメント、コンピュータのファイル、他の監査証 拠についての利用可能性の決定。コンピュータ情報システムは、実質的なテストを行うのに有用（特に 分析的な手続）かもしれないレポートを生成することがある。 2.2.10 情報システム監査人は、デューデリジェンス（相当な注意）と専門家として正当な注意により監査を実施す べきである。 2.2.11 情報システム監査人は、担当業務を実行するために、コンピュータ支援監査ツールやその他のデータ分析 技術のような、主要な情報技術のリスクやコントロール、ならびに利用可能な技術についての知識を持つ べきである。監査は、能力を使い、専門家として正当な注意で実施されるべきである。監査チームは、知識、 スキル、その他責任を果たすために必要な能力を結集すべきである。 2.2.12 情報システム監査人は、 でき得る限り早急に実用的且つ責任の適切なレベルで、監査人が注意すべき内部 統制システムの整備や運用における重大な欠陥をマネジメントに認識させるべきである。 2.2.13 組織が受け入れられないような残存リスクのレベルを上級マネジメントが受け入れたと情報システム監査 人が信じるならば、情報システム監査人は上級マネジメントと良く話し合うべきである。残存リスクに関す る決定がされなければ、情報システム監査人は解決のために経営会議に同様の報告を考慮すべきである。 2.2.14 情報システム監査人は、情報の機密がその仕事で必要であると予想するべきである。そして、特別な権限 がなければ、あるいは開示する法的あるいは専門的な義務がない限り、第三者にその様な情報を開示すべ きではない。担当業務から外れても、情報システム監査人と被監査部門の関係が終わっても、機密の義務 は続けるべきである。 2.2.15 情報システム監査人は、被監査部門と適切なコミュニケーションチャネルを維持すべきである。コミュニ ケーションは、正確、客観的、明確、簡潔、建設的、完全、タイムリーであるべきである。監査の結果は、適 切な関係者か当局に報告されるべきである。 2.2.16 情報システム監査人は、監査終了時に適切な形式で報告書を提出すべきである。報告書はその結果の配付 と使用の制限を含めるべきである。報告書は、目的の受信者とその閲覧に関する制限する組織を識別すべ きである。情報システム監査人は、それぞれの監査機関の報告書標準、ポリシー、手続に従うべきである。 2.2.17 情報システム監査人は、態度や外見のすべてで被監査部門と独立であるべきである。情報システム監査人 の役割は、組織のミッションを果たすためにコントロールが十分であることを保証する、組織の情報システ ム／内部のポリシー、実務、手続を監査することである。情報システム監査人は、監査が行われる組織の 一人であっても、情報システム監査人の独立性が保持されることが重要かつ必要である。 2.2.18 情報システム監査人が組織のコントロールフレームワークの一員である環境において、レビュー中の組織 における特定の情報システム／内部コントロール手続を実施する責任を負うチームの一員ではないことを 合理的に保証すべきである。 2.2.19 情報システム監査人は、担当業務の期間によって要求されるようにフォローアップをすべきである。必要 であれば、情報システム監査人はまた、 マネジメントの行動が効果的に実施されていること、あるいは、上 級マネジメントがマネジメントの実行されないリスクを受け入れていることをモニタリングし、決定するフォ ローアッププロセスを確立すべきである。 2.3 ステークホルダーに対して 2.3.1 情報システム監査人は、行為および人格について高い水準を維持しながら、専門職への不名誉な行為に従 事せずに、合法的かつ誠実な方法でステークホルダーの利益に役立たなければならない。 2.3.2 情報システム監査人は、すべての材料の実例、あるいは、ステークホルダーが関心に直結している事象を 開示すべきである。 2.3.3 情報システム監査人は、担当業務の範囲と目的により、監査の領域の業務の真実かつ正確な状態を開示 すべきである。 262 G34 責任、権限および説明責任 2.3.4 情報システム監査人は、報告書の中で、虚偽表示、曖昧な文、あるいは、多様な解釈につながる文を避け るべきである。 2.3.5 情報システム監査人は、監査を実施している間、必要があれば、独立性が損なわれた材料を開示すべきで ある。 2.4 法令および規制 2.4.1 情報システム監査人は、適用される法律、規則、規制に後れを取らないようついていくべきである。 2.4.2 情報システム監査人は、該当する法定の法律、規則、規制、契約に従っていることを確認し、該当する場合 には、法的手引きを求めるべきである。 2.4.3 情報システム監査人は、被監査部門の同意を得て、法律、そして必要に応じて情報を開示すべきである。 2.4.4 情報システム監査人は、監査の担当業務を行う際、ライセンス取得したツールとソフトウェアを使用すべき である。 2.5 社会に対して 2.5.1 情報システム監査人は、情報システムセキュリティ、コントロール、リスクの評価、管理、情報システム資産 の保護等の理解を高めさせるように公共および被監査部門への教育をサポートすべきである。 2.5.2 情報システム監査人は、技術、コントロールモデル、コントロールの対象、一般に受け入れられているコント ロールの実践、方法論をモニタリングし保証する方法の用途と乱用する可能性に関して、公共および被監 査部門への教育をサポートすべきである。 2.5.3 情報システム監査人は、トランザクションが技術の助けにより起こると考えられるために、実施される警戒 と予防措置に関して、公共および被監査部門への教育をサポートすべきである。 3 権限 3.1 情報システム監査人の権利 3.1.1 情報システム監査人は、範囲、目的、監査の委託事項を特定する監査契約書あるいは監査ポリシーを持 つ権利を有する。 3.1.2 情報システム監査人は、効果的かつ効率的に監査を完了させるための適切な情報と資源に利用する権利 を有する。 3.1.3 情報システム監査人は、テストと評価が情報システム監査人のその他の立証されない限り、不正行為を防 ぎ、抑止し、検出するための適切なコントロールをマネジメントが確立していると信じる権利を有する。 3.1.4 情報システム監査人は、監査の客観的な完了を可能にするために必要かつ適切と思うような情報と説明 を求める権利を有する。 3.1.5 情報システム監査人は、監査の過程で得た、情報システム監査人の結論をサポートする作業ファイル、文 書、監査証拠等を保有する権利と、それらを問題や矛盾がある場合に参照する根拠として使用する権利を 有する。 3.2 制限 3.2.1 情報システム監査人は、不正行為の兆候を識別するだけの十分な知識を持つべきであるが、不正行為を検 出し調査する主な責任者が専門性を有することは期待しなくともよい。 3.2.2 情報システム監査人は、合理的に慎重かつ有能な専門家として期待される専門家として正当な注意とスキ ルを用いるべきである。しかし、専門家として正当な注意が絶対確実を意味するものではない。 263 G34 責任、権限および説明責任 3.2.3 情報システム監査人は、目的、運用、資源に影響する重要なリスクに対して警告すべきである。しかし、専 門家として正当な注意でそれが行われても、保証手続だけではすべての重要なリスクが識別されるは保証 されない。 3.2.4 情報システム監査人が必要な情報を得られず、資源にアクセスすることが制限され、監査人の役割がどの ような方法であれ拘束される場合、情報システム監査人は、その関心事を適切なマネジメントの上級レベ ルにエスカレートすべきである。情報システム監査人は専門的な態度で監査を実施すべきである。 3.2.5 情報システム監査人が外部の専門家のサービスを活用する場合、情報システム監査人は、このような外部 専門家によって実行される作業の有用性と十分性を評価すべきである。また、外部専門家の発見事項を確 認するために適切なテストを実行すべきである。 3.2.6 情報システム監査人は、是正措置を実施するための責任を負うものではない。 4 説明責任 4.1 専門家の説明責任 4.1.1 従来の解釈と通常の論文は、不正行為を責任をとり、それを罰するプロセスとして説明責任が判断する。 専門的には、これは肯定的な動機、つまり成果と管理を実証する機会として見られる。この観点では、説明 責任とは、物事を成し遂げ責任を持つための効果的な関係を確立するのに不可欠な部分である。 4.1.2 情報システム監査人の正確な役割との関係は、異なる組織および担当業務の種類によって異なる。従って、 任務提供者と任務の目的が明瞭であることが重要である。重要な関係者との監査人の関係は、被監査部 門と決定され、その監査契約書の中で記載されるべきである。 4.1.3 情報システム監査人は、客観的であり、例えば組織マネジメントから独立性を維持する原則として受け入れ られている。経営陣、 マネジメントは、時折コントロールとその他のことでより大きな再保証を求める。十分 な内部統制構造を構築して維持するのは経営者の責任である。このような事情のなかで、情報システム監 査人は提出された報告書の信用性に説明責任を持つ。 4.1.4 説明責任は、専門的なデューデリジェンス、積極的なアプローチ、サービスの提供における透明性、関係あ ると認識するグループにタイムリーに信用できる情報を報告し提供することによって確立することができる。 4.1.5 説明責任は、明示的または黙示的両方の期待に合意された実行の責任である。 4.1.6 情報システム監査人は、施行された時点の法令によって求められないかぎり、組織の承諾なしに、専門家 として関与した過程で取得情報を組織以上に人に開示することを充分に注意すべきである。 情報システム監査人は、情報の開示のコンプライアンスに合理的な保証を提供するために、被監査組織に 適用される様々な規制や法的な問題を常に参照すべきである。 4.2 業務上過失 4.2.1 情報システム監査人は、十分要求にかなう情報を得ることなしに、また、一般に受け入れられる監査の実践 に基づいた関係する監査証拠を処理せずに、意見を表明するべきではない。 4.2.2 情報システム監査人は、手続、ポリシー、コンプライアンスとは離れたているが、担当業務を監査している 間に気付きとなったいかなる材料も適切な関係者、当局に報告すべきである。 4.3 制約事項 4.3.1 情報システム監査人は、もしその独立性が損なわれるか、損なわれると思われる場合に、その担当業務を 受け入れるべきではない。例えば、情報システム監査人が被監査組織に利害関係を持つ、あるいは被監査 部門に対して独立性がない場合、その任務を受け入れるべきではない。利害関係の例は、債務、組織に多 額の投資かもしれない。 264 G34 責任、権限および説明責任 4.3.2 情報システム監査人は、監査人の氏名を用いて、権限のない人や企業が報システム監査の担当業務を実施 させるべきではない。 4.3.3 情報システム監査人は、不当な手段で専門家の仕事を求めるべきではない。また、専門家の担当業務を得 るための委員会や証券会社の支払いを行うべきではない。 4.3.4 情報システム監査人は、専門家としての業績やサービスを宣伝すべきではない。情報システム監査人を、そ の専門家サービスを推進する上で、情報システム監査人は、以下のことをすべきでない。 • 専門に不評をもたらす手段の使用 • 提供するサービス、保有する資格、得られた経験に対する誇張した主張 • 他の情報システム監査人の仕事への侮辱 4.3.5 情報システム監査人は、非倫理的な手段で専門家の仕事を求めるべきではない。 5 適用開始日 5.1 本ガイドラインは、2006年3月1日以降に始まるすべての情報システム監査に適用される。 用語集はISACAのウェブサイトwww.isaca.org/glossaryで見ることができる。 265 G35 フォローアップ 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 267 2 フォローアップ‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 268 3 コンサルティング‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 271 4 報告書‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 271 5 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 271 G35 フォローアップ 1 背景 1.1 基準との関連 1.1.1 基準S8『フォローアップ』は「情報システム監査人は、発見事項と勧告事項に係る報告を行った後、経営者 （マネジメント）により、適切な時期に適切な対応措置（アクション）が実施されたか否かを判断するため、 適切な関連情報を収集して評価すべきである」と述べている。 1.2 COBITとの関連 1.2.1 ハイレベルコントロール対象M3『独立した保証を得る』は、 「...組織、顧客やサードパーティプロバイダの 間で信頼と信用を高めるために独立保証を得ること」と述べている。 1.2.2 ハイレベルコントロール対象M4『独立監査に備える』は、 「...自信のレベルを高め、ベストプラクティスの アドバイスの恩恵を受けるように独立監査に備えること」と述べている。 1.2.3 詳細なコントロール対象M4.8『フォローアップ』は、 「監査意見の解決はマネジメントにかかっている。適 切なアクションを速やかに実施されているかどうかを決定するための以前の発見事項、結論、勧告事項に 関する適切な情報を、監査人は要求し、評価すべきである」と述べている。 1.3 COBITの参照 1.3.1 個々の監査範囲に適用可能であるCOBITの中から最も関連する材料の選択は、特定のCOBIT ITプロセ スを選択し、COBITのコントロール目標と関連するマネジメントの実行を勘案して行う。IT監査・保証の専 門家が必要とするITガバナンスに合わせるべく、最も関連し、選定され、採用されそうなCOBITのプロセス が、ここで主要なものとして分類されている。選定され、採用されるべきプロセスとコントロール目的は、特 定の範囲と任務の権限次第で変化するかもしれない。 1.3.2 主要な参照： • M3 独立した保証の取得 • M4 独立した監査に対する提供 1.3.3 能力に最も関連する情報規準： • 主：有効性、効率性、機密性、インテグリティとコンプライアンス • 副：可用性と信頼性 1.4 ガイドラインの目的 1.4.1 本ガイドラインの目的は、報告書に記した勧告事項や監査コメントに基づいて、フォローアップを実施する 情報システム監査人に方向を提供することである。 1.4.2 このガイドラインは、情報システム監査基準S8『フォローアップ』を適用する手引きを提供する。 1.5 ガイドラインの適用 1.5.1 本ガイドラインを適用するとき、情報システム監査人は、他の関連ISACAの基準およびガイドラインとの 関係で、その手引きを考慮するべきである。 267 G35 フォローアップ 2 フォローアップ 2.1 定義 2.1.1 情報システム監査人によるフォローアップは、 「外部監査人等によって作成されるものを含め、業務の考察 と勧告事項について報告されたマネジメントに実行されたアクションの妥当性、有効性、適時性の決定す るプロセスとして」定義される。フォローアッププロセスは、レビューから生じる合意された結果が、経営者 の取組みに基づき実装されていること、あるいは、提案された成果を遅らせたり、実装されていなかったり する固有のリスクを経営者が認識し、認めることを要求することによって、情報システム監査人によって実 施されたそれぞれのレビューが、組織へ最適な利益を提供する合理的な保証の付与を援助するように確立 されるべきである。 2.2 マネジメントの提案アクション 2.2.1 契約組織と情報システム監査人との協議の一部として、情報システム監査人は、業務の結果に、また必要 に応じて運用を改善するアクションプランに、同意を得るべきである。 2.2.2 マネジメントは、それぞれの提案に対するアクションが完了する導入日／アクション日を提供すべきである。 2.2.3 マネジメントが提案アクションを実装するとき、あるいはその逆で、情報システム監査人と協議されるか、情 報システム監査人に提供された勧告事項と監査コメントへ報告されるとき、これらのアクションは約束した 実装日を付した最終報告書の中で経営者の回答として記録されるべきである。 2.2.4 もし情報システム監査人と契約組織が特定の勧告事項あるいは監査コメントについて合意形成できない 場合、契約協議は合意しない点とその理由を述べてもよい。その組織が記載したコメントは業務報告の付 属書として含めてもよい。代わりに、組織の見解は、報告書の本文にまたはカバーレターに表示してよい。 その際、上級マネジメント（あるいは存在するならば監査委員会）は、支援する観点として決定すべきで ある。もし上級マネジメント（あるいは監査委員会）は、特別なケースとして組織の観点から支援する場合、 情報システム環境（2.4.3項参照）の変化による観察の影響の重要性とレベルが変更されていると考慮さ れない限り、情報システム監査人はその特別の勧告事項をフォアローアップする必要はない。 2.2.5 実装前のアプリケーションシステムのようなレビューの期間、発見事項はプロジェクトチーム、あるいはま たマネジメントに課題の形式で継続的に報告されてもよい。これらのケースでは、挙げられた課題を解決す るためのアクションが継続的にモニタリングされるべきである。勧告事項となる課題が実装された際には、 最終報告書の中の勧告事項に対して「完了」か「実装済」と記録することができる。 「完了」か「実装済」 の勧告事項は報告されるべきである。 2.3 フォローアップ手続 2.3.1 フォローアップの手続は次の事項を含んで策定されるべきである。 • マネジメントが勧告事項の合意を回答すべき期間の記録 • マネジメントの回答の評価 • もし適用が必要であれば、回答の検証（2.7項参照） • もし適用が必要であれば、フォローアップ作業 • 未解決で十分でない回答やアクションを適切なレベルの経営者へエスカレートする協議手続 • 救済措置が遅れるか実装される提案になっていない状況における、 マネジメントの関連するリスクの引き 取りに合理的な保証を付与するプロセス 2.3.2 トラッキングシステムあるいはデータベースがフォローアップの実行する行為を支援できる。 268 G35 フォローアップ 2.3.3 適切なフォローアップ手続を決定するために考慮すべき要因は次のとおりである。 • 報告された観察の重要性に影響するかもしれない情報システム環境における変化 • 報告された発見事項あるいは勧告事項の重要性 • 是正措置が失敗に終わる結果の影響 • 報告された問題を是正するために必要な努力とコストの程度 • 是正措置の複雑性 • 関与する期間 2.3.4 情報システム監査人が内部監査環境に従事しているならば、フォローアップの責任は内部監査アクティビ ティのポリシーに定義されるべきである。 2.4 フォローアップの時期とスケジュール 2.4.1 是正措置が取られなければ、フォローアップの種類、時期、程度は、報告された発見事項の重要性を考慮 すべきである。元の報告に関連する情報システムフォローアップのタイミングは、組織に対するリスクとコス トに関連した性質あるいは.大きさのような、多くを考慮した専門的な判断事項である。 2.4.2 高リスクの問題に関連する合意された結果は、アクションの期限の直後にフォローアップされるべきである。 または、順次モニタリングを行ってもよい。 2.4.3 フォローアップは情報システム監査プロセスの不可欠な部分なので、フォローアップは、各レビューを実施 する必要がある他のステップに加えて、スケジュールされるべきである。特定のフォローアップとその活動 の時期は、レビューの結果によってもよいし、部門のマネジメントと協議して決定してもよい。 2.4.4 特定の報告書の中で、 マネジメントが約束した実装日とは異なっているものがあってもマネジメントの回答 すべての実装を一緒にフォローアップしてよい。別の方法としては、 マネジメントが合意している個々の期限 に沿ってフォローアップすることである。 2.5 フォローアップの延期 2.5.1 情報システム監査人は、開発業務スケジュールの一部としてフォローアップを実施するスケジュールに責任 を持つ。フォローアップのスケジュール策定は、是正措置を実装する時期の重要性と難しさの程度と同様 に、リスクと関与する脅威に基づくべきである。 2.5.2 業務観察や勧告事項の相対的な重要性を比較考慮する際に、アクションが既に十分に取られたとマネジ メントの口頭または書面による回答が示していると情報システム監査人が判断する場合もまたあってよい。 この様な場合、実際のフォローアップの検証活動は、関連するシステムあるいは問題を扱う次の業務の一 部として実施されてもよい。 2.6 フォローアップ回答の様式 2.6.1 マネジメントからのフォローアップ回答のもっとも効果がある方法は、書面である。これはフォローアップと 達成状況に対するマネジメントの責任を強化して確認するのに役立つ。また、書面での回答は、アクション、 責任、現状の正確な記録であることを保証する。口頭での回答は、また、情報システム監査人によって受領 され記録され、 マネジメントによって証明されうる場合である。勧告事項のアクション、導入の証拠は、また、 その回答によって与えられてもよい。 2.6.2 情報システム監査人は、 マネジメントが実施した特にハイリスクの問題、リードタイムが長期にわたる救済 措置に関する同意したアクションの進捗を評価するために、 マネジメントから定期的に更新状況を要求、受 領をしてよい。 269 G35 フォローアップ 2.7 フォローアップの種類と程度 2.7.1 通常、情報システム監査人は、組織から同意されたアクションの一部あるいは全部の提案の導入日が過ぎ た後、すぐにフォローアップの状況を要求するだろう。これは勧告事項を導入するために採用されてアクショ ンの詳細を記述する報告書の中の領域を組織に提供するために、最終調書に形式を変更そることになっ てもよい。 2.7.2 組織は、通常、勧告事項を導入するために採用されるアクションの詳細を回答する中で、タイムフレームを 与えられる。 2.7.3 採用されるアクションを詳細なマネジメントの回答は、可能であれば、当初にレビューした情報システム監 査人によって評価される。採用されたアクションの監査証拠は、可能なところではどこでも得られるべきで ある。例えば、手続は記録されるか、経営者レポートが作成されるである。 2.7.4 マネジメントが勧告事項を実装するために採用されるアクションの情報を提供し、情報システム監査人がそ の採用されたアクションの提供された情報やその効果に疑問を持つ場合、フォローアップを完了させる前の、 真の位置あるいは状況を確認するために、適切なテスティングか他の監査手続が取られるべきである。 2.7.5 フォローアップの一部として、情報システム監査人は、実装されていない勧告事項がまだ関連しているか、 あるいはより重要であるかを評価すべきである。情報システム監査人は、特定の改善勧告の実装がもはや 適切ではないと決定してもよい。これは、アプリケーションシステムが変更された場合、補完コントロール が実装された場合、あるいは、元のリスクを効果的な除去または大幅に削減するような方法で、ビジネス対 象、優先事項が変更された場合、である。同様に、情報システム環境における変化は、以前の観察やその 解決の必要性の影響の重要性が増すかもしれない。 2.7.6 フォローアップ業務は、重大且つ重要なアクションの実装を確認するために、スケジュールを策定してよい。 2.7.7 満足しないマネジメントの回答やアクションに対する情報システム監査人の意見は、経営者の適切なレベ ルに報告されるべきである。 2.8 マネジメントによるリスクの受容 2.8.1 マネジメントは、報告された業務の考察や勧告事項に回答する適切なアクションを決定する責任がある。 情報システム監査人は、業務の考察や勧告事項として報告された事項の適切性や適時な解決に対してマ ネジメントアクションを評価する責任がある。 2.8.2 上級マネジメントは、費用あるいは他の考慮事項のため、報告状況を改善しないリスクを受け入れることを 決定するかもしれない。経営陣（もしあるなら監査委員会）は、すべての重要な業務の考察や勧告事項に ついての上級マネジメントの決定を知らされなければならない。 2.8.3 組織がその組織に対して不適切である残存リスクのレベルを受け入れたと情報システム監査人が信じた時、 情報システム監査人は、内部監査と上級マネジメントと共にその点について協議すべきである。もし情報シ ステム監査人が残存リスクに関する決定に同意しないならば、情報システム監査人と上級経営者はそれを 解決するために経営陣（もしあるなら監査委員会）に報告すべきである。 2.9 内部情報システム監査人による外部監査フォローアップ 2.9.1 継続的な内部監査アクティビティのフォローアップ責任は、内部情報システム監査機能、あるいは契約文 書にある他の監査業務は、監査ポリシーの中で割り当てられるべきである。 2.9.2 業務および関係する情報システム監査基準に関する範囲や条項に基づいて、外部情報システム監査人は、 同意を得た勧告事項をフォローアップするため内部情報システム監査機能に依存するかもしれない。 270 G35 フォローアップ 3 コンサルティング 3.1 コンサルティング型業務 3.1.1 コンサルティング型業務、サービスは、 「クライアントに同意を得て、組織運営に価値を付与し、改善する、 助言およびその関係するクライアントサービスアクティビティ、種類、範囲。例えば、意見交換、助言、ファ シリテーション、プロセス設計、トレーニング」として、定義される。契約の種類と範囲は、契約が開始され る前に同意が得られるべきである。 3.1.2 情報システム監査人は、組織の合意の程度でコンサルティング業務の結果をモニタリングすべきである。 様々なモニタリングの型は、コンサルティング業務の異なる型に当てはめてよい。モニタリングする努力は、 その業務成果に対するマネジメントの明示的な関心、あるいは、情報システム監査人の業務によって識別 されるプロジェクトのリスク、組織への潜在的な付加価値の情報システム監査人の評価のような要因に基 づくかもしれない。 4 報告書 4.1 フォローアップの報告書 4.1.1 情報システム監査報告書から想起される同意された救済措置の状況についての報告は、同意された勧告 事項が実装されないことを含めて、もし設置されていれば監査委員会、あるいは、その代替として組織マネ ジメントの適切なレベルに提示されるべきである。 4.1.2 その後に続く契約の間に、経営者が「導入済」と主張したアクションを実際には導入していないと、もし情 報システム監査人が発見した場合、これは上級マネジメント（もしあれば監査委員会）に報告されるべきで ある。 4.1.3 すべての救済措置が実装されたとき、上級マネジメント（もしあれば監査委員会）に対して、実装済、未実 装のアクションすべての詳細を記載した報告書が送られるに違いない。 5 適用開始日 5.1 本ガイドラインは、2006年3月1日以降始まるすべての監査に適用される。 用語集はISACAのウェブサイトwww.isaca.org/glossaryで見ることができる。 271 G36 バイオメトリックス制御 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 273 2 バイオメトリックス制御‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 276 3 監査手続‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 280 4 監査考慮点‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 282 5 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 282 G36 バイオメトリックス制御 1 背景 1.1 基準との関連 1.1.1 基準S6『監査業務のパフォーマンス』では、 「情報システムのメンバは、監査の目的が達成され、当該分 野の諸監査基準が満たされていることについての合理的な保証を確保するため、監督されるべきである。 監査の過程において、情報システム監査人は、監査の目的を達成するために、確実で妥当な証拠を充分得 るべきである。監査の発見事項と監査の結論は、この証拠を適切に分析し、解釈することにより裏付けら れる。」と述べている。 1.1.2 基準S10『ITガバナンス』では、 「情報システム監査人は、情報システムの機能が、監査対象組織のミッ ション、ビジョン、企業価値、目的、戦略に一致しているか否かをレビューし評価すべきである。情報システ ム監査人は、情報システムの資源とパフォーマンスの管理プロセスの実行性をレビューし評価すべきであ る。」と述べている。 1.2 ガイドラインとの関連 1.2.1 コントロールプロセスAI1『自動化されたソリューションの識別』は、 「ITプロセスにおけるコンピュータ化 対応策の明確化のコントロール目標は、ビジネスの機能的要件およびコントロール要件を、効果的かつ効 率的なシステムソリューションによって実現することを、ビジネス要件とし、重点をおくべきコントロールは、 技術的に実現可能でコスト効率に優れたソリューションを明確にすることである。」と述べている。 • ビジネス要件および技術的要件の定義 • 開発標準で定義されている実現可能性調査の実施 • 要件および実現可能性調査結果の承認(または否認) その成果の測定指標は、次の項目である。 • 誤った実現可能性見通しを立てた結果、見込まれた成果を達成できなかったプロジェクトの数 • ビジネスプロセスオーナが承認した実現可能性調査の割合 • 提供された機能に満足したユーザの割合 1.2.2 コントロールプロセスAI3『技術的インフラストラクチャの獲得と保守』では、 「ITプロセスにおける技術イ ンフラストラクチャの調達と保守のコントロール目標は、統合および標準化されたITインフラストラクチャ の調達と保守をビジネス要件とし、重点をおくべきコントロールは、定義されたITアーキテクチャおよび技 術標準に合致するビジネスアプリケーションのための適切なプラットフォームを提供することである。」と 述べている。 実現するための手段は、次の項目である。 • 技術インフラストラクチャ計画と整合性のある技術調達計画の策定 • インフラストラクチャの保守の計画 • 内部統制、セキュリティ、および可監査性の測定指標の導入 その成果の測定指標は、次の項目である。 • 定義されたITアーキテクチャおよび技術標準に合致しないプラットフォームの割合 • 陳腐化した(または、すぐに陳腐化する)インフラストラクチャによりサポートされている重要なビジネスプ ロセスの数 • サポート対象外(または近い将来サポート対象外になる)インフラストラクチャコンポーネントの数 273 G36 バイオメトリックス制御 1.2.3 コントロールプロセスのAI5『IT資源の調達』では、 「ITプロセスにおいてIT資源の調達のコントロール目 標は、ITのコスト効率およびビジネス収益性へのITの貢献度の向上を、ビジネス要件とし、重点をおくべ きコントロールは、サービス提供戦略に対応するITスキルと、統合および標準化されたITインフラストラク チャを調達、維持し、IT調達リスクを削減することである。」と述べている。 実現するための手段は、次の項目である。 • 専門家による法的見地からの助言および契約に関する助言の取得 • 調達手続と標準の策定 • 策定された手続に沿った、要求されたハードウェア、ソフトウェア、およびサービスの調達。 • その成果の測定指標は、次による。 • 調達契約に関する係争の件数 • 購入コストの削減額 • サービスプロバイダに満足している主要な利害関係者の割合 • プラットフォームの割合 1.2.4 コントロール目標のAI3では、 「確立された機能面および技術面でのビジネス要件を満たし、組織の技術 的方向性と一致する技術インフラストラクチャの調達、導入、および保守の計画を策定する。その計画は 能力追加、伝送コスト、技術的リスクと技術的更新のための投資期間の将来の柔軟性を考慮すべきであ る。新たな技術的能力を追加する際のベンダーと製品の複雑なコストと商業的活力を評価すること。」と 述べている。 1.3 COBITの参照 1.3.1 個々の監査範囲に適用可能であるCOBITの中から最も関連する材料の選択は、特定のCOBIT ITプロセ スを選択し、COBITのコントロール目標と関連するマネジメントの実行を勘案して行う。 1.3.2 選択される、そして適用されるプロセスとコントロールの目標は特定の範囲と適用の参照項目に従って異 なってもよい。要求事項に合致するために、COBITに最も関連し、選択され、適用されるプロセスは下記 記載の主項目と副次項目に層別される。 1.3.3 主要な参照： • PO1 IT戦略計画の策定 • PO3 技術指針の決定 • PO5 IT投資の管理 • PO8 品質管理 • PO9 ITリスクの評価と管理 • PO10 プロジェクト管理 • AI1 コンピュータ化対応策の明確化 • AI3 技術インフラストラクチャの調達と保守 • AI5 IT資源の調達 • DS1 サービスレベルの策定と管理 • DS3 パフォーマンスとキャパシティの管理 • DS4 継続的なサービスの保証 • DS5 システムセキュリティの保証 • DS7 利用者の教育と研修 • M1 IT成果のモニタリングと評価 • M2 内部統制のモニタリングと評価 274 G36 バイオメトリックス制御 • ME3 外部要件に対するコンプライアンスの保証 1.3.4 副次的参照： • PO6 マネジメントの意図と指針の周知 • AI6 変更管理 • DS9 構成管理 • DS10 問題管理 • DS11 データ管理 1.3.5 バイオメトリックスコントロールに最も関連する情報要請規準： • 主：有効性、効率性、有用性 • 副：機密性、インテグリティ、信頼性 1.4 ガイドラインの目的 1.4.1 識別と認証の伝統的な手段-アクセス制御への肝心な要点-は、PIN（個人識別番号）のような「個人が 知っている何か」、あるいはパスワード、およびスマートカードやATMカードの様な「個人が持っている何 か」に基づく事である。パスワードを記憶することでもなく、カードを持ち歩くことでもなく、個人の記憶に 頼る必要から離れて、これらのアプローチは個人を特別な方法で区別するものではない。パスワードとトー クンベースのシステムは欠点を持ち、特に危機下においてはボトルネックを導く。技術の進歩に伴い、 「個 人が誰であるか」についてより信頼できるアクセス制御方法へのパラダイムシフトがある。たとえば、バイオ メトリックスベースのアクセス制御。 1.4.2 正確性はバイオメトリックスアクセス制御システムにとって重要な特徴となる。たいていの場合に識別は、 格納されたイメージのデータベースから「多くの人から特定の個人」をサーチする特徴となる。一方、認証は 「個人がその個人である」サーチとして個人により識別される認証請求となる。バイオメトリックスは、通常 物理的なアクセス制御で識別適用され、認証識別は論理的なアクセス制御で適用される。仮に偽者から の認証を区別することができなければ、そのシステムは失敗となる。偽りの拒否（偽りの否認）あるいは偽 りの受諾（偽りの肯定）などのインシデントの比率がコスト/リスク評価の結果として組織に低く受諾され る事が重要である。 1.4.3 バイオメトリックス技術と連携したセキュリティアーキテクチャーの増加に伴い、情報システム監査人がリ スクとそれらの技術に関連した対応策に気づく事が重要になって来ている。情報システム監査人はバイオ メトリックス制御システムのレビューは、ビジネス目標を達成する技術、ビジネスプロセスとコントロール目 標を確実にするための優れた眼識を持つべきである。 1.4.4 監査業務をしている時バイオメトリックス制御をレビューする情報システム監査人へのガイダンスを提供す る必要性を本文書において記述した。 1.5 ガイドライン適用 1.5.1 このガイドラインでは、情報システム監査基準Ｓ６『監査業務の達成』とＳ１０『ＩＴガバナンス』での適用 を提供する。 1.5.2 情報システム監査人は、このガイドラインが先に言及した基準実装をいかに達成するか、適用においてのプ ロフェショナルな判断、逸脱についての正当性の準備をいかにするかへのガイドラインを考慮すべきである。 1.5.3 このガイドラインを適用する際に情報システム監査人は他のＩＳＡCAスタンダードとガイドラインと関連す るガイドラインを考慮すべきである。 275 G36 バイオメトリックス制御 2 バイオメトリックス制御 2.1 導入 2.1.1 「バイオメトリックス」という言葉は、ギリシャ語の「バイオ」と「メトリックス」、 「寿命」を意味する言葉か ら派生している。生理的な特徴、行動的特徴に基づく個人の自動的な識別や認証として定義された。科学 的なバイオメトリックスは、個人の生理的、行動的な特徴のユニーク性を利点として利用している。 2.1.2 バイオメトリックス制御は、ポリシー、手続、実践、組織構造を設計する個人の生理的、行動的な特徴の利 用の事を言っている。それらの特徴はビジネス目標、識別や認証についても、合理的な保証を提供し、好ま しくないイベントが抑止されたり検出、訂正される事も提供する。 2.1.3 典型的なバイオメトリックスシステムの機能を図表１に掲載した。 図表1 典型的バイオメトリックスシステムの機能 2.2 加入登録 加入登録プロセスでは、利用者になりたい人にレファレンステンプレートのリポジトリを電子的に変 換と保存を行うバイオメトリックスサンプルを提供する。 データ保存 個人参照のテンプレートは、リアルタイムアクセスの間、利用者のバイオメトリックスのアクセス可能 な認証リポジトリへの保存がなされる。 その保存は、バイオメトリックスデバイス、中央のリポジトリへのリモート、スマートカードの様なポー タブルトークン、およびそれらの方法の組合せに位置付けられる事が出来る。 データ取得 データは妥当な利用者がアクセスを得るための識別と認証のために得られる。データは利用者がア クセスを得たいと望む時にいつでも得られる。 伝送 伝送経路は識別や認証のためのデータを得られる伝送システムにより利用される。この伝送路はバ イオメトリックスシステムにとって内部あるいはＬＡＮの様に外部でもかまわない。 信号処理 信号処理やイメージ処理は、格納されているデータとのマッチング処理や妥当性検証を含む。リポジ トリに保存されているレファレンステンプレートは得られたデータとマッチングされ、その結果はマッ チングの品質に従う。 決定 この機能は、利用者への許可あるいは拒否を来なうための「マッチする」、 「マッチしない」を決める 機能となる。 識別と認証 2.2.1 バイオメトリックスは、生理的特徴や行動的な特徴に基づく生きている人物の識別のための識別、認証の 自動的なプロセスとなる。 2.2.2 バイオメトリックスにおいて、識別はデータリポジトリから個人の特徴を多くの人物から一人の人物をサー チすることを含む。バイオメトリックスにおける認証は、個人からなされる識別要求の妥当性検証要求を行 う、一人から一人をサーチする事を含む。 2.2.3 典型的にバイオメトリックスは識別にいける物理的コントロールと認証における論理的なコントロールを 利用する。 276 G36 バイオメトリックス制御 2.3 達成状況の測定 2.3.1 達成状況の測定は、プロダクトの評価を助けるベースラインを提供する様に設計されている。情報システ ム監査人は、監査業務時にバイオメトリックスシステムの達成状況を評価するこれらの測定を考慮すべき である。バイオメトリックスシステムにおける主な測定項目は下記、図表２の通りである。 図表2 FAR, FRRとCER、サンプル図 FAR FFR CER パーセンテージ 感受性 FARは感受性の増加により減少し、 FRRは感受性の増加により増加する。 2.3.2 False rejection rate (ＦＲＲ)、タイプⅠエラー – システムにより偽りとして拒否された妥当性に係る パーセンテージの測定。ＦＲＲ(%)＝偽りとしての拒否の数＊ユニークな試行の合計を１００として。 2.3.3 False acceptance rate (ＦＡＲ)、タイプⅡエラー – システムにより偽りとして受容された妥当性無しに 係るパーセンテージの測定。ＦＡＲ(%)＝偽り受容の数＊ユニークな試行の合計を１００として。 2.3.4 Cross-over error rate (ＣＥＲ) – ＦＲＲとＦＡＲが交差する点のパーセンテージを表す。ＣＥＲは、感受 性と達成状況がうまくバランスしたシステムを表現している。 2.3.5 Enrollment time(加入登録時間) – 新しい課題をシステムに提供する際の初期の加入登録に要する時間。 2.3.6 Failure to enroll rate (ＦＴＥＲ) - 加入登録試行の失敗率を決定するために利用される。 ＦＴＥＲ＝ 成功しない加入登録の数/利用者による加入登録試行の合計 2.3.7 スループット率 – 識別や認証機能を処理するデータリポジトリのトランザクションデータの妥当性検証 をするシステムに係る時間。この率は加入登録課題がシステムから受容される、あるいは拒否される際のも のとなる。 277 G36 バイオメトリックス制御 2.4 バイオメトリックスシステムの類型 2.4.1 バイオメトリックスシステムは、広義に２つのガテゴリーに分類される。ひとつは生理的特徴に基づく、つま り「我々が何者であるか」、そしてもうひとつは行動的特徴に基づく、つまり「我々は何をする」。 2.4.2 生理的特徴に基づく様々なバイオメトリックスシステムは、図表３。 図表3 生理的特徴に基づくバイオメトリックスシステム バイオメトリックスシステム データの加入登録/取得 指紋 ガラスやポリカーボネートのプレートに指をしっかりと押し付けた特に得られるイ メージ 指紋ティップ 肌で捕捉する血管のパターン 指の関節 指の第１関節と第２関節で捕捉する ハンドジオメトリー ３次元で手と指の長さ、幅、高さをカメラで水平方向、垂直方向で捕捉する 網膜スキャン 眼球の裏側に位置する網膜の血管パターンイメージをカメラで捕捉する 虹彩認識 カメラでアイリス（虹彩）の捕捉 手首の血管 手首部分の血管パターンで捕捉 指関節折り目 棒を掴んだ時の指関節折り目で捕捉 顔認識 高精度カメラでの顔イメージ認識で捕捉 顔の熱感知 熱感知装置を使って顔組織の熱パターンを捕捉 2.4.3 行動特徴に基づく様々なバイオメトリックスシステムは、図表４。 2.5 図表4 行動特徴に基づくバイオメトリックスシステム バイオメトリックスシステム データの加入登録/取得 音声認識 声を電子的に音声に変換し、バイナリー数で保存。 動的キーストローク キーストロークの時間（個々のキーが押される時間長）とキー間の移動時間の計 測 動的署名 署名される時のスピード、圧力、時間を比較計測 データストレージ 2.5.1 容易な検索と比較のためのアクセス可能なリポジトリにレファレンステンプレートを格納すべきである。 2.5.2 バイオメトリックスリーダー装置内におけるローカルストレージはリファレンステンプレートへの素早い可用 性と早いマッチングを可能にし、展開の柔軟性を許容する。然しながら、バックアップとリストアプロセス により充分に支援されない場合では、システムはシステムクラッシュ時の再加入登録を要求することになる。 2.5.3 大きな組織においては、利用者が中央に位置されバイオメトリックス装置とネットワーク接続を認識する中 央のリポジトリでレファレンステンプレートが保存される。特にデータサイズやボリュームが大きい場合に は、検索は比較的遅い。 2.5.4 利用者がバイオメトリックスレファレンスサンプルを持ち歩く様なスマートカードにレファレンステンプレー トは保存されるべきであり、利用者はリファレンステンプレートのプライバシー、機密性、可用性、インテグ リティについて責任を持つ。スマートカードも同様に装置をより安全にする暗号化、デジタル署名の様な セキュリティ特徴を加えて持っても差し支えない。 2.5.5 データの機密性とインテグリティは、個人情報が承認されないアクセスから防御される様に管理されるべ きである。 278 G36 バイオメトリックス制御 2.6 バイオメトリックスにおけるリスクとコントロール 2.6.1 情報システム監査人はバイオメトリックスシステムにとっての典型的なリスクとコントロールの尺度に留意 すべきでる。最も一般的なリスクと対応策は以下図表５の通りとなる。 図表5 一般的なバイオメトリックスシステムのリスクと対応策 リスク 例 可能な対抗策 スプーフィングと 擬態攻撃 指紋バイオメトリックス装置における人工 的な指紋 マリチモーダル・バイオメトリックス、 持続性検出、インタラクティブ認証 偽者テンプレートリスク サーバに保存された偽者テンプレート 暗号化、侵入検出システム(IDS)、 スマートカード 伝送リスク 加入登録あるいはデータ取得の際の 伝送データの横取り インタラクティブ認証、識別署名や システムインテグレーションの拒否 クロスシステムリスク 異なるセキュリティレベルにおける 異なるアプリケーションでの同一の テンプレートが使われること ハッシュ機能、 コーディングアルゴリズム コンポーネント代替 リスク 悪意あるコード、トロイの木馬、他 システムインテグレーションにおける 優れたセキュリティポリシーの組込 加入登録、管理と システム利用時のリスク 加入登録、管理、システム利用時の データの置き替え 優れたセキュリティポリシーの組込 ノイズと電源喪失の リスク 光学的なセンサーのフラッシュライトによ 優れたセキュリティポリシーの組込 る指紋の温度と湿度による変化 電源と時間分析の リスク バイオメトリックステンプレートにおける電 バイオメトリックス装置における 源分析と収集データの異なる支給電源分析 ノイズジェネレーター、低電源チップ 残存特徴のリスク 様々な手段によりコピーされるセンサー上 の残存指紋 技術的評価、 マルチモーダルアクセス 同様のテンプレート、 同様の特徴における リスク 正当な利用者と同様のテンプレートを持 つ不正な利用者 技術的評価、 マルチモーダルアクセス、差 異計測レビュー ブルートフォース攻撃 リスク 侵入者がブルートフォース攻撃を装置やシ 不成功な攻撃試行の後にアカウントの ステムに対して行う ロックを行う インジェクションリスク 伝送を安全にする、つまり熱センサーに 認証されたシステムへのデジタル署名によ より活性化するスキャナー（温度のある るインジェクション 人体）、イメージのデジタル表現における データ/時刻のスタンプ 利用者による拒否 バイオメトリックステクニックの侵入性質 が引き起こすシステム利用拒否 物理的特徴の変更 いくつかのテクニックは顔や手の特徴に依 ＣＥＲの監視 存しているが、これらは経年変化する。 他のレガシーシステムに伴う インテグレーションコスト インテグレートされるべきレガシーシステム で使用される他のテクニックとの一貫性 コストベネフィット分析 データ喪失のリスク ハードディスク/ハードウェアの不具合 データのバックアップとリストア 利用者への訓練と気づき、および侵入され る可能性の少ないテクニックの選択 279 G36 バイオメトリックス制御 3 監査手続 3.1 バイオメトリックスシステムの選択と取得 3.1.1 情報システム監査人は、次のバイオメトリックスシステムの選択と取得に係るプロセスをレビューすること を考慮すべきである。 • バイオメトリックスシステム導入の目標とこれらの組織ビジネス目標との関連 • リスク分析とプライバシー、法的事項への考慮を含む資産の階層化によるバイオメトリックスシステム選 択の研究 • リスク分析の影響と緩和計画 • バイオメトリックスコントロール利用によるビジネスへの影響 • バイオメトリックスコントロールの従業員、顧客、ビジネスパートナーへの効果 • バイオメトリックスシステム対伝統的アクセスシステム、例えばユーザＩＤとパスワード認証の様なもの からの投資効果 • バイオメトリックス製品の陳腐化 • 製品の産業、国家/世界標準への準拠性 • 製品パフォーマンスとサプライヤーサービス支援のマーケット分析 • 業者の適合資格と製品の適合資格 • データ収集におけるシステムの侵入性 • 同類の産業と他の産業/組織内での利用者アクセス性 • 法的考慮および利用者の権利（プライバシー） 3.2 バイオメトリックスシステムの運用と維持管理 3.2.1 情報システム監査人は次のバイオメトリックスシステムの運用と維持管理に関連した特徴をレビューするこ とを考慮すべきである。 • 組織のセキュリティポリシーに関連したバイオメトリックスポリシー • バイオメトリックス情報のセキュリティ機密性、インテグリティ、可用性（ＣＩA），データリポジトリへの 制限されたアクセス • 加入登録時間、その成功率、失敗率、スループット時間、ダウンタイム時間、偽りの肯定、偽りの否定、 平均不具合時間（ＭＴBF）、平均修復時間（ＭＴTR）、ＦＴＥＲの様なデータ分析を通してバイオメト リックスシステムの効率性を監視する • バイオメトリックスシステムと他のアプリケーションやシステム（例えば、シングルサインオン）とのイン ターフェース • 運用と維持管理のコストの分析 • データストレージ許容量からの要求事項 • データセキュリティ、バックアップ、リストアの手順 • アップグレードとパッチの管理 • 会社が行う実行結果の後に利用者記録が破壊されてしまう • バイオメトリックスシステムの失敗とスタンバイシステムの可用性/補完的コントロールなどの場合におけ 事業継続性 • ロールベースアクセスが利用されている場所での適切な変更管理 280 G36 バイオメトリックス制御 3.3 利用者の訓練と受容 3.3.1 情報システム監査人は次のバイオメトリックスシステムの利用者訓練と受容に関連する特徴をレビューする ことを考慮すべきである。 • 組織内におけるバイオメトリックスポリシーの周知 • バイオメトリックス情報と本来の利用者のプライバシーを安全にすることへのコミットメント • 関連するプライバシーとバイオメトリックスの立法と規制に対するコミットメント • バイオメトリックス認証システム利用者による認知 • バイオメトリックスシステムへの所有者の役割と責任の識別 • 訓練ニーズ、訓練スケジュール、ヘルプデスクとサポートサービスの識別 • システム、防御、システムと自分で行うウィルス予防策利用に係る訓練 • 文書化された訓練マテリアルと掲示板の可用性 • 被害を受けたあるいは怠ったシステムへの利用者が組織的対応されないリスク 3.4 システムパフォーマンス 3.4.1 情報システム監査人は、バイオメトリックスシステムのシステムパフォーマンスに関連した次の特徴をレ ビューすることを考慮すべきである。 • アプリケーションとのシステムインターフェース • 加入登録、再加入登録および利用者の削除のプロセス • 課題とシステムのコンタクト要求事項 • システムに対するテスト、認証、妥当性検証と承認 • アクセス定義と特権管理のテスト • 改ざんあるいは怠業に対する防御 • 情報漏洩に対する防御 • データのバックアップ • システム失敗時における事業継続計画（ＢＣP）とＢＣＰのテスト • 定期的なテスト（たとえば、ブルートフォース） • 偽造と引き延ばされた利用における信頼性への抵抗力 3.5 アプリケーションとデータベースのコントロール 3.5.1 情報システム監査人はバイオメトリックスシステムの設定におけるアクセスコントロールと構成に関連する 次の特徴をレビューすることを考慮すべきである。 • 現在のかつ厳格な事業ニーズを持つ個人における全てのバイオメトリックス情報への制限されたアクセ スを含むプラットフォームセキュリティ構成の設定 • 侵入検出制御 • トランザクションコントロール • 回線を含むネットワークの暗号化 • リポジトリにある格納されたデータの暗号化 • 変更管理（ソフトウェアとハードウェア） • データベースの管理と維持 • ハードウェアとソフトウェアのインストール 281 G36 バイオメトリックス制御 3.6 監査証跡 3.6.1 情報システム監査人はバイオメトリックスシステムにおける監査証跡に関連する次の特徴をレビューするこ とを考慮すべきである。 • アクセスログ • アクティビティログ • 変更ログ • アクセス拒否のログ • システムダウンタイムのログ 4 監査考慮点 4.1 バイオメトリックスシステム利用取得への考慮点 4.1.1 バイトメトリック利用を考慮する際に取り組まれる必要のある考慮点は下記の通り。 • プライバシーへの考慮 – 糖尿病や脳卒中の原因による網膜血管パターンの変化の様な健康上の出 来事。組織が網膜ベースのバイオメトリックスシステムを使っていることがシステム利用者の不利益とし て利用される様な不適切な健康情報を得てしまうことになるかもしれない。物理的特徴の利用と捕捉に 関する全ての立法と規制はバイオメトリックスシステムの導入事前に考慮されなければならない。 • データ収集における侵入 – スキャン時における利用者の個人領域へのセンシティブな侵入 • 感知された疾患 – 感染している皮膚への接触により感染する疾病への考慮（たとえば、指紋スキャ ン時） • システム利用のスキル – システムを利用する際に要求されるスキルを持っていない利用者が居ること もある（リタラシーや能力）し、システムの実際の実行能力を懸念している利用者が居ることもある。運 用条件（たとえば、油で汚れた手、埃っぽい場所）は、システムの実行能力の妨げになることもある。 • システムの頑健性 – バイオメトリックス技術は誰にでも扱えるものではなく、バイオメトリックスアプ リケーションの信頼性に関連する問題を乗り越える必要がある。偽りの拒絶と受容の影響は、運用と 風評の両方の観点からしてもレビューされなければならない。インサイダーによる改ざんと怠業のリスク も排除することができない。 • 導入のコスト – 各アクセスポイントにバイオメトリックス装置を導入するコストは高価なものとなり、 資源を消耗することになるかもしれない。 • 正確性 – 承認されていない利用者がアクセスする可能性と承認された利用者アクセスを拒否される 可能性が存在している。 • 変更への抵抗力 – バイオメトリックスシステムを利用することを抵抗された利用者の存在があるかも しれない。 • バイオメトリックスシステムの利用とコミュニティの利用システムへの許諾の観点での地方自治体での 規制と法定要求事項 5 適用開始日 5.1 本ガイドラインは、2007年2月1日以降に開始するすべての情報システム監査に適用される。 282 G37 構成管理プロセス 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 284 2 監査考慮点‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 286 3 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 289 G37 構成管理プロセス 1 背景 1.1 基準との関連 1.1.1 S6『監査業務のパフォーマンス』では、 「情報システム監査のメンバーは、監査の目的が達成され、当該 分野の諸監査基準が満たされていることについての合理的な保証を確保するため、監督されるべきである。 監査の過程において、情報システム監査人は、監査の目的を達成するために、確実で妥当な証拠を充分得 るべきである。監査の発見事項と監査の結論は、この証拠を適切に分析し、解釈することにより裏付けら れる。」と述べている。 1.2 COBIT4.1との関連 1.2.1 コントロールプロセスのAI2『アプリケーションソフトウェアの調達と保守』のコントロール目標は、適切な 時期に適正なコストで、ビジネス要件に沿った形でアプリケーションの利用を可能にすることを、ビジネス 要件とし、重点をおくべきコントロールは、タイムリーかつコスト効率に優れた開発プロセスが確立するこ とである。 実現するための手段は、次の3項目である。 • ビジネス要件を設計仕様に反映すること • 修正時の開発標準との準拠性 • 開発、テスト、および運用に関するアクティビティの分離 AI2は、次の2項目により測定される。 • 大幅なダウンタイムの原因となった、アプリケーションごとの本番環境での重大問題発生件数 • 提供された機能に満足しているユーザの割合 1.2.2 コントロールプロセスのDS9『構成管理』のコントロール目標では、ITインフラストラクチャ、資源、および 能力を最適化し、IT資産の詳細を把握することをビジネス要件とし、重点をおくべきコントロールは、資産 構成の属性およびベースラインの正確かつ完全なリポジトリを、作成および保守し、実際の資産構成と比 較することである。 実現するための手段は、次の3項目である。 • すべての構成管理アイテムを含む集中管理リポジトリの確立 • 構成管理アイテムの識別と保守 • 構成データのインテグリティのレビュー DS9は、次の項目により測定される。 • 不適切な資産構成に起因するビジネス上のコンプライアンスに関する問題の数 • 構成管理用リポジトリと実際の資産構成の間で確認された相違の数 • リポジトリ内の、購入済みライセンスと所在不明ライセンスの割合 1.2.3 コントロール目標DS9.1『構成リポジトリとベースライン』では、 「構成リポジトリとベースライン構成管理 アイテムに関するあらゆる関連情報を含む集中管理リポジトリと支援ツールを作成する。すべての資産と 資産の変更を監視し記録する。あらゆるシステムとサービスに対する構成管理アイテムについて、変更後に 復元するためのチェックポイントをベースラインとして保持する。」と述べている。 1.2.4 DS9.2『構成管理アイテムの識別と保守』では、 「構成リポジトリに対するすべて変更の管理とログ記録を サポートする構成管理手続を策定する。これらの手続と、変更管理、インシデント管理、および問題管理 の手続を統合する。」と述べている。 284 G37 構成管理プロセス 1.2.5 DS9.3『構成のインテグリティのレビュー』では、 「検証すべき構成データを定期的にレビューして、現在 と過去の構成にインテグリティが保持されていることを確認する。現在インストールされているソフトウェ アについて、ソフトウェア使用ポリシーに照らし合わせて定期的にレビューを行い、個人的に使用している ソフトウェアやライセンスのないソフトウェア、またはライセンス契約の規定数を超えるソフトウェアがない ことを確認する。対処、エラー修正、逸脱を報告する。」と述べている。 1.3 COBITの参照 1.3.1 特定のCOBIT ITプロセスの選択、COBITのコントロール目標の考慮、関連する管理実施策において最も 関連するCOBITマテリアルを選択すること。 1.3.2 選択されるべき、適応されるべきプロセス、コントロールは特定されるスコープや参照される用語に依存し 様々である。要求事項に合致するために、選択されそして適用されやすいCOBITプロセスは次のように識 別される。 1.3.3 主要な参照： • PO9 ITリスクの評価と管理 • AI6 変更管理 • DS9 構成管理 • ME2 内部統制のモニタリングと評価 1.3.4 副次的参照： • PO1 IT戦略計画の策定 • PO3 技術指針の決定 • PO6 マネジメントの意図と指針の周知 • DS4 継続なサービスの保証 1.3.5 構成管理に最も関連する情報要請規準： • 主：有効性 • 副：効率性、可用性、信頼性。 1.3.６ 構成管理に最も関連するITガバナンスの焦点： • 主：価値を納品できること。 • 副：リスク管理 1.4 ガイドラインの目的 1.4.1 構成を管理するとは、精確で完成した構成リポジトリの確立と維持管理を要求するハードウエアのインテ グリティとソフトウエアの構成に合理的な保証を提供することである。 このプロセスには、初期の構成情報、確立したベースライン、妥当性を監査された構成要請情報、要求され 更新され、必要とされるリポジトリ構成の収集を含む。効果的な構成管理は、より多くのシステム可用性を 主導し、生産課題を最小化し、迅速に解決された問題点を迅速に解決する。 1.4.2 現代のビジネスにおいては、コアプロセスの集合が組織される。世界中の各々の組織のほとんどは効果と 効率（すなわち、生産物やサービスに対する高い品質への要求、増加する歳入、コスト削減、新しい生産 物の開発）に対するプレッシャーや良くて、早くて、安く品質の高い企業システムとネットワークの変更管理 プロセスに対するプレッシャーに直面している。しかしながら、デスクトップソフトウエア、ネットワーク、ミ ドルウエア、OSやデータベースのためのシステムソフトウエアの様々なコンポーネントの変更時に発生する 重大リスクは管理されるべきである。 285 G37 構成管理プロセス 1.4.3 このガイドラインは構成管理プロセスのレビュー実施時に情報システム監査人を支援する目的がある。情 報システム監査人にとっての主な目的—外部監査人同様に内部監査人にとっても、この文書は情報システ ムの可用性、データのインテグリティ、および情報の機密性に責任ある他の情報システム専門家にも利用 頂ける。 1.4.4 このガイドラインは、次の観点によって構成管理を説明する。 • プロセスフロー • 役割と責任 • 資産の捕捉とツール • 変更のコントロールとログ情報 • リリース管理を含む要求事項の周知 • 報告されるべき指標 1.5 バックグラウンドと一般的プロセスフロー 1.5.1 構成管理プロセスの目標は次となる。 • システム可用性を維持管理し改善を加えている企業のITシステム、資源、ネットワークへの効果的な変更 管理を維持すること。 • 断定的な効果の精確性を増加させ、変更が引き起こすリスクを管理すること。 • ベースライン構成（例えば、特に大規模、複雑な環境における特定の変更タイプの成功や失敗）の変更 に起因する全ての構成アイテムと過去事実情報の集中的レポジトリーの作成と維持管理を行うこと。 • 長期と短期で計画された変更タイプ数に係る周知をすること。 よって、影響を受ける全ての組織単位との変更に係る状態と存在に関する周知プロセスの確立を行う。 1.5.2 効果的な構成管理は、不充分な準備期間による手戻り、システム利用性とデータ処理インテグリティに とっての互換性の無い変更によるリスク管理を軽減させることができる。 2 監査考慮点 2.1 典型的な構成管理のレビューポイント 2.1.1 組織の規模と複雑度に従い情報システム監査人は構成管理コントロールプロセスの監査証跡を収集すべ きである。情報システム監査人は構成管理に関する上級マネジメントの予測事項を入手すべきである。典 型的に弱い構成管理はシステム可用性とデータの完全性についての重大な脅威として形づくられる。特に 企業システム、資源、ネットワークの構成変更と重要システムの停止、貧弱なデータ完全性、組織情報機 密性欠如、には高い相関関係が存在する。 2.1.2 情報システム監査人は構成管理ポリシーとコミュニケーション要求事項を説明する手続を理解すべきであ る。それらには、企業システムとネットワークにとっての個々人の構成要素となるソフトウエア、ハードウエア 変更の文書化要求も含む。 2.1.3 情報システム監査人はビジネスアプリケーションソフトウエア、ミドルウエア、データベースシステムソフトウ エア、ハードウエア間の企業システムとネットワークの相互関連性と完全性などの全てソフトウエア要素に 関する一般的な理解を得ておくべきである。 例えば、ハードウエアのタイプ、一意に識別するためのモデルナンバー、シリアルナンバー。 2.1.4 情報システム監査人は妥当性検証が完了しているIT資産捕捉システムや比較情報から全てのハードウエア、 ソフトウエア情報（モデルナンバー、シリアルナンバー）を入手すべきである。 仮にこれらが利用できない場合には、完成した棚卸情報を入手してもよい。 286 G37 構成管理プロセス 2.1.5 情報システム監査人は各コンポーネントの関連性と他のコンポーエントとの相互関係性がどのようになっ ているかを含めて理解しておくべきである。 2.1.6 構成管理プロセスのレビューでは、典型的に次の事項が含まれる。 • 全ての構成アイテムの集中リポジトリ確立の検証 • 構成アイテムの識別と構成データの維持管理 • リポジトリーにはコンポーネント、相互関係性、イベントに係る要求された全ての情報が含まれているか どうかの決定 • 構成データはベンダー／サービスプロバイダーカタログに沿っているかどうかの決定 • 相互関連するプロセスの完全性が存在するかどうか、および自動化された方法で構成情報データを利用 し更新する組織あるかどうかの決定 • 構成データのインテグリティに係る合理的保証の提供 • 完成した変更文書を含む公式なシステム変更要求が存在しているかどうかの検証 • 企業システム、資源、ネットワークに変更に関するリスクレベルの識別やカテゴライズが継続的に公式な 方法として採用されているかどうかの決定 • 構成管理委員会あるいはマネジメントの適正なレベルに必要であると看做された変更要求のリスクアセ スメント監査証跡の決定 変更が特定の環境またはネットワーク、および影響する潜在的な利用者数とビジネス情報処理の重要性 に制限させている場合には、リスクアセスメントはその旨を注記しておくべきである。 • リスクアセスメントの結果（すなわち、ファイアーウォール規則設定への変更）をビジネスとITマネジメン トの公式な承認として検証すること • 開発におけるベンダーによる（すなわち、システムエンジニアの実証環境）アップグレード変更導入や開 発がコントロールされていることの決定 • 本番インフラ環境とビジネスソフトウエアで同一環境にある環境において要求された品質が実現できな かったテスト結果では、企業システム、資源、ネットワークの他の要素への影響範囲が及ばないことを注記 • 企業システム、資源、ネットワークへの潜在的な影響を極小化させるコーディネーションに基づく変更を スケジュールすること。ビジネスへの影響を極小化させる同期化された変更を含むソフトウエアプログラ ムの影響拡大をコントロールする一括したマネジメントサブプロセスのリリースにおいてスケジューリン グされる • 本番稼働環境への変更の拡大は、稼動中の本番環境における変更追加テストにおいても業務外時間で もコントロールされる方法が決定されていること。 （すなわち、データベースシステムソフトウエアのアッ プグレードは重要なストアードプロシジャーで実行されること、データ完全性評価のきっかけとして評価 されること） • 全ての資産、構成属性とベースラインのリポジトリを確立する。構成アイテムのベースラインは、変更の 後でも戻せるチェックポイントとして維持されていることを検証する • 各個人コンポーネントの修復、サービス、保証、アップグレード、技術的アセスメントにとって必要となる ハードウア、ソフトウエアデータを提供するベースライン報告を検証する • リポジトリのベースラインに準拠する実際の資産構成のレビューとすること、構成リポジトリの完全性を 確立すること • 規則が実施され、承認されていないソフトウエアを検出、導入の未然防止が強制されているかどうかを 決定すること • 計画されたアップグレード、テクノロジーの更新能力をも提供する修復とアップグレード時期の予測シス テムがあるかどうかを決定すること 287 G37 構成管理プロセス • 変更管理プロセスと構成管理の紐づけができる合理的な保証を提供し、全ての変更観点が構成レ ビュープロセスとして理解されていること 2.2 役割と実行責任 2.2.1 情報システム監査人は構成管理を支援する役割と実行責任の一覧を入手すべきである。これらの役割と 実行責任は、各ITコンポーネントや相関関係にある適用範囲に責任を持つITマネジメント・メンバーのジョ ブ記述に組み込まれているべきである。仮にそれが実現できていない場合には、情報システム監査人は構 成管理（すなわち、全てのプロセス・オーナーの識別）にとっての実行責任を調査すべきである。 2.2.2 情報システム監査人はマネジメントが企業システム、資源、ネットワークに行われる数の計測と元々からの 変更を計測する資源を識別しているかを入手し、検証すべきである。 2.2.3 ここでの説明責任は、構成要素の階層構造支援状況により確立されるべきである。 2.3 資産の追跡とツール 2.3.1 資産について追跡し、個人的資産はモニタリングされ、これらの資産を盗難、悪用、誤用から保護すべきで ある。 2.3.2 ソフトウエアは、ラベルづけられ、棚卸され、適正にライセンス契約されているべきである。ライブラリ管理 ソフトウエアはプログラム変更の監査証跡を生産し、プログラム版数、作成された日付け情報、以前の版 数のコピーを維持管理するために利用される。 2.3.3 情報システム監査人はサーバとデスクトップコンピュータを含む全てのハードウエア機器をスキャンする自 動化ツールの利用により出来る限り全ての承認されたソフトウエアの一覧表を入手すべきである。 このソフトウエアは例えば次のような重要な詳細情報を提供する。 • ハードウエアタイプとモデルナンバー • インターフェースプログラムと相互運用性を検証するためのコントロールを含むソフトウエア要素 • ベンダーソフトウエア –– のバージョン –– の現状のサポート要求の文書 –– からの他のソフトウエアとのインターフェースに影響を与え、提供されたベースラインからのマスタマ イズ文書 2.3.4 情報システム監査人は全ての購買されたソフトウエアがIT資産追跡システムに記録されていることを検証す るために使われるソフトウエア購入コントロールに係る一般的な理解があることを確保しておくべきである。 2.4 コントロールと変更のロギング 2.4.1 手続きは、承認され識別可能な構成アイテムのみが購入され次第、棚卸記録として検証できる様に実施さ れているべきである。 2.4.2 手続きは、構成変更の形跡（例えば、新しいアイテム、開発からプロトタイプへのステータス変更）を保持 する様に実施されているべきである。ロギングとコントロールは、変更記録のレビューを含む構成記録シス テムにおける完全な形の一部となっているべきである。 2.5 リリースマネジメントを含むコミュニケーション要求事項 2.5.1 選ばれた上級マネジメントと上級ITマネジメントから、リスクの高い構成変更（すなわち、ビジネスアプリ ケーション）を評価するためのステアリングコミッティが形成されるべきである。実装変更に係る決定事項 を含む議事録が文書化されるべきである。 288 G37 構成管理プロセス 2.5.2 情報システム監査人は「リリースカレンダー」を含む変更のスケジュールについての監査証跡を入手すべき である。また、その「リリースカンレンダー」は本番処理環境への様々な変更が拡大影響するその日付けと 時間について注記されているべきである。 典型的には情報システム監査人は変更の拡大分離を観測すべきであり、それによりコンピュータ・オペレー ションはより容易にシステム問題を識別することができる。 2.5.3 重要な構成管理のビジネスオーナーへの周知監査証跡は、普段と異なるシステムイベント構成変更を検出 するための記録となっているべきである。 2.6 報告されるべき指標 2.6.1 ダッシュボードを含む全ての計測は、企業システム、資源、ネットワークに対して行われる元の姿からの変 更数の測定結果となるべきである。典型的な計測事例は下記。 • 相違点の識別とそれらを一致させるための平均時間差 • 不完全あるいは失われた構成情報に関連する不一致の数 • パフォーマンス、セキュリティ、可用性のサービスレベルに合致している構成アイテムの割合 • 構成リポジトリと実際の資産構成間での相違点の数 • 購入されたライセンス数とリポジトリ内に計上されていない数の割合 • 承認されたライセンス対使用中購入ライセンスの割合 • 資産の不適正構成に起因するビジネスコンプライアンス問題の割合 2.6.2 応答時間、システム稼動時間（可用性）、データインテグリティの品質などの様なサービスレベル実績統 計情報は、公式に文書化され、ITマネジメントにおいて回覧される。従業員あるいは契約者の業務実績 （IT部門がアウトソースされている場合）は、この指標により計測されるべきである。 2.6.3 次の事項により成功や分裂的な変更による失敗に影響を及ぼす様な変更になる場合には、 マネジメントは 変更のリードタイムを計測し、変更を確実にするべきである。 • リードタイムは重要で、妨げになる変更量を削減し、神経を使うべきタイプを識別する • リスクのレベルに応じた変更の識別やカテゴライズのよりよい方法を決定する • 各々は技術的でマネジメントの説明責任が記録されていることを検証する • プロセス検証記録には技術的メリットとビジネスにとっての継続的方法が準備できている事を確立する。 その方法はビジネスニーズに基づく柔軟性が具備されていること 3 適用開始日 3.1 本ガイドラインは、2007年11月1日以降のすべての情報システム監査に適用される。 289 G38 アクセスコントロール 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 291 2 一般的定義‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 293 3 監査プロセス‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 301 4 作業実績‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 301 5 報告‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 302 6 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 302 G38 アクセスコントロール 1 背景 1.1 基準との関連 1.1.1 基準S1『監査ポリシー』では、 「情報システム監査機能ないし情報システム監査業務の目的、責任、権限、 説明責任は、監査ポリシーまたは監査契約書により適切に文書化されている必要がある。」と述べている。 1.1.2 基準S3『専門家としての倫理と基準』では、 「情報システム監査人は、ISACAの職業倫理規定、を遵守す べきである。」と述べている。 1.2 ガイドラインとの関連 1.2.1 G13『監査計画におけるリスク評価の使用』では、 「情報システム監査人は、全体の監査計画と特定の監 査計画を開発する際に選定されたリスク・アセスメントテクニックを利用すべきである。他の監査テクニッ クと連携して、リスクアセスメントは次の様な意思決定が考慮されるべきである。」と述べている。例えば、 次の事を。 • 監査手続の性質、範囲、時期 • 監査されるべき領域やビジネス機能 • 監査人に割り当てられる時間や資源の量」と述べている 1.3 COBITとの関連 1.3.1 ME2『内部コントロールの監視と評価』では、 「ITに関連したアクションの内部コントロールプロセスを監 視する立法や規定を遵守し、改善活動を識別するIT目的達成、ビジネス要求を満足させている必要があ る。」と述べている。 • ITプロセスフレームワークに組み込まれた内部コントロールシステムを策定すること • ITを俯瞰した内部コントロールの効果を監視し、報告すること • マネジメントの活動面でのコントロールされることによる期待値を報告すること ME2は、次により計測される。 • 内部コントロールの大きな破損点の数 • コントロール改善活動の数 • コントロール セルフ アセスメントがカバーされている数 1.3.2 ME3『外部要件に対するコンプライアンスの保証』では、 「法律、規制、および契約の遵守に対するコン プライアンスの保証を、ビジネス要件とし、重点をおくべきコントロールは、すべての関連法律、規制、契約、 および対応するITのコンプライアンスレベルを特定し、ITプロセスを最適化して、コンプライアンス違反の リスクを低減すると記載されている。」と述べている。 実現するための手段は、次の3項目である。 • IT関連の法律、規制、および契約要件の特定 • コンプライアンス要件の影響評価 • 以上の要件へのコンプライアンスに関するモニタリングと報告 その成果の測定指標は、次の3項目である。 • 和解金や罰金を含む、ITのコンプライアンス違反の費用 • 組織外におけるコンプライアンスに関する課題の特定から解決までに要する平均時間 • コンプライアンスに関するレビューの頻度 291 G38 アクセスコントロール 1.3.3 ME4『ITガバナンス』では、 「ITガバナンスと企業のガバナンス目標との統合、および法律、規制、契約へ の遵守をビジネス要件とし、重点をおくべきコントロールは、ITの戦略、パフォーマンス、およびリスクに関 する取締役会への報告書を作成し、取締役会の指示に従ってガバナンス要件に対応することである。」と 述べている。 実現するための手段は、次の2項目である。 • コーポレートガバナンスに統合されたITガバナンスフレームワークの確立 • ITガバナンスの状況に関する独立した保証の獲得 • その成果の測定指標は、次の3項目である • 利害関係者に対する、取締役会のITに関する報告の頻度(成熟度に関する報告を含む) • IT部門から取締役会への報告の頻度(成熟度に関する報告を含む) • ITのコンプライアンスレビューの頻度 1.4 COBITの参照 1.4.1 特定の監査の範囲に適切なCOBITでの最も関連している材料の選択は特定のCOBIT ITの過程の選択と COBITのコントロール目標の考慮に基づいている。 情報システム監査人の責任、権限および説明責任への要求に合致するために、COBITプロセスとして最も 該当し、選択適用されるものは下記の主項目と副次項目となる。選択適用されるプロセスとコントロール 目標は、特定の範囲と委任条件に従って異なっていても差し支えない。 1.4.2 このガイダンスにより対処される領域をレビューする際に主項目として考慮されるべきCOBITの特別な目 標とプロセスは、以下となる。 • PO1 ISリスク評価 • PO2 情報アーキテクチャーの策定 • PO9 ITリスクの評価と管理 • DS5 システム・セキュリティの確実化 • DS7 利用者の教育と訓練 • DS9 構成管理 1.4.3 このガイダンスにより対処される領域をレビューする際に副次的に考慮されるべきCOBITの特別な目標と プロセスは、以下となる。 • PO6 経営管理の目標と方向性の周知 • PO7 IT人的資源の管理 • AI1 自動化されたソリューションの特定 • AI2 アプリケーション・ソフトウエアの獲得と維持 • AI3 技術的インフラの獲得と維持 • AI6 変更管理 • DS1 サービスレベルの策定と管理 • DS2 サードパーティ・サービスの管理 • DS10 問題管理 • DS12 物理的環境の管理 • ME1 ITパフォーマンスの監視と評価 • ME3 規則順守の保証 292 G38 アクセスコントロール 1.4.4 責任、権限および説明責任に最も関連する情報要請規準： • 主：有効性、効率性、機密性 • 副：可用性、インテグリティ、信頼性 1.5 ガイドラインの目的 1.5.1 実際の相互に関連しあう世界では、組織が、単に投資を保護するのではなく、リソースの誤用で発生する 危険から情報資産を故意にまたは故意でなくても保護するため、権限のない使用からそれらの資産を保 護するべきである。実際の技術実装はさまざまの保護、およびそれらの複合体(例えば、プラットホーム、 アプリケーション、ユーティリティ、オペレーティングシステム、データベース、イーメイル、ユーティリティ、 セキュリティ、および監査ツール、インターネット、ファックス)のすべてから、保護されなければならない。 ビル、設備、テレコミュニケーション、写真複写機、カメラ、ファイルキャビネット、一般的な印刷情報、顧客 ドキュメンテーションなどの物理的資産も同様に保護されなければならない。 この多様性のため、アクセスを制御するために1つの標準プロセスを持っているのは、重要である。この基 準は組織の特別のニーズに対処するベースラインとして運用される。 1.5.2 このガイドラインは、情報システム監査に適用する監査基準のS1とS3のガイダンスを提供する。情報シス テム監査人が上の基準の実装を達成する方法を決定する際にこのガイドラインを考えるべきであるという ことであり、アプリケーションにおけるプロの判断を使用して、あらゆる逸脱を正当化するように準備され る。 1.6 適用指針 1.6.1 このガイドラインを適用する時、情報システム監査人は他の関連するISACA基準とガイドラインを考慮す べきである。 1.7 一般的アクセスのカテゴリ 1.7.1 最小限のアクセス/ 必要となる特定の資源への利用者のアクセス 1.7.2 知識ベース/ 個人的興味ではなく、組織にとっての業務実績に必要となる資源への利用者アクセス 1.7.3 所有者/ 資産への個人の責任における利用者アクセス 2 一般的定義 2.1 セキュリティポリシー 2.1.1 セキュリティポリシーは、 マネジメントや組織の責任を記述し、ビジネス目的を遵守するためのセキュリティ 戦略を記述するハイレベルの文書となる。基準と手続書は完成された実装にて記述されるべきである。基 準は何がポリシーに遵守しているかを策定すべきであり、全ての読者を意識したものであるべきである。手 続書はどのようにされるべきかについて記述されるべきであり、ポリシーを実装しなければならない人々 （例えば、利用者、技術、ベンダー）を意識すべきである。これらは、別々な文書組織あるいはアクセスコン トロールポリシーとして連結されることができる。 2.1.2 セキュリティポリシーを書くことを考えるために、多くの情報資源がある。各組織は、ビジネス、保護の必 要性、および文化に関連して情報を評価して、目的に最も合致する様に採用するべきである。周知され全 ての従業員に署名される前に、ポリシーはビジネスとセキュリティ専門家によって書かれていて、ハイレベ ルの経営者またはディレクターによって承認されるべきである。 293 G38 アクセスコントロール 2.2 アクセスルールを策定するに当たっての要請規準 2.2.1 一般に、要請規準は知っておくべきの原則に基づくべきである。各組織は従業員の各グループ、業者、顧客、 監視委員、監査人にとって適切なアクセスのレベルを策定しなければならない(例えば、役割ベースのアク セス)。情報資産の完全な目録は、情報の重要性、脆弱性、および情報(知的財産)を管理するそれらの情 報が処理される設備と技能または特別な専門的技術を含む環境を含めたITをも考慮して作成されるべきで ある。 保護すべき物理的資産または資源には次のものが含まれる。 • 電源、セキュリティ、および他のインフラストラクチャ項目(例えば、無停電装置[UPS]、ジェネレータ、カ メラ)を含む建物 • データセンタ • 電気通信室 (スイッチ、ハブ、ルータ、自動式構内交換機[PABX]、ケーブル) • ライブラリ (テープ、カートリッジ、ＺＩＰ) • 金庫室/防火金庫 • セーフティーボックス、鍵箱 • ファックス • コピー機 • テレックス • 顧客ドキュメンテーション • 補足資料(規則化されたもの) 2.2.2 組織は、重要責務の分離を確かめるためのアクセス役割のマトリクスを作成して、定期的に見直すことを 考えるべきである。 2.2.3 論理的な資産または保護する資源には次のものを含む。 • サーバ(すなわち、ウェブサーバー、アプリケーションサーバー)とそれらのオペレーティングシステム • データベースシステムまたはファイルシステム • アプリケーションシステム • ユーティリティとツール • 磁気カード、鍵、証書、スマートカード • サーバ、ワークステーション、PABX • 一般的なデータ • メール(法人のアカウントのもの) • ファイアウォール/侵入検知システム(IDS) • 報告書 • 監査ログ • ネットワーク(セキュリティペリメタネットワーク) 2.3 所有権と責任 2.3.1 それぞれの情報(そして、IT関連の物理的情報)資産のための所有者は、正式に割り当てられた責任で策定 されるべきである。責任は、アクセス管理のための主義と規則が組織によって実装されフォローされること を確実にする情報所有者の義務を包含するべきである。 294 G38 アクセスコントロール 2.4 資産分類 2.4.1 資産分類は管理された情報タイプに基づくべきである、(例えば、制限されている、機密である、内部である、 公である)。 2.5 管理 2.5.1 アクセスコントロールポリシーは、ポジション、タスク、部門内異動、情報セキュリティ管理(ISA)などの従 業員状態の変化に応じて明確に責任、役割、および手続を策定されるべきである。それは、使用者の地位 の変化を管理して、資格があること/特権を策定する、与えるか、排除するか、または変えるのに責任がある 人/部としての情報所有者、ユーザ、スーパーユーザ、後見監督人またはいずれへの変化を伝えるための手 続として確立するために、かなり重要となる。セキュリティ管理者には、セキュリティ管理に対する総合的な 責任があるべきである。用語「資格があること」は、承諾されたユーザのアクセスで交換可能である。 2.6 ユーザコントロール 2.6.1 あるセットのコントロールは、利用者活動のコントロールと監視のために策定されるべきである。例えば、 一連の連続したログイン失敗の後に利用者をブロックすること、および策定された不活性の期間の後に不 活性利用者をブッロクしたり検出すること。成功裡にログインされた利用者は、失敗した試行、成功裡のロ グイン日付け・時刻の数を提供されるべきである。 2.7 資格があることのレビュー 2.7.1 所有者/後見監督人がユーザ資格があることと変更の影響の妥当性を確かめるために、少なくとも半年ご とに資格があることのレビューをするべきである。 「手続」の適切さは、資格があるとレビューされた実績 を条件とし、更に頻繁に発生する環境変化（アプリケーション、外部のネットワークアクセス）がある場合 では、少なくとも毎年定期的に評価されるべきである。 2.8 許可された利用と罰則 2.8.1 ポリシーと支援文書（すなわち、基準とガイドライン）は、一方で他のリスク属性に対処している間であって も、組織の資源は個人の便益のためでなくビジネス目的のみに利用することができる。ビジネス資源の誤 用または不適正利用の場合には、罰則/制裁があるべきである。 2.8.2 ポリシーは規定の枠組み(法人の、そして、ローカル)、の包含、プライバシー法、データ保護または銀行に 係る秘密を包含するべきである。また、それは、チェーンレターへの参加、CD/ディスケットまたは組織に よって所有されている情報を使用するときの個人的なソフトウェアを使用して、個人的な利益のためにイン ターネットからソフトウェアをダウンロードするなどの状況が禁止されているかを述べるべきである 2.9 非スタッフ人員 2.9.1 ポリシーでは、機能やトランザクション（例えば、セキュリティトランザクション、承認のトランザクション） は一時的なコンサルタントや第３者個人からアクセスできないべきであると述べている。これらの機能やト ランザクションへのアクセスはネットワークコントロールにより実現することができ、法人のイーメイルダイ ヤルインなどを経由してアクセスされないネットワークコントロールで実現されることができる。 2.10 説明責任とパスワード共有 2.10.1 ポリシーでは、個々の従業員以外の他人がパスワードを使用する場合においても、個々の従業員はかれら のパスワードで実施されるアクションに責任を持つべきであると明確に述べている。パスワードは失効する 日付けを持つべきであり、システムはそれらを自動的に変更させる様に促すべきである。 全ての以前の要素に基づき、各組織は従業員/顧客の現在のビジネス要求事項と法的環境に従ったアクセ ス要求事項を策定する。 295 G38 アクセスコントロール 2.11 アクセスのタイプ 2.11.1 アクセスの起源によって、アクセスはローカルあるいはリモートとして分類されることができる。ローカル・ アクセスは資源が物理的にローカルである組織内部に起源を持つ。リモートアクセスは、自宅のような 他のロケーションからのアクセスに起源を持ち、緊急変更コントロール手続や管理者によって運用スケ ジュール化された使用が典型的である。この最後のケースでは、構成とアンチウイルス・ソフトウエア、セ キュアな接続（仮想私設網VPN、暗号、セキュアソケットレイヤーSSL）と自宅デスクトップからのリモート 接続に対する日々のコントロールなどにより特別なセキュリティ計測が考慮されるべきである。 2.11.2 無線通信またはモバイル機器使用は、最小限かつ厳格にコントロールされるべきである（重要なプロセス/ 情報には使用されない）。アクセスを実行するために必要な複雑性とスキルをアクセスが技術的であろうと 非技術的であろうと、そして構造的であろうと非構造的であろうとの分類する際に考慮すること。これはリ スクの評価・分析と発生事象の発生確率の決定にとって非常に重要となる。 2.12 必須事項 2.12.1 情報資産へのアクセスは識別、認証、認可または非拒否に対して測定されるべきである。 2.12.2 利用者は特に利用者ＩＤ（8文字以上の文字列）、ＩＤカードまたは個人の声、指紋、アイリス/網膜の様な バイオメトリックスの物理的ＩＤリソースにより特定されるべきである。 2.12.3 利用者は、その本人が誰であるかを表現するひとつの秘密事項になる資源を提供することにより認証され るべきである。ユーザは、示される1個の秘密事項をリソースに提供することによって、認証されるべきであ る。分類やリスクの評価に従って、認証は静的パスワード、動的パスワード、あるいはワンタイムパスワード （トークン）、バイオメトリックス、個人認証ナンバー(PIN)/貿易相手国識別番号(TPIN)により識別され ることができる。認証は、 「その人が知っている事」、 「その人が持っているもの」、あるいは「その人が知っ ている事」によって実行される。セキュリティは、要素の組み合わせでより強固になる。例えば、ＡＴＭでは、 その人が知っている事としてのＰＩＮとその人が持っているものとしてのカードという２つの要素で認証さ れる。事例としてアクセス・コントロール・ポリシーは以下のテーブルにある様なテーブルを含むべきである。 (2.12.4 の各事項を指す) 情報分類、リスク評価とアプリケーション 用法、アクセスタイプ テクニック PIN/TPIN 静的 パスワード ワンタイム パスワード バイオ メトリックス 充分である 望ましい 望ましい 望ましい 機密情報、中リスク、トランザクション アプリケーションと内部アクセス 不充分である 不充分である 望ましい 望ましい 限定された情報、高いリスク、トランザクショ ン・アプリケーションとリモートアクセス(web) 不充分である 不充分である 充分である 望ましい 公的情報、低いリスク、非トランザクション アプリケーションと内部アクセス 296 G38 アクセスコントロール 2.12.4 識別/認証が承認されているなら、システムは要求により特定の資源へのアクセスを許可する。このことは アクセスする資源のタイプに従って異なるテクニックにより実行される。例えば、以下の様に。 • ビル、部屋、金庫、データセンタに対しては、ユーザアクセスカード、PIN、および生体認証 • 顧客ドキュメント、キャビネット、およびファックスに対しては、ユーザアクセスキー、カード、および後見 監督人メモ • ファイアウォールとプロキシは他のリソースへのアクセスを許す設備資産である、そして、それらが非常 に重要であるので、特別な保護が与えられるべきである。彼らは、管理者のみの役割、構成への変更、ア ラームやログの様な物理的かつ論理的な保護がなされるべきである。全てのケースにおいて、各企業は どのようなサービス（例えば、ウェブサービス、イーメイル、ＦＴＰ）が利用され、基準/ベスト・プラクティ スの推奨（例えば、ポート８０の不使用）の必要性を分析しなければならない。この目的を達成するため に、各社が脆弱性と脅威が1つ以上のセキュリティ報告の公示（例えば、ＣＥＲT,SANS,NIST）を含ん でいる管理手続であることが重要となる • IDSs/攻勢防御システム(ADSs)/強制介入防止システム(IPSs)は、疑わしい通信を検出・分析する設備 とソフトウェアである。それらは、即時にレビューされる必要のあるアラームやログを生成する様に構成 されなければならない。受け取ったログやアラームのレビューのためのプロセスを実装すること、ログや アラームの分析が脅威リスクに従って構成変更されることは重要である • アプリケーション、DBMSレベルで策定されたオペレーティングシステムとデータベース管理システム (DBMS)ユーザ・プロファイル。各ユーザは利用者特権により選定され、そしてこれがアクセスコント ロールリスト（ＡＣL）に設定される • エンドユーザ コンピューティングとしてのエクセルスプレッドシート、アクセステーブル、そしてＦｏｘや Ｄｂａｓｅなどが仮に存在する場合は、シートパスワード、利用者特権、セルパスワードなどによりプロテ クトされるべきである • これらのツールを重要なプロセスに使用することは推奨されない、なぜならばそれらが提供するセキュリ ティコントロール（すなわち、パスワードプロテクション）は、ＤＢＭＳアプリケーションに組み込まれる セキュリティコントロール程に強固なものではないこともあるからである 2.12.5 取引をした人物が拒否できないということを確かめる目的で拒否しないことを意図的に行う。これは、デジ タル署名とログにより達成できる。 2.13 リスクアセスメント 2.13.1 リスクアセスメントは脅威シナリオへの脅威と変化の基本的な性質により実行されるべきである。 2.13.2 貧弱なアクセスコントロール実施は秘密情報(秘密性)、権限の無いデータへの変更(完全性)、あるいはビ ジネス継続性の損失（可用性）を導くことになる可能性がある。適切なアクセスコントロールが設定されて いないという重要性は定性的観点ばかりでなく定量的観点からも組織の資産価値に基づき考慮されるべ きである。たとえば、風評被害、顧客の認識違い、義務遵守不能、妥結事項（契約、ＳＬＡ）、規則への影 響（科料）、財政への影響、競合上の損害と歳入/収入損害。このリスクを極小化するために、予防的コン トロールはビジネス（潜在リスク）に受容できるレベルまでリスクを減少させる様組み込まれるべきである （ポリシーに従って）。検出コントロールもプロセスを安全にする様要求される。 2.13.3 特定のシステムに必要である信用の度合いは情報資産の価値とそれらの資産への知覚リスクで決定する。 2.13.4 コンピュータシステム（ネットワーク内の）を信頼に値する方法を開発することは、共有する情報資源を信 頼できるものにすることと同等である。 297 G38 アクセスコントロール 2.14 リスクモニターと測定基準 2.14.1 アクセスリスクインディケータはコントロールリスク自己査定などの方法論によって策定されるべきである。 いくつかの実施例： • 外部からの侵入の試みの数(失敗または成功の) • 内部の権限のない試みの数 • 権限のないアクセスで引き起こされたセキュリティインシデントの数 • コンプライアンス内ではない資格があることレビューの数 • 不十分なアクセス要求可決の数 2.15 アクセスへの特定の脅威 2.15.1 製品/サービス/アプリケーションに従って、組織は、ソーシャルエンジニアリング、フィッシング詐欺、ＩＤ 窃盗、サービス不能攻撃、ウェブスプーフィング、クロスサイトスクリプティングへの脅威を分析すべきである。 潜在的な脅威露出に基づいて、彼らはウェブアプリケーションとインフラストラクチャへの特別な測定を考 慮すべきである（例えば、ウェブ標準ポリシー、倫理的なハッキング)。 2.15.2 組織は承認されない侵入を含むアクセス上の突破口に適切に対応するように準備されるべきである 2.16 予防制御 2.16.1 予防制御には以下を含む。 • システムアクセスは強いパスワード(パスワードの長さと複雑さ、変更頻度、パスワード共有などのための 規則)の使用で認証されるべきである • ビジネス情報資源アクセスが承諾される前に、事業主が正式な承認をすることが要求されるべきである • アクセスコントロールポリシーは、周知され、規則的要求事項（全社とローカルでのレベルにおいての） とポリシーに従ったアクセスコントロールテクニックの実装を考慮する全ての従業員により署名されるべ きである • 正しい資源（人的資源）の利用に対するスタッフ協定は調印されるべきである • 訓練や、スタッフを正しいアクセスを意識するように喚起する、およびノン・コンプライアンスへの測定プ ログラムは設置されるべきである • 手続は、プロセスを策定すること、承認すること、廃止すること、取り除くこと、変更すること、周知する こと、ログをとること、およびオーナーとスーパーバイザにより承認されたアクセスを監査することにおい て存在すべきである • 管理機能に係る日々のコントロールを含む利用者管理手続は設置されるべきである • ビジネスニーズが全くない業者によって提供された利用者ＩＤの全ては、排除されるべきである • それらのビジネスニーズのある業者によって提供された利用者ＩＤの初期のデフォルトパスワードは変更 する事を要求されるべきである • 監査ツール、ファイアウォールとIDなどのアクセスコントロールツールは存在させるべきである • 電子メールやインターネットの不適正利用に対する従業員への罰則事項を含む資源利用ポリシーは設 置されるべきである • 第三者アクセス要件(SLAまたは契約) • リスクのレベルによりリスクアセスメントする際の手続的な留意点 • 臨時従業員(保護機能、取引認可)のためのアクセスの制限 • 可能な場所でのデフォルトアクセス/ユーザの除去 • 全ての製品サービスアカウントにおけるユーザによるログオンの制限 298 G38 アクセスコントロール • アクセスコントロールではなく、未承認のアクセスからの影響を削減する暗号化 • ファイルキャビネットや、ファックスや、金庫や、ドキュメントなどの物理的資源へのアクセスを策定する 手続書とそれらの保持と保護に対する要求事項 • 互いのコントロールのレベルに達する2人以上の間の重要なデータへの職務の分離と適用 • PIN/TPIN/安全なインターネットパスワード(HPIN)、トークン、生体認証、利用者プロフィール、特権、 セッションタイムアウト、ケーブル施錠、抗ウイルス、反スパイウェア 2.17 検出コントロール 2.17.1 検出コントロールには以下を含む。 • 非コンプライアンス状況の拡大、ロギングとベンダー、顧客、規則監視員、監査人を含むレビュープロセ スの承認行為 • 特権があるまたはスーパーユーザ・ログインアカウントの活動は、上級コンピュータセキュリティ経営者 側によって密接に監視され、レビューされるべきである • 役割と責任および拡大手続きを含むセキュリティインシデント手続は、不充分なアクセス/疑わしい動き とハッカーの様な資源の悪用を管理するために存在するべきである • 監査/高い次元の特権ユーザ、機能部門のユーザ、デフォルトユーザ、特別なグループへの承認の品質保 証レビュー／ファイアウォール/ＩＤS構成、アラートとログは設定されるべきである • 自己査定方法論は、補完的内部監査レビューとして展開されるべきである。例えば、1セットのコント ロールは、リスクに基づく頻度として各領域で実行され、そしてビジネスプロセスとして統合される • 例年のペネトレーション・テスト評価は適切なネットワーク、人間、資源とビジネスプロセスを含む様に するべきである • 承認されない動きを含むログは、ログ出力されレビューされるべきである 2.18 補完コントロール 2.18.1 補完コントロールは検出コントロールや予防コントロールが不充分な場合に考慮されるべきである。 2.18.2 これらのインディケータのすべてに関しては、セキュリティマネージャがこれらの問題の原因を分析して、問 題を緩和するか、または解決する経営行動計画を策定することを(例えば、トレーニングを強化すること、セ キュリティツールを買うこと)可能にする価値あるきっかけを策定すべきである。 299 G38 アクセスコントロール 2.19 コントロールアクセス手続 2.19.1 アクセスコントロールツールのローカルの手続、プラットホーム、ユーティリティ、および設計によって、こ のタスクは、組織によっては異なってもよいが、すべてのケースに以下を含むべきである。 • 適切な原理と所有者の承認によるすべてのアクション(例えば、追加、削除、リセットとプロフィールの変 更)を正式に記録したアクセス要求が要求されるべきである • コントロールプロセスが手動であるときに(フォームまたはメールによる)、要求を受け取るユーザ管理 者は、要求の可決が正しいかをチェックするべきである。いくつかの場合、このプロセスはそれぞれのリ ソース/領域の所有者/監督人を含んでいて、承認を得るために1回の自動作業フローを実施するアプリ ケーションで自動化されている • それぞれのユーザ管理操作の処理のための時間枠は、ビジネス(例えば、SLA、作業記述)によって策定 されて、同意されるべきである。例えば重要なアプリケーションのためのユーザ・リセットは、ＳＬＡある いは適正に策定された期間に従って対応されなければならない • プロセスは明確に追加またはリセットのためにパスワードをユーザに送る方法を策定するべきである。 いくつかの場合、これはアプリケーションで自動化される、そして、管理者は利用者パスワードを決して知 らない。また、パスワードが生成されるときだけ(すなわち、ユーザ取引の追加またはリセットの間)、それ らがアカウント所有者に知られて、暗号化され格納されるのも、望ましい。それらが制限された情報であ ると考えられるべきであるから • PIN/TPINsを従業員/顧客に届けるプロセスは項目(カード、トークン)と異なった流通チャネルを使用す るべきである、そして、それらを活性化することができる所有者に届くまで不活性であるべきである • コントロールは、所有者に届かないならどんなパスワード/PIN/TPINもある程度の期間の後に破壊され ることを検証するために存在すべきである 2.20 情報セキュリティ統制におけるコントロール 2.20.1 その活動は下記。 • すべてのISA（Information Security Administration）活動が監査ログに記録されるべきである • すべてのユーザコントロール機能がいかなる他のアクティビティ(すなわち、システムコントロール、企業 取引、および開発者活動)からも隔離されるべきである。さもなければ、不適当な職務の分離は利害対 立を引き起こす • 1つの独立しているパーティーが、24時間以内にすべてのISA活動をコントロールするべきである、また は必要なアクションだけが処理されることを検証するためのメーカーあるいはチェッカーの二重のコント ロールを組み込むべきである • すべての特権ユーザ(管理者、DBAs)は、監視され、正当化、ドキュメンテーション、および承認のための、 よりきついコントロールのプロセスを持つべきである 2.21 ユーザ活動のコントロール 2.21.1 ユーザ活動のコントロールは以下を含む。 • 繰り返し失敗したログイン試みは、特定され、調査されるべきである • そして、ブロックされたか中断されたユーザＩＤ（３つ以上連続して失敗した試み）は、そのユーザは正し くそのユーザＩＤであるか、承認されなかったもではないかを検証する調査を実施すべきである • 不活性ユーザをモニターするべきである、そして、例えば、期間、60日の不活性ユーザのブロッキング、お よび90日の不活性なユーザの削除によって、是正措置を取るべきである • デフォルトユーザ（例えば、ゲスト、管理者、所有者、ルートユーザ）や契約者によって実行されているア クティビティは日々監視されるべきである。このタスクにセキュリティツールを使用することを推奨する • データへのアクセスが日、週、月または年間の限られた期間となっているあるべきである 300 G38 アクセスコントロール 2.22 アクセス監視での留意点 2.22.1 アクセス監視の留意点は下記を含む。 • 重要なアカウント、ログファイル、データファイル、およびデータベースへのアクセスは、監視されるべき である • 定期的に、ログは、特権ユーザと失敗したアクセス試みの活動を監視するためにレビューされるべきである • 電子メール使用は法的で、プライバシーの、そして、倫理的な問題に発展することになる乱用を監視すべ きである • 特権がある(システム)ログインアカウントの用法は、監視され、正当化されるべきである。可能であるとき はいつも、そのようなユーザはそれら自身のログオンIDを持って、一般的なＩＤとして共有してもかまわな いＩＤよりはむしろ特権がある権限（シスアド・アカウント）を割り当てられるべきである • ネットワークやサーバ侵入検出などの業者によって供給されたセキュリティ製品では、関連ログが毎日レ ビューされるべきであり、アラートは適正に管理されるべきである 3 監査プロセス 3.1 計画 3.1.1 監査プログラムは、範囲、目的、および監査時期を含んで、組織のリスクアセスメントとリスク管理戦略に 基づいて開発されるべきである。報告内容の調整は明確に監査プログラムに記録されるべきである。組織 とその利害関係者の性質とサイズに対して考慮がなされるべきである。ＩＳ監査人は、組織の役割と、ビジ ネス目的、技術的インフラストラクチャのタイプ、ビジネスにとっての重要なデータに対する理解を得ておき べきである。 3.1.2 情報の管理者、所有者および監督者を含むキーとなるスタッフ固有の役割と責任についての組織的な構 造に対する理解が求められる。 3.1.3 監査計画フェーズの主目的は、アクセスが不当に策定されるか、承認されるか、割り当てられるか、使用さ れるか、または制御されるときに、組織が直面する脅威とリスクを理解することである。 3.1.4 正式なリスク査定方法は、高いリスク領域を強調しながらレビュー対象範囲を策定するために適用される べきである。 3.1.5 適切なサンプリング技法は、適用できるならばテスト結果を定量化する監査計画と考えられるべきである。 3.1.6 以前のすべての監査レポートはレビューされるべきであり、その解決レベルは経営行動計画に従った各問 題として評価されるべきである。 4 作業実績 4.1 監査タスク 4.1.1 情報システム監査人はレビューする際に次の事項を考慮すべきである。 • 前述の予防と検出の可能な場所でのコントロールとの準拠性 • セキュリティ責任を有するすべての人員の組織図と職務記述書 • 現在のビジネス職務と同等として作成される情報資源へのアクセスと関連付けられた役割 • 情報技術グループと関連付けられた従業員アカウントに与えられたアクセス権が、継続したビジネスニー ズの存在として定期的に妥当性検証されていること • 従業員に割り当てられたログオンアカウントが役割終了時に速やかに取り除かられること 301 G38 アクセスコントロール • 完全性、精度、アップデート、および準拠証拠について確かめる、政策、評価基準、およびプロセスが実 装されていること • 承認の手続、責任策定、およびセキュリティ関連機能のための承諾(例えば、情報所有者、ビジネスプロ セス所有者、アプリケーション所有者) • 分類とリスク評価を有する資産目録 • 特に高い特権ユーザのためのISAログと毎日のコントロール • 検出、コミュニケーション、セキュリティインシデントのための増大と解決手続、およびレビューを条件と した期間におけるそれらの測定基準。従業員はセキュリティインシデント手続への認識についてランダ ムにインタビュー評価されるべきである • 認識、トレーニングプログラム、および関連する測定基準 • ISA操作手続 • ある期間のセキュリティインシデントの報告、増大、および解決の証拠(もし存在するならば)、教訓そし て組み込まれた活動計画 • コントロール活動の正当性と是認、および機能ユーザの原理 • リスクと脆弱性評価からの報告リスク • 仕事が始まる時の人的資源手続の一部として調印された従業員協定と条項 • 一時的人事として結ばれた契約 • プラットホーム構成報告書(例えば、サーバ、デスクトップ、ホスト) • レビュー期間における承認されたレビュープロセスの証拠 • ファイアウォール/IDS/IPSの構成レポート • ファイアウォール/IDS/IPSのログが示す地点 • 特定の基準/ガイドライン(すなわち、ファイアウォール、ウェブアプリケーション) • 共有された/第三者サービスプロバイダーとのサービスレベル契約/協定 5 報告 5.1 レポート作成とフォローアップ 5.1.1 草稿監査レポートは、関係要員と作られて、議論されるべきである。明らかな証拠に裏付けされた問題を含 むべきである。 5.1.2 レポートは、問題を解決するか、または改善だろうという推薦と追跡しているオプションをISACAガイドラ インに続けて完成させ、そしてマネジメントへ提供すべきである。 5.1.3 上級経営層によって与えられた、フォローアップ活動、行動計画、責任、目標日付、リソース、およびプライ オリティは、同意されるべきである。 6 適用開始日 6.1 本ガイドラインは、2008年2月1日以降に開始する全ての情報システム監査に適用される。 302 G39 ＩＴ組織 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 304 2 IT 組織‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 305 3 監査プロセス‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 310 4 監査作業の成果‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 312 5 報告‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 314 6 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 314 G39 ＩＴ組織 1 背景 1.1 基準との関連 1.1.1 基準S10『ITガバナンス』では、 「情報システム機能が組織のミッション、ビジョン、価値、目標と戦略に 合っているかどうかをレビューし、評価するべきである」と述べている。情報システム監査人は、情報システ ム機能が事業（有効性と効率性）によって期待されるパフォーマンスについての明確なステートメントを持 ち、その成果を評価しているかどうかをレビューすべきである。 1.2 COBITとの関連 1.2.1 PO1『IT戦略計画の策定』では、 「IT戦略計画のコントロール目標は、便益、コスト、リスクに関わる透明 性を高めるとともに、ビジネス戦略やガバナンス上の要件を維持し、発展させることをビジネス要件とし、 重点をおくべきコントロールは、ビジネス要件を満たすために、どのようなサービスを提供するかという検 討に際して、ITとビジネスのマネジメント層が連携すると同時に、サービスを実現するために、透明性が高 く、効果的な方法により戦略を策定することである。」と述べている。 1.2.2 P04『ITプロセスと組織およびそのかかわりの定義』では、 「ITプロセス:ITプロセスと組織およびそのか かわりのコントロール目標は、ガバナンス要件を遵守しつつ、ビジネス戦略に迅速に対応すると同時に、明 確かつ有能な連絡窓口を設けることを、ビジネス要件とし、重点をおくべきコントロールは、透明性、柔軟 性、即応性を有するIT組織構造を確立し、ビジネスプロセスと意思決定プロセスに統合されたオーナー、 役割、および実行責任を含むITプロセスを定義、導入することである。」と述べている。 1.2.3 P05『IT投資の管理』では、 「ITプロセス：IT投資の管理のコントロール目標は、エンドユーザの期待に応 える統合・標準化されたサービスを提供し、ITのコスト効率とビジネス性への貢献度を継続的かつ確実に 向上させることを、ビジネス要件とし、重点をおくべきコントロールは、IT戦略および投資上の決定に従っ てIT予算を作成し、実績を把握し、IT投資およびポートフォリオに関する効果的、かつ効率的な意思決定 を行うことである。」と述べている。 1.2.4 ME4『ITガバンナンスの提供』では、 「ITプロセス：ITガバナンスの提供のコントロール目標は、ITガバナン スと企業のガバナンス目標の統合、および法律、規則、契約への遵守をビジネス要件とし、重点をおくべき コントロールは、ITの戦略、成果、およびリスクに関する取締役会への報告書を作成し、取締役の指示に 従ってガバナンス要件に対応することである。」と述べている。 1.2.5 個々の監査範囲に適用可能であるCOBITの中から最も関連する材料の選択は、特定のCOBIT ITプロ セスを選択し、COBITのコントロール目標と関連するマネジメントの実行を勘案して行う。情報システム 監査人の責任、権限および責任の要件を満たすために、もっとも関連性の高く、選別された、適用された COBITのプロセスは、主および副として分類される。選別され、適用されたプロセスとコントロール目的は、 特別な範囲と参照となるアサインメントによって変化するかもしれない。 1.2.7 位置づけられた領域をレビューするときに考慮されるべき次のCOBITの特定の目的とまたはプロセスは、 副次的参照に位置づけられる。 • P02 情報アーキテクチャの定義 • P03 技術指針の定義 • P06 マネジメントの意図と指針の周知 • P07 IT人材の管理 • P08 品質管理 • P09 ITリスクの評価と管理 • P010 プロジェクト管理 • DS1 サービスレベルの定義と管理 • DS2 第三者のサービスの管理 304 G39 ＩＴ組織 • DS3 性能とキャパシティの管理 • DS6 費用の捕捉と配賦 • DS7 利用者の教育と研修 • DS8 サービスであるクとインシデントの管理 • DS9 構成管理 • DS10 問題管理 • DS12 物理的環境の管理 • DS13 オペレーション管理 • AI2 アプリケーションソフトウェアの調達と保守 • AI3 技術インフラストラクチャの調達と保守 • AI6 変更管理 • ME1 IT成果のモニタリングと評価 1.2.8 IT組織に最も関連する情報要請規準： • 主：有効性と効率性 • 副：機密性、可用性、インテグリティ、コンプライアンスと信頼性 1.3 ガイドラインの目的 1.3.1 組織の構造は、目的別イネーブラまたは組織の効率の阻害になることができるが、それだけでは組織の成 功を決定することはない。一つの正しい構造というものはない。なぜなら、2つの組織は正確に一致して いないので。すべてのIT組織は、同様の目的を果たし、同様の説明責任を持っているが、そのプロファイル、 管理システム、プロセス、制約、強みと弱みは、各IT組織をユニークにしている。しかし、最適化されたIT組 織構造を検証するための特定の属性がある。 1.3.2 本ガイドラインは、情報システム監査基準S10『ITガバナンス』に適用されたガイダンスを提供する。情報シ ステム監査人は、どのように上記の標準の実装を達成し、そのアプリケーションで専門的な判断を使用し、 任意の離脱を正当化するために準備するための方法を決定する際にこのガイドラインを考慮する必要があ る。 1.4 ガイドラインのアプリケーション 1.4.1 本ガイドラインを適用するとき、情報システム監査人は、他の関連するISACAの基準やガイドラインとの関 係を考慮する必要がある。 2 IT組織 2.1 IT組織のタイプ 2.1.1 今日の組織の境界は、より柔軟でダイナミックで、ほとんどの場合、より広範囲である。組織と業界は、彼 らがその組織の物理的な壁を越えプロセスを含む全体のプロセスに焦点をあてる必要があること理解して いる。それらは、ビジネスパートナー、サプライヤー、顧客に手を差し伸べる必要がある。正確、適切かつタ イムリーな情報は、新しい経済の不可欠な要素か、拡大した企業に一般的に関連しているものである。拡 大した企業の利害関係者間での情報/知識の共有活動が有効な企業ガバナンスを提供する上での重要な 成功要因である。全体的な競争力のある戦略は、効果的な知識経営戦略とリーダーシップを駆動する必 要がある。その上にコントロールの適切なレベルを維持しながら、組織は、意思決定において上級管理職 に必要な情報を提供するために適切な情報組織を構築する必要がある。 305 G39 ＩＴ組織 2.2 ITの連携 2.2.1 ビジネスとそのすべてのコンポーネントをITとの連携により最大化するためのたった一つで適合するアプ ローチはない。多くは、ビジネスの性質、その大きさ、その市場、ITへの依存性、そのリーダーシップのスタ イルとその文化に従っている。有効なその他の要因は、組織の連携のコンポーネントと社内のIT能力、アウ トソーシングへの依存度、そのアウトソーシングの性質、全体のガバナンス構造を決定する。 2.2.2 近年では、ITは、バックオフィスサポートを提供することからトータルビジネスの主要なファシリテータと実 現者になることに大きく移動している。ITの適切な連携がなければ、その利害関係者への価値の配布を通 じてすべての企業が長期的な成功を達成し維持することは難しい。企業の全体的な戦略とITの連携は偶 然には発生しない。これは、企業内のさまざまなレベルと活動から完全かつ積極的な関与と積極的な集中 したマネジメントが必要である。これは、継続的な努力であり、世界クラスの技術や専門知識が、社内かア ウトソーシングのいずれかで、必要である。リスク適用は、適切なリスク管理と一緒に、強力かつ明白なガ バナンスが要求されている。 2.2.3 ITとの連携を実現する上での適切なガバナンスは、企業の最高レベルからのリーダーシップとコミットメン トを要求している。これは、CEOと取締役会の積極的な関与を要求する。これは、取締役会に以下の責任 を要求する。 • IT戦略がビジネス戦略に連携していることを確立すること • ITが戦略に対して提供することを確立すること • 現在の企業をサポートし、企業を変化させ、もしくは企業を成長させるシステムに適切な投資のバランス をとるためのIT戦略を導くこと 2.3 IT戦略計画 2.3.1 組織は、取締役会レベルのIT戦略委員会を確立するべきである。この委員会は、コーポレートガバナンス の一環として、ITガバナンスが適切な対処をされ、戦略的方向性について助言し、取締役会全体の代わり に大規模な投資をレビューすることを確認するべきである。 2.3.2 IT戦略委員会は、ITがいかに企業の戦略的目標（ゴール）と関連するコストとリスクに貢献しているかを、関 連する利害関係者との協力において定義されている戦略的なIT計画を作成するべきである。それは、ITが 実現する投資プログラムおよび運用サービスの提供をいかにITがサポートしているかを含んでいる。その計 画は、いかに目標が達成され、測定され、利害関係者から正式な了承を受け取るかを定義している。IT戦略 計画は投資/運営予算、調達元、調達戦略、買収戦略、法的および規制要件をカバーするべきである。 2.3.3 戦略計画は、戦術なIT計画の定義ができるように十分に詳述するべきである。IT戦略計画から導出される 戦術的なIT計画のポートフォリオを作成するべきである。これらの戦術的な計画は情報システムイニシア チブ、リソース要件、およびいかに資源の利用と便益の成就がモニターされ、管理されているかを記述する。 戦術的な計画はプロジェクト計画の定義を可能にするために十分に詳述するべきである。戦術的な計画と イニシアチブのセットは、積極的にプロジェクトとサービスのポートフォリオを分析することによって管理さ れるべきである。これは、通常、定期的に要件とリソースのバランスをとること、それらと戦略的、戦術的目 標と期待される利益の達成に比較することと、偏差に対して適切な行動をとることを包含する。 2.4 IT運営委員会 2.4.1 経営幹部、ビジネスとITのマネジメントからなるIT運営委員会（または同等のもの）を以下のために確立し なければならない。 • 企業のビジネス戦略と優先順位に沿ってITにより実行される投資プログラムの優先順位付けを決定する • プロジェクトのステータスのトラックおよびリソースの衝突を解決する • サービスレベルとサービスの改善をモニターする 306 G39 ＩＴ組織 2.4.2 その戦略の実装の監督の役割におけるIT運営委員会は、運用・保守部門の長によってサポートされた少な くとも一人のボードメンバー（会長としての役割）、および法律、監査、金融など他の主要な関係者とともに 最高情報責任者（CIO）、最高技術責任者（または同等のもの）により運用されるべきである。その議論は、 IT戦略委員会で予想されるより詳細なより高いレベルでされるであろう。また、それは、多くの入力情報を 戦略委員会の高いレベルの審議に提供することが期待されるであろう。たとえば、以下の推奨を含む。 • ITの年間レベルの支出 • ビジネス目標と企業のITアーキテクチャとの連携 • 重要なIT関連事業投資のためのプロジェクト計画の承認を含むポートフォリオ管理 • プロジェクト計画のモニタリングと内部および外部の変化が適切に更新計画に反映されていることを確 認すること • IT関連のリソースの取得および売却 • 明確なビジネスの優先順位に基づいたITリソースの衝突のモニタリング • 運用およびサポート部門の代表介して戦略目標をプロジェクトチームに伝えること • 計画を策定し、ITダッシュボード、ITバランススコアカードやその他の重要な指標で結果を監督すること • すべての利害関係者へのITの価値を伝えること。これは、さらに重要なのは、企業のWebサイトや利害 関係者とのコミュニケーションを通じて、利害関係者と外部のアナリストへ企業のイントラネット上の記 事やメンバーの印刷物を介してなされるかもしれない。 2.5 IT機能とサポーティング機能の組織の配置 2.5.1 IT機能は、企業内のITの重要性を条件とするビジネスモデルとともに全体的な組織構造に配置するべきで ある。具体的には、ビジネス戦略の重要性とITの運用依存性のレベルを考慮するべきである。CIOの報告 ラインは、企業内の重要性とITの潜在的な利益に相応すべきである。 2.6 ITの組織構造 2.6.1 内部および外部のIT組織構造は、ビジネスニーズを反映していることを確立するべきである。加えて、定期 的にスタッフィングを調整するためにIT組織の構造を見直し、期待されるビジネスの目標と変動する状況 に対処するための戦略を調達するプロセスを導入するべきである。 2.6.2 IT組織は、メンバー、スキル、機能、説明責任、権限、役割と責任、監督の要件を考慮し定義するべきであ る。この組織は、経営幹部と事業部門幹部が関与するように透明性とコントロールを検証するITプロセス フレームワークを組み込むべきである。 2.6.3 IT戦略委員会は、ITのボードの監視を検証すべきであり、また、そのビジネスとITメンバーが参加する1つ または複数の運営委員会が、ビジネスのニーズに沿ったITリソースの優先順位付けを決定するべきである。 プロセス、管理ポリシーおよび手続は、コントロールするために特別な注意、品質保証、リスク管理、情報 セキュリティ、データおよびシステムの所有権、および職務の分離とともに、すべての機能に配置するべき である。ビジネス要件のタイムリーなサポートを確認するには、ITは、関連の意思決定プロセスに関与する べきである。 2.6.4 ITプロセスのフレームワークは、ITの戦略的計画を実行するために配置されるべきである。このフレーム ワークは、ITプロセスアーキテクチャ、 （プロセスのギャップや重複を管理する場合などの）関係、所有権、 成熟度、パフォーマンス測定、改善、コンプライアンス、品質目標、それらを達成するための計画を含める べきである。これは、ITに特定されているプロセス、企業のポートフォリオ管理、ビジネスプロセスやビジネ スの変化のプロセスの統合を提供するべきである。ITプロセスのフレームワークは、品質マネジメントシス テムと内部統制のフレームワークに統合するべきである。 307 G39 ＩＴ組織 2.7 役割と責任 2.7.1 情報システムに関係する組織内のすべての担当者のための役割と責任が、定義されるべきであり、役割と それらに割り当てられた責任を果たすための十分な権限を許可するように通知されるべきである。役割の 記述文書が作成されるべきであり、定期的に更新されるべきである。これらの文書は、権限と責任双方を 記述するべきであり、関連する立場に必要なスキルおよび経験値の定義が含まれており、パフォーマンス 評価での使用に適しているべきである。役割の記述文書は、内部統制の責任を含めるべきである。 2.8 IT品質保証の責任 2.8.1 品質保証機能のパフォーマンス上の責任が、割り当てられるべきであり、品質保証グループは、適切な品質 保証システム、コントロールおよび通信の専門知識とともに提供されるべきである。組織の配置と責任と 品質保証グループのサイズは、組織の要件を満たすべきである。 2.9 アウトソーシングプロセス 2.9.1 ほとんどの企業では、ITの大部分の支出は、運用とユーザーサポートに費やされている。社内の IT部門は これらのサービスを提供することができるが、幹部は、ローカルおよびオフショア双方のサービスプロバイ ダーが、価値と顧客サービスに多くのコントロールのとれたアプローチを提供することを認識しているべき である。 2.9.2 ITの戦略的重要性増加とともに、ITに関係する幹部の期待は増加している。このような状況において、内 部組織とのバランスを保つアウトソーシングの、新しい創造的な用途が生まれている。多くの場合、社内 のITは、組織のユーザーサポート、データセンターの運用、アプリケーション開発などの日常的なサービ スを提供することをコミットしている。一方では、戦略に寄与することや主要な技術革新に貢献すること は、 （専門性があり、柔軟であると見ることができる）外部コンサルタントに任されている。これらの傾向は、 時々、ワークサポーティング規制の増加により、幹部に支持されている可能性がある。ITシステムを変更す るのに必要な時間のため、IT組織に起因するコンプライアンスの欠陥の割合は増加し、これらの傾向も増 加し、これらの課題を解決する以上に社内のリソースを集中している。幹部は、ITの戦略的活用について のアドバイスの必要性を認識し、もし彼らがIT組織からそれを得ることができない場合、他力を使うだろう。 アドバイスを得るための第三者サプライヤーやコンサルタントの活用は、客観性の欠如のリスクとなる可能 性がある。なぜなら、彼らは、戦略的、および日常活動の双方のための独自の製品やサービスを勧めること ができるからである。もし、IT組織が戦略的なアドバイスを提供することができない場合は、日々のサービ スを提供するための機会をも失われることがある。プロセスのアウトソーシングは、その核となる活動に集 中するという経営の意思決定の結果である可能性がある。なぜならば、ITプロセスのアウトソーシングは、 社内の専門知識の使用に対して、より低コストであるからである。 2.10 ITインフラストラクチャとコンピュータの運用 2.10.1 データの完全かつ正確な処理は、データ処理やハードウェアのメンテナンスの効率的な管理を必要とする。 このプロセスは、スケジュールされた処理の効果的な管理、機密性の高い出力の保護、インフラのモニタリ ングとハードウェアの予防保守のための運用ポリシーと手続を定義することが含まれている。効果的な運 用管理は、データのインテグリティを維持し、IT運用コストやビジネスの遅延を削減するのに役立つ。 2.10.2 コンピュータ機器や人員の保護は、よく設計され、管理された物理的な設備を必要とする。物理的な環境 を管理するためのプロセスは、サイトの物理的要件を定義し、適切な施設を選択し、環境要因をモニタリ ングし、物理的なアクセスを管理するための効果的なプロセスを設計することが含まれている。物理的な 環境の効果的な管理は、コンピュータ機器や人員の損傷から起こるビジネスの中断を低減する。良い予防 保守スケジュールは、機器の正常な運転を確保することに役立つ。 308 G39 ＩＴ組織 2.10.3 ハードウェアおよびソフトウェア構成のインテグリティの検証は、正確かつ完全な構成リポジトリの確立 と維持を必要とする。このプロセスは、初期設定情報を収集するベースラインの確立、構成情報の監査と 検証、および必要に応じて構成リポジトリの更新が含まれている。効果的な構成管理は、よりシステムの可 用性を容易にし、生産の問題を最小限にし、問題を迅速に解決する。 2.10.4 ITユーザーのクエリと問題点への適時かつ実効的な対応は、よく設計され、実行されるサービスデスクとイ ンシデント管理プロセスを必要とする。このプロセスは、登録、インシデントのエスカレーション、トレンド、 根本原因の分析、および解決を持ったサービスデスク機能の設定が含まれている。ビジネス上の利点は、 ユーザーのクエリの迅速な解決を介して生産性の向上が含まれる。加えて、効果的な報告を介して（最低 のユーザトレーニングなどの）根本原因に、ビジネスが対処することができる。 2.10.5 継続的なITサービスを提供する必要性は、IT継続計画、オフサイトのバックアップストレージ、定期的継続 計画のトレーニングを開発し、維持し、テストすることを必要としている。効果的な継続的なサービスのプ ロセスは、主要なビジネス機能とプロセス上の主なITサービスの中断の可能性と影響を最小限に抑える。 2.10.6 情報システムリソースのパフォーマンスと容量を管理する必要性は、定期的に現在のパフォーマンスと容量 をレビューするプロセスを必要とする。このプロセスは、ワークロード、ストレージ、および緊急時の要件に 基づいて将来のニーズを予測することが含まれている。このプロセスは、ビジネス要件をサポートする情報 リソースが継続的に利用できることを保証する。 2.10.7 必要なサービスに関する情報システム管理とビジネス顧客間の効果的なコミュニケーションは、文書の定 義と情報システムサービスとサービスレベルの合意によって有効になる。このプロセスでは、サービスレベ ルの達成上の利害関係者へのモニタリングとタイムリーな報告が含まれている。このプロセスは、情報シス テムサービスおよび関連するビジネス要件の間に配置することができる。 2.11 運用手続とタスク 2.11.1 IT運用の標準手続は、定義され、実施され、維持されるべきである。運用メンバーは、それらに割り当て られたすべてのタスクに精通しているべきである。運用手続は、連続運用を確認するために引き継ぎ作業 （すなわち、アクティビティ、ステータスの更新、運用上の問題、エスカレーション手続、現在の責任に関 する報告書の正式な引き渡し）をカバーするべきである。また、ITインフラおよび関連するイベントをモニ ターする手続は、定義されるべきである。 2.12 アプリケーションの開発 2.12.1 以下を含む様々なモードでアプリケーションシステムは獲得/開発される。 • 内部リソースを使用したカスタム開発 • オンサイトまたはオフサイト（ローカルまたはオフショアの場所で）で完全にまたは部分的に外注リソー スを使用したカスタム開発 • カスタマイズのないＡＳ－ＩＳで導入されたベンダーのソフトウェアパッケージ • 特定の要件を満たすためにカスタマイズされたベンダーのソフトウェアパッケージ 時には、 （エンタープライズリソースプランニングシステムを含む）、大規模で複雑なアプリケーションで、 上記の組み合わせが含まれる。 2.13 アウトソーシングの配置を活かしたIT機能の契約の遵守 2.13.1 ITヘルプデスクからIT運用までの多数のITサービスは、第三者のプロバイダに委託することができる。ビ ジネス要件を満たす第三者によって提供されるサービスは、効果的な第三者の管理プロセスを必要とする。 このプロセスは、第三者のアグリーメントの役割、責任と期待を明確に定義することと有効性およびコン プライアンスのための契約をレビューし、モニタリングすることによって達成される。第三者のサービスの 効率的な管理は、不良業者に関連するジネスリスクを最小限に抑える。 309 G39 ＩＴ組織 2.14 第三者に関する手続 2.14.1 すべての第三者のサプライヤのサービスは、サプライヤの種類、意義と重要性に応じて識別され、カテゴラ イズされるべきである。役割と責任、目標および予想成果をカバーする技術的、組織的な関係の正式な文 書には、これらのサプライヤの代表者の資格情報を含めるべきである。各サプライヤのための第三者のリ レーションシップマネジメントプロセスが正式化されるべきである。リレーションシップオーナーは、例えば サービスレベル契約（SLA）を介して、信頼と透明性に基づいて顧客の問題に連携するべきであり、リレー ションシップの質を確認するべきである。新しい第三者のサプライヤサービスが導入された場合は、ビジネ スの変化を反映するためにそのサービスを強化し、適応するためのサービスプロバイダーの能力を考慮す るべきである。 2.14.2 プロセスは、サプライヤが現在のビジネス要件を満たしていること、契約のアグリーメントとSLAを遵守し 続けていること、そのパフォーマンスは別の業者や市場の状況において競争力があることを確認するため にサービス提供をモニターするために確立されるべきである。 2.15 リスク、セキュリティおよびコンプライアンスのための責任 2.15.1 IT関連のリスクのためのオーナーシップと責任は、適切な上級レベルでのビジネス内に埋め込まれるべき である。情報セキュリティ、物理的なセキュリティおよびコンプライアンスのための特定の責任を含む重要 なITリスクを管理するための役割が、定義され、割り当てられるべきである。リスクとセキュリティ管理の責 任は組織全体の問題に対処するため、企業レベルで確立するべきである。追加のセキュリティ管理責任は、 関連するセキュリティ問題に対処するため、システム固有のレベルで割り当てられる必要があるかもしれな い。方向性やガイドラインは、ITリスク、任意の残留ITリスクの承認のために意欲のある上級管理職（との 協議を介して）から取得するべきである。 2.16 人事募集および保持 2.16.1 スタッフィングは、IT機能が十分な数の有能なメンバーを保持していることを確認するために、定期的な運 用、またはビジネスの大きな変更の時に評価されるべきである。人材は、ビジネス/ ITメンバーのクロス機 能トレーニング、ジョブローテーションとアウトソーシングの共同機会を考慮しなければならない。 2.16.2 主要なIT人材は、定義され、認知されるべきである。そして、彼らへの過度の依存は最小化するべきである。 緊急の場合に主要人員にコンタクトするための計画を確立するべきである。また、組織の情報資産の保護 を保証し、合意された契約上の要件を満たしているIT機能によってコンサルタントおよびその他の契約担 当者の活動をコントロールするためのポリシーと手続は、定義され、導入されるべきである。主要業績評価 指標は、そのメンバーが期待どおりに実行していることを確認するために含めるべきである。 3 監査プロセス 3.1 計画 3.1.1 監査プログラムは、範囲、目的、監査のタイミングを含め、組織のリスク評価とリスク管理戦略に基づいて 開発するべきである。レポートの取り決めが明確に監査プログラムに記載するべきである。考察は、その 組織の性格とサイズとその利害関係者に与えられるべきである。情報システム監査人は、組織の使命とビ ジネス目標、技術インフラの種類、およびビジネスクリティカルなデータの理解を得るべきである。 3.1.2 リスクアセスメントの方法論は、リスクの高い分野に焦点を当てて、レビューの範囲を定義するために使用 するべきである。 3.1.3 任意の過去の監査報告書は、見直するべきである。深さのレベルは、管理行動計画に基づいて、各問題に ついて位置づけするべきである。 310 G39 ＩＴ組織 3.1.4 情報システム監査人は次のIT組織に関する情報を取得するべきである。 • 情報管理者、所有者や上司を含む主要メンバーの役割と責任 • 上級管理職ステアリングの役割と責任 • 組織の目標と長期および短期計画 • 企業戦略の方向性の設定 • ITの目標と長期および短期計画 • ステータスレポートや企画/運営委員会会議の議事録 • 情報アーキテクチャモデル • IT組織に関連するポリシーと手続、その関係性 • ポジションの説明、トレーニング、および開発記録 • 第三者のサービスプロバイダーとの契約 • 企業のために設定された戦略的な目標を達成するために必要な技術とITインフラストラクチャを企業は 開発しているかどうかの決定 3.1.5 情報システム監査人は、低いレベルに目標を設定して使用される通信チャネル（トップダウン）とその遵守 を（ボトムアップ）をモニターするために使用する情報を含むセクション4.1.1に記載された機能を実行する ことをIT組織に有効にするプロセスの一般的な理解を、識別し、得るべきである。 3.1.6 情報システム監査人は、 （文書か否かにかかわらず）次の組織の情報システム戦略上の情報を取得するべ きである。 • 組織の使命と目標を達成するための長期および短期計画 • これらの計画をサポートするためのITとシステムの長期および短期戦略と計画 • IT戦略を設定し、計画を立案し、それらの計画に対する進捗状況をモニターするアプローチ • IT戦略と計画の変更を管理するアプローチ、 • ITのミッションステートメントと、IT活動の目的と目標の合意 • 既存のIT活動やシステムのアセスメント 3.2 監査の目的 3.2.1 IT組織の監査の目的は、意図した監査結果の聴取者のニーズと意図された普及のレベルによって影響を 受けるかもしれない。情報システム監査人は、監査の全体的な目標を確立することにおいて、次のオプショ ンを考慮するべきである。 • IT組織およびその有効性の報告 • ITイニシアチブは、組織の使命と目標をサポートするかどうか • アプリケーション、技術、組織の代替戦略の評価 3.2.2 通常、IT組織の情報システム監査の詳細な目的は、、最上位レベルの管理によって行使される内部統制の フレームワークに依存している。確立されたフレームワークのない場合は、COBITフレームワークを詳細な 目標を設定するための最低限の基準として使用するべきである。 311 G39 ＩＴ組織 3.3 監査の範囲 3.3.1 情報システム監査人は、計画とIT活動を組織するための関連するプロセスとアクティビティをモニターする ためのプロセスを監査の範囲に含めるべきである。 3.3.2 監査の範囲は、COBITフレームワークで定義されたITリソースのフルレンジの使用と保護のためのコント ロールシステムを含めるべきである。これらは以下を含む。 • データ • アプリケーションシステム • テクノロジー • 設備 • 人材 • ITガバナンス 3.4 メンバー 3.4.1 情報システム監査人がこのレビューを実行するメンバーには適切な年功と能力のある者が含まれているこ との合理的な保証を提供するべきである。 4 監査作業の成果 4.1 IT組織と戦略的計画プロセスのレビュー 4.1.1 IT組織との関係のレビューでは、情報システム監査人は、定義され、伝達され、ビジネスと整合する役割と 責任ともに、メンバーやスキルの適切な組み合わせがあるかどうかを考慮するべきである。情報システム監 査人は、以下をレビューに含める。 • ポリシーステートメントと上級管理職からの伝達は、IT機能の独立性と権限を確認する • IT計画/運営委員会のメンバーと機能が定義され、責任が識別されている • IT計画/運営委員会の憲章は、組織の目標と長期および短期の範囲の計画とIT目標と長期および短期 の範囲とともに委員会の目標を揃える • CIOのレポートラインは、企業のビジネスとの関係における機能の重要性と同等であり、企業業界とそ の市場の動向をフォローする • ポリシーは、変更の目的や状況に合わせて組織構造の評価と変更の必要性に対処する • 上級管理職は、役割と責任が行われていることを確認する • ポリシーは、情報システム、内部統制、セキュリティに対する組織内のすべての担当者の役割と責任を確 認する • 品質保証機能とポリシーは、IT組織のために存在する • 方針と手続は、すべての主要なデータソースやシステムのためのデータとシステムのオーナーシップをカ バーする • ポリシーと手続は、役割と責任が適切に行使していること、すべての者がそれぞれの役割と責任を実行 するのに十分な権限とリソースを持っていることを確認するために監督プラクティスを記述している • 職務の分離は、システム開発、保守、システム開発と運用、システム開発/保守、情報セキュリティ、運用、 およびデータコントロール、運用、ユーザー、および運用および情報セキュリティの間に存在する • ITメンバーと能力は効果的な技術ソリューションを提供する能力を確認するために維持される • 適切な役割と責任は、システム開発ライフサイクル活動、情報セキュリティ、買収および容量計画などの 重要なプロセスのために存在する 312 G39 ＩＴ組織 • 適切かつ効果的な主要業績評価指標および/または重要な成功要因は、組織の目標を達成することに おいてIT機能の成果を測定することに使用される • ITポリシーおよび手続は、コンサルタントおよびその他の契約担当者の活動をコントロールするため、ま た組織の資産の保護を確認するために存在する • 手続は、組織の取得ポリシーの妥当性、一貫性のためにITサービスの契約に適用される • プロセスは、内外双方のIT機能の利益をコーディネートし、伝達し、文書化するために存在する • ポリシーと手続は、IT機能によるサービスの配信が正当化されたコストであり、要される機能や業界の コスト内で行われていることを保証するために設けられている • 組織の雇用と終了の手続はバックグラウンドチェックを含む 4.1.2 ITの戦略的計画プロセスの見直しでは、情報システム監査人は以下を考慮するべきである。 • ITミッションとビジョンの明確な定義がある • 代替する戦略的IT計画の方法論がある • 方法論は、ビジネスの目標や目的を情報システムの目標と目的に関連付ける • この計画プロセスは定期的に（少なくとも年1回）が更新される • この計画は、必要な情報システムイニシアチブやリソースを特定する • このプロセスに関与した個人のレベルが適切である 4.1.3 現在のシステムのポートフォリオを管理するために使用されるプロセスの見直しでは、情報システム監査人 は、現在のシステムで組織の戦略的かつ支援する領域の範囲を考慮するべきである。情報システム監査人 は以下を評価に含める • ビジネス戦略立案プロセスで定義された戦略的な分野を供給して発行されたポリシーの全体的な範囲 • 詳細に述べられ、伝達され、実施され、および監視ポリシーをモニターするために最上位レベルのマネジ メントによりフォローされたプロセス • 文書化されたポリシーは、必要に応じて次の事項上に存在する：セキュリティ、人材、データの所有権、 エンドユーザーコンピューティング、知的財産、データ保持、システムの取得と実装、アウトソーシング、 独立の保証、継続計画、保険、プライバシー • 評価中のプロセスに関与する人々（例えば、データの所有者、ITマネジメント、上級マネジメント）の役割 と責任の定義は、これらのプロセスをサポートするために適切である • 評価中のプロセスに関与する人々は、スキル、経験とその役割を果たすために必要なリソースを持っている • 内部監査の関与の適切なレベル（もし組織が内部監査のリソースを持っている場合）が提供されている • ITスペシャリストのメンバーや機能の組織内の位置は、事業目標を達成するためにITを最大限活用する ように組織を有効にするために適切である • ITのスペシャリスト、およびIT責任を持つ非スペシャリストの組織とマネジメントは、エラー、不作為、不 正や違法行為の組織へのリスクに対処するために十分である 313 G39 ＩＴ組織 5 報告 5.1 報告書の生成とフォローアップ 5.1.1 監査報告書案は、作成され、関係者と協議されるべきである。明確な監査証拠によってサポートされたそ れらの問題だけが含まれているべきである。修復のためにさされた勧告は、 マネジメントを代表する適切な 担当者と協議するべきである。 5.1.2 報告書には、次のISACAのガイドラインを完成させるべきであり、問題を解決／改善し、オプションをフォ ローアップするための推奨とともにマネジメントに発表されるべきである。 5.1.3 上級マネジメントによって与えられたフォローアップ活動、行動計画、責任、目標期日、リソース、および優 先順位は、合意されるべきである。 6 適用開始日 6.1 本ガイドラインはすべての情報システム監査人のために2008年5月1日から適用される。 参照 IT Governance Institute, IT Alignment: Who’s in Charge?, USA, 2005 314 G40 セキュリティ管理業務のレビュー 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 316 2 セキュリティ管理業務の導入‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 317 3 セキュリティ管理業務の見直し‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 318 4 監査プロセス‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 326 5 業務のパフォーマンス‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 326 6 報告‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 326 7 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 326 G40 セキュリティ管理業務のレビュー 1 背景 1.1 基準との関連 1.1.1 基準S1『監査ポリシー』は、 「情報システム監査機能ないし情報システム監査業務の目的、責任、権限、説 明責任は、監査ポリシーまたは監査契約書により適切に文書化されているべきである」と述べている。 1.1.2 基準S3『専門家としての倫理と基準』は、 「情報システム監査人は、 「ISACAの職業倫理規定」を遵守す べきである」と述べている。 1.2 COBITとの関連 1.2.1 個々の監査範囲に適用可能であるCOBITの中から最も関連する材料の選択は、特定のCOBIT ITプロセ スを選択し、COBITのコントロール目標と関連するマネジメントの実行を勘案して行う。情報システム監査 人がセキュリティ管理業務のレビューする際に、最も関連し、選定され、採用される可能性が高いCOBIT のプロセスが、以下で主要なものと副次的なものとして分類されている。選定され、採用されるべきプロセ スとコントロール目標は、特定の範囲と任務の権限次第で変化するかもしれない。 1.2.2 このガイダンスが対応する領域のレビューを実施する際に検討すべきCOBITの主要な目標、プロセスは次 の通り。 • PO2 情報アーキテクチャの定義 • PO9 IT リスクの評価と管理 • DS5 システムセキュリティの保証 • DS7 利用者の教育と研修 • ME2 内部統制のモニタリングと評価 • ME3 外部要件に対するコンプライアンスの保証 • ME4 ガバナンスの提供 1.2.3 ガイダンスが対応する領域のレビューを実施する際に検討すべきCOBITの副次的な目標、プロセスは次の 通り。 • PO6 マネジメントの意図と指針の周知 • PO7 IT 人材の管理 • DS1 サービスレベルの定義と管理 • DS2 サードパーティのサービスの管理 • DS9 構成管理 • DS10 問題管理 • DS12 物理的環境の管理 • AI1 コンピュータ化対応策の明確化 • AI2 アプリケーションソフトウェアの調達と保守 • AI3 技術インフラストラクチャの調達と保守 • AI6 変更管理 • ME1 IT 成果のモニタリングと評価 1.2.4 責任、権限および説明責任に最も関連する情報要請規準： • 主：有効性、効率性、機密性 • 副：可用性、インテグリティ、信頼性 316 G40 セキュリティ管理業務のレビュー 1.3 ガイドラインの目的 1.3.1 情報は事業において最も価値ある資産である。情報は競争に勝つためにますます不可欠なものとなってお り、経済的生き残りのために欠くことのできないものとなっている。現実の相互関連した世界において、組 織は投資を保護するだけでなく、資源の誤った利用により生じるリスクから情報資産を守るためにも、意 図するかしないかにかかわらず、情報資産を無許可の利用から保護すべきである。このような情報資産の 保護は、正式で詳細な情報セキュリティ管理フレームワークを企業に導入することによってのみ達成でき る。本ガイドラインはマネジメントが導入した情報セキュリティ管理業務の設計と運用の有効性を評価し、 結論づけるための詳細なガイダンスを提供する。 1.4 ガイドラインの適用 1.4.1 本ガイドラインを適用する際、情報システム監査人はそのガイダンスを他の関連するISACAの基準とガイ ドラインとの関連において考えるべきである。 1.5 定義 1.5.1 情報は適切に保護される必要がある組織にとって価値ある資産である。情報は紙に記載されていたり、電 子的媒体に電子的に記録されていたり、媒体に適した方法で伝送されたりするなど多様な形態をとること がある。 1.5.2 情報セキュリティとは、認可されたユーザのみが（機密性）必要なときに（可用性）正確かつ完全な情報に アクセスできること（インテグリティ）を保証するために導入される一連の方策をいう。 1.5.3 情報セキュリティマネジメントシステム（ISMS）は、事業リスクアプローチに基づき情報セキュリティを規 定・導入・運用・モニタリング・レビュー・維持・改善していくための全般的な管理体系である。セキュリ ティ管理施策の導入のための組織体制には、ポリシー、計画活動、責任、手続、プロセス、資源が含まれ る。 1.5.4 ISO27001情報セキュリティマネジメントシステム―仕様および利用の手引はBS7799-2の後継規格で ある。当該規格は第三者監査の基礎を提供することを目的としており、またISO/IEC9001:2000やISO/ IEC14001:2004などの他のマネジメント規格と調和が図られている。 2 セキュリティ管理業務の導入 2.1 計画的なアプローチ 2.1.1 ISMSの適用を検討する企業はセキュリティ管理業務の導入のための一連の処理アプローチに従うべきで ある。セキュリティ管理業務の導入には、ISMSの確立、導入と運用、モニタリング、見直し、維持および改 善といったすべての活動を含むべきである。フレームワークの導入のため、組織は計画－実行－点検－処 置（PDCA）モデルを選択適用することができる。 2.2 セキュリティ管理業務の確立 2.2.1 情報システム監査人は、企業が情報セキュリティポリシー、および適切なリスク評価プロセスにおいて識 別されたリスクの管理に関連する手続を文書化し、導入していることを検証し、情報セキュリティの成果を 改善し、組織のポリシーに対するコンプライアンスを保証し、企業の目標を達成すべきである。 317 G40 セキュリティ管理業務のレビュー 2.3 セキュリティ管理業務の導入と運用 2.3.1 情報システム監査人は、企業が適切なコントロール、責任および情報セキュリティリスクの優先順位づけ を識別し、情報セキュリティを保護するためのリスクと関連する目標への対応に必要なすべてのコントロー ルを導入していることを検証すべきである。加えて、情報システム監査人は、セキュリティインシデントの発 見と対応に関する測定方法を含めて、意図した通りにコントロールを運用するための適切なプロセスを企 業が有していることを検証すべきである。 2.4 セキュリティ管理業務のモニタリングと見直し 2.4.1 情報システム監査人は、組織がセキュリティ管理業務の有効性と効率性をモニタリングするための手続を 有しているか検証すべきである。 2.5 セキュリティ管理業務の維持と改善 2.5.1 情報システム監査人は、ISMSの継続的な適用性、妥当性、有効性および効率性を確認するためにマネジ メントが定期的にレビューを実施することを保証するためのプロセスを企業が有しているか検証すべきで ある。 3 セキュリティ管理業務の見直し 3.1 セキュリティ管理業務 3.1.1 情報システム監査人は、ポリシー、プラクティス、手続、セキュリティ組織およびセキュリティに関する役割 と責任を含む一連のセキュリティ管理業務を企業が有しているか検証すべきである。情報システム監査人 は、セキュリティ管理業務が、リスク評価プロセスを通じてセキュリティ要件を識別した後、かつまた情報 保護ならびに企業に要求される情報処理要件への適合に関する法的、法定あるいは規制上の要件に対す る理解に基づいて、企業により確立されているか検証すべきである。 3.2 情報セキュリティ組織構造 3.2.1 情報システム監査人は、 マネジメントにより承認された詳細な情報セキュリティポリシーの公表と周知によ り、セキュリティ管理業務の導入を確実にするという明確なセキュリティポリシーの方向性を企業が有して いるか検証すべきである。 3.2.2 情報システム監査人は、情報セキュリティポリシーが少なくとも次の点を含んでいるか検証すべきである。 • 情報セキュリティの定義、目標および領域 • セキュリティポリシーの声明で示されるマネジメントのセキュリティ管理業務導入目的 • セキュリティポリシー・原則・基準・コンプライアンス要件の一覧表 • 情報セキュリティ管理構造と関連する責任 • より詳細なポリシーや手続などセキュリティ管理業務の導入関連文書 3.2.3 情報システム監査人は、企業が情報セキュリティポリシーを企業全体に伝達するために継続的な訓練と周 知のためのプログラムを文書化し、導入しているか検証すべきである。 3.2.4 情報システム監査人は、情報セキュリティポリシーの有効性と適用性を確かめるために、これを定期的に 評価するプロセスを文書化し、導入しているか検証すべきである。 3.2.5 情報システム監査人は、企業がセキュリティ管理業務の導入、継続的評価、モニタリングおよび改善に係 る責任、ならびに情報セキュリティの達成のためのセキュリティコントロールの準備と導入の促進に係る責 任について定義しているか検証すべきである。 318 G40 セキュリティ管理業務のレビュー 3.2.6 情報システム監査人は、企業が新たな情報処理設備の導入を承認する前にこれをレビューするプロセスを 有しているか検証すべきである。 3.3 情報への第三者のアクセスおよびアウトソーシング 3.3.1 情報システム監査人は、第三者による権限外のアクセスあるいは情報の不適切な利用を防止するために、 企業が適切なアクセスコントロールプロセスを導入しているか検証すべきである。当該コントロールは、第 三者にアクセスを与える前に導入されるべきである。 3.3.2 情報システム監査人は、企業が次のようなすべてのコントロール要求を組み込んでいるか検証すべきであ る。 • 機密性とインテグリティ • 適切な利用 • 該当する法的要件 • 全関係者がセキュリティに関する責任を確実に自覚するための取り決め • 企業の事業資産のインテグリティと機密性を確保するためのコントロール • 物理的および論理的セキュリティ要件 • アウトソーシングサービスの可用性 • 従業員の身元調査 • アウトソースした設備の監査。すべての第三者との契約に監査権が含まれているべきである 3.4 資産の分類とコントロール 3.4.1 情報システム監査人は、企業がすべての情報資産について、その保護のために、オーナを識別し、説明責 任を課しているか検証すべきである。そのような資産に係るオーナシップと説明責任のプロセスには、保護 のメカニズムの定義の他に、保険や財務管理を含む保護措置を決定する際に役立つ資産目録を含んでい るべきである。また、情報システム監査人は企業の資産に次のカテゴリが含まれているか検証すべきであ る。 • 情報資産（例：データベース・データファイル・事業継続計画・ネットワーク図・セキュリティアーキテク チャ） • ソフトウェア資産（例：アプリケーションソフトウェア・システムソフトウェア・ツールとユーティリティ・ 関連するライセンス） • 物的資産（例：コンピュータ・通信設備・電子的メディア） • サービス（例：暖房や照明・ライフライン） 3.4.2 情報システム監査人は、情報資産のビジネスへの感応度と重要性・保護と保持に係る法的要件を含む情 報の価値・情報あるいは情報のインテグリティが消失するか情報が利用できなくなった際のビジネスへの 影響に基づいて、企業がすべての情報資産を分類しているか検証すべきである。 3.4.3 情報システム監査人は、企業がすべての分類済み情報資産に標章を付けるとともに、複製・保管・様々な 手段による伝送・破棄を含めて適切な取扱手続を定義しているか検証すべきである。 319 G40 セキュリティ管理業務のレビュー 3.5 人的セキュリティ 3.5.1 情報システム監査人は、企業が次を実施しているか検証すべきである。 • 採用段階で、職務内容におけるセキュリティ業務の責任を明確にして、セキュリティに関する責任につい て説明している • 特に機密業務について、全従業員のセキュリティ適格審査の実践を導入している • 従業員あるいは第三者が機密保持契約にサインすることを要求している • 雇用契約条項に基づいて情報セキュリティに対する責任を規定している 3.5.2 情報システム監査人は、企業がセキュリティポリシーおよびセキュリティ手続に関する適切な研修プログラム を有しており、必要に応じてすべての従業員および非従業員に研修を実施する手続を有しているか検証す べきである。情報システム監査人はまた、組織内の選定したユーザについて、少なくとも試査により、ユー ザがすべてのセキュリティ手続を知っており、セキュリティリスクの可能性を最小化するためにこれらの手 続に従う方法を知っているか検証すべきである。 3.5.3 情報システム監査人は、企業が次を実施しているか検証すべきである。 • 報告・インシデント対応が文書化され、導入されている • セキュリティ報告およびインシデント対応手続について企業全体に周知し、教育している • 情報システムにおいて識別されたセキュリティ上の弱点を報告し、適切な改善活動を行うよう、ユーザに 要求している • ソフトウェアの誤動作の報告手続が文書化され、導入されている • マネジメントが再発するインシデントを識別し、適宜セキュリティコントロール要件を強化することがで きるようにするため、適切なインシデント報告機能が導入されている • セキュリティ違反を犯した従業員に対する正式な懲罰プロセスが文書化され、導入されている 3.5.4 情報システム監査人は企業が証拠を集めるための適切な手続を導入しているか検証すべきである。当該手 続には、情報セキュリティインシデントに関わる（民事または刑事の）法的措置が開始された後に、関連す る法的管轄の定めに従って適切な証拠を収集、保持、 （必要に応じて）提出するための、個人または企業 に対するフォローアップを含めるべきである。 3.5.5 情報セキュリティ監査人は、企業がセキュリティ違反に起因して法的措置がとられた場合の従業員解雇の 正式なプロセスを有しているか検証すべきである。当該正式プロセスには次が含まれるべきである。 • 解雇が発生した状況および解雇決定に関する責任 • 退職または契約・合意の終了と同時に、すべての従業員、契約者、第三者は保有する企業の資産をすべ て返却するという要件 • 退職または契約・合意の終了と同時に、すべての従業員、契約者、第三者の情報および情報処理設備 へのアクセス権限を除去（または変更に基づき調整）すること 320 G40 セキュリティ管理業務のレビュー 3.6 物理的セキュリティ 3.6.1 情報システム監査人は、企業が事業所の建物を物理的セキュリティの脅威から守るための適切なセキュリ ティコントロールを導入しているか検証すべきである。これらのコントロールには次が含まれる。 • 情報および情報処理機器が置かれた保護された区画周辺のセキュリティ • 保護された区画へ許可された者のみが立ち入れるための適切な入退手続 • 事業所、執務室および施設の物理的セキュリティ • 自然または人為的災害による損害に対する物理的保護 • 保護された区画での執務の物理的保護 • ネットワークキャビネ（通信機器のキャビネを含む）の物理的アクセスコントロール • 情報処理機器に対する許可されていない者がアクセスする可能性のある搬入場所等と、物理的な場所 およびアクセスエリアの分離 3.6.2 情報システム監査人は、企業が資産の損害・損失・毀損・事業活動の中断等を防ぐような適切な物理的セ キュリティコントロールを導入しているか検証すべきである。これらのコントロールには次が含まれる。 • 環境の脅威、危険および無許可のアクセスによるリスクを減少させるための、通信ネットワーク機器を 含むすべての設備の保護 • その設備の故障により混乱を招くことがないように支援する設備の適切な維持管理 • データや支援情報サービスのために利用する電力およびネットワークケーブルのネットワークの遮断や 損傷からの保護 • 可用性およびインテグリティを継続確保するための設備の適切な維持管理 • 企業の建物の外で作業することで発生する異なるリスクを考慮した、オフサイト設備に対する適切な保 護手段 • すべての機器またはメディアに含まれる全機密データおよびソフトウェアが、機器が処分される前に確 実に削除または上書きされることを確かめるためのコントロール • アクセスカードやトークンなどのアクセス装置が処分される前に機密情報を削除する • 設備・情報・ソフトウェアをオフサイトに移設する前の適切な承認要件 3.7 コミュニケーションと運用管理 3.7.1 情報システム監査人は、企業の運用手続をレビューすると共に、以下の事項について検証すべきである。 • 運用手続が文書化および維持され、必要なすべてのユーザが利用できるようにしている • 情報処理機器およびシステムの変更がコントロールされるべきである • 企業の資産の無許可または無意識の変更または誤用の機会を減少させるために職務分掌およびエリア の分離がなされている • 本番運用環境への無許可のアクセスまたは変更がなされるリスクを減少させるために、開発、テスト、本 番運用環境が分離されている • 第三者ベンダーとの契約に含まれるセキュリティコントロール、サービスの定義および提供レベルが、第 三者ベンダーにより条件に盛り込まれ、運用、維持されるべきである。第三者ベンダーにより提供される サービス、報告および記録は定期的にモニタリング、レビューまたは監査されるべきである 3.7.2 情報システム監査人は、企業が以下の事項について文書化し、導入しているか検証すべきである。 • 必要なシステムのパフォーマンスを確保するための、すべての情報資源が将来的に必要となるキャパシ ティのモニタリング、調整および計画する手続 • 開発および承認前における新しいシステム、アップグレードおよびバージョンアップのシステムの影響テ ストを含む承認規準 321 G40 セキュリティ管理業務のレビュー 3.7.3 情報システム監査人は、企業が悪質なソフトウェアから身を守るため、以下のコントロールを備えているか 検証すべきである。 • 悪質なコードの検出、阻止および復旧と適切なユーザへの注意喚起手続のコントロール。これらの保護 手段にはアンチウイルスソフトウエア、スパイウエア、アドウエアなどを検知、駆除するソフトウェアのイ ンストールを含む • モバイルコードの使用の認可および認可されたモバイルコードが明確に定められたセキュリティポリ シーに従って動作することを確実とする適切な構成管理を確かめるためのコントロール、および未許可 のモバイルコードの実行を防ぐコントロール 3.7.4 情報システム監査人は、企業が合意された戦略を遂行するために日常的な手続、例えばタイムリーな復旧 のために必要とされる復旧テスト、バックアップの失敗と回復の記録、必要に応じた機器環境のモニタリ ングを文書化し、導入しているか検証すべきである。これらの手続には、情報、オペレーションログ、エラー の記録のバックアップを含めるべきである。 3.7.5 情報システム監査人は、企業が送信中のデータを含め、ネットワークを使用しているシステムとアプリケー ションを脅威から保護し、セキュリティを維持するため、ネットワークを管理し、保護する適切なコントロー ルを確立しているかどうか検証すべきである。情報システム監査人は、ネットワークサービス契約が、その サービスが社内サービスであるか委託先のサービスであるかにかかわらず、すべてのネットワークサービス にセキュリティ機能・サービスレベル・マネジメントの要求が含まれているか検証すべきである。保護の手 段としては、必要に応じてファイアウォールの導入や侵入テストを含むネットワークのスキャンも考えられ る。 3.7.6 情報システム監査人は、企業が以下のような正式な手続を確立しているか検証すべきである。 • 不要となったメディアの確実かつ安全な廃棄 • 無許可の公開および誤用を避けるための情報の取り扱いおよび保管 • 無許可のアクセスからのシステム文書の保護 3.7.7 情報システム監査人は、企業が次を確立しているか検証すべきである。 • すべての種類のコミュニケーション設備を通じて情報の交換を保護するための、正式な情報交換のポリ シー・手続・コントロール • 企業と社外組織間での情報およびソフトウェアの受け渡しに関する合意 • 物理的に企業の外に情報を持ち出す場合の、移送中の無許可のアクセス、誤用、破損からのメディアの 保護 3.7.8 情報システム監査人は、企業が次のような方針等を確立しているか検証すべきである • 企業情報システムの相互接続に関する情報を保護するポリシー・手続 • 電子メッセージを含む情報の適切な保護手段 • 公衆回線を介した電子商取引を含む情報を、詐欺行為・契約紛争・無許可の公開・改変から保護する ための適切な保護手段 • オンライン取引が完全に送信されることを保証し、データが誤った経路を辿ることや、無許可のメッセー ジ改変・公開・複製・返信が発生しないことを保証する保護 • 公共システム上で利用できる情報のインテグリティを確保するための保護 3.8 情報資源に対するアクセスコントロール 3.8.1 情報システム監査人は、企業が事業およびセキュリティ要件をもとに、文書化されたアクセスコントロール の方針を有するか検証すべきである。 322 G40 セキュリティ管理業務のレビュー 3.8.2 情報システム監査人は、企業が、すべての情報システムおよびサービスへのアクセス権限の付与・削除に関 して、正式なユーザ登録・削除手続を文書化し、導入しているか検証すべきである。当該プロセスには、a) 制限され、コントロールされた権限の割当てと使用、b)定期的なユーザーアクセス権限のレビュー、c)アク セス権限の適時の削除を含むべきである。 3.8.3 情報システム監査人は、企業が次を保証するためのコントロールを文書化し、導入しているか検証すべきで ある。 • 情報ユーザが、パスワードの選定および利用に関して、優れたセキュリティの実践方法に従う必要がある • 管理者・特権権限を持つ情報ユーザは、より強固なパスワードを利用し、パスワードをより頻繁に変更 する必要がある（さらに言うなら、より強固なパスワードの利用はすべてのユーザにとっての最善の方法 である） • 情報ユーザが、利用していない機器が適切に保護されていることを確かめる • 情報ユーザが、紙文書、リムーバブル記憶メディアについてクリアデスクの方針を採用し、情報処理機器 についてはクリアスクリーンの方針を採る 3.8.4 情報システム監査人は、企業が次のネットワーク・アクセス・コントロールについて文書化し、導入している か検証すべきである。 • リモートユーザによるアクセスをコントロールするための適切な認証および承認手段 • 診断、設定用ポートに対して物理的、論理的にコントロールされたアクセス • ネットワーク上の情報サービス、ユーザおよび情報システムの分離されたグループ。これは特に企業の境 界を越えたネットワークについて、ユーザのネットワーク接続能力が、ビジネスアプリケーションのアクセ スコントロール・ポリシーおよび要件に従うことを保証するように、共有ネットワークに対する適切な制 限を含むべきである • コンピュータの接続および情報フローがビジネスアプリケーションのアクセスコントロール・ポリシーに 違反しないことを保証するための、ルーティングのコントロール 3.8.5 情報システム監査人は、企業がオペレーティングシステムへのアクセスを保護するため、以下の点を文書化 し、導入しているか検証すべきである。 • オペレーティングシステムへの安全なログオン手続 • 企業内のすべてのユーザに本人のみが利用するよう割り当てられたユニークな識別子（ユーザID）、およ び要求されたユーザの識別を実現する適切な認証技法 • パスワード管理およびパスワードのクオリティを確実にするための対話式システム • システムおよびアプリケーションのコントロールを無効化する機能を有する可能性のあるユーティリティ プログラムへのアクセスを制限するコントロール • リスクの高いアプリケーションへの追加的セキュリティとして機能する接続回数の制限 3.8.6 情報システム監査人は、企業がアプリケーションへのアクセスを保護するため、以下の点を文書化し、導入 しているか検証すべきである。 • 定義されたアクセスコントロール・ポリシーに従ったユーザおよび補助者情報およびアプリケーションシ ステム機能へのアクセス • 機密システムを保護するための専用の（切り離された）コンピュータ環境 323 G40 セキュリティ管理業務のレビュー 3.8.7 情報システム監査人は、企業がシステムアクセスおよび利用のモニタリングについて、次の点を文書化し、 導入しているか検証すべきである。 • モバイルコンピューティングおよびコミュニケーションツールの利用によるリスクから守るための正式な ポリシーおよび適切なセキュリティ手段 • ユーザの操作、例外およびセキュリティイベントを記録する監査ログ、および当該ログを将来の調査およ びアクセスコントロール・モニタリングを支援する合意された期間維持するための手続 • 情報処理設備の利用のモニタリングと、モニタリング結果のレビューのための手続 • 不正使用および無許可のアクセスのログ取得機器およびログ情報を守るためのコントロール • ログシステムの管理、運用およびIT管理者の日常的な操作のモニタリング手続 • ログ取得・分析・エラー検知時の手続 • 企業またはセキュリティドメイン内のすべての関連する情報処理システムの時計と合意された正確な時 間ソースとの同期 3.8.8 情報システム監査人は、企業が次の点を完了しているか検証すべきである。 • ネットワーク内部および外部、情報システムおよびアプリケーションからの脅威および脆弱性の正式な 評価 • 企業ネットワーク内への侵入検知の導入 • 情報システムの現在のセキュリティレベルを危険にさらさないセキュリティパッチおよびその他のシステ ムに必要なパッチ適用のための適切な手続 • セキュリティ事故に対応するための予防・発見・修正計画 3.9 システム開発・保守に関わる文書化と導入 3.9.1 情報システム監査人は、新たな情報システムに関するビジネス要件記述書、あるいは既存の情報システム の機能強化において、次のセキュリティコントロールに関する要件が含まれているか検証すべきである。 • アプリケーションシステムのアクセスコントロール • データが正確かつ適切であることを保証するためのアプリケーションデータ入力における妥当性確認の 要件 • 処理誤謬または意図的な行為による情報の破損を検出するアプリケーションのデータ妥当性チェック • アプリケーションにおける信頼性の保証とメッセージインテグリティの保護に関する要件 • 保存情報の処理が状況に応じて正確かつ適切であることを保証するためのアプリケーションからの データ出力の妥当性確認 3.9.2 情報システム監査人は、企業が情報保護のために暗号化コントロールを利用する際のポリシーを文書化 し、導入しているか検証すべきである。当該コントロールには、企業の暗号化技法利用をサポートする暗号 鍵管理を含むべきである。 3.9.3 情報システム監査人は、企業が運用システムへのソフトウェア導入およびプログラムソースコードへのアク セスをコントロールするための手続を確立しているか検証すべきである。 3.9.4 情報システム監査人は、企業が正式な変更管理手続を確立しているか検証すべきである。当該手続には次 が含まれる。 • オペレーティングシステムが変更された際に、組織の運営あるいはセキュリティに悪影響がないことを 保証するために、ビジネス上重要なアプリケーションのレビューとテストを実施する • パッケージソフトウェアの改修を、必須の変更に限定する • アウトソースしたソフトウェア開発をモニタリングする 利用している情報システムの技術的脆弱性に関する情報を適時に入手するプロセス。これには、脆弱性の 発現の評価と、リスクに対処するための適切な対策を導入するプロセスを含む 324 G40 セキュリティ管理業務のレビュー 3.9.5 情報システム監査人は、システムがビジネスおよびコントロールの要件を満たしているか評価するために、 システム開発、導入後にシステムの導入後レビューを実施すべきである。場合によっては、情報システム監 査人は、適時改善のために弱点やコントロールの改善点を識別するため、システム導入に先行してシステム の導入前レビューも実施することがある。 3.10 事業継続管理 3.10.1 情報システム監査人は、企業が次項を定めているか検証すべきである。 • 企業の業務継続に必要な情報セキュリティ要件に対応するための、組織全体の業務継続に関する管理 されたプロセス • ビジネスプロセスの中断を生じる可能性がある事象と、そのような中断の発生可能性と影響および情報 セキュリティに及ぼす影響を識別するためのプロセス。これには災害インシデント対応管理と関連手続 がふくまれるべきである • 重要なビジネスプロセスの中断や障害の後、必要なレベルまで、要求された時間で、業務を維持・復旧 させ、情報の可用性を保証するための計画 • すべての事業継続計画が一貫しており、一貫して情報セキュリティ要件に対応していて、検証と保全の優 先事項が明確になっていることを保証するための、単一の事業継続計画フレームワーク • 事業継続計画が最新かつ有効であることを保証するための、全事業継続計画の検証と定期的な更新。 必要に応じて、情報システム監査人はマネジメントの事業継続計画の検証プロセスを観察することがあ る • 特に企業内で事業継続プロセスに関与するとして特定された人々の責任に関する、訓練と意識向上の 実施計画 3.11 コンプライアンス 3.11.1 情報システム監査人は、企業が次項を実施しているか検証すべきである。 • すべての法令・規制・契約の要件、および企業がこれら要件を各情報システムと企業全体に関して満た すための取り組みについて定義し、文書化し、常に最新の状態にしている • 知的財産権が存在するかもしれない材料の使用、および所有権を主張できるソフトウェアの使用に関 する法令・規制・契約の要件に対するコンプライアンスを保証するための適切な手続が導入されている • 法令・規制・契約、ビジネスの要件に従い、重要な記録が損失、破壊、改ざんから保護されている • 関連する法令・規制ならびに該当する場合には契約条項が要求する、データ保護およびプライバシーに 関するコントロールが導入されている • ユーザの不正目的による情報処理設備の利用を防止するためのコントロールが導入されている • 企業に導入されているすべてのソフトウェアが使用許諾を得ているかオープンソースであることを要求す るコントロールが導入されている • すべての関連する協定・法令・規制に従って、暗号化コントロールが導入されている 3.11.2 情報システム監査人は企業が次項を確認するためのプロセスを確立しているか検証すべきである。 • セキュリティポリシーおよびセキュリティ基準に対するコンプライアンスを達成するため、管理者が責任 範囲におけるすべてのセキュリティ手続の正確な実行を保証している • 情報システムは定期的にセキュリティ実施基準への遵守状況をチェックされている 3.11.3 情報システム監査人は企業が次項を保証するためのプロセスを確立しているか検証すべきである。 • ビジネスプロセスへの混乱を招くリスクを最小化するために、運用システムのチェックを含む監査要件よ び監査活動が計画され、合意される • 誤用や情報漏洩を防止するため、情報システム監査ツールの利用が保護される 325 G40 セキュリティ管理業務のレビュー 4 監査プロセス 4.1 計画 4.1.1 情報システム監査人は、企業のリスク評価とリスク管理戦略に基づき、監査の対象範囲・目的・実施時期 を含めて、企業のセキュリティ管理の実践のレビューのための監査プログラムを準備すべきである。報告 方法については監査プログラムに明確に記載されるべきである。企業の種類・規模・利害関係者について 考慮すべきである。情報システム監査人は企業の使命・ビジネス目標・企業の情報資産・技術インフラ・セ キュリティ管理施策について、理解すべきである。 4.1.2 組織構造、特にセキュリティ管理施策の策定、周知、モニタリングに責任を有する主要メンバーの役割と 責任と、彼らの企業内のコンプライアンス状況の理解が必要である。他の主要なメンバーには情報の管理 者・オーナー・監督者が含まれる。 4.1.3 監査計画段階の主要な目的は、監査目的に到達し、高リスク領域に重点をおいたレビュー範囲を決めるた めに、企業が直面するセキュリティ関連の脅威とリスクを把握することである。 4.1.4 該当する場合には、検証結果を定量化するために、監査計画において適切な試査技法を検討すべきであ る。 4.1.5 前回の監査報告書が必要であり、個々の問題点につき、 マネジメントのアクションプランに基づいて解消度 合を評価すべきである。 5 業務のパフォーマンス 5.1 監査タスク 5.1.1 情報システム監査人は、企業のセキュリティ管理目標が適切に達成されているという保証を与えるために、 セキュリティ管理の実践と実装の詳細かつ独立したレビューを実施すべきである。 5.1.2 情報システム監査人は、そのような保証を与えるために、本ガイドラインに要点を記載したセキュリティ管 理の実践のすべての観点をレビューすべきである。 6 報告 6.1 報告の作成およびフォローアップ 6.1.1 監査報告書の原稿を作成し、関係者と協議すべきである。明確な証拠に裏づけされた問題点のみが含ま れるべきである。 6.1.2 報告はISACAガイドラインにしたがって取りまとめるべきであり、可能かつ適切であれば問題点を解決、 改善するための勧告とフォローアップ事項とともに、 マネジメントあるいはガバナンスを担う取締役会等に 提示すべきである。特に慎重に扱うべきセキュリティの不備については、報告の配布はガバナンスを担う取 締役会あるいは適切なレベルのマネジメントに限定すべきである。 6.1.3 上級マネジメントやガバナンスを担う取締役会等によって指示されたフォローアップ活動・アクションプラ ン・責任・目標期日・資源・優先度について合意すべきである。 7 適用開始日 7.1 本ガイドラインは2008年12月1日以降に開始されるすべての情報システム監査に適用される。 326 G41 セキュリティ投資利益率（ROSI） 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 328 2 ROSI‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 330 3 目標‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 334 4 勘案‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 337 5 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 338 G41 セキュリティ投資利益率（ROSI） 1 背景 1.1 基準との関連 1.1.1 基準S10『ITガバナンス』が述べている、IT監査・保証の専門家がレビューすべきは、 • IT部門が企業の使命、未来図、価値、目標、戦略と連携しているか否かであり、これは同時に評価すべき である。 • IT部門がビジネス（有効性と効率性）に期待されているパフォーマンスについて、はっきりと述べ、達成 度を評価しているか否かである。 • IT資源およびパフォーマンス管理プロセスの有効性であり、評価もすべきである。 1.2 COBITとの関連 1.2.1 個々の監査範囲に適用可能であるCOBITの中から最も関連する材料の選択は、特定のCOBIT ITプロセ スを選択し、COBITのコントロール目標と関連するマネジメントの実行を勘案して行う。IT監査・保証の専 門家が必要とするセキュリティ投資利益率（ROSI）に合わせるべく、最も関連し、選定され、採用されそう なCOBITのプロセスが、ここで主要・副次的なものに分類される。選定され、採用されるべきプロセスとコ ントロール目的は、特定の範囲と任務の権限次第で変化するかもしれない。 1.2.2 主要な参照： • PO1 IT戦略計画の策定 • PO3 技術手引きの決定 • PO5 IT投資の管理 • PO9 ITリスクの評価と管理 • DS3 パフォーマンスとキャパシティの管理 • DS6 費用の補足と配賦 • ME1 ITパフォーマンスのモニタリングと評価 • ME4 ITガバナンスの提供 1.2.3 副次的参照： • PO6 マネジメントの意図と手引きの周知 • AI1 コンピュータ化施策の明確化 • AI5I IT資源の調達 • ME3 規制に対するコンプライアンスの保証 1.2.4 ROSIに最も関連する情報要請規準情報要請規準： • 主：有効性、効率性、可用性、 • 副：機密性、インテグリティ、信頼性 1.3 ガイドラインの目的 1.3.1 企業は、ITセキュリティへの投資事例作成は益々魅力的だと考えている。ROSIの策定は、明らかに、ビジネ ス目標達成する企業にとって重大である。合理的な程度に正確なROSIの見積りを得るために、企業は、セ キュリティ要求事項とROSIの最も適切な測定方法を決定し、ROSIを測定する情報を収集する測定基準を 確立する必要がある。今日、事業体は自らにとってセキュリティの影響を無視することに包含されるリスクと その結果と同様、セキュリティ測定方法の重要性を認識している。決定権者は定期的にセキュリティ測定方 法の有効性を確保すべく、セキュリティ測定基準を計量、レビュー、手直しすることが求められている。加え て、内外および法的コンプライアンスはセキュリティ目標の継続的向上を維持することを必要としている。 328 G41 セキュリティ投資利益率（ROSI） 1.3.2 企業は適切なROSIを有効に達成するために、セキュリティ測定基準の価値提案を無視する余裕がない。 重要なのは、計量可能なユーザニーズに戦略的セキュリティ測定方法を策定し、有効な測定方法策定のた めに合意形成した取組みを具体化するロードマップを展開し、ROSIの継続的向上を確立するために定期 的な評価を提供することである。 1.3.3 IT監査・保証の専門家はROSIに対する価値提案をはっきりと理解しなければならない。ガイドラインは、 監査業務を実施中にROSIを見直すIT監査・保証の専門家に手引きを提供する必要があるというのが、こ の背景である。 1.4 ガイドラインの適用 1.4.1 本ガイドラインは基準S10『ITガバナンス』を適用する際に手引きを提供する。 1.4.2 IT監査・保証の専門家は上記基準の履行方法を決定する際にガイドラインを考慮し、適用に当たっては専 門家としての判断を用い、いかなる逸脱をも正当化する覚悟をすべきである。 1.4.3 本ガイドラインを適用するにあたり、IT監査・保証の専門家は他のISACA基準やガイドラインに関して本 ガイドラインを考慮すべきである。 1.5 リスク管理 1.5.1 情報資産の安全保証に責任のある人々と責任ある上級マネジメントの間で、企業の情報資産を管理するビ ジネスオーナとの協同の定期的リスク評価が展開されるべきである。とり分け、コントロール層である、全 社的ビジネスプロセスオーナのリスク評価は、コントロール環境の理解を得る際に、IT監査の専門家によ る評価の中で考慮されるべきである。例えば、ビジネスプロセスオーナにより実施されるリスク評価は、重 大な情報資産への定期的な再認証アクセスの予防コントロールの妥当性評価を含み、考慮されるべきで ある。 1.5.2 企業にとっての全てのリスクとその必要なリスク軽減コントロールプロセスを充分に理解していない可能性 があるセキュリティエンジニア／アドミニストレータと相俟って主題が大いに複雑化するかもしれないとい う固有リスクがある。例えば、情報資産に関わるセキュリティは、サーバコントロールに加えてネットワーク 伝達の中の種々の出入口で技術的コントロールを必要とするかも知れない。こうして、ネットワークセキュ リティのセキュリティ担当者は、サーバアクセスコントロールに関し、主要な知識を持つセキュリティアドミ ニストレータに次いで、セキュリティリスクの全てを充分に理解することが求められるかも知れない。こうし て、このリスク評価の中で固有なのは、全てのリスクが、充分に特定され、計量され、企業により可能なと ころまで軽減されてきたという主題のリスクである。従って、独立した評価は、全IT分野内の一連のセキュ リティコントロールに精通した種々の担当者から全てのリスクと必要な軽減コントロールを潜在的に特定 するために、必要とされるかも知れない。 1.5.3 独立した評価を遂行する責任のある監査人が、リスクレベルに相応なコントロールプロセスを充分に理解 したり、レビューしていないことに起因する固有な監査リスクがある。加えて、可能性があるのは、監査人 がサンプリングや必ずしもリスク領域の完全網羅に帰着しない規模要因の節約に基づく他の限定された 方法論を梃入れすることによるコントロールの妥当性と効率性に関して適切に結論づけない可能性がある。 こうして、 マネジメントは、監査は、監査人が全コントロールの妥当性に関し完全に特定し、テストし、結論 づけるということを保証していないということを喚起されるべきである。従って、監査人の評価の追加モニ タリングと独立した評価が、企業の情報資産の規模、複雑性、重要性により保証されるかもしれない。 329 G41 セキュリティ投資利益率（ROSI） 2 ROSI 2.1 序論 2.1.1 企業のROSIは、ハッカー、コンピュータウィルス、サイバーテロリストが主役として活躍している今日のサイ バー世界で重要な測定方法である。セキュリティは次の様なたくさんの質問への回答を導く企業にとって 優先事項になってきている。 • どのように企業は安全保証されているか？ • どれだけセキュリティは充分か？ • どのように企業は自らのセキュリティレベルが妥当な時期を知るのか？ • どのようにセキュリティ投資は説明されるべきか？ • セキュリティを実施する正しい金銭的、時間的投資とは何か？ • どのシステム構成要素や他の観点が先ず目標とされるべきか？ とり分け、ROSIの主要基盤は費用（例えば、ファイアウォール生成、障害費用、バックアップ費用、種々の 冗長化されたシステム要素）と、サイバーセキュリティ障害の可能性と帰結する損失を削減するという予防 的かつ修正的利益の比較である。 2.1.2 リスクの測定は、全IT関連影響があるときと同様、システム可用性、データインテグリティと情報の機密性 の中で予想される。 2.1.3 上級決定権限者は最低線のセキュリティの影響を理解したいと思う。セキュリティにどれだけ費用をつぎ 込むかという点に到達するため、彼らが知る必要があるのは、 • セキュリティ欠如がどれだけ企業に負担をかけるか？ • セキュリティ欠如が生産性に与える影響は何か？ • 大規模なセキュリティ障害はどんな影響をもたらすか？ • 費用対効果のある施策は何か？ • 施策は生産性に関してどんな影響をもたらすか？ • リスク発現は削減されているか？ 2.1.4 ROSIはITセキュリティに費やす有効性と効率性を測定する助けとなる重要パフォーマンス達成測定基準 である。その測定基準は、ITセキュリティ費用と生産性を、現在のパフォーマンス評価と計画のための簡明 かつ比較的測定基準に相関させる上意下達の測定方法である。 2.1.5 ROSIを特定することにより、企業は、ITセキュリティ費用の適切な水準と自らを守るために必要とされる セキュリティの適切な水準の両方を決定させてもらえる意味のある計画ツールを持つ。 2.1.6 適切に計画することにより、管理者は、一期間の間、企業に利益を与える運営費用とサイバーセキュリティ 活動の中の、この一期間の限界を超えて拡大する資本投下を区別すべきである。 2.2 ROSIの決定 2.2.1 費用の特定と配賦はROSI原理の展開にとり必須である。直接費は特別に特定のサイバーセキュリティ障 害に直接連結されうる。一方、間接費（例えば、多数の種類の障害に対する豊富なコントロールを提供す る侵入検知システム）は特定の障害に確実には連結され得ない。 2.2.2 次の詳述は、顕在費用と潜在費用の違いである。顕在費用は、例えば、ファイアウォールの開発・維持で は測定されうるが、潜在費用は、風評被害といった不確定な見積りのように、 「機会損失」と定義付けられ るかもしれない。見積りが容易かどうかに拘らず、顕在費用も潜在費用も何らかの測量可能な方法での費 用－利益分析に含まれるべきである。 330 G41 セキュリティ投資利益率（ROSI） 2.2.3 投資利益率(ROI)を決定するために、広く使われている方程式は、 ROI＝ 期待利益－投資費用 投資費用 2.2.4 ROSIに使用する幾つかの測量可能な方法がある。例えば、割引現在価値（NPV）というのは、異なる期間 に係る期待利益と費用を比較する。加えて、内部利益率（IRR）と呼ばれる一種のNPVは、投資のNPVが ゼロと等しくなる割引率を設定する。これら両方の方法は、増加するサイバーセキュリティ活動を受諾する か拒否するかの決定法則を提供する。 2.2.5 金銭の時間価値を考慮せず、予防費用に基づいた、表にあるROSIの計算は、図1に示される。 2.2.6 リスク発現は、一回の損失発現(SLE)の予想費用に期待年間発生率(ARO)を掛けて計算される。リスク発 現 ＝ SLE X AROSLEとAROの見積り方法は、過去の経験から内部的に引き起こされ、外部資源 から作図される測定基準に基づいている。実際の表は保険求償データ、学術的研究、独立した検査から創 出される。 2.2.7 アイダホ大学(米国)からの研究はROSIを次の様な事実の後の復旧費用に基づいて策定している。 ROSI＝R－年間損失期待値(ALE)、一方ALE＝（R－E）＋T、即ちROSI＝E－T 「R」は幾多の侵入から復旧するための年間費用、 「E」はセキュリティツールの使用の結果による金銭的 節約、 「T」は侵入検知ツールの費用である。 図1 ROSI計算 （金銭の時間価値を考慮せず、予防費用に基づいている） ＃ 単位(1,000) ⅰ 金銭的投資レベル ⅱ 無投資でのサイバーセキュリティ障害からの 全潜在的損失 ⅲ ⅰで言及されている各金銭的投資レベルごとの 損失可能性 ⅳ 選択肢 A B C D 0 650.00 1,300.00 1,950.00 10,000.00 10,000.00 10,000.00 10,000.00 .75 .50 .40 .33 各投資レベルごとの予想損失 (ⅳ)＝（ⅱ）X（ⅲ） 7,500.00 5,000.00 4,000.00 3,300.00 ⅴ 全予想サイバーセキュリティ費用＝投資費用＋ 障害からの予想損失（ⅴ）＝（ⅰ）＋（ⅳ） 7,500.00 5,650.00 5,300.00 5,250.00 ⅵ 投資レベルの増加からの増大する利益、予想損 失の減少、即ち、追加投資による（ⅳ）の値減少 N/A 2,500.00 1,000.00 700.00 ⅶ 投資レベルの投資増加の増加レベル、即ち、 ⅰ列の値の増加 N/A 650.00 650.00 650.00 ⅷ 投資レベルの増加の正味利益の増額 （ⅷ）＝（ⅵ）－（ⅶ） N/A 1,850.00 350.00 50.00 図1の単純な方程式は、 （リスク発現 X ％軽減されたリスク）－セキュリティ投資費用 ROSI＝ セキュリティ投資費用 2.2.8 この取組み方において、ROSIはRとALEとの差異より大きいか等しくなければならない。例として付録参照。 331 G41 セキュリティ投資利益率（ROSI） 2.2.9 2個の重要な要素は、提案されたセキュリティ投資により軽減されたリスクを分析する保険と投資の生産 性寄与を評価する要素である。保険は障害の可能性を削減するというより、障害が発生した場合、損失の 甚大化を削減する。保険要素は脆弱性、脅威、実在する情報資産の価値の包括的分析と現在ALEを測定 する防衛手段を必要とする。セキュリティ投資は理想的には、 （セキュリティインフラを向上して）リスクの 除去か、 （保険を購入して）リスクの移転か、 （潜在的リスクを吸収して）リスクの受容のいずれかか、ある いは、その3個の組合せを達成することを目指している。 図2 NPV使用によるROSI計算 ＃ 単位(1,000) ⅰ 金銭的投資レベル、t=0 ⅱ 選択肢 A B C D 0 650.00 1,300.00 1,950.00 無投資でのサイバーセキュリティ障害からの全 潜在的損失、t=1 10,000.00 10,000.00 10,000.00 10,000.00 ⅲ ⅰで言及されている各金銭的投資レベルごと の損失可能性 .75 .50 .40 .33 ⅳ 各投資レベルごとの予想損失 (ⅳ)＝（ⅱ）X（ⅲ） 7,500.00 5,000.00 4,000.00 3,300.00 ⅴ 各投資レベルでのt=1時の予想損失の現在価 値(ⅴ)＝(ⅳ)/（1＋k）註：k＝利子率 6,522.00 4,348.00 3,478.00 2,870.00 ⅵ 全予想サイバーセキュリティ費用現在価値＝ 投資費用＋障害からの予想損失の現在価値 (ⅵ)=（ⅰ)＋(ⅴ) 6,522.00 4,998.00 4,778.00 4,820.00 ⅶ 投資レベルの増加からの増大する利益(B)の 現在価値（PV）(B1/(1+k)＝予想損失のPVの 減少)（即ち、D列の値の減少） N/A 2,174.00 870.00 609.00 ⅷ 投資(C0)の増加レベル、投資レベルの増加、 即ち、ⅱの値の増加 N/A 650.00 650.00 650.00 ⅸ 金銭的投資レベルの増加の正味利益の増額 結果としてNPV=B1/(1+k)－C0(ⅸ)＝(ⅶ)－(ⅷ) N/A 1,524.00 220.00 41.00 2.2.10 時間価値が与えられると、金銭はいくつかの期間に亘り拡大する全ての費用―利益分析に算入されなけれ ばならない。図2はNPV方式を示している。 2.2.11 投資の増大する利益は予想損失における減少分の現在価値である。各投資レベルの予想損失の現在 価値は図2の「ⅴ」で与えられており、予想損失の現在価値での減少分は「ⅶ」で与えられている。加えて、 「ⅸ」で引き出される値は追加金銭的投資レベル（例えば、A列からD列参照）のNPVを表している。従っ て、最適投資レベルを見出すために、投資増額のNPVがプラスである限り、投資は増加し続ける。 2.2.12 金銭の時間価値を考慮しない、表中のROSIの計算は、予防費用に基づいている。その取組み方から明ら かなのは、ROSIを決定するには、企業は、意味のある価値を特定し抽出する反復可能で一貫性のあるセ キュリティ測定基準を持たねばならないということである。 332 G41 セキュリティ投資利益率（ROSI） 2.3 セキュリティ測定基準 2.3.1 セキュリティ測定基準は、意思決定を促進し、関連するパフォーマンス関連データの収集、分析、報告を通 してパフォーマンスと説明責任を改善するように設計された測定方法である。セキュリティ測定基準は、企 業が、セキュリティ防衛の障害時に起きる、風評被害、情報や金銭の盗難、業務中断といったリスクを削減 したり、管理したりするために取る処置（およびそれら処置の結果）に集中している。セキュリティ測定基 準プログラムの開発や実施のために第一に考えることは次の様なものである。 • 測定基準はパーセント、平均、数値のような定量的情報を産み出さなければならない。 • データに裏打ちされた測定基準が容易に使用可能でなければならない。 • 反復可能なプロセスだけが測定のために考慮されなければならない。 • 測定基準は、パフォーマンスを補足し、資源を指図するのに役立たねばならない。 • 測定基準は、高価ではなく、収集に手間がかかるべきではない。 2.3.2 セキュリティ測定基準は、次の様な、さまざまな形式でもよい。 • 実施測定基準－セキュリティ方針の実施を測定する • 有効性／効率性測定基準－セキュリティ施策の結果を測定する • 影響度測定基準－セキュリティ事象による業務への影響度を測定する 現実的に獲得され、役立つ測定基準形式は、企業のセキュリティ計画とコントロールの実施次第である。 ある期間に亘り、測定基準を集積する焦点はコトロールの成熟化とともに移っている。 2.3.3 データ収集はセキュリティ測定基準の大変重要な側面である。データ収集で考慮されるべき段階は、 • データ収集、分析、報告の責任を含んだ測定基準の役割と責任 • データ収集のための聴聞 • 収集、分析、報告のプロセス • 企業内の全部門との調整 • データ収集と追跡ツールの生成や選択と、必要に応じた修正 • データ収集、統合、保管、データ分析用形式への仕分け、報告 • 測定基準概況報告形式 • 差異分析、原因特定、是正処置 2.3.4 一般的セキュリティ測定基準としては、 • 最低限防衛範囲（対ウィルス、対スパイウェア、ファイアウォール、等）－企業が、基本的な情報セキュリ ティ脅威からいかにうまく防御されているかを測定する • パッチ潜伏期間－企業においてパッチ投入と成功裏な展開との間の時間。これは、会社のパッチ訓練 と事故への対応能力の測定基準である。 • パスワード強度－悪いパスワードを削減する。潜在的弱点を特定し、破られ難い強いパスワードの使用 を推進する • プラットフォーム コンプライアンス スコア－ハードウェアを受容しうる基準に合わせる • 合法的e-メールトラッフィク分析－入出トラッフィク量、トラフィクサイズ、企業内外のトラフィク流動形 式を分析する • アプリケーション リスク指数－潜在的リスクを高、中、低に分類する一助となる 333 G41 セキュリティ投資利益率（ROSI） 2.4 情報セキュリティでの最適投資：ゴードン－レオブ モデル 2.4.1 メリーランド大学(米国)のローレンスA.ゴードンとマーチンP.レオブは所与の情報資産セットを保護するた めの最適な金銭的投資を特徴付ける経済的フレームワークを提唱した。そのモデルは、一期間モデル内で の情報セットを保護する方向に企業投資の最適金額を決定する。所与の潜在的損失にとって、情報資産 を保護するために費やされる最適金額は必ずしも情報セットの脆弱性とともに増加しないし、情報セット の脆弱性と共に増加することもないし、中で増加することもないことが示されている。加えて、そのモデル は、会社が情報資産保護のために費やすべき金額は、一般に予想損失のほんの僅かな部分であるべきで あることを示している。 2.4.2 情報セットは次の3個のパラメータにより特徴付けられている。 • λ－障害発生を条件とした金銭的損失 • t －脅威発生可能性 • v －一旦具現した脅威（即ち、攻撃）が成功裏に終わる可能性として策定される、脆弱性 その3個のパラメータが、実世界においては、時を超えて変化しうるとは言っても、ゴードン－レオブ モデ ルは事前見積り定数と仮定する。 ゴードン－レオブ モデルは関数S(z,v)は、脅威の実現が条件付けられ、企業が、情報セットを保護するた めに「z」という情報セキュリティ投資を実施したという前提の下、脆弱性「v」のある情報セットが障害を受 けるという可能性を表示している。関数S(z,v)はセキュリティ障害可能性関数として参照される。殆んど全 ての経済モデルに共通しているように、関数S(z,v)は、充分に連続であると仮定され、継続的に、特に2回 区別されうるものとして充分に役割を果たしている。 一般理論に加えて、ゴードン－レオブは、数種のセキュリティ障害可能性関数を研究した。 ひとつは：S(z,v)＝vAZ+1 パラメータ「α」(>0)が情報セキュリティの生産性の測定方法である場合、最適化問題に対する閉鎖式施 策は、情報セキュリティ投資から得られる予想正味利益(ENBIS)を最大化するということになる。ENBIS の方程式は：ENBIS＝｛v－S(z,v)｝tλ－z 最適的投資の方程式は： z＝z*(v)＝ ln｛－1/（avtλlnv）｝ a ln v 2.4.3 モデルには2個の重要な制限がある－損失「λ」は定数と考えられ、投資「z」は連続している。 但し、現実には、損失は定数ではないし、投資は不連続である。 3 目標 3.1 監査 3.1.1 ROSIへの監査取組みが道筋を付けられるべき方向は、 • 企業全体や企業内のセキュリティ適用範囲として特定された計画や事業にとって充分に策定されたセ キュリティ要求事項の可用性を確保する • 費用としてセキュリティの重大な影響に焦点を当てつつ、個々のビジネス単位や企業全体により達成さ れなければならないビジネス達成目標を確立する • システムの脆弱性、可用性、信頼性に対するマネジメントや業務ユーザの認識 • セキュリティ目標に合わせた費用利益と有効性という意味での分析技術と業務効率 334 G41 セキュリティ投資利益率（ROSI） 3.1.2 セキュリティに対する従業員／ユーザの感覚を理解することは、セキュリティ投資のための重要な勘案であ り、これを達成する一つの方法は、従業員の検査を通すことである。従業員の検査は、適切に解釈されねば ならないし、検査得点と財務的パフォーマンスとの直接相関関係を持っているべきである。検査は概算定 量的回答や定量値を包含する回答となる質問を尋ねるべきである。例えば、毎日どれだけのスパムメールを 受けているか（0-10、10-30、30-50、50超）？とか、ファイルサーバが10分超使用不能になる頻度はどれ くらいか（毎日、週一、月一、滅多にない）？反復しうる一貫性のあるやり方でリスクとその発現を定量化す ることは重要である。これは、価値提案の外部測定とともに、有効な検査と生産性とセキュリティの得点シ ステムを通して可能である。情報セキュリティ監査人は、可能ならば、内部検査を見直すべきである。 3.1.3 中断時間の評価は、セキュリティ事故の間の喪失した生産性の重要な事後分析を提供しうる。生産性の 喪失はまたセキュリティ施策のROIを計算する際に勘案されなければならない。図3は生産性に影響を与え る平均中断時間と要素を示している。 図3 生産性と平均中断時間に影響を与える要素 問題 平均中断時間（分） アプリケーションとシステムの障害 10 Ｅ－メールフィルタリング、仕分け、スパム 15 周波帯幅効率性と仕事量 10 非効率かつ無効なセキュリティ方針 10 セキュリティ方針の強制 10 ITに対するシステム関連の拡張と改良 10 基本ソフトとアプリケーションのセキュリティパッチ 10 不安定かつ非効率なネットワークトポロジー 15 ウィルス、ウィルス走査 10 ワーム 10 トロイの木馬、キーロガー 10 アパイウェア、システム追跡者 10 飛出し広告 10 互換性問題－ハードウェアおよびソフトウェア 15 許諾に基づくセキュリティ問題（ユーザ／通行許可） 15 ファイルシステム無秩序化 10 信頼できないかアクセスできないデータ 15 ハッキングされたか盗まれた情報とデータ 15 バックアップ／保存 15 アップリケーション使用問題 15 出典：ソネンライチ、ベス；「セキュリティ投資効率(ROSI)：実用定量モデル」、情報技術の調査と実践ジャーナル、 38巻、No.1、2006年2月、オーストラリア コンピュータ ソサエティ出版、オーストラリア、2006年 3.1.4 IT監査・保証の専門家は、失われた生産性がリスク発現の意味ある見積りを提供する数多くの方法があり、 そのどれもが、ROSI計算に使用され得るということを認識すべきである。 335 G41 セキュリティ投資利益率（ROSI） 3.1.5 企業にとってROSIを正当化するために軽減されたリスクを計量することは重要である。正常な環境下、セ キュリティ施策は、いかなる有形価値を直接創出することがなく、損失を防ぐのである。 防がれた損失は企業にとり不知の損失かもしれない。例えば、企業の侵入検知システム(IDS)は、今年10 個の侵入成功例に対し、昨年20個の侵入成功例を示していたかもしれない。それは、新セキュリティ施策 が実装されたからなのか、ネットワークへのハッカーの攻撃が減ったからなのか？ 図4 セキュリティ施策による生産性損失 問題 平均中断時間（分） アプリケーションとシステムの障害 10 周波帯幅効率性と仕事量 10 過剰制限のセキュリティ方針 10 セキュリティ方針の強制 10 ITに対するシステム関連の拡張と改良 10 基本ソフトとアプリケーションのセキュリティパッチ 10 ウィルス走査によるファイルダウンロードの混乱 10 互換性問題－ハードウェアおよびソフトウェア 15 多過ぎるパスワード／許諾によるセキュリティ問題 15 出典：ソネンライチ、ベス；「セキュリティ投資効率(ROSI)：実用定量モデル」、情報技術の調査と実践ジャーナル、 38巻、No.1、2006年2月、オーストラリア コンピュータ ソサエティ出版、オーストラリア、2006年 3.1.6 企業が、正確なROSIに到達するセキュリティ施策の失敗を原因とする損害を捕捉することもまた重要であ る。セキュリティ施策は単独では作用しない；他の施策の存在と有効性はセキュリティ施策のパフォーマン スに大きな影響を持っている。使用実績のある最も有効なセキュリティ施策は、生産性に受け容れがたい 影響があるため、めったに実施されない。図4はセキュリティ施策の実施による生産性損失を示している。 3.1.7 IT監査・保証の専門家は、セキュリティ施策の費用は生産性にかかわる施策の影響を含めねばならないと いう事実を考慮すべきである。というのは、むしろこの数字は提案された施策の実行可能性を左右するの に充分大きいからである。セキュリティ施策は、ハッカーが自分たちの周りで作業する方法や新しいリスク を創出するにつれ、有効性が低下してきている。それゆえ、企業がセキュリティのパフォーマンスを定期的 に評価するシステムを持つことは重要である。IT監査・保証の専門家はその種の評価報告と、それについ て取られた処置をレビューすべきである。 3.1.8 セキュリティ施策の初期設計と展開を離れて、企業が実行された施策を管理するよいプロセスを持ち、セ キュリティは有力な実習であると悟るのは同様に必須である。例えば、IDSは新しいウィルス定義にて頻繁 に更新される必要があり、セキュリティ方針は定期的にレビュー、評価されなければならなく、ソフトウェア のパッチは定期的に更新、インストールされなければならず、ファイアウォールはIT基盤内の成長と変化を 反映して調整されなければならない。IT監査と保証の専門家は実施されたセキュリティ施策の持続計画を 見直すべきである。 3.1.9 IT監査・保証の専門家は、企業がセキュリティ施策を次のように有効に実施する際に直面する努力目標も また認識すべきである。 • 熟練労働力の利用 • 訓練労働力の保持 • セキュリティパフォーマンスの24時間7日間のモニタリング • 直近の攻撃、脆弱性、パッチ、技術進歩、上級化、セキュリティ施策の更新 336 G41 セキュリティ投資利益率（ROSI） 4 勘案 4.1 監査 4.1.1 各種のROSIモデルがあるが、一モデルで全ての企業に合ったものはない。モデルの適用性は企業ごとに違 うし、次のような種々の勘案次第である。 • 発現度 • 脆弱性の性質 • 危険の型 • 補完的コントロールの欠如／弱点 • 地理的位置－戦争、自然の気まぐれ、その他コントロールできない事象のような外的要因の脅威 4.1.2 企業は、セキュリティ障害や失効のためのデーダ収集に関する充分識別されたプロセスを持たねばならな い。データ捕捉は企業内で発生する事象に限定されてはいけないし、自らの体制を超えて拡張されるべき であり、その際勘案するのは、 • ビジネスの性質／型 • ビジネスモデル（会社と会社、会社と顧客、等） • ITにより統治される重大なビジネス部門 • 競争相手と同業種のITセキュリティ戦略 そのようなデータは所有され、適切に分析され、その結果はトップマネジメントによって見直される。 4.1.3 セキュリティ投資は、セキュリティ要求事項、リスク評価、製品パフォーマンス、納入業者サービスレベルア グリーメント、もっとも重要なのものとして、包括的ビジネス目標に対する一連のセキュリティ計画を適切に 分析した後、実行される。 4.1.4 充分な保険なくして、セキュリティは完了しない。企業は適切な保険によって充分に保護されるべきである。 4.1.5 セキュリティは、事業を差止めるものとしてではなく、保護するもの、賦活するものとして考えられねばなら ない。セキュリティ費用の正当化は、技術が、ビジネス、セキュリティ方針、手続きがビジネス達成目標と直 接に連携させ、セキュリティ技術を管理・維持することが結果的にセキュリティ投資の最大価値となるとい うことを確保することである。 4.1.6 信用がセキュリティの最高型である。企業は、企業の資産を保護し、障害が予期される時はいつでも、事前 に早期警告をしてくれる、重要なステークホルダーとのパートナー化により「信用企業」に進化すべきであ る。 4.1.7 セキュリティ方針と手続きは、適用さるべき法令の要求事項に合致すべきである。 337 G41 セキュリティ投資利益率（ROSI） 5 適用開始日 5.1 本ガイドラインは2010年5月1日以降開始される全ての情報システム監査に適用される。 付録 A1. 例 ROSI＝ 会社Aがウィルス攻撃を以前に経験した。会社は、ウィルス攻撃による損害の平均費用と生産性の損失が US$25,000であると見積もる。現在、会社Aは年4回の攻撃を受け、US$25,000かかるウィルス走査施 策を実施することにより4回の攻撃のうち、3回を止めることを期待している。ROSIは次の例で計算される。 （リスク発現 X ％リスク軽減）－セキュリティ投資費用 セキュリティ投資費用 リスク発現：US$25,000／1回 X 4回／年 ＝ US$100,000 施策により軽減されたリスク：4回のうち、3回の攻撃、即ち 75% セキュリティ投資の費用＝US$25,000 ROSI＝ （US$100,000 X 75％）－US$25,000 US$25,000 ＝200% 例の中で、セキュリティへの投資は価値があることがわかる。しかし、種々の仮定があり、それゆえ、現 実は違っているかもしれない。例えば、3回の軽 減された攻撃が夫々US$5,0 0 0で、4回目の攻撃が US$85,000だとしたら、どうであろう？ 平均はUS$25,000だが4回目の攻撃は費用がかかっている。 A2. 例 ROSI＝R－ALE、一方ALE＝（R－E）＋T 即ち、ROSI=E－T 会社Aはインターネットに関わる取引を保護するために安全なウェッブサーバをインストールしている。 ウェッブサーバの費用はUS$100,000である。会社は、過去に受けた３個の主たる侵入に基づき、復旧す べき年間費用をUS$500,000、ウェッブサーバをインストールすることにより得られる節約の見積もりを US$250,000と見積もる。この例では、 • ALE＝（$500,000－$250,000）＋$100,000＝$350,000 • ROSI＝$500,000－$350,000＝$150,000 参照 ゴードン、ローレンスA． ；マーチン P．レオブ；情報セキュリティ投資の経済学、情報システムセキュリティ 上のACM取引、2002年11月、p.438-457 マツウラ、カンタ；情報セキュリティとコンピュータネットワークの経済学：学際の調査と投資の統合最適 化の提案、東京大学産業科学研究所、日本、2003年 国立基準技術研究所(NIST)、情報技術システムのセキュリティ測定基準ガイド、米国、2003年 ソネンライチ、ベス；「セキュリティ投資利益率(ROSI)：実用計量モデル」、情報技術の研究と実践ジャーナ ル、38巻、NO.1、2006年2月、オーストラリア コンピュータ ソサエティ出版、オーストラリア、2006年 338 G42 継続的保証 1 背景‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 340 2 継続的保証・監査・モニタリング‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 341 3 計画策定‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 342 4 リスク管理‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 342 5 継続的監査の導入‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 342 6 継続的モニタリングの監督‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 344 7 継続的監査業務のパフォーマンス‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 346 8 報告‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 348 9 適用開始日‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 348 10 参照‥ ‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 349 G42 継続的保証 1 背景 1.1 基準との関連 1.1.1 基準S5『計画策定』は、 「IT監査・保証の専門家は監査の目的を満たし、関係諸法規と当該分野の諸監 査基準に準拠するよう、情報システム監査の範囲を定めた計画を策定すべきである」と述べている。 1.1.2 基準S6『監査業務のパフォーマンス』は、 「監査の過程において、IT監査・保証の専門家は監査の目的を 達成するために、充分であり、信頼できる、関連付けられた証拠を得るべきである」と述べている。監査発 見事項と監査結論は、この証拠を適切に分析し、解釈することにより裏付けられるものである。 1.1.3 基準S7『報告』は、 「IT監査・保証の専門家は、報告結果を裏付ける充分かつ適切な監査証拠を得るべき である」と述べている。 1.1.4 基準S14『監査証拠』は、 「IT監査・保証の専門家は、監査結果の基となる合理的な結論を導き出すため に、充分かつ適切な監査証拠を得るべきである」と述べている。 1.2 ガイドラインとの関連 1.2.1 ガイドラインG2『監査証拠の要求』は、IT監査・保証の専門家に対し、情報システム監査で使用される監 査証拠の型式と充分性に関し、手引きを提供している。 1.2.2 ガイドラインG3『コンピュータ支援監査技法（CAAT）の使用』は、IT監査・保証の専門家に対し、種々の 監査手続きを遂行するに当たり使用され得る多種のコンピュータ支援ツールや技術に関し、手引きを提供 している。 1.2.3 ガイドラインG10『監査サンプリング』は、IT監査・保証の専門家に対し、監査サンプルの設計と選定およ びサンプル結果の評価に関し、手引きを提供している。 1.3 COBITとの関連 1.3.1 個々の監査範囲に適用可能であるCOBITの中から最も関連する材料の選択は、特定のCOBIT ITプロセ スを選択し、COBITのコントロール目標と関連するマネジメントの実行を勘案して行う。 IT監査・保証の専門家が必要とするITガバナンスに合わせるべく、最も関連し、選定され、採用されそうな COBITのプロセスが、ここで主要なものとして分類されている。選定され、採用されるべきプロセスとコン トロール目的は、特定の範囲と任務の権限次第で変化するかもしれない。 1.3.2 主要な参照： • DS5 システムセキュリティの確保 • ME2 内部統制のモニタリングと評価 • AI1 コンピュータ対応策の明確化 1.3.3 最も関連する情報要請規準： • 主：有効性、効率性、機密性、インテグリティ • 副：可用性、コンプライアンス、信頼性 1.4 ガイドラインのために必要なもの 1.4.1 伝統的に、コントロールのテストは、しばしばビジネス活動が起きてしばらく、遡及する循環的な基盤に基 づき、実施されてきた。テスト手続きはしばしばサンプル手法に基づいており、方針、手続き、承認、調停の レビューのような活動もあった。継続的保証は、コントロールやリスク評価を自動的にもっと頻繁に遂行 するために用いられる方法である。この手法の主な美点は、即時のフォローアップや矯正ができるようにな る差異や弱点に対する時宜を得た報告となる、コントロールとリスクの知的効率的継続的テストである。 340 G42 継続的保証 1.4.2 コンセプトとしての継続的保証は厳密にはIT監査に限定されないが、IT監査・保証の専門家は、しばしば 顧客のためや企業内の継続的保証プロセスやシステムを開発、実施、保守することを求められる。IT監 査・保証の専門家は、継続的保証プロセスとシステムを成功裏に実装するために必要な、ビジネスと技術 的熟練と経験の独特の組合せを梃子にすることにより価値を付加し、利害関係者がからんでいる広範囲 なビジネスとITに従事することができる。 1.4.3 本ガイドラインはIT監査・保証の専門家に対し、企業内の継続的保証プロセスとシステムの計画、運用、 保守の間、関連するIT監査と保証基準を適用する際に手引きを提供する。 2 継続的保証・監査・モニタリング 2.1 CAATと継続的保証 2.1.1 コンピュータ支援監査技法(CAAT)は、一般的監査ソフトウェア、テストデータ作成ソフト、統合テスト設 備、コンピュータ監査ソフトウェア、専用監査システムソフトウェアといった、あらゆる自動監査技術である。 2.1.2 継続的保証は、途切れることのないモニタリング手法である。マネジメントの継続的モニタリングのIT監 査・保証の専門家による監督と、 マネジメントとIT監査・保証の専門家が継続的にコントロールとリスクを モニタリングし、技法を使って選択的監査証拠を集積することができるCAATを使用するIT監査・保証の 専門家の継続的監査手法との組合せである。 2.1.3 継続的保証は、IT監査・保証の専門家による時宜を得た報告を提供するために使用され得るプロセスで あり、高リスク、高物量のペーパーレス環境で使用するのに役立つ。継続的保証は、IT監査・保証の専門 家が効率的かつ有効なやり方でコントロール環境を評価するのに重要なツールであり、監査範囲を拡大し、 データ分析がより徹底し、一貫性を保ち、リスクを削減することになる。 2.2 継続的監査 2.2.1 継続的監査は、IT監査・保証の専門家がもっと頻繁にコントロールとリスク評価を実行するために使用 する方法である。それは、IT監査・保証の専門家がコントロールとリスクを継続的にモニタリングできる CAATを使用する方法である。本手法によりIT監査・保証の専門家はコンピュータを通して選択的監査証 拠を収集することができる。 2.3 継続的モニタリング 2.3.1 継続的モニタリングは、方針、手続き、業務プロセスが有効に前向きに運営されているか否かをモニタリ ングするマネジメントプロセスである。マネジメントが展開する継続的モニタリングプロセスに加えて、IT監 査・保証の専門家により実施される継続的監査は、適切であれば、 マネジメントに移管されるかもしれない。 その場合、 マネジメントによって実施される継続的モニタリング手続きになる。IT監査・保証の専門家によ り実施される継続的監査とともに、 マネジメントが継続的モニタリング手続きを使用すれば、コントロール 手続きが有効であり、意思決定のために生成された情報が関連付けられていて信頼できるという保証のた めの要求を満足させる。 341 G42 継続的保証 3 計画策定 3.1 継続的監査に選択される範囲 3.1.1 継続的監査を使用してレビューする範囲を選ぶ活動は、年間監査計画の開発の一部として統合されるべ きであり、すでに開発済みであれば、リスク管理フレームワークを利用すべきである。標準周期に従ってレ ビューを予定するというよりは、レビューの頻度が、範囲や業務プロセスのリスク因子に基づいてなされる べきである。IT監査・保証の専門家は、継続的監査の優先範囲を決定する時は、次を勘案すべきである。 • リスクに基づいてレビューされ、優先順位付けられるべき重要な業務プロセスを特定する • 開発済みならば、企業のリスク管理フレ－ムワークをレビューする • 企業の、範囲をレビューする以前の経験を勘案する • 特定されたリスク範囲にとって継続的監査データの可用性とインテグリティを確かめる • 時宜を得た結果報告が企業にとって大いなる価値がある場所を勘案し、レビューのために特定された範 囲を優先順位付けする • レビュー範囲のレビュー頻度を決定する • 実行権限に包含されるかもしれない範囲の監査目的をレビューするようにする 4 リスク管理 4.1 リスク特定・評価 4.1.1 継続的監査はIT監査・保証の専門家がリスクを特定・評価し、企業内の変化に対応する知的かつ有力な 限界を確立する一助となる。また、継続的監査は、特定監査の目的と同様、年間監査計画の開発に貢献 し、全監査世界のリスク特定・評価を裏付ける。IT監査・保証の専門家は、既に開発済みならば、企業の リスク管理フレームワークをレビューすべきである。 5 継続的監査の導入 5.1 監査業務計画策定 5.1.1 継続的監査を成功理に実施するには、 マネジメントも含め、利害関係者の買戻しと、最も重大な業務シス テムに最初に取組む途中段階の手法を必要とする。次の活動は、継続的監査の使用を開発・裏付ける時、 計画され管理されなければならない。 • 適用範囲を優先順位付け、適切な継続的監査手法を選定する • 重要な顧客人材を確保する • 適切な分析ツールを選定する。これは社内手続き書か納入業者提供ソフトウェアとなろう • 継続的監査手続きを開発し、コントロールを評価し、欠陥を特定する • 継続的監査手続きの適用頻度を決定する • 出力に必要なものを策定する • 報告プロセスを開発する • 関連部署とITマネジメントとの関係を確立する • データインテグリティを評価し、データを準備する • 資源の必要事項、例えば、人材、処理環境（企業のIT設備やIT監査設備）を決定する • マネジメントが自らのモニタリング役割（継続的モニタリング）を遂行する範囲を理解する 342 G42 継続的保証 5.2 マネジメントの支持獲得 5.2.1 一旦、継続監査の目的が策定されたら、上級マネジメントの支持が獲得されるべきである。上級マネジメン トは、結果が報告される方法、時期と同様、必須条件、特にアクセス必要条件について報告されなければ ならない。もしこれがなされれば、異例取引が特定され、 マネジャーが説明のために接触される時、継続的 監査活動の合法性は問題視されない。 5.2.2 マネジメントからの支持は、継続的監査範囲の権限承認にとともに得られる。支持はまた、組織化されて いるなら、監査委員会からも得るべきである。継続監査の権限により規定されている期間はいつも単独の 業務で規定される期間より長いし、その期間が一年に及ぶ場合でも、異常ではない。 5.3 被監査人との調整 5.3.1 詳細取引ファイルのようなデータファイルは、しばしば短期間保持されるだけである。それ故、IT監査・保 証の専門家は、適切な監査時間枠を包含するデータの保持を調整すべきである。 5.3.2 企業のIT設備、プログラム／システム、データへのアクセスは、企業の生産環境への影響を最小限にする ために必要な期間の充分前広に準備されるべきである。 5.3.3 IT監査・保証の専門家は、生産プログラム／システムへの変更が継続的監査手続きの使用時に与える影 響を評価すべきである。その時、IT監査・保証の専門家は、自分たちが使用したプログラム／システムと データのインテグリティと同様、継続的監査手続きのインテグリティと有用性への、これら変化の影響を 勘案すべきである。 5.4 継続的監査手続きの開発 5.4.1 IT監査・保証の専門家は、適切な計画策定、設計、テスト、処理、文書のレビューを通して、継続的監査手 続きのインテグリティ、信頼性、有用性、セキュリティの合理的保証を得るべきである。これは、信頼が継 続的監査手続きに置かれる以前になされるべきである。IT監査・保証の専門家は、システム開発ライフサ イクルが継続的監査手続きの完全性と正確性を確保するために、先行してきた、ということを説明できる べきである。 5.5 継続的保証テストの範囲 5.5.1 IT監査・保証の専門家によって、コントロールとリスクの詳細テストが、実施されなければならない範囲が 決定されるべきである。この決定における主要因子はコントロール環境とモニタリング活動の充分性であ る。IT監査・保証の専門家は、開発済みであるなら、企業のリスク管理フレームワークにより取組まれるコ ントロールフレームワークと範囲を審査すべきである。マネジメントが、継続的モニタリングを含め、コント ロールとリスクを評価する充分に確立され機能するプロセスを持っているならば、IT監査・保証の専門家 は、報告されているコントロールとリスク水準にもっと信頼を置くことができる。しかしながら、もしそのプ ロセスが充分でなければ、IT監査・保証の専門家は、必要性から、もっとしきりにコントロールとリスクの 詳細な評価を実施することが求められる。 5.6 テスト頻度 5.6.1 IT監査・保証の専門家は、継続的監査テストの時期、種類、範囲を設定する時、継続的監査の目的、企業 のリスクに対する関心、 マネジメントの継続的モニタリングの水準と性質、企業のリスク活動を勘案するべ きである。IT監査・保証の専門家は、リスクに優先順位付けし、継続監査を初めて実施する時の高リスク 範囲や重要コントロール点のみを選定するべきである。 343 G42 継続的保証 5.6.2 次の段階は、継続的監査テストが実施される頻度を決定することである。継続的監査活動の頻度は、詳 細取引の同時、若しくは殆ど同時のレビューから、詳細取引の定期的分析、任意抽出、要約データまで及 ぶ。頻度は、検査されるシステムとプロセスと関連するリスク水準だけでなく、 マネジメントにより実施さ れるモニタリングと入手可能な資源の充分性次第である。主要コントロールのある重要なシステムは取引 データの同時分析次第かもしれない。年間監査計画を裏付けるリスク評価は四半期毎に実施されるかもし れない。しかし、個々の監査を裏付けるリスク評価と監査を推奨するものの追跡は、特別に発生するかも しれない。継続的監査手続きを実施する頻度はリスク次第であるべきである。頻度を議論する時の重要な 勘案は継続的監査テストの自動化がリスク評価やコントロールの検証を実施する費用を低下させるという ことである。 5.6.3 最後に、継続的監査が実施される頻度や時期を決定する時、IT監査・保証の専門家は、法的要求事項だけ でなく、 マネジメントが曝されたリスクや潜在的影響に取り組む度合をも勘案すべきである。マネジメントが コントロールの継続的モニタリングシステムを実行した時、内外の監査の専門家はこれを考慮し、詳細コン トロールテストを削減するために、彼らが継続的監査プロセスに依拠する度合を決定することができる。 5.7 データインテグリティとセキュリティ懸念 5.7.1 データ分析の情報を抽出するために、継続的監査手続きが使用される場合、IT監査・保証の専門家は、情 報システムのインテグリティとそのデータが抽出されたIT環境を検証すべきである。 5.7.2 要注意のプログラム／システム情報と生産データは安全に保持され続けられるべきである。IT監査・保証 の専門家は、機密性を確保するためにセキュリティの適切な水準でプログラム／システムと生産データを 防衛するべきである。その時、IT監査・保証の専門家は、データ保有企業と関連法令によって必要とされ る機密性とセキュリティの水準を勘案すべきである。 5.7.3 IT監査・保証の専門家は、継続的監査手続きの進行中のインテグリティ、信頼性、有用性、セキュリティの ために、供給すべき適切な手続きの結果を使用し、文書化すべきである。 例えば、これは、承認された変更だけが継続的監査手続きに対し行われたということを決定するために、 プログラム保守とプログラム変更のレビューを含んでいる。 5.7.4 継続的監査手続きが、IT監査・保証の専門家のコントロール下にない環境に存在する時、コントロールの 適切な水準は、継続的監査手続きへの変更を特定するのに効果があるべきである。継続的監査手続きが 変更される時、IT監査・保証の専門家は、継続的監査手続きに信頼が置かれる前に、適切な計画策定、設 計、テスト、処理、文書のレビューを通して、それらの、インテグリティ、信頼性、有用性、セキュリティの保 証を獲得すべきである。 6 継続的モニタリングの監督 6.1 継続的モニタリング 6.1.1 継続的モニタリングは、 マネジメントが方針、手続き、業務プロセスが有効に作動していることを確保する ために適所に置くプロセスを指している。継続的モニタリングは、典型的にコントロールの充分性と有効 性を評価するマネジメントの責任を言及している。マネジメントが継続的にコントロールをモニタリングする ために使う多くの技法は、IT監査・保証の専門家により継続監査の中で実施されるかも知れない技法に 似ている。継続的保証もまたマネジメントのモニタリングの有効性をモニタリングしている。 344 G42 継続的保証 6.1.2 継続的モニタリングの要点は、そのプロセスが、有効なコントロール環境を実施、保守する責任の一部とし て、 マネジメントにより、所有され実施されるべきである。マネジメントは内部統制に責任があるので、コント ロールが設計通り作動しているかどうかということを、進行中に決定する方法を持つべきである。同時にコ ントロール問題を特定し、是正することを可能にすることにより、包括的なコントロールシステムが改善さ れ得る。企業への典型的な付随的恩恵は誤謬と不正の事例が削減され得ることである。マネジメントのモ ニタリングとリスク管理活動の充分性と、IT監査・保証の専門家がコントロールの詳細テストとリスクの評 価を実施しなければならない程度は正反対の関係にある。継続的監査へのIT監査・保証の専門家の手法 と量はマネジメントが継続的モニタリングを実施した程度次第である。 6.2 マネジメントの責任 6.2.1 マネジメントは、方針、手続き、業務プロセスといった主要コントロールの運用が、効率的、有効に意図さ れた事業目的に適っていることを確保するために継続的にコントロ－ル環境をモニタリングするプロセス とシステムを実行する責任がある。 6.2.2 マネジメントがコントロール環境の継続的モニタリングを実施するにあたって使用する可能性のある各種 技法は、 • ビジネスプロセス内でのリスクとコントロールポイントの策定 • ビジネスプロセスのためのコントロール目的と主張の特定 • 特定のコントロール目的に取組む手動と自動のコントロールの設計 • 手動と自動のコントロールの運用テスト • 正常なビジネス取引に渡る手動と自動の運用モニタリング • マネジメントコントロールにより特定されたコントロール例外処理の調査 • 検知されたコントロール弱点と取引誤謬を是正する適切な処置 • ビジネスプロセス変更を反映しての、手動と自働のコントロールの更新、再テスト 6.3 IT監査・保証の専門家の責任 6.3.1 IT監査・保証の専門家は、組織化されているならば、監査委員会と他の主要利害関係者に対し、継続的モ ニタリングプロセスとシステムが、特定のコントロール目的に取組む効率的かつ有効に作動しているという、 監督と保証を提供することが求められている。 6.3.2 IT監査・保証の専門家は、 マネジメントの継続的モニタリング活動の運用を監督するために使用するかも 知れない技法は、 • 主要継続的モニタリング活動に関連する、文書化、システム開発ライフサイクル、訓練、論理アクセス、 変更コントロールといった、継続的モニタリングメカニズムの開発に係るコントロールのレビューとテスト • マネジメントの継続的モニタリング活動から得られたものを、IT監査・保証の専門家により実行される 同様の継続監査手続きへのなぞらえ。例えば、 マネジメントレポートが潜在的誤謬を完全に、正確に検 知することを確保するための例外報告比較 • 以前のマネジメントレポートのレビューと、気付いた例外処置に対して取った処置と、その処置の結果に 関するマネジメントとの議論 345 G42 継続的保証 7 継続的監査業務のパフォーマンス 7.1 監査証拠の集積 7.1.1 継続監査手続きの使用は、監査目的と手続きの詳細内訳が一致しているという合理的な保証を提供する IT監査・保証の専門家によりコントロールされるべきである。IT監査・保証の専門家がなすべきなのは、 • 適切な場合、コントロール全体の調和の実施 • 出力情報の合理性レビュー • 論理、パラメータ、手続きの他の特徴のレビュー実施 • 継続的監査手続きのインテグリティに寄与するかもしれない企業の全般ITコントロールのレビュー（例、 プログラム変更コントロールと、システム、プログラム、データファイルへのアクセス） 7.2 継続的監査結果の解釈 7.2.1 一旦テストが遂行されたら、IT監査・保証の専門家は、問題が存在する場所を特定するためにテスト結果 をレビューすべきである。コントロールの弱点が、コントロールテストに不合格となった取引により立証さ れる。リスクの水準増加は比較分析（即ち、プロセス同士、エンティティ同士の比較とか同じテストを動か し、時間をかけて結果を比較する）により特定され得る。継続的監査やモニタリングシステムを実施すると いう実践的努力目標の一つは、特定されるコントロール例外措置とリスクへ効率的に対応することである。 継続的監査やモニタリングシステムが先ず実施されると、識別されるべき大量の例外措置が、調査と同時 に、懸念でないと判明するということは、異常ではない。継続的監査システムは、テストパラメータに、適 切であれば、そのような例外措置が結果的に警告にも通知にもならないように調整させることを必要とす る。一旦そのような、誤検知を特定するプロセスが実施されると、そのシステムは、ますますコントロール欠 如や重大懸念のリスクを識別するためだけ信頼され得る。加えて、特定された取引への監査対応の性質は 変化し、全てが監査や緊急処置を必要とする訳ではない。結果は優先順位付けされ、それに従って行動さ れるべきである。維持されるべき詳細は、 • 得られた結果 • 取られた処置に関する決定 • 通知された人と時期 • 期待される回答日 7.3 マネジメントアクション 7.3.1 もし継続的監査の発見事項がマネジメントに示されれば、IT監査・保証の専門家は、またアクションプラ ンとその日付の概要を描くマネジメントの回答を要求するべきである。一旦適切な処置がとられれば、IT監 査・保証の専門家は、是正行為がコントロール弱点に取組んできたとか、リスク水準を軽減してきたかと いったことを再度知るために継続的監査テストを実行すべきである。次のテストは同じ問題を特定すべき ではない。 346 G42 継続的保証 7.4 よく設定された継続保証手続き 7.4.1 適正に設計された継続監査アプリケーションを使用することは、 マネジメントが有効なコントロールフレー ムワークを維持し、積極的にリスクを管理するという保証を提供するという役割で監査活動を補助する。 しかしながら、継続的監査はリスク発現とコントロール環境の変化に柔軟かつ敏感でなければならない。 継続的監査は、実施して、長期間放置され得るものではない。IT監査・保証の専門家は、継続的監査プロ グラムの効率性と有効性を定期的にレビューすべきである。追加のコントロール点と発現したリスクは追 加される必要があるかもしれないし、外しても良いかもしれない。限界と種々の分析論のコントロールテス トとパラメータは、締めたり緩められたりする必要があるかもしれない。このレビュー中に、IT監査・保証 の専門家は、また継続的監査からの結果が、企業資源管理(ERM)、バランススコアカード、パフォーマンス 測定とモニタリング活動のような他のマネジメントアクティビティに含まれることを確保すべきである。 7.5 継続的保証結果の文書化 7.5.1 継続的監査プロセスは充分な監査証拠を提供するために充分に文書化されるべきである。 7.5.2 とりわけ、監査業務報告書は、次項にある詳細のような、継続的監査手続きを表現するに足る文書を内容 とすべきである。 7.6 計画策定文書 7.6.1 文書の内容としては、 • 継続的監査目的 • 使用される継続的監査手続き • マネジメントが所有する継続的モニタリングプロセスの評価 • 実施されるコントロール • スタッフィングと時期 • 報告先 7.7 執行文書 7.7.1 文書の内容としては、 • 準備と継続監査手続きのためのテスト手続きとコントロール • 継続敵監査手続きにより実施されるテストの詳細 • 入力（例、使用データ、ファイルレイアウト）、処理（例、高水準フローチャート、論理）、出力（例、ログ ファイル、報告）の詳細 • 関連パラメータやソースコードのリスト 7.8 監査証拠文書化 7.8.1 監査証拠の文書化の通常の基準は継続的監査業務に適用されるべきである。文書化としては、 • 生成された出力 • 監査の記述や出力で実施された監査業務の分析 • 監査発見事項 • 監査結論 • 監査推奨 7.8.2 使用されたデータとファイルは安全な場所に保管されるべきである。 347 G42 継続的保証 8 報告 8.1 実査完了と報告日の間隔 8.1.1 （内外監査人が使用する）伝統的な監査モデルにおいて、実査完了と関連監査報告の発行の間、一定の 期間が経過する。多くの例では、発行遅延の影響は、ユーザにとって、報告内容の情報の有用性と有益性 を低下せしめる。これは、被監査人が特定された欠陥へ修正を加えたり、特定されたコントロールの弱点 や欠陥に原因するコントロール環境（または関連する被監査人のデータ）への更なる品質低下のような問 題によって影響され得る報告内容の風化の結果である。 8.2 継続的保証報告 8.2.1 それゆえ、継続的監査はIT監査・保証の専門家が、現状のモデルの下、というよりずっと短い時間枠内で 主題に関して報告できるように設計されている。理論的に、何らかの環境の下、殆ど即時で、真の継続的 保証を提供するために、報告時間枠を短縮することが可能であるべきである。報告プロセスは、もっと時 宜を得た対応と継続的監査の実行から発生する問題の報告を確保するために、利害関係者と共に、策定 される必要がある。重大な問題は、可及的迅速に報告されるべきである。 8.2.2 策定により、継続的監査は、伝統的監査が必要とする以上に被監査人の情報システムに高度に依存する ことを必要とする。これは、監査テストの基盤としての外部にて生成された情報に対し、システムが生成し た情報に依存する必要の結果である。こうして、IT監査・保証の専門家は、システム自体によって生成され た情報と共に、被監査人のシステムの品質に関して、判断をする必要がある。低品質なシステムや低信頼 性の情報を生成する（そして高度の手動作業を必要とする）システムは、高品質かつ信頼性の高い情報を 生成するシステムより、継続的監査には効果がない。 8.2.3 高品質かつ信頼性の高い情報を生成する環境は、継続的期間に不足する報告期間にははるかに良く適し ている。低品質な環境や、信頼性の低い情報を生成する環境は、ユーザがシステムにより処理された情報 をレビューしたり、その結果、承認したり修正したりできるように経過しなければならない期間を補うだけ の長い報告期間を使用すべきである。 8.3 継続的保証の内容 8.3.1 報告の、目的・範囲・方法論の項は、使用された継続的保証プロセスに関するはっきりした記述を含むべ きである。この記述は充分に詳述され、読者に良質の外観を提供すべきである。 8.3.2 継続的監査手続きの目的の記述は、手続きの使用に関連する特定の発見事項が議論される場合、また、 報告書の本文に包含されるべきである。 8.3.3 使用された手続きの記述はいくつかの発見事項に適用されたり、あまりに詳述されているならば、報告の 目的・範囲・方法論の項で簡単に検討され、読者には、もっと詳細な記述のある付録を示すべきである。 9 適用開始日 9.1 本ガイドラインは2010年5月1日以降開始される全てのIT監査に適用される。 348 G42 継続的保証 10 参照 10.1 内部監査人協会、 「継続的監査：アシュアランス、モニタリング、リスク評価の関係、総括的技術監査ガイ ド」、アメリカ、2005年 ISACA 3701 Algonquin Road, Suite 1010 Rolling Meadows, IL 60008 USA Telephone: +1.847.253.1545 Fax: +1.847.253.1443 E-mail: [email protected] Web Site: http://www.isaca.org 349 今回の翻訳、査読・校正等の活動においては、 ISACA東京支部の次の方々にご協力頂きました。 ISACA東京支部 2011－2012年 会長・理事 柴田 昭 2011－2012 基準委員会 畠中 一浩（委員長） 坂川 克己（副委員長） 楠 正彦（副委員長） 富田 勲 （委員） 高木 和夫（委員） 坂本 哲 （委員） 鎌田 孝一（委員） 岩下 廣美（委員） 〒108-0075 東京都港区港南2-16-8-705 (株)ラーニング･アーキテクチャ研究所内 ISACA（情報システムコントロール協会）東京支部 TEL：03(5782)8358 FAX：03(5782)8312 Web Site: http://www.isaca.gr.jp
© Copyright 2024 Paperzz
