AWSやSlackなどのクラウドサービスには、管理状況を第三者が評価したSOC 2報告書があります。営業担当者の「安全に運用しています」という説明だけでなく、評価した対象や、実際の運用を確かめる資料です。
経営者や事業責任者が全文を一人で精読する必要はありません。担当者に報告書の入手と確認を依頼し、自社の使い方に影響する問題がないかを判断に反映することに意味があります。
自社でも追加費用を払って取得しましょう、という話ではありません。今回は、サービスを利用する会社がSOC 2をどう活用できるかを説明します。
SOC2とは？誰のために作る報告書なのか
SOCはSystem and Organization Controlsの略です。SOC 2は、サービス提供会社のセキュリティなどに関する内部統制を、独立した監査人が評価した報告書です。内部統制とは、業務が適切に行われるための管理の仕組みを指します。
例えば、権限を付与する時に承認する、退職者の権限を削除する、障害へ対応する、変更を検証する、といった管理が対象になります。セキュリティを監視する組織のSOCとは別の意味です。
提供会社が監査を受け、その結果を顧客や顧客の監査人などへ提示します。顧客が一社ずつ立ち入り、同じ管理内容を最初から調べる負担を減らす判断材料になります。
AWS・Slackなどで、実際にどう提供されている？
| 提供会社 | 報告書の入手・提供方法 |
|---|---|
| AWS | AWS Artifactから取得。SOC 2は年2回発行し、各報告書は過去12か月を対象とする |
| Slack | コンプライアンスのページからSOC 2の写しを請求できる |
| マネーフォワード Admina | SOC 2 Type 2の開示申請を受け付けている |
AWS Artifactの資料は無料で提供されています。報告書によって利用条件があるため、入手後の社外共有はその条件に沿って扱います。
実務では、導入担当者が候補サービスを選び、セキュリティ担当者や監査担当者が報告書を確認し、必要な追加質問を提供会社へ送る、といった使い方になります。小規模な会社なら、社内の責任者と外部専門家で役割を分けることも考えられます。
Type1・Type2、SOC1・SOC3、ISMSとの違い
Type2は、一定期間の運用まで評価する
| 種類 | 見る対象 |
|---|---|
| Type 1 | 特定時点の管理の仕組みが適切に設計されているか |
| Type 2 | 設計に加え、一定期間に実際に有効に運用されていたか |
ルールがあることと、毎回実施されることは違います。例えば退職時に権限を消す規程があっても、対象期間中の削除に遅れがあれば、その運用は別に評価されます。
報告書は対象時点・期間についての評価です。有効期限付きの免許と同じではありませんが、古い報告書だけでは現在の運用を把握しにくくなります。報告対象の期間と、その後の変更を合わせて確認します。
SOC1・SOC3・ISMSとの違い
| 資料・制度 | 主な役割 |
|---|---|
| SOC 1 | 利用企業の財務報告に関係する内部統制の評価 |
| SOC 2 | セキュリティ等の管理を評価した詳細な報告 |
| SOC 3 | 関連する評価結果を、一般公開に適した形式で示す報告 |
| ISMS認証 | 定めた適用範囲の情報セキュリティ管理が規格に適合していることを認証 |
ISMSも運用や改善を含むため、「ISMSは書類だけ、SOC 2だけが実態を見る」という区別は適切ではありません。受け取れる情報の形式・詳しさや、対象の捉え方が異なります。ISMSとPマークの比較では、組織認証を別の角度から説明しています。
報告書では何を確認する？導入判断につながる五つの点
1．使うサービスと機能が対象に入っているか
会社がSOC 2報告書を持っていても、すべての製品や機能が対象とは限りません。サービス名、対象システム、拠点などを、自社の利用範囲と照合します。
SaaSがAWS上で動いているからといって、AWSの報告書だけでSaaS側の権限管理や開発・運用まで評価されたことにはなりません。基盤とサービス運営の範囲を分けることが大切です。
2．どの基準について評価したか
SOC 2の基準には、セキュリティ、可用性、処理のインテグリティ、機密保持、プライバシーがあります。すべてが必ず対象になるわけではありません。
例えば、自社が停止時間を重視しているのに、セキュリティの評価だけを見て復旧能力まで確認できたと考えると、判断に抜けが生まれます。契約のサービス水準や復旧に関する説明と合わせて読むことになります。
3．対象期間は、現在の運用に近いか
報告期間後に大きなシステム変更やサービス追加があれば、その扱いも確認対象です。新しい報告書が発行されるまでの期間について、提供会社が補足資料を用意している場合もあります。
4．監査人の意見と、テストで見つかった例外は何か
Type 2では、監査人の実施した検証と結果が重要です。問題の指摘があったから即座に不採用とするのではなく、どの管理で、どの程度起き、自社の利用へどう影響するかを確認します。
例えば権限削除の遅れなら、対象となったシステム、遅れの規模、他の管理で補われたか、改善が済んでいるかで受け止め方が変わります。これは読み方の説明例で、特定企業の監査指摘ではありません。
5．利用企業で実施することは何か
提供会社の管理だけで、サービス全体の安全性が完結するとは限りません。報告書には、利用企業側に求める管理が記載されることがあります。
例えば利用者の登録・削除、多要素認証、権限の設定などです。提供会社が適切に管理していても、自社の退職者アカウントが残っていれば、自社側のリスクは残ります。
経営者・責任者は、担当者へどう依頼するとよい？
「SOC 2がありますか」だけでなく、次のように判断へ必要な回答を依頼すると使いやすくなります。
- 今回使うサービス・機能が評価対象か。
- 利用に影響する指摘や、報告期間後の変更があるか。
- 自社で実施する管理と、その担当者は決まっているか。
- 残る問題が、導入を止めるものか、追加対策で扱えるものか。
経営者が知りたいのは、報告書のページ数より、このサービスをこの条件で使ってよいかです。技術的な確認結果を、その判断へつながる説明にまとめてもらうことが重要になります。
SOC2報告書がないサービスは使えない？
SOC 2がないことだけで、安全性の低いサービスと決めることはできません。他の第三者評価、契約、運用資料、個別の確認などから判断する場合もあります。
一方、重要な情報を預けるのに説明資料が十分得られないなら、利用範囲を限定する、追加確認をする、別の候補と比較するといった判断につながります。報告書は必須のロゴを探すためではなく、管理状況を具体的に確かめるための資料です。
まとめ｜「取得済み」ではなく、自社の使い方と照合する
SOC 2は、提供会社が管理状況を説明し、利用企業が確認するために、実際のクラウド取引で使われている報告書です。
導入時や重要な更新時には、担当者へ入手・確認を依頼できると、自己申告だけに頼らない判断ができます。評価された範囲、指摘、自社に残る管理を、自分たちの利用方法と結び付けることが活用の要点です。
参考資料
- AICPA：SOCの説明：制度の目的。
- デロイト トーマツ：SOC2報告書：評価基準と報告書。
- AWS：SOC、AWS Artifact：提供範囲、発行頻度、入手方法。
- Slack：コンプライアンス、Admina：セキュリティ：顧客向けの提供例。
- CSA：SaaS利用者向けガバナンスのベストプラクティス日本語版：外部評価の活用、基盤とサービスの範囲の違い。
本記事の文章・表・図解・グラフは、Skill Business Architecture Labが独自に編集・作成しています。引用・紹介する場合は、引用箇所が分かる形で、記事名・サイト名・記事URLをご記載ください。
コメント