企業法務、内部統制、個人情報保護、契約管理、情報セキュリティを一体で設計するための要点を、2026年6月11日時点の制度動向を踏まえて整理します。
このページの前提、対象読者、基準日、認証文書上の注意点を整理します。
このページは、ISMS認証取得と社内体制構築について、企業法務に関係する問題に悩む経営者、法務担当者、コンプライアンス担当者、個人情報保護担当者、情報システム部門、内部監査部門、管理部門、士業・専門職の読者を想定して作成した専門解説です。
このページの編集方針は、弁護士、企業内弁護士、外部弁護士、法務担当、コンプライアンス担当、内部監査担当、個人情報保護担当、公認会計士、税理士、社会保険労務士、弁理士、情報セキュリティ担当、デジタルフォレンジック専門家、リスクマネジメント担当などが共同で論点を整理する場合の水準を想定しています。もっとも、このページは一般的な情報提供を目的とするもので、個別案件の法的助言、認証審査の合格保証、または特定の認証機関の審査判断を代替するものではありません。
このページの基準日は2026年6月11日です。日本国内の実務では、ISO/IEC 27001:2022およびISO/IEC 27001:2022/Amd 1:2024に対応するJIS Q 27001:2025への言及が重要です。認証文書上の表記、移行、審査運用については、必ず契約予定または契約中の認証機関にも確認する必要があります。ISMS-ACは、JIS Q 27001:2025が2025年5月20日に公示され、JIS Q 27001:2023は追補1によりJIS Q 27001:2025となる旨を公表しています。
IT部門の認証作業ではなく、企業統治の設計として全体像を押さえます。
IT部門の認証作業ではなく、企業統治の設計として全体像を押さえます。
次の重要ポイントは、ISMS認証取得と社内体制構築が何を実現する仕組みなのかを表しています。読者にとって重要なのは、認証ロゴの取得だけでなく、リスクを経営管理の言葉に置き換え、証跡として残し、改善し続けることを読み取る点です。
ISMSの本質は、情報資産を特定し、リスクを評価し、経営として受容可能な水準を決め、管理策を実装し、証跡を残し、監査とレビューで改善することにあります。
ISMS認証取得と社内体制構築を検討するとき、最初に修正すべき誤解は、「ISMSは情報システム部門がチェックリストを埋めれば取得できる認証です」という見方です。ISMS、すなわち情報セキュリティマネジメントシステムは、情報の機密性、完全性、可用性を守るための組織的な仕組みで、技術対策だけでなく、経営判断、規程、契約、教育、委託先管理、内部監査、インシデント対応、継続的改善を含みます。
ISOは、ISO/IEC 27001を情報セキュリティマネジメントシステムの要求事項を定める国際規格として説明し、あらゆる規模・業種の組織が、情報セキュリティマネジメントシステムを確立し、実施し、維持し、継続的に改善するための枠組みとして説明しています。 また、JIPDECは、ISMS認証を、ISO/IEC 27001（JIS Q 27001）の要求事項に基づき、第三者である認証機関が組織の対応状況を審査し、適合を証明するものと説明しています。
企業法務の観点からは、ISMSは「法令違反を直接に治癒する制度」ではありません。しかし、個人情報保護法上の安全管理措置、委託先監督、漏えい等発生時の報告・本人通知、取引先との情報管理条項、クラウド利用時の責任分界、役職員の秘密保持義務、内部統制システム、取締役会・監査役等の監督、サプライチェーンリスクの説明責任に深く関係します。したがって、ISMS認証取得と社内体制構築は、単なる取得プロジェクトではなく、企業の情報リスクを経営管理の言語に翻訳し、証拠化し、継続運用するための法務・統制プロジェクトとして設計する必要があります。
ISMS、認証、規格、情報資産、三要素、リスク対応、適用範囲を確認します。
ISMSとは、Information Security Management System、すなわち情報セキュリティマネジメントシステムです。情報資産に対するリスクを把握し、必要な管理策を選定し、運用し、監視し、改善するための組織的な仕組みを指します。ISMS-ACは、ISMSについて、個別の技術対策だけでなく、組織のマネジメントとして自らのリスクアセスメントにより必要なセキュリティレベルを決め、計画を持ち、資源を配分し、システムを運用するものと説明しています。
ISMS認証とは、認証機関が、対象組織のISMSがISO/IEC 27001またはJIS Q 27001の要求事項に適合しているかを審査し、適合している場合に認証文書を発行する第三者認証です。これは「絶対に情報漏えいが起きない」という保証ではありません。また、特定のシステム、製品、クラウドサービスそのものの完全性を保証するものでもありません。認証の本質は、組織が情報セキュリティリスクを識別し、管理し、改善するための仕組みを構築・運用していることについて、第三者の審査を受ける点にあります。
ISO/IEC 27001は、ISMSの要求事項を定める国際規格です。ISOは、正式な略称はISO/IEC 27001です。単にISO 27001と略記されることがありますが、正式にはISOとIECが共同で発行する規格として説明されています。
JIS Q 27001は、日本産業規格としての対応規格です。日本国内の認証実務では、契約書、審査申請書、認証文書の記載において、ISO/IEC 27001とJIS Q 27001のどちらで表記するか、また2025年追補後の表記をどう扱うかが問題になり得るため、認証機関への確認が必要です。
ISO/IEC 27002は、情報セキュリティ管理策の実践的な指針を示す規格です。ISO/IEC 27001が要求事項を定めるのに対し、ISO/IEC 27002は管理策のベストプラクティスや実装上の考え方を提供するものと理解すると分かりやすいです。
情報資産とは、組織に価値をもたらす情報および情報を取り扱う手段を指します。顧客情報、従業員情報、取引先情報、契約書、設計図、ソースコード、営業秘密、財務情報、研究開発データ、認証情報、ログ、端末、サーバ、クラウド環境、紙文書、バックアップ媒体、外部委託先が保持するデータなどが含まれます。
情報資産を「個人情報だけ」と捉えると、ISMSの設計は必ず失敗します。個人情報は重要な情報資産ですが、知的財産、営業秘密、契約上の秘密情報、業務継続に必要なログや設定情報、財務報告に影響するデータも、同等またはそれ以上に重要な情報資産となり得ます。
情報セキュリティの代表的な三要素は、機密性、完全性、可用性です。ISOは、ISO/IEC 27001における情報セキュリティの三原則として、適切な者だけが情報にアクセスできる機密性、情報が破壊・改ざんされず信頼できる状態で保たれる完全性、必要なときにアクセスできる可用性を説明しています。
法務的には、機密性は秘密保持義務、個人情報保護、営業秘密管理と結びつきます。完全性は、証拠性、監査証跡、財務報告、品質管理、電子契約の真正性と関係します。可用性は、サービス提供義務、SLA、業務継続、損害賠償、行政・金融・医療などの規制業種における継続的提供義務と関係します。
リスクアセスメントとは、情報資産に対する脅威、脆弱性、影響度、発生可能性などを評価し、優先順位を定める作業です。リスク対応とは、リスクを低減する、回避する、移転する、または受容するという意思決定です。
ここで重要なのは、リスクを「ゼロにする」ことが目的ではない点です。実務上の目的は、経営資源、事業上の重要性、法的義務、契約上の約束、ステークホルダーへの説明責任を踏まえ、許容可能な水準までリスクを管理することです。
適用範囲とは、ISMS認証の対象となる組織、業務、拠点、システム、情報資産、プロセス、外部委託範囲を定めるものです。適用範囲は認証の核心です。広すぎれば初回構築が重くなり、狭すぎれば取引先から「実質的なリスクを覆っていない」と評価されます。法務・営業・経営の観点からは、認証取得の目的、顧客要求、入札要件、委託先審査、グループ会社との関係、海外拠点とのデータ移転、クラウド利用範囲を踏まえて設定する必要があります。
取締役責任、個人情報保護、契約、労務、会計・内部監査との関係を整理します。
ISMS認証取得と社内体制構築は、経営者の関与なしには成立しません。経済産業省とIPAのサイバーセキュリティ経営ガイドラインは、IT利活用が企業の収益性向上に不可欠である一方で、顧客の個人情報や重要な技術情報を狙うサイバー攻撃が増加・巧妙化しており、経営者による判断が必要と説明しています。また、同ガイドラインは、経営者が認識すべき「3原則」と、CISO等に指示すべき「重要10項目」をまとめています。
会社法上も、取締役会設置会社では、業務の適正を確保するための体制、すなわち内部統制システムの整備が重要な論点となります。会社法第362条第4項第6号および第5項、会社法施行規則第100条は、取締役の職務執行が法令・定款に適合することを確保する体制、損失危険の管理に関する規程その他の体制、情報の保存・管理に関する体制などを含む内部統制体制を問題にします。
情報セキュリティ事故は、単なるIT障害にとどまらず、顧客損害、行政報告、適時開示、取引停止、損害賠償、株主代表訴訟、役員責任、信用毀損に波及し得ます。そのため、ISMS認証取得と社内体制構築は、経営判断の証跡を残し、リスク管理体制を説明可能にするための重要な仕組みとなります。
個人情報を取り扱う企業にとって、ISMSと個人情報保護法は密接に関係します。個人情報保護法は、個人データの安全管理措置、従業者監督、委託先監督、漏えい等発生時の報告・本人通知などを定めています。 個人情報保護委員会は、2022年4月1日から、個人データの漏えい等が発生し、個人の権利利益を害するおそれがあるときは、個人情報保護委員会への報告および本人への通知が必要と説明しています。また、要配慮個人情報が含まれる事態、財産的被害が生じるおそれがある事態、不正目的による漏えい等、1,000人を超える漏えい等が該当例として示されています。
ただし、ISMS認証を取得していることは、個人情報保護法への完全な適合を意味しません。ISMSは情報セキュリティリスク管理の枠組みで、個人情報保護法は本人の権利利益保護を中心とする法規制です。両者は重なりますが、同一ではありません。したがって、ISMS文書体系の中に、個人情報の取得、利用目的、第三者提供、委託、共同利用、越境移転、保有個人データ対応、漏えい等報告、本人通知の手順を組み込む必要があります。
取引先からISMS認証を求められる場面は増えています。SaaS、BPO、システム開発、データ分析、コールセンター、決済、医療・金融・教育関連サービスでは、秘密情報、個人情報、営業秘密、業務データの取扱いが契約の中核となります。
契約法務では、次の論点が特に重要です。
ISMS認証取得と社内体制構築を契約法務から切り離すと、審査上は文書が整っていても、実際の契約義務に対応できないという事態が生じます。
情報セキュリティ事故の多くは、人に起因します。誤送信、持ち出し、退職者によるデータ持出し、シャドーIT、過剰権限、内部不正、教育不足、委託先担当者の不注意などです。
人事・労務の観点では、次の制度設計が必要となります。
社会保険労務士、弁護士、情報システム部門が連携しなければ、セキュリティルールは就業規則上の根拠を欠き、懲戒や調査の場面で弱くなります。
情報システムは財務報告にも影響します。販売管理、購買、在庫、会計、給与、経費精算、ワーク手順、電子契約、決裁システムが侵害されれば、財務情報の正確性や承認統制にも影響し得ます。公認会計士や内部監査担当は、ISMSを単なるセキュリティ活動ではなく、IT全般統制、権限管理、変更管理、ログ管理、バックアップ、外部委託管理、証跡保全と接続して評価する必要があります。
目的設定から認証登録後の継続的改善まで、取得プロジェクトの順序を確認します。
ISMS認証取得と社内体制構築は、一般に次の順序で進めると整理しやすい。
JIPDECは、認証取得を希望する組織は、ISMS-ACが認定した認証機関の中から申請先を選択し、審査は原則として第一段階と第二段階の2段階で行われ、通常1年ごとにサーベイランス審査、3年ごとに再認証審査が行われると説明しています。
目的、範囲、現状調査、台帳、リスク対応、適用宣言書を具体化します。
最初に決めるべきことは、「なぜISMS認証を取得するのか」です。目的が曖昧なまま始めると、文書作成のための文書作成になり、運用が形骸化します。
典型的な目的は次のとおりです。
次の比較表は、ISMS認証取得と社内体制構築のステップ別実務に関する項目を整理したものです。確認漏れを防ぐために重要です。各行から、実務で確認すべき内容と担当領域を読み取ってください。
| 目的 | 法務・経営上の意味 |
|---|---|
| 取引先要求への対応 | 入札、委託先審査、継続取引条件への対応 |
| 顧客信頼の向上 | セキュリティ質問票への回答負担の軽減、説明可能性の向上 |
| 個人情報・秘密情報の管理強化 | 法令・契約違反リスクの低減 |
| 内部統制の整備 | 取締役会、監査役、内部監査への説明可能性 |
| グループ統制 | 子会社・海外拠点・委託先の管理水準の統一 |
| インシデント対応力の向上 | 初動遅れ、証拠散逸、報告漏れの防止 |
| セキュリティ投資の合理化 | リスクに応じた優先順位付け |
目的が「顧客に言われたから」だけであっても、それ自体は悪くありません。しかし、認証取得後に運用が停止すれば、サーベイランス審査で不適合を受けるだけでなく、取引先への説明と実態の不一致という法務リスクが生じます。
適用範囲の設計では、次の問いに答える必要があります。
適用範囲を狭く設定する場合でも、範囲外の部門や外部委託先が範囲内業務に重要な影響を及ぼすなら、インターフェース管理は不可欠です。たとえば、SaaS事業部だけを対象範囲にしても、人事部がアカウント発行を行い、総務部が入退室管理を行い、法務部が顧客契約を管理し、経理部が請求データを扱うなら、これらのプロセスを完全に無視することはできません。
現状調査は、文書と実態を分けて確認します。
文書面では、既存の情報セキュリティ基本方針、個人情報保護方針、秘密情報管理規程、就業規則、委託先管理規程、インシデント対応規程、システム管理規程、アクセス権限規程、ログ管理規程、クラウド利用規程、文書管理規程、内部監査規程、BCPなどを確認します。
実態面では、現場ヒアリング、システム棚卸し、アカウント一覧、アクセス権限、クラウド設定、端末管理、バックアップ、ログ、委託先一覧、契約書、教育履歴、過去インシデント、問い合わせ対応履歴、脆弱性対応履歴、例外承認を確認します。
この段階で重要なのは、現場を責めることではありません。ISMS構築における現状調査は、責任追及ではなく、リスクの可視化です。現場が実態を隠すと、後の審査で不整合が露呈します。
情報資産台帳は、ISMSの基礎です。台帳には、少なくとも次の観点を持たせると整理しやすいです。
次の比較表は、ISMS認証取得と社内体制構築のステップ別実務に関する項目を整理したものです。確認漏れを防ぐために重要です。各行から、実務で確認すべき内容と担当領域を読み取ってください。
| 項目 | 例 |
|---|---|
| 資産名 | 顧客DB、契約書フォルダ、ソースコード、給与データ |
| 資産区分 | 電子データ、紙文書、システム、端末、媒体、クラウド |
| 保有部門 | 営業、開発、人事、法務、経理 |
| 管理責任者 | 部門長、プロダクトオーナー、情報資産管理者 |
| 利用者 | 正社員、委託先、派遣社員、外部開発会社 |
| 保管場所 | クラウド、社内サーバ、端末、書庫 |
| 機密性 | 公開、社内限り、秘密、極秘 |
| 完全性 | 改ざん時の業務影響 |
| 可用性 | 停止時の許容時間 |
| 法令・契約 | 個人情報、要配慮個人情報、営業秘密、契約上の秘密情報 |
| 保存期間 | 法令、契約、業務上の必要性 |
| 廃棄方法 | 削除、破砕、消去証明、媒体破壊 |
情報資産台帳は一度作って終わりではありません。新サービス開始、クラウド追加、委託先変更、組織改編、M&A、海外展開、生成AIツール導入などのたびに更新されるべきものです。
リスクアセスメントの方法は、組織に合っていなければなりません。大企業では定量的評価、詳細なシナリオ分析、業務影響度分析を組み合わせることがあります。中小企業では、資産価値、脅威、脆弱性、影響度、発生可能性を簡潔に評価する方法でも対応できます。
重要なのは、評価基準を事前に定義し、同じ基準で評価することです。たとえば、影響度を「軽微・中・大・重大」とする場合、それぞれについて、売上影響、顧客影響、法令報告、サービス停止時間、信用毀損、損害賠償見込みなどの目安を決めます。
法務部門は、次の観点をリスク評価に入れるべきです。
リスク対応には、一般に次の選択肢があります。
次の比較表は、ISMS認証取得と社内体制構築のステップ別実務に関する項目を整理したものです。確認漏れを防ぐために重要です。各行から、実務で確認すべき内容と担当領域を読み取ってください。
| 対応 | 内容 | 例 |
|---|---|---|
| 低減 | 管理策により発生可能性または影響を下げる | 多要素認証、暗号化、教育、監視 |
| 回避 | リスクを伴う業務をやめる | 高リスクな外部共有を廃止 |
| 移転 | 契約・保険などにより一部を移す | サイバー保険、委託先補償条項 |
| 受容 | 残存リスクを承認する | 経営判断として許容 |
リスクを受容する場合、単に「費用がかかるからやらない」では不十分です。リスク所有者が、残存リスク、理由、監視方法、見直し時期を明示し、必要に応じて経営層が承認する必要があります。
適用宣言書、Statement of Applicability、SoAは、ISMSにおける中心文書です。SoAは、附属書Aの管理策について、適用するか否か、その理由、実装状況、関連文書を整理します。SoAは審査対策の一覧表ではなく、組織がリスクに対してどの管理策を採用し、なぜそれでよいと判断したかを説明する文書です。
SoAでよくある失敗は次のとおりです。
経営層、CISO、法務、人事、総務、内部監査などの役割を整理します。
経営層は、情報セキュリティ方針の承認、目的の設定、資源配分、責任権限の明確化、リスク受容、マネジメントレビューを担います。ISMSにおける経営層の役割は形式的な署名ではありません。経営者が「事業上どの情報を守るべきか」「どこまでリスクを許容するか」「どの投資を優先するか」を判断しなければ、ISMSは運用できません。
CISOまたは情報セキュリティ責任者は、ISMSの実務統括を担います。ただし、CISOがすべてを自分で実施する必要はありません。むしろ、法務、人事、総務、IT、開発、営業、内部監査、委託先管理を横断する調整機能が重要です。
CISOに必要な権限は、少なくとも次のとおりです。
法務部門は、ISMSの「契約・法令・証拠」側面を担います。具体的には、秘密保持契約、業務委託契約、クラウド契約、個人情報取扱いに関する契約、インシデント通知条項、監査条項、損害賠償、責任制限、再委託、越境移転、保存・廃棄義務、証拠保全、当局対応、顧客対応文書を管理します。
法務がISMSに関与しない場合、規程上は安全でも、契約上の義務に違反しているという矛盾が生じます。たとえば、顧客契約では24時間以内の通知義務があるのに、インシデント対応規程では「必要に応じて報告」としか書かれていない場合、実務上の初動は破綻します。
個人情報保護担当は、個人情報の取扱い、利用目的、第三者提供、委託、共同利用、越境移転、保有個人データ対応、漏えい等報告、本人通知、プライバシーポリシー、個人情報台帳、個人情報取扱い教育を担当します。
ISMSとPマークを併用する企業では、文書体系の重複に注意します。二つの制度で似た規程を別々に作ると、内容不一致や更新漏れが起きます。個人情報安全管理措置とISMS管理策を対応付け、同じ証跡を使えるようにすることが有効です。
情報システム・開発部門は、技術的管理策を中心に担います。アクセス制御、認証、ネットワーク、端末管理、脆弱性管理、パッチ適用、ログ監視、バックアップ、暗号化、開発環境、変更管理、リリース管理、クラウド設定、セキュアコーディング、監視運用、インシデント検知が主な領域です。
ただし、技術部門が法務・経営判断を代替してはいけません。たとえば、ログ保存期間、監視対象、従業員端末の調査、顧客への通知、サービス停止判断、委託先への調査要求には、法務・経営の関与が必要となります。
人事・労務部門は、入社・異動・退職、教育、誓約書、就業規則、懲戒、リモートワーク、端末貸与、労働時間管理、従業員モニタリング、内部通報を担います。情報セキュリティ教育は、単なる年1回のeラーニングでは不十分です。高権限者、開発者、営業、コールセンター、人事、経理、委託先管理者など、リスクに応じた教育設計が必要です。
総務部門は、入退室管理、来訪者管理、書庫、施錠、廃棄、郵送、複合機、会議室、セキュリティカード、監視カメラ、災害対策を担います。ISMSでは、サイバーだけでなく物理的安全管理も対象となります。紙文書の放置、共有スペースでの会話、廃棄物からの情報漏えい、紛失端末などは、法務上も重大な問題となり得ます。
内部監査部門は、ISMSが規程どおり運用され、有効に機能しているかを独立の立場で確認します。内部監査は、認証審査前の予行演習ではありません。経営者に対して、リスク管理体制が実際に機能しているかを報告するガバナンス機能です。
内部監査で確認すべき事項は、文書の有無だけではありません。アクセス権限が定期的に見直されているか、退職者アカウントが削除されているか、委託先評価が形骸化していないか、教育未受講者が放置されていないか、例外承認が期限切れになっていないか、インシデント訓練の改善事項が実施されているかを確認します。
実行責任、最終責任、協議先、報告先を一覧で確認します。
ISMS認証取得と社内体制構築では、責任分担を曖昧にしないことが重要です。以下は一例です。
次の比較表は、ISMS認証取得と社内体制構築のRACI責任分担に関する項目を整理したものです。確認漏れを防ぐために重要です。各行から、実務で確認すべき内容と担当領域を読み取ってください。
| 領域 | 経営層 | CISO/ISMS事務局 | 法務 | IT/開発 | 人事 | 総務 | 内部監査 |
|---|---|---|---|---|---|---|---|
| 適用範囲 | A | R | C | C | C | C | I |
| リスク基準 | A | R | C | C | C | C | I |
| 情報資産台帳 | I | A | C | R | R | R | I |
| 契約条項 | I | C | R/A | C | C | I | I |
| 個人情報対応 | A | C | C | C | C | I | I |
| アクセス管理 | I | A | C | R | C | I | I |
| 教育 | A | C | C | C | R | I | I |
| 物理管理 | I | C | I | C | C | R | I |
| インシデント初動 | A | R | R | R | C | C | I |
| 内部監査 | I | C | I | I | I | I | R/A |
| マネジメントレビュー | R/A | R | C | C | C | C | C |
Rは実行責任、Aは最終責任、Cは協議先、Iは報告先を意味します。実際の組織では、規模や部門構成に応じて調整します。
規程、手順、記録、証跡を審査と法務の両面から設計します。
ISMSでは「規程を作ること」自体が目的ではありません。規程、手順、記録、証跡が連動して初めて有効に機能します。
文書体系は、一般に次のように階層化すると管理しやすい。
次の比較表は、ISMS認証取得と社内体制構築の規程・記録・証跡設計に関する項目を整理したものです。確認漏れを防ぐために重要です。各行から、実務で確認すべき内容と担当領域を読み取ってください。
| 階層 | 文書例 | 役割 |
|---|---|---|
| 方針 | 情報セキュリティ基本方針 | 経営者の意思、目的、基本原則 |
| 規程 | 情報資産管理規程、アクセス管理規程、委託先管理規程 | 組織全体のルール |
| 手順 | アカウント発行手順、インシデント対応手順、バックアップ手順 | 実務担当者の作業基準 |
| 様式 | リスク評価表、委託先評価表、教育記録、例外申請 | 記録の標準化 |
| 記録 | 監査記録、レビュー議事録、ログ、承認履歴 | 実施した証拠 |
認証審査では、組織の規模や適用範囲に応じて異なるが、次のような文書・記録が確認されやすい。
重要なのは、文書が「実態に合っていること」です。審査対策として過度に高度な規程を作り、現場が守れない状態になることは避けるべきです。守れない規程は、審査上も法務上も不利な証拠になります。
証跡は、審査のためだけでなく、事故時の法的防御にも必要です。アクセスログ、変更履歴、承認履歴、教育履歴、委託先評価、リスク受容、インシデント対応、顧客通知、当局報告、復旧作業、原因分析、再発防止策の記録は、紛争時の重要証拠となります。
ただし、証跡を残せばよいというものではありません。保存期間、アクセス権限、改ざん防止、プライバシー、労務上のモニタリングルール、電子データの証拠性を考慮する必要があります。
顧客契約、委託先管理、クラウド責任分界をISMSに接続します。
ISMS認証取得企業であっても、顧客契約の情報セキュリティ条項が不十分なら、事故時の責任範囲が曖昧になります。次の観点を契約に反映することが有効です。
次の比較表は、ISMS認証取得と社内体制構築を契約条項に接続するに関する項目を整理したものです。確認漏れを防ぐために重要です。各行から、実務で確認すべき内容と担当領域を読み取ってください。
| 論点 | 契約上の検討事項 |
|---|---|
| 秘密情報 | 定義、除外情報、管理方法、利用目的 |
| 個人情報 | 委託か第三者提供か、再委託、越境移転 |
| セキュリティ基準 | ISMS、社内規程、顧客基準、個別仕様 |
| インシデント通知 | 通知期限、通知内容、暫定報告、最終報告 |
| 監査 | 書面監査、現地監査、第三者報告書、頻度 |
| 再委託 | 事前承諾、通知、再委託先管理、責任 |
| クラウド | 利用可否、地域、サブプロセッサ、責任分界 |
| データ返還・消去 | 契約終了時、バックアップ、消去証明 |
| 損害賠償 | 直接損害、間接損害、上限、例外 |
| 法令報告 | 当局報告、本人通知、顧客承認 |
| 変更管理 | 重要な管理策変更、拠点変更、委託先変更 |
ISMSは自社内だけでは完結しません。クラウド、SaaS、データセンター、開発会社、保守会社、コールセンター、配送、廃棄業者、給与計算、採用管理、電子契約、会計システムなど、多数の外部委託先が情報資産に関与します。
委託先管理では、次のサイクルが必要です。
委託先評価は、質問票を送るだけでは足りません。重要委託先については、認証取得状況、SOCレポート、脆弱性対応、障害履歴、サポート体制、バックアップ、サブプロセッサ、データ保管国、契約上の監査権、インシデント通知期限を確認する必要があります。
クラウドを利用する場合、「クラウド事業者が安全だから自社は安全」とは言えません。クラウドには責任共有モデルがあります。クラウド事業者がデータセンターや基盤を管理していても、アカウント設定、権限、暗号鍵、ログ取得、公開範囲、バックアップ、アプリケーション脆弱性は利用者側の責任となることが多いです。
法務部門は、クラウド契約の標準約款、データ処理条件、SLA、サポート条件、責任制限、準拠法、データ所在地、サブプロセッサ、監査資料、削除手続を確認する必要があります。
個人情報台帳、漏えい等対応、プライバシーマークとの違いを確認します。
個人情報保護法対応では、個人情報の種類、取得元、利用目的、保管場所、委託先、第三者提供、保存期間、アクセス権限を管理する必要があります。ISMSの情報資産台帳と個人情報台帳を別々に作ると、更新漏れや不整合が起きやすい。両者は一体または相互参照できる形にする必要があります。
個人情報保護委員会への報告・本人通知が必要な事態では、初動が重要です。PPCは、該当する漏えい等が発生した場合、速やか、概ね3〜5日以内に報告を行うこと、本人への通知では概要、個人データの項目、原因などを本人に分かりやすい方法で行うことを説明しています。
ISMS上のインシデント対応規程には、少なくとも次を含めるべきです。
ISMSは情報セキュリティマネジメントシステムの認証で、プライバシーマークは個人情報保護マネジメントシステムに関する制度です。どちらが優れているという問題ではなく、目的が異なります。個人情報を中心に社会的信頼を示したい場合はプライバシーマーク、情報資産全般のリスク管理を示したい場合はISMSが有力です。両方を取得する企業もありますが、文書体系・教育・監査・委託先管理・事故対応を統合しなければ、運用負荷が過大になります。
事前準備、証拠保全、法務判断、事後改善までを危機管理として整理します。
サイバーインシデント対応は、発生してから考えるものではありません。事前に、連絡網、判断権限、外部専門家、フォレンジック会社、外部弁護士、広報、顧客対応、当局報告、保険会社、クラウド事業者、委託先との連携を決めておく必要があります。
典型的な対応チームは次のとおりです。
次の比較表は、ISMS認証取得と社内体制構築のインシデント対応と危機管理に関する項目を整理したものです。確認漏れを防ぐために重要です。各行から、実務で確認すべき内容と担当領域を読み取ってください。
| 役割 | 主な担当 |
|---|---|
| インシデント責任者 | CISO、担当役員 |
| 技術対応 | 情報システム、SOC、CSIRT、外部フォレンジック |
| 法務対応 | 企業内弁護士、外部弁護士、法務部 |
| 個人情報対応 | DPO相当者、個人情報保護担当 |
| 顧客対応 | 営業、カスタマーサクセス |
| 広報対応 | 広報、IR |
| 労務対応 | 人事、社労士、弁護士 |
| 経営判断 | 代表取締役、取締役会、危機対策本部 |
| 監査対応 | 内部監査、監査役、公認会計士 |
事故時には、善意の復旧作業が証拠を消してしまうことがあります。ログ、端末、サーバイメージ、メール、チャット、アクセス履歴、クラウド監査ログ、設定変更履歴、EDRアラート、VPNログ、IDプロバイダログを保全する手順が必要です。デジタルフォレンジック専門家を早期に関与させる必要となる場面もあります。
法務部門は、次を判断します。
日本法では、米国型の広範な attorney-client privilege がそのまま認められるわけではないため、外部弁護士に依頼した調査であっても、記録の作成・保管・共有範囲には慎重な設計が必要です。
インシデント後の改善は、ISMSの有効性を示す重要な証跡となります。原因分析、再発防止策、教育、技術対策、契約見直し、委託先評価、リスクアセスメント再実施、マネジメントレビューへの報告を行います。事故を隠す文化ではISMSは機能しません。事故を学習に変える仕組みが必要です。
内部監査とマネジメントレビューを、継続改善の仕組みとして運用します。
内部監査は、認証審査のためのリハーサルではなく、組織のISMSが要求事項、自社規程、法令・契約要求事項に適合し、有効に機能しているかを確認する活動です。
内部監査では、次の3層を見るべきです。
内部監査では、次のような質問が有効です。
マネジメントレビューは、経営層がISMSの適切性、妥当性、有効性を確認し、改善方針を決める場です。単なる報告会ではありません。
レビューでは、少なくとも次の情報を扱うべきです。
出力として、方針変更、目的変更、資源配分、リスク対応、組織体制変更、規程改定、教育強化、技術投資、委託先見直しなどの決定を記録します。
認証機関の選定、第一段階審査、第二段階審査、不適合対応を確認します。
JIPDECは、ISMS等の認証取得の申請先は認定された認証機関です。ISMS-ACは認証機関を認定する機関であって組織に対するISMS認証登録は行わない旨を説明しています。 したがって、企業は認証機関を選定し、見積、審査日程、審査範囲、審査員の専門性、費用、審査方針を確認します。
選定時の確認事項は次のとおりです。
第一段階審査では、主に文書、適用範囲、リスクアセスメント、SoA、内部監査、マネジメントレビュー、審査準備状況が確認されます。ここで重大な不足があると、第二段階審査に進めない場合や、是正が必要となる場合があります。
第二段階審査では、実際の運用が確認されます。審査員は、経営層、ISMS事務局、現場部門、IT、法務、人事、総務、内部監査などにインタビューし、記録と実態の整合を確認します。
第二段階審査でよく問題になるのは、次のような点です。
不適合を受けた場合、原因分析、是正処置、再発防止、効果確認を行います。不適合を「審査員に指摘されたから直す」と捉えるのではなく、組織の管理上の弱点が見つかったと捉えるべきです。
中小企業が90日、180日、365日で進める現実的な順序を整理します。
中小企業では、専任CISOや法務部、内部監査部門が存在しないことも多いです。しかし、ISMS認証取得と社内体制構築は、組織規模に応じて設計できます。ISOも、ISO/IEC 27001はあらゆる規模・業種の組織に適用できると説明しています。
IPAは中小企業向けに「中小企業の情報セキュリティ対策ガイドライン」を公開しており、第4.0版では、経営者が認識し実施すべき指針と、社内で対策を実践する手順・手法をまとめている旨を説明しています。また、同ガイドラインは個人事業主・小規模事業者を含む中小企業等の利用を想定しています。
中小企業では、次の順序が現実的です。
中小企業で最も避けるべきなのは、大企業向けの重厚な規程をそのまま導入することです。規程は少なくてもよいが、守れること、証跡が残ること、経営者が説明できることが重要です。
弁護士、法務、監査、人事労務、知財、会計、フォレンジックの関与点を確認します。
経営者不在、範囲不一致、証跡不足、法務不在、取得後放置を避けます。
ISMSを担当者任せにすると、リスク受容、資源配分、部門横断の調整が進みません。経営者が最低限、方針、目的、適用範囲、重大リスク、資源、レビューに関与することが必要です。
営業資料では「全社でISMS取得」と表現していますが、実際の認証範囲は一部部門だけという場合、取引先への説明が問題になります。認証範囲の表示は正確に行う必要があります。
規程を増やしすぎると、現場が守れません。規程は、リスクに応じて必要な粒度にします。重要なのは、文書数ではなく運用可能性です。
「やっています」と言っても、審査では証跡が求められます。教育、権限棚卸し、委託先評価、バックアップ、ログ確認、内部監査、レビューの記録を残します。
契約上の通知期限や委託先義務を把握しないままインシデント対応規程を作ると、事故時に契約違反となります。法務部門は早期に関与する必要があります。
質問票を送って回収するだけでは不十分です。重要委託先は、契約、認証、障害履歴、再委託、監査資料、インシデント通知体制を確認します。
自分で作った規程を自分で監査すると、監査の有効性が弱い。小規模組織でも、可能な限り担当外の者、外部専門家、他部門を活用します。
ISMSは取得後が本番です。年次サーベイランス、3年ごとの再認証、組織変更、新サービス、法改正、インシデント、委託先変更に対応し続ける必要があります。
取締役会・経営会議で確認する質問を整理します。
取締役、監査役、社外取締役、CLO、CISO、内部監査責任者は、次の質問を定期的に確認する必要があります。
開始前、構築中、審査前、取得後の実務確認事項を整理します。
よくある疑問を一般情報として整理します。
一般的には、ISMS認証は情報セキュリティマネジメントシステムが要求事項に適合していることを示す第三者認証で、個人情報保護法への完全適合を保証するものではありません。安全管理措置、委託先監督、漏えい等報告、本人通知などは、別途、法令と実態に即して整備する必要があります。具体的な対応は、取扱情報、委託関係、事故態様、契約内容によって変わるため、弁護士等の専門家へ相談する必要があります。
一般的には、組織規模、適用範囲、既存体制、委託先数、システム数によって期間は変わります。小規模で既に規程・運用がある企業なら半年程度で準備できることもありますが、全社規模、複数拠点、クラウド・委託先が多い企業では1年以上かかることもあります。具体的な計画は、認証範囲と運用証跡の蓄積状況を踏まえて認証機関や専門家に確認する必要があります。
一般的には、法務部門は初期段階から関与することが重要とされています。適用範囲、法令・契約要求事項、インシデント通知、委託先管理、個人情報、秘密保持、顧客説明に関わるためです。ただし、組織体制や契約関係によって関与範囲は変わります。具体的な役割分担は、社内規程と契約状況を整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、認証範囲外でも、範囲内業務に影響する部門はインターフェース管理が必要とされています。人事、総務、法務、経理、親会社、委託先、クラウド管理者が範囲内業務を支えている場合、その関係を整理する必要があります。具体的な管理範囲は、業務実態、システム構成、委託関係、認証機関の審査方針によって変わります。
一般的には、外部コンサルタントは設計支援、文書化支援、教育支援、内部監査支援として有用です。一方で、ISMSは組織自身が運用する仕組みで、審査では現場が説明できることが求められます。責任まで外部へ移すことはできないため、社内の責任者、経営層、関係部門が理解して運用できる体制を整える必要があります。
一般的には、リスク対応には技術対策、規程、教育、契約、保険、委託先変更、業務廃止、リスク受容など複数の選択肢があります。重要なのは、リスクに応じた合理的な対応を選び、その理由を説明できることです。具体的な対応は、情報資産の重要度、法令・契約上の義務、費用、事業継続への影響によって変わります。
一般的には、適用範囲、リスクアセスメント結果、適用宣言書が中核文書とされています。これらは、何を守るのか、どのリスクを重視するのか、どの管理策をなぜ採用するのかを示すためです。ただし、組織規模、業種、契約、委託先構成によって重要文書は変わる可能性があります。具体的な文書体系は、認証機関や専門家へ確認する必要があります。
認証取得を企業の信用、契約履行、法令遵守、事業継続に結び付けます。
ISMS認証取得と社内体制構築は、情報システム部門だけの作業ではありません。企業法務、個人情報保護、契約管理、内部統制、労務、知財、会計、内部監査、経営判断を統合するプロジェクトです。
ISMSの本質は、規程を作ることでも、認証ロゴを得ることでもありません。情報資産を特定し、リスクを評価し、経営として受容可能な水準を決め、管理策を実装し、証跡を残し、監査し、レビューし、改善することです。認証は、その仕組みが一定の要求事項に適合していることを第三者に説明するための手段です。
実務上の成功条件は、次の5点に集約されます。
企業がデータ、クラウド、AI、外部委託、グローバル取引に依存するほど、情報セキュリティは経営そのものになります。したがって、ISMS認証取得と社内体制構築は、単なるセキュリティ認証ではなく、企業の信用、契約履行能力、法令遵守、事業継続、ガバナンスを支える基盤として位置づけることが重要です。
制度・規格・公的情報を確認するための資料名を整理します。