Trupeer Blog
要約
SOC 2 は、AICPA の 5 つの Trust Services Criteria に対する独立した保証（アテステーション）です。Security は必須で、その他の基準は任意であり、かつ貴社のサービス範囲にスコープされます。これは認証ではありません。レポートは、貴社の統制が適切に設計されているか、また（Type II の場合）それらが時間の経過とともに有効に運用されていたかを示します。
おそらく、見込み客、調達チーム、またはセキュリティ質問票によって SOC 2 レポートを求められたから、ここに来たのではないでしょうか。誰かが「認証だ」と言ったかもしれませんし、別の誰かが「Type I と Type II のどちらか」を尋ねたかもしれません。そしてエンジニアリングチームは、監査人が必要とするスクリーンショット、チケット、ログが何なのかを気にしているかもしれません。
私は以前から、この混乱をチームと一緒に解いてきました。SOC 2 のコンプライアンスを「購入するバッジ」として考えるのではなく、実際に運用され、証拠として提示できる統制によって、組織が顧客情報を保護していることを示すための、構造化された方法だと捉えるのが有益です。
目次
実務における SOC 2 コンプライアンスの意味
SOC 2 コンプライアンスは認証ではなく、独立した保証（アテステーション）レポートです。 AICPA は 2009 年に SOC 2 を導入しました。これは、サービス組織における統制に焦点を当てた監査レポートであり、独立した監査人が、それらの統制を選定された Trust Services Criteria に照らして評価します。PwC による SOC 2 の説明は、フレームワークがどのように機能するかを理解するうえで役立つ背景情報を提供しています。
平易に言うと、サービス組織とは、別の会社に対して重要なサービスを提供する会社のことです。顧客の財務データを保存する B2B 請求プラットフォームは、わかりやすい例です。顧客は、アクセスが制限されていること、変更が管理されていること、インシデントが適切に扱われていること、そしてサービスが確実に動作することに対する安心を求めています。
レポートは、エンタープライズ顧客、調達チーム、ベンダーリスクのレビュー担当者、規制当局など、独立した保証を必要とする人向けに書かれています。通常、機微な運用の詳細が含まれるため、組織は NDA（秘密保持契約）または管理されたトラストセンターを通じて顧客に共有することが一般的です。公開されたマーケティングページで「監査が存在する」と述べることはできますが、詳細なレポートは通常、リスクを評価する人のためのものです。
SOC 2 エンゲージメントの構成要素
私はプロセスを 4 つの質問で説明します：
どのサービスが評価対象ですか？ サービスを支えるシステム、人、プロセス、拠点を定義します。
どのリスクが重要ですか？ 顧客のコミットメントとサービスモデルに合う Trust Services Criteria を選択します。
それらのリスクに対応する統制は何ですか？ アクセス管理、モニタリング、変更管理、インシデント対応、および関連する活動に対する期待を対応づけます。
統制が機能していることを証明する証拠は何ですか？ 統制が適切に設計されていること、また（Type II の場合）一貫して運用されていることを示す記録を収集します。
Security はすべての SOC 2 レポートで必須です。可用性、Processing Integrity、Confidentiality、Privacy は任意なので、企業は自動的に 5 つすべてを含めるわけではありません。
実務上のルール： SOC 2 レポートは顧客の保証に関する質問に答えますが、考えられるすべてのセキュリティリスクが消えたことを保証するものではありません。
ベンダーを評価している場合は、SOC 2 トラストセンターが有用な出発点になることがありますが、それでもレポートのスコープ、日付、含まれる基準、監査人の意見、そして例外事項を確認したいはずです。たとえば Trupeer は SOC 2 Type II と ISO 27001 の認証を保有し、トラストセンターを通じてセキュリティの詳細を共有しています。
要点： SOC 2 のコンプライアンスとは、サービスに合致する統制環境を構築し、独立して検証することです。これは保証の証拠であり、恒久的な証明書や万能のセキュリティ保証ではありません。
5 つの Trust Services Criteria を解説
5 つの Trust Services Criteria は、Security、Availability、Processing Integrity、Confidentiality、Privacy です。 Security はすべてのエンゲージメントで必須ですが、残りの 4 つはサービス、顧客の約束、リスクに応じて選択されます。
Security が基準値を決める
Security は、組織がシステムと情報を、不正なアクセス、利用、または改変から保護しているかどうかを問います。実務では、アイデンティティの統制、論理および物理のアクセス制限、システム運用、モニタリング、変更管理が含まれます。Security の基準は、AICPA の Common Criteria に対応づけられることが一般的で、CC1 から CC9 としてよく説明される統制も含まれます。SOC 2 Trust Services Criteria のガイダンスでは、これらの統制が運用上のリスクとどのようにつながるかが説明されています。
すべての SaaS 企業はここから始まります。チームが「誰が本番環境にアクセスできるのか」「アクセスはどのように承認されるのか」「疑わしい活動はどう検知されるのか」を示せない場合、任意の基準がエンゲージメントを救うことはありません。これらの統制が置かれている、より広いプログラムについては、エンタープライズセキュリティとは何かと、そのレイヤーがどのように組み合わさるかをご覧ください。
顧客が稼働率（アップタイム）に依存している場合、可用性が重要
可用性は、サービスが約束どおりに運用・利用できる状態で提供されているかをカバーします。稼働率（アップタイム）のコミットメント、キャパシティプランニング、バックアップ手順、ディザスタリカバリ、リカバリーテストにつながります。
契約上の可用性コミットメントがあるインフラ基盤、ホスト型データベース、またはワークフローシステムでは、この基準を不可欠だと考えることが多いでしょう。可用性の約束がない小規模な社内ツールでは、同じスコープが必要ない場合もあります。
Processing Integrity は「信頼できる成果」について
Processing Integrity は、システムの処理が 完全で、正当で、正確で、適時で、かつ承認されているかどうかを問います。これは特に、ソフトウェアが請求書を計算する、取引をルーティングする、レポートを生成する、または顧客データを変換する場合に重要です。
請求プラットフォームの例で言えば、データベースが保護されているかどうかだけが問題ではありません。顧客は、請求書が正しく計算されていること、そして失敗した処理や重複した処理が検知され、適切に扱われることにも安心を求めています。
Confidentiality は制限された情報を保護する
Confidentiality は、組織が不正な開示から保護することに合意している情報に焦点を当てます。データプロセッサは、顧客が機微な記録、ソースファイル、またはビジネス情報の保持を「制限された状態」であることを期待しているため、この基準をスコープに含めることがあります。
統制には、権限、暗号化、データ分類、保管（保持）ルール、安全な削除などが含まれ得ます。適切なスコープは、製品に付けられたラベルではなく、顧客に対して行ったコミットメントに依存します。
Privacy は個人情報に対応する
Privacy は、個人情報の取り扱いに関する懸念です。収集、利用、保持、開示、廃棄の方法を含みます。ユーザープロフィールや顧客から提供された個人データを保存する製品では、この基準をプライバシー義務と併せて検討する必要があるかもしれません。
私は、チームが競合のリストを見て基準を選ぶことが多いと感じています。それは逆です。契約書にある約束と、アーキテクチャ上のリスクから始め、その約束を監査人が検証できる基準を選びましょう。
アクセス制御を実務的に見るには、ナレッジベース向けのセキュリティ統制が、アイデンティティと権限が情報保護につながる例として役立ちます。
要点：基準は、サービスの「実際のリスク」を中心にスコープしてください。Security は基準値ですが、他の基準は、顧客があなたに「提供され、保護されること」を頼りにしている内容を反映すべきです。
SOC 2 Type I と Type II の違い、およびそれぞれを追求するタイミング
調達ミーティングでは、ある質問が決め手になります。「セキュリティ統制が機能していることを示せますか？」その答えは、Type I レポートがあるのか、Type II レポートがあるのか、あるいはどちらもないのかによって変わります。Type I は、特定の時点における統制設計を評価します。Type II は、レビュー期間にわたる設計と運用の有効性を評価し、一般的に 6〜12 か月です。 Type I と Type II の監査上の違いが重要なのは、ポリシーのスナップショットでは、人々がプロセスを繰り返し実行していたことを示せないからです。
Type I レポートは「この日付時点で、統制は適切に設計されていましたか？」に答えます。Type II レポートは「それらの統制は適切に設計されており、レビュー期間を通じて効果的に運用されていましたか？」に答えます。私の経験では、この違いは、Type I をレシピの検査、Type II をそこから作られた食事を時間をかけて確認すること、と捉えると理解しやすくなります。
SOC 2 Type I と Type II を一目で比較
項目 | Type I | Type II |
|---|---|---|
評価する内容 | 特定の時点における統制設計 | レビュー期間における統制設計と運用の有効性 |
証拠のパターン | ポリシー、設定、統制の存在 | アクセスレビュー、モニタリング、リカバリーテストなどの反復記録 |
典型的なスケジュール | エンドツーエンドで約 3〜6 か月（公開されている SOC 2 のスケジュールガイダンスに基づく） | 観察期間を通じて証拠が蓄積する必要があるため、一般的に 6〜12 か月以上 |
買い手の解釈 | 統制環境が設計されていることを示す | 統制環境が一貫して運用されていたことを示す、より強い証拠を提供する |
最適なケース | 初めてのレポート準備中、または直近の調達ニーズがある企業 | 成熟した統制を持ち、テストを支える十分な運用履歴がある企業 |
私は通常、Type I を「ゴール」ではなく「意図的な踏み台」として扱うことをおすすめします。スコープを確立し、ギャップを明らかにし、組織がより長い証拠の履歴を構築している間に、営業チームに対してアテステーションレポートを提供できます。
Type II には、一貫した運用の習慣が必要です。監査人は、レビュー期間を通じて、繰り返し行われるアクセスレビュー、デプロイ承認、リカバリー演習、モニタリング記録をテストする場合があります。監査当日に撮影したスクリーンショットは、その時点で設定が存在していたことを証明します。しかし、それが期間を通じて機能していたことまでは証明しません。
たとえば、エンタープライズの買い手が「退職した元従業員のアクセスは、速やかに失われますか？」と尋ねたとします。Type I レポートでは、オフボーディングのプロセスが存在し、適切に設計されていることが示されるかもしれません。Type II レポートには、繰り返し行われたオフボーディングの記録を含めることができ、そのプロセスが説明どおりに運用されていたかどうかを示せます。
これらの監査ワークフローを社内で説明するチーム向けには、規制当局への提出のためのプロセスを文書化することが、反復可能な記録がなぜ重要なのかを理解するうえで役立つ比較になります。
要点：初回のアテステーションが必要で、統制が検査の準備できている場合は Type I を選びましょう。顧客が、それらの統制が時間の経過とともに一貫して機能していたことの証拠を必要としている場合は Type II を追求します。
実際の統制と証拠に基づく、実務的な SOC 2 準備チェックリスト
SOC 2 の準備は、すべての統制に「担当者」「繰り返し可能な実行」「証拠となる成果物」があるときに最も効果的です。 私は巨大なポリシーフォルダから始めません。まず、チームが今何をしているのか、その活動がどのリスクに対応しているのか、そして証拠がどこにあるのかを質問します。
ID とアクセスから始める
適切な場面では SSO を必須にし、本番環境へのアクセスには MFA を強制し、特権アクセスは定期的なスケジュールでレビューします。統制は「アイデンティティプロバイダを使っていること」ではありません。統制とは、「誰にアクセスを付与するのか」「なぜ必要なのか」「誰が承認するのか」「いつアクセスを取り消すのか」という、繰り返し可能な判断のことです。
有用な証拠には以下が含まれます：
アイデンティティ設定： SSO と MFA の設定を示すスクリーンショットまたはエクスポート。
アクセスレビューの記録： 完了したレビュー、承認チケット、ユーザーとロールの一覧。
ジョイナー／リーバーの記録： プロビジョニングとデプロビジョニングを示すチケットまたはシステムログ。
インフラの統制を記録に紐づける
エンドポイントやインフラについては、パッチ適用の期待、ディスク暗号化、環境の分離、集中ログを文書化します。監査人は、ポリシーの PDF、設定のエクスポート、脆弱性管理の記録、またはクラウドやエンドポイントツールからのクエリを求めることがあります。
変更管理については、デプロイ前にチケット、ピアレビュー、テストの証拠、承認を必須にします。開発者が自分自身で承認し、自分自身で本番変更をデプロイできる場合は、リスクを文書化し、適切な職務分掌の分離を導入してください。
ベンダーとインシデントを検証可能にする
ベンダーリスク管理は、調達の迷路になる必要はありません。リスクランク付けしたベンダーのインベントリを維持し、関連する保証レポートやセキュリティ質問票を収集し、レビューの判断を記録します。
インシデント対応には、洗練されたランブック以上のものが必要です。机上演習を実施し、参加者と判断を記録し、フォローアップのアクションを記録し、顧客通知テンプレートを維持します。証拠は、人がプレッシャー下でもプロセスを使えることを示すべきです。
証拠の原則： 統制が実施されていても、誰も記録していなければ、監査人はその統制に対して評価（クレジット）を与えられない可能性があります。
私は、GRC プラットフォームを早期に選び、証拠の収集を一元化し、各成果物を特定の統制に紐づけることをおすすめします。画面録画を構造化された手順に変換することも、従業員のガイダンスやトレーニングに役立ちます。たとえば、従業員向けのコンプライアンス研修ビデオは、統制プログラムの文書化・教育の側面を支援できます。
ヒント： 多くの SOC 2 統制は、人が毎回同じ手順に従うことに依存しています。たとえばアクセスレビュー、オフボーディング、インシデント対応などです。Trupeer では、統制の担当者が手順を 1 回記録するだけで、スクリーンショット付きのステップバイステップガイドと短いトレーニング動画が手に入ります。バージョン履歴により、何がいつ変更されたかが分かるため、監査人から「手順はどのように周知されたのか」と聞かれたときに役立ちます。
要点： ドキュメント作成の短期集中ではなく、「証拠の仕組み」を構築しましょう。繰り返し行われる各統制は、明確で日付のある、レビュー可能な記録を生み出すべきです。
SaaS チーム向け：SOC 2 のスケジュールとコスト見込み
SaaS チームはポリシーを用意できていても、有用な SOC 2 レポートが完成するまで数か月かかることがあります。私の経験では、カレンダーが文書作成の量よりも左右されるのは、統制が一貫して運用され、監査人が検証できる証拠が生成されるかどうかです。
SOC 2 のスケジュールは「週」ではなく「月」で測ります。 Type I の作業は、多くの場合 エンドツーエンドで約 3〜6 か月かかります。最初の Type II は一般的に 6〜12 か月以上です。監査人が観察期間を評価し、繰り返しの証拠をレビューする必要があるためです。この SOC 2 の監査スケジュールでは、「一点時点のレビュー」と「運用期間のレビュー」の違いを説明しています。
私はコスト見積もりを「見積書」ではなく「計画用のレンジ」として扱います。スコープ、準備状況、監査人の選択、会社規模、社内の工数によって結果は大きく変わり得ます。アクセス記録がきれいな小規模チームは、承認の欠落、ポリシーの不完全さ、またはモニタリングの不整合を修正するために大規模チームより少ない時間で済む場合があります。
企業規模・段階別の SOC 2 スケジュールとコスト範囲
会社の段階 | 準備スケジュール | Type I の期間 | Type II の期間 | 報告された Type I の準備・監査コスト |
|---|---|---|---|---|
従業員 50 名未満 | 準備状況とスコープによって変動 | 通常、3〜6 か月のエンドツーエンドプロセスの一部 | 一般的に 6〜12 か月以上 | 約 $91,000 |
従業員 50〜250 名 | 準備状況とスコープによって変動 | 通常、3〜6 か月のエンドツーエンドプロセスの一部 | 一般的に 6〜12 か月以上 | 約 $186,000 |
会社規模の混合ベンチマーク | スコープと統制の成熟度に依存 | エンドツーエンドで約 3〜6 か月 | 約 6〜12 か月以上 | 時間と費用を合わせると概ね $147,000（平均） |
上記の 公開されているコンプライアンスベンチマーク では、$91,000、$186,000、$147,000 の数値が報告されています。これらは保証された監査費用ではなく、重要な投資が必要であることを示しています。セキュリティの担当体制、エンジニアリング工数、ポリシー作業、是正（リメディエーション）、証拠ツール、そして継続的なモニタリングのための予算を確保しましょう。
不確実性を切り分ける計画上の質問は 1 つです。「毎週、統制を所有しているのは誰ですか？」誰もその責任を持っていない場合、監査人を雇っても運用プロセスは修復されません。明確な責任分界を割り当て、エンジニアリングと運用を早期に巻き込み、現地作業（フィールドワーク）に入る前に繰り返し統制をテストしてください。監査準備の間だけ機能する統制は、検査官のためにリハーサルされた消防訓練のようなものです。通常のプレッシャー下でチームが対応できることは証明できていません。
要点： 継続的な運用作業と、複数か月にわたるレビューサイクルを見込んで計画してください。見た目が最も安いルートでも、準備が弱いことでスコープ、統制、証拠を作り直す必要が出ると、結果的にコストが増えることがあります。
SOC 2 は ISO 27001 と GDPR とどう違う？
SOC 2 と ISO 27001 はセキュリティプログラムに関する保証を提供し、GDPR はプライバシーに関する法律です。 対象領域は重なりますが、ベンダー評価ではそれぞれ異なる質問に答えます。
スタートアップが初めてエンタープライズ顧客を獲得する場合、同じ会話の中で 3 つすべてが求められることがあります。顧客の調達チームは SOC 2 レポートを求めるかもしれません。国際的な買い手は ISO 27001 を好む場合があります。顧客のプライバシーチームは、GDPR のもとでスタートアップが個人情報をどう扱っているかを尋ねるかもしれません。
SOC 2 はサービスの統制に焦点を当てる
SOC 2 は AICPA の Trust Services Criteria を基に構成され、独立した監査人のアテステーションレポートを作成します。原則ベースなので、組織は自社のサービスコミットメントに合う基準とシステムをスコープします。
ISO 27001 は情報セキュリティマネジメントシステムに焦点を当てる
ISO 27001 は、ISMS、リスクアセスメント、リスク対応を中心に据えた、国際的に認められた標準です。認定された認証機関が、マネジメントシステムが標準を満たしているかどうかを評価します。この ISO 27001 標準のガイドでは、条項や統制をより詳しく扱っています。国際的な認知や、正式なマネジメントシステムの認証が顧客にとって重要な場合、組織はそれを選ぶことがよくあります。
GDPR は法的なプライバシー義務を生む
GDPR は個人情報の処理を規定します。適法な処理、データ主体の権利、処理記録、影響評価、侵害時の義務、プライバシーガバナンスなどの論点を扱います。SOC 2 レポートは、それらの責任に代わるものではありません。
実務では、チームはセキュリティ保証に関する質問への回答や、データインベントリ、処理活動の記録、プライバシー通知、データ保護影響評価などの別途の GDPR 対応を維持するために、SOC 2 または ISO 27001 を活用することがよくあります。エンタープライズ向け GDPR トレーニングのガイダンスは、顧客対応チームや運用チームが自分の役割を理解するのに役立ちます。
要点： どのフレームワークが勝つのかを聞かないでください。顧客、規制当局、そしてビジネスモデルが何を求めているのかを聞きましょう。多くの組織は、1 つの統制の土台を構築し、それを複数の保証・プライバシー義務に整合させています。
よくある SOC 2 の落とし穴と回避方法
ほとんどの SOC 2 の失敗は、ポリシー文言がないことではなく、スコープが弱いこと、一貫性のない運用、または証拠のトレイルが欠けていることから起こります。 アクセスレビュー、デプロイ承認、インシデント演習が「証明しにくい」ままなのに、チームが書類を磨く作業に何週間も費やしているのを見たことがあります。
監査をチェックボックスとして扱う
ある会社はポリシーを集め、監査を通過して、その後は統制のモニタリングを止めてしまうかもしれません。このやり方は、チームがツールや人、環境、責任を変えるときにズレ（ドリフト）を生みます。
是正策： 統制の担当者を割り当て、定期的なレビューをスケジュールし、年を通じて証拠を点検します。
誤ったシステムをスコープする
スコープしすぎたエンゲージメントは、不要な作業を生みます。スコープが足りないエンゲージメントは、顧客のコミットメントを支えるシステムを除外してしまう可能性があります。
是正策： データフロー、インフラ、チーム、ベンダー、境界を示すシステム図を描きます。そして、各境界の判断を、評価対象のサービスに紐づけてください。
統制を定義せずにツールだけを使う
脆弱性スキャナーは指摘事項を特定できますが、承認済みのプロセス内でチームがそれらをトリアージしていることを自動的に証明するわけではありません。アイデンティティプロバイダは MFA を強制できますが、アクセスレビューが完了していることを証明するものではありません。
是正策： 各ツールに対して、書面化された手順、担当者、エスカレーション経路、そして人が出力をレビューしたことを示す証拠をセットで用意します。
土壇場で統制を展開する
新しく作成したポリシーは完成して見えるかもしれませんが、Type II の検査に必要な「運用の履歴」を提供できません。土壇場でのアクセスレビューや後追いで埋めたチケットは、特に危険です。記録が通常の運用を反映していない可能性があるためです。
是正策： 繰り返し統制を早期に開始し、元の記録を保持してください。例外が発生した場合は、隠すのではなく、担当者と期限日を割り当てます。
率直な助言： 監査人は完璧さを期待していません。例外を把握していること、影響を評価していること、そして次に何をしたかを示すことを期待しています。
要点： SOC 2 を、予測可能なセキュリティ作業のためのマネジメントシステムとして扱いましょう。適切なスコープ、一貫した責任体制、そして誠実な証拠があれば、監査ははるかに混乱を招きにくくなります。
Trupeer が SOC 2 の手順とトレーニングをどう支援するか
SOC 2 の統制は、人が毎回同じ手順に従い、それを証明できるときにのみ機能します。Trupeer は、文書化とトレーニングの両面で支援します：
統制手順の文書化： アクセスレビュー、オフボーディング、またはインシデント対応の手順を 1 回記録し、スクリーンショット付きのステップバイステップガイドを入手します。
スタッフを一貫してトレーニング： 同じ録画を、AI ボイスオーバー付きの短いトレーニング動画に変換します。
何が変わったかを示す： バージョン履歴を記録して、各手順の過去バージョンの記録を残します。
機微なコンテンツを保護： SAML SSO、SCIM プロビジョニング、ロールベースのアクセスと監査ログに加え、画面上の機微データをぼかすツールも提供します。
自社のレビューを通過できるベンダーを使う： Trupeer は SOC 2 Type II と ISO 27001 の認証を取得しています。
SOC 2 コンプライアンスを始める前にチームが尋ねる質問
SOC 2 の判断は、通常「顧客の期待」「サービスのリスク」「証拠の成熟度」に集約されます。 これらは、プロダクトマーケター、セールスエンジニア、カスタマーサクセスのリード、IT 担当者から私が最もよく聞く質問です。
誰が SOC 2 を必要とする？
顧客データを取り扱うサービスを提供している、または重要な顧客プロセスを支援している場合は検討するべきだと考えます。特に、エンタープライズの買い手が調達において独立した保証を含めている場合です。正式なフレームワークとしては任意ですが、顧客との契約やベンダーレビューによって、商業的に重要になることがあります。
スタートアップは最初から Type II に進める？
はい。統制がすでに適切に設計されており、信頼できる証拠で観察期間全体を支えられるなら可能です。スタートアップが初回レポートを必要としている、または Type II を支えるほど統制を十分な期間一貫して運用していない場合は、まず Type I を選ぶのがよいでしょう。
SOC 2 レポートはどれくらい有効？
私はレポートを「恒久的な約束」ではなく「期間が区切られた統制の見え方」として扱います。顧客は、最新のレポート、ブリッジレター、更新された統制の詳細、または検査期間以降の変更に関する証拠を求めることがあります。
SOC 2 は顧客のセキュリティレビューに代わる？
いいえ。顧客は、あなたのアーキテクチャ、サブプロセッサ、インシデント履歴、データの所在、事業継続、補完的なユーザー統制について、引き続き質問する可能性があります。レポートは不確実性を減らしますが、すべてのデューデリジェンスの質問が終わることは、ほとんどありません。
レポート以外に顧客が求める証拠は？
顧客は、NDA のもとでのレポート、スコープと基準の説明、例外事項、マネジメントの回答、サブプロセッサ情報、そして自社の質問票への回答を求めることがあります。これらの資料は、レポートで説明されている統制とシステムに整合している状態を保ってください。
社内チームにこれらの回答を説明する場合は、全員に分厚いポリシーライブラリを送るのではなく、短く役割別のウォークスルーを使いましょう。そうすることで、営業、サポート、エンジニアリング、運用が「何をしなければならないか」「どんな証拠を保持しなければならないか」を理解しやすくなります。
中心となる学びはシンプルです：SOC 2 コンプライアンスは、独立したアテステーションによって裏付けられた、繰り返し可能な運用の規律です。 顧客のコミットメントから始め、適切なシステムをスコープし、サービスに合う基準を選び、証拠収集を日常業務の一部にしてください。
Trupeer で SOC 2 の手順を簡単に実行できるようにしましょう。 各統制手順を 1 回記録すると、Trupeer がそれをステップバイステップのガイド、短いトレーニング動画、検索可能なナレッジベースのエントリに変換します。さらに、そのプラットフォーム自体が SOC 2 Type II と ISO 27001 の認証を取得しており、SAML SSO と監査ログも備えています。エンタープライズ向けの Trupeer を見る。
