説明/参照：
Explanation:
システム開発ライフサイクル（SDLC）は、情報システムを開発するプロセスです。SDLCには、開始、開発、取得、実装、運用、保守、および廃棄の各フェーズが含まれます。
開始フェーズには、システムの目標と実現可能性の決定が含まれます。システムの実現可能性には、システム要件と、それらが運用プロセスとどの程度一致しているかが含まれます。緊急時対応計画の要件は、システムの要件と設計に基づいて分析する必要があります。
不正解：
B：緊急時対応計画は、開発/取得フェーズではなく、開始フェーズで最も重要です。プロジェクトの可能な限り早い段階で緊急時対応計画を作成することが重要です。
C：緊急時対応計画は、実装フェーズではなく、開始フェーズで最も重要です。緊急時対応計画は、システムを実装する前に作成する必要があります。
D：緊急時対応計画は、運用/保守フェーズではなく、開始フェーズで最も重要です。システムが展開された後ではなく、プロジェクトの可能な限り早い段階で緊急時対応計画を作成することが重要です。
参照：
EC-Council、Disaster Recovery、Cengage Learning、Andover、2010年、4〜11ページ

認定とは、本番環境にソフトウェアまたはシステムを実装するための管理者による承認です。この承認は、暫定的または完全なもののいずれかです。
以下は不正解です。
認定が正しくありません。認証は、のセキュリティスタンスを評価するプロセスです。
選択した一連の標準またはポリシーに対するソフトウェアまたはシステム。認定は技術的なものです
製品の評価。これは認定に先行する可能性がありますが、必須の前兆ではありません。
受け入れが正しくありません。この用語は、ソフトウェアの一部または
システムは一連の機能レベルまたはサービスレベルの基準を満たしています（新しい給与システムは
検収試験）。この文脈では、認証がより良い方法です。
評価が正しくありません。評価は確かに認証プロセスの一部ですが、そうではありません
質問に対する最良の答え。
この質問に使用される参照：
ISC2のCBKの公式学習ガイド、559〜560ページ
AIO3、pp.314-317
AIOv4セキュリティのアーキテクチャと設計（369〜372ページ）
AIOv5セキュリティアーキテクチャと設計（370〜372ページ）

説明/参照：
Explanation:
一元化されたインシデント報告は、従業員がインシデントを報告する可能性を減らすのではなく、増やすでしょう。
不正解：
A：従業員は、関与することを恐れ、インシデントの報告を控えることができます。
C：自分がしなかったことで告発されることを恐れている従業員は、事件を報告する可能性が低くなります。
D：会社のセキュリティポリシーと手順を知らない従業員は、インシデントを報告する可能性が低くなります。
参照：
https://en.wikipedia.org/wiki/Computer_security_incident_management

監査証跡は、システムまたはアプリケーションプロセスごとのシステムアクティビティの記録を維持します
そしてユーザーの活動によって。適切なツールと手順と組み合わせて、監査証跡は提供することができます
個人の説明責任、イベントを再構築し、侵入を検出し、問題を特定する手段。
監査証跡管理は技術管理と見なされます。インシデントの監視と追跡はもっと
インシデント対応機能に関連する運用管理。
この質問に使用される参照：
SWANSON、Marianne、NIST Special Publication 800-26、セキュリティ自己評価ガイド
情報技術システム、2001年11月（ページA-50からA-51）。
注：NIST SP 800-26は次のように置き換えられました：FIPS 200、SP 800-53、SP 800-53A新しい代替品は次の場所にあります：http：//csrc.nist.gov/publications/PubsSPs.htmlただし、あなたは本当に古い標準を見たいと思っています、それはアーカイブされた文書としてリストされています：http://csrc.nist.gov/publications/PubsSPArch.html