ISMSのリスクアセスメント（6.1.2）｜物差しは結果を見る前に決める

連載「ISMS審査員・監査への道」の第7回です。第6回では、方針と役割を誰が決めるのかを扱いました。今回は箇条6に入ります。方針を決めた組織が、何を守るべきかを見極める工程です。

リスクアセスメントで検索すると、シートのサンプルや記入例がたくさん出てきます。正直、私も最初はそこから入りました。ところが規格の要求を追っていくと、様式そのものを指定する話は出てきません。求められているのは、別のものでした。

---

6.1をひとことで言うと —— 計画と手順の2段構え

6.1は、リスク及び機会に対処する活動を定めた節です。6.1.1と6.1.2はどちらもリスクを扱いますが、見ている高さが違います。

6.1.1は、組織のリスクマネジメントの観点から、ISMS全体としてどのリスクと機会に取り組むかを計画する条項です。6.1.2は、個々のリスクを決まった手順で特定し、分析し、評価する条項になります。

項目	6.1.1 一般	6.1.2 情報セキュリティリスクアセスメント
見ている高さ	ISMS全体で取り組むリスクと機会	個々のリスク
材料	4.1の課題、4.2の要求事項	適用範囲の中の情報資産と、リスク基準
出てくるもの	対処する活動の計画と、有効性の評価方法	評価して優先順位を付けたリスク
次につながる先	ISMSのプロセスへの組込み	6.1.3 リスク対応

順番で言えば、6.1.1で「何に取り組むか」を決め、6.1.2で「個々のリスクをどう測るか」を決めます。個々のリスクにどう手を打つかは、その次の6.1.3の担当です。

6.1.1 一般 —— 取り組むリスクと機会を決める

6.1.1は、ISMSを計画するときに、4.1の課題と4.2の要求事項を考慮してリスクと機会を決めることを求めます。第4回で扱った課題と利害関係者が、ここで材料として使われる形です。

決めたリスクと機会には、対処する活動を計画します。その活動をISMSのプロセスに組み込み、有効性をどう評価するかまで決めておく。決めて終わりではなく、効いたかどうかを確かめる方法までが計画に入ります。

意外と読み飛ばされるのが「機会」という言葉です。リスクが起きてほしくないことなら、機会はこうなっていてほしい状態の側だと理解しています。たとえば異動で引継ぎが崩れるリスクがあるなら、その裏には、異動があっても手順が回る状態という目指す姿があります。同じ事柄を、避けたいものと目指すものの両面から書く発想です。

6.1.2 情報セキュリティリスクアセスメント —— 手順と判断基準を決めて、使う

6.1.2の要求の中心は、リスクそのものではなくプロセスです。リスクアセスメントの手順と判断基準を定め、文書にしておくことが求められます。

細目	求められていること	ひとことで
a)	リスク基準を確立し、維持する。リスク受容基準と、アセスメントを実施するための基準を含む	物差しを先に作る
b)	繰り返し実施しても、一貫性と妥当性のある結果が出るようにする	誰がやっても同じ物差し
c)	適用範囲の中のリスクを特定する。あわせてリスク所有者を明確にする	洗い出しと、持ち主
d)	起こり得る結果と起こりやすさを分析し、リスクレベルを決める	見積もり
e)	リスクレベルをリスク受容基準と比べて対策の要否を判断し、対応の優先順位を付ける	判定と順番

残すのはリスクの一覧だけではありません。どういう手順と物差しで出したのかも、示せる形にしておく必要があります。

シートの列の並びや点数の付け方は、組織が決める部分だと読んでいます。資産の価値・脅威・ぜい弱性を掛け合わせてリスクレベルを出す方法がよく紹介されますが、これも数ある方法の一つです。サンプルを探して来た方には肩透かしかもしれません。ただ、ここは自由度として受け取るほうが得だと思っています。

リスク基準は、結果より先に決める

a)が表の先頭にある意味は大きいと感じています。

結果を見てから「このくらいなら受け入れよう」と決めると、基準が結果に合わせて動きます。b)の一貫性も、物差しが固定されていなければ成り立ちません。担当者が替わって点数の付け方が変われば、リスクが増えたのか物差しが変わったのか、区別がつかなくなります。

リスク所有者は、作業をする人とは限らない

c)では、リスクの持ち主も明確にします。リスク所有者（リスクオーナー）は、そのリスクにどう対応するかを判断する立場の人や組織だと考えると、つかみやすいと思います。次の6.1.3では、対応したあとに残るリスクの承認を、リスク所有者から得る流れになります。

実際に対策の作業をする人と、リスク所有者が一致するとは限りません。むしろ一致しない組織のほうが多いのではないでしょうか。この点は、後半の現場の話でもう一度扱います。

資産台帳から入るのは、よく使われる方法

リスクの特定では、情報資産を洗い出し、その資産を取り巻く脅威とぜい弱性を明らかにする進め方が広く使われています。資産名、管理責任者、保管場所、資産の価値といった項目を並べていく形です。

ただ、これは広く使われている方法であって、要求の文言そのものとは分けて考えたほうがよさそうです。資産から入る以外の特定のしかたをどう扱うかは、一次資料で確かめてから別の回で書きます。

---

［現場］リスクの特定は、協議の場で既に行われている

ここから現場の話です。

筆者が関わっている現場では、現行の構成から変わる仕様について、協議の会議が開かれます。筆者も技術面の立場で出席しています。

協議で話されるのは、変わることで何が起きるかです。今動いているものが止まらないか。切り替えの間に使えなくなる業務はないか。こうした洗い出しは、6.1.2のc)でいう特定にかなり近い作業だと感じています。筆者のような運用側の意見は、d)の「起こり得る結果」を見積もる材料にもなっているはずです。

ただ、規格の言葉で読み直すと、確かめたくなる点が出てきます。

協議でどんな論点が挙がるかは、その案件の中身と、出席した人によって変わります。それ自体は自然なことです。一方でb)は、誰がやっても一貫した結果が出ることを求めていました。判定の物差しが協議の外に文書として定められているのか、筆者の立場からはそこまで見えていません。

見えていないので、無いとは書きません。書けるのは、特定の作業は既に行われていて、それを6.1.2の「プロセス」として示すには物差しの所在が問われる、というところまでです。

［現場］基幹系のリスクには、持ち主が2つある

次にリスク所有者です。

筆者の認識では、基幹系の業務システムで何かあったとき、手を打つかどうかを判断するのは、その業務を所管する課と情報部門の両方です。内部情報系のシステムであれば、情報部門が判断します。

内部情報系は分かりやすい構図です。基幹系が面白いのは、持ち主が2つに分かれている点でしょう。

考えてみると、これは理にかなっています。基幹系のシステムが止まったとき、困るのは窓口で住民対応をしている課です。起こり得る結果の重さを一番知っているのは、業務を持っている側になります。一方で、なぜ止まるのか、どう防ぐのかという技術側の判断は情報部門にあります。結果の重さと、手段の選択が、別々の場所にある形です。

持ち主が2つある場合、その先で問いが1つ生まれます。対応したあとに残るリスクの承認を、どちらが出すのかという問いです。これは次回の6.1.3で扱う範囲なので、ここでは問いを置くだけにします。

審査で問われやすいのは「一覧」より「手順」

ここまでをまとめると、6.1.2で見られるのは、リスクの一覧がどれだけ網羅されているかだけではありません。

審査で確かめられやすいこと	対応する細目
受容基準と、実施の基準が文書になっているか	a)
誰がやっても同じ物差しで判定できるか	b)
リスクごとに所有者が明確になっているか	c)
リスクレベルの出し方を説明できるか	d)
対策の要否と優先順位が、受容基準との比較から出ているか	e)

一覧が立派でも、どう出したかを説明できなければ弱い。逆に一覧が短くても、手順が一貫していれば説明はできます。ここが6.1.2の読みどころだと考えています。

よくある落とし穴／審査で指摘されやすい点

様式から入ってしまう

サンプルのシートを取り寄せて、列を埋めるところから始めるケースです。手は動きますが、基準を決める工程が抜けやすくなります。シートの点数欄はあっても、その点数が何を意味するのかを誰も説明できない、という状態になりがちです。

基準を後から決める

一通り洗い出して点数を付けてから、どこで線を引くかを決める進め方です。結果に合わせて線を引くことになるので、a)の順番と逆になります。

リスク所有者が情報部門に集まる

情報セキュリティの話なので、所有者欄が全部情報部門の名前で埋まる。起こりやすい形だと思います。ただ前述の通り、結果の重さを知っているのは業務を持つ側です。業務側の関与が見えないと、d)の見積もりの妥当性が問われます。

実施するたびに物差しが変わる

前述の通り、担当者が替わるたびに点数の付け方が変わるケースです。人事異動のある組織では特に起こりやすい。物差しが人の頭の中にあって、文書に無いときに起きます。

---

まとめ

• 6.1.1はISMS全体で取り組むリスクと機会を計画し、6.1.2は個々のリスクを手順に沿って特定・分析・評価する
• 6.1.2が求めるのは、リスクの一覧だけでなく、手順と判断基準を決めて文書にしておくこと
• リスク基準は結果より先に決め、誰がやっても一貫した結果になる形にしておく
• リスク所有者は作業する人とは限らない。基幹系では業務側と情報部門に分かれることがある
• 現場の協議は、既にリスクの特定を行っている。規格の言葉で示すには、物差しの所在が問われる
• 次回は6.1.3、リスク対応と適用宣言書を扱います。持ち主が2つあるリスクで、残ったリスクを誰が承認するのかという話の続きになります

用語の意味を確認したいときはISMS用語集に戻ってください。連載の入口は第1回です。

引っかかった点

最初は6.1.1と6.1.2を、別の種類のリスクだと思い込んでいました。6.1.1は仕組みのリスク、6.1.2は情報のリスク、という分け方です。学習に使っている教科書の例を見直すと、6.1.1の側にも具体的なセキュリティの事柄が並んでいました。違うのは種類ではなく見ている高さだ、と読み直しています。

もうひとつは、協議の場の話です。書き始めた時点では「リスクアセスメントをしていない現場」という筋も頭をよぎりました。実際には特定の作業は行われていて、見えていないのは物差しの所在だけでした。見えないことを、無いことにしない。第6回に続いて、ここは自分への戒めです。

資産から入る特定の進め方が、要求なのか方法の一つなのか。版ごとの扱いを含めて、ここはまだ一次資料で確かめきれていません。