情報セキュリティポリシーは、企業の情報資産を守るための基本方針と行動指針を文書化したものです。形式的に整えるだけでは現場で機能せず、実態と乖離した「棚に置かれるだけの規程」になりがちです。

しかし、中堅企業ではクラウドサービスの利用拡大、リモートワークの定着、退職者によるアカウント残存、シャドーITの増加など、ポリシーが想定していなかったリスクが急速に広がっています。形式と実態のズレを放置すると、ISMSやSOC 2などの認証審査で指摘を受けるだけでなく、実際のインシデント発生時に対応が機能しません。

本記事では、情報セキュリティポリシーをゼロから設計・改訂するための実践的な作り方を、中堅企業のIT管理担当者向けに整理します。3階層モデルの構造、必須項目、策定ステップ、運用フェーズで陥りがちな落とし穴まで、現場で使える形で解説します。

対象読者は、情報セキュリティポリシーの策定・改訂を担当する情シス責任者、ISMSやSOC 2の認証取得を主導する管理部門、現場で実装する立場の管理職です。

情報セキュリティポリシーとは何か｜役割と中堅企業での重要性

情報セキュリティポリシーとは、組織が情報資産を保護するために定める基本方針・対策基準・実施手順を体系化した文書群です。経営層の意思を従業員の日常行動にまで落とし込むための「橋渡し」の役割を果たします。

中堅企業では従業員数が増え、部門ごとに業務プロセスが分岐するなかで、口頭ルールや属人的な運用では統制が効かなくなります。ポリシーは、誰がどのような判断基準で情報を扱うべきかを明文化し、判断を組織として一貫させる装置です。

経営方針と現場行動をつなぐ位置づけ

ポリシーは経営層が定める基本方針を起点にし、対策基準で部門ごとの責任範囲を示し、実施手順で具体的な手順書まで落とし込みます。この3階層が連動していないと、現場は何を守るべきか判断できません。

例えば「機密情報の社外持ち出し禁止」という方針を掲げただけでは、USB持ち出し、私用クラウド共有、スマートフォン撮影といった具体的シーンで判断できません。実施手順まで明確にして、初めてポリシーは機能します。

規格・法令との関係

ポリシーはISO/IEC 27001、Pマーク、SOC 2（保証報告書）、J-SOX、APPI、GDPRなど複数の規格・法令の要件を統合する文書として位置づけられます。ISMAPは主に政府クラウドサービス提供事業者向けの評価制度です。各規格が要求する管理策をポリシーに反映することで、認証取得と日常運用を両立できます。

中堅企業では複数規格を同時に対応するケースが増えており、規格ごとに別文書を作るのではなく、共通ポリシーに統合する設計が現実的です。重複する管理策を一本化することで、改訂負荷と運用コストを抑えられます。

参考：ISO/IEC 27001:2022 概要 - JIPDEC

情報セキュリティポリシーの3階層構造｜基本方針・対策基準・実施手順

ポリシーは一枚岩の文書ではなく、抽象度の異なる3階層で構成します。階層を分けることで、改訂の影響範囲を局所化でき、現場での参照効率も上がります。

中堅企業の多くは、3階層を意識せず1冊の文書に詰め込んでしまい、改訂のたびに全社レビューが必要になる事態に陥ります。階層分離は運用負荷削減の出発点です。

第1階層：基本方針（Policy）

経営層の意思を表す最上位文書です。情報セキュリティに対する組織の姿勢、適用範囲、責任体制、違反時の措置などを宣言的に記述します。文量は2〜5ページ程度で、原則として頻繁な改訂は行いません。

基本方針は社外公開する企業も多く、顧客や取引先からの信頼の基盤になります。抽象度が高い分、解釈に幅が出ないよう、用語の定義と適用範囲を厳密に書く必要があります。

第2階層：対策基準（Standard）

基本方針を実現するための部門別・領域別の管理ルールです。アクセス制御、暗号化、物理セキュリティ、人的セキュリティ、サプライヤ管理、インシデント対応などのテーマごとに分割します。

対策基準は管理職が参照する文書として位置づけ、各項目に責任部署と遵守義務を明記します。中堅企業では10〜20本程度の対策基準を保持するケースが一般的です。

第3階層：実施手順（Procedure）

具体的な作業手順書・チェックリスト・運用マニュアルです。アカウント発行手順、退職者アカウント停止手順、インシデント連絡フロー、バックアップ実施手順など、現場が日常業務で参照します。

実施手順は変更頻度が高く、システムの導入・改修に応じて更新します。基本方針や対策基準を巻き込まず、手順だけを差し替えられる構造にすることで、改訂負荷を最小化できます。

参考：情報セキュリティ監査制度 - 経済産業省

情報セキュリティポリシーに含めるべき必須項目

ポリシーに何を書くかは、規格要件・法令要件・自社のリスク特性の3つから決まります。中堅企業向けに整理すると、以下の項目が標準的に必要です。

各項目は対策基準として独立した文書にするか、まとめて記載するかを設計時に判断します。改訂頻度と参照頻度の高い項目ほど、独立文書化する価値があります。

適用範囲・体制・責任分担

ポリシーが適用される組織・人・情報資産の範囲を明示します。グループ会社、業務委託先、派遣社員、退職者などの扱いを曖昧にすると、運用フェーズで解釈が分かれます。

責任分担は、CISO・情報セキュリティ委員会・各部門責任者・全従業員という階層で記述します。経営層がオーナーシップを持つ構造を明文化することで、現場任せの運用を防げます。

情報資産分類と取扱基準

情報資産を機密度別（極秘・秘・社外秘・公開）に分類し、それぞれの取扱基準を定めます。保管・送信・複製・破棄の各段階で、機密度ごとに許容される手段を明示します。

中堅企業では、SaaSやクラウドストレージへの保存可否、外部への共有可否、私物デバイスでの参照可否など、現代的な利用シーンに対応した基準が必要です。

アクセス制御・認証・特権管理

ID発行・変更・廃止のライフサイクル、認証要件（多要素認証、パスワード強度）、特権アカウントの管理、定期的なアクセスレビューを規定します。退職者アカウント残存はインシデントの主要原因です。

ISO/IEC 27001:2022のAnnex A「A.5.15 アクセス制御」「A.5.16 アイデンティティ管理」「A.5.17 認証情報」「A.5.18 アクセス権」が直接対応する領域です。

物理的・技術的・人的セキュリティ

物理的セキュリティはオフィス入退室、サーバルーム管理、デバイス保管。技術的セキュリティは暗号化、ネットワーク分離、ログ監視、脆弱性管理。人的セキュリティは雇用前審査、教育訓練、退職時手続きを含みます。

3つの側面をバランスよくカバーすることで、技術対策に偏らず、人とプロセスの脆弱性も補強できます。

インシデント対応・事業継続

インシデント発見時の連絡経路、初動対応、影響範囲特定、関係者通知、再発防止までのフローを定めます。APPI改正で個人データ漏えい時の報告義務化が強化された点（速報：3〜5日以内、確報：30日以内、不正目的の場合は60日以内）も反映が必要です。

事業継続計画（BCP）と接続し、災害・サイバー攻撃・サプライチェーン障害などの中断シナリオに対する復旧目標を含めます。

情報セキュリティポリシー策定の5ステップ

ポリシー策定は、いきなり文書を書き始めるのではなく、リスク特定から運用準備までを段階的に進めます。中堅企業向けの実践的なステップを解説します。

各ステップを飛ばすと、現場で機能しない「飾りのポリシー」になります。特にステップ1のリスク評価とステップ4の合意形成は、所要時間がかかっても省略してはいけません。

ステップ1：情報資産棚卸しとリスク評価

自社が保有する情報資産を業務プロセス単位で洗い出し、機密性・完全性・可用性の観点で価値を評価します。次に、各資産に対する脅威と脆弱性を特定し、リスクレベルを算出します。

中堅企業ではSaaS利用の実態把握が出発点です。シャドーITが残っている状態でポリシーを作っても、適用範囲外の領域でインシデントが起きます。SaaS管理ツールでの可視化が前提条件です。

ステップ2：参照規格・法令の特定

自社が対応すべき規格・法令を特定します。ISO/IEC 27001、Pマーク、SOC 2、J-SOX、APPI、GDPRなどから、業界・取引先要請・上場区分に応じて選択します。

複数規格に対応する場合は、要件を統合して重複を排除します。ISO/IEC 27001:2022の93個の管理策について、リスク評価に基づき適用・除外を判断し、適用宣言書（SoA）で管理できる構造にします。

ステップ3：3階層文書の起草

基本方針は経営層と合意したうえで、抽象度を高く保って起草します。対策基準は領域別にテーマを切り出し、責任部署と連携して内容を詰めます。実施手順は現場の運用担当が中心となって書きます。

ひな形は、IPAやJIPDECが公開している雛形を活用します。ゼロから作るより、既存テンプレートを自社特有の事情で調整するアプローチが効率的です。

ステップ4：レビュー・合意形成・承認

法務・人事・情シス・経営層で多角的にレビューします。特に労働契約や就業規則との整合、業務委託契約への反映、教育訓練計画との接続を確認します。

経営会議または取締役会で正式承認を取り、社内通達として全従業員に周知します。承認プロセスを文書化することで、ISMSやSOC 2の審査で求められる「経営層のコミットメント」を証明できます。

ステップ5：運用開始・教育・モニタリング

ポリシー適用日を定め、従業員教育を実施します。eラーニングや集合研修で全従業員に内容を周知し、理解度テストで定着を確認します。

運用開始後は、定期的な内部監査でポリシー遵守状況をモニタリングし、インシデントや業務変化に応じて改訂します。改訂サイクルは通常1〜2年ごとですが、重大な事案発生時は臨時改訂を行います。

参考：中小企業の情報セキュリティ対策ガイドライン - IPA

中堅企業が陥りやすい5つの落とし穴と対処法

ポリシー策定後の運用フェーズで、現場が機能しない状態に陥るパターンには共通点があります。事前に対処法を組み込むことで回避できます。

落とし穴は文書設計の問題ではなく、運用設計の問題として現れます。策定段階で運用負荷を見積もり、無理のない設計にすることが重要です。

落とし穴1：抽象的すぎて現場が判断できない

「適切に管理する」「必要に応じて」のような曖昧な表現が多いと、現場で判断が分かれます。実施手順レベルで具体的な手順・基準・閾値まで落とし込むことが対処法です。

落とし穴2：規格要件のコピー＆ペースト

ISO/IEC 27001の管理策をそのまま転記しただけのポリシーは、自社の実態と乖離します。規格要件を満たしつつ、自社の業務プロセス・組織構造に合わせて翻訳することが必要です。

落とし穴3：教育・周知が形式化

ポリシー策定時のeラーニングだけで終わると、新入社員や中途入社者が理解しないまま業務に入ります。入社時オリエンテーション、定期的な再教育、部署別の事例研修を組み合わせます。

落とし穴4：例外運用が増殖して機能不全

「特例」「暫定対応」が積み重なり、ポリシーと実態が乖離します。例外申請の文書化、承認権限の明確化、定期的な例外レビューを設けることで、抜け穴を統制下に置けます。

落とし穴5：改訂が滞り陳腐化する

クラウド・リモートワーク・AI利活用など、業務環境は急速に変化します。改訂責任者を明確にし、年次レビューを定例化することで陳腐化を防ぎます。重大インシデント発生時は臨時改訂を発動します。

参考：情報セキュリティ対策の落とし穴 - IPA

用語集｜情報セキュリティポリシー策定で押さえる10語

策定・運用フェーズで頻出する用語を整理します。文書内で用語が定義されていないと、現場で解釈が分かれてトラブルの原因になります。

ポリシー本文の冒頭または別添に用語集を配置し、組織内で共通理解を持てるようにします。

• ISMS：情報セキュリティマネジメントシステム。ISO/IEC 27001で要件が定義される包括的な管理体制
• 情報資産：組織が保有する情報・システム・ソフトウェア・人・施設など、価値を持つ資源全般
• 機密性：認可された者だけが情報にアクセスできる状態。Confidentialityの訳語
• 完全性：情報が正確かつ完全に維持される状態。Integrityの訳語
• 可用性：認可された者が必要時に情報にアクセスできる状態。Availabilityの訳語
• リスクアセスメント：脅威・脆弱性・影響度を分析し、リスクレベルを決定する一連の活動
• 管理策：リスクを低減するために実施する対策・手段。ISO 27001:2022は93個の管理策を規定
• 特権アカウント：システム管理権限を持つアカウント。漏洩時の影響が大きいため厳格管理が必須
• アクセスレビュー：アクセス権が業務上適切か定期的に確認するプロセス。ISMS・SOC 2必須項目
• インシデント対応：セキュリティ事象の発見から復旧・再発防止までの一連の対応プロセス

ジョーシスでセキュリティポリシー運用を実装する方法

策定したポリシーを日常運用で機能させるには、IT資産・SaaS・ID・アクセス権の継続的な可視化と統制が欠かせません。ジョーシスのプラットフォームは、ポリシーで定めた管理策を自動化された運用基盤に落とし込みます。

中堅企業の情シスは限られた人員でポリシー遵守を維持する必要があり、手作業の点検・台帳更新では運用が破綻します。ツールによる自動化が現実解です。

SaaS可視化と利用状況の継続的把握

ジョーシスは350以上のアプリと連携し、組織内で利用されているSaaSの全体像を継続的に可視化します。シャドーITの早期発見、未使用ライセンスの特定、アクセス権の棚卸しが、人手に頼らず実行できます。

ポリシーで定めた「許可されたSaaSのみ利用」「定期的な利用状況確認」といった管理策を、ダッシュボードベースで継続的に運用できます。

IDライフサイクル管理と退職者アカウント自動停止

入社・異動・退職時のアカウント発行・変更・廃止を、人事システムと連携して自動化します。退職者アカウント残存はISMS・SOC 2監査で頻出する指摘事項ですが、自動化により発生源を断てます。

特権アカウントの利用状況、多要素認証の有効化状況、ログイン履歴も継続的に追跡できるため、ポリシーに基づくアクセス制御を可視化された状態で運用できます。

監査証跡の自動取得とレポーティング

ISO/IEC 27001、Pマーク、SOC 2の審査では、アクセス権の変更履歴、レビュー記録、特権操作ログなどの証跡提示が求められます。ジョーシスは操作ログを自動記録し、レポート出力できるため、監査準備工数を大幅に削減します。

実際にジョーシス導入企業では、IT工数を最大50%、ITコストを最大75%削減した事例があります。ポリシー運用の自動化が、情シス組織の生産性と統制水準を同時に底上げします。

ジョーシスは国内外700社以上に導入され、SaaS管理・IDガバナンス・IT資産管理を統合的に担うプラットフォームとして、中堅企業のセキュリティポリシー運用を支えています。

ジョーシスを5分で理解する資料ダウンロード

無料デモで自社への導入効果を確認する

参考：Josys 公式サイト

よくある質問｜情報セキュリティポリシー策定の疑問

策定・改訂・運用フェーズでよく挙がる質問を整理します。中堅企業の情シスからの相談で頻度が高い論点をピックアップしました。

Q1：ポリシー策定にはどれくらいの期間が必要ですか

ゼロから策定する場合、リスクアセスメントから承認まで通常6〜12ヶ月かかります。既存文書の改訂であれば3〜6ヶ月が目安です。ISMSやSOC 2の審査スケジュールから逆算して、レビュー・教育・運用開始の余裕を確保します。

Q2：ひな形をそのまま使ってもよいですか

IPAやJIPDECのひな形は出発点として有効ですが、自社の業務プロセス・組織構造・利用システムに合わせて必ず調整します。コピーのままでは現場で機能せず、審査でも実態と乖離していると指摘されます。

Q3：改訂はどのタイミングで行うべきですか

定期改訂は1〜2年に1回が標準です。加えて、組織変更、重大インシデント、新規SaaS導入、規格・法令改正のタイミングで臨時改訂します。改訂責任者と改訂プロセスをポリシー本文に明記しておきます。

Q4：複数規格に対応する場合の文書構造は

基本方針は1本に統合し、対策基準で規格別に必要な管理策を網羅します。ISO/IEC 27001を軸に、Pマーク・SOC 2・APPIの追加要件を補完する構造が効率的です。重複管理策を排除することで、改訂負荷を抑えられます。

Q5：ポリシー違反時の処分は記載すべきですか

就業規則・懲戒規程との整合を取りつつ、ポリシー違反が懲戒対象になる旨を明記します。具体的な処分は就業規則で規定し、ポリシー側では参照関係を示すのが一般的です。法務部門と連携して文言を確定します。

まとめ｜実態に即したポリシーで継続運用する

情報セキュリティポリシーは、策定して終わりではなく、運用と改訂を通じて組織のセキュリティ水準を継続的に高めるための装置です。3階層構造で改訂負荷を抑え、リスクアセスメントから運用開始まで5ステップで段階的に整備することが現実解です。

中堅企業では、限られた人員でポリシー遵守を維持するために、SaaS管理・IDガバナンス・IT資産管理を統合したツール基盤の整備が前提条件になります。ジョーシスのような統合プラットフォームを活用することで、ポリシーの管理策を自動化された運用に落とし込み、情シスの工数を最大50%削減しながら統制水準を高められます。

まずは自社の情報資産の棚卸しと、SaaS利用実態の可視化から着手することをおすすめします。実態が見えれば、ポリシーに何を書くべきかが具体化され、現場で機能する文書設計が可能になり