SOC業務の計画と実施
章構成を新カリキュラムに刷新しました。旧構成との対応は移行ガイドをご覧ください。
ストーリー(冒頭プレビュー)
🦉 Episode 9: 「今日は大丈夫です」で終わらない
登場: 🦉 カイロウ(新人)/💼 先輩(IT監査部門)/🏢 元町さん(クライアントの情報セキュリティ担当)
今日のスクリーンショット
訪問先は、企業向けに勤怠管理のクラウドサービスを提供する会社だった。この会社を利用している取引先に向けて出す報告書のために、先輩たちのチームが統制の状況を確認している。取引先の一社から、契約更新の条件としてこの報告書の提出を求められており、期限は来月末になっているという。カイロウは今日が現地での確認作業に加わる初日だった。
先輩から、四半期ごとのアクセス権限見直しの証拠を集めるよう頼まれた。
🦉「元町さん、権限の見直しがきちんとできているか確認したいんです。何か見せていただけますか」
🏢「今の権限一覧なら、今ここで画面をお見せできますよ」
元町さんが画面を開くと、担当者ごとの権限が整理された一覧が表示された。営業・経理・システム管理の3つの部門ごとに色分けされていて、更新日の欄には今日の日付が並んでいる。
🦉「更新日、全部同じ日になっていますね」
🏢「今朝、念のため見直しておいたので」
🦉「ちゃんと整理されていますね。これで大丈夫そうです」
🏢「毎回のことなので、慣れたものです」
カイロウはその画面を写真に収め、先輩に報告した。
先輩の一言
先輩は写真を見て、少し首をかしげた。
💼「これ、今日時点の状態だよね」
🦉「はい、さっき元町さんに見せてもらいました」
💼「今日ちゃんとしているかどうかじゃないんだよ。対象になっている期間ずっとできていたかを見るんだ」
🦉「今日だけ整えて見せている、という可能性もあるということですか」
💼「そう疑うわけじゃないけど、証拠として見せるべきものが違うんだ。期間中の各四半期に、実際に見直しをした記録が要る」
元町さんが少し困ったように言った。
🏢「見直し自体は毎回やっているんですが、記録として残しているかは、確認してみないと分かりません。口頭で確認して終わりにしていた四半期もあった気がします」
元町さんは共有フォルダを開いた。「Q1見直し.xlsx」「Q3見直し.xlsx」の2つはすぐに見つかったが、Q2とQ4にあたるファイルは見当たらない。
🦉「4つの四半期のうち、2つしか残っていないんですね」
🏢「Q2は担当が忙しくて、メールで簡単にやり取りしただけだったかもしれません」
🦉「Q4のほうは、何か理由があったんですか」
🏢「Q4はちょうど担当者が交代した時期で、引き継ぎのときに漏れてしまったんだと思います」
インプット(冒頭プレビュー)
この章の試験での位置づけ
| 項目 | 内容 |
|---|---|
| 所属エリア | Area III --- システムおよび組織統制(System and Organization Controls、SOC)業務に関する考慮事項 |
| Blueprint参照 | Area III-A --- SOC業務の計画と実施に固有の考慮事項 |
| エリア出題比率 | 15%〜25% |
⏱ 読了目安: 約154分(インプット教材のみ・個人差があります)。一度に読み切る必要はありません。キリのよいセクションで区切って進めてください。
Area IIIはISC全体の中では出題比率が相対的に低いエリアだが、範囲が絞られている分、SOC1・SOC2・SOC3の区別やType1・Type2の違いといった「定義の正確さ」がそのまま得点に直結しやすい領域でもある。
前提知識 --- この章に入る前に、分かっているとラクなこと
| 前提知識 | なぜ必要か |
|---|---|
| 証明業務(Attestation engagement)の基本構造(依頼人・実施者・想定利用者の三者関係) | SOC業務も証明業務の一種であり、「誰が」「何を」「誰のために」保証するのかという枠組みを先に押さえておくと、SOC1〜3の違いが素直に頭に入る |
| 信頼できるサービス基準(Trust Services Criteria、TSC。詳細は別の章で扱う) | SOC2・SOC3が何を評価規準にしているかの名前だけでも知っておくと、本章の説明がスムーズになる |
| 内部統制における「デザイン(設計)」と「オペレーション(運用)」の違い | Type1報告書とType2報告書の違いは、この2つのどちらまでを保証するかの違いにほぼ一致する |
| 監査証拠におけるサンプリングの基本的な考え方(全件ではなく一部を見て母集団を推定する) | 本章末のサンプリング論点の前提になる |
1. なぜこの論点が必要か(Why)
【SOC業務の全体プロセス】
受嘱の判断 → スコーピング(範囲確定) → リスク評価 → 統制のテスト(デザイン→運用) → 意見の形成・報告
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
← 今ここ(本章の範囲) → (報告の詳細は次章)
想像してほしい。あなたの所属する監査法人に、クラウド型の経費精算SaaSを提供するサービス組織から「取引先の監査人からSOC 2報告書を求められたので対応してほしい」という依頼が来たとする。この時点で処理すべき問いは、実は驚くほど多い。そもそもSOC 1ではなくSOC 2で正しいのか。報告対象の期間はどこからどこまでか。この経費精算SaaSが裏側で利用しているクラウドインフラ事業者(サブサービス組織)の統制はどう扱うか。限られた期間でどこまでテストすれば十分な証拠と言えるか。これらを報告書を書き始める前に決めておかないと、あとから「実はスコープが間違っていた」と言い直すことはできない。
続きとアウトプット演習・整理ノートはISC教材(購入者限定)でご覧いただけます。