グループ全体のリスクアセスメント手法の見直しと残留リスクの受容判断

結論：ベースラインアプローチで全社を底上げし、変化のあった領域に詳細リスクアセスメントを重ねる「組合せ」が適切。

理由の組み立て

1. 現状は事実上「詳細リスクアセスメントのみ」を5名で回しており、620資産×グループ3社を毎年評価する工数が確保できない。評価の粗さが「上位30件だけ見る」という運用を生み、SaaSのように台帳に載らない対象を落としている。
2. ベースラインアプローチ（標準的な管理策の充足状況をチェックする方式）は工数あたりの網羅性が高く、全社・グループ会社の底上げに向く。ただし重要資産の個別リスクは見えない。
3. したがって、①全社はベースラインで点検、②重要業務（受注・出荷・EDI）、③クラウド／外部委託、④サポート終了など「変化のあった領域」には詳細リスクアセスメントを適用する二層構造とする。

実務上の要点

• 資産ベースではなく業務・サービスベースで洗い出す。SaaSは「機器・ソフトの台帳」に入らないため、業務単位で棚卸ししないと同じ漏れが再発する。
• 尺度（影響度3段階・発生可能性3段階など）としきい値を先に全社合意する。B社の独断は尺度が共有されていなかったことに起因する。
• 各リスクに対し回避／低減／移転／受容のいずれを選んだか、誰が承認したかを記録する。予算配分の根拠はこの記録が担う。

整理：これは「リスク低減の先送り」であり、正式な「リスク受容」ですらない。

• 回避：当該システムの廃止、業務プロセスの変更。
• 低減：OS移行、ネットワーク分離、WAFやEDRによる緩和、監視強化。B社が本来選ぶべきだった選択肢。
• 移転：ベンダの延長サポート契約、サイバー保険。
• 受容：リスクを認識した上で、対策を打たずに保持すると決めること。

B社の状態は、低減策を実施しないまま2年が経過しており、結果として受容しているのと同じ状態である。しかし、①リスクの大きさを評価した記録、②受容の意思決定、③責任者、のいずれも存在しない。これは「管理された受容」ではなく「放置」であり、監査上は不備となる。

受容の主体 受容はリスクを保有する業務部門の責任者が起案し、CISOが全社リスク基準との整合を確認した上で、最終的に経営会議（グループ全体のリスクなら持株会社の経営会議）が承認する。B社単独の判断で閉じてはならない。承認時には、受容する期間、再評価のトリガ（新たな脆弱性公表、インシデント発生、残存サポート期限）、モニタリング方法を併せて記録する。

原因分析 台帳の登録対象が「情報システム部が所管する機器・ソフトウェア」と種類で定義されていたため、部門が経費で直接契約するSaaSは構造的に登載されない。加えて、調達・契約プロセスを経由しない利用（いわゆるシャドーIT）を検知する仕組みがなく、外部委託先台帳との突合も行われていない。

再発防止策

1. スコープの再定義：台帳の登録単位を「業務・情報」に変更し、その業務が依存するシステム、SaaS、外部委託先を紐づける。
2. 契約経路の一元化：SaaSの新規契約は情報システム部の審査を必須とし、経費精算・購買申請の勘定科目からSaaS利用を検知する。
3. 技術的な可視化：SSO／IDaaSへの集約で利用中サービスを把握し、CASB等で未承認のクラウド利用を検出する。
4. 外部委託先管理との統合：委託先台帳と資産台帳を年1回以上突合し、アクセス権限の棚卸しを定期実施する。
5. 運用手続き：四半期ごとの棚卸しと、その結果を情報セキュリティ委員会へ報告する責任者・期限の明確化。