いよいよ試験一ヶ月を切りましたね。最近はシステム監査の勉強をしているんですが、皆さんの解き方のコツやアドバイスなどあったら教えてほしいです！！

ぉぉさん
こんばんは

お久しぶりです。
システム監査に特化したコツですね。
まず、システム監査基準を一読することから始めることをご推奨いたします。
で、わたしがまとめたノートをローンチ（公開、覚えたて）しちゃいまーす。

職務の分離
・入力と承認を別人にするコントロールが必要
・入力、変更の禁止の設定、解除を使用者以外の者が行う
・特権アカウントの管理と行使の権限を同一人物に付与しない

最少権限の原則

何を監査したいのかテーマをよく理解すること

システム監査の問題
・レベルの低いリスクが仕組まれている、あまり難しく考えない
・問題文の一つのワードに根拠や正解に導くヒント有り、よく読む
・プロセスに不自然な文章や日本語に設問の答え有り、よく読む
・登場人物は皆不正をしようと疑って読め！人間性悪説
・犯罪捜査ではない、監査部門の協力を得ながら

個人情報の目的外利用に本人の同意が必要  頻出

作業後のチェックがないために不適切  頻出

予防的コントロール
  プログラム修正や変更の本番環境への反映は変更者以外が行う
  第三者の目線でチェックし未然に防ぐ
発見的コントロール
  本番環境に正しく反映されたことを第三者が確認する

頻出の突合・照合法で「何と何を」選ぶか
  何を正しく実施しているか、という目的を正しく読み取れ
    例：正当な承認なく受注の変更が行われていないか
          変更履歴と承認済みの変更登録簿
    例：ウィルス対策管理者が通知を適切に記録しているか
          ログと管理簿

データの完全性のポイント
・網羅性  抜け、漏れがないか、全てのデータを入力する
・正確性  データが正しい、不正なデータがないこと
・安全性  安全に保護されていること
・整合性  データが一貫していること

監査証拠を入手する

指摘事項と改善勧告はそれぞれ対応

アクセス権が付与されたユーザIDの定期的な点検

ウォークスルー法
  書面又は実際に追跡。作業負荷が大きいので数を増やせばいいものではない

インダビュー（ヒヤリング）
  1人だけでなく複数人の関係者に。組織の問題か明らかにする

相関分析
  2つ以上の要因がもう一方の変化にどの程度影響を与えているか

全てのテストケース実施＝システムの目的を達成  ではない
  要件定義通りに作られていること

変更の受け付け順ではなく変更要求の緊急度を考慮して処理順を決定する

[新しい購買業務プロセスの概要]にも職務の分離に反している問題もある。正しいと思い込むな

情報化投資の有効性を確認する
  事前に定めた指標と比較し達成/未達成を評価すること（モニタリングではない）

委託先は再委託先に直接指示できない
  委託元→委託先→再委託先

承認額を超えた場合、購買の申請を差し戻す
  正しい値に直させる、ご発注なら返品

与信限度額は承認を得て超えた後すぐに元に戻す

財務報告に係る内部統制の評価及び監査の基準
・実在性
・網羅性                      知識が無くても「・・性」という文脈から考える            
・権利と義務の帰属
・評価の妥当性
・期間配分の適切性
・表示の妥当性

COBIT
  企業などの組織において情報システムを適切に管理するための指針や規約
  標準的な工程をまとめたガイドライン  IT統制

特定の監査から得られる、得られない監査結果がある
  複数の監査手続きを組み合わせる

正しいプロセスを飛び越した例外的な問題文には要注意！
  例：支払い遅延をさけるため購買管理システムを経由せず会計システムの債務データに直接追加、修正を行うことがある
  例：先行発注業務が受注管理システムと連携していないため不正発注が起こりうる

想定される不正の解答に「不正」は記述しなくてよい

比較するのが「～日」と何か、では「～日（時）」まで記述する
  例：ログの確認日と最新のハードディスクスキャンの実行日時

内部統制  会社が健全に事業活動を遂行するためのルールや仕組み
  4つの目的
    ①業務の有効性及び効率性
    ②財務報告の信頼性
    ③事業活動の信頼性
    ④資産の保全
  6つの要素
    ①統制環境
    ②リスクと評価と対応
    ③統制的活動
    ④情報と伝達
    ⑤モニタリング
    ⑥IT（情報化技術）への対応

アクセス権といっても参照権限と更新権限では想定されるリスクが大きく異なる

プロジェクト遅延を報告するだけではダメ
  スケジュールを見直して経営陣に再度承認をとる

ふーーー
以上でございます。
主に間違えた解答をドットコム様の解説や講評から反省の意味を込めてまとめたものです。
取捨選択して拾ってください。
何か役にたてば幸いでございます。

AgentTakaさんお久しぶりです！
わーすごいたくさん書いていただきありがとうございます！一通り読んで知識を盗ませていただきます。本番お互いに頑張りましょう！

ぉぉさん
こんにちは

盗みまくってください。その方が全然うれしいです。
ただ、わたしのノートも断片的なのでぜひ「システム監査基準（平成30年）」をネットで検索して入手し監査を体系的に学ぶところから入って下さい！40ページもないのでしぎ読み終わりますよ。

よく見たら2か所も誤字ありましたので読み替えお願い致します。ごめんなさい、、、

誤：委託先は再委託先に直接指示できない
正：委託元は再委託先に直接指示できない

誤：  正しい値に直させる、ご発注なら返品
正：  正しい値に直させる、誤発注なら返品

本番お互いに頑張るぞーーー！  おおっーーー！

AgentTakaさん私も是非参考にしたいのですが、URLなど終えていただけないでしょうか。

kさん
こんにちは

ドットコム様のルールで当サイトとIPA以外のリンクは貼れないんです。

システム監査基準  平成30年
で検索すると
PDF システム監査基準 - METI
てすぐヒットしますよ。

ありがとうございます。助かりました。

こんにちは。

AgentTaka様、まとめノート読ませていただきました。
とても素晴らしい内容でめちゃめちゃ勉強になりました。
（このサイトもそうですが、）無料で読ませてもらって良いのだろうか…と思いました（笑）

どうしても感謝を伝えたく。失礼しました。

NoNameさん
おはようございます。

古いスレッドだったのでご投稿頂いたことに気が付いておりませんでした。
NoNameさんのお気持ち、確かに受け取りました！
秋はお互い最善を尽くしましょう！
ご検討を祈ってます。

>AgentTakaさん

＞予防的コントロール
＞  プログラム修正や変更の本番環境への反映は変更者以外が行う
＞  第三者の目線でチェックし未然に防ぐ
ちょうどこの過去問と解きました（H25秋）
本番環境への反映について、プログラム修正者以外が立ち会うのも
予防的コントロールになると考えてよいのでしょうか？
（一人がリリース作業して、もう一人が間違ってないよね～って確認するやつです）

ぬるぽよさん
こんばんは

いやー、ずいぶん前のスレッドだから気が付かなかったよー。わははは
んー、ぬるぽよさんのご質問は、、、
ごめん！正直わかんね！わははは
ただ、真剣に予防的コントロールの状況を考えると、変更者が立ち会ってたらジャマな気がします。
変更者が口出して、「いや、これはこれでいいんだよ！」なんて言い出したら本番環境への反映をする第3者は「あぁ、そうですかぁ？」ってなりそうじゃないですか？
そしたら予防的コントロールの威力半減してしまう思いでおります。
自分なら本番環境への反映は変更者がいないところでじっくり行いたい気持ちでおります。
曖昧で申し訳ございません、、、

あー、そうですね。
プログラム修正者以外が立ち会う、ということは変更者ではない者が立ち会うということですね？
であれば、立派な予防的コントロールかと存じます。わたしはそういうのをダブルチェックとか相互チェックと呼んで、出来るだけ多くの「目」でチェックすることを目指しています。いいと思います！

AgentTaka様

古いスレッドだったので、きっと気づいていただけないと思いつつ書いたのですが、お返事いただけて感激です。ありがとうございます！

本番が近づいてきて、今からドキドキしていますが、良い結果が出せるよう頑張りたいです。
AgentTaka様はワクチン接種もあるそうで大変ですが…、ご健闘をお祈りいたしますm(_ _)m