これはいいことだね。ただ、最後まで読んでる人に一つだけ言っておきたいことがある。真剣な監査人を使っているなら、Type 1を通過しない方法は基本的にないよ。Type 1の目的は、ある時点でのベースラインを文書化することだから。Type 2が最初の「本物の」監査で、Type 1で証明したことをちゃんとやってるかを確認するだけなんだ。つまり、Type 1のためにやるセキュリティ作業は最小限に抑えて、ずっと守れるベストプラクティスの小さなセットに絞るべきだよ（シングルサインオンと保護されたブランチが基本的に90%を占めてる）。後からコントロールを追加するのはいつでもできるけど、取り除くのはすごく面倒だからね。SOC2に初めて挑む人にはいつもこれが心配なんだ。業界のベンダーは、Type 1を利用してチームをスキルアップさせたり、いろんなものを展開させようとするから、ひどいミスだよ。これは、ExcalidrawがType 1をクリアしたことに興奮しているという記事の結びに書いたんだ。彼らの監査人が、いつもそのハードルをクリアするって言ってくれたことを願ってる。

記事から: > SOC 2はAICPAが作ったセキュリティとコンプライアンスのフレームワーク。どうして会計士の集団（米国公認会計士協会）がソフトウェアのためのセキュリティフレームワークを作り、SaaSベンダーを認証する監査人を決める唯一のゲートキーパーとして自分たちを位置づけることができたのか、驚きだよね。企業がベンダーのITセキュリティプラクティスを判断するのに、テック業界の人ではなく会計士に頼るなんて信じられない。でも、テック業界全体がこれを受け入れているみたいで、GoogleやMicrosoftもそうだし。どうしてこうなったんだろう？

あの図はどうやって作ったんだろう？見た目がいいね :)

元Meta FinTechのセキュリティGRC責任者で、元MotorolaのCISO。今は、コンプライアンス修正エンジニアリングのスタートアップでテクニカルファウンダーをやってる。いくつか細かい指摘があるよ。SOC 2は「認証」されるものではなく、Type 1の場合はコントロールが設計されていること、Type 2の場合は効果的に運用されていることの証明を受けるだけなんだ。だから、正しい表現は「Excalidraw+はx,y,zのトラストサービス基準に対するSOC 2 Type 1の証明を受けた」ってことになる（通常はセキュリティ、可用性、機密性。企業は他の二つ、プライバシーと処理の完全性を選ぶことはあまりないけど、HIPAAなどの他のコンプライアンスフレームワークと重なる場合は別）。これが重要なのは、表現が大事だからで、誤った言い回しは成熟度の欠如を示すんだ。また、他の人が言っているように、誰もSOC 2監査に「失敗」することはないよ。監査人の意見は4つのうちの1つしか得られない - 修正なし、条件付き、否定的、免責（修正なしを目指したいね）。監査人が特に厳しくチェックする技術的な領域は、アクセス管理（人間とサービスアカウント）、変更管理（サプライチェーンセキュリティとアーティファクトセキュリティ）、脅威と脆弱性管理（パッチ管理、インシデントレスポンスなどを含む）。この情報が誰かのSOC 2証明の準備に役立つことを願ってるよ :-) 同様に、注意が必要なレポートの領域は、セクション3: システム説明（過度に広いシステムスコープにサインしてコンプライアンスの危険を冒さないように）、セクション4: テストマトリックス（自分には適用されないコントロールや、監査テストプランが意味をなさない場合は反論すること - 監査人はまだ2000年代初頭の「クライアントサーバーレガシーデータセンター」モードにとらわれていて、現代のクラウド環境を理解していないから）。最後に、VantaやDrataなどを使っているなら、セキュリティポリシーテンプレートをしっかり読んで、自分の組織に対して盲目的に受け入れないようにしてね。そうしないと、一度決めたらそれが固定されて、監査の基準になっちゃうから（例 - ほとんどの現代のオペレーティングシステムにはアンチマルウェアが組み込まれているから、別のソフトウェアを購入するためにお金を無駄にする必要はないよ、少なくとも最初の年はね - だからポリシーには別のエンドポイント保護ソリューションが稼働しているとは書かないように）。もう一つ、WeWorkのコワーキングスペースモデルだけで使っているオフィスがあるなら、カメラやバッジシステムなどの物理的セキュリティコントロールは、適用されないか、大家の責任になるから、あなたには無関係だよ）。このコメントが誰かの役に立つことを願ってる！SOC 2は実際には必要以上に複雑（そして高価）にされていることが多いから。

今の職場でも同じことを経験したよ。SOC2タイプ1を取得するのは簡単じゃなかったし、何年分ものインフラのゴタゴタを片付けることになった。監査ログなんて存在しなかったし、アクセスログも半分壊れてたし、変更履歴の管理も全然できてなかった。急にそれらをちゃんとしなきゃいけなくなったんだ。しかも、オープンコアの設定で有料SaaSも運営してるから、同じような苦労があった。どの部分を公開するか、どれをログインの裏に隠すか、どのアクションを追跡する必要があるかをはっきりさせなきゃいけなかった。OSSはスピードをくれるけど、コンプライアンスが求められるまで表面が見えない。早く出荷してた時には誰も気にしなかったことが、急にブロッカーになったりするんだよね。結局、やるって言ったことを実際にやった証拠があるかどうかをチェックされるだけ。成長を強いられるけど、創業者には優しくないやり方だよね。

SOC 2については全然知らないんだけど（他の公式っぽいフレームワークについても）。オランダの大きな自治体で働いてて、彼らも監査人がすべてを追跡・検証できるように、すべてのステップを細かく文書化してるんだ。彼らがこの目標を達成するためにやったことを見て、次のステップ（彼らの提案）でISOをやるのは楽勝だと思うよ。だって、どの「フレームワーク」も細かい文書化を要求するから。

残念だけど、SOC 2の認証を持ってても、ベンダーの質問票（や一時的なセキュリティの要求）からは逃れられないけど、少しは楽になるよ。 ;)

これは良いまとめだね。今、私たちも同じプロセスを進めてるところ（SOC2 & ISO27001）。長い旅だったよ。コンプライアンスプラットフォームはすごく助かるけど、まだまだやるべきことがたくさんある。早い段階で監査経験のある人を関わらせるのはいつも良いことだね。

認証を取得するのに一番簡単な方法って何？VantaやDrataみたいなのを使うのがいいのかな？あれって実際どうなの？

Metaは技術面接でExcalidrawを使ってたけど、主に未実行のコードを評価するためのEtherpad（共同テキストエディタ）として使ってたよ。だから、PiratePadやEtherpad、Googleドキュメントでも十分だと思う。