和田拓馬（株式会社デジタルキューブ 取締役 / 公認会計士・税理士）
上場準備を進めていると、取得を検討すべき認証や評価の名前が次々と出てきます。ISMS、プライバシーマーク、SOC レポート、各種のセキュリティ認証。証券会社や監査法人との面談で話題に上り、他社が取得していると聞けば気にもなります。
ところが、いずれも取得には費用と時間がかかります。審査対応に人員を割けば、本業にも影響が出ます。何をどこまで取得するべきかを決められないまま、見積もりだけが手元に積み上がっていく状況は珍しくありません。
『IT ガバナンスはどこまでやるべきか』では、基準点がないからこそ第三者による評価が判断材料として機能すると書きました。『整備すべきシステムは、思っているより少ない』では、財務諸表の領域で範囲を絞る手順を整理しました。今回は、具体的にどの評価を選び、どう使い分けるかを扱います。自社での取得経験も交えて解説します。
第三者評価が効くのは “基準点がないから”
前提を確認しておきます。上場審査には、ここまで整備すれば通過するという数値基準が存在しません。証券取引所は、経営者へのヒアリングに加えて、監査役、証券会社、監査法人などにも確認しながら心証を得ていきます。
基準点がない状況では、自社が十分だと考えている水準を、自社の言葉だけで説明しなければなりません。説明が主観的になるほど、審査する側は判断に迷います。
第三者評価が効くのは、まさにその場面です。外部の定義された要件を満たしていると示せれば、説明は客観的な事実に変わります。自社の水準を自社が主張する構図から抜け出せる点に、認証や評価の本質的な価値があります。
逆に言えば、審査で説明したい論点がない領域の認証を取っても、費用に見合う効果は得られません。 何を説明したいのかが先にあり、評価の選択は後から決まります。
3領域と第三者評価の対応関係
コーポレートガバナンスに含まれる IT ガバナンスの「情報セキュリティ」「ビジネス」「財務諸表」、3領域にそれぞれ対応する評価があります。
「情報セキュリティ」の領域
代表的な選択肢が ISMS 認証です。情報セキュリティマネジメントシステムの国際規格である ISO/IEC 27001 に基づく認証で、組織が保有する情報資産の安全性を確保する体制が整っていることを示せます。
情報セキュリティは全社必須の領域です。個人情報や機微な取引情報を扱う事業であれば、取得を前向きに検討する価値があります。認証取得の過程で、規程の整備やリスクアセスメントの実施が進む点も、上場準備との相乗効果を生みます。
「ビジネス」の領域
事業を支えるシステムそのものが適切に構築・運用されているかを示す領域です。目指すレベルを自社で定義するしかない領域であるため、外部の評価を取り入れる意味が最も大きくなります。
ただし、決まった認証が存在するわけではありません。自社でシステムを開発・運用している企業であれば、利用しているクラウド基盤の提供事業者が用意している技術レビューが選択肢になります。市販のパッケージやクラウドサービスを組み合わせて業務を回している企業であれば、自社が評価を受けるより、利用しているサービス側の評価を確認するほうが現実的でしょう。
自社の事業構造によって、取るべきものと確認すべきものが変わる領域だと言えます。
「財務諸表」の領域
自社が他社に業務を委託している場合、委託先の内部統制が財務諸表に影響します。委託先の内部統制について保証を得る仕組みが SOC レポートです。後半で詳しく扱います。
デジタルキューブの例 ─ クラウド基盤の技術レビューを使う
「ビジネス」の領域で外部評価をどう使ったか、自社の例を紹介します。前提として、デジタルキューブは AWS 上でホスティングサービスやクラウドサービスを提供しており、事業の中核がシステムそのものである会社です。
活用したのが AWS FTR（Foundational Technical Review）です。ソフトウェアやソリューションが AWS のベストプラクティスに基づいて実装・運用されているかを、あらかじめ定義された共通要件に従って検証するパートナープログラムで、リスクの軽減や運用体制の改善に活用できます。AWS の認定を受けている点を対外的に表明できる点も特徴です。
参考：
AWS Foundational Technical Review（Amazon Web Services）
AWS の FTR 認定を取得しました… が、 FTR ってなんだろう？ AWS のなかのひとに訊いてみた。（デジタルキューブグループ 公式 note）
デジタルキューブでは、上場準備クラウドの FinanScope、ホスティングサービスの Amimoto と Shifter という3つのプロダクトで AWS FTR を取得しました。東証の審査および開示書類においても記載し、ガバナンス向上に活用しています。
ISMS が組織の情報セキュリティに関するマネジメント体制を対象とするのに対し、AWS FTR は個々のプロダクトの技術要件を対象とします。事業の中核がシステムそのものである企業にとっては、後者のほうが説明したい論点に直結しました。レビューの過程で改善点が具体的に指摘されるため、認証を得ること自体より運用の見直しに価値を感じる場面もありました。
なお、AWS FTR は AWS のパートナー企業を対象としたプログラムであり、すべての企業に当てはまるものではありません。要点は、利用している基盤の提供事業者が技術面の評価やレビューの仕組みを用意していないかを確認することにあります。クラウド基盤ごとに同種の仕組みが存在しますし、自社でシステムを開発していない企業であれば、後述する他社の保証を確認する方向に切り替えることになります。
SOC レポートは「取る」より「もらう」
SOC レポートは、受託業務に係る内部統制について保証を得るための報告書です。米国公認会計士協会（AICPA）が定めた枠組みで、保証の対象と想定される利用者によって SOC1、SOC2、SOC3 の3種類に分かれます。
SOC1・SOC2・SOC3 の違い
SOC1 は、委託会社の財務報告に関連する内部統制を保証対象とします。想定利用者は委託会社と委託会社の監査人で、財務諸表監査に直結する報告書です。機密情報を含むため、公開はされません。
SOC2 は、セキュリティ、可用性、処理のインテグリティ、機密保持、プライバシーを保証対象とします。想定利用者は委託会社と委託会社の監査人に加えて、委託会社または受託会社に係る規制当局が含まれます。公開範囲は顧客向けに限定されます。
SOC3 は SOC2 と同じ領域を扱いますが、想定利用者が不特定であり、概要報告書のみが提供されます。一般に公開できる点が、前の2つと大きく異なります。
報告書にはタイプの区分もあります。タイプ1は特定の時点における内部統制の整備状況を評価し、タイプ2は一定期間にわたる整備状況と運用状況の両方を評価するものです。期間は6か月から1年程度が一般的で、運用状況まで検証するタイプ2のほうが負担も費用も大きくなります。なお、タイプの区分が存在するのは SOC1 と SOC2 のみです。
なぜ「もらう」で足りるのか
3種類の違いを押さえたところで、制度が存在する理由に触れておきます。ここに、自社で取得しなくてよい根拠があります。
業務を外部に委託している企業の監査人は、委託先の統制が財務諸表に与える影響を評価しなければなりません。監査基準委員会報告書402「業務を委託している企業の監査上の考慮事項」が、その考え方を定めています。
とはいえ、委託会社が1社ずつ委託先へ監査に入るのは現実的ではありません。委託先から見ても、顧客ごとに同じ説明と対応を繰り返すことになります。そこで委託先が一度だけ独立した監査人の評価を受け、作成された報告書を複数の委託会社とその監査人が利用する。効率性の要請から生まれた仕組みが、受託業務に係る内部統制の保証報告書です。
つまり報告書は、委託会社とその監査人が利用するために作られています。利用する側に回ることは、制度が本来想定している使い方にほかなりません。
日本基準では名称が異なる
ひとつ補足しておきます。SOC という呼称は米国基準のものであり、日本の監査法人に依頼する場合は別の名称が使われます。
SOC1 に相当するのが、日本公認会計士協会の監査・保証実務委員会実務指針第86号「受託業務に係る内部統制の保証報告書」です。2011年12月に公表され、信託財産の運用・保管、給与計算、IT アウトソーシングといった受託業務を対象としてきました。2019年には保証業務実務指針3402へと見直されています。
参考：保証業務実務指針3402「受託業務に係る内部統制の保証報告書に関する実務指針」（日本公認会計士協会）
SOC2 に相当するのが IT 委員会実務指針第7号です。米国で2011年に SOC1・SOC2・SOC3 の体系が整理されたことを受け、日本では2013年に公表されました。
監査法人との会話では、SOC ではなく86号や IT7号という呼び方が出てくる場面があります。同じものを指していると知っておくと、話が早く進みます。
自社で発行するハードル
実務上の判断として申し上げたいのは、自社システムに対して保証報告書を発行するのは相当にハードルが高いということです。
工程を追うと、まず監査法人の選定があり、次に統制目標の設定から文書化までを含む内部統制の整備、そして監査の実施へと進みます。整備の段階だけで数か月を要することが多く、全体では半年から1年程度を見込む必要があります。タイプ2であれば、運用状況を検証するための期間がさらに加わります。監査費用も高額です。
上場準備中の企業が優先的に取り組む対象とは考えにくいでしょう。自社が受託会社として顧客から求められている、という状況でなければ、着手する理由は乏しいはずです。
現実的な使い方
現実的なのは、他社のレポートを入手することです。クラウド基盤の提供事業者や会計システムのベンダーが保証報告書を作成している場合があります。
ただし、簡単に手に入るとは限りません。SOC3 に相当する概要報告書は一般に公開されていることがある一方、SOC1 や SOC2 に相当する報告書は公開されておらず、取引先として提供を依頼し、守秘義務契約を結んだうえで受け取る流れになります。利用しているサービスの提供事業者に確認するところから始めてください。
入手できれば、自社が利用しているシステムの内部統制について、審査の場面でも監査法人との協議でも根拠を示せます。委託先の統制が保証されている状態を、自社で証明する必要はありません。すでに存在する保証を取り寄せて使う。限られたリソースで進めるには、割り切りが必要です。
自社で取るか、他社のものを使うか
3領域と評価の対応を踏まえると、判断の軸が見えてきます。
自社が説明責任を負う領域は、自社で取得します。自社のプロダクトが顧客の情報を預かっているなら、安全性は自社が示すしかありません。ISMS 認証や、基盤提供事業者による技術レビューが該当します。
一方、他社に委ねている領域は、他社の保証を入手します。クラウド基盤の統制、会計システムの統制は、提供事業者が保証すべき領域です。SOC レポートの入手が該当します。
切り分けを誤ると、コストが跳ね上がります。 委託先が保証している領域まで自社で検証しようとすれば、工数は際限なく膨らみます。逆に、自社の中核プロダクトについて外部評価を一切持たないまま審査に臨めば、説明は主観的にならざるを得ません。
フレームワークは認証の代わりになるか
認証や評価とは別に、公開されているフレームワークを参照するという道もあります。取得費用が不要である点は魅力ですが、位置づけは異なります。
NIST サイバーセキュリティフレームワーク（CSF）は、あらゆる業種の組織がサイバーセキュリティリスクを管理する枠組みとして広く参照されています。2024年2月26日に公開された 2.0 では、従来の「識別」「防御」「検知」「対応」「復旧」に加えて、6つ目の機能として「統治」が新設されました。組織の方針や役割、監督体制を明確化する機能であり、第1回で扱った IT 全社統制と重なる考え方です。対象範囲も、重要インフラから中小企業を含むあらゆる組織へ拡大されました。
参考：NIST サイバーセキュリティフレームワーク（CSF）2.0 日本語訳（情報処理推進機構）
国内では、経済産業省と情報処理推進機構（IPA）が公表しているサイバーセキュリティ経営ガイドラインがあります。2023年3月に公開された Ver3.0 では、経営者が認識すべき3原則と、経営者が担当幹部に指示すべき重要10項目という構成が維持されつつ、内容が見直されました。経営層の関与とサプライチェーン全体での対策推進が、より強く求められる内容になっています。
参考：サイバーセキュリティ経営ガイドライン Ver3.0（経済産業省・情報処理推進機構／2023年3月24日）
情報セキュリティの管理策そのものを確認するのであれば、経済産業省の情報セキュリティ管理基準が参照できます。
参考：情報セキュリティ管理基準（経済産業省／令和7年改正版）
フレームワークとガイドラインは、自社の取り組みを設計し、抜け漏れを点検するための道具です。取得という概念がないため、第三者が保証したという事実は得られません。認証の代わりにはならず、認証を取る前の設計図として使うものと位置づけるのが適切でしょう。
もっとも、上場準備の初期段階でいきなり認証取得に走るより、フレームワークで自社の現状を整理するほうが順序として健全です。何が足りないかを把握したうえで、説明責任を負う領域から認証を検討する。順序を踏めば、取得すべき範囲は絞られていきます。
取得を判断する3つのポイント
最後に、取得の可否を判断する際のポイントを挙げます。
審査で説明したい論点に直結するか
事業の中核が自社プロダクトであれば技術面の評価が効き、情報資産の保護が論点であればマネジメント体制の認証が効きます。論点と評価がずれていれば、費用に見合いません。
上場スケジュールに間に合うか
認証の取得には準備期間と審査期間が必要です。審査直前に着手しても間に合わない場合があります。着手時期から逆算した判断が求められます。
取得後の運用を継続できるか
多くの認証には維持審査があり、取得後も運用を続ける必要があります。一時的に体裁を整えるだけでは、維持の段階で負担が表面化します。
まとめ
第三者評価は、基準点のない上場審査において、自社の水準を客観的に説明する材料になります。ただし数が多く費用もかかるため、すべてを取得する必要はありません。
「情報セキュリティ」には ISMS 認証、「ビジネス」には利用している基盤の技術レビュー、「財務諸表」には SOC レポートという対応関係を押さえたうえで、自社が説明責任を負う領域は自社で取得し、他社に委ねている領域は他社の保証を入手する。切り分けができれば、費用は必要な範囲に収まります。
フレームワークやガイドラインは、認証の代わりではなく設計図です。現状を整理してから取得を検討する順序を踏めば、範囲は自ずと絞られます。
これまでの3回を通じて一貫していたのは、範囲を絞るという考え方でした。『IT ガバナンスはどこまでやるべきか』では目的別に3領域へ分け、『整備すべきシステムは、思っているより少ない』では財務諸表から遡ってシステムを特定し、今回は説明責任の所在から評価を選びました。
完璧な体制を短期間で作ることは誰にもできません。自社にとって何が重いのかを見極め、根拠を持って優先順位を説明できる状態を作ること。上場審査で問われているのは、整備の完成度ではなく、判断の筋道だと考えています。
無料相談会のご案内
FinanScope では、TOKYO PRO Market 上場に関する無料相談会を実施しています。
相談可能な内容
- TOKYO PRO Market 上場の準備・進め方
- IT ガバナンス・情報セキュリティ体制の整備に関するご相談
- 上場準備における体制整備・資本政策のご相談
特徴
- 自らの TOKYO PRO Market 上場経験に基づく実践的なサポート
- 公認会計士・税理士の資格を持つ担当者が実務目線でアドバイス
- オンラインで全国どこからでも参加可能
▶ ご相談はこちらから https://meetings.hubspot.com/takuma6/finanscope-online
「地方から、新しい可能性を切り拓く」。一社一社の状況は異なりますが、その挑戦を私たち FinanScope は全力で支援します。
TPM や上場準備に関する情報は、FinanScope 公式 note でも継続的に発信しています。最新の市場動向や実務的な知見を定期的に更新していますので、ぜひフォローしてご活用ください。
▶ FinanScope 公式 note：https://note.com/finanscope
