ISO27001附属書Aの組織的管理策（A.5.31〜A.5.37）｜外から来る決まりを、中で守れているか見る

連載「ISMS審査員・監査への道」の第19回です。前回は供給者、クラウド、インシデント、事業継続の12個を読みました。組織の外にいる相手と、何かが止まったときの話でした。

今回はA.5.31からA.5.37までの7個で、組織的管理策の最後になります。法令と契約、知的財産権、記録、プライバシー。そして独立したレビューと、方針の順守、操作手順書が並びます。

経済産業省の情報セキュリティ管理基準は、この7個を「コンプライアンス管理」という1つのグループにまとめています。ただ、7個の目的欄を並べてみると、書いてあることは3つに割れていました。今回もその割れ方を先に示してから、7個を順に見ていきます。

---

A.5.31〜A.5.37をひとことで言うと——外の決まり、守れているかの確認、手順書

ひとことで言うと、組織の外から来る決まりを集めて守ることと、それが守れているかを見ることです。最後の1つだけ、決まりを作業の形に落とした操作手順書が入っています。

番号	管理策	ひとことで	2013年版
A.5.31	法令、規制及び契約上の要求事項	守るべき法令と契約を特定し、文書にし、最新に保つ	A.18.1.1、A.18.1.5
A.5.32	知的財産権	ソフトウェアや著作物の権利を守る手順を実施する	A.18.1.2
A.5.33	記録の保護	記録を消失・改ざん・流出から守る	A.18.1.3
A.5.34	プライバシー及びPIIの保護	個人を特定できる情報の保護の要求事項を特定し、満たす	A.18.1.4
A.5.35	情報セキュリティの独立したレビュー	取組全体を、独立した立場の人が定期的に見直す	A.18.2.1
A.5.36	情報セキュリティのための方針群、規則及び標準の順守	方針や規則が守られているかを定期的に確かめる	A.18.2.2、A.18.2.3
A.5.37	操作手順書	情報処理設備の操作手順を文書にし、使える状態にする	A.12.1.1

2013年版のA.18（順守）にあった8個は、どれも2022年版ではこの範囲のどこかに対応付けられています。新しく入った管理策はありません。A.5.37だけが、2013年版では運用のセキュリティ（A.12）の先頭にあったものです。

A.18.2.3（技術的順守のレビュー）は、教科書の付録の対応表ではA.5.36とA.8.8（技術的ぜい弱性の管理）の両方に出てきます。統合先が2つある、ということになります。脆弱性検査のような技術的な点検の中身は、A.8.8の回で扱う予定です。

A.5.31は、2つをまとめてできた管理策でした。講演資料によると、2013年版の「暗号化機能に対する規制」（A.18.1.5）を吸収したそうです。個別具体的な管理策を取り込み、法令と契約の特定という一般的な形にした、という説明でした。管理基準のA.5.31の細目にも、暗号の輸出入や利用の規制を考慮する項目が残っています。

目的欄で見ると、7個は3つに分かれる

結論から言うと、7個は「外の決まりを守る4個」「守れているかを見る2個」「作業の手順を書く1個」に分かれる、と筆者は読んでいます。管理基準の目的欄の書き出しが、きれいに3種類に割れていたからです。

役割	管理策	目的欄に書かれていること（管理基準から）
外の決まりを守る	A.5.31	法令、規制及び契約上の要求事項の順守
外の決まりを守る	A.5.32	知的財産権に関連する、法令、規制及び契約上の要求事項の順守
外の決まりを守る	A.5.33	記録に関連する、法令、規制及び契約上の要求事項の順守と、社会の期待に応えること
外の決まりを守る	A.5.34	PIIの保護に関連する、法令、規制及び契約上の要求事項の順守
守れているかを見る	A.5.35	取組の継続的な適切性、十分性及び有効性
守れているかを見る	A.5.36	方針、規則及び標準に従って実施し、運用すること
作業の手順を書く	A.5.37	情報処理設備の正確で、セキュリティに配慮した操作

上の4つは、同じ言葉を繰り返しています。A.5.31が総論で、A.5.32〜A.5.34は知的財産、記録、個人情報という特定の分野の各論にあたる形です。

真ん中の2つは、向きが違います。上の4つが外から来る決まりを見ているのに対し、A.5.36は組織が自分で決めた方針や規則を見ています。A.5.35は、それらを含む取組の全体を、対象となる領域から独立した立場で見直す管理策です。

この3つの分け方は、筆者が目的欄を並べて付けたものです。管理基準がこう図示しているわけではありません。

A.5.31 法令、規制及び契約上の要求事項——一覧を作り、最新に保つ

A.5.31は、情報セキュリティに関係する法令、規制、契約上の要求事項を特定し、文書にし、最新に保つ管理策です。要求事項そのものだけでなく、それを満たすための組織の取組も一緒に特定する、という書き方になっています。

管理基準の細目は、外の要求事項を考慮に入れる場面を6つ挙げていました。方針と手順の策定、管理策の設計・実施・変更、情報や関連資産の分類。リスクアセスメントとリスク対応の決定、役割と責任に沿ったプロセスの決定、そして供給者との契約上の要求事項の特定です。つまり、ISMSを作るほぼすべての段で参照される前提になっています。

法令については、次の4つを行う、とされています。

• 組織の情報セキュリティに関係する法令と規制を、漏れなく特定する
• 他国で事業をしている、他国の製品を使う、国境を越えて情報を移す場合は、関係する国の法令も考える
• 特定した法令を定期的に見直し、改正や新しい法令に追いつく
• 要求を満たすためのプロセスと、個々の責任を決めて文書にする

意外と重いのは3つ目です。一覧を作った日から、一覧は古くなり始めます。「特定し、文書化する」で終わらず「最新に保つ」まで書かれているのは、そこを見ているのだと思います。

契約上の要求事項としては、顧客との契約、供給者との契約、保険契約の3つが挙がっていました。供給者との契約は、前回のA.5.20で読んだ合意のことです。

教科書は、法令の一覧表に、改訂年月日や順守すべき具体的な条項まで書いておくことを勧めていました。これは一覧を最新に保つための実務上の工夫で、管理基準の細目がそこまでの書き方を指定しているわけではありません。ただ、改訂日の欄がない一覧は、最新かどうかを外から確かめられません。第11回で書いた「版と改訂日の欄があれば、安定と放置を区別できる」と同じ話です。

自治体の場合、国の法令に加えて、条例や規則という自前の決まりも持っています。情報セキュリティポリシーも、国のガイドラインに沿って組み立てられるのが一般的です。第15回で書いたとおり、筆者の見ている対策基準も、国のガイドラインの例文にほぼ沿った印象でした。外の要求を方針に取り込む最初の一手は、制度の側で先に済んでいる形です。

A.5.32 知的財産権——ソフトの数と、複写しないこと

A.5.32は、知的財産権を守るための手順を実施する管理策です。中心にあるのはソフトウェアの使用許諾、いわゆるライセンスの管理でした。

管理基準の細目は12個あります。筆者が目を留めたのは次の4つです。

• ソフトウェアは、定評のある供給元からだけ取得する
• 使用許諾で認められた最大の利用者数や資源の数（例としてCPUの数）を超えない
• 認可されたソフトウェアと、使用許諾を受けた製品だけが入っているかをレビューする
• 公衆のネットワークや外部から手に入れるソフトウェアと情報の使用条件を守る

2つ目は、数え方が契約ごとに違うのが厄介なところです。利用者の数で数えるものもあれば、CPUの数で数えるものもあります。仮想化やクラウドに移ると、同じソフトでも数え方が変わる場合があるので要注意です。

4つ目は、無償のソフトウェアにも効きます。無償であることと、使用条件がないことは別です。業務での利用を条件付きにしているものもあります。

12個の最後の項目は、少し面白いものでした。著作権法や使用許諾が認める場合を除き、書籍、記事、報告書、そして規格の全部又は一部を複写しない。規格の例として、ISO/IEC規格が名指しされています。思わず手元の教科書を見返しました。なお、この連載で教科書の文章や図をそのまま再現せず、自分の言葉で整理しているのは、筆者自身の執筆上の方針です。

現場から：入れてよいソフトは、誰が決めるか

筆者の現場では、業務用のパソコンに新しいソフトを入れてよいかは職員が判断します。無償のソフトも同じです。筆者に回ってくるのは判断が済んだ後で、導入の作業を受け持ちます。

第6回で書いた、決めるのは職員、手を動かすのは筆者、という分担がここでも同じ形で出てきました。A.5.32から見ると、これは弱い形ではありません。「認可されたソフトウェアだけが入っているか」をレビューするには、まず認可という点がどこかに要ります。判断する人と作業する人が分かれていれば、その点ははっきりしている、と言えそうです。

一方で、筆者の位置から見えないこともあります。職員が判断するとき、使用条件のどこまでを材料にしているかです。業務で使ってよいか、数の上限はあるか。そうした確認がどの段で行われているかは、作業を受け取る側からは分かりません。

入れた後のことも、A.5.32は見ています。認可したものだけが入っているかを、後から確かめるレビューです。入れる前の判断がしっかりしていても、入った後を数え直す段がなければ、この項目は半分しか答えられないことになります。

A.5.33 記録の保護——残すことと、読めること

A.5.33は、記録を消失、破壊、改ざん、認可されていないアクセス、不正な流出から守る管理策です。目的欄には、法令と契約の順守に加えて「コミュニティ又は社会の期待」に応えることも書かれていました。

細目は、記録の一生に沿って並んでいます。

段階	管理基準の細目（要旨）
決める	保存・受け渡し・処分の指針を出す。どの記録をどれだけの期間残すか、保持計画を作る
分ける	記録の種類、保持期間、使ってよい媒体で分類する。分類体系に沿って保護を決める
取り出す	求められた記録を、許される時間と書式で取り出せる保存の仕組みを選ぶ
読める状態を保つ	将来の技術変化で読み出せなくならないよう、保持期間を通して媒体と書式の読み取りを確保する。暗号化した記録なら、鍵とプログラムも残す
捨てる	保持期間が終わり、必要がなくなったら、適切に破棄できるようにする

表の4行目が、この管理策の読みどころだと感じました。残してあることと、開けることは別です。記録を守る対象は、紙やデータそのものだけでなく、それを読むための環境にまで及んでいます。

前述の通り、第11回では、ログをいつまで残すかは機器やシステムの設定と容量で決まっている、と書きました。紙の文書は公文書の保存年限の仕組みに乗ります。1行目の保持計画にあたるものは、少なくとも紙の側では制度が先に持っている形です。

4行目については、第13回の話がつながります。問い合わせの履歴は別の台帳にあり、システムのリプレイスごとに保管されていて、過去を調べるときに実際に使われている、と書きました。リプレイスをまたいで残すとき、前の世代の形式を次の世代で開けるかどうか。A.5.33が見ているのは、まさにそこです。

A.5.34 プライバシー及びPIIの保護——自治体では、法の側が変わった

A.5.34は、適用される法令、規制、契約に従って、プライバシーとPII（ピーアイアイ）の保護の要求事項を特定し、満たす管理策です。PIIは、ざっくり言えば個人を特定できる情報のことです。直接には名前が出てこなくても、ほかの情報と結び付けて個人にたどり着けるものまで含めて考えます。

管理基準の細目は、方針を作って伝える、手順を作って伝える、役割と責任を決める、という流れでした。責任者が要員や委託先に手引を示す、という項目もあります。参考として、プライバシー担当役員のような一人の責任者を置くのが最も達成しやすい、とも書かれていました。

日本でPIIの保護といえば、中心は個人情報保護法です。自治体にとっては、ここで大きな制度の変化がありました。

2021年（令和3年）の法改正で、それまで自治体ごとの個人情報保護条例で決めていたルールが、個人情報保護法の全国共通のルールにまとめられました。自治体への適用は、2023年（令和5年）4月の全面施行からです。個人情報保護委員会は、条例は必要最小限の独自ルールを除き、法の共通ルールのもとで施行される、と説明しています。条例で定めるのは、開示請求の手続や手数料のように法が条例に委ねている事項と、内部の手続のように個人情報保護やデータ流通に直接影響しない事項、という整理です。解釈や運用、監視・監督も、個人情報保護委員会が一元的に担う形になりました。

A.5.31の言葉で言い直すと、特定すべき法令そのものが入れ替わった、ということです。一覧に「個人情報保護条例」とだけ書いてあるなら、いま適用される個人情報保護法と、各自治体の法施行条例などを確かめ直すことになります。旧条例の中身が、そのまま施行条例へ移ったわけではありません。法に統合されてなくなった規定もあれば、条例で定めることが認められる事項として残った規定もあります。定期的に見直していれば、ここで一覧が動いたはずです。

現場から：法の改正は、作業にどう届いたか

では、この改正で筆者の作業は変わったのか。正直に言うと、特に変わりませんでした。設定も、手順も、日々の作業も、目に見える変化はなかったと記憶しています。

これには2通りの読み方があると考えています。1つは、作業に響かない種類の改正だった、という読み方です。今回の改正は、ルールの置き場所と、解釈・監督の担い手を変えるものでした。技術的な安全管理の中身は、もともと情報セキュリティポリシーの側で持っていて、そこが大きく動かなかったのかもしれません。

もう1つは、影響の確認が職員の側で行われ、「作業には影響なし」という結論だけが、そもそも筆者まで降りてくる必要がなかった、という読み方です。どちらなのかは、派遣という立場からは判別できません。

A.5.31から見ると、どちらでも構わないのだと思います。法令の一覧が動くことと、作業が動くことは別です。大事なのは、改正を特定し、それを満たす取組を見直した結果「作業は変えなくてよい」と判断したのなら、その判断をどう行ったかを説明できるかどうか。規格が決まった形の記録を求めているわけではありませんが、説明の手掛かりは記録に残っているのがいちばん確実です。第8回で書いた「受容と放置は、外から見ると記録の有無でしか区別できない」と同じ形です。変わらなかったこと自体は、何も悪くありません。

A.5.35 独立したレビュー／A.5.36 方針群の順守——独立して見るか、自分の責任範囲を見るか

A.5.35は、人、プロセス、技術を含む情報セキュリティの取組の全体を、決めた間隔で、又は大きな変化があったときに、独立した立場でレビューする管理策です。A.5.36は、組織の方針、規則、標準が守られているかを定期的にレビューする管理策です。

似ていますが、見る人が違います。本文の内部監査（9.2）も並べると、違いがはっきりします。

	A.5.35 独立したレビュー	A.5.36 方針群の順守	9.2 内部監査（本文）
誰が見るか	レビューの対象から独立した個人・組織。権限をもつ系統に属さない	管理者と、サービス・製品・情報の管理責任者	客観性と公平性を確保できる監査員
何を見るか	取組の全体。改善の機会や、方針・管理策の変更の必要も評価する	自分の責任範囲で、方針や規則が守られているか	ISMSが要求事項に適合し、有効に実施・維持されているか
いつ	決めた間隔で。大きな変化があったときも	定期的に	あらかじめ定めた間隔で
結果の行き先	発議した管理層。適切ならトップマネジメント	記録に残し、独立したレビューの実施者にも報告する	関連する管理層

A.5.35とA.5.36の列は、管理策の文だけでなく、管理基準の詳細管理策の内容も足して書いています。管理策の文そのものは「独立したレビューを実施する」「順守を定期的にレビューする」というところまでです。

A.5.35の実施者の例として、管理基準は内部監査の担当部署、独立した管理者、レビューを専門にする外部の関係者を挙げていました。教科書も、一般的な方法として監査員による監査（9.2）を挙げています。実施者の独立性やレビューの範囲がA.5.35の条件に合うなら、内部監査がA.5.35の独立したレビューとして位置付けられることもあり得ます。ただし、9.2を実施していれば自動的にA.5.35も満たす、という関係ではありません。9.2は本文の要求事項、A.5.35は附属書Aの管理策で、見る範囲や時機の考え方が同じとは限らないからです。

A.5.35には、定期のレビューに加えて、独立したレビューを検討する場面が5つ挙がっていました。組織に影響する法令が変わったとき、重大なインシデントが起きたとき、新しい事業を始めるときです。新しい製品やサービスを使い始める場合と、管理策や手順を大きく変える場合も入っています。1つ目は、A.5.31で見た法令の見直しとつながっています。

A.5.36の不順守が見つかったときの流れは、原因を特定し、是正の必要を評価し、是正処置をとり、その有効性をレビューする、の4段でした。第14回で読んだ10.2（不適合及び是正処置）と同じ形です。是正が次のレビューまでに終わらなければ、次のレビューで少なくとも進捗を取り上げる、とも書かれていました。

管理基準の細目には、管理者の責任範囲に独立したレビューが行われるときは、A.5.36の結果をその実施者に報告する、ともありました。条件付きではありますが、管理者が自分で見た結果が、A.5.35の材料になり得るということです。2つは別の管理策ですが、組み合わせて運用できる関係にあります。

現場から：自己点検は、どちらに当たるか

第14回で、各課がオンラインのフォームで点検に回答し、情報部門が取りまとめている、と書きました。外部からの点検を機に、動き出したばかりの仕組みです。

A.5.35とA.5.36の表に当てはめると、各課が自分の範囲の実施状況を答える部分は、A.5.36の「管理者が自分の責任範囲を見る」に近い形です。一方、取りまとめる側は、答えを集める部署であって、答えを証拠と照らし合わせる立場とは限りません。第14回では、9.2との差は独立性より手前の「証拠と照らすかどうか」にある、と書きました。A.5.35の側から見ても、同じところに差があります。

外部からの点検は、A.5.35の実施者の例にある「外部の関係者」に近い位置にあります。もっとも、外部であることと独立していることは同じではありません。見る人が対象の権限の系統から離れているかどうかが要点です。そのうえで、筆者はその点検の直接の対応者ではありません。どの範囲を、どう見ているのかは、筆者の位置からは見えていません。

ここで言えるのは、自己点検と外部からの点検が、A.5.36とA.5.35に近い2段の形を取り始めている、というところまでです。2つの間で結果が受け渡されているかどうかは、筆者には確かめられていません。

A.5.37 操作手順書——まれな作業と、引き継ぐ前

A.5.37は、情報処理設備の操作手順を文書にし、それを必要とする要員が使える状態にする管理策です。

管理基準は、手順書を作る場面を4つ挙げていました。ここがいちばん実務に効く部分だと思います。

手順書を作る場面	書いておかないと起きること
多くの人が同じ活動をする	人によってやり方がばらつく
まれにしか行わず、次に行うときに手順を忘れている可能性が高い	前回の担当者の記憶に頼る
新しい活動で、正しく行わないとリスクが生じる	初回の誤りがそのまま事故になる
新しい要員に活動を引き継ぐ前	引き継いだ人が、理由の分からない作業を続ける

右の列は、筆者が付けた言い換えです。管理基準に書いてあるのは左の列だけです。

手順書に明記する事項は12個ありました。責任者、導入と構成、情報の処理、バックアップ、スケジュールと他システムとの依存関係、例外の処理、再起動と回復の手順、ログの管理、監視、保守。そして、外部のサポート先を含む、連絡先とエスカレーション先です。第16回で、大きな障害のとき筆者が把握している外部の連絡先は保守の委託先だけ、と書きました。手順書に書かれる連絡先の一つは、まさにそれです。

手順書は必要に応じて見直して更新し、変更は認可のもとで行う、とされています。教科書も、担当者の個人的な文書ではなく、正式な手順書にしておく必要がある、と書いていました。担当者が不在でも対応できるように、という理由です。

2013年版では運用のセキュリティの先頭にあったものが、2022年版では組織的管理策に移っています。移した理由は、手元の資料からは読み取れませんでした。

現場から：年に1回の作業は、何を見てやるか

年に1回くらいしか回ってこない作業のとき、筆者が見ているのは2つです。前回の作業記録と、自分で書き残した手順メモ。A.5.37が手順書を作る場面の2つ目に挙げた「まれにしか行わない活動」に、そのまま当たります。

前回の作業記録には、強みがあります。実際にその手順で作業が終わった、という実績付きの記録だからです。日付もあり、何をどの順でやったかが残っています。机の上で書いた手順より、よほど当てになる場面もあります。

ただ、記録は手順書ではありません。前回と今回の間に、機器やソフトの版が変わっていれば、記録はそのぶん古くなっています。自分の手順メモも同じで、書いた本人の頭の中にある前提までは書かれていません。本人が読むぶんには十分でも、別の人が読むと穴が開いている。第2回で、引継書は残るが理由が書かれず、異動後の担当者が苦労する、と書いたのと同じ構図です。

第11回では、作業の手順メモや下書きはグループウェアのワークフローに乗らず、承認が付かない、と書きました。手順メモは、まさにその側の文書です。全部を決裁に回せば業務が止まるので、それ自体は緩さではありません。A.5.37から見た論点は、どの作業のメモを、いつ正式な手順書に格上げするかの線引きです。管理基準の「新しい要員に引き継ぐ前」は、その線を引く時期の一つを指しているのだと筆者は読んでいます。

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

法令の一覧が、作った日のまま

A.5.31は「最新に保つ」までを求めています。改訂日の欄がないこと自体が問題というわけではありません。ただ、一覧の更新状況や見直しの実施を説明できる情報がないと、最新の状態に保っていることを説明しにくくなります。自治体の個人情報保護のように、法令の側が大きく動いた例があると、一覧の古さは外からも見えやすくなります。

ライセンスは数えているが、無償ソフトの条件を読んでいない

購入したソフトの本数は、調達の記録で追えます。見落としやすいのは、無償で配られているソフトやサービスの使用条件です。業務利用を制限しているものもあるため、A.5.32の「外部から入手するソフトウェアの使用条件を守る」に引っかかります。

記録は残っているが、開けない

保存期間を決めて残していても、その形式を読めるソフトや機器が先になくなることがあります。A.5.33の細目は、保持期間を通して読める状態を保つことまで挙げていました。暗号化した記録なら、鍵を失うと同じことが起きます。

自己点検を「独立したレビュー」と呼んでしまう

各部署が自分で答える点検は、A.5.36の自己チェックとしては意味があります。ただ、それだけでA.5.35の独立したレビューとするのは難しいはずです。管理基準の細目は、A.5.35のレビューを、権限をもつ系統に属さない人が行うことを挙げています。誰が、誰から独立して見たのかを言えるかが分かれ目になります。

手順書が、書いた人にしか読めない

手順書があっても、前提の知識が書かれていないと、担当者が不在のときに役に立ちません。A.5.37が作る場面の一つに「新しい要員に引き継ぐ前」を挙げているのは、そこを見ているのだと思います。

まとめ

• A.5.31〜A.5.37は、組織的管理策の最後の7個です。2013年版のA.18（順守）の8個はすべてここに来ました。新規はなく、A.5.37だけがA.12（運用のセキュリティ）から移ってきました
• 管理基準は「コンプライアンス管理」の1つのグループにまとめていますが、目的欄を並べると、外の決まりを守る4個、守れているかを見る2個、作業の手順を書く1個に分かれます（この分け方は筆者の整理です）
• A.5.31は、法令と契約を特定して文書にするだけでなく、最新に保つことまで求めています。自治体の個人情報保護は、2023年4月から個人情報保護法の全国共通ルールになりました。一覧が動くべき大きな変化です
• A.5.33は、記録を消失や改ざんから守る管理策です。管理基準の細目は、保持期間を通して読める状態を保つことまで挙げています
• A.5.36は管理者が自分の範囲を見る管理策、A.5.35は対象から独立した立場で取組の全体を見る管理策です。独立は外部と同じ意味ではありません。A.5.36の結果はA.5.35の材料になり得ます。内部監査（9.2）は、独立性や範囲が合えばA.5.35として位置付けられることもありますが、自動的に兼ねるわけではありません
• A.5.37は、まれな作業と、引き継ぐ前の作業に手順書を求めています
• 法の改正で作業が変わらなかったこと自体は問題ではありません。問われるのは「変えなくてよい」という判断を説明できるかです。手順メモも同じで、どのメモをいつ正式な手順書にするかの線引きが論点になります

次回からは人的管理策（A.6）に入ります。選考、雇用条件、教育、懲戒、秘密保持、リモートワーク、事象の報告など8個です。

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

参考にした一次資料

• 経済産業省「情報セキュリティ管理基準（令和7年改正版）」 … 管理策基準の5g（5.31〜5.37）を読みました。各管理策の文・目的・詳細管理策を確認しています。JIS Q 27001:2023、JIS Q 27002:2024をもとにした版です。本文は意見公募時に公開されていた版から読んでいます
• 情報セキュリティマネジメント・セミナー2022 講演資料（JNSA 日本ISMSユーザグループ／2022年12月16日） … 「ISO/IEC 27002改定の解説」（土屋直子／NTTテクノクロス）で、5.31が18.1.1に18.1.5の個別具体的な管理策を吸収して一般化した例として説明されていることを確認しました
• 個人情報保護条例（個人情報保護委員会） … 令和3年改正法の施行により、地方公共団体の条例は必要最小限の独自ルールを除き、個人情報保護法の共通ルールのもとで施行される旨を確認しました（2026年9月26日確認）
• 個人情報の保護に関する法律についてのガイドライン（行政機関等編）（個人情報保護委員会） … 令和3年改正法が令和5年4月に全面施行されたこと、地方公共団体にも行政機関等と同様の規律が全国共通ルールとして適用されることを確認しました。条例で定めることが必要・許容される事項（開示請求の手続・手数料など）と、直接影響しない内部の手続などは独自の規定を置けるという整理も、同じページで確認しています（2026年9月26日確認）
• 岡田敏靖『ISO27001:2022の規格と審査がしっかりわかる教科書 改訂2版』（技術評論社） … 連載で使っている教科書です。32節（A.5）のうち、A.5.31〜A.5.37の説明を読みました。2013年版の番号は、付録の対応表（27002:2022の附属書Bをもとに作成、と注記あり）から引いています

引っかかった点

7個を目的欄で3つに分ける整理は、筆者の読みです。管理基準の目的欄の書き出しを並べて付けたもので、規格や管理基準がそう説明しているわけではありません。

教科書のA.5.34の説明には、日本で該当する法規制として「自治体の個人情報保護条例」が挙がっていました。個人情報保護委員会の説明では、2023年4月の全面施行以降、自治体の個人情報保護は法の全国共通ルールで運用されています。条例で定めるのは、法が委ねた事項などに限られます。教科書の奥付の発行日を筆者はまだ確かめていないので、執筆時期によるずれなのかどうかは分かりません。自治体でISMSを考える読者は、ここは法の側を見るほうが確実です。

A.18.2.3（技術的順守のレビュー）の行き先で、少し迷いました。教科書の付録の対応表では、A.5.36とA.8.8の両方の行に出てきます。教科書の本文もA.5.36の節で技術的順守のレビューを説明していました。一方、管理基準のA.5.36の細目には、自動的な測定・報告ツールの利用を考える項目はあるものの、脆弱性検査のような具体は出てきません。技術的な点検の中身はA.8.8の側に寄せて読むのがよさそうだ、と今は考えています。

教科書のA.5.37の説明では、手順書が「管理者によって承認されていること」が挙がっていました。管理基準には、手順書の「変更は認可のもとで行う」とあります。作ったときの承認まで細目に書かれているかは、管理基準からは読み取れませんでした。記事では変更の認可までを書いています。