ISO27001附属書Aの組織的管理策（A.5.19〜A.5.30）｜止まったときの段取りは、契約の中にある

連載「ISMS審査員・監査への道」の第18回です。前回は資産の目録からアクセス権まで、組織の中にあるものを数えて渡す10個を読みました。

今回はA.5.19からA.5.30までの12個です。供給者との関係、クラウドサービス、インシデント管理、事業継続。今度は組織の外にいる相手と、何かが止まったときの話が並びます。

経済産業省の情報セキュリティ管理基準は、この12個を「供給者管理」「インシデント管理」「事業継続」の3つのグループに分けています。3つは別の話に見えます。ところが細目を読むと、供給者管理の中にインシデントと事業継続の話があり、インシデント管理の中にも供給者が出てきました。今回もその線を先に示してから、12個を順に見ていきます。

---

A.5.19〜A.5.30をひとことで言うと——外の相手と、止まったときの12個

ひとことで言うと、外の相手に仕事や情報を預けるときの決まりと、何かが起きて止まったときの備えです。前半の5つが供給者、中ほどの5つがインシデント、最後の2つが事業継続にあたります。

番号	管理策	ひとことで	2013年版
A.5.19	供給者関係における情報セキュリティ	供給者を使うときのリスクを扱う手順を決める	A.15.1.1
A.5.20	供給者との合意における情報セキュリティの取扱い	要求事項を供給者と合意し、文書にする	A.15.1.2
A.5.21	ICTサプライチェーンにおける情報セキュリティの管理	供給者のその先まで目を届かせる	A.15.1.3
A.5.22	供給者のサービス提供の監視、レビュー及び変更管理	合意どおりか見に行き、変更を管理する	A.15.2.1、A.15.2.2
A.5.23	クラウドサービスの利用における情報セキュリティ	クラウドの選定から利用終了までの手順を決める	新規
A.5.24	情報セキュリティインシデント管理の計画策定及び準備	起きる前に、役割と手順を決めておく	A.16.1.1
A.5.25	情報セキュリティ事象の評価及び決定	起きたことがインシデントかを判定する	A.16.1.4
A.5.26	情報セキュリティインシデントへの対応	手順どおりに対応し、終わらせる	A.16.1.5
A.5.27	情報セキュリティインシデントからの学習	起きたことを次の対策に回す	A.16.1.6
A.5.28	証拠の収集	処分や法的な手続きに使える形で証拠を残す	A.16.1.7
A.5.29	事業の中断・阻害時の情報セキュリティ	止まっている間も、守りの水準を保つ	A.17.1.1、A.17.1.2、A.17.1.3
A.5.30	事業継続のためのICTの備え	ICTの備えを計画し、維持し、試験する	新規

管理策の名前は管理基準の表記に合わせています。2013年版の番号は、連載で使っている教科書の付録にある対応表（27002:2022の附属書Bをもとにしたもの）から引きました。A.5.23とA.5.30が新規であることは、JNSA（日本ネットワークセキュリティ協会）のセミナーの講演資料でも確認しています。

2013年版の側から見ると、動きがはっきりしています。供給者関係（A.15）の5つは、すべてここに来ました。インシデント管理（A.16）の7つのうち、ここに来たのは5つです。事象の報告と弱点の報告の2つは、人的管理策のA.6.8へ移っています。事業継続（A.17）の4つのうち、冗長性の1つは技術的管理策のA.8.14へ移りました。

報告が「人」の管理策に移ったのは、面白い動きだと感じます。報告するのは、仕組みではなく人だからでしょう。ここは筆者の受け取り方です。

前回までと同じく、各管理策の細目は管理基準の「詳細管理策」から引いています。27002の手引をもとに組み立てられた部分で、附属書Aの管理策の文そのものではありません。

3つのグループを通る「供給者」という線

結論から言うと、インシデントと事業継続の段取りの一部は、供給者との合意の側に先に書いておく形になっている、と筆者は読んでいます。詳細管理策を横断すると、供給者管理の細目がインシデントと事業継続に触れ、インシデント管理の細目にも供給者が出てくるからです。

グループ	管理策	供給者が出てくる箇所（詳細管理策から）
供給者管理	A.5.19	供給者の製品・サービスに関わるインシデントへの対処。組織と供給者の両方の責任を含める
供給者管理	A.5.20	合意に、インシデント管理の要求事項と手順を入れる。とくに回復中の通知と協力
供給者管理	A.5.22	供給者が、重大な不具合や災害の後もサービスを続けられる計画を持っているか
インシデント管理	A.5.24	インシデント管理の計画に、関係当局や顧客と並んで供給者との調整を入れる
インシデント管理	A.5.26	対応の中で、関係当局や顧客と並んで供給者と調整する

表の上の3行は、平時に決めておくこと。下の2行は、起きたときに動くことにあたります。起きたときに供給者と調整できるかどうかは、平時の合意にそれが書いてあるかで大きく変わります。

事業継続の2つ（A.5.29・A.5.30）の細目には、供給者は直接は出てきません。ただ、表の3行目の項目には、管理基準自身がA.5.29とA.5.30を参照先として付けていました。事業継続の側からではなく、供給者管理の側から線が引かれている形です。

この表は、筆者が詳細管理策から拾って並べたものです。管理基準がこの流れを1つのプロセスとして説明しているわけではありません。

自治体の制度にも、同じ向きのものがあります。総務省の「地方公共団体におけるICT部門の業務継続計画（BCP）策定に関するガイドライン」です。策定の手引きのステップの中に、「外部事業者との契約の見直し」が1つの段として置かれています。業務継続を考えると、契約の話に行き着く。規格の側から読んでも、自治体の制度の側から読んでも、そこは同じでした。

A.5.19 供給者関係／A.5.20 供給者との合意——決める手順と、交わす合意

A.5.19は、供給者の製品やサービスを使うことに伴うリスクを扱うプロセスと手順を決め、実施する管理策です。A.5.20は、供給者との関係の種類に応じて要求事項を決め、供給者ごとに合意する管理策です。

2つの役割の違いは、はっきりしています。A.5.19は組織の中の段取りで、A.5.20は相手との約束です。A.5.19の手順は、クラウドサービスの利用にも当てはめる、と管理基準は書いていました。

A.5.19の参考には、手順に含める内容の例が並んでいます。筆者が目を留めたのは、次の3つです。

• 供給者の種類を特定する。例として、ICTサービス、物流、公益事業、金融サービスが挙がっている
• 供給者の要員とやり取りする、組織の側の要員にも意識向上と訓練を行う
• 関係を終えるときの要求事項を決める。アクセス権の回収、資産の返却、機密保持の継続など

最後の項目は、前回のA.5.11（資産の返却）とA.5.18（アクセス権）を、供給者の側から言い直した形です。人が辞めるときと、契約が終わるときで、やることはほぼ同じだと分かります。

A.5.20で合意に含めることを考える事項は、aからzまで26個ありました。情報の分類の対応付け、インシデントのときの通知と協力、監査する権利、下請負の扱い、契約終了時の引継ぎの支援。量は多いですが、全部を1本の契約書に詰めろという書き方ではありません。「含めることを考慮することが可能」という言い方です。

もう一つ、見落としやすい項目がありました。外部との合意の登録簿を作り、維持する。自分の情報がどこへ渡っているかを追跡するためだ、と書かれています。合意は定期的に見直し、まだ必要か、条項が目的に合っているかを確かめる、とも続きます。

現場から：「供給者の要員」の側から読んでみる

この管理策を読んでいて、筆者は自分の立ち位置に気づきました。筆者は委託を発注する側ではなく、委託を受けて常駐先で実務を担う側です。派遣元の会社が、常駐先に要員やサービスを提供する供給者に位置付けられるなら、筆者は供給者の要員の側に立つことになります。

ただし、規格が「派遣や常駐の技術者は供給者の要員だ」と定めているわけではありません。契約の形や、ISMSの対象をどう定義するかで整理は変わりえます。ここから先は、筆者が自分の立場をA.5.19とA.5.20に当てはめてみた話です。

第4回で、着任時に派遣元から個人情報とセキュリティのチェックリストで確認を受けた、と書きました。常駐先の職員向けのeラーニングを受けることもありました。A.5.20の観点から見ると、教育には派遣元からの経路と常駐先からの経路の2本があるように見えます。それが契約上の要求事項として位置付けられているかまでは、筆者からは確認できません。

第10回では、保守や構築で入る委託先の技術者の力量は、個人を確かめる場面が見えず、信用で受け取っている、と書きました。A.5.20には、供給者のプロセスについて第三者の立証の証拠を求める項目もあります。個人を見る代わりに、会社としての認証や報告書を見る。信用の根拠をどこに置くかを、合意の側で決めておく形です。

供給者の側に立つと、もう一つ見えることがあります。関係を終えるときの項目です。常駐が終わる日には、アクセス権の回収と、預かっていたものの返却があるはずです。筆者はまだその日を迎えていないので、どういう手順で進むのかは、正直なところ分かりません。

A.5.21 ICTサプライチェーン／A.5.22 監視・レビュー及び変更管理——合意の先と、合意の後

A.5.21は、ICT製品とサービスのサプライチェーンに関わるリスクを扱うプロセスと手順を決め、実施する管理策です。A.5.22は、供給者の活動とサービス提供を定常的に監視し、レビューし、評価し、変更を管理します。

A.5.21は、合意の「先」の話です。供給者が、さらに別の会社から部品やサービスを仕入れていることがあります。管理基準の細目には、下請けまで組織の要求事項を伝えるよう求める、製品に使っているソフトウェアの構成要素の情報を求める、といった項目が並びます。部品が本物で、仕様から変えられていないことを確かめる手段として、改ざん防止のラベルや暗号ハッシュ、ディジタル署名も例に挙がっていました。

筆者が現実的だと感じたのは、最後の項目です。供給者が事業をやめる、あるいは技術の進歩で部品を出さなくなる。そうして構成要素が手に入らなくなるリスクを管理し、代わりの供給者を考えておく、という書き方でした。保守の期限が切れる機器の話を、サプライチェーンの言葉で言うとこうなるのだと思います。

A.5.22は、合意の「後」の話です。合意したとおりに提供され続けているかを定常的に監視・レビューし、供給者の側の変更を管理します。一度確かめれば終わり、という書き方ではありません。管理基準は、監視する変更の例をかなり具体的に挙げていました。サービスの強化、新しいシステムの開発、ネットワークの変更、新しい版やリリースの採用、設備の設置場所の変更、下請けの変更などです。

目に留まったのは、細目の終わりのほうにある2つの文です。供給者との関係を管理する責任を、指定された個人かチームに割り当てる。合意の要求事項を満たしているかを監視するために、十分な技術力と人的資源を確保しておく。契約書を交わしただけでは、見に行く人がいないということです。

教科書は、多くの顧客を相手にするサービスでは、約款の変更がWebサイトで知らされるので、最新の約款を入手してレビューする、と説明していました。変更の知らせを、こちらから取りに行く場合もあるということです。

現場から：変更の知らせは、どこに届くか

第12回で書いた通り、調達で入ってきた機器やソフトは、納品後は保守契約で見ています。契約という器があるので、A.5.22の「合意に沿って監視する」の土台は、すでにある形です。

仕様の変更や版上げ、計画停止の知らせは、まず職員に届きます。影響があるかを確かめ、必要な作業をするのは筆者の側です。知らせが職員を経由して、筆者に回ってくる形です。

A.5.22の細目と並べると、さきほどの2つの文が、ちょうど2人に分かれていました。関係を管理する責任を割り当てる、は職員の側。監視のための十分な技術力を確保する、は筆者の側です。第6回で書いた、作業上の責任は筆者に、権限と決定は職員に、という分担と同じ形でした。

ここで一つ気づいたことがあります。供給者の変更を技術面で見ているのは筆者で、その筆者自身も、前述の整理に立てば供給者の要員の側にいます。組織が供給者を見るための技術力を、別の供給者から借りている形になります。

これを歪みだとは考えていません。管理基準は技術力を「確保しておく」と書いていて、組織の中で育てろとまでは書いていないからです（筆者の読みです）。ただ、借りている技術力は、契約が変われば入れ替わります。知らせを受けて何を確かめたかが、担当者の頭の中だけでなく記録に残っているか。A.5.22で効いてくるのは、そこだと考えています。

A.5.23 クラウドサービスの利用——新規。使う側の管理策

A.5.23は、クラウドサービスの調達、利用、管理、利用終了のプロセスを、組織の要求事項に沿って決める管理策です。2022年版で新しく入りました。

2022年の講演資料の説明では、この管理策が扱うのは、組織がクラウドサービスを利用するときの対策です。クラウドサービスの提供は対象外で、ISO/IEC 27017とも整合させている、とありました。つまりA.5.23は、クラウドサービスを提供する側のセキュリティ管理そのものを対象にした管理策ではありません。

提供する側に管理が要らない、という意味でもありません。クラウドの事業者も、自分が別のクラウドサービスを使う場面では利用する側に立ちます。A.5.23の主語は、あくまで「利用する組織」だと筆者は読んでいます。

管理基準の細目で、組織が決めておく事項は10個あります。筆者が重いと感じたのは、次の3つです。

• どの管理策をクラウドの事業者が受け持ち、どれを利用する組織が受け持つか
• 事業者が実施している管理策について、保証を得る方法
• 利用を変えたり、やめたりする方法。いわゆる出口戦略

もう一つ、現実的な一文がありました。クラウドサービスの合意は、多くの場合あらかじめ決まっていて、交渉の余地がない。だからこそ、すべてのクラウドサービスについて合意をレビューする、という書き方です。

A.5.20までの供給者管理は、合意の中身を相手と詰められる前提で読めます。クラウドでは、その前提が崩れます。条項を足せない代わりに、選ぶ段階で確かめ、合わない部分のリスクを組織の側で受け止め、出口を用意しておく。管理基準は、クラウド利用の残留リスクを適切な管理層が特定し、受容する、とまで書いていました。

現場から：作業記録に、クラウドの項目が出てきた

筆者は常駐先で、日々の作業報告を長く書き続けてきました。テーマ別に数えると、クラウドのIDやSaaSに関わる作業は、長い間ほぼゼロでした。それが直近になって、まとまった件数で出てくるようになっています。1人の担当者の記録を数えただけなので、自治体一般の姿だとは言えません。

A.5.23の目で見ると、この変化は「使い始めた」だけでは終わりません。どの管理策を事業者が持ち、どれをこちらが持つか。その線引きが、使い始めた時点で新しく生まれているはずです。今まで自前の機器で持っていた管理策のうち、一部は事業者の側へ移り、一部はこちらに残ります。

その線引きがどの文書に書かれているかは、派遣の立場からは見えていません。ただ、境目を1枚で説明できるかどうかが、この管理策の審査で最初に聞かれそうな点だと筆者は考えています。

A.5.24〜A.5.28 インシデント管理——計画、判定、対応、学習、証拠

インシデント管理の5つは、時間の順に並んでいます。起きる前の準備（A.5.24）、起きたことの判定（A.5.25）、対応（A.5.26）、振り返り（A.5.27）、そして証拠（A.5.28）です。

番号	いつの話か	細目で目に留まったこと
A.5.24	起きる前	インシデント管理の目的に、経営陣が同意している。報告した人に、結果を知らせる手続きを持つ
A.5.25	起きた直後	インシデントに分類する基準を含む体系に合意する。評価と決定の結果を詳しく記録する
A.5.26	対応中	対応を記録する。滞りなく済んだら、正式に終わらせて記録する。根本原因を分析する
A.5.27	終わった後	インシデントの種類、規模、費用を数えて監視する。再発するもの、重大なものを見つけてリスクアセスメントを更新する
A.5.28	全体を通して	懲戒や法的な手続きに使えるよう、証拠を特定・収集・保存する手順を持つ。機器の電源が入っているかどうかまで考える

ここで押さえておきたいのが、情報セキュリティ事象と情報セキュリティインシデントの区別です。A.5.25の管理策の文は、事象を評価し、インシデントに分類するか否かを決定する、という書き方でした。起きたことを全部インシデントとして扱うのではなく、組織の基準に照らして振り分ける。その振り分けを仕組みとして持つのが、A.5.25です。

教科書は、事象の分類例に、誤送付や紛失、不正アクセスと並んで、業務システムの故障やネットワーク障害も入れていました。可用性が損なわれることも、情報セキュリティの話だからです。ただし、どの障害をインシデントとして扱うかは、組織が決める基準しだいです。障害がそのままインシデントになるわけではありません。

現場から：障害報告は、すでにインシデント対応の形をしている

筆者の仕事には、ネットワーク障害の一次対応が入っています。第3回で書いた通り、障害が起きると短い時間で一次報告を上げる決まりがあり、原因、対応、再発防止に加えて、発生から解決までの経過時刻まで記録されます。

A.5.24〜A.5.26の細目と並べると、かなりの部分が重なります。報告の手順があり、対応の経過が記録され、原因を分析し、終わったことが記録に残る。名前はインシデント管理ではなくても、形はすでにそこにあります。

では、障害の対応の途中で「これは情報セキュリティの問題かもしれない」と扱いが切り替わった場面はあるか。振り返ってみると、筆者はそういう場面に当たったことがありません。筆者が一次対応した障害は、機器の故障や回線、設定の問題として片づいてきました。

教科書の分類例に沿えば、筆者が扱ってきた障害は、どれも情報セキュリティ事象の候補でした。そのたびに「インシデントには当たらない」という判定が、名前の付かないまま下されてきた、とも言えます。

当たったことがないのは、運がよかった面もあると思います。ただ、A.5.25の目で見ると、別の読み方もできます。切り替えの基準と経路は、筆者の見てきた範囲では一度も使われていない、ということです。

基準が無い、という意味ではありません。あるとすれば、対策基準や実施手順の側に書かれているはずです。第3回で書いた通り、職員が読むのは基本方針までで、実施手順までは届きにくい構造があります。一度も使っていない基準は、いざというときに誰の頭にも入っていないかもしれません。A.5.24の詳細管理策には、インシデントを扱う要員に、文書化した手順と定期的な訓練を提供する項目があります。使う機会の少ない基準ほど、訓練で思い出す場面が要るのだと筆者は受け取りました。

第16回では、大きな障害のときに筆者が連絡先を把握しているのは、保守の委託先だと書きました。そのときは、関係当局との連絡というより、供給者との連絡として整理するほうが自然だ、というところで止めています。

今回その続きが見つかりました。A.5.24の計画とA.5.26の対応の細目には、調整する相手として「供給者」がはっきり挙がっています。筆者の手元にある連絡先は、インシデント管理の中に居場所がある、ということです。ただ、連絡先があることと、合意に「回復中の通知と協力」が書かれていることは別です。後者を確かめる立場に、筆者はいません。

第14回では、障害報告に書いた再発防止策を見返すのは、次の障害が起きたとき、とも書きました。A.5.27は、インシデントの種類や規模を数えて監視し、再発するものを見つけることを求めています。1件ずつの報告は丁寧でも、束ねて傾向を見る場面があるかどうか。A.5.27が問うのは、そこだと筆者は読んでいます。

A.5.29 事業の中断・阻害時／A.5.30 事業継続のためのICTの備え——守りを保つことと、戻せるよう備えること

A.5.29は、事業が止まったり乱れたりしている間も、情報セキュリティを適切な水準に保つ方法を計画する管理策です。A.5.30は、事業継続の目的とICT継続の要求事項に基づいて、ICTの備えを計画し、実施し、維持し、試験します。2022年版で新しく入りました。

2つの違いは、目的の欄を並べると分かります。A.5.29の目的は、中断の間に情報と資産を「保護する」こと。A.5.30の目的は、中断の間に情報と資産の「可用性を確実にする」ことです。A.5.30はICTの備えを計画・実施・維持・試験する管理策で、復旧の手順だけを扱うものではありません。そのうえで筆者は、A.5.29は守りの水準を保つ側、A.5.30は決めた時間内にICTを使える状態へ戻せるよう備える側、と整理しています。

A.5.29で筆者がいちばん現実的だと思ったのは、細目の最後の項目です。中断の間に維持できない管理策を、補う管理策を用意しておく。非常時には、いつもの手順が使えないことがあります。そのとき「守らなくてよい」にならないように、代わりの手当てを先に決めておく書き方です。

教科書は、A.5.29は事業継続のマネジメントシステムやBCP（事業継続計画）そのものを作れと求めているのではない、と説明していました。管理基準も、情報セキュリティの要求事項を事業継続マネジメントのプロセスに「含める」という書き方です。BCPを持っている組織なら、その中に情報セキュリティが入っているかが問われます。

A.5.30は、より具体的です。事業影響度分析（BIA）で優先する活動と目標復旧時間（RTO）を決め、それを支えるICTサービスにもRTOを定める。ICT継続計画は、演習とテストで定期的に評価し、経営陣が承認する。講演資料は、災害だけでなくサイバー攻撃などの有事も視野に入れた管理策だと説明していました。

現場から：手順はたぶんある。読んだ記憶がない

第4回で、災害や停電のときの手順は文書になっている可能性が高いが、筆者は読んだ記憶がない、と書きました。存在の有無すら断言できない、という書き方をしています。

前述の通り、自治体にはICT部門の業務継続計画のガイドラインがあります。総務省が最初に作ったのは平成20年度で、令和5年度に時点更新されています。手引きの流れには、情報システムの現状調査、重要なシステムの選定、目標復旧時間の精査、訓練といった段が並んでいます。A.5.30の細目と、かなり近い並びです。

では、止めて戻す訓練はあるのか。筆者の場合、実質の訓練になっているのは、計画停電と法定の点検です。電源が落ちる日に合わせてシステムを順に止め、終われば立ち上げて、動作を確かめる。訓練という名前は付いていませんが、止めて戻す手順は、そのたびに実地で試されています。

A.5.30の目で見ると、これは演習とテストにかなり近いものです。しかも机上ではなく、本当に止まります。

一方で、この形では試されない部分もあります。計画停電は日時が前もって決まっていて、全員が準備してから止める形です。予告なしに止まったときの初動や、バックアップからデータを戻す手順は、ここでは出番がありません。A.5.29の「止まっている間も守りの水準を保つ」も、止まる時間が短く人がそろっている計画停電では、問われにくい部分です。

もう一つ、点検の日程を決めるのは、庁舎の設備を管理する側だと思います（筆者の見方です）。ICTの継続計画から逆算して組んだ試験ではなく、設備の都合でやってくる機会です。これをA.5.30の試験として説明するなら、目標復旧時間と照らして結果を残しておく一手が要りそうです。機会はすでにある。足りないとすれば、それを試験として読むための記録のほうだと考えています。

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

契約書に書いたことを、誰も見に行かない

A.5.20で合意を丁寧に作っても、A.5.22の監視が回っていなければ、合意は紙に残るだけです。管理基準は、関係を管理する責任を個人かチームに割り当て、見に行くための技術力も確保する、としていました。担当が決まっていないと、報告書が届いても読まれないまま積まれます。

クラウドの約款を「交渉できないから」で読まない

合意の条項を足せないことと、合意を読まなくてよいことは別です。A.5.23は、交渉の余地がないからこそ、すべてのクラウドサービスについて合意をレビューする、という書き方でした。どの管理策が事業者側に移ったかを説明できないと、残りを誰が持つのかも決まりません。

障害とインシデントの境目が、人によって違う

A.5.25は、事象をインシデントに分類する基準に合意し、その判定の結果を記録するよう求めています。基準が文書になく、担当者の頭の中にあるだけなら、同じ出来事でも報告の経路が人によって変わりかねません。文書にあっても、一度も使われていない基準は、いざというときに思い出されないおそれがあります。

BCPはあるが、情報セキュリティが入っていない

BCPが「どう復旧するか」だけを書いていると、A.5.29の「中断の間も守りの水準を保つ」が抜けます。非常時に手順を省略する場面が想定されているなら、その間の補う手当てまで書いてあるか。ここは見られやすいと考えています。

まとめ

• A.5.19〜A.5.30は、供給者、インシデント、事業継続の12個です。2013年版のA.15の5つはすべてここに来ました。A.16とA.17からは、報告の2つと冗長性の1つが、それぞれA.6.8とA.8.14へ移っています
• 管理基準は3つのグループに分けていますが、詳細管理策を横断して読むと、インシデントと事業継続の段取りの一部は供給者との合意の側に書かれています（この読み方は筆者の整理です）
• A.5.20は合意を作り、A.5.22は合意の後も継続して監視・レビューし、変更を管理します。見に行く担当と技術力まで求めている点が重いと感じました。技術力を外から借りている場合は、確かめた内容が記録に残っているかが効いてきます
• A.5.23は、クラウドサービスを利用する組織の側の管理策です。提供する側のセキュリティ管理そのものを対象にしたものではありません。交渉できない合意だからこそ、選ぶ段階での確認と、出口の用意が効いてきます
• インシデント管理は、計画・判定・対応・学習・証拠の5つに分かれています。障害がそのままインシデントになるわけではなく、判定の基準は組織が決めます
• A.5.29は中断の間も守りの水準を保つ管理策、A.5.30は事業継続に必要なICTの備えを計画・実施・維持・試験する管理策です。計画停電のような止める機会は、試験として読む記録があれば演習とテストの材料になり得ます。ただし予告なしの停止やデータの戻しは、それでは試されません

次回は組織的管理策の最後、A.5.31〜A.5.37です。法令や契約上の要求事項、知的財産権、記録の保護、プライバシー、独立したレビューなどが並びます。

連載の入口は第1回です。

参考にした一次資料

• 経済産業省「情報セキュリティ管理基準（令和7年改正版）」 … 管理策基準の5d（5.19〜5.23）、5e（5.24〜5.28）、5f（5.29〜5.30）を読みました。各管理策の文・目的・詳細管理策を確認しています。JIS Q 27001:2023、JIS Q 27002:2024をもとにした版です。本文は意見公募時に公開されていた版から読んでいます
• 情報セキュリティマネジメント・セミナー2022 講演資料（JNSA 日本ISMSユーザグループ／2022年12月16日） … 「ISO/IEC 27002改定の解説」（土屋直子／NTTテクノクロス）で、5.23と5.30が新規の管理策であること、5.23がクラウドサービスを利用する側の対策で、提供は対象外・ISO/IEC 27017とも整合と説明されていること（2022年時点の説明）、5.30が災害やサイバー攻撃などの有事を想定していることを確認しました
• 自治体のサイバーセキュリティ対策（総務省） … 「地方公共団体におけるICT部門の業務継続計画（BCP）策定に関するガイドライン」（令和6年3月29日）の表紙と目次を確認しました。平成20年度に作成し、令和5年度に時点更新した旨の記載、手引きのステップに「外部事業者との契約の見直し」があることを確認しています（2026年9月26日確認）
• 岡田敏靖『ISO27001:2022の規格と審査がしっかりわかる教科書 改訂2版』（技術評論社） … 連載で使っている教科書です。32節（A.5）のうち、A.5.19〜A.5.30の説明を読みました。2013年版の番号は、付録の対応表（27002:2022の附属書Bをもとに作成、と注記あり）から引いています

引っかかった点

3つのグループを「供給者」の線がつなぐ、という整理は筆者の読みです。管理基準の詳細管理策から、供給者が出てくる箇所を拾って並べたもので、規格や管理基準がそう説明しているわけではありません。

A.5.19とA.5.21で、教科書と管理基準の書き方が違っていました。教科書は、A.5.19を「要求事項について供給者と合意し、文書化することを要求している」と説明しています。A.5.21も「供給者との合意に要求事項を含めることを要求している」という説明でした。管理基準では、どちらも「プロセス及び手順を定め、実施する」という管理策の文で、合意と文書化はA.5.20の側に書かれていました。記事は管理基準の書き方に合わせています。教科書がなぜこう説明しているのかは、この記事の範囲では確かめられていません。

A.5.23の細目も、読み方が分かれました。教科書は、事業者との合意に含める10個の事項を「クラウドサービスプロバイダが実施する対策」として紹介しています。管理基準では、事業者と利用する組織との「合意が含む規定」として書かれています。講演資料も、A.5.23は利用する側の対策で、クラウドサービスの提供は対象外だと説明していました。記事では、利用する組織が合意の中身として確かめる事項、と読んでいます。

教科書のA.5.30の説明には、非常時に維持できない管理策を「保管するための管理策」という表現がありました。管理基準のA.5.29では「補う管理策」です。文脈からは補う意味だと筆者は読んでいますが、確かめてはいません。管理基準では、既存の管理策の維持と補う管理策はA.5.29の細目に入っていて、教科書はそれをA.5.30の節で説明していました。2つの境目は、解説する側でも揺れやすいところなのかもしれません。