ISO 27001とは：認証取得より先に決めること

ISO/IEC 27001は、情報セキュリティマネジメントシステム（ISMS）の要求事項を定めた国際規格です。 ISMSは「対象業務のリスクを評価し、対策の責任者・実施・評価・改善を継続する仕組み」です。ISO/IEC 27002は管理策の実施指針で、27002自体を認証規格として案内しません。

対象読者は、取得を検討する経営・情シス担当、SaaSの調達担当、監査へ記録を提出する開発・運用担当です。取引条件に認証が必要なら認証範囲を先に確認し、運用改善が目的なら自社の高影響業務からリスクと責任分担を整理します。 認証取得は、規格に沿って改善することとは別の選択です。

最初の実務にはSaaS権限棚卸しチェックリストを使い、承認・権限反映・実際のアクセス確認を分けて記録してください。認証マークの有無だけで、利用者側の確認を省略しないためです。

資料確認：2026年10月26日／CyberLens編集部

ISOの規格概要・認証案内と、ISO/IEC JTC 1/SC 27の公開解説を照合して改訂しました。2024年追補の存在も確認しています。規格本文を転載するものではなく、認証審査・組織の適合性評価・専門家監修は実施していません。正式な要求は適用する規格本文と認証機関の案内で確認してください。

  • 1｜範囲と要求

    業務・情報・関係者・法令や契約の条件を揃え、何を守るか決める。

  • 2｜必要な管理策

    リスク対応を選び、附属書Aとの照合と適用宣言書へ判断を残す。

  • 3｜実施と証跡

    担当者が実施し、設定だけでなく利用・復旧・制限の結果も確認する。

  • 4｜評価と改善

    内部監査・経営層の見直し・是正の結果を、次のリスク評価へ戻す。

図：範囲・リスク・実施・見直しをつなぐ運用例。認証取得までの期間や合格を保証する図ではありません。

ISMS認証の範囲と確認方法：会社全体の安全保証ではない

認証は外部の認証機関が行い、ISO自身が企業へ認証書を発行する仕組みではありません。取引先の確認では、認証書にある法人・部門・業務・拠点、適用規格、期限、発行機関を照合します。部署単位の範囲を会社の全サービスへ広げて説明しないでください。

調達・監査の確認例。証明書だけで侵害がないことを保証する表ではありません。
判断対象確認すること不足するときの対応
認証範囲利用するサービス・部門・拠点が対象に入るか。認証書の版・期限・発行機関も確認。提供者に対象範囲の説明を求める。未確認を認証済みと記入しない。
利用者の設定自社の管理者、退職者、ゲスト、アプリ同意、共有設定。SaaS管理者が権限と実際の反映を点検する。
委託の境界提供者と利用者の管理責任、事故連絡、証跡の取得可能性。契約・運用窓口・ログ確認方法を揃える。責任を丸ごと移転したと扱わない。
運用の効果必要な管理策が動作し、失敗・未確認・是正が記録されているか。設定を保存した記録だけで完了にせず、対象業務の確認結果を残す。

2022年版の93管理策と、2024年追補の確認

2022年版に対応する管理策は、組織的37、人的8、物理的14、技術的34の計93に整理されています。ISO/IEC 27002の編集者による公開解説は、以前の114からの統合と11管理策の追加を説明しています。これは「管理策数が減ったので自社の対策も減らす」という意味ではありません。

2026年10月26日のISO公式カタログでは、2022年版と、気候変動への対応に関するAmd 1:2024を確認できます。2022年版だけを参照した古い資料で確認を終えず、適用する追補も照合します。業務では、災害による電力・拠点・委託先の利用不能など、組織の状況に関係するリスクを検討し、関連の有無と根拠を記録します。この例は一律の追加設備・製品購入義務を定めるものではありません。

附属書Aは全製品を買うリストではない

テーマ実務で確認すること誤解しないこと
クラウド提供者との責任分担、権限・共有・変更・終了時の管理。CSPM製品を買えばクラウド管理が完了するわけではない。
情報流出情報の分類、持ち出し経路、アクセス制御、検知・教育の組み合わせ。DLPという特定製品を全組織に一律導入する説明にしない。
安全な開発開発手順、設計レビュー、コードレビュー、検証結果と修正記録。SASTを通せばすべての脆弱性がなくなるわけではない。
事業継続重要業務の依存先、必要な復旧条件、訓練と結果の見直し。バックアップを取った記録と、復旧できた結果は別に確認する。

適用宣言書（SoA）の作り方：必要性・実施・除外を分ける

適用宣言書は、必要な管理策、採用理由、実施状況、附属書Aから除外する理由を追える文書です。 自社のリスク対応で必要な管理策を決め、附属書Aと照合して見落としを確認します。附属書Aにない独自の管理策や、外部提供者が実施する必要な管理策も確認対象です。公開解説は補助資料であり、規格本文と同じ位置付けにはしません。

  1. 対象業務、情報、関係者の要求、想定する問題を整理する。
  2. 問題を許容できるか評価し、必要な対応と管理策を決める。
  3. 附属書Aと照合し、採用・実施・除外の理由を別々に残す。
  4. 担当者、期限、証跡の保管先、効果の確認方法を対応計画へつなぐ。

次は編集部作成の架空例です。規格が指定する様式や、認証に合格した組織の実績ではありません。機密の台帳をこのサイトへ入力せず、社内の管理先で使ってください。

記録欄SaaS権限レビューの記入例
リスク・範囲退職者の外部共有アクセスが残る。対象は営業部の顧客資料SaaS
必要な管理策退職・異動時の権限反映確認と、例外の再レビュー
採用理由顧客情報への継続アクセスを制限し、契約上の条件を満たすため
実施状況管理者の変更は完了。対象SaaSのアクセス確認が一部未完了
担当・期限SaaS管理者と業務所有者。社内承認した期限・確認日を記載
証跡・残件変更記録と確認結果の保管先。不明な委託先アクセスは調査継続

予算不足で未実施の必要な管理策を、「不要なので適用除外」と書き換えません。 残るリスクを誰がどの条件で引き受けるか、追加対策と期限を判断してください。セキュリティ例外申請の書き方を、承認と再確認の記録例として使えます。

リスク対応の判断：低減・回避・共有・受容

対応は組み合わせられます。下表は運用を理解する例で、個別の適合性判断ではありません。
選択選ぶ条件と例残る確認
低減高権限へのアクセスを絞り、変更・監視・復旧手順を改善する。対策後の残存リスクと、実際に効果があった根拠。
回避不要な機能・業務を停止し、その活動に伴うリスクを避ける。別の処理へ移した際の新たなリスクや契約条件。
共有委託や保険等でリスクの一部を分担する。委託先管理、免責・補償範囲、自社に残る責任。
受容承認された許容基準の下で、残るリスクを責任者が引き受ける。判断理由、責任者、見直す条件。法令・契約の義務を免除するものではない。

決済を外部へ委託して自社でカード番号を保持しなくしても、委託先管理、連携権限、取引情報のリスクは残ります。「外注だからすべて排除」「対策費が高いから何も記録しない」とは説明しません。

取得前・審査前のチェックリストと費用の見積条件

  • 対象範囲が契約・顧客への説明と一致し、範囲外の依存先も把握している。
  • リスク評価・対応計画・適用宣言書と、現場の実施記録が矛盾していない。
  • 内部監査、経営層による見直し、是正の担当と証跡を確認できる。
  • 新しいSaaS、委託先、拠点、重大な事故など、再評価する条件が決まっている。
  • 認証機関へ見積もる範囲、人数、拠点、業務の複雑さ、既存運用、希望する審査時期が揃っている。

一律の「取得費用○万円」「必ず○か月で取得」は置きません。 規格購入、社内整備の工数、外部支援、認証審査、維持・再審査を分け、同じ範囲・条件で見積もります。これは費目整理で、実際の料金表ではありません。

具体的な監視基盤の選定にはSIEMとSOARの違い・導入判断を使い、「製品を入れた」から「ログを確認し、対応と見直しを続ける」へ判断を進めてください。NIST CSF 2.0はリスク管理の整理に併用できますが、全組織に両方の認証・導入を義務付けるものではありません。

理解度チェック

必要と判断した管理策が予算不足で未実施です。適切な記録はどれですか？

実務・復習・保存へ