セクション：ITのガバナンスと管理
説明／参考資料：
実行 - 計画を実行し、プロセスを実行し、製品を作成します。チャート作成と分析のためのデータを収集します。
以下の「確認」および「実行」の手順。
試験を受けるにあたっては、以下の情報を知っておく必要があります。
PDCA（計画-実行-評価-改善または計画-実行-評価-調整）は、
プロセスと製品の管理と継続的な改善のためのビジネス。
デミングサイクル、スチュワートサイクル、コントロールサイクル、または計画・実行・評価・改善（PDSA）サイクル。
このPDCAサイクルのバージョンはOPDCAです。追加された「O」は観察を意味します。
「現状を把握せよ。」
PDCAサイクルの各ステップは以下のとおりです。

プラン
期待される成果物に応じて結果を出すために必要な目標とプロセスを確立する
（目標または目的）。出力の期待値を設定することで、仕様の完全性と正確性は
これも目標とする改善策の一環です。可能であれば、小規模で開始して効果を検証してください。
する
計画を実行し、プロセスを実行し、製品を作成します。チャート作成と分析のためにデータを収集します。
「確認」と「実行」の手順に従う。
チェック
実際の結果（上記の「DO」で測定・収集されたもの）を調べ、期待される結果と比較する。
（「計画」からの目標または目的）の相違点を確認する。実施における逸脱を探す。
計画を確認し、実行を可能にするための計画の適切性と完全性も確認します。
「実行」。データをグラフ化することで、複数のPDCAサイクルにわたる傾向を把握しやすくなり、
収集したデータを情報に変換する。情報は次のステップ「行動」に必要なものだ。
活動
実際の結果と計画された結果の大きな差異について、是正措置を要求します。
違いを特定して根本原因を突き止める。変更を適用する場所を決定する。
プロセスまたは製品の改善。これら4つのステップを実行しても改善の必要性が生じない場合
改善するために、PDCA の適用範囲を、より詳細に計画および改善するように細分化することができます。
サイクルの次の反復、またはプロセスの別の段階に注意を向ける必要がある。
以下の回答は誤りです。
計画 - 目標とプロセスを確立し、
期待される成果（目標または目的）。
チェック - 実際の結果（上記の「DO」で測定および収集されたもの）を調べ、
期待される結果（「計画」からの目標または目的）との差異を確認する
ACT - 実際の結果と計画された結果の大きな違いについて是正措置を要求します。
違いを特定して根本原因を突き止める。変更を適用する場所を決定する。
プロセスまたは製品の改善
この質問を作成するにあたり、以下の参考文献が使用されました。
CISAレビューマニュアル2014年版、107ページ

Business stakeholders being involved in approving the IT strategy best demonstrates that IT strategy is aligned with organizational goals and objectives. IT strategy is a plan that defines how IT resources and capabilities will support and enable the achievement of business goals and objectives. Business stakeholders are the individuals or groups who have an interest or influence in the organization's activities and outcomes.
By involving business stakeholders in approving the IT strategy, the organization can ensure that the IT strategy reflects and supports the business needs, expectations, and priorities. The other options do not necessarily indicate that IT strategy is aligned with organizational goals and objectives, as they do not involve the participation or feedback of business stakeholders. References: CISAReview Manual, 27th Edition, page
97

包括的かつ詳細な説明：
インシデント管理の主な目的は、業務の重要度に基づいてITサービスを可能な限り迅速に復旧させ、業務の中断を最小限に抑えることです。
* 根本原因分析（C）は、インシデント管理ではなく、問題管理により近いものです。
* インシデント（B）の報告は重要ですが、主要な目的ではありません。
* プログラムの修復（D）は是正活動であり、中心的な目標ではありません。
# ISACA 参考資料: CISA レビュー マニュアル第 27 版、ドメイン 2 (IT 運用と事業継続性)、ITIL インシデント管理プロセスに関するセクション。

Comprehensive and Detailed Step-by-Step Explanation:
To ensurecompleteness of outbound transactions, alog with periodic validationis thebest control.
* Option A (Incorrect):Edit checkshelp withdata accuracy, not completeness.
* Option B (Incorrect):Sequential numberingdetects missing transactions but does not verifyactual transmission.
* Option C (Incorrect):Recipient ID validationis important foraccuracy, not for ensuring all transactions are sent.
* Option D (Correct):Maintaining and validating transaction logsensures thatall outbound transactions are properly accounted for, making it the best completeness control.
Reference:ISACA CISA Review Manual -Domain 3: Information Systems Acquisition, Development, and Implementation- Coversdata integrity, completeness controls, and transaction logging.