ISMSの適用宣言書（6.1.3）｜管理策は附属書Aから選ぶのではない

連載「ISMS審査員・監査への道」の第8回です。第7回では、リスクを測る物差しを先に決める話を扱いました。今回はその続きで、測ったあとに何をするかの条項に入ります。

前回の最後に、問いをひとつ残していました。リスクの持ち主が2つに分かれているとき、残ったリスクを誰が承認するのか。その答えの前提になるのが、今回の6.1.3です。

適用宣言書で検索すると、記載例やサンプルが並びます。正直、私も最初はそこを見に行きました。ところが規格が決めているのは様式ではなく、載せるべき項目のほうでした。

この記事でわかること

• 6.1.3が、選ぶ・決める・突き合わせる・宣言するの順で組まれていること
• 附属書Aが、管理策を選ぶためのリストではなく、漏れを照合するためのリストであること
• 適用宣言書（SoA）に書くことが決まっている4つの項目
• 除外した管理策の理由が、審査でよく読まれる場所になること
• 残留リスクの承認が、対策を作った人からは出せない理由
• 自治体の現場で、対策の一覧と「やる／やらない」がどんな形で残っているか

---

6.1.3をひとことで言うと —— 決めて、突き合わせて、宣言する

6.1.3は、情報セキュリティリスク対応のプロセスを定めた条項です。6.1.2で評価したリスクに、実際に手を打つ工程がここになります。

やることは6つ。並び順そのものに意味があるので、まず全体を置きます。

細目	やること	ひとことで
a)	アセスメントの結果を踏まえ、リスク対応の選択肢を選ぶ	方針を選ぶ
b)	選んだ選択肢を実施するために必要な管理策を決める	手段を決める
c)	決めた管理策を附属書Aと比較し、見落としがないか確かめる	漏れを照合する
d)	適用宣言書を作成する	宣言する
e)	リスク対応計画を策定する	段取りを組む
f)	リスク対応計画と残留リスクについて、リスク所有者の承認を得る	承認をもらう

6.1.3については、リスク対応のプロセスに関する文書化した情報を保持することが求められます。そのうち適用宣言書とリスク対応計画は、作ること自体が要求になっています。

ここで作った計画を実際に動かすのが8.3です。運用段の話は第12回（箇条8）で扱っています。

a) 対応の選択肢を選ぶ —— 「対策する」以外にも道がある

最初に決めるのは、そのリスクにどういう構えで向き合うかです。

リスクへの向き合い方は、広く4つに分けて説明されます。私が学習に使っている教科書でも、この4つで整理されていました。

選択肢	中身	身近な例
低減	管理策を打ち、起こりやすさか影響を下げる	アクセス制限、バックアップ、教育
回避	リスクの元になる活動そのものをやめる	その機能を使わない、預からない
移転（共有）	他者と分け合う	委託、保険
受容（保有）	手を打たず引き受ける	影響が小さい、費用が見合わない

注意したいのは、受容が「何もしなかった」ではない点です。判断した結果として選ぶのが受容で、判断していないものは放置になります。

呼び方は解説によって揺れ、共有や保有とも言います。用語より、対策する以外の道が用意されていることをつかむほうが大事でしょう。

b) 必要な管理策を決める —— 起点はリスクの側

選択肢を選んだら、それを実行するために必要な管理策を決めます。ここで言う管理策は、リスクを扱うための手段です。仕組みで押さえるもの、ルールで押さえるもの、人で押さえるものが含まれます。

起点になるのは自分たちのリスクで、カタログではありません。この順番が、次のc)につながります。

c) 附属書Aと比較する —— 選ぶリストではなく、照合するリスト

ここが6.1.3で一番おもしろい細目だと思っています。

c)が求めているのは、b)で決めた管理策を附属書Aと比較して、必要な管理策が見落とされていないことを確かめる作業です。附属書Aには93の管理策が、4つのテーマに分けて並んでいます。

順番を図にすると、こうなります。

	よくある思い込み	6.1.3の並び
起点	附属書Aの93項目	自分たちのリスク
作業	使えそうなものを選ぶ	必要な管理策を決める
附属書Aの役目	選択肢のカタログ	漏れがないか照合する相手
出てくる答え	93項目のうち何個を採用したか	自分たちに必要な管理策の一式

附属書Aから選ぶ形で進めても、書類自体は埋まります。違うのは埋まり方です。カタログから選ぶと、「なぜこの管理策が必要なのか」の答えがカタログ側にできてしまいます。

審査で問われるのは後者だと読んでいます。管理策の数ではなく、その管理策がどのリスクに紐づいているか。ここは私の理解であって、教科書がこの順序をどう説明しているかまでは照合できていません。

もうひとつ、附属書Aを「93個すべて実施する義務のリスト」と読まないことも大事です。c)が求めているのは比較と検証で、全採用ではありません。採用しないものが出るのは自然で、その扱いを決めるのが次のd)です。

適用宣言書（SoA）に書く4つのこと —— 6.1.3 d)

適用宣言書は、英語のStatement of Applicabilityから、SoA（エスオーエー）とも呼ばれます。自分たちがどの管理策を使うと決めたのかを、外に向かって示す文書です。

書くことは決まっています。

載せるもの	何を示すか
必要と決めた管理策	b)とc)を経て残った一式
それを含めた理由	なぜ必要なのか。リスクとの紐づけ
実施しているかどうか	宣言した時点の状態。計画中なのか、動いているのか
附属書Aの管理策を除外した場合、その理由	なぜ要らないと判断したのか

様式は決まっていません。表計算ソフトの一覧でも、文書の形でも構わないはずです。サンプルを探して来た方には物足りないかもしれませんが、自分たちの管理しやすい形にできる部分でもあります。

除外の理由のほうが、じっくり読まれる

4つのうち、書くのに時間がかかるのは除外の理由です。

含めた理由は、リスクの一覧と突き合わせれば書けます。除外は違います。「必要ない」と言い切る根拠を、こちらから示す必要があるからです。

しかも除外理由は、書きぶりが理解度をそのまま映します。「該当する業務がないため」なら適用範囲と整合しているか、「リスクが小さいため」なら6.1.2の物差しとつながっているかを確かめられる。理由の書き方ひとつで、前の条項までさかのぼれる形になっています。

e) リスク対応計画 —— 「やる」と「いつやる」は別

d)の「実施しているかどうか」と、e)のリスク対応計画は対になっています。

必要だと決めた管理策が、その日から全部動いているとは限りません。予算が要るもの、機器の入替が要るもの、教育の日程が要るもの。時間がかかるほうが普通です。

だからこそ、実施していないものを隠さずに書ける形になっています。まだ動いていない管理策は、いつ誰が何をするのかを計画の側に持たせる。適用宣言書とリスク対応計画は、状態と段取りで役割を分けていると理解しています。

ただし、必要だと決めたのに実施していない管理策には、その分のリスクが残ります。この残ったリスクを引き受けることについては、次のf)でリスク所有者の承認を得る形になります。計画に載せて終わり、ではありません。

f) 残留リスクの承認 —— 作った人の自己申告では足りない

対応しても、リスクがすべて消えるわけではありません。手を打ったあとに残るものを残留リスクと呼びます。

f)は、リスク対応計画と残留リスクの受容について、リスク所有者から承認を得ることを求めています。前回扱ったリスク所有者が、ここで効いてきます。

大事なのは、承認が対策を作った側から出るものではない点です。設計した人が「これで十分です」と言えば自己申告になります。結果を引き受ける立場の人が残ったものを引き受けると言うから、承認に意味が出ます。

ここで、第7回に残した問いへ戻りましょう。リスクの持ち主が業務所管課と情報部門の2つに分かれているとき、残留リスクの承認はどちらが出すのか。次の現場の話で考えます。

---

［現場］リストは持っている。突き合わせた結果が見当たらない

ここから現場の話です。

行政には、情報セキュリティのルールが三層で用意されています。基本方針、対策基準、実施手順の順です。このうち対策基準は、やるべきことを項目立てて並べた文書になります。附属書Aと同じ役割のリストが、認証の取得とは関係なく最初から存在しているわけです。

ところが、そのリストに対して「この項目は実施している、これはしていない」を一枚で見渡せる文書を、私は見た記憶がありません。

見た記憶がないだけで、無いとは書きません。第7回と同じです。派遣という立場で見えている範囲には限りがあり、所管の課が持っている可能性は十分にあります。

それでも、この空白は私にとって収穫でした。適用宣言書が何のための文書なのかが、ここでようやく腑に落ちたからです。

値打ちがあるのは、管理策のリストを持っていることではありません。リストを持っている組織は珍しくない。適用宣言書が示すのは、そのリストに対する答えのほうです。どれを使うと決めたか、どれを外したか、今それは動いているか。この3つが一枚に載っているかどうかで、外から見える情報量がまるで変わります。

［現場］受け入れたのか、先送りになったのか

次は残留リスクです。

私が見ている範囲では、「ここまでやって、残りは受け入れる」という線引きが文書として出てくる場面は多くありません。仕様変更の協議の場で、話の流れの中で決まることがあります。はっきり言葉にならないまま、次の年度に送られるものもある。

これを現場の緩さと読むのは、たぶん間違いです。年度で予算が動く組織では、今年できることと来年に回すことを分けるのは当たり前の作業になります。制度に沿って動いた結果として、そうなっている。

ただ、規格の側から見ると、扱いが変わる部分があります。6.1.3のf)が求めているのは、残ったリスクを引き受けるという承認をリスク所有者から得ることでした。口頭で決まったものは、承認が無いわけではありません。承認の記録が残っていない、という状態です。

前述の通り、受容と放置は判断の有無で分かれます。ただし外から見る人には、両者は記録の有無でしか区別できません。同じ「対策していない」でも、判断して残したものと、話題に上らず流れたものは意味が違う。その違いを外に見せる手段が記録なのだと理解しています。

ここで、第7回に残した問いに答えが出ます。基幹系のリスクは、業務を所管する課と情報部門の2つが持っている。では残留リスクの承認をどちらが出すのか。私の見えている範囲では、線引きが起きる協議の場には、たいてい両方が顔を出しています。判断できる人は揃っている。規格が足しているのは、その場に人を集めることではなく、出た結論を残す形のほうです。

［現場］未実施の対策は、予算の言葉に翻訳される

やると決めたのに先送りになった対策も、消えてなくなるわけではありません。次年度の予算要求の資料に入るか、情報部門が持つ課題の一覧に残ります。

この2つは、役割としてはリスク対応計画にかなり近い。何を、いつ、いくらでやるのかが書かれています。適用宣言書でいう「実施していない」に当たるものが、行き先を持っている形です。

面白いのは、書かれている理由が入れ替わることです。

	予算要求の資料	リスク対応計画・適用宣言書
読む相手	財政部門、意思決定をする側	審査員、自組織の管理層
必要な理由の書き方	機器の更新時期、国や県からの要請、老朽化	どのリスクに対する手当なのか
時期の意味	予算年度で決まる	リスクの大きさと優先順位で決まる

同じ対策でも、通すために必要な理由が違う。予算の場で「更新時期が来たから」と書いたものを適用宣言書の「含めた理由」に転記しても、リスクとの紐づけにはなりません。

逆に言えば、6.1.2で決めた物差しが先にあれば、予算要求のほうにも根拠を渡せるはずです。この向きで使えると気づいたのは、今回の収穫でした。

---

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

附属書Aの93項目を起点にしてしまう

前述の通り、c)は照合の作業です。93項目を先に開いて上から検討すると、採用の理由がリストの側に寄ります。「附属書Aにあったから」は、含めた理由としては弱いでしょう。

除外の理由が全部同じ文言になっている

「該当業務なし」だけが並ぶ形です。作るのは速いのですが、除外の判断を本当にしたのかが伝わりません。ひとつひとつ違う言葉で書けているかは、そのまま理解度として読まれると思っています。

実施していないものを「実施済み」と書く

計画が間に合いそうにないとき、つい起きやすい書き方です。未実施はリスク対応計画があれば説明できます。実態と食い違う宣言のほうが、説明の材料を自分で捨てることになります。

承認が押印だけになる

決裁の形は残るのに、何を受け入れたのかが書かれていないケースです。中身のない承認は、後から見たときに範囲が分かりません。承認した人ではなく、承認した内容のほうが問われます。

除外の理由に「まだ実施していない」と書く

実施の状況と、除外の理由は別の欄です。まだ手が回っていないものは、必要だと決めたうえで未実施と書く場所があります。費用が高いという理由も同じで、除外の根拠にはなりにくい。除外は「自分たちには要らない」と言い切る欄だと考えています。

---

まとめ

• 6.1.3は、選択肢を選び、管理策を決め、附属書Aと照合し、宣言し、計画を立て、承認を得る順で組まれている
• 附属書Aは選ぶためのカタログではなく、漏れを照合するためのリストとして使う
• 適用宣言書に書くのは、必要な管理策・含めた理由・実施の有無・除外の理由の4つ。様式は決まっていない
• 除外した理由は、適用範囲やリスク基準までさかのぼって確かめられる場所になる
• 残留リスクの承認は、対策を作った側ではなくリスク所有者から得る
• 行政は附属書Aと同じ役割のリストを先に持っている。適用宣言書の値打ちは、そのリストに対する答えを一枚で示すほうにある
• 次回は6.2と6.3、情報セキュリティ目的と変更の計画策定を扱います。決めた対策を、どんな目的の形に落とすかという話になります

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

参考にした一次資料

• ISMS適合性評価制度の概要（一般社団法人情報マネジメントシステム認定センター） … 制度の入口。認証基準の版数はこのサイト内の一覧から辿れます
• 地方公共団体における情報セキュリティポリシーに関するガイドライン（総務省 地方行政のデジタル化） … 本文で触れた三層の出どころ。PDFは改定のたびに差し替わるため、この一覧ページから最新版を開いてください

引っかかった点

b)とc)の順序を「カタログから選ぶのではなく、決めてから突き合わせる」と読みました。この読み方は私の理解です。学習に使っている教科書が同じ説明をしているかまでは照合できていません。読み違えていたら、後から直します。

低減・回避・移転・受容の4つも、どこまでが規格本文の言葉なのかを確かめきれていません。教科書にはこの4つが載っていました。ただ、規格の条文がこの4つを列挙しているのか、広く使われる分類が紹介されているのかは、規格本文を手元に持っていないため区別がつきません。記事では分類として書いています。

適用宣言書の「実施の有無」が2022年版で明示されたものなのか、2013年版にもあったのかも未確認です。移行の話は別の回で扱います。

もうひとつ。書き始めた時点では、この回は文書の作り方の話になると思っていました。書いてみると、いちばん引っかかったのは受容と放置の区別のほうでした。判断はされている。残っていないのは記録だけ。第7回の「見えないことを、無いことにしない」に続いて、今回は「決めたことを、決めた形で残す」が自分への宿題になりました。