>
>
公開日
最終更新日
ISMS認証は、情報漏洩対策を整備していることを示すためだけの制度ではありません。自社にある情報資産を洗い出し、事業に影響するリスクを評価し、ルール・教育・監査を継続的に改善する管理の仕組みです。
特に情シス部門では、SaaSアカウント、共有ID、退職者の権限削除、委託先管理、生成AIへの入力情報など、日々の運用が審査の対象になります。認証取得を急ぐあまり、実務で守れないパスワード規程や過剰な台帳を作ると、取得後に運用が止まります。
本記事では、ISMS認証の制度と取得手順を説明したうえで、費用を見積もる前提条件、ISMSとPマークの使い分け、認証情報管理の実務、生成AIセキュリティのベストプラクティスをまとめます。社内稟議やプロジェクト計画に使えるチェックリストも掲載します。
読む優先順位の目安：取得を初めて検討している方は「ISMS認証とは」「取得の流れと期間」「費用と予算化」の順に読むと制度と費用感を把握できます。PマークやクラウドISMSとの比較が必要な方は「ISMSとPマークの違い」へ、すでに取得済みで運用の見直しをしたい方は「維持管理と失敗パターン」「実務チェックリスト」が参照先です。
ISMS認証とは
ISMS認証とは、組織が構築・運用する情報セキュリティマネジメントシステムがISO/IEC 27001に適合していることを、認証機関が審査して登録する制度です。
本記事のポイント
ISMS認証は、情報資産の機密性・完全性・可用性を、リスクに応じて管理する仕組みです。
旧ISO/IEC 27001:2013に基づく認証から2022年版への移行期限は、2025年10月31日でした。
ISMS-ACは、2026年8月31日時点の国内ISMS登録数を8,669件と公表しています。
取得後の成否は、文書量ではなく、現場で守れるルールと証跡を維持できるかで決まります。
ISMSはInformation Security Management Systemの略で、日本語では情報セキュリティマネジメントシステムといいます。対象は個人情報だけではありません。顧客情報、営業資料、設計情報、ソースコード、契約書、会計データ、クラウド設定、端末、ネットワーク機器、認証情報など、事業に影響する情報資産を対象にします。
ISO/IEC 27001は、情報セキュリティの対策製品を指定する規格ではありません。組織の状況、利害関係者の要求、リスク評価の方法、対策の選定、教育、内部監査、経営層による見直しを一連の仕組みとして管理します。そのため、ウイルス対策ソフトやMFAを導入していても、資産の把握・責任者・運用記録がなければ、それだけでISMS認証に適合するとはいえません。
一般社団法人情報マネジメントシステム認定センター（ISMS-AC）は、認定した認証機関によるISMS認証登録数が2024年12月に8,000件を超えたと公表しました出典：ISMS-AC「ISMS認証登録数8000件超のお知らせ」2024年12月27日公開、。また、同センターは「ISMS登録数の推移」ページisms.jpで登録数の最新状況を随時公表しています。2022年9月以降の約2年3か月で約1,000件増えたという同センターの集計は、取引先審査や委託先評価で認証の提示を求める企業が増えている背景を示します。
ISO/IEC 27001:2022への移行
2022年版では、附属書Aの管理策が旧版の114項目から93項目に整理され、組織的・人的・物理的・技術的という4テーマに再編されました。
ISO/IEC 27001:2022は2022年10月25日に発行されました。ISMS-ACは、旧版からの認証移行期限を2025年10月31日と案内しています。2026年に新規認証または更新を受ける組織は、JIS Q 27001:2023を基準に適用範囲、リスクアセスメント、適用宣言書、運用記録を整備します。
93項目をすべて機械的に実装する必要はありません。附属書Aは管理策の参照集合であり、組織はリスクアセスメントの結果を踏まえて採否を決め、適用しない管理策は適用宣言書に理由を記録します。ただし、未適用の理由を「実施が面倒」「費用がかかる」だけにすると、リスク受容の妥当性を説明できません。
認証範囲とISMSマークの扱い
ISMS認証の適用範囲は、法人全体に限られません。特定の事業部門、拠点、サービス提供部門などを範囲として定められます。
範囲を定める際は、顧客との契約主体、情報を扱う拠点、開発・運用・サポートの担当部門、外部委託先との接点を確認します。たとえばSaaSサービス部門だけを範囲に含めても、人事部門がそのサービスの本番アカウントを管理しているなら、権限付与・退職処理の統制を範囲外として切り離せるとは限りません。
ISMSマークは、認証登録された組織が認証範囲を誤認させない形で使用する必要があります。営業資料やWebサイトに表示する場合は、認証登録番号、認証範囲、認証機関の表示ルールとの整合を取ります。「会社全体が認証済み」と受け取られる表現になるかは、適用範囲との関係で判断します。
ISMS認証の取得メリットと適用範囲
ISMS認証の主な効果は、取引先に説明できる管理体制を作り、情報セキュリティの責任分担を社内で明確にすることです。
認証があるだけで事故を防げるわけではありません。しかし、情報資産、業務プロセス、委託先、利用中のクラウドサービスを棚卸しし、リスクの評価と対策の責任者を定めることで、属人的な運用を減らせます。取引先からセキュリティチェックシートを受け取ったときにも、規程、台帳、教育記録、監査結果を根拠として回答しやすくなります。
総務省「令和8年版 情報通信白書」soumu.go.jpは、日本ネットワークセキュリティ協会が2017年1月〜2024年6月に実施した調査として、ランサムウェア感染被害組織の平均被害金額は約4,959万円と紹介しています。ISMSは、このような事故の損害額を保証する制度ではありません。一方で、バックアップ、アクセス制御、インシデント対応、委託先管理をリスクに応じて見直す枠組みになります。
認証取得が事業に与える効果
認証の効果は、営業上の信頼性と内部統制の整備に分けて考えると判断しやすくなります。
営業面では、入札参加資格、取引先の委託先評価、SaaS導入審査で、ISMS認証の有無を聞かれる場面があります。ただし、認証が必須か、同等の統制資料で代替できるかは、取引先の調達条件によって変わります。認証が条件として明記されているなら取得計画を優先し、明記されていないなら、現行のセキュリティ質問票と求められる証跡を分析してから範囲を決めます。
内部統制の面では、入社・異動・退職に伴うアカウント管理、クラウドサービスの契約管理、インシデント報告の連絡網、委託先の評価基準を文書化できます。経営層がリスク受容を判断する場を設ける点も、技術対策だけでは補いにくいISMSの特徴です。
国内企業の運用事例
実例では、認証取得のための作業を減らすことよりも、情報管理の見える化を運用成果として捉える企業があります。
タクミ商事株式会社は、ISMS・Pマークの運用支援ツールを導入した事例で、約50種類に及んでいた関連文書の作成業務をほぼなくしたとPR TIMESで公表していますprtimes.jp。この事例は、ツール導入そのものが認証を保証するものではなく、文書の重複を減らし、担当者の更新作業を整理した結果として捉えるべきです。自社に同様の課題がある場合は、現行文書を「規格上必要な記録」「社内統制に必要な台帳」「目的不明の重複資料」に分けてから移行対象を決めます。
株式会社彌満和製作所は、サプライチェーン・サイバーセキュリティ評価制度への対応とISMS取得を見据え、ファイル共有状況の可視化と共有の自動停止による情報ガバナンス強化を実施したと公表しています。ファイル共有は、パスワード規程だけでは管理できません。共有期限、外部共有の承認、退職者の権限停止、操作ログを、情報資産の重要度に応じて設計する必要があります。
クラウド利用と委託先管理
クラウドサービスを多用する組織では、自社の統制と委託先の統制を分けて評価します。
ISMSクラウドセキュリティ認証は、ISO/IEC 27017に基づくクラウドサービスに関する認証です。ISMS-ACは2024年3月に、その認証登録数が500件を超えたと公表しました出典：ISMS-AC「ISMSクラウドセキュリティ認証登録数500件超のお知らせ」。クラウドサービスを利用しているだけでISO/IEC 27017が必要になるわけではありませんが、クラウドサービス提供者として顧客データを処理し、契約上クラウド統制の説明を求められる場合は、通常のISMSとあわせて検討対象になります。
委託先評価では、認証書の有無だけで判断しません。扱う情報、再委託の有無、データ保存地域、インシデント通知期限、ログの提供範囲、契約終了時のデータ削除方法を確認します。認証が確認できれば評価を簡略化できる領域はありますが、委託する業務のリスクが高ければ個別評価を残します。
ISMS認証におけるパスワード・認証情報管理
ISMSにおけるパスワード管理は、定期変更を一律に強制することではなく、認証情報の発行から廃止までをリスクに応じて統制することです。
ISO/IEC 27001:2022の附属書Aでは、一般に5.17が認証情報管理、8.5が安全な認証に関する管理策として対応するとされています（規格の詳細はISMS-AC等の公式資料で確認できます）。パスワードは利用者個人だけの問題ではありません。採用時のアカウント発行、異動時の権限変更、退職・契約終了時の無効化、共有アカウントの例外管理、特権IDの利用記録まで、ライフサイクル全体を対象にします。
パスワードポリシーの設計基準
ISO/IEC 27001の規格本文は認証機関や公式資料で参照できます。規格はリスクに応じた管理の仕組みを定めるものであり、パスワードの文字数や変更頻度について一律の数値を直接規定する形にはなっていないと一般に解説されています。
したがって、文字数や複雑性は、利用システムの重要度、MFAの有無、外部公開の有無、ログイン試行制限、漏洩時の影響を踏まえて決めます。MFAを利用できないレガシーシステム、管理者権限、インターネットから到達できる管理画面は、より長くランダムなパスワード、接続元制限、監査ログなどを組み合わせます。
一方で、「毎月変更」「記号を必ず3種類」「紙に控えることを禁止」といった過剰な規程は、使い回しや末尾数字だけの変更を誘発します。変更頻度は、侵害の疑い、漏洩情報の検知、共有者の離任、特権IDの利用終了など、リスクイベントを契機にする設計が実務に適します。規程に定期変更を残す場合も、対象を特権IDや共有IDに限定し、理由と実施記録を残します。
安全な保管と共有の方法
認証情報は、表計算ソフト、チャット、メール本文に平文で保存・共有しない運用にします。
パスワードマネージャーは、ログインID、パスワード、APIキー、回復コード、クレジットカード情報などを暗号化して保管し、部署・プロジェクト単位でアクセス権を設定する手段です。導入するなら、個人保管庫と共有保管庫を分け、閲覧・編集・共有・エクスポートの権限を役割別に設計します。共有パスワードを利用者に表示しない機能がある場合でも、画面撮影やブラウザ開発者ツールなどによる持ち出しリスクをゼロにはできないため、重要アカウントは個人ID化とMFAを優先します。
パスワードマネージャーを使わない組織でも、最低限、共有IDの所有者、利用目的、利用者一覧、変更責任者、退職時の変更手順を台帳化します。ただし、閲覧履歴を記録できず、編集権限を適切に制御できない表計算ソフトは、特権IDや顧客システムの認証情報の保管先には適しません。
多要素認証とアカウントライフサイクル
MFAは、パスワード漏洩後の不正ログインを抑える基本対策として、優先順位を高く置きます。
対象は、メール、IdP、クラウド管理コンソール、リモートアクセス、ソースコード管理、会計・人事などの重要SaaSから決めます。特にメールとIdPが侵害されると、パスワードリセットを経由して多数のサービスを乗っ取られる可能性があります。フィッシング対策の強度を高めるなら、対応サービスではFIDO2セキュリティキーまたはパスキーを選択肢に含めます。
入退社の運用では、人事システムのイベントを起点に、IdPと各SaaSのアカウントを連動させます。SCIM連携で削除または無効化まで自動化できれば、オフボーディング漏れを減らせます。連携できないサービスは、退職日当日に実施する停止手順と実施者を明記し、チケットや操作ログを証跡として残します。
監査で確認されやすい証跡
審査では、規程の存在だけでなく、定めた認証情報管理が実際に運用されている証跡が確認されます。
確認領域 | 証跡の例 | 確認時の判断 |
|---|---|---|
アカウント発行 | 申請、承認、権限付与の記録 | 職務に必要な権限だけが付与されているかを確認します。 |
異動・退職 | 無効化ログ、権限削除チケット、共有ID変更記録 | 雇用・契約終了に連動して停止できているかを確認します。 |
共有アカウント | 利用者一覧、所有者、保管場所、変更履歴 | 個人ID化できない理由と代替統制を確認します。 |
特権ID | 利用申請、作業記録、操作ログ、定期棚卸し | 常時利用を避け、利用を追跡できるかを確認します。 |
認証強度 | MFA設定画面、条件付きアクセス設定、例外承認 | 高リスクのサービスに相応の認証が適用されているかを確認します。 |
認証情報の管理策は、93の管理策のうち技術的管理策だけで完結しません。人事、総務、部門長、情シスがそれぞれ何を通知し、誰が停止を実行し、どこに記録を残すかまで決めることで、退職者アカウントの放置を防げます。
ISMS運用と生成AIセキュリティのベストプラクティス
生成AIを業務利用する場合は、利用禁止の一律ルールではなく、入力情報・利用目的・利用サービスを分類して統制します。
ChatGPTなどの生成AIは、議事録要約、文章作成、プログラム支援、問い合わせ対応の下書きなどに活用できます。一方で、顧客情報、未公開の財務情報、ソースコード、認証情報、契約書を入力すると、情報漏洩、契約違反、著作権・ライセンス問題、誤回答の利用といったリスクが生じます。ISMSでは、これらを新しい情報資産と業務プロセスとしてリスクアセスメントに組み込みます。
生成AI利用のリスク分類
生成AIの利用可否は、データ区分と出力の利用方法を掛け合わせて決めます。
利用場面 | 入力できる情報 | 必要な統制 |
|---|---|---|
一般的な文章の下書き | 公開済み情報、匿名化済み情報 | 利用サービスの指定と、出力内容の人による確認を行います。 |
社内資料の要約 | 社内利用に限定された情報 | 契約プランの学習利用設定、アクセス制御、利用者教育を確認します。 |
顧客データの分析 | 個人情報・機密情報を含む可能性がある情報 | 匿名化、契約条件、保存・削除条件、法務・個人情報保護部門の承認を必要とします。 |
認証情報や秘密鍵の入力 | パスワード、APIキー、秘密鍵 | 入力を禁止し、誤入力時の報告・無効化手順を定めます。 |
「社外秘なので生成AIに入力しない」という規程だけでは、現場が判断できません。たとえば顧客名を伏せても、案件規模、日付、製品名、組織名の組み合わせで個社を識別できることがあります。入力前の匿名化とは何を削除・置換するか、具体例を教育資料に載せます。
利用サービスの評価項目
法人向けの生成AIサービスを利用する場合は、学習利用、保存期間、管理者機能、契約条件を評価対象にします。
確認対象として一般的に挙げられる項目には、入力データや出力データがモデル学習に使われる条件、管理者が利用者を追加・削除できるか、MFAやSSOに対応するか、操作ログを取得できるか、データ保存場所、サブプロセッサー、インシデント通知条件などがあります。ただし、サービスごとにプラン・地域・契約形態で仕様が異なるため、各サービスの公式利用規約や管理者向けドキュメントで個別に確認します。公開情報で仕様を確認できた範囲を委託先評価票と利用規程に反映し、確認できない項目が残る場合は、機密情報を扱わない用途に限定するか、契約・質問票で確認できるサービスへ切り替えます。
生成AIサービスはプラン・地域・契約形態で設定や機能が変わる場合があります。対象・提供状況は、導入時点の公式契約条件と管理者向け仕様で確認します。その結果、組織管理、学習利用の制御、ログ取得が確認できるなら限定した業務から利用を開始し、確認できないなら公開情報のみを扱う利用に制限します。
社内ガイドラインの最小構成
生成AIガイドラインは、禁止事項だけでなく、現場が迷わず使える承認・相談ルートを含めます。
利用目的と対象サービスを定義します。
公開情報、社内情報、個人情報、機密情報、認証情報にデータを分類します。
入力禁止情報と、匿名化・承認を条件に入力できる情報を定めます。
出力物の事実確認、著作権確認、対外発信前の承認を定めます。
誤入力、誤送信、不適切出力を発見した場合の報告先と初動を定めます。
利用ログ、教育受講、例外承認を記録し、内部監査の対象にします。
生成AIに関する教育では、実際の業務に近い設問を使います。「顧客名を消した契約書を要約してよいか」「障害ログに含まれるIPアドレスを入力してよいか」「公開前の決算説明資料を翻訳してよいか」といった場面ごとに、利用可否と相談先を示します。年1回の受講記録だけでなく、サービス追加や大きな機能変更の際にルールを見直す運用が必要です。
メール認証とAIを使ったなりすまし対策
生成AIの普及で、自然な日本語を使うフィッシングメールやなりすまし連絡への対策も必要になります。
総務省「令和8年版 情報通信白書」soumu.go.jpによると、2025年12月時点でのJPドメインにおける送信ドメイン認証技術の導入率は、SPFが約89.6％に対してDMARCは約37.2％にとどまります。SPFだけではなりすまし対策として十分ではありません。自社ドメインから取引先や顧客へメールを送る組織は、送信元を棚卸しし、DKIMとDMARCの設定を段階的に進めます。DMARCレポートで正当な送信元を確認できればポリシーを強化し、未把握の送信元があるなら隔離・拒否を急がず設定を修正します。
▲ 生成AI業務利用における情報入力・利用可否の判断フロー
ISMS認証取得の流れと期間の目安
ISMS認証は、規程作成から始めるのではなく、適用範囲と情報資産を決めてからリスク評価・運用・審査へ進めます。
準備から認証登録までの期間は、適用範囲、既存の統制、内部監査員の確保、審査機関の日程、不適合の改善速度で変わります。一般に数か月単位の準備を見込みますが、「何か月で必ず取得できる」と断定できる公的一律基準はありません。急ぐ場合ほど、対象範囲を正当に定義し、審査前に運用記録を作る期間を確保します。
取得プロジェクトのフェーズ
以下の順序で進めると、規程だけが先行し、実運用とのずれが大きくなる失敗を防げます。
フェーズ | 主な実施内容 | 成果物・証跡 |
|---|---|---|
方針・範囲設定 | 対象事業、拠点、情報資産、責任者、利害関係者を定めます。 | 適用範囲、情報セキュリティ方針、体制図 |
現状把握 | 資産、クラウド、委託先、アカウント、既存規程を棚卸しします。 | 情報資産台帳、委託先一覧、課題一覧 |
リスク対応 | 脅威・脆弱性・影響を評価し、管理策の採否を決めます。 | リスクアセスメント、リスク対応計画、適用宣言書 |
運用・教育 | 権限管理、バックアップ、インシデント対応、教育を実施します。 | 申請記録、ログ、教育記録、点検記録 |
内部監査・レビュー | 内部監査、不適合是正、経営層による見直しを行います。 | 監査報告書、是正記録、マネジメントレビュー記録 |
外部審査 | 第1段階・第2段階の審査と指摘への対応を行います。 | 審査報告、是正対応、認証登録 |
適用宣言書は、附属書Aの各管理策について、適用するか、適用しないか、適用する理由、実装状況を整理する文書です。テンプレートを埋める作業と考えると、実際の対策と文書がずれます。リスク評価で特定したリスクに対し、どの管理策で対応するかを追えるようにします。
内部監査とマネジメントレビュー
外部審査の直前に内部監査を形式的に終わらせると、不適合の是正が間に合いません。
内部監査では、監査対象の担当者から証跡を受け取り、規程どおりに運用されたかを確認します。監査員自身が担当する業務を監査すると独立性が弱くなるため、部門をまたいで担当を分けるか、必要に応じて外部支援を利用します。監査で見つかった不備は、「教育を再実施した」で終えず、原因、暫定対応、恒久対策、効果確認、期限、責任者を記録します。
マネジメントレビューでは、経営層が監査結果、インシデント、目標達成状況、リスク、資源の必要性を確認し、改善の意思決定を行います。経営層の署名だけを取得する会議ではなく、予算や人員が必要な対策について判断を残す場として設計します。
認証機関の比較観点
認証機関を選ぶ際は、認定の有無だけでなく、審査日程、見積もり条件、審査工数の説明を比較します。
見積もりでは、適用人数、拠点数、適用範囲、シフト勤務、海外拠点、委託業務、統合審査の有無が審査日数に影響します。見積書に初回審査、第1段階・第2段階、サーベイランス審査、更新審査、出張費、不適合対応の条件が分けて記載されていれば、3年間の予算を比較できます。条件が不明確なら、安価に見える見積もりでも追加費用が発生する可能性を残します。
▲ ISMS認証取得プロジェクトのフェーズと主要成果物の流れ
ISMS認証にかかる費用と予算化の考え方
ISMS認証の費用は、組織規模だけでは決まらず、適用範囲、拠点、審査日数、既存統制、外部支援の利用範囲によって変動します。
「取得費用はいくらか」という問いに単一の相場で答えることはできません。審査機関の料金は個別見積もりが基本であり、コンサルティングやツールの利用料も契約内容により異なります。予算化では、初年度の認証取得費用だけでなく、3年間の維持審査、更新審査、社内工数を分けて見積もります。
費用項目と変動要因
見積もりで確認する費用項目は、審査料、構築支援、運用支援、システム費、社内工数の5区分です。
費用区分 | 主な内容 | 金額が変動する要因 |
|---|---|---|
認証審査料 | 初回審査、維持審査、更新審査、出張費 | 適用人数、拠点数、審査日数、統合審査の有無 |
構築支援費 | 現状分析、文書整備、リスク評価、内部監査支援 | 既存規程の整備度、支援範囲、担当者の稼働 |
運用支援費 | 維持審査準備、教育、内部監査、改善支援 | 自社で実施できる業務の範囲、年間支援回数 |
システム費 | 台帳管理、eラーニング、ログ管理、パスワード管理 | 利用人数、必要機能、既存ツールとの重複 |
社内工数 | 棚卸し、会議、教育、証跡収集、監査対応 | 部門数、資産数、委託先数、運用の自動化状況 |
認証機関への審査料は、審査日数と条件が見積書に明記されているかで比較します。コンサルティング費は、文書を納品するだけなのか、担当者への教育、内部監査、是正対応まで含むのかで内容が大きく変わります。料金が非公開のサービスは、公開価格を推測せず、要問合せとして扱います。
3年間で見る予算計画
予算は、初年度の取得費用と、2年目以降の維持費を混ぜずに管理します。
初年度には、現状分析、リスク評価、規程・台帳整備、教育、内部監査、初回審査への対応が集中します。2年目と3年目にはサーベイランス審査があり、認証サイクルの終盤には更新審査が予定されます。更新審査の年度に予算不足になるケースを避けるため、認証取得を決める時点で3年分の審査費用と社内工数を概算します。
費用削減は、審査に必要な作業を無理に省くことではありません。既存の人事申請、チケット、端末管理、ログ監視、教育システムを証跡として使える場合は、同じ情報を別の台帳へ二重入力しない設計にします。一方、既存システムから証跡を出せず、担当者しか状況を説明できない場合は、ツール追加より先に責任者と記録の置き場所を決めます。
社内稟議に使う費用試算テンプレート
稟議では、初期費用の総額だけでなく、取得しない場合に残る対応負荷と比較します。
認証対象の事業・拠点・人数を明記します。
認証機関から初回、維持、更新を含む見積もりを取得します。
外部支援を使う業務と、自社で担当する業務を分けます。
既存ツールで代替できる証跡と、新規に必要な機能を整理します。
担当者ごとの月間工数を見積もり、人件費換算の前提を記載します。
取引要件、入札条件、委託先評価など、取得によって対応する事業要請を添えます。
稟議では市場動向ではなく、自社のリスクと対応コストを根拠として記載します。
ISMS認証とPマークの違い
ISMS認証とPマークは、保護対象、適用範囲、基準となる規格が異なるため、取引先の要求と自社が扱う情報を基準に選びます。
ISMSとPマークの違いは、「セキュリティ対個人情報」という単純な対立ではありません。どちらも組織的な管理の仕組みを評価する制度です。ISMSは情報資産全般を対象にISO/IEC 27001に基づいてリスク管理を行い、Pマークは個人情報保護マネジメントシステムをJIS Q 15001に基づいて評価します。各制度の詳細な要求事項や適用範囲は、ISMS-AC（）およびJIPDEC（）の公式情報で確認できます。
比較項目 | ISMS認証 | Pマーク |
|---|---|---|
主な保護対象 | 個人情報を含むすべての情報資産 | 事業者が取り扱う個人情報 |
基準規格 | ISO/IEC 27001、国内規格はJIS Q 27001 | JIS Q 15001 |
適用範囲 | 事業、部門、拠点などを定義して認証範囲を設定できます。 | 原則として事業者全体の個人情報保護体制を対象にします。 |
管理方法 | 情報資産のリスクアセスメントに基づいて対策を選定します。 | 個人情報の特定、利用目的、本人対応、委託先管理などを含めて管理します。 |
外部への説明 | 情報セキュリティ管理体制を国際規格で説明できます。 | 個人情報を適切に取り扱う体制を国内制度で示します。 |
取得判断の基準
顧客・従業員の個人情報保護が主要な取引条件ならPマークを、サービス運用や機密情報を含む情報資産全体の統制が問われるならISMSを軸に検討します。
ただし、Webサービス、BPO、人材、広告、医療、教育などでは、個人情報保護と情報セキュリティの両方を取引先から確認されることがあります。取引先の要求書にPマークまたはISMSのいずれかでよいと書かれているなら、適用範囲、対象情報、将来の事業展開、維持工数を比較します。Pマークが明記されているなら、ISMS認証だけで代替できると判断せず、要求元に代替可否を確認します。
パスワード管理の共通点と違い
パスワード管理は、ISMSでもPマークでも、リスクに応じたアクセス制御の一部として設計します。
Pマークだから定期変更が必須、ISMSだから文字数だけを決めればよい、という理解は正確ではありません。いずれも、扱う情報、権限、端末、ネットワーク、委託先、事故時の影響を考慮して技術的・組織的な安全管理措置を整えます。個人情報を扱うシステムでは、個人ID、最小権限、MFA、アクセスログ、退職時の無効化を組み合わせ、規程と実態が一致するようにします。
関連規格との関係
クラウド、個人情報、AIの管理課題が大きい組織は、ISMSを基盤に関連規格を検討できます。
経済産業省の情報セキュリティ管理基準の改訂版は、JIS Q 27001:2023およびJIS Q 27002:2024に準拠して策定されています。これは、ISMSの考え方が認証だけでなく、情報セキュリティ監査や管理基準の基盤にもなっていることを示します。ISO/IEC 27017、ISO/IEC 27701、ISO/IEC 42001などの関連規格を検討する場合も、先に自社の情報資産、委託先、個人情報、AI利用のリスクを整理すると、認証ありきの重複投資を避けられます。
▲ ISMS認証とPマークの主な違い（対象・範囲・規格）の対比
ISMS認証後の維持管理と失敗パターン
ISMS認証を維持するには、審査前だけ作業を増やすのではなく、日常業務から証跡が残る運用へ組み替えます。
認証は通常3年のサイクルで維持され、その間にサーベイランス審査と更新審査があります。維持管理で問われるのは、初回審査時に作った規程が残っているかではなく、リスク評価、教育、内部監査、是正、マネジメントレビューが継続しているかです。インシデントや組織変更が起きた際に、台帳や規程を更新できる体制が必要です。
過剰なルールによる形骸化
守れないルールを増やすことは、ISMS運用で避けるべき失敗です。
たとえば、全サービスに毎月のパスワード変更を課す、全ファイル共有に部門長承認を求める、すべての変更を紙の申請書で管理するといった運用は、現場が迂回しやすくなります。情シスに申請が集中し、緊急対応で記録が後回しになれば、統制の実効性が下がります。
対策は、情報の重要度とリスクに応じてルールを分けることです。顧客データ、本番環境、特権IDには厳格な承認・ログ・MFAを適用し、公開情報や低リスクの業務には簡潔な手順を適用します。例外が必要な業務には、期限、承認者、補完対策を記録する例外申請を用意します。
台帳の二重管理と証跡不足
既存システムの情報を手作業で転記し続けると、台帳はすぐに古くなります。
資産台帳、アカウント台帳、委託先台帳、教育記録は、更新の起点を決めます。端末台帳なら資産管理システム、アカウント台帳ならIdPやチケット、人事情報なら人事システムを正とします。CSVで証跡を出力できるなら定期的な保管ルールを作り、API連携で取得できるなら自動収集の対象にします。
ツールを導入しても、データの所有者と更新期限が決まらなければ、古い台帳を新しい画面に移しただけになります。棚卸し対象、頻度、抽出方法、差分の確認者、是正期限を決め、内部監査で実施記録を確認します。
外部支援への過度な依存
コンサルティングや運用支援は有効ですが、判断と責任まで外部へ移すと認証後に社内運用が止まります。
外部支援を利用する場合は、どの文書を誰が維持するか、リスク評価の判断者は誰か、内部監査の実施者をどう育成するかを開始時に明確にします。支援会社が作成した規程でも、現場の実態に合わなければ改訂します。教育資料や監査チェックリストを自社の業務に合わせて更新できる状態を残します。
インシデント発生時の初動
不正アクセスの疑いが生じた場合は、原因調査より先に被害拡大を抑える手順を実行します。
アカウント侵害が疑われる場合は、該当アカウントの無効化またはセッション失効、パスワード変更、MFA再登録、関連する共有認証情報の変更を行います。その後、ログ保全、影響範囲の確認、顧客・委託先への連絡判断、再発防止を進めます。コンピュータ不正アクセス被害の相談・届出先としては、IPAへの届出のほか、警察への被害届、個人情報が関係する場合は個人情報保護委員会への報告なども対応が求められる場合があります。連絡先をインシデント対応手順にあらかじめ記載し、休日・夜間の連絡責任者も定めます。
ISMS運用を始めるための実務チェックリスト
認証取得を検討する段階では、まず対象業務と現状の証跡を確認し、足りない統制を優先順位順に埋めます。
すべての規程を一度に作り直す必要はありません。取引要件や事故時の影響が大きい領域から確認し、既存の仕組みで証跡を出せるものと、新たな運用が必要なものを分けます。以下のチェックリストは、キックオフ会議や現状分析に使えます。
着手前の確認項目
各項目で「担当者がいる」「証跡を出せる」「定期見直しがある」の3点を確認します。
認証の適用範囲に含める事業、拠点、部門、委託先を定義していますか。
情報資産の所有者、保管場所、重要度、廃棄方法を把握していますか。
メール、IdP、クラウド管理者、本番環境にMFAを適用していますか。
入社、異動、退職、業務委託終了に連動するアカウント管理手順がありますか。
共有IDと特権IDについて、利用者、所有者、変更履歴を追跡できますか。
クラウドサービスと委託先について、契約、再委託、データ削除、インシデント通知条件を確認していますか。
生成AIに入力してよい情報と禁止する情報を、具体例付きで定義していますか。
バックアップの取得だけでなく、復元テストの記録を残していますか。
インシデントの連絡先、初動、記録、顧客連絡の判断者を定めていますか。
内部監査とマネジメントレビューの実施時期、責任者、是正期限を決めていますか。
このうち、メールやIdPのMFA、退職者アカウントの無効化、特権IDの記録が未整備なら、認証文書の作成より先に運用を開始します。すでに運用できているが証跡を取得できない場合は、ログ出力、チケット記録、承認フローのいずれかを整えます。
最初の90日間の進め方
最初の90日間は、範囲設定、リスク把握、優先対策、運用開始の順で進めると、審査準備と実務改善を両立できます。
最初の30日間：経営層、情シス、総務・人事、対象部門で体制を決め、対象範囲と情報資産を棚卸しします。取引先の要求書や契約上の義務も収集します。
31日目から60日目：リスクアセスメントを実施し、MFA、退職処理、バックアップ、委託先評価、生成AI利用など優先度の高い対策を決めます。適用宣言書の原案を作ります。
61日目から90日目：規程を実運用に合わせて確定し、教育を実施します。アカウント申請、権限変更、インシデント対応などの証跡を蓄積し、内部監査の準備を始めます。
情報セキュリティ製品やサービスの市場が拡大しても、導入数を増やすことが目的ではありません。外部サービスを利用する場合も、社内で保有すべき判断・承認・証跡を明確にし、委託先に任せる範囲を限定します。
まとめ
自社の事業に合うISMS運用
ISMS認証は、取得そのものを目的にするのではなく、情報資産と事業リスクを継続的に管理する仕組みとして設計します。費用は審査料だけで判断せず、適用範囲、維持審査、社内工数、既存ツールとの重複を含めて3年間で比較します。Pマークとの違いは、保護対象と適用範囲を基準に判断します。
明日から始めるなら、メール、IdP、本番環境、共有IDの4領域について、誰が利用でき、退職時に誰が停止し、どのログが残るかを書き出します。その結果を情報資産台帳とリスク評価の出発点にすれば、パスワード管理、生成AI利用、委託先管理を実務に沿って整備できます。
主な参考資料
ISMS-AC「ISO/IEC 27001:2022への移行について」isms.jp
ISMS-AC「ISMS認証登録数8000件超のお知らせ」2024年12月27日isms.jp
ISMS-AC「ISMS登録数の推移」isms.jp
ISMS-AC「ISMSクラウドセキュリティ認証登録数500件超のお知らせ」2024年3月isms.jp
総務省「令和8年版 情報通信白書」該当章soumu.go.jp— 国内情報セキュリティ製品市場規模、ランサムウェア被害額、送信ドメイン認証導入率を含む
経済産業省「情報セキュリティ管理基準（令和7年改訂版）」meti.go.jp
経済産業省「不正アクセス行為に関する相談・届出先」meti.go.jp
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
