ISO27001附属書Aの技術的管理策（A.8.13〜A.8.19）｜ログ取得は「定期的なレビュー」から「分析」へ

連載「ISMS審査員・監査への道」の第25回です。前回に続いて、技術的管理策（A.8）を読みます。

経済産業省の情報セキュリティ管理基準は、A.8の管理策を8a〜8dの4つに区切っています。ISOの附属書Aそのものの区切りではなく、管理基準の整理です。前回と今回で読んでいるのは、2つ目の「8b 情報資産運用に関する管理」でした。今回はその後半、A.8.13〜A.8.19の7個です。

前半の6個は、2022年版の新規が4つ並ぶ区切りでした。後半の新規は、A.8.16の監視活動の1つだけです。ただ、数が少ないから地味かというと、そうでもありませんでした。ログと監視の組み立てが、2013年版から大きく変わっているからです。

これまでと同じく、附属書Aの管理策の文と、管理基準が挙げる詳細管理策（以下、細目）は分けて書きます。細目はISO/IEC 27002をもとにした実施の手引です。多くは「考慮する」事項として並んでいます。

---

A.8.13〜A.8.19をひとことで言うと——戻す、気づく、絞る

ひとことで言うと、止まったときに戻し、起きたことに気づき、守りを外せるものを絞る7個です。

番号	管理策	ひとことで	2013年版
A.8.13	情報のバックアップ	方針に沿って複製を持ち、定期的に検査する	A.12.3.1
A.8.14	情報処理施設・設備の冗長性	可用性の要求を満たすだけの予備を持つ	A.17.2.1
A.8.15	ログ取得	ログを取得し、保存し、保護し、分析する	A.12.4.1、A.12.4.2、A.12.4.3
A.8.16	監視活動	異常な挙動がないかを見張り、処置する	新規
A.8.17	クロックの同期	組織が決めた時刻源に時計を合わせる	A.12.4.4
A.8.18	特権的なユーティリティプログラムの使用	制御を無効にできる道具を絞る	A.9.4.4
A.8.19	運用システムへのソフトウェアの導入	動いているシステムに入れるものを管理する	A.12.5.1、A.12.6.2

2013年版の9つの管理策が、2022年版では6つに整理されました。そこに新規のA.8.16が加わって7個です。まとまり方が大きいのはA.8.15で、3つが1つになっています。

3つの組に分けて読む

筆者は7個を3つの組に分けて読みました。

組	管理策	何をする組か
止まっても戻す	A.8.13、A.8.14	複製から戻す。予備に切り替えて止めない
起きたことを残し、気づく	A.8.15、A.8.16、A.8.17	記録を残す。異常に気づく。記録どうしをつなぐ
制御を外せるものを絞る	A.8.18、A.8.19	守りを迂回できる道具と、システムに入れるものを管理する

この分け方は筆者の整理です。管理基準が7個をこう説明しているわけではありません。

A.8.13 情報のバックアップ——取ることより「検査する」が文に入っている

A.8.13は、合意されたバックアップの方針に従って、情報、ソフトウェア、システムのバックアップを維持し、定期的に検査する管理策です。目的は、データやシステムを失ったときに回復できるようにすることです。

管理策の文には「取得する」ではなく「維持し、定期的に検査する」とあります。取ってあるだけでは足りず、戻せる状態かを確かめ続けるところまでが管理策だ、と読みました。

細目は、試験の仕方まで書いている

細目は、バックアップの計画で考えることを7つ挙げています。正確な記録と、文書化した復旧手順を作る。範囲と頻度を決める。離れた場所に保管する。物理的に守る。媒体を試験する。必要なら暗号化する。取る前に、うっかり消えたデータがないかを確かめる。

目を引いたのは、媒体の試験の項目です。復旧の試験はテスト用のシステムで行い、原本の媒体に上書きしない、とありました。試験の失敗で本物のデータを壊さないための注意です。ここまで具体的に書いてあるのは、正直少し意外でした。

別の細目では、定期的な試験を復旧手順のテストと組み合わせ、事業継続計画で必要な復旧時間に照らして確かめる、ともあります。戻せるかだけでなく、間に合うかまで見る書き方です。

方針が先、という順番

細目の最初は、バックアップの方針を決めることでした。範囲と頻度は、業務上の要求と、その情報が業務を続けるうえでどれだけ大事かを考えて決めます。例として、目標復旧時点（どの時点までのデータを取り戻せれば業務が続けられるか）が挙がり、ICTの備え（A.5.30）を参照していました。

最後の細目は、保持期間が終わったら、バックアップの媒体にある情報も削除する、というものです。参照先は前回読んだ情報の削除（A.8.10）でした。本番のデータを消しても、複製に残っていれば消したことにならない。消す方針と残す方針が、ここでもつながっています。

クラウドの細目も1つ紹介します。クラウドサービスに付いてくるバックアップを使うなら、組織の要求を満たすかどうか、どう満たすかを特定する、とありました。用意されたものをそのまま使うのではなく、自分の要求と突き合わせる書き方です。

現場から：範囲と頻度は、構築のときの設計で決まった

筆者の現場では、バックアップの範囲や頻度は、システムを構築したときの設計で決まったものに見えます。

これは第16回で書いた、セキュリティの細部は構築の途中で決まっていく、という話と同じ流れです。設計や構築を委託する調達では、細部は委託先の設計の中で詰まっていきます。バックアップの設計もその一部だと考えています。ここは筆者の見方です。

細目と並べると、気づいたことがありました。クラウドの細目の「付いてくるバックアップが要求を満たすかを特定する」は、構築の設計にもそのまま当てはまる問いです。

	設計で決まったバックアップ	細目の問い
決まった時点	構築のとき	業務上の要求と、情報の重要度から決める
決めた物差し	そのときの業務と、委託先の設計	目標復旧時点、必要な復旧時間
その後	運用に引き継がれる	要求を満たし続けているかを確かめる

構築のときに決めること自体は、筋の通ったやり方です。システムの使われ方を一番よく知っている時期に、専門の設計者が決めています。

問われるのは、その後だと考えています。システムは何年も使われ、扱うデータも業務の重みも変わっていきます。構築のときの設計が、いまの業務の要求に照らしてまだ足りているか。それを誰が、いつ確かめるのか。ここは今回、確かめていません。

前回の構成管理でも、あるべき設定は構築のときの設計書に残ることが多い、と書きました。バックアップの設計も同じ場所にあるはずです。設計書が完成とともに役目を終えるのか、運用の物差しとして生き続けるのか。同じ問いが、ここにも出てきました。

A.8.14 情報処理施設・設備の冗長性——二重にする前に、要求を決める

A.8.14は、可用性の要求を満たすのに十分な冗長性をもって、情報処理施設・設備を導入する管理策です。冗長性とは、一部が壊れても動き続けられるように、予備を持っておくことです。

細目の最初は、業務とシステムの可用性の要求を特定することでした。どれだけ止まってよいかが決まって初めて、どれだけ予備を持つかが決まる、という順番です。管理策の文も「十分な」冗長性と書いていて、全部を二重にせよとは書いていません。

細目には、手段の例が並んでいます。回線などの供給者を二者以上と契約する。地理的に離れた2つのデータセンターを使う。電源を二重にする。機器の部品を二重にする、などです。

その中で、手段より大事だと感じた項目が2つありました。

• 予備の側も、主たる側と同じセキュリティの水準を持つこと
• できれば本番の状態で、切り替えが意図どおりに動くかを試すこと

予備は普段使わないので、更新や設定が後回しになりがちです。切り替えたら、守りの甘い予備で業務を続けることになった、では意味がありません。そして予備は、切り替わって初めて役に立ちます。A.8.13のバックアップと同じく、試して初めて意味がある管理策だと読みました。

止めて戻す機会については、第18回で、計画停電や法定点検が実質の訓練になっていると書きました。前述の通り、それで試せる部分と試せない部分があります。A.8.14は構成そのものの話になるため、筆者の現場の話はここまでにします。

A.8.15 ログ取得——動詞が「定期的にレビュー」から「分析」へ

A.8.15は、活動、例外処理、過失、その他の関連する事象を記録したログを、取得し、保存し、保護し、分析する管理策です。

ログとは、システムで起きた活動、例外処理、過失などの事象を記録したものです。細目は、記録する各事象に、利用者ID、システムの動作、日時と内容、機器の識別情報、ネットワークアドレスを含める、としています。目的には、証拠を残すこと、ログ情報の完全性を保つこと、インシデントにつながる事象を見つけること、調査を支えることが並んでいます。

2013年版の3つが1つにまとまった

JNSAのセミナーの解説資料によると、A.8.15は2013年版の3つの管理策をまとめたものです。イベントログの取得、ログ情報の保護、実務管理者・運用担当者の作業ログの3つでした。

並べると、動詞が変わっています。

	2013年版（解説資料の要約）	2022年版 A.8.15
イベントログ	取得、保持、定期的なレビュー	取得、保存、保護、分析
ログ情報の保護	保護
管理者・運用担当者の作業ログ	記録、保護、定期的なレビュー

管理策の文から、「定期的なレビュー」が消え、「分析」が入りました。レビューという言葉は細目に残っています。特権を与えられた利用者のログを、説明責任のために保護し、レビューする、という項目です。

分析の中身は、細目に【ログ分析】という見出しで並んでいます。分析する人に必要な技能、手順、既定の規則で拾う例外、利用者のふだんの挙動との比較、傾向の分析、脅威インテリジェンスの活用などです。決まった間隔で目を通す、という書き方ではありません。異常な活動を特定するために何を使うか、という書き方でした。

残すことより、残したログを守る細目が厚い

細目を読んでいて、残し方よりも守り方に多くの行が割かれていると感じました。

• 特権をもつ利用者を含め、自分の活動のログを削除したり止めたりする権限を持たない
• 記憶媒体の容量を超えたときに、記録が漏れたり、古い記録が上書きされたりしないようにする
• ハッシュ化や、追記しかできないファイルへの記録で、ログを守る
• 不具合の調査でログを業者に送るときは、送る前に、可能ならデータマスキングで個人や機器を識別できないようにする

最初の項目は、管理する人が自分の記録を消せてはいけない、ということです。ログの値打ちは、誰にも書き換えられていないことにあります。

2つ目の容量の項目は、第11回で書いた、ログの保存期間が設定と容量で決まっている話と同じ場所を指しています。

最後の項目は、前回読んだデータマスキング（A.8.11）を参照していました。ログは調べるための材料ですが、それ自体が守るべき情報でもあります。

現場から：ログを開くのは、何かを調べるとき

筆者がログを開くのは、障害や問い合わせを調べるときです。何かが起きて、原因をさかのぼって探すために読みます。何も起きていないときに開いて眺めることは、ほとんどありません。

管理策の目的と並べると、この使い方は「調査を支援する」にそのまま当たります。記録が残っていて、必要なときに引ける。障害の原因を突き止めるとき、これほど頼りになるものはありません。

一方で、目的にはもう1つ、インシデントにつながる事象を見つけること、が入っています。こちらは、起きたことを後から調べる向きではありません。まだ誰も気づいていないことに気づく向きです。

	調べるために読む	気づくために読む
きっかけ	障害や問い合わせが起きたとき	何も起きていないように見えるとき
向き	1件の原因をさかのぼる	多くの記録から、ふだんと違うものを探す
主に担う管理策	A.8.15（調査の支援）	A.8.16（監視活動）

第13回で、問い合わせの履歴は「一件を探す方向」に使われている、と書きました。ログも同じ向きで使われていることになります。

気づく側の仕事は、2022年版では新規のA.8.16に独立しました。筆者の現場でも、気づく向きの仕事は人がログを眺めるのではなく、ツールのアラートが担っています。そのアラートを誰が見ているかは、次の節で書きます。

なお、細目はログを作る目的と、何を記録するかを決め、方針に文書化するよう求めています。筆者の現場で、それがどの文書に書かれているかは確かめていません。

A.8.16 監視活動——異常を見る前に「正常」を決める新規の管理策

A.8.16は、ネットワーク、システム、アプリケーションに異常な挙動がないかを監視し、適切な処置を講じる管理策です。監視の目的は、情報セキュリティインシデントの可能性を評価することにあります。2022年版で新しく入りました。

JNSAの解説資料は、技術的な監視を強化するための新規として紹介していました。脅威インテリジェンス（A.5.7）やICTの備え（A.5.30）と並べて、サイバーセキュリティへの対応を厚くした例にも挙げています。

細目は、範囲を決め、正常の基準を置いてから異常を見る

細目の並びを追うと、監視の組み立て方がそのまま順番になっていました。

順	細目の中身
1	監視の範囲とレベルを、業務と情報セキュリティの要求に従って決める。監視を記録し、保持する
2	何を監視するか（通信、重要な機器へのアクセス、構成ファイル、セキュリティツールのログ、資源の使用状況など）
3	正常な挙動の基準を決め、それに照らして異常を見る（通常時とピーク時の使用率、利用者のふだんのアクセスの時間・場所・頻度）
4	異常の例（計画外の停止、既知の攻撃の特徴、ボトルネックや過負荷、認可されていないアクセスなど）
5	しきい値を決めて警告を出す。誤検出を減らすよう調整する
6	警告に対応する人を訓練する。誤検出を見分けて対処する手順を決める

一番大事だと感じたのは3番目です。異常は、正常が決まっていなければ見つけられません。異常を探す前に、何が「いつもどおり」かを言葉にしておく。監視は、その基準からのずれを拾う仕事だという書き方です。

第13回で、筆者はアラートの件数を毎月見ていて、多いか少ないかは体感で分かる、と書きました。20年見てきた体感は、たいてい当たります。A.8.16の細目は、その体感の中にある「いつもどおり」を、基準として外に出しておくよう求めているのだと読みました。

現場から：アラートを閉じる判断は、委託先にある

筆者の現場で、アラートが上がったときに「これは対応不要」と判断して閉じるのは、委託先です。しきい値の調整も、委託先の側で行われています。

第13回で書いたとおり、アラートの件数は筆者の目にも入ります。ただ、1件ずつを見て、問題か誤検出かを切り分けるのは委託先でした。

これは、第16回で書いた脅威情報の見立てと同じ形です。あのときも、関係があるかの判断は委託先から届いていました。第22回の故障の予兆も、記録は業者の側にありました。専門の判断を外の力で補うのは、筋の通った分担だと考えています。細目にも、警告に対応する要員は訓練を受けさせる、とあります。日々アラートを見ている専門の人が判断するのは、その趣旨に沿っています。

細目と並べると、組織の側に残る仕事と、委託先に渡っている仕事が分かれて見えました。

細目	どちらの側の仕事か（筆者の整理）
監視の範囲とレベルを、業務の要求に従って決める	組織。業務の要求を知っているのは組織
正常な挙動の基準を決める	両方。業務のふだんを知る組織と、技術のふだんを知る委託先
しきい値の調整、誤検出の見分け	委託先（筆者の現場）
異常な事象を関係者に伝える	委託先から組織へ

前述の通り、判断を外に委ねても、結果を受けて動く責任は組織の側に残ります。委託先が閉じたアラートの記録が、組織の側から見える形で戻ってきているか。正常の基準のうち、業務のふだんの部分を組織が伝えているか。ここは今回、確かめていません。

A.8.17 クロックの同期——記録をつなぐための時計合わせ

A.8.17は、組織が使う情報処理システムの時計を、組織が採用した時刻源と同期させる管理策です。目的は、記録された事象を関係付けて分析し、インシデントの調査を支えることでした。

時計合わせがセキュリティの管理策になっているのは、ログのためです。複数のシステムのログを突き合わせて「何が先に起きたか」を追うとき、時計がずれていると順番を取り違えます。A.8.15の細目にも、システム間のログを関係付けられるよう、全てのシステムが同期した時刻源を持つことが重要だ、という参考がありました。

細目で目を引いたのは、対象の広さです。ビル管理システムや入退出のシステムも含めて、組織の基準とする時刻源を決める、とありました。第21回で読んだ物理的な入退の記録も、時刻をそろえる対象に入ります。A.8.15のログ分析の細目にも、入口や出口の物理的な監視の記録を含める項目がありました。

クラウドの細目もあります。クラウドサービスを使うと時計を合わせにくい場合があるので、各サービスの時計を監視し、差を記録する、というものです。合わせられないなら、ずれを知っておく。現実的な書き方だと感じました。時刻源の構成は守りの中身にあたるため、筆者の現場の話は書きません。

A.8.18・A.8.19 制御を外せるものを絞る

最後の2個は、守りを迂回できるものを管理する組です。A.8.18は道具の側、A.8.19はシステムに入れるものの側を扱います。

A.8.18 特権的なユーティリティプログラム——使う期間まで絞る

A.8.18は、システムやアプリケーションによる制御を無効にできるユーティリティプログラムの使用を、制限し、厳しく管理する管理策です。ユーティリティプログラムとは、システムの管理や保守のための補助的なソフトウェアのことです。強力なものは、アクセス制御などの守りを飛び越えて操作できてしまいます。

細目には、使う人を少人数に絞る、使う人を一意に識別する、不要なものは消す、全ての使用をログに残す、などが並びます。その中で、臨時に使うときの認可と、使える期間を絞る項目が目を引きました。例えば、認可されたシステム変更の期間だけ使える、という形です。

第23回で、筆者の現場では管理者の権限がいつも手元にあり、絞られているのは権限ではなく作業だ、と書きました。A.8.18の細目は、道具についても同じ二通りの絞り方があることを示しています。誰が持つかで絞るか、いつ使えるかで絞るか、です。

A.8.19 運用システムへのソフトウェアの導入——2つの流れがまとまった

A.8.19は、運用システムへのソフトウェアの導入を、セキュリティを保って管理するための手順と対策を実施する管理策です。運用システムとは、実際に業務で動いているシステムのことです。

2013年版の2つの管理策がまとまっています。教科書の対応表では、A.12.5.1とA.12.6.2です。細目を読むと、2つの流れが前後に並んでいるのが分かりました。

流れ	細目の主な中身
管理する人が入れる	適切な管理層の認可に基づき、訓練された管理者だけが更新する。十分なテストの後に入れる。構成管理の仕組みで管理する。変える前に戻し方（ロールバック計画）を決める。旧版を保管する。供給者が関わるときは、必要なときだけ認可してアクセスさせ、監視する
利用者が入れる	利用者が入れてよいソフトウェアの種類の規則を決める。許すもの、禁じるものを特定する。特権は役割に基づいて最小限に与える

旧版の保管の細目は、緊急時の備えのためだけではありません。保管しているデータをその版で読む必要がある間も、設定や手順と一緒に残しておく、とありました。システムを更新したら、古いデータが開けなくなった。そういう事態を見越した書き方です。

もう1つ、サポートの細目があります。運用システムのソフトウェアは、供給者がサポートする版に保ち、サポートのないソフトウェアに依存するリスクを考える、というものです。

現場から：A.8.19は、これまでの話の合流点

A.8.19の細目は、この連載で聞いてきた現場の話が何本も合流する場所でした。新しく聞いた話ではないので、対応だけ並べます。

A.8.19の細目	これまでに書いた現場の話
適切な管理層の認可に基づいて導入する	ソフトウェアを入れてよいかは職員が判断し、筆者が導入作業をする（第19回）
パッチは、脆弱性を除くか減らすのに役立つなら適用する	修正の知らせが来ても、すぐには当てず待つ（第24回）
構成管理の仕組みで管理する	構成管理の中身は資産管理ツールの台帳（第24回）
変える前に戻し方を決める	戻し方を書く欄があるかは、作業による／筆者からは分からない（番外編）
供給者が関わるときは監視する	機器のある部屋で保守の委託先の技術者が作業するとき、付き添うのは主に職員（第21回。ソフトウェアの導入に限った話ではない）

1行目は、管理策の文がそのまま当てはまる分担です。認可する人と、手を動かす人が分かれています。第6回で書いた、責任は筆者に、権限は職員に、という形と同じでした。

並べて分かったのは、1つ1つの話が、A.8.19の細目の別々の行に当たることです。導入の判断、適用の時期、構成の記録、戻し方、供給者の監視。それぞれは現場で回っていても、1回のソフトウェアの導入として通して見たとき、全部の行がそろっているか。外から見るなら、その通し方を問うのだろうと考えています。

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

バックアップを取っていることだけで、A.8.13を説明する

管理策の文は「維持し、定期的に検査する」です。戻せるかを試しているか、それが事業継続で必要な時間に間に合うかまで説明を求められることがあると考えています。範囲と頻度を、いつ、何の要求に照らして決めたかも、聞かれやすい点です。

冗長性を、二重にした構成の図だけで説明する

細目の出発点は、可用性の要求の特定です。どれだけ止まってよいかが言えないと、十分な冗長性かどうかを説明しにくくなります。予備の側のセキュリティ水準と、切り替えの試験も見られやすいと思います。

ログを取っていることと、ログで気づけることを混同する

ログが残っていれば、後から調べることはできます。ただ、まだ気づいていない異常を見つけるには、監視の仕組み（A.8.16）が別に要ります。調べるためのログと、気づくための監視を、分けて説明できるかが問われやすいと考えています。

アラートは見ているが、何を「正常」としているかを言えない

A.8.16の細目は、異常を見る前に、正常な挙動の基準を決めるよう求めています。しきい値の調整を委託先に任せている場合も、その基準を組織としてどう把握しているかは聞かれることがあると考えています。

ソフトウェアの導入を、認可の有無だけで説明する

A.8.19の細目には、テスト、構成の記録、戻し方、旧版の保管、サポートの確認まで並んでいます。認可が明確でも、それ以外の行がどこで担われているかを示せると、説明しやすくなります。

まとめ

• A.8.13〜A.8.19の7個は、管理基準の「情報資産運用に関する管理」の後半です。2013年版の9つの管理策が6つに整理され、新規のA.8.16が加わりました
• A.8.13とA.8.14は、どちらも試して初めて意味がある形で書かれています。筆者の現場のバックアップは構築のときの設計で決まっていて、それがいまの業務の要求に足りているかを誰が確かめるかは、確かめていません
• A.8.15の管理策の文は、2013年版の「定期的なレビュー」から「取得、保存、保護、分析」に変わりました。筆者がログを開くのは調べるときで、管理策の目的のうち調査の支援に当たります
• 新規のA.8.16は、細目が、正常な挙動の基準を決めてから異常を見る順に並んでいます。筆者の現場では、アラートを閉じる判断としきい値の調整は委託先にあります。組織の側に残るのは、監視の範囲と、業務のふだんを伝える部分だと考えています
• A.8.17は、ログをつなぐための時計合わせです。A.8.18とA.8.19は、守りを迂回できる道具と、システムに入れるものを絞る2個で、A.8.19にはこの連載の現場の話が何本も合流していました

次回は、管理基準の3つ目の区切り（8c）にあたるA.8.20〜A.8.24を読みます。ネットワークセキュリティ、ネットワークの分離、ウェブフィルタリング、暗号の利用などが並んでいます。

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

参考にした一次資料

• 経済産業省「情報セキュリティ管理基準（令和7年改正版）」 … 管理策基準の8b（8.13〜8.19）の管理策・目的・詳細管理策を読みました。JIS Q 27001:2023、JIS Q 27002:2024をもとにした版です。本文は意見公募時に公開されていた版から読んでいます
• 情報セキュリティマネジメント・セミナー2022 講演資料（JNSA 日本ISMSユーザグループ／2022年12月16日） … 「ISO/IEC 27002 改定の解説」（土屋直子／NTTテクノクロス）で、8.16が新規であることと、8.15が2013年版の12.4.1〜12.4.3をまとめたものであることを確認しました
• 岡田敏靖『ISO27001:2022の規格と審査がしっかりわかる教科書 改訂2版』（技術評論社） … 連載で使っている教科書です。35節（A.8）のうちA.8.13〜A.8.19の説明を読みました。2013年版の番号は、付録の対応表（27002:2022の附属書Bをもとに作成、と注記あり）から引いています

引っかかった点

教科書のA.8.15の説明は、イベントログを取得し、定期的にレビューすることを要求している、という書き方でした。管理基準の管理策の文は「取得し、保存し、保護し、分析する」です。JNSAの解説資料で、2013年版のイベントログの管理策が「取得、保持、定期的なレビュー」だったことを確認しました。教科書の説明は、2013年版の書き方を引き継いでいる可能性があると考えています。記事では管理基準の語で書きました。

教科書のA.8.17の説明は、セキュリティ領域内の全ての情報処理システムの時計を「単一の参照時刻源」と同期させる、という書き方でした。管理基準の管理策の文は「組織が採用した時刻源」で、細目には2つの外部の時刻源を同時に使うこともできる、とあります。記事では管理基準の語で書きました。教科書の書き方が2013年版の管理策の文に由来するかどうかは、2013年版の本文を手元で照らせていないため、ここでは判断していません。

教科書のA.8.13の説明では、バックアップの範囲と頻度を決めるときの参照先に、附属書AのA.5.21が挙がっていました。A.5.21はICTサプライチェーンの管理策です。管理基準の同じ細目は、目標復旧時点の例としてA.5.30を参照しています。記事では管理基準の参照先で書きました。

2013年版で、ログの4つの管理策（A.12.4.1〜A.12.4.4）がどういう括りの名前の下にあったかは、手元の資料で確かめられていません。記事では括りの名前を書いていません。