paint-brush
CTO が SOC 2 コンプライアンスについて知っておくべき 3 つのこと@mikedekock
571 測定値
571 測定値

CTO が SOC 2 コンプライアンスについて知っておくべき 3 つのこと

Mike DeKock5m2024/08/03
Read on Terminal Reader

長すぎる; 読むには

データ セキュリティの状況は近年大きく進化しており、SOC 2 レポートの需要が高まっています。顧客は、第三者監査によって検証された堅牢なセキュリティ プログラムが導入されているという透明性と保証を期待しています。現在知られている SOC 2 レポートは、2010 年に AICPA によって開発されました。
featured image - CTO が SOC 2 コンプライアンスについて知っておくべき 3 つのこと
Mike DeKock HackerNoon profile picture
0-item

マイク・デコックの創設者兼CEO MJDアドバイザー


圧倒的なサイバー攻撃の波からシステムを守るためのデータセキュリティの需要が高まるにつれ、より多くのスタートアップ企業がSOC 2レポートを利用して顧客にサイバー衛生を証明するようになりました。多くのスタートアップ企業が、自社のセキュリティを強化するためにSOC 2レポートを利用しています。ビジネスチャンスしかし、監査プロセスは避けたい難しい要件として描かれているため、監査プロセスについてまだ不安を抱いているかもしれません。


実のところ、コンプライアンス部門は近年、ビジネスの要求に適応するために大きな変化を遂げており、企業がデータセキュリティを証明する方法を完全に変えています。たとえば、証拠の収集はもはや手動で行われず、関係者全員の多大な労力と時間を必要としていました。ガバナンス、リスク、コンプライアンス(GRC)ソフトウェアは、これらのタスクを業務の裏で自動化します。これは、2025年に20億ドルに達すると推定される急成長市場でもあります。 376.3億ドル今後4年以内に。


それでも、誤解は多く、監査人を喜ばせるために、事業の健全性のためではなく、一夜にして業務形態を変える企業さえあります。一時的には役立ちますが、これは良いコンプライアンスがもたらすものではありません。むしろ、良い慣行を示し、組織内に前向きな変化を生み出す成長促進剤のように見えるべきです。


したがって、CTO、上級エンジニア、またはデータ コンプライアンスを担当するその他のビジネス リーダーであれば、自信を持って SOC 2 検査を実施できるように、3 つの点を明らかにして明確にする必要があります。

SOC 2 について知っていることはもう過去のもの

SOC 2の歴史1970年代に遡るこれは、2010 年に制定された比較的新しいコンプライアンス標準です。ほぼ 15 年が経過しましたが、プロセスが劇的に変化したのはここ 2、3 年だけです。無限のスクリーンショットや次から次へと出てくるセキュリティ アンケートでいっぱいというわけではありません。しかし、大多数の人々は依然としてコンプライアンスをこのように認識しています。


誤解のほとんどは、単に背景が欠けているか、時代遅れです。今日では、コンプライアンス管理ツールのおかげで、プロセスははるかに簡単でスムーズになりました。これらのプログラムは、手動で時間のかかるタスクの自動化に特化しているため、タスクは自動化され、非同期で実行されるため、SOC 2 要件を満たすために長時間の会議や業務の停滞が発生する必要がありません。


たとえば、一部の GRC プラットフォームは、GitHub などの一般的な開発者ツールに接続して、ワークフローを中断することなく、コンプライアンスのために日々の活動を監視します。これらのツールにより、複雑な監査活動にかかる時間が大幅に短縮され、代わりに監査活動に価値と効率性がもたらされます。


タスクの自動化により、監査人の負担も軽減され、分析タスクに多くの時間を費やせるようになりました。また、コンプライアンスに対する監査人の高度な技術的アプローチにより、監査人は検査対象のプログラムの内容を理解することができました。その結果、監査人は、SOC 2 を超えてコンプライアンスを維持するために、より優れたデータ セキュリティ プラクティスと GRC ツールを導入するのを支援できる専門家へと進化しました。

SOC 2 は思ったほど要件が厳しくない

テクノロジー企業が満たさなければならないすべてのコンプライアンス要件の中で、SOC 2 に関する何かが翻訳で失われました。他のより厳格な監査とは対照的に、SOC 2 レポートは、適合しなければならない標準条件のチェックリストではなく、業界と顧客ベースが直面している企業のニーズに合わせて作成されます。つまり、顧客に対して行ったセキュリティの取り組みを示すルールを作成するのは企業です。


これは、規制当局によって義務付けられた非常に具体的な慣行に全員が従う必要があるというコンプライアンスとは相反するように思えますが、この自由さこそが、SOC 2 をコンプライアンス レポートとして成功に導いているのです。また、SaaS などの業界の北米企業がセキュリティ アンケートよりも SOC 2 を好む理由でもあります。


このアプローチが有利なのは、セキュリティ フレームワークとして、SOC 2 はすべての企業がそれぞれ異なる方法で運営され、多様なクライアントに対応し、幅広い製品やサービスを提供していることを認識しているからです。すべての企業が同じ要件に従うことを期待するのは不可能です。たとえば、教育テクノロジー企業は学生データへのアクセス制御に重点を置くかもしれませんが、金融サービス企業は金銭取引のデータ暗号化を優先するかもしれません。


真実は、SOC 2が5つの信頼サービス基準そのうち必須なのは 1 つだけです (セキュリティ管理)。監査人と会うときは、製品について話し合い、どの基準を満たす必要があり、どの基準を省略するかを判断します。SOC 2 は必須ではなく、会社に利益をもたらすビジネス上の決定であるため、ニーズを理解し、どの基準に準拠するかを賢く選択するのはあなた次第です。

監査人を喜ばせるためだけにアップグレードしないでください

監査業務に何十年も携わってきた者として、私はあらゆることを見てきました。私があまりにも頻繁に目にし、企業が絶対に避けるべきことの 1 つは、監査人を喜ばせるためだけに、検査の直前にセキュリティ ツールを入手することです。レポートの完成後もそれらのツールを保持するかどうかは別として、それらをテストに合格するための一時的な応急処置と見なすべきではありません。


SOC 2 は、すでに実施しているプラクティスとプロセスをリストアップし、顧客や潜在的な顧客にセキュリティ体制についての洞察を提供します。監査のためだけに侵入検知、静的コード分析、その他の脆弱性管理ツールなどのプログラムを一時的に使用すると、SOC 2 レポートで顧客を失望させ、誤解させることになります。最終的には、不正なプラクティスによって会社に損害を与えることになりかねません。


代わりに、CTO は監査人と面談し、可能な限り透明性を保つように奨励されるべきです。監査人は、あなたがすでに行っている優れた取り組みを強調するためにいるのであって、あなたの弱点を指摘するためにいるのではありません。例外を受け取った場合、これは監査人が仕事をうまくやり遂げ、あなたの実践を改善し、より優れたデータ セキュリティに準拠するためのソリューションを提供したことを意味します。


むしろ、監査を理由に適切なセキュリティ対策を実施し、会社がより良い取引を獲得し、将来的に大きな成功を収められるようにしてください。誰もがそれを望まないでしょうか?


SOC 2 に対する認識の変化は一夜にして起こるものではないことは承知していますが、その新たなアプローチを提唱し、より多くの企業が自信を持って積極的にセキュリティ対策を披露できるようにすることが重要です。監査会社はスタートアップ企業やテクノロジー業界のペースに急速に適応し、コンプライアンスをかつての姿とはほとんど似ていない合理化された要件にしています。