ISO27001附属書Aの技術的管理策（A.8.25〜A.8.34）｜開発しない組織にも、開発の管理策は委託を通って届く

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

経済産業省の情報セキュリティ管理基準は、A.8の管理策を8a〜8dの4つに区切っています。今回はその最後、「8d 情報システム開発／導入の管理」にあたるA.8.25〜A.8.34の10個です。技術的管理策は、この回で読み終わります。

並ぶのは、開発のライフサイクル、コーディング、テストといった名前です。正直、自分で開発しない組織には遠い区切りだと思って読み始めました。筆者の現場でも、業務システムを作っているのは委託先です。ところが細目を読むと、多くの項目に「外部委託した場合は」という一文が添えてありました。

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

---

A.8.25〜A.8.34をひとことで言うと——決めて、作って、確かめて、任せて、変える

ひとことで言うと、システムを作るときと変えるときに、セキュリティを最初から組み込むための10個です。

番号	管理策	ひとことで	2013年版
A.8.25	セキュリティに配慮した開発のライフサイクル	開発の規則を決めて適用する	A.14.2.1
A.8.26	アプリケーションセキュリティの要求事項	作る・買うときに要求を決めて承認する	A.14.1.2、A.14.1.3
A.8.27	セキュリティに配慮したシステムアーキテクチャ及びシステム構築の原則	構築の原則を決めて、全部の開発に当てる	A.14.2.5
A.8.28	セキュリティに配慮したコーディング	コーディングの原則を当てる	新規
A.8.29	開発及び受入れにおけるセキュリティテスト	テストの手順を決めて実施する	A.14.2.8、A.14.2.9
A.8.30	外部委託による開発	委託した開発を指揮し、監視し、レビューする	A.14.2.7
A.8.31	開発環境、テスト環境及び本番環境の分離	3つの環境を分けて守る	A.12.1.4、A.14.2.6
A.8.32	変更管理	変更は手順に従う	A.12.1.2、A.14.2.2、A.14.2.3、A.14.2.4
A.8.33	テスト用情報	テストに使う情報を選び、守る	A.14.3.1
A.8.34	監査におけるテスト中の情報システムの保護	監査のテストを計画し、合意する	A.12.7.1

対応を見ると、2013年版の箇条A.14「システムの取得、開発及び保守」の行き先がはっきりします。A.14の13個のうち、14.1.1は第16回で読んだA.5.8へ移りました。残りの12個は、すべてこの区切りに入っています。

A.8.32は、4つの管理策がまとまった1個です。この区切りで一番多い統合でした。新規はA.8.28だけです。JNSAのセミナーの解説資料は、開発段階からのセキュリティを強化するための新規として紹介していました。

5つの組に分けて読む

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

組	管理策	何をする組か
決める	A.8.25〜A.8.27	開発の規則、要求事項、構築の原則
作って確かめる	A.8.28、A.8.29、A.8.33	コーディング、テスト、テストに使う情報
任せる	A.8.30	外部委託した開発
分けて変える	A.8.31、A.8.32	環境の分離と、変更の手順
監査で触る	A.8.34	運用中のシステムにかかる監査のテスト

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

A.8.25〜A.8.27 決める——要求も原則も、作る前に置く

A.8.25 開発の規則を決める

A.8.25は、ソフトウェアとシステムをセキュリティに配慮して開発するための規則を決め、適用する管理策です。

細目は、規則で考える側面をa)〜j)の10項目で挙げています。環境の分離、コーディングの手引、設計段階の要求事項、テスト、リポジトリ、版の管理、開発者の知識と能力、ライセンスです。並びを見ると、この区切りのほかの管理策への参照が多く付いています。A.8.25は、8dの目次のような位置にあると感じました。

最後に、外部委託についての一文があります。開発を外部委託したら、供給者が組織の規則を守っていることの「保証を得る」。規則は自分たちで作るものですが、守る人は外にいてもよい、という書き方です。

A.8.26 要求事項は、リスクアセスメントから

A.8.26は、アプリケーションを開発または取得するときに、情報セキュリティの要求事項を特定し、規定し、承認する管理策です。「取得」が入っているので、自分で作らず買う場合も対象になります。

細目の最初は、要求事項をリスクアセスメントを通じて特定する、です。第7回から読んできたリスクアセスメントが、ここで個々のアプリケーションの仕様につながります。情報セキュリティの専門家の支援を受けることも、考慮する事項に挙がっていました。

要求事項に含める項目は、a)〜p)の16項目です。認証、情報の分類、アクセスの分離、入力の管理、ログ、エラーメッセージの扱いなどが並びます。その中に、意外な項目が1つありました。

• m) 「自由記述」欄の内容に関する制限。機密データ（例えば個人データ）が、管理されないまま保存されることにつながり得るため

備考欄やメモ欄には、決まった項目に入らない事情が書き込まれがちです。項目として設計した情報は守られていても、自由記述欄の中身は誰も把握していない。そうなりやすいことを、細目は要求事項の段階で拾っています。業種を問わず、身に覚えのある人は多いのではないでしょうか。

A.8.27 構築の原則と、満たし切れないものの承認

A.8.27は、セキュリティに配慮したシステムを構築するための原則を決め、文書化し、維持し、すべての開発活動に適用する管理策です。

細目には、原則の名前がずらりと並んでいました。セキュリティバイデザイン、多層防御、デフォルト拒否、最小特権などです。ゼロトラストの原則も挙がっています。組織の情報システムはすでに侵害されていると想定し、ネットワークの境界のセキュリティだけに頼らない、という考え方です。

前回のA.8.22は、ネットワークを分けて境界で守る管理策でした。境界だけに頼らない、という今回の原則と並べると、向きが違って見えます。ただ、細目はゼロトラストを「考慮する」と書いているだけです。分けることをやめよ、とは書いていません。境界で守ったうえで、内側も信用しすぎない。筆者はそう読みました。

もう1つ、目を引いた項目があります。セキュリティ要求事項を完全には満たせないまま対策を採るときは、そのことを文書にして正式に承認する、というものです。例として、安全に関する要求を優先する場合が挙がっていました。

これは第8回で読んだ、残留リスクの承認と同じ形です。満たせないこと自体は起こり得る。問われるのは、満たせないと分かったうえで誰が承認したかが残っているか、です。

現場から：要件の細部は、構築の途中で決まる

第16回で、筆者の現場ではログの取り方や権限の割り方といった細部が構築の途中で決まっていく、と書きました。委託で調達する場合には自然な流れだと、筆者は考えています。

A.8.26の管理策の文は、要求事項を特定し、規定し、「承認する」です。構築の途中で決まった細部も、要求事項であることに変わりはありません。途中で決まったものを誰がどこで確かめるのか。この問いは、次のA.8.29の受入れにつながっていきます。

A.8.28 セキュリティに配慮したコーディング——新規の1個

A.8.28は、セキュリティに配慮したコーディングの原則を、ソフトウェア開発に適用する管理策です。目的は、ソフトウェアの潜在的なぜい弱性の数を減らすことです。2022年版で新しく入りました。

細目は、工程の順に並んでいます。

段階	細目の主な中身
全般	組織全体のプロセスとベースラインを決める。第三者の構成要素とオープンソースソフトウェアも対象に広げる。現実の脅威を監視し、原則を継続的に改善する
コーディング前	組織内と外部委託の両方に使う期待と原則。開発ツールの構成と更新。脅威モデリングを含む設計
コーディング中	言語ごとの慣行。ピアレビューなどの手法。ハードコードされたパスワードなど、配慮しない設計手法の禁止
運用開始の前後	攻撃対象領域と最小特権を評価する。運用開始後は、更新の適用、ぜい弱性への対処、ログのレビュー、ソースコードの保護
外部の部品	外部ライブラリの目録（版を含む）を持ち、規則正しく更新する。出どころと使用許諾を確かめる

外部ライブラリの目録は、第24回の技術的ぜい弱性の管理とつながります。どの部品をどの版で使っているか分からなければ、部品のぜい弱性が公表されても、自分たちに関係するかを判断できません。

現場から：筆者がいた頃の規約に、攻撃の観点はなかった

筆者は以前、COBOLやOracleで開発をしていました。その頃にもコーディング規約はありました。中身は命名や構造、書き方をそろえるためのものです。セキュリティの観点、つまり攻撃を防ぐという観点は入っていませんでした。

細目と並べると、違いは規約が何に合わせて書かれているかにあると感じます。

	筆者の知る規約	A.8.28の細目が求める原則
合わせる相手	組織の中の読みやすさ、そろいやすさ	外の現実の脅威と、ぜい弱性の最新の情報
防ぐもの	書き方のばらつき	悪用され得る欠陥
更新のきっかけ	（細目には対応する項目がない）	脅威の変化を監視し、継続的に改善する

書き方をそろえる規約にも、もちろん価値はあります。読み違いが減り、引き継いだ人が追いやすくなるからです。ただ、それだけでは外から来る攻撃に合わせて中身が変わっていきません。2022年版でこの管理策が独立して入ったのは、その差を埋めるためだと筆者は読みました。

自分で開発しない組織にとって、この管理策の入口は細目の一文です。コーディング前の項目に、組織内と外部委託の「両方」に使う原則、とあります。委託先のコーディングにも、組織として期待を示す前提の書き方です。

パッケージを改造するときの考慮事項

A.8.28の細目の最後に、ソフトウェアパッケージを変更する必要がある場合の考慮事項がありました。

• 組み込まれた管理策や完全性が損なわれるリスク
• 業者の同意を得るか
• 標準の更新として業者から変更を得られる可能性
• 変更の結果、将来の保守の責任が組織に移る影響
• ほかのソフトウェアとの互換性

教科書はこの内容を、A.8.32 変更管理の説明の中に置いていました。この点は「引っかかった点」に書きます。

自治体の基幹業務システムには、国が定める標準化の方針があります。その基本方針は、原則として標準準拠システムをカスタマイズしないようにする、と書いています。独自の施策は、別のシステムとして疎結合で作る、という考え方です。

国の方針の理由は、統一・標準化の目標の側にあります。細目の4つ目は、セキュリティと保守の側から同じ向きを指している、と筆者は読みました。改造するほど、業者の標準の更新に乗れなくなり、保守の責任が組織の側へ寄っていきます。

A.8.29・A.8.33 確かめる——テストと、テストに使う情報

A.8.29 テストの程度は、重要性に見合ったもの

A.8.29は、セキュリティテストの手順を開発のライフサイクルの中で決め、実施する管理策です。目的は、アプリケーションやコードを本番環境に入れるときに、要求事項を満たしているかを確かめることです。

細目で押さえておきたい点を、4つ挙げます。

• セキュリティテストは、システムのテストに組み込み、その一部とする
• テストの程度は、システムの重要性、性質、変更の潜在的な影響に見合ったものにする
• 組織内で開発するものは、開発チームのテストの次に、独立した受入れテストを行う
• 外部委託した開発と購入した部品は取得の手順に従い、契約で要求事項に触れる。取得の前に、契約で決めた要求事項に照らして評価する

2つ目は、全部を同じ重さで試さなくてよい、という意味でもあります。小さな変更に大がかりな試験を課せば、変更そのものが止まってしまいます。逆に言えば、なぜこの程度で足りるとしたかを説明できる状態が求められている、と考えています。

現場から：受入れは、職員と委託先で完結している

委託先が新しいシステムや改修を納めるとき、受入れは職員と委託先の間で完結しています。筆者が関わるのは、稼働した後の運用からです。

これは、筆者が委託を受けて運用を担う側だからです。仕様書や検収といった発注側の工程は、もともと筆者の仕事ではありません。第2回の認証書や、第22回の消去の証明書と同じく、確かめる工程は職員の側にあります。分担として筋が通った形だと考えています。

並べてみると、工程ごとに見える人が変わります。

工程	主に担う人	筆者の位置から見えるもの
要求事項を決める（A.8.26）	職員と委託先	見えない
細部を決める（構築の途中）	委託先と職員	決まった結果
受入れで確かめる（A.8.29）	職員と委託先	見えない
運用する	筆者	動いている姿のすべて

運用する人は、ログの取り方や権限の割り方が実際の業務に合っているかに、最初に気づける位置にいます。気づいたことが次の更改のときにA.8.26の要求事項へ戻る経路があるか。ここが分かれ目だと考えていますが、今回は確かめていません。

A.8.33 本番の情報をテストに使うとき

A.8.33は、テストに使う情報を適切に選び、保護し、管理する管理策です。

細目は、取扱いに慎重を要する情報（個人を特定できる情報を含む）を、開発環境やテスト環境に複製しない、と書いています。そのうえで、本番の情報の複製をテストに使う場合の決まりも並べていました。

• 本番と同じアクセス制御をテスト環境にも当てる
• 複製をテスト環境に置くたびに、認可を受ける
• 複製と利用のログを取り、監査証跡にする
• 慎重を要する情報は、削除やマスキングで守る
• テストが終わったら、すぐにテスト環境から消す

「複製しない」と「複製を使うなら」が並んでいるのは、原則と例外の関係だと読みました。住民の情報を扱うシステムでは、この例外の重さが一段上がります。テスト環境が委託先の側にある場合、これらの決まりは契約を通して届けることになります。次のA.8.30の細目に、開発環境のセキュリティ要求事項が挙がっているのはそのためでしょう。

A.8.30 外部委託による開発——指揮し、監視し、レビューする

A.8.30は、外部委託したシステム開発の活動を、組織が指揮し、監視し、レビューする管理策です。目的は、組織が求める対策が、委託した開発でも実施されるようにすることです。

細目は、委託するときにすることとして、要求と期待を伝える、合意する、成果物を継続的に監視する、開発されたシステムをレビューする、の4つを挙げています。続いて、サプライチェーン全体で考慮する事項がa)〜k)の11項目です。筆者なりにまとめると、3つに分かれます。

まとまり（筆者の整理）	細目の主な中身
権利を決める	使用許諾、コードの帰属、知的財産権。ソースコードの預託契約（例えば供給者が事業を終了する場合）。開発の手順と管理策を監査する、契約上の権利
作り方を求める	設計・コーディング・テストについての契約上の要求事項。考慮すべき脅威モデルの提供。開発環境のセキュリティ要求事項。適用される法令
証拠を受け取る	受入れテスト。最低限の機能を満たす証拠（保証報告書など）。悪意のある内容や既知のぜい弱性がないことを示す、テストの証拠

第23回で、筆者の現場では業務システムのソースコードは開発の委託先にある、と書きました。コードの側の扱いは契約とA.8.30に行く、とも書いています。今回、その行き先の中身を読んだことになります。

細目は、コードが委託先にあること自体を問題にしていません。問うているのは、そのコードが誰のものか、委託先がいなくなったらどうなるかを、先に決めてあるかです。預託契約が例に挙がっているのは、まさにその備えでしょう。

筆者は契約書を見る立場にないので、現場の契約にこれらが入っているかは分かりません。そのうえで、この区切りの細目を見直すと、外部委託に触れる項目がA.8.30の外にもいくつもあります。

管理策	外部委託に触れる細目
A.8.25	供給者が組織の規則を守っていることの保証を得る
A.8.27	構築の原則を、契約などを通じて委託した開発にも当てる
A.8.28	コーディングの原則を、組織内と外部委託の両方に使う
A.8.29	委託した開発と購入した部品は取得の手順に従い、契約で要求事項に触れる
A.8.30	指揮、監視、レビュー。権利、作り方、証拠

自分で開発しない組織にとって、8dに触れる入口の1つはA.8.30だと考えています。ほかの管理策の中身も、多くは契約と受入れを通って委託先へ届きます。「開発していないから8dは関係ない」とは読めない、というのが今回の一番の発見でした。

A.8.31・A.8.32 分けて、変える

A.8.31 本番への入口は、組織の手元に残る

A.8.31は、開発環境、テスト環境、本番環境を分け、それぞれのセキュリティを保つ管理策です。目的は、開発やテストの活動による危険から、本番環境とそのデータを守ることです。

細目には、次のような項目があります。

• 開発から本番へソフトウェアを移す規則と認可を、はっきり決めて文書にし、実施する
• 本番への変更は、本番に当てる前にテスト環境で試す
• 特定し承認された場合を除き、本番環境でテストをしない
• 本番のシステムから、必要のないときにコンパイラや開発ツールへ手が届かないようにする
• 1人の人間が、事前のレビューと承認なしに、開発環境と本番環境の両方を変えられないようにする

最後の項目は、第6回から何度か書いてきた、判断する人と手を動かす人を分ける考え方と同じ筋です。細目は、アクセス権を分けても、監視を伴う規則で止めてもよい、としています。

開発を委託している組織では、開発環境が委託先の側にあることもあります。その場合、組織の手元に残るのは本番への入口です。1つ目の、本番へ移す規則と認可がそれに当たります。第19回で書いた、ソフトウェアの導入は職員が判断し、筆者が作業する、という形もこの入口の一部です。

A.8.32 変更管理は、9つの中身を持つ

A.8.32は、情報処理設備と情報システムの変更を、変更管理の手順に従って行う管理策です。目的は、変更するときに情報セキュリティを保つことです。

ここで1つ区別しておきます。第9回で読んだ箇条6.3は、ISMSそのものを変えるときの計画です。システムを変えるたびに6.3が働くわけではありません。システムや設備の変更を受け持つのは、このA.8.32の側です。

細目は、新しいシステムの導入と既存システムの重要な変更を、合意した規則と正式な手続に従わせます。手順は設計の初期から保守作業まで、ライフサイクル全体にわたって文書にします。手順に含める中身は、a)〜i)の9つでした。

手順の中身	この連載で関係する回（筆者の整理）
a) 依存関係を考えた影響の計画と評価	番外編：作業ごとのリスク検討の書き場所
b) 変更の認可	第6回・第19回：判断は職員、作業は筆者
c) 関係者への伝達	第18回：供給者の変更の知らせは職員を経て筆者へ
d) テストと受入れ	今回のA.8.29
e) 導入計画を含む実施	—
f) フォールバック手順を含む、緊急時と不測の事態	このあとの現場の話
g) 上のすべてを含む記録の維持	第11回：ワークフローに乗ると記録が残る
h) 運用文書と利用者手順を、必要に応じて変える	第9回・第11回：規程・手順書の改訂が見えにくい
i) ICT継続計画と復旧手順を、必要に応じて変える	第18回：止めて戻す手順の試験

並べてみると、連載で何度も出てきた話が、変更管理の1本の手順の中に収まっていきます。とくにh)とi)が面白いと感じました。システムを変えたら、手順書と継続計画も変える。ここまでを変更管理の中身に入れているのは、変更の後に文書が取り残されやすいからでしょう。第11回で書いた「改訂が見えない」は、この2行の側から見直せそうです。

現場から：急ぎの変更でも、先に口頭で了承を取る

障害対応で、急いで設定を変えなければならない場面があります。筆者の現場では、その場合も口頭などで職員の了承を得てから変更します。ワークフローや報告などの記録は、後から整える形です。

f)の緊急時の考慮が、現場で回っている形です。急ぐ場面でも、判断する人と手を動かす人の順番は崩れていません。筆者はこれを、この分担の強みだと考えています。

細目と並べると、緊急の変更について審査で聞かれやすいのは2点だと考えています。1つは、後から整えた記録から、誰がいつ了承したかをたどれるかです。g)は、緊急時の対応も含めて記録を保つよう書いています。もう1つは、どんな場面を緊急として扱ってよいかの線引きです。急ぎの経路が便利になるほど、通常の経路を通らない変更は増えやすくなります。どちらも、緊急の経路を持つ組織ならどこでも問われる点です。

A.8.34 監査におけるテスト中の情報システムの保護——監査する側にも決まりがある

A.8.34は、運用中のシステムを評価する監査のテストやその他の保証活動を計画し、テストをする人と適切な管理層の間で合意する管理策です。目的は、監査が運用中のシステムと業務に与える影響を、できるだけ小さくすることです。

細目は8項目あり、筆者なりにまとめると次のようになります。

決めること	細目の主な中身
同意と範囲	システムとデータへのアクセスについて、適切な管理層の同意を得る。技術的な監査のテストの範囲を合意し、管理する
触り方	読み出し専用のアクセスに限る。それで足りなければ、権限を持つ経験のある管理者が監査人に代わって実行する。読み出し専用以外は、隔離した複製に対してだけ許す
持ち込む機器	アクセスに使う機器（ノートパソコンなど）のセキュリティ要求事項を決め、確かめる
時間と道具	監査ツールの実行など、特別な処理を合意する。可用性に影響しそうなテストは営業時間外に行う
記録	監査とテストを目的とするすべてのアクセスを監視し、ログを取る

監査は守るための活動です。それでも、運用中のシステムに触る以上はリスクになる。附属書Aがそこまで管理策にしているのは、監査する側も例外にしない、という考え方だと読みました。第14回の内部監査でも、技術的なテストを含むなら、この観点が計画に入ることになります。

筆者が監査に関わったのは、書類を出す側としてだけです。運用中のシステムにテストをかける監査の場面は見ていません。そのため、ここは一般論にとどめます。脆弱性診断のように運用中のシステムに外から検査をかける場面も、この形に当てはまりそうだ、というのが筆者の読みです。

審査員や監査人を目指す人にとって、この管理策は自分が守る側の決まりでもあります。技術的な検査を伴う監査をする側に回るなら、読み出し専用で触る、持ち込む機器の状態を示す、といった準備が求められる、と考えています。

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

「開発していないから、8dは対象外」と読む

この区切りの細目は、外部委託した開発にも何度も触れています。自分で開発しない組織でも、委託や購入を通して多くの管理策が関わります。適用宣言書で適用しないとするなら、その理由をリスクや組織の状況に照らして説明できるかが問われやすいと考えています。附属書Aは全部を一律に求めるものではありませんが、細目はその説明を組み立てる材料になります。

受入れで、機能だけを確かめている

A.8.29の細目は、セキュリティテストをシステムのテストに組み込むよう書いています。受入れの観点が業務の機能に寄っていると、要求事項として決めたセキュリティの機能が確かめられないまま本番に入りがちです。

本番のデータを、そのままテストに使う

A.8.33の細目は、慎重を要する情報をテスト環境に複製しないことを原則にしています。使うなら、都度の認可、ログ、マスキング、終了後の削除までがひと組です。委託先のテスト環境で行うなら、契約で届いているかも見られやすい点です。

緊急の変更が、手順の外にある

A.8.32の細目は、緊急時の扱いを変更管理の手順の中身に含めています。急ぎの経路が手順の外の慣行になっていると、後から記録を整えるときに、誰がいつ了承したかがたどれなくなることがあります。

システムを変えたのに、手順書と継続計画が古い

A.8.32の細目は、変更に合わせて運用文書や継続計画を変えることまで手順に入れています。システムは新しいのに手順書が前の画面のまま、という状態は、変更管理の抜けとして指摘されやすいと考えています。

まとめ

• A.8.25〜A.8.34の10個は、管理基準の「情報システム開発／導入の管理」です。2013年版のA.14は、14.1.1がA.5.8へ、残る12個がすべてこの区切りへ移りました。新規はA.8.28だけです
• 新規のA.8.28の細目は、コーディングの原則を現実の脅威に合わせて継続的に改善するよう書いています。筆者がいた頃の規約は書き方をそろえるもので、攻撃の観点は入っていませんでした
• パッケージを改造するときの考慮事項は、管理基準ではA.8.28の細目にあります。自治体の標準化の方針も、原則としてカスタマイズしない向きです
• A.8.30の細目は、コードの帰属や預託、監査の権利まで契約で決めるよう挙げています。自分で開発しない組織にとって、8dに触れる入口の1つはA.8.30だと筆者は読みました
• 筆者の現場では、受入れは職員と委託先で完結しています。運用で気づいたことが次の要求事項へ戻る経路があるかは、確かめていません
• A.8.32の細目は、緊急時の扱いと、変更後の手順書・継続計画の見直しまで手順に含めています。筆者の現場では、急ぎの変更でも先に口頭で了承を取っています

技術的管理策は、これで読み終わりました。附属書Aの93の管理策も、この回で一巡したことになります。次回からは第4期に入り、ISMSを構築してから認証を取るまでの流れを読む予定です。

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

参考にした一次資料

• 経済産業省「情報セキュリティ管理基準（令和7年改正版）」 … 管理策基準の8d（8.25〜8.34）の管理策・目的・詳細管理策を読みました。JIS Q 27001:2023、JIS Q 27002:2024をもとにした版です。本文は意見公募時に公開されていた版から読んでいます
• 情報セキュリティマネジメント・セミナー2022 講演資料（JNSA 日本ISMSユーザグループ／2022年12月16日） … 「ISO/IEC 27002 改定の解説」（土屋直子／NTTテクノクロス）で、8.28が新規であることと、その趣旨を確認しました
• 自治体情報システムの標準化・共通化（総務省） … 「地方公共団体情報システム標準化基本方針」で、カスタマイズを原則として行わないという記述を確認しました。読んだのは令和6年12月の版です。改定が続いているため、一覧ページから最新版を開いてください
• 岡田敏靖『ISO27001:2022の規格と審査がしっかりわかる教科書 改訂2版』（技術評論社） … 連載で使っている教科書です。35節（A.8）のうちA.8.25〜A.8.34の説明を読みました。2013年版の番号は、付録の対応表（27002:2022の附属書Bをもとに作成、と注記あり）から引いています

引っかかった点

パッケージを変更するときの考慮事項の置き場所が、教科書と管理基準で違いました。教科書はA.8.32 変更管理の中に「パッケージソフトウェアの変更管理」として置いています。管理基準では、同じ5つの事項がA.8.28 セキュリティに配慮したコーディングの細目にありました。付録の対応表では、2013年版の14.2.4はA.8.32へ移っています。管理策の番号の行き先と、手引の中身の置き場所が分かれたのかもしれません。2013年版の本文と27002:2022の本文を手元で照らせていないため、ここは推測にとどめます。

A.8.29の独立した受入れテストの範囲も違って見えました。教科書は、組織内で開発したものと外部委託したものの両方に、独立した受入れ試験を行うと説明しています。管理基準の細目は、組織内で開発するソフトウェアのテストの順番として、開発チームの次に独立した受入れテスト、と書いていました。外部委託や購入した部品は、取得の手順に従うという別の項目です。記事では管理基準の書き方で書きました。

教科書のA.8.30の説明には、適用される法令の順守と管理の効率の検証について、組織が責任を負う、という項目がありました。管理基準のA.8.30の細目では、対応する項目は「適用される法令の考慮」まででした。責任の所在を書いた文は、見つけられていません。記事には入れていません。

教科書のA.8.25の説明では、リポジトリを、仕様・デザイン・ソースコード・テスト情報・インシデント情報などを一元的に貯める場所としていました。管理基準の細目は「ソースコード及び構成ファイルのための」リポジトリです。教科書の説明は、解説として範囲を広げたものだと読みました。

2013年版のA.14.1.2〜A.14.3.1、A.12.1.2、A.12.1.4、A.12.7.1の管理策名は、手元の資料で確かめられていません。記事では番号だけを書きました。