>
>
公開日
最終更新日
クラウドサービス、リモートワーク、生成AIの利用が業務に定着した現在、情報資産を社内ネットワークだけで守る考え方では不十分です。セキュリティポリシーは、従業員、委託先、利用するSaaSを含めて「誰が、どの情報を、どの条件で扱えるか」を決める組織の共通ルールです。
ただし、ポリシーを作成しても、現場が読めない長文になったり、生成AIを一律禁止してシャドーAIを招いたりすると、かえってリスクが高まります。この記事では、情報セキュリティポリシーとは何かという基本から、実務で使える文書体系、策定・運用のチェックリスト、失敗しやすい運用までを具体的に整理します。
セキュリティポリシーとは
セキュリティポリシーとは、情報資産を守るために組織が定める基本方針・対策基準・実施手順から成る文書体系です。
本記事のポイント
セキュリティポリシーは、理念だけではなく、具体的な設定基準と現場手順までをつなぐ3階層構造で運用します。
生成AI、クラウド、外部委託先を利用する組織では、従来の端末・パスワード規程だけでは管理範囲が足りません。
策定後は年1回の定期見直しと、インシデント後の臨時改定をルール化します。
現場向けには長大な規程集ではなく、判断に使えるハンドブックと例外申請フローを用意します。
情報セキュリティポリシーの目的は、機密性・完全性・可用性を維持し、情報漏えい、改ざん、サービス停止などの損害を抑えることです。情報資産には顧客情報、従業員情報、契約書、ソースコード、営業資料だけでなく、SaaSの設定情報、認証情報、生成AIに入力するデータも含まれます。
ポリシーは、ファイアウォールの個別設定値やパスワードの変更手順を1冊に詰め込む文書ではありません。経営層が承認する上位方針、情シスや各部門が守る対策基準、担当者が日々実行する手順を分けることで、改定しやすく、監査可能な状態になります。
セキュリティポリシーの対象範囲
対象範囲は、社内のPCやネットワークに限定せず、利用者・情報・委託先・クラウドまで明示します。
対象者には役員、正社員、契約社員、派遣社員だけでなく、業務委託先や一時的にシステムへ接続する保守事業者も含めます。対象システムには、ID管理基盤、SaaS、IaaS、業務アプリケーション、端末、ネットワーク機器、紙媒体の情報を列挙します。対象を曖昧にすると、「委託先の端末は対象外」「無償の生成AIは規程外」といった管理の空白が生じます。
情報資産の棚卸しでは、情報資産の分類と管理を先に整理すると、保護すべき対象とアクセス権の範囲を決めやすくなります。
情報セキュリティポリシーの基本方針と文書体系
情報セキュリティポリシーは、経営判断を示す基本方針、守るべき基準、実務の手順に分けると、現場で使える文書になります。
総務省は、国民のためのサイバーセキュリティサイトで、情報セキュリティポリシーを基本方針・対策基準・実施手順の階層で整備する考え方を紹介しています。3層を混在させないことが、改定負荷と運用ミスを減らす基本です。
階層 | 主な内容 | 承認・管理の主体 | 改定の目安 |
|---|---|---|---|
基本方針 | 目的、適用範囲、法令遵守、責任体制、違反時の考え方 | 経営層 | 年1回または経営・法令変更時 |
対策基準 | アクセス管理、端末管理、委託先評価、ログ、バックアップの最低基準 | 情報セキュリティ責任者 | 年1回または脅威・サービス変更時 |
実施手順 | アカウント発行、退職者の権限削除、事故連絡、復旧、例外申請の手順 | 情シス・業務部門 | 運用変更時に随時 |
基本方針に記載する宣言事項
基本方針には、組織が何を守り、誰が責任を負い、違反時にどう扱うかを簡潔に記載します。
最低限、情報資産を事業継続と顧客信頼の基盤として扱うこと、適用対象、情報セキュリティ責任者と各部門長の責務、教育・監査の実施、法令や契約の遵守、インシデント報告の原則を明記します。技術的な製品名やパスワード文字数は基本方針に書かず、対策基準へ分離します。製品の入れ替えや技術変更のたびに経営承認を取り直す事態を避けられます。
対策基準と実施手順の役割分担
対策基準では守るべき最低条件を定め、実施手順では担当者が迷わず実行できる操作順を定めます。
たとえば対策基準には「特権アカウントは多要素認証を必須とする」「重要情報を扱うSaaSでは監査ログを保存する」と記載します。実施手順には「退職日までに人事部門が申請し、情シスがIDを無効化する」「管理者が月次で特権IDを棚卸しする」と担当・期限・証跡を記載します。情報セキュリティ対策の全体像と結び付けることで、文書だけが独立する状態を防げます。
▲ セキュリティポリシーを支える3階層の文書体系とそれぞれの役割構造
セキュリティポリシーが必要な理由
セキュリティポリシーは、技術対策を組織横断で機能させ、事故時の判断と取引先への説明を可能にするために必要です。
IPAは「2024年度 中小企業における情報セキュリティ対策に関する実態調査」（IPA公式サイト「情報セキュリティ対策支援サイト」内に掲載、2025年公開）で、中小企業を対象とした調査の結果として、情報セキュリティ対策をルール化して従業員に明示している企業は39.2%にとどまると報告しています。同調査では、約7割の中小企業がセキュリティ対策を組織的に行っていないと回答しています。ルールが存在しない場合、部門や担当者ごとに判断が分かれ、権限付与、データ持ち出し、委託先管理の統制ができません。
IPAは中小企業向けに情報セキュリティ対策支援サイトを公開しており、経営者の関与、組織的な管理、従業員教育を対策の基盤として示しています。ポリシーは技術製品の代替ではありませんが、技術・教育・監査・復旧手順を同じ方向にそろえる役割を持ちます。
被害の拡大と復旧コスト
サイバー攻撃の被害は情報漏えいだけでは終わらず、復旧作業、取引停止、信用低下へ連鎖します。
IPAが公表した中小企業向け資料（「中小企業の情報セキュリティ対策ガイドライン」関連資料、IPA公式サイト掲載）では、サイバー攻撃を受けた中小企業の被害額は平均73万円、最大1億円、復旧までの平均期間は5.8日と紹介されています。また、被害を受けた企業の約7割で取引先企業にも影響が及んだとIPAは紹介しています。これらの数値は同資料記載の調査時点のものであり、IPAの調査資料ページで最新版を確認できます。自社だけで復旧できればよいという考え方では、委託先や取引先を含む事業継続リスクを管理できません。
警察庁は「令和7年におけるサイバー空間をめぐる脅威の情勢等について」で、不正アクセス行為の認知件数を令和7年：7,190件、令和6年：5,358件、令和5年：6,312件と集計しています。警察庁のサイバー空間をめぐる脅威の情勢は、ID・パスワードの窃取やランサムウェアが継続的な脅威であることを示しています。
社内不正と取引先信頼の確保
ポリシーは外部攻撃だけでなく、権限の残存、持ち出し、誤送信などの内部起因リスクにも対応します。
入社・異動・退職のたびに誰が権限を承認し、いつ削除したかを記録しなければ、不要なアクセス権が残ります。さらに、取引先からセキュリティチェックシートへの回答を求められた際、方針、教育記録、委託先管理、インシデント対応の証跡がなければ、実施状況を説明できません。ポリシーは営業部門や調達部門の取引継続にも関わる統制文書です。
セキュリティポリシーに盛り込むべき内容
現在のセキュリティポリシーには、従来の端末管理に加え、生成AI、ゼロトラスト、クラウド、委託先を対象にした規程が必要です。
すべての項目を上位方針に書く必要はありません。基本方針の下に、アクセス管理規程、クラウド利用規程、生成AI利用ガイドライン、委託先管理基準、インシデント対応手順を配置し、改定単位を分けます。
アクセス管理とゼロトラスト
アクセス管理は、社内ネットワークに接続していることではなく、利用者・端末・アクセス状況を継続的に検証する考え方で設計します。
ゼロトラストでは、社内からの接続でも無条件に信用しません。IDごとに多要素認証を適用し、職務に必要な最小権限のみを付与し、管理者権限の利用を記録します。端末のOS更新、ディスク暗号化、画面ロック、EDRの稼働状況もアクセス許可の条件にできます。クラウドを利用している場合は、VPNの有無だけではなく、ID・端末・データ・ログの管理基準を規程化します。
生成AI利用規程とベストプラクティス
生成AI利用規程では、入力してよい情報、利用を許可するサービス、生成物の確認責任を明確にします。
総務省と経済産業省は、AI事業者ガイドラインを公表し、AIの安全性、プライバシー、公平性、透明性、アカウンタビリティーを示しています。社内規程では、顧客情報、個人情報、未公表の財務情報、認証情報、ソースコードなどを、承認済みでない外部AIへ入力しないルールを定めます。
生成AIセキュリティのベストプラクティスとしては、用途別に許可ツールを定めること、機密データを匿名化または要約してから入力すること、出力内容を業務責任者が検証すること、プロンプトインジェクションを想定して外部文書の指示を無条件に実行しないことが挙げられます。生成物は正確性、著作権、個人情報、差別的表現の観点で確認し、AIの出力をそのまま顧客向け文書やプログラムへ反映しない手順にします。
クラウドサービスとシャドーIT
クラウド利用規程では、導入前審査、アカウント管理、データ保存先、契約終了時の削除を定めます。
部門が独自に契約したSaaSは、退職者アカウントの放置、契約更新の見落とし、データの所在不明につながります。利用申請では、取り扱う情報の区分、管理者、監査ログの取得可否、データ削除方法、再委託の有無を確認します。監査ログをAPIまたはCSVで取得できる場合は定期棚卸しへ組み込み、取得できない場合は重要情報を保管しない用途へ限定する判断ができます。
サプライチェーンと外部委託先管理
委託先管理では、契約時の確認だけでなく、委託中の報告と契約終了時のデータ返却・削除までを管理します。
経済産業省と内閣官房国家サイバー統括室は、サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）の構築を進めています。制度の対象範囲・評価区分・適用時期は取引形態や業種によって変わります。調達部門は経済産業省の「サプライチェーンセキュリティ対策評価制度」関連ページおよび内閣官房国家サイバー統括室の公表資料で自社の取引形態が対象に該当するかを確認し、対象となる場合は示された評価基準に合わせて委託先質問票と契約条項を更新します。対象外と判断した場合でも、委託先の多要素認証、脆弱性対応、事故連絡期限、再委託管理、データ消去証明を確認項目に残すことで、実務上の最低限の統制を維持できます。
セキュリティポリシー策定の5つのステップ
セキュリティポリシーは、雛形を先に埋めるのではなく、資産とリスクを把握してから責任者・基準・手順を順に決めます。
策定作業を情シスだけに任せると、業務実態や契約上の制約が反映されません。経営層、情シス、法務・総務、人事、主要業務部門、調達部門がそれぞれの責任範囲を確認する進め方が有効です。
情報資産と業務を棚卸しします。顧客情報、従業員情報、契約書、ソースコード、SaaS、管理者ID、委託先を一覧化し、重要度と保管場所を整理します。
リスクを評価します。漏えい、改ざん、停止、アカウント乗っ取り、ランサムウェア、誤送信、委託先事故を洗い出し、発生可能性と影響度で優先順位を付けます。リスクアセスメントの進め方を参照すると、評価項目を業務へ落とし込みやすくなります。
文書体系と責任体制を決めます。基本方針、対策基準、実施手順の管理者を決め、経営層の承認範囲と部門長の責任を明記します。
対策基準と例外フローを作成します。認証、権限、端末、クラウド、生成AI、委託先、バックアップ、事故対応の最低条件を定め、業務上の例外申請の承認者と期限を決めます。
教育・監査を準備して運用を開始します。規程公開、ハンドブック配布、研修、遵守確認、監査ログ確認、改定予定日を同時に設定します。
策定・運用チェックリスト
以下の項目に未決定が残る場合は、その項目を担当者・期限付きの課題として登録してから公開します。
確認領域 | チェック項目 | 未整備時の対応 |
|---|---|---|
体制 | 経営承認者、情報セキュリティ責任者、各部門の責任者が決まっている | 責任分界を決め、承認経路を文書化します |
資産 | 重要情報、SaaS、管理者ID、委託先の一覧がある | 棚卸し台帳を作成し、更新担当を指定します |
認証 | 特権IDと重要SaaSに多要素認証を適用している | 対象IDから段階的に設定し、例外には期限を付けます |
生成AI | 入力禁止情報、許可ツール、出力確認の担当が決まっている | 業務利用を限定し、利用申請と教育を開始します |
委託先 | 事故報告、再委託、データ削除を契約・質問票で確認している | 新規契約から基準を適用し、既存契約は更新時に見直します |
事故対応 | 連絡先、初動、証拠保全、顧客・取引先への連絡判断がある | 連絡網と初動手順を作り、机上訓練で検証します |
承認と公開の判断基準
公開前には、文書の完成度よりも、責任者・対象範囲・例外処理・教育計画が決まっているかを確認します。
アクセス権の申請先や事故連絡先が未定の場合、ポリシーを公開しても現場は行動できません。一方で、すべてのSaaS設定値を待って公開を遅らせる必要はありません。上位方針と最低基準を承認し、設定値や操作手順は対象システムごとに順次整備することで、統制と実装を並行できます。
▲ セキュリティポリシー策定における5つの実行ステップ
形骸化を防ぐセキュリティポリシーの運用・教育とPDCA
セキュリティポリシーは、周知、訓練、監査、改定を繰り返して初めて組織の行動基準として機能します。
NRIセキュアテクノロジーズは、同社が毎年公表する調査レポート「NRI Secure Insight」（最新版はNRIセキュアテクノロジーズ公式サイト「NRI Secure Insight」ページで公開）で、セキュリティ遵守状況やリスクを正確に把握できている企業は約16%にとどまるという調査結果を紹介しています。同レポートは国内企業を対象とした調査で、規模・業種別の集計条件は各年度版の公開ページに掲載されており、数値は年度によって異なる場合があります。規程が存在していても、実際の権限・端末・SaaSの利用状況と一致していなければ、統制は機能していません。
年1回の定期見直しと臨時改定
定期見直しは年1回、臨時改定は重大インシデント、法令変更、重要なクラウド導入時に実施します。
年次レビューでは、資産台帳、退職者ID、特権ID、SaaS契約、委託先、教育受講率、インシデント記録を確認します。見直しの議題を「規程の文章を直すこと」だけにすると、現場の運用不備を見逃します。「実施手順どおりに証跡が残ったか」「例外申請が期限切れになっていないか」を監査項目にします。
ランサムウェア感染、誤送信、アカウント乗っ取りなどが発生した場合は、原因分析後に対策基準と実施手順の両方を見直します。技術対策だけを追加しても、報告経路や権限承認の問題が残れば同種事故を繰り返します。
従業員向けハンドブックと階層別教育
従業員には規程原文だけを配布せず、日常業務で判断するための短いハンドブックを渡します。
ハンドブックには、「怪しいメールを開いた場合の連絡先」「外部共有リンクを発行する条件」「生成AIに入力してはいけない情報」「私用端末を使う際の条件」「退職・異動時の返却物」を1ページ単位で記載します。一般従業員には標的型メール、パスワード、データ共有、生成AIを中心に教育し、管理職には事故報告と部門責任、管理者には特権ID・ログ・復旧を中心に教育します。
教育は受講率だけで終わらせず、標的型メール訓練の報告率、端末更新率、期限切れ例外の件数など、行動結果を確認します。たとえば訓練メールの報告窓口を設けた後は、開封率だけでなく、疑わしいメールを報告できた割合を毎回比較すると、初動能力の変化を測れます。
CSIRTとインシデント対応の連携
インシデント対応体制では、発見者、一次受け、技術対応、経営報告、対外連絡の役割を分けます。
CSIRTを設置する場合は、常設の専門チームでなければならないわけではありません。まずは情報セキュリティ責任者、情シス、法務、広報、人事、事業部門の連絡先を定め、夜間・休日を含む連絡経路を文書化します。端末隔離やアカウント停止を誰が判断するか、証拠保全を誰が行うか、顧客・取引先への連絡を誰が承認するかを決めると、初動の混乱を抑えられます。
セキュリティポリシー運用のよくある失敗パターンと対策
セキュリティポリシーの失敗は、ルール不足よりも、現場が守れない設計と例外管理の欠如から起こります。
禁止事項を増やすだけでは、利便性を優先する現場が別の手段を探し、見えないリスクが増えます。以下の失敗を事前に避けることで、ポリシーを業務の障害ではなく判断基準として機能させられます。
長文化による未読状態
40ページを超える規程集を全従業員にそのまま読ませる運用では、必要な場面でルールを参照できません。
基本方針・対策基準・実施手順を分け、従業員向けには10項目程度のハンドブックを作成します。「外部共有の前に確認する項目」「紛失時の連絡手順」のように業務場面別にまとめると、検索しやすくなります。規程原文は監査・管理者向け、ハンドブックは利用者向けと役割を分けます。
生成AIの一律禁止によるシャドーAI
生成AIを全面禁止すると、現場が個人アカウントや未承認サービスで利用し、利用実態を把握できなくなります。
機密情報の入力禁止は維持しつつ、要約、議事録のたたき台、文章校正など、非機密情報で使える許可用途を定めます。法人契約の有無、入力データの学習利用設定、ログ管理、管理者機能を確認できるサービスは限定検証に進めます。これらを確認できないサービスは、公開情報のみを扱う用途へ限定することで、禁止と放任の間に運用可能な基準を作れます。
例外申請フローの不在
業務上の例外を認める手順がないと、口頭承認や独自ルールが増え、監査時に経緯を説明できません。
例外申請には、対象システム、例外の理由、リスク、代替策、承認者、有効期限、見直し日を記録します。期限を設定しない恒久例外は、実質的に規程を無効化します。例外が頻発する項目は、現場の業務に合わない基準である可能性が高いため、個別承認を繰り返すのではなく基準そのものを改定します。
策定後の放置
ポリシーを一度作成して数年間更新しない状態では、新しいSaaS、生成AI、委託先、脅威に対応できません。
文書ごとに改定責任者、見直し月、確認する証跡を記載します。年次レビューで変更がなかった場合も、「変更なし」と判断した根拠を残します。退職者IDの削除漏れ、未承認SaaS、教育未受講などの監査結果を次年度の改善項目へ反映すれば、PDCAが文書上の形式ではなく運用改善として回ります。
▲ シャドーAI・シャドーITを防ぐための業務ツール利用判断フロー
国内企業におけるセキュリティポリシー運用の事例
国内企業の事例では、クラウド利用、外部委託、リモートワークの変化に合わせて、ポリシーと運用手順を更新する取り組みが見られます。
以下の各事例は、各社の公式サイト・プレスリリース・業界誌等で公開されている情報をもとにまとめています。具体的な取り組み内容や実施時期は各社の公開資料で確認できます。定量的な削減効果が公開情報で確認できない事例については、成果を推測せず、公開されている施策の内容に限定して記載しています。事例を自社へ適用する際は、導入製品だけを模倣するのではなく、どの業務変化に対して、誰の責任と手順を見直したかを参照してください。
セコム株式会社のクラウドセキュリティ管理
セコム株式会社は、パブリッククラウド活用の拡大に対応し、クラウドセキュリティの可視化と運用体制の整備を進めています（出典: Cloudbase導入事例：セコム株式会社）。
クラウド環境では、開発部門、運用部門、セキュリティ部門が別々に設定を管理すると、責任範囲が不明確になりやすい点が課題です。共通ポリシーと対応マニュアルを整備し、設定状況を可視化する取り組みは、クラウド利用規程を作る際の参考になります。自社でクラウドアカウントを複数運用している場合は、まず管理者権限、多要素認証、公開設定、ログ保存の4項目を共通基準にします。
コープきんき事業連合のPDCA運用
生活協同組合連合会コープきんき事業連合は、脆弱性の可視化を起点に、現状把握、体制整備、振り返りを継続する運用を進めています（出典: 網屋 導入事例：コープきんき事業連合）。
ポリシー策定で見落とされやすいのは、「できていないこと」を記録する仕組みです。実施済み対策だけを並べても、未対応の端末、未受講者、未評価の委託先は把握できません。月次または四半期ごとに未対応項目を一覧化し、担当者と期限を割り当てることで、ポリシーを改善活動へ接続できます。
まとめ
セキュリティポリシーは、情報資産を守るための宣言文ではなく、基本方針・対策基準・実施手順を通じて、日々の判断と事故対応を支える仕組みです。2025年から2026年にかけては、生成AI、クラウド、ゼロトラスト、サプライチェーンを前提に、対象範囲を見直す必要があります。
明日から着手するなら、まず利用中のSaaS、管理者ID、重要情報、外部委託先を1つの台帳に集めます。そのうえで、責任者、生成AIへの入力禁止情報、退職者IDの削除手順、例外申請の4項目を決めると、ポリシーを実際の運用へつなげられます。年1回の見直しと教育を予定表に入れ、作成して終わらない統制を作ります。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
