セキュリティリスクアセスメントは、情報資産に対する脅威・脆弱性・影響度を体系的に分析し、組織として優先的に対応すべきリスクを特定するためのプロセスです。ISO/IEC 27001（ISMS）の中核要件であり、認証取得・維持の必須ステップに位置づけられます。

しかし、多くの中堅企業では「テンプレートにリスクを書き出すだけ」「年1回の形式作業」になりがちで、実際のセキュリティ対策につながっていません。形式と実態が乖離すると、ISMS審査で指摘を受けるだけでなく、現実のインシデント発生時に判断材料を欠きます。

本記事では、ISMS対応のセキュリティリスクアセスメントを実務で機能させるための手順を、ISO/IEC 27001:2022の要求事項に沿って整理します。情報資産棚卸しから残留リスク承認まで、中堅企業の情シスが運用できる現実解を示します。

対象読者は、ISMS認証取得を主導する情報セキュリティ責任者、リスクアセスメントを実施するIT管理担当者、内部監査担当者です。

セキュリティリスクアセスメントとは｜ISMSにおける位置づけ

セキュリティリスクアセスメントは、ISO/IEC 27001の要求事項6.1.2「情報セキュリティリスクアセスメント」で定義されるプロセスです。情報資産に発生しうるリスクを特定・分析・評価し、対応の優先順位を決定する一連の活動を指します。

このプロセスは、ISMSの中で「リスクベースで管理策を選択する」ための土台として機能します。組織の規模や業界に関係なく、自社固有のリスクを把握したうえで、適切な管理策を選び、リソースを配分する判断材料になります。

リスクアセスメントとリスク対応の違い

リスクアセスメントは「リスクを特定・分析・評価する」段階であり、リスク対応は「特定されたリスクに対して低減・保有・回避・共有（移転）のいずれを選ぶか決定する」段階です。両者は連続したプロセスとして設計します。

中堅企業ではこの2段階を混同し、リスクを書き出した直後に対策表を作るパターンが多く見られます。リスク評価基準が曖昧なまま対策に進むと、優先順位を取り違えます。

ISMSリスクマネジメントプロセスの全体像

ISO/IEC 27001は、リスクアセスメントを単発の作業ではなく、計画から実施・見直しまでを繰り返すリスクマネジメントプロセスの一部として要求しています。規格の条項との対応を先に押さえておくと、審査で「どの活動がどの要求に応えているか」を説明しやすくなります。

6.1.2・6.1.3が「プロセスの決め方」を定める計画段階の条項、8.2・8.3が「決めたプロセスを運用の中で実際に回す」実施段階の条項という関係です。さらに内部監査（9.2）やマネジメントレビュー（9.3）で有効性を確認し、次回のアセスメントに反映することで、プロセス全体が循環します。本記事で解説する5ステップは、この規格要求を実務の作業単位に置き換えたものです。

ISO/IEC 27001:2022での位置づけ

2022年版では、Annex Aの管理策が93個に再編され、リスクアセスメントの結果に応じて適切な管理策を選択する構造が強化されました。リスク評価結果と管理策の対応関係を「適用宣言書（SoA）」で文書化することが求められます。

2025年10月31日の移行期限を経て、現在はISO/IEC 27001:2022（国内対応規格はJIS Q 27001）が認証審査の基準となっています。これから認証取得を目指す場合も、2022年版のAnnex A構成を前提にリスクアセスメントを設計します。

参考：JIS Q 27001:2023 - 経済産業省

リスクアセスメントの全体像｜5ステップで構成される標準プロセス

リスクアセスメントは、情報資産棚卸しから残留リスク承認まで5つのステップで構成されます。各ステップで必要なアウトプットが明確になっているため、プロジェクト管理の単位として機能します。

ステップ間の依存関係を理解せず、並行で進めると、後のステップで前段のやり直しが発生します。順序を守ることが結果的に最短経路です。

ステップ1：情報資産の特定と棚卸し

組織が保有する情報資産を業務プロセス単位で洗い出します。電子データ、紙文書、システム、ソフトウェア、人、施設など、価値を持つ全ての資源が対象です。中堅企業では、SaaSサービス・クラウドストレージ上のデータも漏れなく含めます。

棚卸しの粒度は、後続の評価作業に耐えうるレベルまで細かくします。ただし、細かすぎると数百〜数千件の資産が並び、評価が形骸化します。500件以下を目安に、業務単位でグルーピングします。

SaaSの利用実態を把握できていない場合は、棚卸しの前に利用サービスの可視化から着手します。ISMSの管理策とSaaS管理の関係はISMS対応でSaaS管理が問われる理由で詳しく解説しています。

ステップ2：リスク評価基準の設定

リスクの大きさを判断するための基準を、評価実施前に明確にします。機密性・完全性・可用性（CIA）の各観点で、影響度と発生頻度を3〜5段階で定義します。

判断基準を文書化しないまま評価を進めると、評価者によって結果が大きくばらつき、再現性のないアセスメントになります。基準書は経営層が承認し、組織共通のルールとして運用します。

ステップ3：脅威・脆弱性の特定とリスク分析

各情報資産に対して、想定される脅威（不正アクセス、マルウェア、内部不正、災害など）と脆弱性（パッチ未適用、アクセス権過剰付与、教育不足など）を組み合わせて、リスクシナリオを書き出します。

シナリオごとに、影響度×発生頻度でリスクレベルを算出します。中堅企業では、過去のインシデント実績、業界事故事例、IPAの脅威動向などを参考に、現実的なシナリオを設定します。

書き出した脅威シナリオは、実際に発生した場合の対応フローとセットで検討すると現実味が増します。検知から再発防止までの流れはセキュリティインシデント対応手順を参照してください。

ステップ4：リスク評価とリスク対応決定

算出したリスクレベルを評価基準と照合し、許容できるリスクと対応が必要なリスクを区別します。対応が必要なリスクには、低減・保有・回避・共有（移転）の4つの選択肢から最適な対応を選びます。

低減は管理策の追加、保有は基準の範囲内での受け入れ、回避は活動の中止、共有（移転）は保険や委託によるリスクの分配です。それぞれの判断基準は後述の「リスク対応の4つの選択肢」で詳しく解説します。経営判断を伴うため、対応方針は経営層またはISMS委員会で承認します。

ステップ5：残留リスクの承認と文書化

リスク対応後も残るリスクを「残留リスク」として明示し、経営層が承認します。残留リスクの承認はISMS審査で必ず確認される項目で、責任所在を経営層に置く構造が求められます。

リスクアセスメント結果、リスク対応計画、適用宣言書、残留リスク承認記録を、ISMS文書として整理・保管します。次回アセスメント時の比較基準にもなります。

これらの文書は内部監査・外部審査の主要な確認対象です。監査側の視点で何が見られるかはセキュリティ監査の実施方法で解説しています。

参考：情報セキュリティ監査制度・管理基準 - 経済産業省

リスク特定・リスク分析・リスク評価のやり方｜ISMSが求める3つの活動

ISO/IEC 27001の6.1.2は、リスクアセスメントを「リスク特定」「リスク分析」「リスク評価」の3つの活動として定義しています。前章の5ステップではステップ3・4の中核にあたる部分です。

‍

審査では規格の用語で質問されるため、社内の手順書もこの3つの活動に対応づけて整備しておくと、説明の手戻りがなくなります。ここでは各活動で何をすべきかを規格の要求に沿って掘り下げます。

リスク特定｜資産ベースと事象ベースの2つのアプローチ

リスク特定は、機密性・完全性・可用性の喪失に関するリスクを漏れなく洗い出す活動です。ISO/IEC 27001の6.1.2では、特定した各リスクにリスク所有者（リスクを運用管理する責任と権限を持つ人）を決めることも要求されます。所有者が決まっていないリスクは、対応の意思決定が宙に浮くため、審査でも確認されるポイントです。

リスクマネジメントの指針であるISO/IEC 27005では、リスク特定のアプローチとして2つの型が示されています。

• 資産ベースアプローチ：情報資産の一覧に対して、脅威と脆弱性の組み合わせからリスクを洗い出す。網羅性が高く、資産台帳と直結するため運用しやすい
• 事象ベースアプローチ：経営目標を脅かす事象・シナリオ（ランサムウェア感染による事業停止など）を起点にリスクを洗い出す。経営層と共有しやすい

中堅企業では、資産ベースを軸に据えて網羅性を確保し、経営影響の大きいシナリオを事象ベースで補完する組み合わせが現実的です。洗い出しの参考情報としては、IPAが毎年公表する情報セキュリティ10大脅威、業界の事故事例、自社の過去インシデントが有効です。

リスク分析｜起こりやすさと結果の大きさを見積もる

リスク分析は、特定したリスクが現実になった場合に起こり得る結果（影響の大きさ）と、現実的な起こりやすさ（発生頻度）を見積もり、リスクレベルを決定する活動です。

分析の手法は、大きく定性的評価と定量的評価に分かれます。定性的評価は影響度・発生頻度を3〜5段階の尺度で見積もる方法で、少ない工数で全資産をカバーできます。定量的評価は損失額や復旧費用を金額で見積もる方法で、精度は高いものの算定根拠の整備に工数がかかります。

中堅企業の初回アセスメントでは、定性的評価で全体を分析し、リスクレベルの高いものだけ金額影響を補足する運用が現実的です。評価者によるばらつきを抑える尺度の作り方は、次章「リスク評価基準の設計」で解説します。

リスク評価｜リスク受容基準と比較して優先順位を決める

リスク評価は、リスク分析の結果をあらかじめ定めたリスク基準と比較し、対応の優先順位を決める活動です。リスクアセスメントの最終工程であり、ここでの判断がリスク対応計画の入力になります。

具体的には、算出したリスクレベルをリスク受容基準（組織として受け入れられるリスクの水準）と突き合わせ、基準を超えるリスクをリスク対応の対象として優先順位付けします。基準内に収まるリスクは保有（受容）とし、状況変化がないか継続的に監視します。

評価結果は「リスクレベル順に並んだ対応候補の一覧」として文書化します。この一覧が、経営層・ISMS委員会がリスク対応の意思決定を行う際の判断材料になります。

参考：情報セキュリティ10大脅威 2026 - IPA

リスク評価基準の設計｜影響度・発生頻度の定量化

リスクアセスメントの精度は、評価基準の設計品質で大きく変わります。基準が抽象的だと評価結果が再現できず、ISMS審査で指摘を受けます。

中堅企業では3〜5段階のシンプルな基準で十分機能します。基準を厳密にしすぎると、評価作業が膨大になり継続できません。

影響度の評価尺度

影響度は機密性・完全性・可用性の3軸で評価します。例えば機密性なら、「個人情報・営業秘密が大量漏えい（5）」「重要顧客情報が漏えい（4）」「社内機密情報が漏えい（3）」「業務情報が漏えい（2）」「公開情報のみ（1）」のような区分です。

定量基準を設けることで、評価者間のばらつきが抑えられます。金銭的影響、復旧時間、社会的信用への影響など、組織にとって測りやすい尺度を選びます。

発生頻度の評価尺度

発生頻度は「年に複数回想定（5）」「年1回程度想定（4）」「数年に1回程度（3）」「10年に1回程度（2）」「ほぼ発生しない（1）」のような区分が一般的です。

過去のインシデント記録、業界統計、脆弱性公表情報などを参考に、根拠を持って区分します。経験則だけで判断すると、楽観的すぎる評価になりがちです。

リスクレベルの算出方法

影響度×発生頻度でリスクレベルを算出します。5×5マトリクスなら、25が最大、1が最小です。算出値を「高（15以上）」「中（8〜14）」「低（7以下）」のような区分にまとめ、対応優先度を決定します。

中堅企業では、高リスクは即時対応、中リスクは年度内対応、低リスクは許容（または継続監視）という運用が標準的です。経営資源の制約を踏まえた現実的な対応計画を立てます。

リスク受容基準の設定方法

リスク受容基準は、組織としてどこまでのリスクなら受け入れられるかを定めた基準です。ISO/IEC 27001の6.1.2では、リスク基準の一部としてリスク受容基準を確立し維持することが要求されており、基準がないまま「このリスクは保有とする」と判断すると、審査で根拠を問われます。

実務では、次の3つの要素を組み合わせて設定するのが標準的です。

• リスクレベルの閾値：「低（7以下）は受容する」のように、算出値で機械的に線を引く
• 条件付き受容：「中（8〜14）は、対応コストがリスクの想定損失を上回る場合に限り、リスク所有者の承認を得て受容できる」のような条件を付す
• 受容できないリスクの明示：法令違反・重要な契約違反に直結するリスクは、リスクレベルにかかわらず受容の対象外とする

受容基準は経営層が承認し、リスク評価基準書の一部として文書化します。事業内容や法規制の変化で受け入れられる水準は変わるため、年次のマネジメントレビューで見直す運用を組み込みます。

記入例｜SaaSアカウント管理を題材にした評価の具体例

評価基準の使い方を、中堅企業で頻出するSaaSアカウント管理のリスクを題材に示します。影響度・発生頻度とも5段階、リスクレベルは高（15以上）・中（8〜14）・低（7以下）の区分です。

このように、同じ「SaaSに関するリスク」でも、扱う情報の機密性と管理状態によってリスクレベルと対応は変わります。評価表には評価日・評価者・リスク所有者の欄を設け、次回アセスメントで見直せる形式にしておきます。

リスク対応の4つの選択肢｜リスク低減・リスク保有・リスク回避・リスク共有（移転）

リスクアセスメントで優先順位が決まったら、ISO/IEC 27001の6.1.3「情報セキュリティリスク対応」に基づき、リスクごとに対応の選択肢を決定します。選択肢は低減・保有・回避・共有（移転）の4つに整理でき、排他ではなく組み合わせも可能です。例えば、管理策で発生頻度を下げつつ（低減）、残る影響をサイバー保険で分配する（共有）判断は実務で一般的です。

なお、JIS Q 27001をはじめとする現行規格の用語では「リスク共有」が使われており、従来「リスク移転」と呼ばれてきた対応に相当します。社内文書の用語もリスク共有に揃えておくと、審査時の混乱を避けられます。

リスク低減｜管理策の追加でリスクレベルを下げる

リスク低減は、管理策（コントロール）の導入・強化によって、影響度または発生頻度を下げる対応です。アクセス制御の強化、暗号化、バックアップ、教育訓練などが典型で、実務で「リスクコントロール」と呼ばれる活動の多くは、この低減のための管理策の導入・運用を指します。

低減を選ぶ場合は、導入する管理策をAnnex Aの93管理策と対応づけ、適用宣言書（SoA）に反映します。管理策の導入・運用にはコストがかかるため、想定されるリスクの損失規模と対策費用のバランスで判断します。あらゆるリスクに低減を選ぶと投資が分散し、重要なリスクへの対策が薄まる点に注意が必要です。

管理策はJ-SOXにおけるIT統制とも重なる領域が多く、内部統制と一体で設計すると重複投資を避けられます。全体像はIT内部統制とはで解説しています。

リスク保有｜受容基準の範囲内でリスクを受け入れる

リスク保有は、追加の管理策を導入せず、リスクを認識したうえで受け入れる対応です。リスクレベルが受容基準内にある場合や、対応コストが想定損失を明らかに上回る場合に選択します。

保有と「放置」の違いは、意思決定と記録の有無です。リスク所有者が受容基準に照らして判断し、承認の記録を残して初めて保有と呼べます。承認記録のないリスクは審査で「未対応のリスク」と扱われるため、保有を選んだリスクこそ文書化を徹底します。

保有したリスクも消えるわけではないため、発生頻度や影響度が変わっていないかを定期アセスメントで再評価します。状況が変われば、低減や共有への切り替えを検討します。

リスク回避｜リスク源となる活動や資産をなくす

リスク回避は、リスクを生じさせる活動・資産・プロセスそのものを取りやめる対応です。利用目的の薄い個人情報項目の収集停止、セキュリティ水準を確認できない無料SaaSの利用禁止、老朽化した公開サーバの廃止などが該当します。

回避はリスクを根本から断てる一方、その活動が生んでいた事業価値も失われます。売上や業務効率への影響とリスクの大きさを比較し、代替手段の有無まで含めて経営層が判断します。管理策を尽くしてもリスクレベルが受容基準まで下がらない場合の最終手段と位置づけるのが実務的です。

リスク共有（移転）｜保険や委託でリスクを第三者と分配する

リスク共有（移転）は、保険や外部委託によって、リスクの一部を第三者と分配する対応です。サイバー保険による金銭的損失の補填、データセンター・クラウドサービスへの運用委託、セキュリティ監視（SOC）の外部委託などが該当します。

注意すべきは、共有できるのは金銭的な損失や運用の負荷であって、説明責任までは移転できない点です。クラウドサービスに運用を委託しても、自社データの管理責任は自社に残ります。委託先の管理はAnnex Aのサプライヤ関係の管理策（A.5.19〜A.5.22）の対象であり、共有を選んだリスクには委託先評価をセットで組み込みます。

保険による共有を検討する場合の補償範囲や選定基準はサイバー保険とランサムウェア対策で解説しています。

参考：ISMS適合性評価制度 - ISMS-AC

ISO/IEC 27001:2022 Annex Aの管理策との連動

リスクアセスメント結果は、ISO/IEC 27001:2022 Annex Aの93個の管理策と紐づけて、適用宣言書（SoA）にまとめます。リスクと管理策の対応関係を文書化することで、リスクベースの管理体制であることを審査で証明できます。

2022年版では、管理策が4テーマ（組織的・人的・物理的・技術的）に再編され、新規追加された管理策（脅威インテリジェンス、クラウドサービス利用、ICT準備態勢など）も含まれます。管理策全体の実装手順はISO27001のIT管理で解説しています。

組織的管理策（37項目）

ポリシー、役割と責任、職務分離、サプライヤ関係、インシデント管理、事業継続などの管理策が含まれます。中堅企業では、特に「A.5.19 サプライヤ関係における情報セキュリティ」「A.5.23 クラウドサービス利用」が重要度を増しています。

リスクアセスメントで「サプライチェーン経由のリスク」「クラウドサービスの脆弱性」が高評価された場合、これら管理策を適用する必要があります。管理策の起点となるポリシー体系の整備は情報セキュリティポリシーの作り方を参照してください。

人的管理策（8項目）

雇用前審査、雇用条件、教育訓練、懲戒手続き、機密保持契約などの管理策です。リモートワーク拡大に伴い「A.6.7 リモートワーク」が整理・強化されており、自宅・カフェなどの作業環境のリスク評価が重要視されています。

物理的管理策（14項目）

入退室管理、装置の保護、ケーブル配線などの管理策です。中堅企業では、データセンタやサーバルームを保有しないケースも多く、「A.7.10 ストレージメディア」「A.7.13 装置の保守」が現実的な対象になります。

技術的管理策（34項目）

アクセス制御、暗号化、システム取得・開発・保守、通信セキュリティなどの管理策です。2022年版で追加・整理された「A.8.9 構成管理」「A.8.16 監視活動」「A.8.23 ウェブフィルタリング」「A.8.1 ユーザエンドポイント装置」などは、現代的なリスクに対応するため重要度が高い管理策です。

参考：ISO/IEC 27001:2022 移行情報 - ISMS-AC

中堅企業がアセスメントで陥りやすい5つの罠と回避策

リスクアセスメントを形式作業で終わらせず、実務で機能させるには、よくある罠を事前に把握することが有効です。

中堅企業特有のリソース制約・組織構造を踏まえた回避策を組み込むことで、継続運用に耐える設計にできます。

罠1：情報資産の粒度が粗すぎる・細かすぎる

業務単位で500件以下を目安に、価値・脅威・脆弱性が共通する資産はグルーピングします。1万件の資産台帳は評価しきれません。

罠2：評価者によってリスクレベルがばらつく

評価基準書を策定し、複数評価者で同じ資産を評価する「評価キャリブレーション」を実施します。基準の解釈を揃えてから本評価に入ります。

罠3：リスク対応が「低減」一辺倒になる

低減・保有・回避・共有（移転）の4選択肢を意識的に検討します。サイバー保険による共有、業務プロセス変更による回避など、低減以外の選択肢が経営的に最適なケースもあります。

罠4：残留リスクの承認が形式化する

経営層への報告では、リスク総数だけでなく、上位リスクの内容と影響を具体的に説明します。残留リスクの承認は経営判断であり、判断材料を提供する責任があります。

罠5：年1回の形式作業で陳腐化する

定期アセスメント（年1回）に加え、組織変更・新システム導入・重大インシデント発生時に臨時アセスメントを実施します。SaaS追加時の都度評価を仕組み化することで、シャドーITリスクも統制下に置けます。

用語集｜リスクアセスメントで押さえる15語

ISMS実務で頻出する用語を整理します。文書間で用語が統一されていないと、審査で指摘を受けるリスクがあります。

組織内で用語の解釈を揃え、ポリシー・対策基準・実施手順で一貫した使い方をします。

• ISMS：情報セキュリティマネジメントシステム。ISO/IEC 27001で要件が定義される
• 情報資産：組織が保有する情報・システム・人・施設など、価値を持つ資源全般
• リスク：脅威が脆弱性を悪用して情報資産に損害を与える可能性とその影響度
• 脅威：情報資産に損害を与える可能性のある事象。マルウェア、内部不正、災害など
• 脆弱性：脅威に悪用される可能性のある弱点。パッチ未適用、教育不足など
• リスクレベル：影響度×発生頻度で算出されるリスクの大きさを示す指標
• リスク対応：特定されたリスクに対する低減・保有・回避・共有（移転）の4つの選択肢
• リスク所有者：リスクを運用管理する責任と権限を持つ人。リスク対応と残留リスク受容の承認者
• リスク受容基準：組織として受け入れられるリスクの水準を定めた基準。リスク基準の一部として確立する
• リスク保有：追加の管理策を導入せず、承認のうえでリスクを受け入れる対応。承認記録が必須
• リスク共有（移転）：保険や委託により、リスクの一部を第三者と分配する対応。説明責任は移転できない
• リスクコントロール：リスクを低減するための管理策とその運用。Annex Aの管理策が代表例
• 残留リスク：リスク対応後に残るリスク。経営層の承認が必要
• 適用宣言書（SoA）：ISO/IEC 27001 Annex Aの管理策のうち、適用する管理策を明示した文書
• 内部監査：ISMSが計画通り運用されているか組織内部で確認する活動

ジョーシスでアセスメント結果を運用に反映する

リスクアセスメントで特定された管理策を、日常運用に落とし込むには、IT資産・SaaS・ID・アクセス権の継続的な可視化が出発点です。ジョーシスのプラットフォームは、SaaS台帳・IDライフサイクル・アクセスレビュー周辺の証跡取得を自動化し、ISMS運用を支援します。なお、教育・委託先管理・物理セキュリティなどは別途組織的に対応が必要です。

中堅企業の情シスでは、限られた人員でISMS要件を満たし続ける必要があり、手作業での台帳更新・点検では運用が破綻します。ツールによる自動化が現実解です。

情報資産棚卸しの自動化

ジョーシスは350以上のSaaSと連携し、組織内で利用されているサービス・ライセンス・ユーザを継続的に可視化します。情報資産棚卸しの主要部分が自動化され、Excel手動更新からの解放を実現します。

シャドーITの早期発見、未使用ライセンスの特定、アクセス権の網羅性確認まで、ダッシュボードベースで運用できます。

管理策の継続的な実施と監査証跡

ISO/IEC 27001:2022のAnnex Aから「A.5.15 アクセス制御」「A.5.16 アイデンティティ管理」「A.5.18 アクセス権」「A.8.16 監視活動」など、IT管理に関わる管理策をジョーシス上で自動運用できます。

退職者アカウント自動停止、特権アカウント監視、アクセス権定期レビュー、操作ログ保全など、内部監査・外部審査で求められる証跡を自動取得できます。実際の導入企業では、IT工数を最大50%、ITコストを最大75%削減した事例があります。アクセス権定期レビューの具体的な進め方はアクセス権レビューとはで解説しています。

リスク評価の更新運用

新規SaaS導入時の自動検知、利用状況変化のアラート、アクセス権過剰付与の検出など、リスク評価のトリガーとなる変化をリアルタイムで把握できます。年1回の形式作業ではなく、継続的なリスク管理体制を実現します。

ジョーシスは国内外1,000社以上に導入され、SaaS管理・IDガバナンス・IT資産管理を統合的に担うプラットフォームとして、中堅企業のISMS運用を支えています。‍

無料デモで自社への導入効果を確認する

参考：Josys 公式サイト

よくある質問｜リスクアセスメントの実務疑問

ISMS認証取得・維持に取り組む情シスからよく挙がる質問を整理します。実務判断で迷いやすいポイントを中心にピックアップしました。

Q1：アセスメントの実施頻度はどれくらいが適切ですか

定期アセスメントは年1回が標準です。加えて、組織変更、新システム導入、重大インシデント発生、規格・法令改正のタイミングで臨時アセスメントを実施します。継続的にリスクを把握する仕組みを整えることが重要です。

Q2：情報資産はどこまで細かく洗い出すべきですか

500件以下を目安に、業務プロセス単位でグルーピングします。価値・脅威・脆弱性が共通する資産はまとめて評価して問題ありません。粒度が粗すぎても細かすぎても評価が形骸化します。

Q3：評価基準は他社のものを流用してよいですか

業界・規模・業務特性に応じて自社で調整する必要があります。他社事例は出発点として参考にし、影響度の金額基準・発生頻度の根拠などを自社実情に合わせて設定します。

Q4：リスク対応はすべて低減を選ぶべきですか

リスクの性質と経営資源を踏まえ、低減・保有・回避・共有（移転）の4選択肢から最適なものを選びます。サイバー保険による共有、業務プロセス変更による回避、受容基準内での保有など、低減以外の選択肢も検討します。

Q5：適用宣言書（SoA）の更新タイミングは

リスクアセスメント結果や管理策の選択が変更された都度更新します。ISO/IEC 27001:2022への移行時には、Annex Aの93個全管理策に対して適用・除外の判断を再実施し、適用宣言書を全面改訂します。

Q6：リスク共有とリスク移転は同じ意味ですか

実務上はほぼ同じ対応を指します。現行のJIS Q 27001などの規格ではリスク共有が用いられており、保険や委託で「リスクを完全に第三者へ移せるわけではない」という実態を反映した用語です。社内文書ではリスク共有に統一し、旧文書の「リスク移転」は改訂時に読み替えておくと、審査での用語の不一致を避けられます。

まとめ｜継続的なリスク管理体制への移行

セキュリティリスクアセスメントは、ISMSの中核要件であり、組織のセキュリティ水準を継続的に高めるためのプロセスです。情報資産棚卸しから残留リスク承認までの5ステップを丁寧に進めることで、形式作業ではなく実務で機能するアセスメントになります。

あわせて、規格が求めるリスク特定・リスク分析・リスク評価の3つの活動と、低減・保有・回避・共有（移転）の4つのリスク対応を用語レベルで揃えておくと、手順書・評価表・報告書の間で一貫性が生まれ、審査対応もスムーズになります。

中堅企業では、限られた人員でISMS要件を満たすために、SaaS管理・IDガバナンス・IT資産管理を統合したツール基盤の整備が前提条件です。ジョーシスのような統合プラットフォームを活用することで、情報資産棚卸しの自動化、管理策の継続的実施、監査証跡の自動取得が実現でき、IT工数を最大50%削減しながらアセスメント品質を高められます。

まずは自社の情報資産の現状把握から着手し、SaaS利用実態を可視化することをおすすめします。実態が見えれば、リスク評価の精度が上がり、経営層への説明責任も果たせます。