ISO27001附属書Aの組織的管理策（A.5.9〜A.5.18）｜資産の目録からアクセス権まで、1本の線でつながる

連載「ISMS審査員・監査への道」の第17回です。前回は組織的管理策の最初の8つ、ISMSの上流を固める管理策を読みました。

今回はその続き、A.5.9からA.5.18までの10個です。資産の目録、情報の分類、情報の転送、アクセス権。一気に手触りのある名前が並びます。

経済産業省の情報セキュリティ管理基準は、この10個を「資産管理」と「アクセス権管理」の2つのグループに分けています。ところが細目まで読むと、2つのグループを1本の線が通っていました。今回はその線を先に示してから、10個を順に見ていきます。

---

A.5.9〜A.5.18をひとことで言うと——数えて、分けて、渡す10個

ひとことで言うと、組織が持っているものを数え、重要さで分け、誰にどこまで渡すかを決める管理策の集まりです。前半の6つが資産と情報の扱い、後半の4つがアクセスの扱いにあたります。

番号	管理策	ひとことで	2013年版
A.5.9	情報及びその他の関連資産の目録	持っているものを洗い出し、責任者を決める	A.8.1.1、A.8.1.2
A.5.10	情報及びその他の関連資産の許容される利用	使ってよいこと、いけないことを決めて伝える	A.8.1.3、A.8.2.3
A.5.11	資産の返却	辞めるとき、契約が終わるときに返してもらう	A.8.1.4
A.5.12	情報の分類	情報を重要さで分ける	A.8.2.1
A.5.13	情報のラベル付け	分類が見て分かるように印を付ける	A.8.2.2
A.5.14	情報の転送	情報を渡すときの規則を決める	A.13.2.1、A.13.2.2、A.13.2.3
A.5.15	アクセス制御	誰がどこまで触れるかの規則を決める	A.9.1.1、A.9.1.2
A.5.16	識別情報の管理	IDを作ってから消すまでを管理する	A.9.2.1
A.5.17	認証情報	パスワードなどの渡し方と守り方を決める	A.9.2.4、A.9.3.1、A.9.4.3
A.5.18	アクセス権	権限を与え、見直し、外す	A.9.2.2、A.9.2.5、A.9.2.6

管理策の名前は管理基準の表記に合わせています。2013年版の番号は、連載で使っている教科書の付録にある対応表（27002:2022の附属書Bをもとにしたもの）から引きました。

並べてみると、10個のうち9つが2013年版の2つの箇条から来ています。A.8「資産の管理」とA.9「アクセス制御」です。例外はA.5.14だけで、こちらは通信のセキュリティ（A.13）から移ってきました。

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

資産管理とアクセス権管理をつなぐ「管理責任者」

結論から言うと、2つのグループには、資産の管理責任者という共通の登場人物がいると筆者は読んでいます。詳細管理策を横断して読むと、目録で責任を割り当てた人が、分類とアクセスの判断にも関わる書き方になっているからです。

管理基準の詳細管理策から、管理責任者が出てくる箇所を拾うと次のようになります。

管理策	管理責任者の役目（詳細管理策から）
A.5.9 目録	資産ごとに、個人かグループに管理責任を割り当てる
A.5.12 情報の分類	情報の管理責任者が、その分類に説明責任を負う
A.5.15 アクセス制御	管理責任者が、アクセス制御に関する要求事項を決める
A.5.18 アクセス権	アクセス権の割当てには、管理責任者からの認可の取得を含む
A.5.9 目録（責任者の義務）	アクセスの制限が分類に合っているかを定期的に見直す

表の最後の行を見ると、線が一周しているのが分かります。目録で決めた責任者が、自分の資産へのアクセスが分類どおりかを見直す。資産の話がアクセスの話に入り、また資産の話に戻ってきます。

この表は、筆者が詳細管理策を横断して拾い、並べたものです。管理基準がこの流れを1つのプロセスとして説明しているわけではありません。ただ、目録の段階で責任者が決まっていないと、後ろの管理策で判断する人がいなくなる。そこは読み違えていないと考えています。

教科書も、資産の管理責任者は多くの場合、リスクアセスメント（6.1.2）のリスク所有者と同じになる、と説明していました。第7回で見たリスク所有者が、ここでもう一度出てくる形です。

A.5.9 情報及びその他の関連資産の目録——1冊の台帳でなくてよい

A.5.9は、情報とその他の関連資産の目録を、管理責任者も含めて作り、維持する管理策です。目的は、資産を特定し、適切な管理責任を割り当てることにあります。

意外だったのは、目録の形にかなり幅があることです。管理基準の参考には、目録は単一のリストである必要はない、と書かれていました。ハードウェア、ソフトウェア、仮想マシン、施設、要員、記録。それぞれの機能が持つ目録の集まりとみてよい、という書き方です。専用の目録を新しく作らなくても、既存の目録で維持してよいとも書かれています。

その代わり、求められる状態ははっきりしています。

• 正確で、最新で、一貫していて、他の目録と整合している
• 正確さを保つ手段として、定期的なレビューか、設置・変更・除去のときに自動で更新される仕組みを挙げる
• 管理責任は、資産が生まれた時点か、組織に移ってきた時点で割り当てる
• 責任者が職務を離れたら、必要に応じて割り当て直す

教科書は、リスクアセスメントで作る資産台帳を、そのまま目録にしてよいと説明していました。もう一つ目に留まったのが、責任の持ち方の例です。ファイルサーバに置いたデータの管理責任は、サーバを管理する部門ではなく、データを使う部門にある。サーバを管理する部門が受け持つのは、機器の保守やバックアップのほうだ、という整理でした。

現場から：目録は、すでに何冊かに分かれている

筆者の現場にも台帳はあります。第11回で書いた通り、年度で区切らずに通年で1つのファイルを使い、過去分は別名で残す運用です。第12回では、調達で入ってきた機器やソフトは、納品後は保守契約で見ている、とも書きました。

A.5.9の参考に照らすと、これは「目録の集まり」の形にかなり近いと感じます。機器は台帳と保守契約で、日々の状態は監視の仕組みで追っている。1冊にまとまっていないこと自体は、この管理策では問題にされていません。

問われるとすれば、別のところです。筆者の見ている台帳には、誰が責任者かを書く欄がありません。

欄が無いから責任者がいない、とは考えていません。第6回で書いた通り、情報セキュリティの役割は事務分掌で職に割り当てられています。業務のシステムには、それを所管する課もあります。責任者は台帳の欄ではなく、分掌と所管の側に書かれている形だと思います（ここは筆者の見方です）。

ただ、A.5.9の管理策の文は、目録を管理責任者も含めて作る、という書き方です。目録を複数の目録の集まりとして持ってよい以上、責任者の情報まで1枚の台帳に全部載っていなければならない、とまでは読めません（筆者の読みです）。規格が台帳の形を決めているわけでもありません。それでも、「この機器の責任者は誰か」と聞かれて台帳から辿れないなら、分掌の文書と突き合わせる手間がそのまま残ります。

もう一つ、教科書の整理どおりなら、中身のデータの責任は使う側の課にあります。機器の台帳だけでは、目録の半分にとどまるかもしれません。

A.5.10 許容される利用／A.5.11 資産の返却——返ってこないのは知識

A.5.10は、情報と資産を使ってよい範囲の規則と取扱いの手順を決め、文書にして実施する管理策です。A.5.11は、雇用や契約が変わる・終わるときに、預けていた資産を全部返してもらう管理策です。

A.5.10でテーマごとの方針に書く事項として、管理基準は3つを挙げています。期待する行動と許容できない行動。許可する利用と禁止する利用。そして、組織が実行している監視活動です。

3つ目は見落としやすいと思いました。監視していることを、使う人に向けて書いておく。禁止事項を並べるだけでは、この項目は埋まりません。

A.5.11で返すものは、パソコンや入館証のような形のあるものだけではありません。管理基準は、継続中の作業に重要な知識を持つ人がいる場合、その情報を文書にして組織に引き継ぐ、としています。教科書も、無形のものとしてソフトウェアや知識を挙げ、退職や契約終了後の秘密保持を明確に求める必要がある、と書いていました。

現場から：物は返っても、理由は返ってこない

第2回で、人事異動の引継書は残るが形式的で、なぜそうしているかが書かれていない、と書きました。異動後の担当者が苦労する、という話です。

A.5.11の目で見ると、これは返却の問題でもあります。パソコンや鍵は、返したかどうかが目に見えます。返ってこないのは、判断の理由のような知識のほうです。管理基準が知識の引継ぎを返却と同じ管理策に入れているのは、そこが抜けやすいからだろうと筆者は受け取りました。

A.5.12 情報の分類／A.5.13 情報のラベル付け——全員が同じ物差しで分けられるか

A.5.12は、機密性・完全性・可用性と、利害関係者の要求事項に基づいて情報を分類する管理策です。A.5.13は、その分類が伝わるように、情報にラベルを付ける手順を決めて実施します。

A.5.12で筆者がいちばん重いと感じたのは、一貫性の項目です。分類の体系は、全員が情報を同じ方法で分類できるよう、組織全体で一貫させ、手順に含める。必ず同じ結果を出せ、というより、同じ体系と基準で分ける、という書き方です。人によって「秘」と「社外秘」の基準が違えば、その後ろのアクセス制御や転送の扱いにも響きかねない、と筆者は考えています。

ほかにも、実務で効きそうな項目が並んでいます。

• 情報の管理責任者が、その分類に説明責任を負う
• 分類を後で見直すための基準を、体系の中に含めておく
• 情報の価値や重要度が変われば、分類も更新する
• 他の組織から受け取った情報の分類を、どう読み替えるかの手順を持つ

最後の項目の参考には、レベルの名前が似ていても、組織が違えば体系は異なりうる、とありました。同じ「秘」でも、相手の「秘」と自分の「秘」が同じ重さとは限らない。外部とやり取りの多い組織ほど効いてくる一文です。

A.5.13では、ラベル付けを省いてよい場合を手順に定めてもよい、とされています。例は、作業負荷を減らすために秘密でない情報へのラベルを省くことです。手法の例には、物理的なラベル、ヘッダ・フッタ、メタデータ、透かし、ゴム印が並んでいました。

教科書には、もう一つ注意が書かれていました。分類を示すことで、悪意のある人にとっての目印になる場合がある。印を付けること自体に、別のリスクがあるということです。

現場から：分類は、ネットワークの側にも埋め込まれている

自治体のネットワークは、扱う情報の重さに応じて系統を分けて組まれることが多いです。マイナンバーを扱う系統、行政専用のネットワークにつながる系統、インターネットにつながる系統、という分け方です。

A.5.12の参考には、情報以外の資産も、そこで扱う情報の分類に合わせて分類できる、とありました。この見方をすると、どの情報をどの系統に置くかという判断は、分類をネットワークの形で先に済ませているとも読めます（ここは筆者の見方です）。

ただ、それで一貫性の項目まで満たせるかは別です。同じ系統の中に置かれた文書どうしの重さの違いは、ネットワークの分け方では表せません。

筆者の手元にも、「社外秘」と表示された資料が回ってくることはあります。A.5.13でいうラベルにあたるものです。一方で、どの資料にその表示を付けるのか、という物差しの話は聞いたことがありません。

ラベルは見えるのに、物差しは見えない。これを緩さとは受け取っていません。第3回で書いた通り、職員が日常で読むのはポリシーの基本方針までです。分類の決まりがあるとすれば、その下の対策基準や手順の側でしょう。

規格の側から見ると、問われるのは、その物差しが表示を付ける人全員に届いているかです。A.5.12の一貫性の項目は、全員が同じ方法で分類できることを求めています。表示だけが回っていて基準が届いていないと、同じ資料が人によって違う扱いになりかねません。

A.5.14 情報の転送——口頭での伝達も入った

A.5.14は、組織の中と外の間で情報を渡すときの規則、手順、合意を、あらゆる種類の転送手段について備える管理策です。

管理基準は、転送の形を3つに分けています。電子的な転送、紙を含む物理的な記憶媒体の輸送、口頭での伝達です。JNSAのセミナー資料では、2013年版の3つの管理策を1つにまとめ、手引も充実させた「変更の多い例」として紹介されていました。3つの形のうち口頭での伝達は、この改定で加わったものとされています。

細目は具体的です。いくつか拾います。

• 誰でも使える外部サービス（ファイル共有やクラウドストレージなど）を使うときは、事前に承認を得る
• 外部のメールアドレスへの自動転送を防ぐ
• 重要な情報を、ショートメッセージやインスタントメッセージで送らないよう助言する
• 秘密の情報を含むメッセージを、留守番電話に残さない
• 取扱いに注意が要る会話では、始めに情報の分類と取扱いを出席者に伝える

最後の項目は、会議の冒頭で「今日の話は外に出さないでください」と言う場面にあたります。口頭が管理策に入ったことで、こうした一言にも置き場ができた形です。

現場から：系統をまたぐ受け渡しには、決まった経路がある

前述の通り、自治体のネットワークは系統を分けて組まれます。系統をまたいでファイルを渡すときは、無害化などの決まった経路を通すのが一般的です。組織の中の転送にも規則を持つ、というA.5.14の書き方には、この仕組みがそのまま当てはまると感じます。

電子的な転送は、こうして仕組みの側で形になりやすいものです。気になるのは、2022年版で加わった口頭のほうです。電話や打合せでの気の配り方は、仕組みに乗せにくく、人の感覚に寄りやすい。ISMSを組む組織なら、ここをどこまで規則として言葉にするかを、一度は決めることになりそうです。

A.5.15 アクセス制御／A.5.16 識別情報の管理——人間以外のIDも対象

A.5.15は、情報と資産への物理的・論理的なアクセスを制御する規則を、事業と情報セキュリティの要求事項に基づいて決める管理策です。A.5.16は、IDを作ってから消すまでのライフサイクル全体を管理します。

A.5.15で考慮する事項は11個並んでいます。どのエンティティにどのアクセスが要るか。知る必要性の原則。特権的なアクセスの制限。職務の分離。アクセス制御の機能（要求・認可・管理など）を分けること。ログの取得。

ここでいうエンティティは、人間の利用者だけではありません。管理基準は、機械や装置、サービスのような技術的なものも含むとしています。サーバどうしが通信するための専用アカウントも、アクセス制御の対象になるということです。

A.5.16は、IDの持ち方を具体的に決めています。

場面	管理基準の書き方
個人に割り当てるID	1つのIDは1人の個人にだけひも付ける。行った処理の説明責任をその人に負わせるため
複数人で使うID	業務上・運用上の理由で必要で、承認と文書化をした場合だけ許可する
人間以外に割り当てるID	権限を分けた承認と、独立した継続的な監視の対象にする
要らなくなったID	時機を失せず無効化か削除する（組織を去った、役割が変わった、など）

共有のIDは禁止ではなく、条件付きで認められています。条件を筆者なりにまとめると、業務上の理由と、承認と、文書化です。昔から使っているから、は条件に入っていません。

なお、IDの登録と削除（A.5.16）と、そのIDに与える権限（A.5.18）は、似ていますが別の管理策です。IDは「誰か」を特定するもの、アクセス権は「その誰かが何をできるか」です。教科書では、定期的なIDの見直しがA.5.16の手順に入っていました。管理基準では、定期的な見直しはA.5.18の側に書かれています。

A.5.17 認証情報——渡し方まで決めてある

A.5.17は、パスワードのような認証情報の割当てと管理を、適切な取扱いを利用者に助言することも含めて管理する管理策です。教科書は、パスワードのほか、秘密鍵、ワンタイムパスワード、パターン、生体認証を例に挙げていました。

割当ての細目で、実務に直結するのは次のあたりです。

• 仮のパスワードは推測できず、一人ひとり違うものにし、最初に使った後で変えさせる
• 新しい認証情報を発行する前に、本人確認の手順を決めておく
• 認証情報は安全な方法で渡し、保護されていない電子メールで送らない
• 利用者は受け取ったことを知らせる
• 業者が初めから設定している認証情報は、インストールの直後に変える

利用者の責任には、秘密を保つ、他人と共有しない、異なるサービスで同じパスワードを使わない、などが並びます。そして、これらの義務が雇用条件にも含まれている、という項目で締めくくられていました。

パスワード管理システムの細目も8つあります。強いパスワードを使わせる、最初のログインで変えさせる、以前のパスワードの再利用を防ぐ、よく使われるパスワードや漏えいした組合せを使わせない、などです。

目に留まったのは、変えさせる場面の書き方でした。最初のログインのほかは「必要に応じて」とされ、例としてインシデントの後や、共有IDのパスワードを知る人が辞めたり役割が変わったりしたときが挙がっています。定期的に変えさせる、という言葉は見当たりません。

少なくとも管理基準の5.17の細目に、定期変更を求める記述はないということです。ただし、定期変更を禁じる書き方でもありません。あくまで「必要に応じて」です。

国内外の指針は、ここからもう一歩踏み込んでいます。米国NISTのデジタルIDのガイドライン（SP 800-63B）は、パスワードの定期的な変更を利用者に求めてはならず、侵害の証拠があれば変更させる、としています。総務省の国民向けのサイトにも、流出した事実がなければ変える必要はない、という説明があります。定期的に変えさせると、作り方がパターン化して簡単になったり、使い回しにつながったりするほうが問題だ、という理由でした。

管理基準は定期変更を「求めていない」。NISTは「求めてはならない」。向きは近くても、言い切りの強さは違います。

教科書は、利用者への周知に不正アクセス禁止法の話を入れる役割にも触れていました。同法は、業務その他正当な理由がある場合を除き、他人の識別符号（IDとパスワードなど）を、アクセス管理者や本人以外の者に提供することを禁じています。ルールの説明だけでなく、法律の話として伝える。利用者向けの教育では効きそうな観点です。

A.5.18 アクセス権——与える・見直す・外すが1つになった

A.5.18は、アクセス権を、アクセス制御の方針と規則に従って提供し、見直し、変更し、削除する管理策です。JNSAのセミナー資料では、2013年版の3つの管理策を、提供から削除までの一連の流れとしてまとめた「ライフサイクルに沿った統合」の例として紹介されていました。

与えるときと外すときの細目は11個あります。とくに実務で効きそうなのは次のものです。

• 資産の管理責任者から認可を得る
• 承認する役割と実施する役割を分ける
• 組織を去った利用者のアクセス権は、時機を失せず削除する
• 臨時の要員や一時的なアクセスには期限を付け、期限の日に取り消す
• 認可の手続が終わってからだけ、アクセス権を有効にする
• IDごとに与えたアクセス権を、一元的に記録しておく
• 役割や職務が変わった利用者のアクセス権を変える

定期的な見直しでは、異動・昇進・降格・退職の後のアクセス権と、特権的なアクセス権を考慮する、とされています。

もう一つ目に留まったのが、変わる「前」の項目です。雇用の変更や終了の前に、アクセス権を見直し、調整か削除をする。判断の材料として、変更が本人の側から来たものか組織の側からか、いまの責任、アクセスできる資産の価値、が挙がっていました。変わってから直すのではなく、変わる前に手を打つ書き方です。

現場から：いちばん多かった仕事は、人事異動

筆者は常駐先で、日々の作業報告を長く書き続けてきました。その記録をテーマ別に数えたことがあります。毎年いちばん多かったのは、セキュリティ事故でも障害対応でもなく、人事異動に伴うアカウントと権限の作業でした。年によって20件から40件あまりで、首位を譲った年はありません。1人の担当者の記録を数えただけなので、自治体一般の姿だとは言えません。

A.5.18の条文を読むと、アクセス権の管理は「提供・見直し・変更・削除」と一行で済みます。ただ、年度替わりに異動が集中する組織では、これが年に一度の大きな工事になります。内示が出てから準備を始め、発令の後もしばらく尾を引く。

振り返ると、内示の後の準備は、5.18.3の「雇用の変更の前に見直す」にかなり近い動きだと気づきました。変わる前に手を打つ仕組みは、制度の側が先に持っていた形です。

筆者の作業は、職員からの依頼を起点に動きます。依頼が来れば付与し、変更する。変更の瞬間には強い形です。依頼とは別に、権限をまとめて見直す場面もあります。多いのは組織の変更のときです。課や係の形が変わると、その下の権限をまとめて洗い直すことになる。人事異動と時期が重なることが多いので、年度替わりの工事がさらに大きくなります。

規格の書き方と並べると、見直しのきっかけが暦ではなく、組織の形の変化になっています。管理基準の見直しの考慮事項も、異動・昇進・降格・退職といった変化を最初に挙げていました。変化の大きい瞬間をとらえる点では、理にかなった形だと思います。

残る問いは1つです。組織の形が変わらなかった年に、依頼の来なかった権限を誰が拾うのか。A.5.18の「定期的な見直し」は、その年のための項目だと筆者は読んでいます。その年にどう拾っているかまでは、今回は確かめていません。

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

目録を機器の台帳だけで作る

機器やソフトの台帳は、情報部門の手元に揃いやすいものです。ただ、A.5.9の目録は「情報及びその他の関連資産」の目録です。中身の情報と、その管理責任者が抜けていると、分類とアクセス権の判断をする人が決まりません。責任者が分掌や所管で決まっている組織でも、台帳からそこへ辿れる形にしておきたいところです。

分類の基準はあるが、人によって結果が違う

分類の体系が文書にあっても、人によって判断の基準がばらばらなら、A.5.12の一貫性の項目は満たしにくくなります。分類の例を具体的に示す、迷ったときの問い合わせ先を決める、といった支えが要ると思います。

付与の手順はあるが、見直しと削除が依頼待ち

A.5.18は、与えるだけでなく、見直しと削除まで1つの管理策にしています。依頼で付与する流れがきちんと回っていても、依頼の来ない権限が残り続けるなら、ライフサイクルの後ろ半分が空いたままです。

共有IDを「昔からあるから」で残す

A.5.16は共有のIDを条件付きで認めています。条件は業務上の理由と承認と文書化です。理由を言えない共有IDは、そのまま指摘の対象になりやすいと考えています。

まとめ

• A.5.9〜A.5.18は、資産を数え、分類し、アクセスを渡す10個です。10個のうち9つは2013年版のA.8（資産の管理）とA.9（アクセス制御）から来ています
• 管理基準は資産管理とアクセス権管理の2グループに分けていますが、詳細管理策を横断して読むと、資産の管理責任者が両方に関わっています（この読み方は筆者の整理です）
• 目録は1冊の台帳でなくてよい一方、目録どうしの整合と、情報そのものの責任者が問われます。責任者が分掌で決まっている組織でも、台帳からそこへ辿れるかが効いてきます
• 情報の分類は、全員が同じ方法で分類できる一貫性が要になります。ラベルが回っていても、付ける物差しが届いているかは別の問題です
• 情報の転送には、2022年版で口頭での伝達が加わりました
• 認証情報の細目は、変えさせる場面を「必要に応じて」と書き、定期的という言葉はありません。禁じる書き方ではありませんが、NISTや総務省の指針と向きは近いものです
• アクセス権は、提供・見直し・変更・削除が1つの管理策にまとまりました。変わる前に見直す項目もあります

次回は組織的管理策の3回目、A.5.19〜A.5.30です。供給者との関係、クラウドサービス、インシデント管理、事業継続が並びます。

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

参考にした一次資料

• 経済産業省「情報セキュリティ管理基準（令和7年改正版）」 … 管理策基準の5b（5.9〜5.14）と5c（5.15〜5.18）を読みました。各管理策の文・目的・詳細管理策を確認しています。JIS Q 27001:2023、JIS Q 27002:2024をもとにした版です。本文は意見公募時に公開されていた版から読んでいます
• 情報セキュリティマネジメント・セミナー2022 講演資料（JNSA 日本ISMSユーザグループ／2022年12月16日） … 「ISO/IEC 27002改定の解説」（土屋直子／NTTテクノクロス）で、5.18が2013年版の3つの管理策をライフサイクルに沿ってまとめたものであることを確認しました
• 「ISO/IEC 27001 及び ISO/IEC 27002 の活用 ー情報セキュリティ管理策を軸にー」（山下真／JNSA 日本ISMSユーザグループ 情報セキュリティマネジメント・セミナー2023／2023年12月18日） … 5.14が2013年版の3つの管理策をまとめた「変更の多い例」であること、口頭での伝達が加わったことを確認しました
• NIST SP 800-63B（米国国立標準技術研究所のデジタルIDのガイドライン） … パスワードの定期的な変更を求めてはならない、という記述を確認しました。侵害の証拠があれば変更させる、とも書かれています（2026年9月25日確認。ページの版は2025年8月）
• 安全なパスワードの設定・管理（総務省 国民のためのサイバーセキュリティサイト） … 流出した事実がなければパスワードを変える必要はないこと、定期的な変更の弊害を確認しました（2026年9月25日確認）
• 不正アクセス行為の禁止等に関する法律（e-Gov法令検索） … 第5条（他人の識別符号の提供の禁止）の文言を確認しました（2026年9月25日確認）
• 岡田敏靖『ISO27001:2022の規格と審査がしっかりわかる教科書 改訂2版』（技術評論社） … 連載で使っている教科書です。32節（A.5）のうち、A.5.9〜A.5.18の説明を読みました。2013年版の番号は、付録の対応表（27002:2022の附属書Bをもとに作成、と注記あり）から引いています

引っかかった点

資産管理とアクセス権管理を「管理責任者」がつなぐ、という整理は筆者の読みです。管理基準の詳細管理策から、管理責任者が出てくる箇所を拾って並べたもので、規格や管理基準がそう説明しているわけではありません。

パスワードの変更で、教科書と管理基準の書き方が違っていました。教科書は、パスワード管理システムの条件として「定期的及び最初のログイン時など、必要に応じて変更する」を挙げています。管理基準の5.17は、最初のログイン時と、インシデントの後や雇用の終了・変更の時など、必要に応じて変えさせる書き方です。定期的という言葉は見当たりませんでした。両者の書き方には違いがあります。教科書がなぜ「定期的」を入れているのかは、この記事の範囲では確かめられていません。27002:2022の手引そのものと、2013年版の手引で定期変更がどう書かれていたかは、筆者は確かめていません。自分の組織の規程が定期変更を定めているなら、運用を変える前に規程の見直しが先になります。

IDの定期的な見直しを、教科書はA.5.16（識別情報の管理）の手順に入れ、管理基準はA.5.18（アクセス権）の見直しとして書いています。教科書の図にも、登録と削除の手順がA.5.18の欄に置かれている箇所がありました。IDと権限の境目は、解説する側でも揺れやすいところなのかもしれません。

A.5.10の名前は、管理基準では「許容される利用」、教科書では「利用の許容範囲」でした。記事は管理基準の表記に合わせています。