(1)システム監査の重要性
1.（有用性）ユーザのニーズを十分に満たしているか
2.（経済性）ユーザの満足を得るために、過大なコンピュータ資源を使用してないか
3.（信頼性）処理過程が間違っており、提供される情報が信頼できないものである可能性はないか
4.（安全性）事故や故障、災害、不正等により正常な情報処理業務が阻害される事態への備えは十分か

(2)システム開発監査の対象領域
1.プロジェクト管理（プロジェクト全体の統制）
　進捗管理
　予算管理
　労務管理
　教育訓練
　承認手続き
　プロジェクト評価

2.ソフトウェア開発（業務システムの開発）
　要件設定
　設計
　プログラミング
　テスト

(3)システム開発監査の課題
1.プロジェクト管理業務の監査上の課題
2.ソフトウェア開発に関する監査上の課題

２．システム開発監査のアプローチ方法
1.継続的監査
2.システム完成前監査
3.システム稼働後監査
4.局面監査

(1)事前準備
1.監査リスクの明確化
監査を進める上で障害となる要因を明確にする
システムを事前に理解しておく
2.監査資源の調達
監査スタッフの調達（技量、専門家、人数）
監査資料（既存システムや業務の監査調書、など）の明確化
監査ツールの準備
3.監査計画の策定
スケジュールの決定
予算の決定

(2)プロジェクト・チームとの事前協議
1.プロジェクト管理方法
　プロジェクト管理方法
　進捗管理方法
2.開発過程のドキュメントの整理と取り扱い
　レビュー報告書、承認書など監査証跡となるドキュメントの整理
　機密対象ドキュメントの管理基準設定
3.監査手続き
　監査手続きの概要と趣旨をプロジェクトメンバーへの説明
　監査実施上支障となる事項の事前確認
4.システム監査人の職務権限
　ドキュメント提出の依頼の権限
　次局面へ進む場合の承認権限（監査人の同意が必要かどうかなど）
5.システム監査に要する期間
　各局面終了ごとにシステム監査が実施されるため、時期や期間についてあらかじめプロ　　　ジェクト計画に組み込む必要がある
6.監査モジュールの組み込み
　監査モジュールの組み込みが必要な場合はその工数、予算を見込む
7.システム監査人との定期的打ち合わせ
　プロジェクトと監査人との定期的打ち合わせの時期、頻度をあらかじめ決定しておく
8.システム監査人へのミーティング開催通知
　システム開発過程で行われる開発チームのミーティングのなかで監査上重要と認めるミーティングにはシステム監査人自らが参加する。
そのため、会議開催の通知がシステム監査人に連絡する事要求する必要がある。

(3)局面レビュー
1.要件設定局面
　プロジェクト、ユーザで検討が十分にされたか
　システムの統制・保護機能が盛り込まれているか
　スケジュールに手戻り作業が必要となった場合の余裕率が組み込まれているか
　スケジュールが過去の開発実績や対象システムの難易度に基づき合理的に計画されたものか
2.設計局面
（外部設計）
　システム要件がもれなく正確に記述されているか
　監査証跡が明確に定義されているか
　セキュリティに関する十分な配慮がされているか
（内部設計）
　以下の項目について担当者以外の者によるレビューが行われたか
　開発手順、標準が守られているか
　不要な機能が付加されていないか
　モジュール間に重複した機能が無いか
3.プログラミング局面
（プログラミング局面）
　論理レビューが適当な者によって効果的に実施されたか
　プログラムの作成基準（標準）が準備されているか
　プログラム作成基準が遵守されているか
（結合テスト局面）
　下記の確認をするためテストの条件・方法について十分なものか確認する
　システムの信頼性を保証するに足る質・量両面からの十分なテストが行われたか
　テスト結果の確認、質問および立ち会い
4.システムテスト局面
　ユーザがシステムテストに参加し結果を検証しているか
　システムに組み込まれた統制・保護機能が実際に機能するか
5.移行局面
　適切に計画された移行計画にそってスムーズに行われるか
　テスト完了した資源がプログラマがアクセスできないよう管理されているか

(4)報告書作成
　1.報告書提出前にプロジェクトメンバーと十分検討する
　2.勧告事項はプロジェクトメンバーの同意が得られるよう努力する