リスクアセスメントの進め方｜評価基準の設計

リスクアセスメントは、ISMSで最も工数がかかり、最も品質差が出る工程です。そして審査で最も深く掘られる工程でもあります。審査員が見ているのは、リスク値の数字そのものではありません。その数字がどういう基準で付いたのか、別の人が同じ手順で評価しても同等の結果になるのかです。

規格は、リスクアセスメントについて「繰り返し実施したときに、一貫性があり妥当で比較可能な結果が得られること」を求めています。この一文が、実務上のすべての要求を規定しています。比較可能にするためには基準が固定されていなければならず、基準を固定するには評価を始める前に尺度を言語化しておかなければならない。リスクアセスメントの品質は、評価作業ではなく基準の設計で決まります。

本記事は、基準の設計を軸にリスクアセスメントの進め方を整理します。前提となる台帳は 情報資産の洗い出しと台帳の作り方、規格上の位置づけは 箇条6 計画｜リスクアセスメントと情報セキュリティ目的、規格全体は ISMS（ISO/IEC 27001）とは をご覧ください。

免責：本記事は一般的な情報提供です。規格の要求事項の解釈、認定・認証の取扱いは、ISO/IEC 27001（JIS Q 27001）の規格本文および認定機関・審査機関の公表資料が正本です。実際の対応はそれらに基づいて行ってください。

なぜここでつまずくのか

1. 「評価する」ことから始めてしまう

台帳ができたので、さっそく点数を付け始める。ここで多くのプロジェクトが品質を失います。基準の設計は評価の前に完了していなければならないのに、評価しながら基準を後付けすると、最初に評価した資産と最後に評価した資産で判定が変わります。同じ台帳の中で基準が揺れている状態は、審査で必ず見抜かれます。

2. 附属書Aから逆算してしまう

93管理策を上から並べ、それぞれに対応するリスクを後付けする作り方です。形式的にはSoAが埋まりますが、自社固有のリスクが一つも出てきません。附属書Aは検証用のチェックリストであって出発点ではないという原則は、ここで最もよく破られます。

3. 網羅性と実行可能性のバランスを取れていない

台帳が200行あり、各行に脅威が5つ、脆弱性が3つ——と展開すると3000件のリスクが生まれます。これを全部評価するのは不可能で、実際には途中で機械的な処理に切り替わります。評価する件数を最初に見積もり、そこから逆算して展開の粒度を決める必要があります。

4. リスク所有者を後回しにしている

評価が終わってから「誰を所有者にするか」を決めると、結局ISMS責任者が全件を引き受けることになります。リスク所有者は、そのリスクについて対応を決め、残留リスクを受け入れる権限を持つ人です。権限の実態と合わない台帳は、審査での定番の指摘です。

何を決めるのか

評価を始める前に決めるべきものは、次の5つです。

資産ベースとシナリオベース

これが最初の分岐です。両者は排他ではなく、併用が現実的な解になることが多いと考えられます。

初回は資産ベースで網羅性の土台を作り、そこにシナリオベースで自社固有のリスクを追加する——この組み合わせが、審査と実効性の両方を満たします。シナリオベースで追加すべき項目は業態によって決まり、ヘルスケアでは後述の例が該当します。

3段階か5段階か

尺度の段階数は、評価者の人数と、つけたい優先順位の細かさで決めます。

中小規模のヘルスケア企業では、3段階から始めるのが実務的です。5段階は一見精緻ですが、各段階に判定可能な文言を書き分けられないと、結局「3」が多発して3段階より粗い結果になります。段階を増やすのは、評価が安定してから2年目以降に検討すれば足ります。少人数組織での進め方は 少人数組織のISMS もご覧ください。

受容基準の線をどこに引くか

ここが最も重要な決定です。 受容基準とは、「この値以下のリスクは追加対応せず受け入れる」という線です。線を引かずに評価を始めると、高リスクが200件出て対応しきれないという状態になります。

正しい順序は逆算です。

1. 次の1年間で、リスク対応に充てられる工数と予算を見積もる
2. その範囲で対応できるリスクの件数を概算する（たとえば30〜50件）
3. 評価を試行し（台帳の一部、20〜30行程度）、リスク値の分布を見る
4. 分布を見ながら、対応必須となる件数が2の範囲に収まるよう線を引く
5. 線を引いた根拠を文書に残す

5番目が重要です。「なぜこの線なのか」の説明がないと、審査で「基準の妥当性」を問われたときに答えられません。「当社の年間のセキュリティ投資可能額と要員体制から、年間◯件程度の対応が上限であり、リスク値◯以上をその範囲とした」という説明が成立します。

実務の手順

手順1：リスクアセスメント手順書を先に書く

評価を始める前に、手順書として次を文書化します。アプローチ、評価尺度の定義（文言つき）、リスク値の算出方法、受容基準、リスク所有者の割り当て規則、実施の頻度とタイミング。この文書が「繰り返しても比較可能」を担保する仕掛けです。

手順2：尺度を文言で定義する

結果（影響度）と起こりやすさの両方について、各段階に判定可能な文言を書きます。

ヘルスケアでは、影響度の尺度をC・I・Aで別に定義する設計が有効です。 一般的な尺度は機密性の観点に寄りますが、治験データや診療記録では完全性の毀損が、電子カルテ連携では可用性の毀損が、それぞれ最大の影響になります。1本の尺度に押し込めると、この差が消えます。

手順3：小さく試行して分布を見る

台帳の20〜30行で評価を試行します。この段階で「全部『中』になる」「高リスクが半分を超える」といった問題が見えるため、尺度の文言を調整できます。全件を評価してから尺度を直すのは、全件の再評価を意味します。

手順4：資産ベースで全件を展開する

台帳の各行に対し、脅威と脆弱性を当てはめてリスクを特定します。展開の粒度をここで制御します。脅威のカタログをあらかじめ用意し、資産の分類ごとに「当てはめる脅威の組み合わせ」を決めておくと、件数が制御でき、評価者による展開のばらつきも減ります。

手順5：シナリオベースで自社固有のリスクを追加する

資産ベースの展開では出てこないリスクを、事象から考えて追加します。現場のエンジニア・サポート担当を交えた議論の形式が有効です。「もしこれが起きたら」という問いから入ると、台帳の行からは導けないリスクが出てきます。

手順6：リスク所有者を割り当てる

割り当ての規則を先に決めておきます。実務的には、その資産を業務で使っている部門の長が自然です。判断の軸は「この人は、対応するかしないかを決められるか」「残留リスクを受け入れると言えるか」の2点です。

手順7：評価結果をレビューし、基準の妥当性を確認する

全件の評価が終わったら、分布を確認します。高リスクが想定件数を大幅に超えている、あるいはゼロに近い場合、尺度か受容基準に問題があります。この段階での基準の見直しは正当ですが、見直したら全件を再評価し、見直しの経緯を記録に残す必要があります。

よくある失敗

リスク値が全部「中」になる

尺度に判定可能な文言がないときに必ず起こります。評価者は無難な中央値を選びます。手順2を丁寧にやることでしか防げません。

受容基準を後から決めた

評価が終わってから「高リスクが多すぎるので、基準を上げよう」と線を動かす。これ自体は手順7として正当なのですが、動かした理由が「件数が多かったから」だけでは説明になりません。工数・予算からの逆算という根拠が必要です。

同じ資産に対して評価者ごとに違う値がついている

部門ごとに評価を任せたときに起こります。尺度の文言を配布するだけでなく、評価の前に実例で認識を合わせる場（30分程度の説明会）を設けるのが効果的です。

脅威と脆弱性が混ざっている

「アクセス制御が不十分」は脆弱性であって脅威ではありません。「不正アクセス（脅威）が、アクセス制御の不備（脆弱性）を突いて発生する」という構造で整理すると、対応の設計が具体的になります。混ざっていると、リスク対応で何を直せばよいかが導けません。

自社固有のリスクが1件もない

一般的な脅威カタログをそのまま当てはめた結果、どの会社でも同じ内容の台帳になっている状態です。審査で「リスクアセスメントが形式的である」と評価されます。手順5が対策です。

リスク所有者がISMS責任者に集中している

前述のとおり定番の指摘です。手順6の規則を先に決めることで回避できます。

2年目に基準を変えてしまう

比較可能性が失われます。改善のために基準を変えること自体は認められますが、変更した年は前年との比較ができないため、変更の理由と影響を記録に残す必要があります。無自覚に尺度の文言を書き換えるのが最も危険です。

評価の記録に「いつ・誰が」がない

リスクアセスメントは記録として維持する必要があります。実施日、評価者、承認者が記録されていないと、繰り返し実施していることを示せません。

ヘルスケア企業の例

一般的な脅威カタログからは出てこず、シナリオベースで追加すべきリスク項目を業態別に挙げます。

医療機関向けSaaSを提供する企業

AI機能のリスク設計は既存記事の AI音声カルテのセキュリティ、権限設計は MCPの権限設計、責任分界は AI電子カルテのセキュリティ設計｜責任共有モデル が参考になります。

PHR事業者

同意管理の不備が独立したリスク項目として立ちます。同意の撤回が反映されないまま利用が続く、範囲変更の履歴が追えない——いずれも法令違反に直結します。詳細は PHR事業者のISMS｜個人情報保護法との関係 をご覧ください。

治験・臨床研究システムを扱う企業

完全性に重みを置いた尺度が必須です。「監査証跡の欠落」「事後の改変が検知できない」は、機密性の毀損と同等かそれ以上の影響を持ちます。影響度の尺度をC・I・Aで分けて定義する設計が、ここで効きます。

SaMDを開発する企業

リスクアセスメントがISMSのリスクと製品安全性リスク（ISO 14971）の二系統になります。統合すべきではありませんが、接点は明示します。「ソフトウェア更新の配信経路が侵害される」というセキュリティリスクは、製品側では「誤動作による患者への危害」に接続します。SaMDとISMS・QMSの関係 で扱います。

共通：3省2ガイドラインとの接続

顧客である医療機関が求める安全管理措置は、リスクアセスメントの結果として導かれた対応と重なります。ガイドライン対応を別立てのプロジェクトにせず、リスク対応計画の中に位置づけると管理が一本化できます。ガイドラインの全体像は既存記事の 3省2ガイドラインとは、実務ステップは 3省2ガイドライン対応の実務ステップ をご覧ください。

まとめ

1. リスクアセスメントの品質は、評価作業ではなく基準の設計で決まる。手順書を先に書く
2. 初回は資産ベースで網羅性の土台を作り、シナリオベースで自社固有のリスクを追加する。附属書Aからの逆算は避ける
3. 尺度は3段階から始めるのが実務的。各段階に判定可能な文言を付けなければ、段階数を増やしても精度は上がらない
4. 受容基準は、対応できる工数と予算から逆算して引く。線を引いた根拠を文書に残す
5. リスク所有者は対応を決め、残留リスクを受け入れられる人。部門長が自然な単位で、ISMS責任者への集中は指摘される
6. 全件評価の前に20〜30行で試行し、分布を見て尺度を調整する。全件評価後の尺度変更は全件再評価を意味する

評価が終わったら、対応の選択と受容の判断に進みます。リスク対応計画とリスク受容の判断、その結果をまとめる 適用宣言書（SoA）の書き方 へと続きます。土台となる台帳は 情報資産の洗い出しと台帳の作り方 をご覧ください。

ポテックは、ヘルスケア領域に特化してISMS認証取得を支援しています。評価基準の設計と、ヘルスケア固有のリスク項目の洗い出しは、業界を知っているかどうかで結果が変わる領域です。支援内容と料金は ISMS認証取得支援サービス、個別のご相談は お問い合わせ から承ります。

参考・出典

• 情報マネジメントシステム認定センター（ISMS-AC）
• ISO/IEC 27001 Information security management systems｜ISO
• ISO 31000 Risk management｜ISO
• 日本産業標準調査会（JISC）
• 医療情報システムの安全管理に関するガイドライン｜厚生労働省
• 個人情報保護委員会

※規格の要求事項の解釈、認定および認証の取扱いは、規格本文および認定機関・審査機関の公表資料をご確認ください。改定や運用の見直しにより取扱いが変わる場合があります。