ISMS（ISO/IEC 27001）のリスクアセスメントとは、自社の情報資産にどんなリスクがあるかを洗い出し、その大きさを評価して、対策の優先順位を決めていく一連のプロセスです。ISMS認証の根幹をなす取り組みであると同時に、進め方に迷いやすく、つまずく人が多い工程でもあります。
この記事では、リスクアセスメントの基本的な意味から、実際に自社のリスクを洗い出していく具体的な手順までを、専門用語をかみ砕きながら順を追って解説します。
リスクアセスメントとは、自社の情報資産にどんな危険（リスク）があるかを洗い出し、その大きさを見極めて、対策の優先順位を決めるための一連の作業です。
規格上の定義はもう少し厳密で、JIS Q 27000（ISO/IEC 27000）では、リスクアセスメントは「リスク特定・リスク分析・リスク評価」という3つのプロセス全体を指すとされています。
リスクアセスメントは、リスク特定・リスク分析・リスク評価という3つの段階を順番に進めていきます。
まず「リスク特定」で、自社にどんなリスクがあるかを洗い出します。情報資産ごとに、漏えいや改ざん、利用できなくなるといった危険を見つけ出す段階です。なお、情報資産を起点に洗い出すのは代表的な方法の一つで、規格上は必須の手法ではありません。
次の「リスク分析」では、洗い出したリスクが実際にどのくらい起こりやすく、起きたらどれほどの影響をおよぼすのかを調べます。そして「リスク評価」で、その分析結果をあらかじめ決めた基準と照らし合わせ、どのリスクから優先的に対応すべきかを判断します。
この3段階を踏むことで、「なんとなく不安だから対策する」のではなく、根拠にもとづいて対策の優先順位を決められます。
なお、リスクアセスメントという考え方そのものを基礎から知りたい場合は、以下、入門的な解説記事もあわせて参考にしてください。
混同しやすいのが「リスクアセスメント」と「リスク対応」の関係です。リスクアセスメントは"評価して優先順位を決めるところまで"。その結果を受けて、実際に「どう手を打つか」を決めて実行するのがリスク対応です。
たとえるなら、リスクアセスメントは健康診断、リスク対応はその後の治療や生活改善にあたります。診断（評価）だけして放置すると意味がない一方、診断なしにいきなり治療を始めるのも非効率であり、両者はセットで初めて機能します。
ISMS認証の国際規格であるISO/IEC 27001:2022（以下、ISO/IEC 27001）では、リスクアセスメントの実施が「要求事項」として明確に定められています。具体的には箇条6.1.2でリスクアセスメントのプロセスを確立すること、「箇条8.2」でそれを実施することが求められており、避けて通ることはできません。あわせて6.1.2では、特定したリスクについて、誰が責任を持つかを示すリスク所有者（リスクオーナー）を定めることも求められます。
リスクの考え方がリスクマネジメントの国際規格ISO 31000と整合し、機密性・完全性・可用性（CIA）の喪失という観点からリスクを特定する、という枠組みは、すでに2013年版で確立されています。2022年版では、参照するISO 31000の箇条番号が更新された程度で、リスクアセスメントの手順そのものは変わっていません。
一方で、リスク対応の段階で参照する管理策（附属書A）が114から93へ再編されたため、適用宣言書（SoA）の見直しが必要になりました※。
※参考：一般財団法人日本情報経済社会推進協会（JIPDEC）.「ISMSユーザーズガイド（JIP-ISMS111）」
リスクアセスメントにおけるリスク分析のアプローチには、ベースラインアプローチ・非形式的アプローチ・詳細リスク分析という大きく3つの手法があります※。それぞれの特徴と、自社に合った選び方を順に解説します。
あらかじめ定めた「最低限満たすべき基準」と、自社の現状とのギャップを確認していく手法です。短期間で進められる反面、自社固有のリスクを取りこぼしやすいという弱点があります。
担当者の知識や経験、専門家の助言をもとにリスクを評価する手法です。スピーディーですが、評価が属人的になりやすく、人によって結果がぶれやすい点に注意が必要です。
情報資産ごとに価値や脅威・脆弱性を細かく評価し、点数化していく手法です。手間はかかりますが、客観性が高く、説明責任を果たしやすいのが特徴です。評価は必ずしも厳密な数値化に限らず、高・中・低といった定性的な表し方も可能です。
手法を選ぶ前に、どこまでのリスクを許容するか（リスク受容基準）をあらかじめ決めておくと、評価結果を一貫した物差しで比較しやすくなります。
実務では、これらを単独で使うより組み合わせるのが現実的です。この組み合わせは、正式には「組合せアプローチ」と呼ばれ、複数の手法の長所を生かす4つ目の手法として、GMITS（リスク管理の国際的な技術文書）でも推奨されています。おすすめは、まず全社にベースラインアプローチで共通の最低基準を当て、そのうえで特に重要な情報資産にだけ詳細リスク分析を行う方法です。
小規模で人手が限られるなら、全社にベースラインを当て、重要な資産だけ詳細リスク分析を加える形が現実的です。機微な情報を多く扱う組織や大規模組織は、詳細リスク分析を中心に据えるとよいでしょう。最初から全資産を詳細に分析しようとすると息切れするため、対象にメリハリをつけます。
※参考：独立行政法人情報処理推進機構（IPA）.「中小企業の情報セキュリティ対策ガイドライン」
こちらでは、実際のリスクアセスメントの進め方について、5つのステップに分けてご紹介します。
まずは自社が持つ情報資産を洗い出します。情報資産とは、価値のある情報そのものだけでなく、それを扱う仕組み（書類、PC、サーバー、USBメモリ、ソフトウェア、人など）も含みます。
コツは、いきなり完璧を目指さず、各部署の担当者が日々の業務フローに沿って「これは大事な情報だ」と思うものから挙げていくことです。業務の流れに沿えば、抜け漏れが減ります。
洗い出した情報資産は「情報資産管理台帳」にまとめます。台帳に並べる列は、たとえば次のように設計すると、後のステップにそのままつながります。
| 列の例 | 記入内容 |
|---|---|
| 資産名 | 顧客名簿、契約書、勤怠データ など |
| 管理部署・管理者 | 営業部／○○ |
| 媒体・保存先 | ファイルサーバー、書庫、クラウド など |
| 個人情報の有無 | 有／無 |
| 機密性・完全性・可用性レベル | 各1〜3 |
| 発生可能性レベル | 1〜3 |
| 脆弱性レベル | 1〜3 |
| リスク値 | 算出結果 |
| 対応方針 | 低減／回避／移転／受容 |
最初は前半の列（資産名〜個人情報の有無）だけ埋め、後半の評価列はSTEP3以降で埋めていく、という進め方で構いません。
なお、「個人情報の有無」が「有」の資産は、漏えい時に個人情報保護法上の報告・通知の対象になりうるため（要配慮個人情報や1,000人超などの場合）、重要度を高めに見ておくと安全です。
台帳に並べた資産ごとに、どんな危険があるかを洗い出します。このとき手がかりになるのが、情報セキュリティの3要素「CIA」です。CIAとは、機密性（Confidentiality）・完全性（Integrity）・可用性（Availability）の頭文字をとった呼び方で、情報資産が安全に使える状態を示します。機密性は許可された人だけが情報にアクセスできること、完全性は情報が正確で改ざんされていないこと、可用性は必要なときにいつでも使えることを指します。
この3つのいずれかが損なわれる場面を具体的に思い浮かべると、危険を漏れなく洗い出せます。たとえば機密性なら「メールの誤送信」「USBメモリの紛失」、完全性なら「データの入力ミス」「改ざん」、可用性なら「サーバー停止」「災害による機器の損壊」といった具合です。資産ごとに、この3方向から危険を書き出していきます。
| 要素 | 意味 | 損なわれる例 |
|---|---|---|
| 機密性（Confidentiality） | 許可された人だけが情報にアクセスできる状態 | 関係者以外に情報が漏れる、メールの誤送信、USBメモリの紛失 |
| 完全性（Integrity） | 情報が正確で、改ざんされていない状態 | データの入力ミス、第三者による改ざん |
| 可用性（Availability） | 必要なときにいつでも使える状態 | サーバー停止、災害による機器の損壊で使えなくなる |
どんな脅威を想定すべきか迷ったら、IPA（情報処理推進機構）が毎年公表する「情報セキュリティ10大脅威」が参考になります。2026年版（組織編）では、ランサムウェア被害が1位、サプライチェーンや委託先を狙った攻撃が2位を維持し、「AIの利用をめぐるサイバーリスク」が初めてトップ3に入りました※。ただし、これはあくまで世の中全体の傾向です。一覧をそのまま自社のリスクとして書き写すのではなく、自社の情報資産や事業環境に関係するものを選び取って当てはめていくようにしましょう。
※参考：独立行政法人情報処理推進機構（IPA）.「情報セキュリティ10大脅威 2026」
特定したリスクについて、その大きさを「重要度」「発生可能性」「脆弱性」の3つの要素から評価します。
重要度は、そのリスクが現実になったときに自社が受ける影響の大きさです。金銭的な損失だけでなく、取引先からの信用低下や法的責任なども含めて考えます。先ほどのCIAの観点でいえば、機密性・完全性・可用性のどれがどれだけ損なわれるかを見て判断します。発生可能性は、そのリスクがどのくらいの頻度で起こりうるかです。過去のトラブル履歴や、現在の対策状況をふまえて評価します。脆弱性は、管理上の弱点や対策の不備のことで、これが大きいほどリスクは現実になりやすくなります。
この3つの要素を評価し、かけ合わせてリスクの大きさを数値化します。詳しい数値の出し方は次章で解説します。
算出したリスク値を、あらかじめ決めておいた基準（例：「○点以上は要対応」）と照らし合わせ、対応の要否と優先順位を判断します。この「基準」を先に決めておくと、担当者による評価のぶれを防げます。
あわせて、リスクごとに「誰がそのリスクに責任を持つか」というリスク所有者を決めておきます。ISO/IEC 27001では、このリスク所有者を特定することが要求事項として定められています。
リスクの分析では、「どのリスクが、どれだけ大きいか」を比較できる形にする必要があります。
そこで使われるのが、リスクの大きさを表す「リスク値」です。この章では、リスク値の算出式を確認し、重要度・発生可能性・脆弱性のレベル設定例を示します。そのうえで、実際の資産を例にリスク値を計算し、評価がブレないための基準の決め方までを順に解説します。
リスク値の代表的な算出方法は、次のかけ算です。
リスク値 ＝ 重要度レベル × 発生可能性レベル × 脆弱性レベル
ここで重要な注意点があります。このリスク値の算出は、あくまで一般的な実務手法であって、ISO/IEC 27001の要求事項として必須なわけではありません。規格が求めているのは「一貫性があり、妥当で、比較可能な結果を出せる基準を定めて評価すること」です。数値化は、そのための分かりやすい一手段と捉えてください。
各観点を3段階で評価する場合の例です。レベルの段階や内容は、組織が自社の実情に合わせて自由に設定できます。
| レベル | 重要度（影響度） | 発生可能性 | 脆弱性 |
|---|---|---|---|
| 1 | 影響は限定的 | ほとんど起きない | 適切に管理されている |
| 2 | 一時的に業務が停滞 | 数年に一度程度 | 改善の余地がある |
| 3 | 事業継続が困難・信用失墜 | 年に数回以上 | ほとんど管理されていない |
クラウド上のデータを扱う営業担当者のノートPCを例に計算してみます。
まず重要度は、機密性3・完全性2・可用性3のうち最も高い値を採用して「3」とします。次に発生可能性は、持ち運ぶ機会が多く紛失の恐れがあるため「2」と評価します。脆弱性は、生体認証を設定し持ち出しルールも整備済みであることから「2」としました。
これらをかけ合わせると、リスク値は 3 × 2 × 2 ＝ 12 になります。あとはこの「12」を自社の基準と照らし合わせ、対応が必要かどうかを判断します。
なお、対策を講じたあとに同じ式でリスク値を測り直すと、対策によってリスクがどれだけ下がったか（残留リスク）を確認できます。
リスクアセスメントの理想は、「誰が評価しても同じ結果になる」ことです。これに近づけるには、数値の定義をあらかじめ言葉で固めておく必要があります。
たとえば「発生可能性レベル3＝年に数回以上発生している」のように、各レベルが指す状態を具体的な事象で定義します。さらに、機密性・完全性・可用性で評価が割れたときは「最も高い点数を採用する」といった一律のルールを決めておくと、担当者による判断のばらつきを最小限に抑えられます。
なお、最も高い点数を採るのは代表的なやり方の一つで、合計や加重平均で評価する組織もあります。いずれにせよ、社内で一つのルールに統一しておくことが大切です。
リスク評価が終わったら、対応方針を決めます。対応の選択肢は大きく4つです。
| 対応方針 | 詳細 |
|---|---|
| リスク低減 | 対策を施して発生可能性や影響を小さくする （例：データの暗号化、アクセス権限の設定） |
| リスク回避 | リスクの原因そのものを断つ （例：PCの社外持ち出しを禁止する） |
| リスク移転 | 外部にリスクを移す （例：業務の外部委託、サイバー保険への加入） |
| リスク受容 | 対策せず、リスクを認識したうえで受け入れる （例：影響が小さく対策費用のほうが高くつくリスクを、対応せず受け入れる） |
なお、リスク移転は「リスク共有」とも呼ばれます。外部委託やサイバー保険でリスクの一部を移しても、最終的な説明責任や本人への対応義務は自社に残る点に注意が必要です。たとえば委託先で個人情報が漏えいしても、委託元の監督責任は免れません。
このうちリスク低減では、ISO/IEC 27001の附属書Aにある管理策のなかから自社に必要なものを選び、その採否を「適用宣言書（SoA）」としてまとめることが求められます※。
ここで注意したいのが、基準を超えたリスクのすべてに必ず対応する必要はない、という点です。対策にかかるコストが、リスクが現実になったときの損失を上回るなら、その対策に合理性はありません。
「基準超過＝即対応」と機械的に考えるのではなく、費用対効果を冷静に見極めます。ただし受容する場合も、「なぜ対応しないのか」という根拠は記録に残しておきます。理由が説明できないまま放置するのとは、まったく意味が違います。
※参考：「ISO/IEC 27001 及び ISO/IEC 27002 の活用―情報セキュリティ管理策を軸に―」. 日本ネットワークセキュリティ協会（JNSA）情報セキュリティマネジメント・セミナー2023
多くの組織が陥りがちな失敗を、対策とあわせて整理します。
資産やリスクの洗い出しに工数をかけすぎ、本来の目的である「対策の決定」まで力尽きてしまうケースです。最初から完璧な網羅性を狙わず、影響の大きい重要資産から優先的に着手します。洗い出しは目的ではなく、対策を決めるための手段だと捉えておきます。
発生可能性や影響度の定義が主観的だと、評価者ごとに結果がばらつきます。前述のとおり、各レベルを具体的な事象で定義し、組織内で共有しておくことで防げます。
リスクアセスメントが審査のためだけの書類づくりになり、現場の改善につながっていないケースです。事務局だけで完結させず現場の声を吸い上げ、決めた対策が「自分たちを守るためのもの」だと現場に伝えれば、形骸化を防げます。
ISMSのリスクアセスメントは、「リスク特定→分析→評価」を通じて対策の優先順位を決め、リスク対応へつなげる一連のプロセスです。難しく考えすぎず、「優先順位を明確にし、対策を講じる」という本来の目的を見失わないことが軸になります。
そして、リスクは一度評価して終わりではありません。ISO/IEC 27001は、あらかじめ定めた間隔で、または重大な変化が生じたときにリスクアセスメントを実施するよう求めています。継続的に見直してこそ、形だけでない、実態に即した仕組みになります。
完璧を目指して立ち止まるより、まずは自社にとって最も大切な情報資産を1つ洗い出し、台帳の1行目を埋めるところから始めてみてください。
ユービーセキュアでは、ISMSのリスクアセスメントで洗い出した技術リスクを実際に検証する脆弱性診断、外部公開資産のリスク可視化（ASM）、専門家によるリスクアセスメント設計支援を提供しています。リスクアセスメントの進め方や、評価結果を実効性のあるリスク対応につなげる方法に迷ったら、お気軽にご相談ください。