リスクの洗い出しの方法と例（ISMS 6.1.2）｜業務の流れを歩けば、リスクは出てくる

連載「ISMS審査員・監査への道」の番外編です。第7回では、6.1.2のリスクアセスメントを扱いました。規格が求めているのは、シートの様式ではなく手順と物差しだ、という話でした。

あの回で、私は「サンプルを探して来た方には肩透かしかもしれません」と書きました。実は、肩透かしを食っていたのは私自身です。手順は分かった。それなのに、リスクを1行目から書けと言われると手が止まる。今回はその宿題として、洗い出しを例題で最初から最後までやってみます。

---

6.1.2 c) の洗い出しとは —— 作るのは「1行」

6.1.2 c) は、機密性・完全性・可用性が損なわれることに関わるリスクを特定し、あわせてリスク所有者を明確にすることを求めています。このリスクの特定を、現場ではよく「洗い出し」と呼びます。

特定したリスクをどんな形で書くかまでは、規格は決めていません。この記事では、リスクを具体的にするために、1つのリスクを1行に整理する方法を使います。まず、その1行の例を見てください。

資産	脅威（原因）	ぜい弱性	起きること	損なわれるもの
申請者の個人情報が入った通知書	封入作業での人のうっかり	封入を一人で行い、照合する手順がない	別人に届き、内容が漏れる	機密性

文にすると「封入作業でのうっかりが、照合のない一人作業をすり抜け、通知書が別人に届く」となります。この記事でいう洗い出しは、こうした1行を、業務の端から端まで書き並べていく作業です。

点数は、ここではまだ付けません。起こりやすさや影響を見積もるのは、次の6.1.2 d) の分析の仕事です。

1行の部品は5つ

部品	問い	家にたとえると
資産	何を守るのか	家の中の財産
脅威（きょうい）	何が害の原因になるのか	空き巣
ぜい弱性（ぜいじゃくせい）	なぜ原因を防げないのか	鍵をかけ忘れる習慣
起きること	資産に何が起きるのか	財産が盗まれる
損なわれるもの	漏れる（機密性）・誤る（完全性）・止まる（可用性）	使いたいときに無い

この記事では、脅威がぜい弱性に付け込み、資産に何かが起きる、という筋で1行を組み立てます。空き巣の多い地域でも、戸締まりが完璧なら被害は起きにくくなります。鍵をかけ忘れても、空き巣が来なければ何も起きません。

脅威・ぜい弱性・起きることの見分け方

いちばん取り違えやすいのが、この3つです。正直に書くと、私も下書きの段階では「通知書が別人に届く」を脅威の欄に書いていました。今は次の問いで見分けています。

• 自分たちで消せない原因 → 脅威（地震、攻撃者、マルウェア、人がうっかりミスをするという性質）
• 自分たちで直せる弱み → ぜい弱性（手順がない、設定が古い、確かめていない）
• 資産に起きる結果 → 起きること（見られる、誤って登録される、止まる）

マルウェアは脅威で、「定義ファイルの更新を端末任せにしている」がぜい弱性、「感染して業務が止まる」が起きることです。これは規格の定義ではなく、この記事で分類するための簡便な目安です。脅威とぜい弱性の正式な定義は、用語の規格であるJIS Q 27000にあります。

ぜい弱性の欄には、自分たちの組織の事情を書きます。ここが一般論のままだと、後で考える対策も一般論になってしまいます。

リスクの洗い出しの手順 —— 資産から入る6つのステップ

いきなり「リスクを挙げてください」と言われると、頭が真っ白になります。先に業務の流れという地図を描き、その上を順に歩くと、リスクは意外と自然に出てきます。

ステップ	やること	出てくるもの
1	範囲を決める	「この業務だけ」という枠
2	業務の流れを書く	情報が生まれてから消えるまでの段階
3	段階ごとに資産を拾う	紙、データ、PC、システム、人、委託先
4	資産ごとに3つの問いを当てる	起きること（漏れたら？ 誤ったら？ 止まったら？）
5	原因と「なぜ防げないか」を書く	脅威とぜい弱性
6	リスクの持ち主を決める	リスク所有者（6.1.2 c)）

資産・脅威・ぜい弱性から特定していく進め方は、学習に使っている教科書でも望ましい方法として紹介されています。ただ、第7回で書いたとおり、これは方法の一つです。規格の文言が資産から入ることを求めているわけではありません。

リスクの洗い出しの例 —— 架空の「申請の受付業務」を最後まで歩く

ここからは、架空の業務で6つのステップを通しでやります。特定の組織をモデルにしたものではありません。

ステップ1・2 範囲を決めて、流れを書く

範囲は「申請を受け付けてから、結果を通知し、書類を捨てるまで」にします。組織全体を一度にやろうとしないのがコツです。

流れは5つの段階に分けました。受け取る（窓口で紙の申請書）、入力する（業務システムへ）、しまう（紙は書庫、データはサーバ）、知らせる（結果を郵送）、捨てる（保存期間後に廃棄）。裏方として、システムの保守業者がいます。

ステップ3 段階ごとに資産を拾う

段階	出てくる資産
受け取る	申請書（紙）、窓口の職員
入力する	業務用PC、業務システム、入力担当者のID
しまう	書庫の紙、サーバ上のデータ、バックアップ
知らせる	通知書、宛名データ
捨てる	保存期間を過ぎた書類、廃棄業者
裏方	保守業者、保守用の接続経路

資産は情報そのものだけではありません。情報が載っている入れ物、扱う人、預け先も拾います。

ステップ4・5 3つの問いを当てて、原因と「なぜ」を書く

ここが洗い出しの本体です。たとえば「受け取る」段階に、3つの問いを当ててみます。

• 漏れたら？ → 前の人の申請書が次の人に見える。原因は来訪者の目。なぜ防げない？ → 書類の置き場所が決まっていない
• 誤ったら？ → 記入漏れのまま受け付ける。原因は人のうっかり。なぜ防げない？ → 受付時の確認項目がない
• 止まったら？ → 受付ができなくなる。原因は担当者の病気や休暇。なぜ防げない？ → 手順を知っているのが一人だけ

同じように最後まで歩くと、次の14件になりました。

#（段階）	起きること	脅威（原因）	ぜい弱性（なぜ防げないか）	CIA
1（受け取る）	申請書を他の来訪者に見られる	来訪者の目	書類の置き場所が決まっていない	C
2（受け取る）	記入漏れのまま受け付ける	人のうっかり	受付時の確認項目がない	I
3（受け取る）	受付が止まる	担当者の病気・休暇	手順を知っているのが一人だけ	A
4（入力する）	誤ったデータが登録される	人のうっかり	入力後の照合をしていない	I
5（入力する）	異動した職員のIDで誰かがログインする	元の職員や第三者	異動とIDの削除が連動していない	C・I
6（入力する）	PCが感染して情報が抜かれる・止まる	マルウェア付きのメール	訓練や注意喚起の機会がない	C・I・A
7（しまう）	データが暗号化されて使えない	ランサムウェア	バックアップが同じネットワーク上にある	A
8（しまう）	いざというとき戻せない	機器の故障・誤削除	戻す練習をしたことがない	A
9（知らせる）	通知書が別人に届く	封入作業での人のうっかり	封入が一人作業で照合がない	C
10（知らせる）	古い住所に届く	申請者の転居	住所変更の反映手順が決まっていない	C・I
11（捨てる）	廃棄先で書類が流出する	廃棄業者側の事故・不正	廃棄の証明を受け取っていない	C
12（捨てる）	保存期間内の書類がなくなる	人のうっかり	廃棄前の確認手順がない	I・A
13（裏方）	システムに侵入される	外部の攻撃者	保守用の接続が常に開いている	C・I・A
14（裏方）	何が行われたか後から追えない	保守作業での誤操作・不正	作業の記録を確かめていない	I

CIAは、C＝機密性、I＝完全性、A＝可用性です。冒頭で例として見せた1行は、9番にあたります。「人のうっかり」が何度も出てくるのは、同じ脅威でも、付け込まれるぜい弱性が段階ごとに違うからです。

ステップ6 リスクの持ち主を決める

たとえば、業務のやり方に関わる1〜3と9〜12は申請受付業務の責任者、システムに関わる4〜8と13・14はシステムの管理責任者、と振り分けます。

部署名ではなく、判断できる役職で書くのがポイントです。これは規格が書き方を定めているのではなく、実務上の工夫です。部署名だけだと、あとで残ったリスクの承認を誰から得るのかがぼやけます。その承認は6.1.3 f) の話で、第8回で扱いました。

もう1つの入口 —— 出来事から考える

ステップ4は「資産から、起きることへ」の順でした。逆に「起きたら最悪の出来事」から出発する方法もあります。

たとえば「この業務が1週間止まる」を起点にしてみます。システムが止まる（ランサムウェア、故障、停電）。人がいない（病気、感染症の流行）。場所が使えない（災害）。こんなふうに枝分かれしていきます。

リスクマネジメントの手引にあたるISO/IEC 27005は、2022年版でこの2つの入口を並べて示しました。事象から入る方法（イベントベース）と、資産から入る方法（資産ベース）です。どちらか一方でも、両方を組み合わせてもよい、という扱いだと解説されています。

入口	向いていること（筆者の整理）	気をつけること（筆者の整理）
資産から	細かく、漏れなく拾える	行数が増えやすい。組織全体に関わる大きな出来事が埋もれる
出来事から	大きくて怖いものから拾える。経営層に説明しやすい	想像力に頼る。網羅できているかを示しにくい

正直、私は資産からの方がとっつきやすく感じました。業務の流れに沿って歩くので、迷子になりにくいからです。ただ、例題の14件を見返すと、「感染症で担当者がそろって休む」は資産から歩いても出てきませんでした。入口を変えると見える景色が変わる、というのは実感としてあります。

［現場］歩いていくと、委託先の手前で道が途切れる

この例題を、自分の現場に置き換えて歩いてみました。情報部門の技術担当という私の位置から一番見えにくいのは、委託先の内側です。

保守や構築、開発を外に任せている部分は、渡したものと戻ってきたものは見えます。けれど、その間に預けたデータや作業が委託先の中でどう扱われているかは、歩いて確かめられません。例題でいえば、11番の廃棄業者や13・14番の保守業者の先で、地図が途切れるイメージです。

これは緩さではなく、委託という分担の自然な結果だと思っています。中まで見えないからこそ、外に任せられるわけです。

洗い出しで大事なのは、その区間を空白のまま通り過ぎないことだと考えています。一覧に「ここは自分たちでは歩けていない」と印を付けておく。その区間のリスクは、委託先に聞く、契約で確かめるといった別の道具で拾うことになります。附属書Aでいえば、第18回で扱った供給者関係（A.5.19〜A.5.22）の出番です。

［現場］洗い出しに近いことは、作業ごとにすでにやっている

もう一つ気づいたことがあります。機器の更新や設定変更の前に「うまくいかなかったらどう戻すか」を考えるのは、現場では当たり前の作業です。これは、その業務やプロセスに「止まったら？」を当てている洗い出しそのものです。

では、それをどこに書いているのか。私の位置から見える範囲では、作業によって違います。計画書に書かれることもあれば、打ち合わせで確かめて終わることもあるようです。決まった形があるのかどうかは、正直分かりません。

作業ごとに判断するやり方は、現場の動き方としては筋が通っています。ただ、ISMSの洗い出しとして見ると、もう一歩が要ります。作業ごとに散らばった「止まったら？」が一つの一覧に集まらないと、組織として何を抱えているかが見えません。

第12回では、仕様変更の協議を8.2の「重大な変更が提案された場合」の入口として読みました。考えることはすでに行われている。足りないのは、決まった型で書いて、一か所に残す一手なのだと思います。

よくある落とし穴

対策を書いてしまう

「ウイルス対策ソフトを入れる」は対策です。洗い出しの段階では「定義ファイルの更新が端末任せ」のように、いまの弱みを書きます。対策は6.1.3のリスク対応で考えます。

脅威・ぜい弱性・起きることが同じことを言っている

「脅威：情報漏えい／ぜい弱性：情報が漏れる」では、何も書いていないのと同じです。情報漏えいは、起きることの側に入ります。脅威の欄には原因（人のうっかり、攻撃者）を、ぜい弱性の欄には防げない理由を書き分けます。

大きすぎる・小さすぎる

「セキュリティ事故が起きる」では大きすぎて、対策が決まりません。逆に机の引き出し1つまで下りると、一覧が終わりません。対策を1つか2つ思い浮かべられる大きさが目安です。

自分の担当範囲だけを見る

技術担当だけで歩くと、技術のリスクに偏ります。紙や窓口、委託先、人の異動は、別の担当者のほうがよく知っています。前述の通り、見えない区間には印を付けておきます。

最初から完璧を目指す

洗い出しは1回で終わりません。8.2は、あらかじめ定めた間隔のほか、重大な変更が提案されたときや重大な変化が生じたときにも、アセスメントを行うことを求めています。最初は粗くてかまわない、と私は受け取っています。

確かめ問題

問1　次の文を、資産・脅威・ぜい弱性・起きることに分けてください。「会議室のホワイトボードに書いた個人名入りの表が、消し忘れのまま来客に見られる。会議後に消す決まりがない」

問2　ぜい弱性として書くのに適しているのはどれでしょう。①地震が起きる ②サーバラックが床に固定されていない ③耐震工事を行う

問3　「委託先に預けた個人情報が委託先から漏れる」リスクの持ち主は、①委託先の担当者 ②委託している業務の責任者（委託元）のどちらでしょう。

答え：問1は、資産がホワイトボードの表、脅威が来客の目、ぜい弱性が会議後に消す決まりがないこと、起きることが個人名を来客に見られることです。問2は②です。①の地震は消せない原因なので脅威、③は対策にあたります。

問3は、この例なら②の委託元の責任者がリスク所有者になることが考えられます。ただ、規格の上では、委託元か委託先かという立場だけで一律に決まるわけではありません。そのリスクを管理する責任と権限を持つ人を、リスク所有者として決めます。

まとめ

• 6.1.2 c) が求めるのはリスクの特定とリスク所有者。書く形は規格が決めておらず、この記事では資産・脅威・ぜい弱性・起きることを1行に整理した
• 迷ったら、消せない原因が脅威、直せる弱みがぜい弱性、資産に起きる結果が起きること（記事内の目安）
• 業務の流れを段階に分け、資産ごとに「漏れる・誤る・止まる」の3つの問いを当てる
• 入口は資産からと出来事からの2つ。組み合わせると互いの漏れを補える
• 委託先の内側のように歩けない区間は、空白にせず印を付けて別の道具で拾う
• 次回は附属書A.8の続きに戻ります

用語の意味を確認したいときはISMS用語集に戻ってください。

引っかかった点

一番つまずいたのは、脅威と起きることの区別です。下書きでは「通知書が別人に届く」を脅威の欄に書いていて、見直しの段階で指摘を受けました。脅威は原因の側で、届いてしまうのは結果の側です。用語の規格の定義の原文には、まだ自分では当たれていません。

もう一つは、ISO/IEC 27005の2つの入口です。規格本文には当たれておらず、解説記事2本の記述が一致したところまでで書いています。

参考にした資料

• 第7回 ISMSのリスクアセスメント（6.1.2）
• 第8回 ISMSの適用宣言書（6.1.3）
• 第12回 ISO27001の運用（箇条8）
• Secureframe「The ISO 27005 Approach to Information Security Risk Management: 2022 Updates Explained」（2026年10月1日閲覧）
• NordLayer「ISO 27005 standard explained」（2026年10月1日閲覧）
• 『図解即戦力 ISO27001:2022の規格と審査がしっかりわかる教科書 改訂2版』（岡田敏靖 著／技術評論社）