San Antonio API Security Summit 2025 に参加しよう!
San Antonio API Security Summit 2025 に参加しよう!
San Antonio API Security Summit 2025 に参加しよう!
San Antonio API Security Summit 2025 に参加しよう!
San Antonio API Security Summit 2025 に参加しよう!
San Antonio API Security Summit 2025 に参加しよう!
閉じる
プライバシー設定
ウェブサイト運営に必要なCookieや類似技術を使用しています。追加のCookieは貴社の同意がある場合のみ利用されます。同意は「Agree」をクリックすることでいただけます。どのデータが収集され、どのようにパートナーと共有されているかの詳細は、Cookieポリシープライバシーポリシーをご確認ください。
Cookieは、貴社デバイスの特性や、IPアドレス、閲覧履歴、位置情報、固有識別子などの特定の個人情報を取得、解析、保存するために使用されます。これらのデータは様々な目的で利用されます。分析Cookieによりパフォーマンスを評価し、オンライン体験やキャンペーンの効果向上に役立てます。パーソナライズCookieは、利用状況に応じた情報やサポートを通じ、貴社専用の体験を提供します。広告Cookieは、第三者が貴社のデータをもとにオーディエンスリストを作成し、ソーシャルメディアやネット上でのターゲット広告に使用します。貴社は各ページ下部のリンクから、いつでも同意の許可、拒否、または撤回が可能です。
ご送信ありがとうございます。内容を受け付けました。
申し訳ありません。フォーム送信時にエラーが発生しました。
/
/
Pentest

SOC 2 Type 2 ガイド:SOC 2監査プロセス 第2部

監査範囲となるシステムの把握、ポリシーと手続きの策定、リスク低減のための新たなセキュリティ管理策の導入を含みます。

準備が整いましたら、認可されたCPA監査人のサービスを利用して監査を実施します。実際のプロセスは、範囲設定、資料の収集、現地訪問などが含まれ、電話での説明に数時間、現地での面談に2日程を要します。SOC 2監査の範囲を設定する際、まずType IかType IIかの監査種類を決定することが重要です。

初めての方には、数値やローマ数字が多く混在しており、用語が分かりにくいかもしれません。

著者
SOC 2 Type 2 ガイド:SOC 2監査プロセス 第2部

覚えやすい簡単な方法は次のとおりです: 

S = 範囲,
T = 時間.
つまり,
SOC 1 = 財務範囲.
SOC 2 = 情報セキュリティ範囲.
Type I = ある一点の時刻において.
Type II = 過去6ヶ月間にわたって.


SOC 2 を有利に活かす

SaaSプロバイダー選定が貴社と競合他社の間で行われる際、SOC 2 Type IIに準拠していることは選ばれる可能性を高めます。SOC 2準拠である点と監査の種類を明示することは、特に先を見据える企業に好まれる要素となります。

消費者の88%は購入前にオンラインで選択肢を調べるため、貴社のSOC 2準拠をウェブサイト上で強調することが重要です。

例えばIntercomは、セキュリティ対策専用のページにSOC 2準拠の詳細を掲載しています。

Intercomのように、SOC 2 Type IIの報告書を取得した際には、以下の情報をウェブサイトに追加してください:

  • 5つの信頼サービス原則のうち、どれに準拠しているかを明示する
  • 各原則について、内部で実施した手続きの概要を記載する
  • セキュリティチームの連絡先を掲載し、詳細情報の問い合わせ先を示す

米国人口のおよそ77%がソーシャルメディアアカウントを持っているため、TwitterやFacebookなどのプラットフォームでSOC 2の状況を共有するなど、一歩進んだ対応も検討してください。これにより、潜在顧客が最も利用する場所で情報が目に留まり、データセキュリティ基準について更なる情報提供が可能になります。

SOC 2準拠の情報発信には工夫を凝らし、対象となる方々が多く集まるオンラインの場所に展開することが望ましいです。宣伝戦略には業界プラットフォームやソーシャルメディアの活用も含めるとよいでしょう。

SOC 2準拠の始め方

顧客のニーズに応えることは成功の要です。顧客の意見を参考にしながら、SOC 2準拠が実際のニーズに合致しているか確認してください。

顧客のニーズを把握する方法はいくつかあります。以下に例を示します:

ソーシャルメディア上のフォロワーのコメントを確認してください。Facebookのビジネスページでは、投稿に対するコメント、シェアされる内容、肯定的または否定的なフィードバックをチェックすることができます。

  • サポートチームに寄せられる質問や問い合わせ内容を確認する。顧客は、問題発生時、機能が正常に動作しない場合、またはサービス全体に満足できない際に連絡するため、このフィードバックを参考により良い対応方法を検討してください。
  • 上記を基にした短いアンケートメールを送信し、顧客のニーズをさらに絞り込む。選択式の質問に加え、自由記述の質問で理由を尋ねると有効です。
  • ウェブサイトのリード獲得フォームを活用して顧客のニーズを調査する。リードが氏名やメールアドレスを入力した際、確認画面で選択式の質問を設け、最も重要な項目を選んでもらいましょう。
  • 機能価値分析を実施し、顧客がアプリをどのように利用しているか調査する。利用状況から、重要な機能やサポート方法が見えてきます。
  • 収集したデータを分析してターゲット顧客が最も求めているものを把握し、その知見を手続きに反映、注力すべき原則を選定してください。


SOC 2の原則が一貫して守られているか定期的に監査する

技術の進化とともに、既知・未知の脅威が増大しているため、事業で重視するSOC 2の原則について定期的な監査が必要です。

例としてAuth0を挙げます。Auth0では1日に3~4回新リリースが行われ、各リリースを追跡するためのプロセスが整備されています。SOC 2 Type II報告書のセキュリティ原則に基づく手続きでは、更新内容はステージングから本番環境に移行する前に、別のメンバーの承認が必要となります。

また、Auth0ではコード、ユーザーインターフェース、APIが正しく動作しているか確認するため、機能テスト、機能テスト、HTTPテストの3種類の検証を継続的に実施しています。これらのテストはSlack連携を活用しており、実施履歴も記録されています。

SOC 2 Type II報告書および監査のためのポリシーと手続きを策定する際、以下の質問を参考にしてください。これらの質問はすべての原則に共通です:

  • 本当に対処すべき脅威があるかを判断する基準は何か?
  • 最初に通知されるのは誰で、どのような対応をするのか?
  • クラウドストレージ環境における通常状態はどのように定義するか?
  • クラウド環境にはどのような脅威が存在するか?
  • 顧客にはいつ問題が通知されるか?
  • 顧客に送付する情報は何か?
  • 問題解決中、どの程度の頻度で顧客に連絡するか?
  • どの方法(メール、テキスト、ソーシャル等)で情報を共有するか?
  • ドキュメントはどこに保管するか?
  • チーム内の誰でも容易に確認できる状態か?
  • 顧客が変更履歴を確認できる場所はあるか?

これらの質問への回答がSOC 2報告書の基盤を作り、将来の脅威に対応するための計画策定に役立ちます。


監査準備

監査準備として、以下の4つのステップがあります:

  • 監査の目的を決定する。SOC 2 Type IかType IIか、どちらの監査が必要かを判断します。現状の手続きが正しく整備されているかだけを確認するならType I、一定期間にわたる運用状況も確認するならType IIを選択してください。
  • 業務範囲に関する規制を確認する。業種やニッチに応じて、関連する地方、州、または連邦の規制・方針・ルールを調査し、事業運営に関する法律を把握していることを文書で示してください。
  • プロセスの文書化を行う。監査準備の一環として、CPAがSOC 2認証取得の判断材料とするために、手続きの重要な詳細を記録してください。上記の11の質問を手続きガイド作成の出発点として活用しましょう。
  • 実際の監査に備えた事前テストを実施する。文書の各セクションを確認し、発生しうる脅威に対応しているか検証してください。この事前テストで問題点を発見し、監査前に解決することができます。

SOC 2準拠監査にはType IとType IIがあり、通常、SOC 2 Type IIはより多くの時間が必要です。監査予定の数ヶ月前から準備を開始し、問題の発見と解決、そして手続きが原則を十分に支えているか確認してください。セキュリティ強化、文書の更新、チームへの情報共有の機会を見逃さないよう努めましょう。

soc2 audit

避けるべきSOC 2の落とし穴

SOC 2監査の準備中に注意すべき5つのポイントは以下の通りです:

1. 監査報告書の範囲設定が不十分で、データシステムの境界やサービスが明確でないこと。

多くの企業が犯す重大なミスは、SOC 2報告書で定義されたシステムからどのサービスを利用し、または除外するかを明確に定義しないことです。

2. 対象となる主要内部統制の文書化が不十分であること

経営陣またはCTOは、システムの主要な内部統制についての説明を作成する必要があります。以下の点を十分に説明してください:

  • システムの設計
  • システムのインフラ
  • システムで使用するソフト
  • システムが扱うデータおよび情報

3. 事前評価を行わずに監査テストを開始すること

組織が準備できていない状態でSOC 2監査を開始すると、監査プロセスが長引き、時間とコストの無駄につながります。監査パートナーに事前評価を依頼し、問題点を洗い出して解決してください。

4. 自社環境と第三者との間で監査の境界が明確でないこと

多くの企業は外部ベンダーを利用して業務を行っています。例としてクラウドサービスプロバイダーなどが挙げられます。自社とそのサービス提供者との間で、コンプライアンスの範囲を明確に分ける必要があります。

5. 複数のコンプライアンス要件を一つのSOC報告書に統合しないこと

その他のコンプライアンス要件をSOC報告書に統合する機会を逃さないでください。SOC 2報告書に関連事項を含めることで、コストやリソースの負担を軽減できます。

データセキュリティはビジネス成功の鍵です。IntercomやAuth0のような企業は、SOC 2準拠の価値を実証しています。これらの成長や成功がすべて認証によるものではありませんが、大手企業の獲得に寄与しているのは確かです。中小企業や大企業も、貴社がセキュリティ脅威に備えていると確信できることを求めています。その結果、こうした顧客は貴社を選び、取引先に紹介する可能性が高まります。

SOC 2準拠を検討すべきタイミングはいつか

大手企業に技術サービスを提供し、あるいは重要な顧客データを取り扱う場合、早期にSOC 2準拠を検討するのが望ましいです。

規模が小さくリソースが限られているときはSOC 2準拠の取り組みは困難かもしれませんが、企業が成長すると、組織文化、プロセス、ツールなどの変更はさらに難しくなります。

小規模な段階ではITやセキュリティ担当者がいない場合もありますが、そのような人材を採用した段階で、SOC 2準拠の準備を始めるとよいでしょう。早めの対策は、手続きや管理体制をチームの文化に定着させるために有効です。

前編

FAQ

参考資料

最新情報を購読

更新日:
February 25, 2025
学習目標
最新情報を購読
購読
関連トピック