SOC2保証報告書の提示が「取引条件」に入る日は近いかもしれない

こんにちは、cloudpack.media編集長の増田です。

今回はみなさんにあまり馴染みのないテーマ、タイトルにもある「SOC2保証報告書」について、可能な限りわかりやすく書いてみることにチャレンジしてみます。

「SOC2ってなんかスゴイんでしょ？」
「取るの大変なんでしょ？」って思っているア・ナ・タ！

はい、アナタのための記事です。

あまり興味がないという人も、後学のためにぜひ読んでおきましょう！

SOC保証報告書って何でしょう？

SOC = Service Organization Controls
和訳すると『受託業務に係る内部統制の保証報告書』

SOC保証報告書は、外注先の業者またはサービス提供会社の『内部統制』について、監査法人や公認会計士が独立した第三者の立場から客観的に検証した結果が記された報告書になります。

SOC1では財務報告の信頼性について、SOC2ではサービスの中身に応じて、セキュリティ・可用性・処理のインテグリティ・機密保持・プライバシーの5原則のいずれか1つ以上を対象にして、内部統制の信頼性を検証します。

あなたの会社が外部のクラウドサービスを利用するにあたり、そのサービスの運営会社を業務委託先として評価する際に利用できるドキュメントだと言えます。

外部委託先の評価方法

例えば、どこの企業にもある『決算書（財務諸表）』を作成する場合、購買業務・経理業務・販売業務などがあって、それぞれの購買システム・会計システム・販売システムあたりのアプリケーションを使うことが一般的です。

そしてそのシステムは、外部のデータセンターに置いてあるサーバー類（ハードウェア）で動いていて、ネットワークでつながっていたりしますよね。この場合の『外部のデータセンター』が業務委託先に該当します。（そもそもこの時代、業務のすべてを自社内で完結している企業なんて存在するのかしらん？）

決算報告の監査をする段階で、自社の業務処理の内部統制は評価できるのは当然なのですが、『外部のデータセンター』など業務委託先の内部統制はどうやって評価するのでしょうか？

大きくわけて3つの方法があります。

1. 用意した質問票に回答してもらって、内部統制の評価をする

2. 外部委託先を直接訪問して、インタビューを行うなどの方法で内部統制を評価する

何かしらのサービスを利用している企業なら、委託先のチェック方法で1や2は「あるある」の範囲でしょう。

特に1のやり方では、質問票への回答を信用することになります。あくまでも質問した範囲への回答なので網羅性に欠けるし、自己申告なのでそれが真実かどうかは委託先しかわかりません。

2のように監査人が乗り込んであれこれ調べる方法でも、質問したことに答えてもらうパターンになるので、回答が不十分だったり、聴き漏れなどが発生する心配があります。

そして、3つめの方法です。

3. 委託先の保証報告書を入手して評価をする

実はこの「保証報告書」こそが、SOC保証報告書なのです！

委託先の内部統制に関するデザインと運用状況が開示され、それが適切かつ有効であるか、正しく運用されているかを第三者が評価して報告書にまとめたもの、それがSOC保証報告書です。

1や2の評価方法よりも網羅性があり、それを第三者が評価しているという点で、委託先の内部統制を「信用する」に値すると言われています。

ISMSとSOC2の違い

ITの内部統制という観点で、ISMS（情報セキュリティマネジメントシステム）の認証を取得している企業も多いことでしょう。

まずSOC2は、外部から『保証報告書として提供』されるものであり、ISMSのような何らかの「認証を取得する」ものではありません。ここがピンとこない方もいるのでは。

そこで、ISMSとSOC2の違いを比較表にしてみました。

これらの違いは、あなたが『ある企業が提供するクラウドサービスを利用する』という観点でみると、理解が早いかもしれません。

ISMSは、情報セキュリティに対するマネジメントシステムの仕組みが、そのクラウドサービスを運営している企業にある一定以上の水準で『存在する』ことを証明しているだけで、そのサービスそのものがどういう内部統制で運営されているかを知ることができません。また、監査で部分的に問題が見つかっても改善されていれば証明書が発行されます。一体どのような不適合が見つかったのか、何がどう改善されたのかを知る手段がありません。

SOC2保証報告書は、内部統制の仕組みが詳細に記述されているため、入手して読めば、そのクラウドサービスのセキュリティ設計や運用に関する具体的な手続きについて知ることができます。また、監査で検出された内容がありのまま記載されています。原則として、報告書はそのまま提出するルール（抜粋等はNG）なので、そのサービスを利用して問題ないかどうかの判断材料として有効だと言えるでしょう。

SOC2報告書を受領している企業はどれぐらいいるの？

実は、どの企業がSOC2報告書を受領しているのか全容を知ることは困難です。プライバシーマークやISMSのような認証モノではないですし、誰でも自由に閲覧できる書類ではないため、コーポレートサイトやブログなどで公表していなければ把握できないのが現状です。

ちなみに2017年4月4日にcloudpack（アイレット）が『SOC2 Type2保証報告書を受領しました』という発表をしたところですが、従業員200名以下の企業で、AWSを対象としたフルマネージドサービス事業でSOC2 Type2報告書を受領したのは弊社が世界初かもしれないと耳にしました（前述のとおりでホントのところは不明です）。

しかし、クラウドが当たり前のように利用され、サイバー攻撃などのリスクが増大する中で、SOC2保証報告書を活用する企業が増えているのはどうやら間違いなさそうです。そうした動きを察知してか、主要クラウドベンダーは既にSOC2保証報告書を持っているか、もしくは監査中といった状況だと言われています。

さて、SOC2保証報告書はどのようなときに必要とされるのでしょうか？

ヨソで起きた情報漏えい事件などを契機に、監督官庁から外部委託先管理について報告が求められるようなケースでも、SOC2保証報告書があると役に立ちます。

また、金融機関向けの安全対策基準に、FISC（金融情報システムセンター）が発行している『金融機関等コンピュータシステムの安全対策基準』というのがありますが、この中で、外部委託先の選定時に、SOC2保証報告書を参照すべし、とあります。

金融・医療・官公庁、それから基幹システムなどのミッションクリティカルなシステムを弊社のクラウドに！と考えている企業は、SOC2保証報告書を持っていることが必要な時代になりつつあります。既に一部の外資系企業では、外部委託先はSOC2保証報告書の提出がmustなところもあるそうなので、SOC2が取引条件になる日は案外すぐにやってくるのかもしれません。

SOC2保証業務のフローについて

ここまで読んで、我が社にもSOC2保証報告書が必要だな！と思った方のためのフローは以下のとおりです。

• 対象を決める（原則・サービス・組織・施設）
• 評価期間を決める（ある1日における時点評価・ある期間における期間評価）
• 内部統制記述書の作成（全社的な内部統制・対象サービスに対するシステム統制）←これは自社で記述します
• 監査法人による監査（適合性評価・Walk Through評価・Entity level Control評価・Test of Control評価・有効性確認の手続き・経営者インタビューによる信憑性確認）

評価は、監査法人によって指摘事項・例外事項・除外事項の3段階で記述されます。保証報告書にはありのままが記述されるので、評価を受けるまでに内部統制に必要なあれやこれやを整備していくことになります。

cloudpackのSOC2保証報告書の対象範囲

cloudpackのSOC2報告書の目次

前述のとおり、SOC2保証報告書は不特定多数の誰もが閲覧できるドキュメントではないので、cloudpackでは誰でも見られるドキュメントとして『cloudpackセキュリティホワイトペーパー』を公開しています。

SOC2はSOC2＋へ

ここ最近は、SOC2に業界標準のフレームワークを追加する『SOC2＋』が注目されています。

SOC2への追加に有用な業界標準のフレームワークの例としては

• 金融業界：金融情報システムセンター（FISC）の安全対策規準
• 医療業界：HIPAA（Health Insurance Portability and Accountability Act/医療保険の携行性 と責任に関する法律）
• クラウド業界：クラウドセキュリティアライアンス（CSA）、クラウドコントロールマトリックス（CCM）

プライバシーマークもISMSも、企業は認証を取得することがゴールになりがちで、形骸化を心配する声が日々高まっています。社内での形骸化を防ぐために腐心しているご担当の方も、たくさんいらっしゃるんじゃないかと想像しています。

これからはサイバーセキュリティに特化した保証ニーズなども高まりそうですし、より網羅性・具体性・柔軟性のあるSOC2＋報告書の受領を目指すのは、社内の内部統制の形骸化を防ぐという観点でも、一考する価値はありそうです。