ISMSの管理策とは？ISO 27001:2022附属書Aの93項目と選定手順を実務目線で解説

ISMSの管理策とは、情報セキュリティリスクを下げるためにISO/IEC 27001:2022の附属書Aへ整理された具体的な対策のことです。この記事では、管理策と要求事項の違い、2022年改訂で114項目から再編された93管理策の一覧と4カテゴリの全体像、新設された11の管理策、そしてリスクアセスメントから適用宣言書（SoA）に落とし込む選定手順までを、実務目線でまとめます。移行期限が終わった現在に新規取得や再認証で押さえるべき論点まで一気に確認できます。

まとめ｜ISMSの管理策はリスクで選ぶ93項目という結論と次の一手

ISMSの管理策は、ISO/IEC 27001:2022附属書Aに整理された全93項目の情報セキュリティ対策です。最大の要点は、93項目をすべて導入するのではなく、自社のリスクアセスメント結果に基づいて必要なものを選び、適用宣言書（SoA）で採否と理由を示す点にあります。2022年改訂で管理策は114項目から93項目へ再編され、組織的37・人的8・物理的14・技術的34の4カテゴリと、新設11項目に整理されました。

移行期限だった2025年10月31日はすでに過ぎているため、これから取得する企業は2022年版（日本語版はJIS Q 27001:2023）を前提に進めます。次の一手は、自社の情報資産とリスクを棚卸しし、附属書Aと突き合わせてSoAを作るところから着手することです。各管理策の中身や選定の進め方、運用での落とし穴は、以下の各章で根拠とともに掘り下げます。

ISMSにおける管理策の意味と要求事項・CIAとの関係をやさしく整理

まず管理策が何を指すのか、似た用語との関係を押さえておくと、後の選定や運用でつまずきにくくなります。

管理策とは情報セキュリティリスクを下げる具体的な手段という定義

管理策（control）とは、情報セキュリティのリスクを修正するための具体的な手段を指します。英語では「control」で、日本語規格のJIS Q 27001:2023では「管理策」と訳されています。たとえば「アクセス権を必要最小限に絞る」「持ち出し端末を暗号化する」といった、現場で実際に動く対策の一つひとつが管理策です。抽象的な方針ではなく、リスクに対して「何をするか」を定めた打ち手である点が特徴になります。ISMSでは、リスクアセスメントで洗い出した脅威に対し、どの管理策で対応するかを決めていきます。つまり管理策は、リスクと現場の運用をつなぐ接点として位置づけられます。

要求事項（箇条4〜10）と附属書Aの管理策の役割分担と違い

ISO/IEC 27001は大きく「本文の要求事項（箇条4〜10）」と「附属書Aの管理策」に分かれます。要求事項はISMSという仕組みそのものを回すためのルールで、組織の状況把握、リーダーシップ、リスクアセスメント、内部監査、マネジメントレビューなどが該当します。これらは認証を受けるうえで必須です。一方、附属書Aの管理策は、要求事項のリスク対応プロセスで「使う候補」として参照する対策集にあたります。要求事項が「ISMSをどう運営するか」という骨格なら、管理策は「具体的に何で守るか」という中身です。要求事項は全項目が必須、管理策はリスクに応じて取捨選択する、という適用の差が両者を分ける最大のポイントになります。

機密性・完全性・可用性（CIA）と管理策のつながり

情報セキュリティは、機密性（Confidentiality）・完全性（Integrity）・可用性（Availability）の3要素、いわゆるCIAを守ることを目的とします。管理策は、このCIAのどれを、どの脅威からどう守るかを具体化したものです。たとえば暗号化は主に機密性を、改ざん検知やバックアップは完全性や可用性を高めます。ある管理策が複数の要素にまたがることも珍しくありません。選定の際にも「この管理策はCIAのどれを守るのか」を意識すると、自社のリスクとの対応づけが明確になり、過不足の判断がしやすくなります。CIAは管理策を読み解くときの共通のものさしとして機能します。

附属書AとISO/IEC 27002:2022の関係と管理策の参照元

附属書Aの93管理策は、ISO/IEC 27002:2022の箇条5〜8に規定された内容がそのまま取り入れられており、両規格は整合が保たれています。違いは詳しさです。27001の附属書Aは管理策の「名称と概要」を示すのに対し、27002は各管理策の目的、実装の手引き、考慮点まで踏み込んで解説します。実務では、附属書Aで「どの管理策を採用するか」を判断し、ISO/IEC 27002を「どう実装するか」のガイドとして併読するのが効率的です。規格書を読み込む際は、27001で全体像をつかみ、迷ったら27002で具体策を確認する、という二段構えを覚えておくと作業がスムーズになります。

管理目的の言及廃止と属性の導入という2022年版の考え方

2013年版では各管理策に「管理目的（control objective）」が紐づいていましたが、2022年版では管理目的への明示的な言及が削除されました。代わりにISO/IEC 27002:2022では、各管理策に「属性（attributes）」という分類軸が導入されています。属性は、管理策のタイプ（予防・検知・是正）、情報セキュリティ特性（CIA）、サイバーセキュリティ概念、運用機能などのタグで、目的に応じて管理策を横断的に絞り込めるようにする仕組みです。認証取得そのものに属性の使用は必須ではありませんが、自社の対策を整理・分析する道具として活用できます。2013年版から移ってきた担当者は、この考え方の変化を押さえておくと違和感なく読み進められます。

ISO 27001:2022附属書Aで再編された4カテゴリ93管理策の全体像

2022年版の附属書Aは、4つのカテゴリに93の管理策を配置する構成です。それぞれが何を対象にしているかを押さえると、自社のどこに効く対策なのかが見えてきます。

組織的管理策37項目が担う方針・体制・サプライヤ管理の範囲

組織的管理策（番号5.x）は37項目あり、4カテゴリで最も多くを占めます。情報セキュリティ方針の策定、役割と責任の割り当て、資産の管理、アクセス制御の方針、サプライヤ関係のセキュリティ、インシデント管理、事業継続といった、組織の仕組みやルールに関わる対策が中心です。技術や設備というより「誰が・どんな方針で・どう管理するか」を定める層と捉えると分かりやすくなります。たとえば委託先の管理（5.19〜5.22）は、近年のサプライチェーン経由の事故を踏まえて重視される領域です。37項目と数が多いため、自社の体制図や既存規程と照らしながら、抜けている統制を探す使い方が現実的です。

人的管理策8項目が定める雇用ライフサイクル全体の統制

人的管理策（番号6.x）は8項目で、4カテゴリの中では最少です。採用時の選考（6.1）、雇用契約での責任の明確化、入社後の教育・訓練、懲戒手続、そして退職・異動時の権限の見直しまで、従業員の雇用ライフサイクル全体をカバーします。人はセキュリティの最も弱い環であると同時に最前線の守り手でもあるため、「人」に着目した対策が一群として独立しています。項目数は少ないものの、リモートワーク（6.7）や秘密保持契約（6.6）など、働き方の変化に直結するものが含まれます。教育記録や誓約書の整備など、運用の証跡を残しやすい領域でもあり、審査でも確認されやすい部分です。

物理的管理策14項目が守る施設・装置・媒体のリスク低減

物理的管理策（番号7.x）は14項目で、オフィスやサーバ室、装置や記憶媒体への物理的な脅威に対応します。物理的セキュリティ境界の設定、入退室管理、装置の設置・保守、記憶媒体の取り扱い、クリアデスク・クリアスクリーンなどが含まれます。2022年版では「物理的セキュリティの監視（7.4）」が新設され、監視カメラや侵入検知センサー、警備員の配置などで施設への不正アクセスを継続的に監視することが求められるようになりました。クラウド中心の企業でも、本社や拠点の入退室、放置された書類や端末といった物理リスクはゼロにはなりません。自社で守るべき物理的資産がどこにあるかを起点に検討すると過不足が判断しやすくなります。

技術的管理策34項目が扱うアクセス制御・暗号・監視の範囲

技術的管理策（番号8.x）は34項目で、情報システムやネットワークの利用、開発、運用に関わる対策をまとめています。認証とアクセス制御、暗号の利用、マルウェア対策、技術的脆弱性の管理、ログによる監視、バックアップ、セキュアな開発などが代表例です。たとえば「セキュリティを保った認証（8.5）」では、多要素認証やシングルサインオンの適切な実装が論点になります。社外のID基盤と連携する場合は、OpenID Connect（OIDC）による認証連携の仕組みを理解しておくと、何をどう守るかの設計がしやすくなります。技術的管理策は最も実装の幅が広く、自社のシステム構成によって必要な項目が大きく変わる領域です。

5.x〜8.xの番号体系と93管理策を俯瞰する読み解き方

93の管理策は、カテゴリごとに5.x（組織的）、6.x（人的）、7.x（物理的）、8.x（技術的）と番号が振られています。番号の頭を見れば、その管理策がどの観点の対策かが一目で分かる仕組みです。全体像を数で押さえると、自社の現状とのギャップ分析がはかどります。

この表を骨組みにして、自社で運用済みの対策をカテゴリへ振り分けていくと、どの群が手薄かが見えてきます。

114項目から93項目へ｜2022年改訂で統合された管理策と新設11項目

2013年版を知る人ほど気になるのが、何がどう変わったのかという点です。改訂のポイントを数と中身の両面で整理します。

14カテゴリ114項目から4カテゴリ93項目への再編の全体像

2013年版の附属書Aは14カテゴリ・114項目という構成でした。2022年版ではこれが4カテゴリ・93項目へと再編されています。項目数が減ったのは、似た管理策を統合したためで、対策の範囲が縮小したわけではありません。カテゴリも、対策のタイプ別に細かく分かれていた14分類から、組織的・人的・物理的・技術的という4つの大きな側面へまとめ直されました。これにより、どの観点の対策かを直感的につかみやすくなっています。移行作業では、旧版の番号と新版の番号が一対一で対応しない箇所があるため、新旧対比表を使って自社のSoAを更新する作業が欠かせません。数の変化に惑わされず、中身の対応関係を追うことが重要になります。

新規11・統合24・更新58で削除ゼロという内訳の意味

93項目の内訳は、新規追加が11項目、複数の旧管理策を一つにまとめた統合が24項目、内容が見直された更新が58項目で、削除された管理策は一つもありません。削除ゼロという事実は、2013年版で求められていた対策の考え方が引き続き必要であることを意味します。つまり改訂は「やめてよくなった」ではなく「整理し直して新しい脅威に対応した」ものです。既存の認証組織にとっては、統合された24項目で番号と紐づけを付け替え、新設11項目の要否を判断し、更新58項目で記述の変化を確認する、という三方向の点検が必要になります。新規取得を目指す企業は最初から93項目を前提にできるため、この移行特有の手間は発生しません。

脅威インテリジェンスやクラウドなど新設11管理策の具体名

2022年版で新たに加わった11の管理策は、いずれも近年のサイバー脅威やIT利用の変化を反映しています。これらは既存運用組織にとって「適用するか」を改めて検討すべき項目であり、新規取得組織もリスクに応じて要否を判断します。具体的には次の11項目です。

• 5.7 脅威インテリジェンス
• 5.23 クラウドサービスの利用のための情報セキュリティ
• 5.30 事業継続のためのICTの備え
• 7.4 物理的セキュリティの監視
• 8.9 構成管理
• 8.10 情報の削除
• 8.11 データマスキング
• 8.12 データ漏えい防止（DLP）
• 8.16 監視活動
• 8.23 ウェブフィルタリング
• 8.28 セキュアコーディング

クラウド利用やログ監視、開発時のセキュリティなど、現在の事業で実際に直面しやすい領域が並んでいる点が特徴です。

移行期限2025年10月31日の終了と現在の認証取得の前提

ISO/IEC 27001:2022は2022年10月に発行され、認証組織の移行期限は発行月末から3年後の2025年10月31日と定められていました。この期限はすでに到来・終了しています。そのため2026年時点では、認証を維持・取得するすべての組織が2022年版に基づいて運用しているのが前提です。新規に認証を取る企業は、旧版（2013年版）の初回審査が終了しているため、最初から2022年版で取得することになります。すでに移行を終えた組織は、以降の維持審査や再認証審査の中で、選定し直した管理策とSoAが実態に合っているかを問われます。移行は終点ではなく、新しい管理策体系を前提にした運用の出発点だと捉えるのが実務的です。

JIS Q 27001:2023と2024年の気候変動追補という最新の論点

日本語版の規格は、翻訳作業を経て2023年9月にJIS Q 27001:2023として発行されました。英語版が2022年版、日本語版が2023年版と年号が異なりますが、内容は同一の規格です。社内文書や審査の文脈でどちらの表記が使われても、同じものを指していると理解しておけば混乱を避けられます。加えて2024年2月には、ISOのマネジメントシステム規格に共通する追補として「気候変動への配慮」が加わりました。これは環境活動を強制するものではなく、気候変動が自社の課題に関係するかを検討し、そのプロセスを記録として残すことを求める内容です。管理策そのものの変更ではありませんが、組織の状況把握（箇条4）に関わる最新の論点として押さえておくとよいでしょう。

リスクアセスメントから適用宣言書（SoA）まで管理策を選ぶ3ステップ

管理策は一覧を眺めて終わりではなく、自社に必要なものを選び抜く作業が本番です。選定の流れを3つのステップで具体化します。

管理策は全項目を実施せずリスクベースで取捨選択するという原則

附属書Aの93項目は、すべてを必ず実施する義務リストではありません。あくまでリスク対応で漏れがないかを確認するためのベンチマーク（参照集）です。自社のリスクアセスメント結果に照らし、必要な管理策を選び、不要と判断したものは除外できます。重要なのは、採用も除外もリスクに基づいた合理的な説明ができることです。この原則を取り違えて93項目を機械的に全採用すると、運用が現場に合わず形だけの対策になりがちです。逆に根拠なく多くを除外すると、審査で妥当性を問われます。「全部やる」でも「都合よく省く」でもなく、リスクで判断するという軸が選定全体を貫きます。具体的な進め方は、次の3ステップに分解できます。

1. 情報資産を洗い出し、リスクアセスメントを実施する
2. 附属書Aと照合し、必要な管理策を特定する
3. 適用宣言書（SoA）に採否と理由を文書化する

ステップ1：情報資産の洗い出しとリスクアセスメントの実施

最初に、自社が守るべき情報資産を洗い出します。顧客データ、ソースコード、契約書、業務システム、従業員情報など、形式を問わず棚卸しすることが出発点です。次に、それぞれの資産に対する脅威と脆弱性を洗い出し、起こりやすさと影響度からリスクの大きさを評価します。たとえば「顧客個人情報が外部に漏えいする」リスクなら、発生可能性と漏えい時の損害を見積もります。この段階で管理策の話を先に持ち出すと、対策ありきの分析になりがちなので、まずはリスクの実態を素直に把握することが肝心です。評価の基準（リスク受容水準）をあらかじめ決めておくと、後のステップで「どこまで対策するか」の判断が一貫します。リスクアセスメントの質が、選定全体の精度を左右します。

ステップ2：附属書Aと照合し必要な管理策を特定する作業

洗い出したリスクごとに、どう対応するかを決めます。対応の選択肢は、低減・回避・移転・受容の4つです。このうち「低減」を選んだリスクに対して、附属書Aの93管理策から有効なものを当てはめていきます。たとえば「ノートPCの紛失による情報漏えい」というリスクには、装置の管理（7.x）や暗号の利用（8.24）、アクセス制御（8.x）といった管理策が候補になります。一つのリスクに複数の管理策が対応することも、一つの管理策が複数のリスクをカバーすることもあります。ここで附属書Aを順に確認することで、自社で見落としていた対策に気づけます。リスクと管理策の対応表を作っておくと、後の説明責任を果たしやすく、運用の見直し時にも再利用できます。

ステップ3：適用宣言書（SoA）で採否と除外理由を文書化する手順

選定の結論を文書にまとめたものが適用宣言書（SoA：Statement of Applicability）です。SoAには、93すべての管理策について「適用するか・しないか」を明記し、適用する場合は実施状況を、適用しない場合はその理由を記載します。たとえば自社で開発を行っていない企業が「セキュアコーディング（8.28）」を除外する場合、「自社開発が存在しないため」といった具体的な理由を残します。SoAは認証審査で必ず確認される中核文書であり、リスクアセスメントの結果と一貫していることが求められます。管理策の番号が114項目時代から変わっているため、旧版から移行した組織は新版の番号体系でSoAを作り直す必要があります。SoAは一度作って終わりではなく、リスクや事業の変化に応じて更新していく生きた文書です。

新設11管理策の適用可否を検討するときの判断基準

新設された11管理策は、適用するかどうかを特に丁寧に検討すべき項目です。判断のものさしは、自社の事業実態とリスクにそのテーマが当てはまるかどうかにあります。たとえばクラウドサービスを業務で使うなら「クラウドサービスの利用のための情報セキュリティ（5.23）」は適用が自然です。一方、Web経由の脅威にさらされる業務が限定的なら「ウェブフィルタリング（8.23）」の重み付けは下がるかもしれません。ただし「面倒だから除外」は通用せず、除外するならリスク上の根拠が要ります。多くの企業に共通して関係しやすいのは、構成管理（8.9）、監視活動（8.16）、情報の削除（8.10）あたりです。迷ったら、その管理策が守るリスクが自社に存在するかへ立ち返ると、採否の判断がぶれにくくなります。

管理策の運用と有効性評価｜形骸化を避け審査で説明できる状態の作り方

選んだ管理策は、運用して初めて意味を持ちます。文書だけが立派で実態が伴わない状態をどう避けるかが、認証維持の分かれ目です。

文書化だけで終わる形骸化が起きる典型パターンと回避策

管理策が形骸化する典型は、規程は整っているのに現場が実行していないケースです。たとえば「アクセス権は定期的に見直す」と規程にあるのに、実際の棚卸しが一度も行われていない、といった状態です。原因の多くは、担当者任せで運用の証跡（記録）を残す仕組みがないことにあります。回避策は、管理策ごとに「誰が・いつ・何を記録するか」を運用ルールへ落とし込むことです。アクセス権レビューなら、四半期ごとに一覧を出力し、承認の記録を残す、といった具合に手順と頻度を明示します。証跡が自然にたまる仕組みにしておくと、運用と審査対応が同時に進みます。立派な文書を作ることより、無理なく続く運用を設計することが形骸化を防ぎます。

管理策の有効性を測る指標とレビューの回し方

ISO/IEC 27001は、情報セキュリティ目的の達成度を監視・測定することを求めています。管理策単位でも、効いているかどうかを測る視点が有効です。たとえばマルウェア対策なら検知・駆除件数、教育なら受講率や標的型メール訓練の開封率、脆弱性管理なら未対応の脆弱性が放置されている日数などが指標になります。数値を継続的に追うことで、対策が機能しているか、悪化していないかが見えてきます。指標は欲張らず、管理策の効果が現れやすいものを少数選ぶのが現実的です。集めた数値はマネジメントレビューの材料となり、改善のサイクル（PDCA）を回す根拠になります。測れないものは管理できない、という前提で運用設計を考えると、有効性評価が形だけになりにくくなります。

技術的脆弱性の管理（8.8）を例にした運用の実際

技術的管理策の中でも運用負荷が高いのが「技術的脆弱性の管理（8.8）」です。これは、自社が使うソフトウェアやライブラリの脆弱性情報を収集し、影響を評価し、必要な対応を行う一連の活動を指します。実際には、製品の脆弱性が公表されるたびに「自社で使っているか」「影響範囲はどこか」「いつまでに修正するか」を判断します。たとえば7-Zipで公表された脆弱性への対応事例のように、広く使われるツールでも深刻な脆弱性が見つかることがあり、利用有無の把握とパッチ適用の段取りが問われます。脆弱性管理は、資産台帳・情報収集の経路・対応のSLAをあらかじめ決めておくと、いざ公表されたときに慌てずに動けます。属人化させず、手順として回すことが運用の鍵です。

内部監査とマネジメントレビューで管理策を点検する観点

運用した管理策は、内部監査とマネジメントレビューで定期的に点検します。内部監査では、SoAで適用とした管理策が実際に運用され、証跡が残っているかを現場目線で確認します。ここで重要なのは、規程との一致だけでなく「効いているか」まで見ることです。マネジメントレビューでは、内部監査の結果や有効性指標、インシデントの発生状況などを経営層が確認し、リソース配分や改善方針を決めます。両者は、現場の点検（内部監査）と経営の意思決定（マネジメントレビュー）という役割分担で連動します。点検で見つかった不備は、是正処置として記録し、原因まで掘り下げて再発を防ぎます。この一連の流れが回っていることが、管理策を生かし続ける土台になります。

審査員に管理策の妥当性を説明するための準備

認証審査では、選んだ管理策が自社のリスクに照らして妥当か、そして実際に運用されているかが問われます。審査員に説明しやすい状態とは、リスクアセスメント、SoA、運用記録の三つが一本の線でつながっている状態です。「このリスクがあるから、この管理策を適用し、こう運用し、こう記録している」と一気通貫で示せれば、説明は明快になります。逆に、SoAでは適用としているのに記録が見当たらない、除外理由が抽象的、といったズレは指摘の対象になりがちです。準備としては、主要なリスクごとに対応する管理策と証跡をひとまとめにしておくと、当日の応対がスムーズです。審査を「説明の場」と捉え、日頃の運用記録をそのまま見せられるよう整えておくことが、最も確実な対策になります。

移行完了後の2026年に押さえるISMSの管理策の新規取得と再認証の論点

移行期限が終わった現在は、これから取得する企業と既存の認証組織とで、管理策との向き合い方が分かれます。立場別の論点を整理します。

移行が完了した現在に新規取得する企業が前提とすべき規格

これからISMS認証を取得する企業は、ISO/IEC 27001:2022（日本語版はJIS Q 27001:2023）を前提に進めます。旧版での初回審査は受け付けが終了しているため、選択の余地はありません。新規取得組織にとっては、114項目から93項目への移行という作業が発生しない分、最初から4カテゴリ93管理策の体系で設計できる利点があります。一方で、新設11管理策を含む最新の対策を前提に、リスクアセスメントとSoAを一から組み立てる必要があります。取得を急ぐ場合でも、情報資産の棚卸しとリスク評価を省かずに行うことが、後の運用と審査を楽にします。最新版前提という出発点は、むしろ余計な過去の互換性に悩まずに済むという意味で、新規組織には有利に働きます。

既存認証組織が再認証・維持審査で管理策を見直す観点

すでに2022年版へ移行した組織にとって、管理策の見直しは移行で完結したわけではありません。再認証審査（通常3年ごと）や毎年の維持審査の中で、選定した管理策が現在の事業実態に合っているかが継続的に問われます。事業の拡大、新規システムの導入、働き方の変化があれば、リスクの姿も変わり、必要な管理策も変わります。たとえば新たにクラウドサービスを採用したなら、5.23の適用状況を見直すべきタイミングです。見直しの起点は、変化したリスクとSoAの記載がずれていないかの確認にあります。移行直後のSoAを固定的に運用し続けると、実態と乖離していきます。年に一度はリスクと管理策の対応を棚卸しし、SoAを更新する習慣をつけると、審査でも実運用でも齟齬が生じにくくなります。

クラウド利用に効くISO/IEC 27017など関連規格との使い分け

クラウドサービスを多用する企業では、ISO/IEC 27001の管理策に加えて、クラウド固有の管理策を定めたISO/IEC 27017の併用が選択肢になります。27017は、クラウド事業者と利用者の双方を対象に、責任分界や仮想環境の分離といったクラウド特有の論点を補う規格です。27001の5.23（クラウドサービスの利用）で大枠を押さえつつ、より踏み込んだ統制が必要なら27017を参照する、という使い分けが現実的です。同様に、個人情報の取り扱いに重きを置くならISO/IEC 27018なども関連します。すべてを取得する必要はなく、自社のリスクと事業特性に応じて、基盤となる27001にどの規格を足すかを判断します。関連規格は、27001の管理策を補完する「拡張パーツ」として捉えると整理しやすくなります。

ISMSとプライバシーマークの管理策の違いと選び方

情報を守る認証として、ISMS（ISO/IEC 27001）とプライバシーマーク（Pマーク）はよく比較されます。両者は守る対象が異なります。ISMSは情報資産全般のセキュリティを対象とし、リスクに応じて管理策を選ぶ柔軟な仕組みです。一方Pマークは、個人情報の保護に特化し、JIS Q 15001という国内規格に基づきます。管理策の考え方も、ISMSがリスクベースで取捨選択するのに対し、Pマークは個人情報の取り扱いに沿った要求事項への適合を重視します。自社が守りたいのが個人情報中心か、情報資産全般かで選ぶのが基本です。両方取得する企業もありますが、その場合は重複する運用を整理して二重管理を避ける工夫が要ります。プライバシーマーク（Pマーク）の概要と取得の流れとあわせて比較すると、自社に合う認証が判断しやすくなります。

中小企業が限られた工数で管理策の優先順位を決める考え方

専任の担当者を置きにくい中小企業では、93管理策にすべて同じ熱量で取り組むのは現実的ではありません。優先順位の決め手は、リスクの大きさと、対策にかかる手間のバランスです。発生したときの損害が大きく、かつ低コストで効果が出る管理策から着手すると、限られた工数で守りを固められます。たとえばアクセス権の最小化、多要素認証の導入、バックアップの定期取得などは、比較的少ない手間で広いリスクをカバーできます。逆に、自社にほとんど関係しないリスク向けの管理策に時間をかけるのは非効率です。SoAで除外を明確にすれば、やらない判断も正当化できます。最初から完璧を目指さず、リスクの高い領域から段階的に整える進め方が、無理なく続く運用につながります。

よくある質問

ISMSの管理策について、検索でよく寄せられる疑問とその答えを簡潔にまとめます。

ISMSの管理策と要求事項の違いは何ですか？

要求事項はISO/IEC 27001本文の箇条4〜10に定められ、ISMSという仕組みを運営するための必須のルールです。リスクアセスメントや内部監査、マネジメントレビューなどが該当します。一方、管理策は附属書Aに整理された具体的な対策集で、リスク対応の中から自社に必要なものを選んで適用します。要求事項は全項目が必須、管理策はリスクに応じて取捨選択する点が最大の違いです。要求事項が「ISMSをどう回すか」の骨格、管理策が「何で守るか」の中身、と整理すると分かりやすくなります。

ISMSの管理策は何項目ありますか？

最新のISO/IEC 27001:2022（日本語版JIS Q 27001:2023）では、附属書Aに全93項目の管理策が定められています。内訳は組織的管理策37、人的管理策8、物理的管理策14、技術的管理策34の4カテゴリです。2013年版では14カテゴリ・114項目でしたが、似た管理策の統合により93項目へ再編されました。新規追加は11項目、統合24項目、更新58項目で、削除された管理策はありません。「114項目」という数字は旧版のものなので、現在の取得・運用では93項目を前提に考えます。

附属書Aの管理策はすべて実施する必要がありますか？

いいえ、すべてを実施する必要はありません。附属書Aは、対策に漏れがないかを確認するための参照集（ベンチマーク）であり、義務リストではありません。自社のリスクアセスメント結果に基づき、必要な管理策を選定し、適用しないものは適用宣言書（SoA）でその理由を記載します。ただし、採用も除外もリスクに基づいた合理的な説明ができることが前提です。根拠なく多くを除外すると、審査で妥当性を問われます。「全部やる」ではなく「リスクで選ぶ」が基本姿勢になります。

ISMSにおける物理的管理策とは何ですか？

物理的管理策（番号7.x）は、オフィスやサーバ室、装置、記憶媒体への物理的な脅威に対応する14項目の管理策です。物理的セキュリティ境界の設定、入退室管理、装置の保守、記憶媒体の取り扱い、クリアデスク・クリアスクリーンなどが含まれます。2022年版では「物理的セキュリティの監視（7.4）」が新設され、監視カメラや侵入検知などで施設への不正アクセスを継続的に監視することが求められます。クラウド中心の企業でも、拠点の入退室管理や書類・端末の放置対策など、物理リスクへの備えは必要です。

ISO 27002やISO 27017は管理策とどう関係しますか？

ISO/IEC 27002:2022は、27001附属書Aの各管理策について、目的や実装の手引きまで詳しく解説したガイド規格です。附属書Aで「何を採用するか」を判断し、27002で「どう実装するか」を確認する、という併読が効率的です。ISO/IEC 27017は、クラウドサービスに特化した管理策を補う規格で、27001の5.23（クラウド利用）をより踏み込んで統制したい場合に参照します。いずれも27001を土台に補完する位置づけで、自社のリスクと事業特性に応じて必要なものを組み合わせて使います。

関連記事

• Microsoft Authenticatorの概要と多要素認証（MFA）の基礎：技術的管理策の「セキュリティを保った認証（8.5）」を実装面から理解するための補足記事です。