入力・処理・データのコントロール

結論：まず「何を守りたいか」を決めれば答えが決まる

監査人が確かめるのは、リスクを抑えるコントロール（統制。ミスや不正を防ぐ・見つける仕組み）がきちんと働いているかです。問題文には必ず「漏れなく重複なく」「正確性」「不具合のリスク」のような守りたいものが書いてあります。それに合う仕組みを選び、別の目的の仕組みを消せば正解にたどり着けます。

入力原票の管理：入力した結果は「頼んだ側」に確認させる

入力原票とは、業務部門が手書きなどで作る入力の元になる伝票です。情報システム部門が代わりに入力するときは、入力した結果を処理結果リストとして業務部門に返し、原票ごとに確認してもらうのが正しい統制です。内容を一番よく知っているのは起票した業務部門だからです。

たとえるなら、クリーニング店が預かり品を受け取ったその場で枚数を数え、仕上がりをお客さんに確認してもらうのと同じです。「勝手に直す」「後でまとめて数える」「すぐ捨てる」は、どれも統制の不備です。

入力の漏れ・重複を確かめる：プルーフリスト照合

「起票された伝票が漏れなく、重複なく入力されたか」を確かめるには、プルーフリスト（入力されたデータをシステムから印刷した一覧）と元の伝票を1件ずつ突き合わせ、照合した証拠の照合印を確かめます。伝票と入力データを直接突き合わせるので、抜けも二重入力も見つかります。

試験では、目的の違う監査技法がひっかけとして並びます。

見分け方は「伝票（紙）とデータを突き合わせているか」です。「プログラム」「テストデータ」の話になっている選択肢は、漏れ・重複の問題では外れです。

コントロールトータルチェック：送った数と届いた数を合わせる

コントロールトータルチェックは、送信側で数えた件数や金額の合計と、受信側で数えた合計を照合して、データの欠落や重複がないかを確認する仕組みです。宅配便で「段ボール5箱」と伝票に書き、受け取った人が5箱あるか数えるのと同じ発想です。1件ずつの中身ではなく、合計値の一致を見るのがポイントです。

問題文に「合計」「件数」「送信側と受信側」が出たら、迷わずコントロールトータルチェックです。

ソフトウェア資産管理とパッチ適用：証拠と事前確認

出題が最も多い知識です。ソフトウェア資産管理とは、組織が使うソフトウェアとその利用権（ライセンス）を正しく把握・管理することです。監査のチェックポイントは、ライセンス証書などの「使う権利がある」ことを示す証拠が保管されているかです。車でいえば、乗っている車と車検証がそろっているかを確かめるイメージです。

ひっかけの選択肢は、別の観点のチェックポイントです。

同じ系統で、パッチ（ソフトウェアの修正プログラム）の適用で不具合が起きるリスクを下げるコントロールも問われます。答えは本稼働前にシステムの動作確認を十分に行っているかです。キャパシティプランニング（将来の処理量に備えた資源計画）、マスタデータの管理手続、ハードウェア管理台帳は、パッチによる不具合とは関係の薄い統制なので外します。

DBのインテグリティとスプレッドシート：正しさを守る仕組みを見る

インテグリティ（完全性。データが正確で欠けていない状態）の監査では、データに不具合が起きたときの障害回復の手段が組み込まれているかを確認します。利用効率・領域のバランス・レスポンスタイムは性能の観点なので外れです。

スプレッドシートの処理ロジックの正確性は、計算の中身（プログラム内容）が文書化され、検証されているかで確かめます。バックアップは可用性、利用者を決めるのは機密性の対策で、計算が正しいかどうかとは無関係です。