KAIRO
KAIRO
9Chapter 9

SOC業務の計画と実施

Part 3: システムおよび組織統制(SOC)業務に関する考慮事項Blueprint Area III 対応・配点 15-25%読了目安 約154分

章構成を新カリキュラムに刷新しました。旧構成との対応は移行ガイドをご覧ください。

ストーリー(冒頭プレビュー)

🦉 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教材(購入者限定)でご覧いただけます。

この章は購入者限定コンテンツです

Chapter 1は無料でお読みいただけます。Chapter 2以降は教材を購入するとすべてご覧いただけます。