連載「ISMS審査員・監査への道」第3回
リスク、管理策、是正処置。ISMSの勉強を始めると、見たことのある単語ばかりが並びます。
だから知っているつもりで読み進めて、あとで意味がずれていたと気づきます。正直に書くと、学習を始めて最初に手が止まったのは条文ではなく単語でした。
第1回で規格の構造を、第2回で認証制度を見てきました。第3回は言葉そのものを扱います。この記事は連載のハブとして置き、以降の記事で用語が出てきたらここに戻れるようにする予定です。
第1回：ISO/IEC 27001の全体像｜規格を知らないと、ベンダーとの会議で何も言えなくなる
第2回：ISMS認証制度と審査の仕組み｜審査する側も、別の機関から審査されている
- ISO/IEC 27001の箇条3に、用語の定義が並んでいない理由
- 要求事項は2022年版なのに、用語の親規格は2018年版のままという状態
- 機密性・完全性・可用性、リスク、管理策、適用宣言書の意味と、出てくる条項
- 2013年版と2022年版で並びが入れ替わった箇条10の注意点
- 不適合の区分の呼び方が、認証機関の規則で決まっていること
- 現場の言葉と規格の言葉が噛み合わない、典型的な3つの場面
用語の定義は、27001の中には書かれていない（箇条3）
結論から書きます。ISO/IEC 27001の箇条3は「用語及び定義」という見出しですが、そこに定義がずらりと並んでいるわけではありません。定義はISO/IEC 27000の側にまとめられていて、27001はそれを参照する構成になっています。
なぜ分けるのか。27000ファミリーには27001だけでなく27002や27017など複数の規格があり、それぞれが同じ言葉を使うからです。定義を一か所に置いておけば、どの規格を読んでも言葉の意味が揃います。
27000ファミリーの家族構成と、本文と附属書Aの二階建て構造は第1回で扱いました。ここが曖昧なままだと、用語の置き場所も見えにくくなります。
逆に言うと、27001だけを何度読み返しても、言葉の正確な意味にはたどり着けません。審査員が「規格でいう〇〇は」と前置きするのは、この二段構えがあるからです。
ここで版の話を一つ。日本語版の要求事項はJIS Q 27001:2023で、ISO/IEC 27001:2022と一致する内容です。一方、用語の親規格はJIS Q 27000:2019で、こちらはISO/IEC 27000:2018に対応しています。
つまり、要求事項は新しくなりましたが、用語の土台は2018年版のままという状態です。
規格名の日本語も揃っていません。27001は「情報セキュリティ，サイバーセキュリティ及びプライバシー保護」という新しい呼び方に変わりましたが、27000は「情報技術―セキュリティ技術―」という旧い形のままです。細かい話に見えて、検索するときにはここでつまずきます。
情報セキュリティとは、三つの性質を保つこと
情報セキュリティの定義は、次の3つを維持することとして整理されています。頭文字を取ってCIAと呼ばれます。
| 性質 | ひとことで言うと | 崩れたときに起きること |
|---|---|---|
| 機密性（Confidentiality） | 見せてよい相手にだけ見せる | 情報が漏れる、権限のない人が読める |
| 完全性（Integrity） | 勝手に書き換えられていない | データが改ざんされる、古い版が最新扱いされる |
| 可用性（Availability） | 必要なときに使える | システムが止まる、住民サービスが提供できない |
3つ並べると当たり前に見えます。ただ、実務で軽く扱われがちなのは可用性だと感じています。セキュリティという言葉から連想するのは、たいてい漏えいや改ざんのほうだからです。
止まらないことも守ることのうち、という感覚は意識して持たないと抜け落ちます。
マネジメントシステム側の用語（箇条4〜10）
規格本文で繰り返し出てくる言葉を、出てくる場所とセットで並べます。番号が地図になるので、意味と一緒に覚えたほうが早いです。
| 用語 | ひとことで言うと | 主に出てくる箇所 |
|---|---|---|
| 利害関係者 | ISMSに要求を出す側、影響を受ける側 | 4.2 |
| 適用範囲（スコープ） | どこまでをISMSの対象にするか | 4.3 |
| 方針 | 経営層が示す意図と方向づけ | 5.2 |
| 目的 | 方針を、測れる形に落としたもの | 6.2 |
| 力量 | その役割を果たせる知識と技能 | 7.2 |
| 認識 | 自分の行動が何に影響するか分かっている状態 | 7.3 |
| 文書化した情報 | 規程も記録も、まとめてこう呼ぶ | 7.5 |
| 監視／測定 | 状態を見続けること／値を求めること | 9.1 |
| 内部監査 | 組織が自分で行う、独立した確認 | 9.2 |
| マネジメントレビュー | 経営層がISMSを見直す場 | 9.3 |
| 継続的改善 | ISMSを繰り返し良くしていくこと | 10.1 |
| 不適合／是正処置 | 要求が満たされていない状態／原因を取り除く処置 | 10.2 |
このなかで取り違えが起きやすいのは「文書化した情報」です。規程やマニュアル（これから守るもの）と、記録（起きたことの証拠）が同じ名前で呼ばれます。
まもる
しろ「力量」と「認識」も並べて覚えると分かりやすくなります。できるかどうかが力量、分かっているかどうかが認識です。研修をやりましたという報告だけでは、どちらの証明にもなりません。
番号の並びで、一つ注意しておきたい箇所があります。箇条10は、2022年版では10.1が継続的改善、10.2が不適合及び是正処置です。2013年版はこの逆でした。
学習教材の付録にある新旧の構成比較でも、入れ替わりとして挙げられています。古い解説記事を引き写すと番号がずれるので、審査員を目指す立場では押さえておきたい部分です。
リスクの用語（箇条6.1）
リスクは日常語では「危険」ですが、規格では「目的に対する不確かさの影響」という捉え方をします。良いほうに振れる可能性も含む、という点が日常語と違います。ここが最初のずれです。
| 用語 | ひとことで言うと | 主に出てくる箇所 |
|---|---|---|
| リスクアセスメント | 特定→分析→評価の3工程をまとめた呼び方 | 6.1.2 |
| リスク特定 | 何が起こりうるかを洗い出す | 6.1.2 |
| リスク分析 | 起きやすさと影響の大きさを見積もる | 6.1.2 |
| リスク評価 | 基準と照らして、対応するかどうかを決める | 6.1.2 |
| リスク対応 | 低減・回避・移転・保有から選ぶ | 6.1.3 |
| 管理策 | リスクを変えるための具体的な手段 | 6.1.3、附属書A |
| 適用宣言書（SoA） | どの管理策を使い、なぜ使わないかを示す文書 | 6.1.3 |
| 残留リスク | 対応したあとに残るリスク | 6.1.3 |
| リスク受容 | 残ったリスクを承知のうえで受け入れる決定 | 6.1.3 |
覚えておくと得なのは、リスクアセスメントとリスク対応が別の工程だという点です。日常会話では「リスク評価をやった」の一言で両方を指すことがあります。規格の側では、洗い出して測るところまでがアセスメント、手を打つのが対応です。
もう一つ、2022年版では箇条6.3として「変更の計画策定」が新しく置かれました。2013年版にはなかった条項で、学習教材の付録にある新旧の構成比較でも新設として挙げられています。
仕組みを変えるときも計画的にやりなさい、という要求です。細かい追加ですが、システム更改の多い現場では効いてくる条項だと考えています。
制度と審査の用語
認定機関、認証機関、要員認証機関、サーベイランス。このあたりは第2回で扱ったので、定義だけ置いて詳細はそちらに送ります。
三層の関係と審査の周期は、第2回で図表にして整理しています。用語の意味だけ先に押さえたい方は、この先の表だけでも足ります。
ここでは、第2回で書けなかった「不適合の区分」に戻ります。前回は呼び方に揺れがあるようだと書いて、断定を避けました。今回、認証機関が公開している規則に当たって、少し形が見えてきました。
一般には、指摘は「重大な不適合」「軽微な不適合」「改善の機会」の3つで説明されます。ただ、この3区分が規格そのものに定められている、という理解は正確ではないようです。実際には、認証機関がそれぞれの規則で区分と呼称を定めています。
たとえば日本品質保証機構（JQA）が公開している審査登録規則では、指摘は「改善指摘事項カテゴリーA」と「カテゴリーB」に分かれます。カテゴリーAが重大な不適合事項、カテゴリーBが軽微な不適合事項という対応です。
重大と判断する例としては、マネジメントシステムまたは手順が完全に欠落している場合、まったく機能していない場合が挙げられています。
興味深いのは、この規則の指摘区分に「改善の機会」が出てこないことです。世の中の解説記事には当然のように並んでいる言葉が、機関の規則では別の枠組みになっている。つまり受ける側としては、自分の組織が契約している認証機関の規則を読むのが確実だ、ということになります。
| 用語 | ひとことで言うと |
|---|---|
| 不適合 | 要求事項が満たされていない状態 |
| 修正 | 起きてしまったことへの手当て |
| 是正処置 | 原因を取り除き、再発しないようにする処置（10.2） |
| 改善の機会 | 不適合ではないが、良くする余地があるとして示されるもの |
| サーベイランス（維持審査） | 認証後、年1回以上行われる継続確認 |
混同しやすい言葉のペア
ここまで出てきた言葉のうち、並べて覚えたほうがよいものをまとめます。監査の場で問われるのは、たいていペアの区別です。
| ペア | 違い |
|---|---|
| 修正／是正処置 | 起きたことへの手当て／原因を取り除く処置 |
| 監視／測定 | 状態を見続ける／値を求める |
| 認定／認証 | 審査する機関を認める／組織の仕組みを認める |
| 方針／目的 | 向かう方向／測れる到達点 |
| リスク受容／残留リスク | 受け入れるという決定／受け入れた結果として残っているもの |
| 管理策／対策 | 規格の用語／現場の口語。粒度が合わないことが多い |
このなかで最も実務に効くのは、修正と是正処置の区別だと思います。障害を復旧させたのは修正であって、是正処置ではありません。なぜ起きたのかをたどって手を打ち、そこまで記録して初めて是正処置になります。
現場では、言葉が噛み合わない場面がだいたい決まっている
ここからは、筆者が自治体の情報システム部門で見てきた話です。用語の理解が現場でどう転ぶか、3つ挙げます。
AIの利用が広がるほど、温度差が見える
ここ最近、業務を所管する各課でもAIの利用が始まっています。感じるのは、利便性だけで語られやすいことです。速い、楽になる、というところで会話が終わってしまう。
責めたい話ではありません。むしろ、使う側がリスクを語る言葉を持っていないことのほうが問題だと考えています。共通の語彙がないと、議論は「使う」か「使わせない」かの二択に落ちます。
ほんとうに決めたいのは、どの情報なら入れてよいか、という線引きのはずです。
規格の言葉に置き換えると、この線引きはリスクアセスメント（6.1.2）そのものです。どの情報資産が対象で、何が起こりうるかを洗い出す。そのうえで、使う側が自分の行動の影響を分かっている状態、つまり認識（7.3）を作る。用語がないままでは、この作業に着手できません。
障害報告には、すでに是正処置が書かれている
筆者が関わってきた現場では、システム障害が起きたら短時間のうちに一次報告を上げる決まりがあります。復旧までの経過も、時刻を含めて正確に残します。原因、対応、再発防止まで詳細に書く運用です。
これは規格の言葉に翻訳すると、そのまま「修正」と「是正処置」の記録になります。復旧させた行為が修正、原因をたどって再発防止を打つのが是正処置。そして報告書そのものが、7.5でいう文書化した情報です。
しろISMSの導入というと新しい作業が増える話に聞こえますが、実際には既存の運用に規格の名前を貼り直す作業が相当な割合を占めるはずです。
ただし、ここには注意点があると考えています。障害の報告経路は、たいてい「止まったとき」のために作られています。可用性が崩れた場面ですね。
一方で、誤送信や持ち出しといった機密性側のヒヤリは、同じ様式に乗りにくい。同じ勢いで記録されているかというと、そこは組織によって差が出そうです。監査の目で見るなら、報告様式が三つの性質のうちどれを想定して作られているかを確かめたい部分です。
ポリシーは、基本方針までしか読まれない
自治体の情報セキュリティポリシーは、基本方針・対策基準・実施手順という三層で語られることが多いです。ただ、現場の職員が実際に読むのは、おそらく基本方針の部分までではないかと感じています。
理由は理解の問題だけではないと思っています。そもそも、読みやすい場所に置かれていない。どこにあるか分からない文書は、存在していないのとあまり変わりません。
規格の側では、方針は組織内に伝達され、必要に応じて利害関係者が入手できる状態であることが求められます（5.2）。この二つは別々の号として書き分けられています。庁内に周知したというだけでは、片方に答えたことにしかなりません。
掲示したかどうかではなく、届いているかを問う書き方です。読まれていない方針は、この要求を満たしているとは言いにくいでしょう。
| 自治体の呼び方 | 規格側で対応する言葉 | 関係する箇所 |
|---|---|---|
| 情報セキュリティ基本方針 | 情報セキュリティ方針 | 5.2 |
| 対策基準 | 個別方針、または文書化した情報 | 5.2、7.5 |
| 実施手順 | 手順書（文書化した情報） | 7.5 |
| 職員向けの周知・研修 | 認識、コミュニケーション | 7.3、7.4 |
この対応表は、筆者が学習しながら整理したものです。総務省のガイドラインと規格の用語を厳密に突き合わせたものではないので、そこは要確認としておきます。
用語集を作るときの落とし穴
組織で用語集を作るとき、規格の定義をそのまま並べた一覧を作りがちです。作った側は仕事をした気になりますが、たいてい使われません。読んでも自分の業務と結びつかないからです。
使われる用語集は、規格の言葉と組織の言葉の対応表になっています。「うちで言う障害報告書は、規格でいう是正処置の記録にあたる」という形です。翻訳表として機能して初めて、現場の人が自分の作業の意味を理解できます。
もう一つ。現場の言葉を規格の言葉に置き換えさせようとすると、たいてい失敗します。「対策」を「管理策」と言い換えさせる必要はありません。橋を架ければ十分です。用語の統一を目的にすると、本来の目的だったリスクの議論が止まります。
まとめ
第3回の内容を整理します。
- 27001の箇条3に定義は並んでいない。用語の定義はISO/IEC 27000側にある
- 要求事項はJIS Q 27001:2023（2022年版）だが、用語の親規格はJIS Q 27000:2019（2018年版）のまま
- 情報セキュリティは機密性・完全性・可用性の3つを保つこと。可用性が軽く見られやすい
- リスクは「目的に対する不確かさの影響」。危険という日常語とは範囲が違う
- 不適合の区分の呼び方は、認証機関の規則で定められている。ある機関ではカテゴリーA／Bだった。契約先の規則を読むのが確実
- 修正と是正処置の区別が、実務では最も効く。復旧は修正であって是正処置ではない
- 箇条10は2022年版で10.1が継続的改善、10.2が不適合及び是正処置。2013年版とは並びが逆になっている
- 現場の運用には、規格が求めるものが既に含まれていることが多い。用語集は翻訳表として作る
用語が揃うと、規格の条文が急に読めるようになります。次回からは規格本文に入り、箇条4「組織の状況」を扱う予定です。何を守るのかを決める前に、誰が何を求めているのかを整理する段階の話になります。
この記事で参照した資料
規格の版と名称、審査の指摘区分は、記憶で書かず一次資料に当たっています。
- JIS Q 27001:2023 書誌情報（日本規格協会）——規格名称、2023年9月20日改正、ISO/IEC 27001:2022と一致（IDT）
- JIS Q 27000:2019 書誌情報（同上）——2019年3月20日制定、ISO/IEC 27000:2018に対応
- マネジメントシステム審査登録規則 第20版（日本品質保証機構）——改善指摘事項カテゴリーA／Bの呼称と、重大と判断する事例
- 情報マネジメントシステム認定センター（ISMS-AC）——認定制度の枠組み
規格本文は有償のため、本文中では番号と趣旨の言及にとどめています。用語の正式な定義は、JIS Q 27000をお手元でご確認ください。条項の対応関係は、学習教材として使っている『ISO27001:2022の規格と審査がしっかりわかる教科書』（岡田敏靖 著）と突き合わせています。2013年版との構成の違いは、同書の付録にある新旧の比較で確認しました。
連載「ISMS審査員・監査への道」
- 第1回：ISO/IEC 27001の全体像｜規格を知らないと、ベンダーとの会議で何も言えなくなる
- 第2回：ISMS認証制度と審査の仕組み｜審査する側も、別の機関から審査されている
- 第3回：ISMS用語集（この記事）
- 第4回：組織の状況と利害関係者のニーズ（準備中）
連載の記事はISO27001・ISMSカテゴリにまとめています。