テストは、ユーザー要件が検証されているかどうかを判断する上で非常に重要です。このフェーズには情報システム監査人が関与し、エラー レポートを確認して、エラーのあるデータを正確に認識し、エラーを解決する手順を確認する必要があります。概念設計仕様は、要件定義フェーズで作成される文書です。ベンダー契約は、ソフトウェア取得プロセス中に作成されます。プログラム変更要求は通常、実装後フェーズの一部として確認されます。

潜在的なセキュリティの脆弱性を特定した後、IS 監査人の次のステップは、脆弱性を悪用する脅威のビジネス影響分析を実行することです。

セクション: 情報システムの監査プロセス

バッチ制御調整は、職務の分離が不十分な場合のリスクを軽減するための補償制御です。

品質保証 (QA) フェーズは、IS 監査人が、ユーザー仕様を満たしていない社内 SDLC プロジェクトの要件を最初に調査するフェーズです。これは、QA フェーズが、システムがユーザー仕様と設計仕様に照らしてテストおよび検証され、機能要件と非機能要件、および品質基準と期待を満たしていることを確認するフェーズであるためです。QA フェーズには、ユニット テスト、統合テスト、システム テスト、受け入れテスト、パフォーマンス テスト、セキュリティ テストなど、さまざまなテスト アクティビティが含まれ、欠陥、エラー、または仕様からの逸脱を特定して解決します12。
構成フェーズは、情報システム監査人が、ユーザー仕様を満たしていない社内 SDLC プロジェクトの要件を最初に調査するフェーズではありません。構成フェーズは、ハードウェア、ソフトウェア、ネットワークなどの対象環境にシステムをインストールして構成し、展開と運用の準備をするフェーズです。構成フェーズには、システムが既存のインフラストラクチャやシステムと互換性があり相互運用可能であることを確認するために、インストール、カスタマイズ、移行、統合などのアクティビティが含まれる場合があります34。
ユーザートレーニングフェーズは、情報システム監査人がユーザー仕様を満たしていない社内 SDLC プロジェクトの要件を最初に調査するフェーズではありません。ユーザートレーニングフェーズは、エンドユーザーがシステムを効果的かつ効率的に使用する方法についてトレーニングおよび教育を受けるフェーズです。ユーザートレーニングフェーズには、ユーザーがシステムの機能に慣れ親しんで快適に使用できるように、トレーニング資料の作成、トレーニングセッションの実施、フィードバックとサポートの提供などのアクティビティが含まれる場合があります56。
開発フェーズは、IS 監査人が最初にユーザー仕様を満たしていない社内 SDLC プロジェクトの要件を調査するフェーズではありません。開発フェーズは、設計仕様とユーザー仕様に基づいてシステムがコーディングされ、構築されるフェーズです。開発フェーズには、システムの実用的なプロトタイプまたは最終製品を作成するためのプログラミング、デバッグ、ドキュメント作成などのアクティビティが含まれる場合があります。