システム監査の用語
全141語。
コンピュータを利用して行う監査技法の総称。
⚠ 専用ソフトに限らない（汎用ソフトでもよい）
監査の進め方：計画から本調査まで
磁気テープを使うバックアップ媒体。DDS-4は約20GB（圧縮なし）を記録できる。
⚠ CD-R（約700MB）、MO（最大約2.3GB）、DVD-RAM（片面約4.7GB）より容量が大きい。
可用性とバックアップの監査
組織が情報セキュリティをPDCAで継続的に管理・改善するための仕組み。
情報セキュリティ監査基準と ISMS
組織のISMSがJIS Q 27001に適合しているかを第三者の認証機関が審査・認証する制度。
⚠ 評価するのは「組織の仕組み」。IT製品の評価（ISO/IEC 15408）とは違う。
情報セキュリティ監査基準と ISMS
IT製品のセキュリティ機能が適切・確実に作られているかを評価するための国際規格。
⚠ ISMS適合性評価制度と混同しやすい。15408は製品、ISMSは組織。
情報セキュリティ監査基準と ISMS
経営者がITを経営戦略・目標に沿うように統制する仕組みと活動。
⚠ ITマネジメントは日々の管理・運用で、ガバナンスは経営者による方向づけ。
システム監査とは何か：目的・基準と監査人の立場
経営者がITの活用を方向づけ、統制し、事業の価値につなげる仕組み。
⚠ 改善計画は、この観点から経営資源の状況を踏まえて評価する。
監査報告とフォローアップ
情報システムに関わる内部統制で、システムによる処理の正確性や不正防止を確保するための仕組み。
内部統制とコントロールの基本
ISMSの要求事項を定めた日本の規格で、ISO/IEC 27001を日本語にしたもの。
⚠ JIS Q 15001（個人情報保護・Pマーク）と番号が似ている。27001＝ISMS、15001＝個人情報。
情報セキュリティ監査基準と ISMS
計画・実行・点検・改善を繰り返して管理の質を上げる考え方。
⚠ システムライフサイクル（企画・開発・運用・保守）とは別物。
システム管理基準の構成と情報戦略
提供するサービスの品質水準を、委託元と委託先で合意して文書にしたもの。
⚠ 品質の評価に使うもので、委託先の破綻対策ではない。破綻対策はエスクロウ。
開発工程と外部委託の監査チェックポイント
サービスの提供者と利用者が、提供する水準を数値で取り決めた合意。
⚠ 中断時間を定めたSLAの管理は可用性の項目。SLAという言葉だけで機密性などと結びつけない。
可用性とバックアップの監査
停電や電圧の乱れが起きても、しばらく電力を供給して機器を守る装置。
⚠ 電源の対策であり、地震や火災などの災害対策（遠隔地のバックアップ）の代わりにはならない。
可用性とバックアップの監査
誰がどの情報を見たり変更したりできるかを制限する仕組み。
⚠ 機密性の対策。変更の承認は完全性の対策。
開発工程と外部委託の監査チェックポイント
権限を持つ人だけがシステムやデータを使えるよう制限する仕組み。
⚠ データの欠落・重複の確認とは無関係で、機密性の対策。
入力・処理・データのコントロール
誰が・いつ・何にアクセスしたかの記録。
セキュリティ管理策の監査指摘事項
利用者を識別し、許可された範囲だけ操作させる仕組み。
⚠ 安全性の検証項目。フェールソフトなどの信頼性の機能と並べて出される。
セキュリティ管理策の監査指摘事項
どのデータや機能を使ってよいかを利用者ごとに決めた権限。
⚠ 退職・異動したら遅滞なく削除・変更する。まとめて行うのは指摘事項。
セキュリティ管理策の監査指摘事項
監査人が直接、関係者に口頭で質問して回答を得る技法。
⚠ チェックリスト法は書面での回答。チェックリストを作るのは監査人
監査の進め方：計画から本調査まで
データが正確で、欠けたり矛盾したりしていない状態のことで、その維持には障害時の回復手段などが必要になる。
⚠ 利用効率やレスポンスタイムは性能の観点で、インテグリティの監査ポイントではない。
入力・処理・データのコントロール
データの生成から入力・処理・出力・活用までの流れと、そこに組み込まれたコントロールを、書面上または実際に追跡する技法。
⚠ テストデータ法は用意したデータで期待結果を確かめる。ウォークスルーは流れを追う
監査の進め方：計画から本調査まで
委託先が経営破綻しても保守を続けられるように、ソースコードなどを第三者に預けておく仕組み。
⚠ 瑕疵担保責任（欠陥への責任）や SLA（品質水準）は破綻への備えにならない。
開発工程と外部委託の監査チェックポイント
入力された個々のデータ項目の形式・範囲・論理が妥当かを検査する仕組み。
⚠ コントロールトータルチェックは合計値の照合で、こちらは1項目ずつの検査。
入力・処理・データのコントロール
将来の処理量の増加を予測し、必要なCPUや記憶容量などの資源を計画すること。
⚠ 性能・容量の計画であり、パッチ適用時の不具合リスクの対策ではない。
入力・処理・データのコントロール
災害や障害などの緊急事態が起きたときに、業務を継続・復旧するための対応をあらかじめ決めた計画。
⚠ 事前に作る計画だが、事故後の立て直しに使うため分類は復旧統制。
内部統制とコントロールの基本
リスクを抑えるために組織が設ける具体的な管理策（ルール・手続・チェックなど）。
システム監査とは何か：目的・基準と監査人の立場
ミスや不正を防いだり見つけたりするために組織が組み込む仕組みや手続のこと。
入力・処理・データのコントロール
リスクを低く抑えるために組織が設ける仕組みやルール。
⚠ どのリスクに効く統制なのかを対応させる。利用者要件の充足に効くのは利用部門のレビュー。
開発工程と外部委託の監査チェックポイント
送信側と受信側でデータの件数や金額の合計を照合し、欠落や重複がないかを確かめる仕組み。
⚠ エディットバリデーションチェックは個々の項目の妥当性、チェックデジットはコード番号の入力ミスを見る。「合計」ならこれ。
入力・処理・データのコントロール
全体の中から一部だけを抜き出して確かめること。
⚠ テスト項目の選び方としては網羅性が足りず指摘事項になる。
開発工程と外部委託の監査チェックポイント
プログラムを組み合わせたシステム全体が、設計どおりに動くかを確かめるテスト。
⚠ 受入れテストとの違いは主体。システムテストは開発側が中心、受入れテストは利用部門が主体。
開発工程と外部委託の監査チェックポイント
システムの一生のことで、システム管理基準では企画・開発・運用・保守の4段階。
⚠ PDCAサイクル（計画・実行・点検・改善）と取り違えやすい。「企画」で始まるのがライフサイクル。
システム管理基準の構成と情報戦略
旧システムから新システムへ、データや業務を切り替える作業。
⚠ 移行結果の検証を開発部門内だけで完結させるのは指摘事項。
開発工程と外部委託の監査チェックポイント
情報システムのリスクに対するコントロールが整い動いているかを独立した立場で評価し、改善につなげる活動。
⚠ 脆弱性診断・テストは運用部門などが自分で行う作業で、監査ではない。
システム監査とは何か：目的・基準と監査人の立場
独立した監査人が、情報システムのリスクに対するコントロールが適切に整備・運用されているかを証拠に基づいて評価し、依頼者に報告すること。
監査の進め方：計画から本調査まで
独立した監査人が、情報システムのリスクに対する統制が適切に整備・運用されているかを確かめ、評価すること。
開発工程と外部委託の監査チェックポイント
システム監査人が監査を行うときに守るべき行為規範。
⚠ システム管理基準は監査の判断尺度。「監査」基準は監査人、「管理」基準は組織のためのもの。
システム監査とは何か：目的・基準と監査人の立場
監査の目的・権限・責任などを定めた組織内のルールで、経営者が最終承認する。
⚠ 情報システム部門長や被監査部門長が承認するのは誤り。
システム監査とは何か：目的・基準と監査人の立場
情報システムを、独立した立場から証拠に基づいて点検・評価し、監査意見を述べる人。
⚠ 被監査部門の担当者と混同しない。監査人は報告と確認までを行い、改善の実施・管理はしない。
監査報告とフォローアップ
情報戦略の立案からIT投資、リスク低減のコントロールの整備・運用までの実践事項をまとめ、監査の判断尺度にもなる基準。
⚠ システム監査基準（監査人の行為規範）と逆にしやすい。
システム監査とは何か：目的・基準と監査人の立場
経済産業省がまとめた、情報システムを適切に管理するための項目集で、システム監査のものさしになるもの。
⚠ システム監査基準は「監査人がどう監査するか」の基準。システム管理基準は「監査される側がどう管理すべきか」の基準。
システム管理基準の構成と情報戦略
組織が保有・利用するソフトウェアとそのライセンスを把握し、正しく管理すること。
⚠ 開発体制の考慮・導入時の整合性評価・障害の局所化は別観点のチェックポイント。
入力・処理・データのコントロール
コード番号に計算で求めた検査用の数字を付け加え、入力時にその数字を再計算して入力ミスを検出する仕組み。
⚠ 件数や合計の照合ではなく、1つのコードの誤りを見つけるもの。
入力・処理・データのコントロール
監査人が用意したテストデータを対象プログラムで処理し、期待した結果が出るかを確かめる技法。
⚠ 監査モジュール法は監査用プログラムを本番に組み込む
監査の進め方：計画から本調査まで
監査人が用意したテストデータをプログラムに処理させ、予想した結果と比べてチェック機能や処理の正しさを確かめる監査技法。
⚠ 並行シミュレーション法は監査人側がプログラムを用意し実データを流す。テストデータ法はデータを用意して本番プログラムに流す。
入力・処理・データのコントロール
ソースコードの変更履歴を保存し、誰がいつ何を変えたかを管理する仕組み。
開発工程と外部委託の監査チェックポイント
ソフトウェアの不具合や脆弱性を直すための修正プログラムで、適用前に本稼働前の動作確認を行うのが不具合リスクを下げる統制。
入力・処理・データのコントロール
被監査部門の担当者に質問して情報を得る監査手続。
⚠ 聞いた話はそれだけでは弱いので、文書や記録で裏付けを取る。
監査証拠と監査調書
故障したとき、機能や性能を落としてでも処理を続ける考え方。
⚠ フォールトトレラントは全機能を維持し、フェールソフトは機能を落としてでも動かす。
セキュリティ管理策の監査指摘事項
部品を二重化するなどして、故障しても全機能が止まらないようにする考え方。
⚠ フェールソフトとの違いは、機能を落とさない点。
セキュリティ管理策の監査指摘事項
改善勧告に対して、被監査部門の改善が計画どおりに進んでいるかを監査人が確認する活動。
⚠ 進捗管理・技術支援・計画策定と取り違えやすい。監査人は確認するだけで、手は出さない。
監査報告とフォローアップ
JIS Q 15001に基づき、個人情報を適切に保護する体制を整えた事業者を認定する制度。
⚠ ISMSは情報全般、Pマークは個人情報に限定。
情報セキュリティ監査基準と ISMS
入力されたデータをシステムから印刷した一覧で、元の伝票と照合して入力の漏れ・重複・誤りを見つけるのに使う。
⚠ テストデータ法・並行シミュレーション法はプログラムの確認で、原票との突合ではない。
入力・処理・データのコントロール
ウイルスなどの不正なプログラムを検知・駆除するソフト。
⚠ 導入を個人の判断に任せるのは統制の不備。
セキュリティ管理策の監査指摘事項
内部統制が有効に機能しているかを継続的に監視・評価する活動。
内部統制とコントロールの基本
状況を継続的に見守り、確認すること。
⚠ 「管理」とは違う。管理は自分でコントロールすること、モニタリングは見て確かめるだけ。
監査報告とフォローアップ
利用部門（委託者）が要件定義に基づき、納品されたシステムを受け取ってよいか確かめるテスト。
⚠ システム部門だけ、受託者だけ、監査人が計画する、はいずれも誤り。
開発工程と外部委託の監査チェックポイント
ソフトウェアを正規に使う権利があることを示す書類で、資産管理の監査ではその保管状況を確認する。
入力・処理・データのコントロール
障害が起きたあと、データやシステムを正常な状態に戻すこと。
セキュリティ管理策の監査指摘事項
バックアップデータから実際にシステムやデータを戻せるかを試すこと。
⚠ 確かめられるのは「戻せるか」であり、「毎日取れているか」ではない。
可用性とバックアップの監査
問題が起きる可能性とその影響の大きさを見積もり、優先順位をつける作業。
⚠ 監査対象は体制・順序・無作為ではなく、リスクの大きさで選ぶ
監査の進め方：計画から本調査まで
リスクを特定・分析し、リスク受容基準と比べて対策が必要かを評価する一連の作業。
情報セキュリティ監査基準と ISMS
どの程度のリスクなら対策せずに受け入れるかを決めた線引きで、リスクアセスメントの前に決めておくもの。
⚠ 順番のひっかけに注意。アセスメントの「後」に決めるのは不適合。
情報セキュリティ監査基準と ISMS
プログラムの分岐によって処理が通りうる道筋。単体テストではすべての道筋を確かめる。
開発工程と外部委託の監査チェックポイント
システムが不正なアクセスや使用から守られていること。
⚠ 信頼性（障害に強いこと）と混同しやすい。「不正」という言葉があれば安全性。
セキュリティ管理策の監査指摘事項
JIS X 19790（ISO/IEC 19790）などに基づき、暗号モジュールの実装とセキュリティ要件を試験・認証する制度。
⚠ 電子政府推奨暗号リストと混同しやすい。リストは推奨暗号アルゴリズムの一覧であり、認証制度ではない。
情報セキュリティ監査基準と ISMS
完成したシステムを運用手順や年間運用計画に沿って日々動かし、異常に対処する段階。
⚠ 保守業務はシステム自体を直す・変える段階。運用は動かし続ける段階。
システム管理基準の構成と情報戦略
設定内容や実行結果ログなどの記録を読み、過去の実績を確かめる手続。
⚠ 再実施（監査人が自分でやり直す手続）は今の1回分しか確かめられない。継続して取れているかを見るなら閲覧。
可用性とバックアップの監査
バックアップ媒体を、稼働中のシステムから離れた場所に保管すること。
⚠ サーバの近くに置くのは災害時に一緒に失われるため不適切。外部の倉庫会社への委託は、機密保持契約があれば適切。
可用性とバックアップの監査
コントロールの有効性を監査できるように、情報システムが設計・運用されていること。
⚠ 監査人の能力や監査証拠の十分性ではなく、システム側の性質を指す。
内部統制とコントロールの基本
必要なときにシステムやデータを使える性質。
⚠ 完全性（データが正しいこと）と混同しやすい。止まる・停止・復旧の話なら可用性、正しさ・改ざんの話なら完全性。
可用性とバックアップの監査
監査人が報告書で改善を提案すること。実際に改善するのは被監査部門。
⚠ 「改善指示」と混同しやすい。監査人は命令しない。その場での指示は役割外。
監査証拠と監査調書
指摘事項について、監査人が報告書の中で示す改善の勧め。
⚠ 「改善指示」と混同しない。指示するのは監査依頼者で、監査人は勧めるだけ。
監査報告とフォローアップ
改善勧告を受けて被監査部門が作成し、提出する改善の実施計画。
⚠ 監査人が策定する選択肢は誤り。
監査報告とフォローアップ
計画に沿って、標準化された開発方法に基づき設計・プログラミング・テストを行う段階。
システム管理基準の構成と情報戦略
個別システムの費用・スケジュール・開発体制・投資効果などを明確にする計画。
⚠ 全体最適化計画（組織全体のあるべき姿）と区別する。
システム管理基準の構成と情報戦略
監査人が組織上・立場上、監査対象と利害関係がない状態。
⚠ 精神上の独立性は心の中の公正さ。研修や能力要件は「専門能力」で、どちらの独立性でもない。
システム監査とは何か：目的・基準と監査人の立場
データが正確で、欠けや改ざんがない性質。
⚠ 入力チェック・エラーチェックは完全性。「チェック機能」とあっても可用性ではない。
可用性とバックアップの監査
監査を依頼し、監査報告を受けて改善を指示する人（多くは経営者）。
⚠ 被監査部門とは別。報告先は被監査部門ではなく依頼者
監査の進め方：計画から本調査まで
監査を依頼し、監査報告書を受け取って改善を指示する人。多くは経営者。
⚠ 被監査部門の長と取り違えやすい。報告書の提出先は依頼者であり、被監査部門ではない。
監査報告とフォローアップ
監査証拠にもとづいて監査人が下す評価・結論。
監査証拠と監査調書
監査人が、集めた証拠に基づいて報告書に示す評価や結論。監査人はこれに責任を負う。
⚠ 「指摘した問題点の改善」も監査人の責任と思いやすいが、改善は被監査側の責任。
監査報告とフォローアップ
監査の目的・対象範囲・時期・体制などを、依頼者のニーズを踏まえて事前に決めたもの。
監査の進め方：計画から本調査まで
監査項目について、十分かつ適切な監査証拠を入手するための手順。
⚠ 計画立案・報告書作成・チーム編成は監査手続ではない
監査の進め方：計画から本調査まで
資料の閲覧、ヒアリング、突き合わせなど、監査証拠を集めるための具体的な作業。
監査証拠と監査調書
監査人が証拠を集めるための方法（閲覧・観察・再実施・質問など）。
可用性とバックアップの監査
監査意見の根拠となる、閲覧・確認などで集めた事実や資料。
システム監査とは何か：目的・基準と監査人の立場
監査人が結論を出すための裏付けになる資料・記録・回答など。
監査の進め方：計画から本調査まで
監査人が監査意見の裏付けとして被監査部門から入手する運用記録などの客観的な資料。
⚠ 監査調書と混同しやすい。証拠は相手からもらうもので、調書は監査人が自分で書く記録。
監査証拠と監査調書
監査意見や指摘事項の裏付けとなる資料や記録。
⚠ 証拠の裏付けがない事項は、監査人が必要と思っても指摘事項にできない。
監査報告とフォローアップ
監査人が結論を出す根拠として集める記録や資料。
⚠ どの観点の証拠かを問われる。アクセスログは安全性、故障率の報告書は信頼性、CPU の性能評価は効率性。
セキュリティ管理策の監査指摘事項
監査対象システムの入力から出力に至る処理過程を、後から追跡できる仕組みと記録。
⚠ 監査調書は監査人が作業中に集めた・作った資料。監査証拠は監査手続で入手して評価した資料。
内部統制とコントロールの基本
監査人が監査業務の全過程で収集・作成した資料をまとめた記録。
⚠ 監査証跡はシステム側の追跡記録で、監査調書は監査人側の作業記録。
内部統制とコントロールの基本
監査人が行った監査手続とその結果を書き残した記録で、監査意見の根拠となるもの。
⚠ 監査報告書と混同しやすい。報告書は結論を依頼者に伝える文書で、調書は監査人側で保存する作業記録（公表義務はない）。
監査証拠と監査調書
監査の結論（監査意見・指摘事項・改善勧告）を依頼者に伝える文書。
⚠ 報告書に書いた指摘事項は監査人が作ったものなので監査証拠にはならない。
監査証拠と監査調書
監査の結果として、監査意見・指摘事項・改善勧告をまとめ、監査依頼者に提出する文書。
監査報告とフォローアップ
取締役の職務執行の監査の一環として、独立した立場から内部統制の整備・運用状況を監視・検証する者。
⚠ 基本方針を決めるのは取締役会。最終責任を負うのは経営者。
内部統制とコントロールの基本
リスクを下げるために組織が実施する具体的なセキュリティ対策（入退室管理、アクセス制御など）。
情報セキュリティ監査基準と ISMS
個別システムを作る前に、内容・費用・リスク・使い続ける期間などを固める段階。
⚠ 情報戦略は組織全体の方針。企画は1つのシステムの計画。
システム管理基準の構成と情報戦略
許可された人だけが情報にアクセスできる性質。
⚠ 完全性は内容が正しく改ざんされていないこと、可用性は必要なときに使えること。
開発工程と外部委託の監査チェックポイント・可用性とバックアップの監査
許可された人だけが情報にアクセスできる状態を保つこと。
⚠ 漏えい・不正使用のリスクには機密性の対策が答え。ドキュメントの更新や標準化は別の目的。
セキュリティ管理策の監査指摘事項
監査人が受け入れられる内部統制の逸脱率の上限で、サンプル件数を決めるときに使う。
⚠ サンプリングリスク（サンプルからの結論が全件を調べた場合と食い違うリスク）とは別物
監査の進め方：計画から本調査まで
企業が持つ人・物・金・情報などの資源。
⚠ 「部門予算の範囲内」は経営資源のごく一部しか見ていないため、誤りの選択肢になる。
監査報告とフォローアップ
内部統制を整備・運用する最終的な責任を負う者。
⚠ 監査役や監査人は監視・評価する立場で、責任者ではない。
内部統制とコントロールの基本
報告書を確定する前に、原案の内容を被監査部門と確認し合うこと。
⚠ 目的は事実誤認の確認。承認を得ることや、追加調査の代わりにすることではない。
監査報告とフォローアップ
個々の監査について対象・手続・日程などを定めた、監査人が作る計画書。
⚠ 監査人が作成した書類なので監査証拠ではない。
監査証拠と監査調書
認証局が、公開鍵とその持ち主を結び付けて保証する電子的な証明書。電子証明書とも呼ぶ。
⚠ 有効期間がある。署名した日と検証日の両方が期間内でないと検証できない。
セキュリティ管理策の監査指摘事項
CPU などの資源を無駄なく使い、必要な性能が出ていること。
⚠ CPU の性能評価レポートは効率性の証拠で、安全性の証拠ではない。
セキュリティ管理策の監査指摘事項
ある立場の人がどう行動すべきかを定めた決まり。
⚠ 判断尺度（何ができていれば合格かの物差し）とは別。
システム監査とは何か：目的・基準と監査人の立場
対策の前後で、障害原因別の件数と停止時間の実績を比べ、減ったかどうかを確かめること。
⚠ 報告書に記載があるか、承認されているかは形式の確認で、効果の確認ではない。
可用性とバックアップの監査
決算書などの財務情報を正しく作成・報告することで、内部統制の4つの目的の一つ。
⚠ 効果は「株主や取引先からの信頼向上」。「業務プロセスの効率化」は業務の有効性及び効率性の効果。
内部統制とコントロールの基本
監査で見つけた問題点を示し、改善を勧めること。
⚠ 改善命令は監査人の権限外。
システム監査とは何か：目的・基準と監査人の立場
監査で見つかった問題点として報告書に記載する内容。
⚠ 監査人が書くものなので監査証拠ではない。
監査証拠と監査調書
監査で見つかった不備のうち、監査人が証拠と重要性から報告が必要と判断したもの。
⚠ 被監査部門の承認は不要。ただし事前に事実誤認がないかは確認する。
監査報告とフォローアップ
監査で見つかった、改善が必要な問題点として監査報告書に記載する事項。
⚠ 「チェックポイント」はあるべき状態、「指摘事項」は問題がある状態。問い方の向きを逆に取らないこと。
開発工程と外部委託の監査チェックポイント
監査で見つかった問題点として、監査報告書に記載する事項。
⚠ 一見手間がかかっていそうでも、目的に照らして適切なものは指摘事項にならない。
可用性とバックアップの監査
監査人が基準と照らし合わせて不備だと判断し、監査報告書に書く事項。
⚠ 適切に運用されている状況は指摘しない。選択肢の中から穴のあるものを1つ選ぶ。
セキュリティ管理策の監査指摘事項
災害や事故が起きても業務を続ける、または早く再開するための対策の計画。
⚠ この単元では「〇〇を明確にする計画」の問題でダミー選択肢として出る。「あるべき姿」「費用・スケジュール」とは無関係。
システム管理基準の構成と情報戦略
調査結果の事実を取り違えて理解していること。
監査報告とフォローアップ
入力・処理した結果の一覧で、起票した業務部門が自分の原票と見比べて確認するためのもの。
入力・処理・データのコントロール
コントロールの改善に役立つ意見を監査人が提供すること。
⚠ 命令とは違い、実施するかどうかは相手が決める。
システム監査とは何か：目的・基準と監査人の立場
プルーフリストと伝票を突き合わせて確認したことを示すために押す印で、照合が行われた証拠になる。
入力・処理・データのコントロール
ネットワークやサーバなど、組織全体で共通に使う情報システムの土台。
システム管理基準の構成と情報戦略
経済産業省が定めた、情報セキュリティ監査を行う監査人の行動ルールと監査の進め方の基準。
⚠ 情報セキュリティ管理基準と混同しやすい。監査基準＝監査人のルール、管理基準＝判断に使う物差し。
情報セキュリティ監査基準と ISMS
組織が実施すべき情報セキュリティの管理策をまとめた基準で、情報セキュリティ監査の判断の尺度として原則使われるもの。
⚠ 監査基準との区別。「判断の尺度」と書かれていたら管理基準。
情報セキュリティ監査基準と ISMS
情報化にどれだけ投資するかを定める計画で、情報戦略の段階で策定する。
⚠ 開発計画の「投資効果」は個別システムの効果。全社の投資計画は情報戦略。
システム管理基準の構成と情報戦略
組織にとって価値のある情報と、それを扱う媒体全般のことで、電子データだけでなく紙や人の知識も含む。
⚠ 情報システムと混同しやすい。情報資産は紙も含むので、コンピュータの無い部署も監査対象になる。
情報セキュリティ監査基準と ISMS
経営戦略に沿って、組織全体の情報化の方針・あるべき姿・投資を決める段階。
⚠ 企画業務は個別システムの話。「組織全体」「経営戦略」が出たら情報戦略。
システム管理基準の構成と情報戦略
一つの業務の決定・承認・実行などを別々の人に分担させ、互いにチェックし合える（相互牽制）ようにすること。
⚠ 「自ら決定し自ら承認」は職務分離ができていない状態で、監査の指摘事項になる。
内部統制とコントロールの基本
障害が起きにくく、起きても処理を続けたり元に戻したりできること。
⚠ フェールソフト・フォールトトレラント・リカバリは信頼性に当たり、安全性ではない。
セキュリティ管理策の監査指摘事項
文書が本人によって作られ、改ざんされていないこと。
セキュリティ管理策の監査指摘事項
監査人が公正で客観的な態度を保ち、判断を曲げないこと。
⚠ 外観上の独立性は所属などの組織上の独立。
システム監査とは何か：目的・基準と監査人の立場
システム設計書の内容を関係者で確認し、誤りや要件の漏れを見つける作業。
開発工程と外部委託の監査チェックポイント
部分ごとではなく組織全体として最も効果が出るよう情報システムを整えることで、情報システム基盤の整備計画などを含む。
⚠ 個別システムの開発体制・スケジュール・ハードウェア導入スケジュールは含まない。
システム管理基準の構成と情報戦略
組織全体の情報システムのあるべき姿を明確にする計画で、情報戦略段階の成果物。
⚠ 開発計画は個別システムの費用・日程・体制の計画。「あるべき姿」なら全体最適化計画。
システム管理基準の構成と情報戦略
機器が故障してもシステム全体が止まらずに動き続けられる強さ。
可用性とバックアップの監査
プログラムを1本（1モジュール）ずつ動かして、正しく動くかを確かめるテスト。
⚠ システムテストは全体を組み合わせたテスト、受入れテストは利用者が受け取るかどうかを判断するテスト。
開発工程と外部委託の監査チェックポイント
サービスが止まって使えない時間。SLAでは上限を決めておく。
可用性とバックアップの監査
システムに必要な人・物・サービスを外部から買い入れること。
システム管理基準の構成と情報戦略
規格の附属書にある管理策ごとに、採用するかしないかとその理由をまとめた文書で、ISMS確立の最後に作るもの。
⚠ 手順の最初に置く選択肢はひっかけ。管理策を選び終えた後でないと書けない。
情報セキュリティ監査基準と ISMS
秘密鍵で文書に付ける署名。公開鍵で検証すると、本人が作成し改ざんされていないことを確かめられる。
セキュリティ管理策の監査指摘事項
CRYPTRECが安全性などを評価し、政府が利用を推奨する暗号アルゴリズムをまとめた一覧。
⚠ JCMVPと混同しやすい。リスト＝アルゴリズムの一覧、JCMVP＝暗号モジュールの認証制度。
情報セキュリティ監査基準と ISMS
監査人が監査対象と利害関係や身分上の関係を持たず、公正に判断できる状態。
⚠ 「業務に詳しいから被監査部門の人を入れる」は独立性違反
監査の進め方：計画から本調査まで
監査人が監査対象から利害関係や上下関係の面で切り離されていること。
⚠ 同じ会社の監査人でも、対象部門から独立していれば監査はできる。
監査証拠と監査調書
監査人が監査対象から離れていて利害関係を持たず、公正に判断できる状態。
⚠ 被監査部門のメンバーで監査チームを組む、自ら是正する、といった行為は独立性を損なう。
監査報告とフォローアップ
監査人が監査対象から離れた立場にあり、利害関係なく公正に判断できること。
⚠ 「専門性が高いから独立性は不要」という誤りの選択肢に注意。独立性は常に必要。
情報セキュリティ監査基準と ISMS
組織が自分たちのISMSがルールどおり運用されているかを、社内の監査人に点検させること。
情報セキュリティ監査基準と ISMS
モニタリングの一環として、内部統制の整備・運用状況を検討・評価し、必要に応じて改善を促す社内の担当者。
⚠ 外部監査人（監査法人など）は社外から、経営者による内部統制の評価が適正かを監査する。
内部統制とコントロールの基本
業務部門から独立し、社内の監査を担当する部門。
システム監査とは何か：目的・基準と監査人の立場
業務を正確・効率的に、不正なく進めるために組織内に設ける仕組み。
システム監査とは何か：目的・基準と監査人の立場
会社が業務の効率化・正しい財務報告・法令遵守・資産保全を達成するために社内に組み込む仕組みと手続。
⚠ システム監査と混同しやすい。内部統制は会社が作って運用する仕組みで、監査はそれを評価する活動。
内部統制とコントロールの基本
同じ役割の機器を複数用意し、1台が故障しても動き続けられるようにする構成。
⚠ バックアップ（データの写しを取っておくこと）とは別。二重化は止まらないため、バックアップは失ったデータを戻すため。
可用性とバックアップの監査
誰がいつ部屋に入り、いつ出たかを個人単位で制限・記録すること。
⚠ 共通の暗証番号では個人を特定できないので、入退室管理にならない。
セキュリティ管理策の監査指摘事項
業務部門が起票する、システムへ入力するデータの元になる伝票のこと。
⚠ プルーフリストは入力した後にシステムから出す一覧で、原票は入力前の元資料。
入力・処理・データのコントロール
1年間の運用の予定を定める、運用業務の計画。
システム管理基準の構成と情報戦略
起きてしまった誤りや不正を事後に見つける統制。
⚠ 「照合」「突き合わせ」「検知」が目印。立て直しまで行うのは復旧統制。
内部統制とコントロールの基本
監査で、対象が適切かどうかを判定するときに比べる基準。
情報セキュリティ監査基準と ISMS
監査で対象が適切かどうかを判定するための物差し。
⚠ システム監査ではシステム管理基準がこの役割を担う。
システム監査とは何か：目的・基準と監査人の立場
監査を受ける側の部門。
システム監査とは何か：目的・基準と監査人の立場・監査の進め方：計画から本調査まで
監査を受ける側の部署。
監査証拠と監査調書
監査を受ける側の部門で、改善計画の作成と改善の実施に責任を持つ。
⚠ 監査人と役割が逆になった選択肢が多い。是正・管理・計画策定はこちらの仕事。
監査報告とフォローアップ
規格の要求事項や組織の規定を満たしていない状態で、内部監査で指摘事項として報告する対象。
⚠ 事故やマルウェア検知そのものは不適合ではない。対応がルールどおりなら指摘不要。
情報セキュリティ監査基準と ISMS
事故や障害が起きた後に、業務やデータを元の状態に立て直す統制。
⚠ 運用計画や手順書は通常業務のルールなので予防統制。事故後に使う計画や復元だけが復旧統制。
内部統制とコントロールの基本
監査人が本番と同じ処理をするプログラムを用意して実データを処理し、本番の結果と一致するかでプログラムの論理の正確性を確かめる監査技法。
⚠ テストデータ法は「データを用意」、並行シミュレーション法は「プログラムを用意」と覚える。
入力・処理・データのコントロール
稼働中のシステムの不具合修正や変更要求への対応を行う段階。
⚠ 運用業務と混同しやすい。プログラムやデータに手を入れるのが保守。
システム管理基準の構成と情報戦略
監査の結果として、コントロールが適切であることを第三者として表明すること。
⚠ 助言は改善のアドバイス。どちらも監査人の役割。
システム監査とは何か：目的・基準と監査人の立場
監査手続書に沿って、十分かつ適切な監査証拠を入手し評価する調査。
⚠ 予備調査は実態の把握が目的
監査の進め方：計画から本調査まで
本調査に先立ち、監査対象業務の実態を把握するために行う調査。
⚠ 本調査は証拠の入手が目的。計画の調整や本調査の補完ではない
監査の進め方：計画から本調査まで
誤りや不正が起きる前にそれを防ぐ統制。
⚠ 発見統制は起きた後に見つける。アクセス権の付与・画面設計・教育・運用手順書は予防統制。
内部統制とコントロールの基本
システムを実際に業務で使う部門。要件を一番よく知っている。
⚠ システム部門（開発部門）は作る側、運用部門は動かし続ける側。
開発工程と外部委託の監査チェックポイント
聞いた話が事実かどうかを文書や記録で確かめること。
監査証拠と監査調書
入力値が項目同士の関係として矛盾しないか、決められた桁数や文字種の形式に合っているかを入力時に検査すること。
⚠ 入力時の個別チェックであり、伝票全体の漏れ・重複は確かめられない。
入力・処理・データのコントロール
納品物に欠陥があったとき、作った側が修補や賠償を負う責任。現在の民法では契約不適合責任と呼ぶ。
⚠ 委託先が存続していることが前提なので、破綻への備えにはならない。
開発工程と外部委託の監査チェックポイント