SOC 2 は、AICPA によって策定されたセキュリティフレームワークであり、サービス組織におけるセキュリティ、可用性、完全性、機密性およびプライバシーに関する管理策を対象としています。
したがって、SOC 2 はセキュリティフレームワークそのものと、企業が SOC 2 の要件に準拠しているかどうかを確認する監査の両方を指します。

SOC 2監査では、企業は各ポリシーに必要な統制について、その実施を示す証拠を提出する必要があります。例えば、企業が「変更管理」に関するポリシーを定めている場合、「環境の分離」「変更の通知」「変更の文書化と承認」といった統制についての証拠を提示しなければなりません。
一般的に、セキュリティポリシーは次のようなカテゴリに分類できます

それぞれのポリシーについて、会社は管理策を、「変更管理ポリシー」の以下の例のように用意する必要があります。

それぞれの「管理策」(例:「変更管理」における「環境の分離」など)について、企業は「証拠」を次のように提示できます:

SOC 2 と ISO 27001 の比較
どの種類のセキュリティ認証を取得するかの選択は、クライアント次第です。もし企業に国際的なクライアントがいる場合は ISO 27001 を選び、米国拠点のクライアントが中心であれば SOC 2 を選ぶとよいでしょう。両方を取得することも可能ですが、ほとんどの顧客はどちらか一方で問題ないはずです。ISO 27001 認証は、対象範囲に含まれる項目が多いため、取得までにより時間がかかる場合があります。
SOC2 タイプ1 と SOC2 タイプ2 の違い
企業がSOC 2認証を取得しようとしている場合、まずType 1を取得するか、最初からType 2に進むかを選択する必要があります。Type 1は、特定の日など、ある一点の時点に対して実施される監査です。そのため、求められる証拠は比較的少なくなります。Type 2は通常、3〜6か月の期間にわたって実施される監査であり、期間が定められている分、はるかに多くの証拠が必要になります。あなたがベンダーであれば、ほとんどの顧客はSOC 2 Type 2を求めてくるでしょう。もし、SOC 2 Type 1のようなセキュリティコンプライアンスを至急求めてくる顧客がいないのであれば、直接Type 2に進むことをお勧めします。この点については、監査人に相談して決めることもできます。
SOC 2 の準備
1. SOC 2監査の基準を選定する
SOC 2 のコンプライアンス取得を進める際には、監査を受けたい柱、つまりトラストサービス基準を選択することができます。

多くのスタートアップは、セキュリティ、可用性、機密性を選択します。しかし、特定の業界では、プライバシーや完全性も必要となる場合があります。2. ポリシー/監査管理ツールを選択する
自動化された SOC 2 コンプライアンス向けで最も一般的なベンダーは、Tugobat Logic、Vanta、そして SecureFrame です。
これらの自動化された SOC 2 ベンダーは、自社向けにカスタマイズすることを前提としたセキュリティポリシーのテンプレートを提供してくれます。また、リスクアセスメントのテンプレートなど、ポリシーにおける多くの管理策について証拠を提示するためのテンプレートも提供しています。多くの監査人は自前のツールを持っていますが、往々にして原始的なものにとどまります。監査人は、あなたを支援するために適切な管理策テンプレートを提供することよりも、不備を見つけることに重点を置きがちです。そのため、もしあなたがスタートアップであれば、Tugboat や Vaanta のようなベンダーを必ず利用するようにしてください。
3. 監査人を選定する
Align や ssflip などの監査人を選ぶか、Tugboat/Vaanta が推奨する監査人を選択してください。

プロのコツ: 監査の準備を始める前に、監査人に対して、どの統制やポリシーに重点を置いてほしいのか、またどのような支援を提供してもらえるのかを確認しましょう。
4. 監査準備
監査を開始する前に前もって準備を始めましょう。これらはあなたにとって最も重要なステップになります。監査人は、監査が始まる前にすべてが準備できていることを期待しています。また、監査人に対して、どのポリシーやコントロールに自社として重点を置くべきかといったアドバイスを求めることもできます。コントロールの証拠は、管理しやすいように Vanta や Tugboat Logic などに直接アップロードし始めるとよいでしょう。一般的なスタートアップの場合、SOC 2 準拠を達成するための取り組みは、おおよそ次の領域に分けられます。
プロのヒント:初回監査では、監査人がより短い監査期間で報告書を発行してくれるか確認しましょう。そのほうが報告書を早く出してもらえます。2回目以降の監査は、翌年分を対象に実施するようにしましょう。

a) セキュリティ
- 可能であれば外部の第三者に依頼して、データセンターのペネトレーションテストと監査を実施してもらいましょう。たとえば、GCP の監査とペネトレーションテストには私たちは ThreatWatch を利用しました。外部によるペネトレーションテストの報告書は、お客様から提出を求められる可能性が高いです。

- 次のものが導入されているか確認してください:IDS システム(例:ネットワークログやSQLクエリなどを監視)
- 送信中および保存中のすべてのデータが暗号化されていることを確認してください。
- さらに、機密性の高い項目のデータを暗号化してください。
- JIRA などのツールにおけるドキュメントアクセス申請プロセス
- インシデント管理計画を策定しておくこと
b) 人事/IT
- オンボーディングの際には、職務責任のある全員分について、オファーレターが署名済みであることを必ず確認してください

- 各従業員に就業規則(ハンドブック)へ署名してもらうこと
- 人事評価の計画を立てておきましょう。
- オフボーディング計画(アクセス権の削除、ノートパソコンの返却)を文書化しておくこと
- オンボーディングの手順を文書化する。
- すべての職務要件を文書化し、第三者による確認・承認を受けること
- 取締役会の議事録を作成・保存してください。
- コンプライアンス担当に、会社全体を対象としたリスクアセスメントを実施させてください。その際、SLA、製品、経営陣のコミットメント、特許などに起因するリスクを網羅的に評価する必要があります。
c) コンピューターセキュリティ
- USBアクセスの制限や端末の初期化などが行える Airwatch のような MDM ソリューションを導入していることを確認してください。

- 各コンピューターに必ずウイルス対策ソフトを入れてください。Mac や iPad を使用している場合は、例外が認められることがあります。
- メールやGoogleドキュメントなどでDLPが有効になっていることを確認してください。DLPを有効にしておくことで、従業員が意図せず機密情報を漏えいしてしまうことを防げます。
d) ベンダー管理/一般
- 各サードパーティーベンダーごとにリスク評価を行い、そのベンダーが利用不能になった場合の影響を算出してください。

- ベンダー管理プロセスを整備していることを確認してください。例えば、取引先ベンダーに対して SOC 2 レポートや財務の健全性に関する情報を求めるなどの対応が必要です。その際には、https://panorays.com/ のようなツールを利用して、これらの情報を収集することができます。
e) 変更管理
- Jira などのシステムを使い、各デプロイ前に承認を取得してください。

- あらゆるシステムやデータベースへのアクセス申請について、文書による承認を行うこと。
- すべてのインシデントを記録し、再発を防ぐために根本原因分析を実施してください。
- スクラムのような開発プロセス(SDLC)を文書化し、アジャイルボードのスクリーンショットを提示できるように準備してください
f) 事業継続/災害復旧(DR)計画
- 事業継続計画(BCP)および災害復旧計画(DR計画)を策定していること

- 災害復旧をどのようにテストしたかについての文書を作成してください。
- BCPの主要なリスクを評価するBCP担当マネージャーを任命してください。

