情報セキュリティポリシーは、企業の情報資産を守るための基本方針と行動指針を文書化したものです。作る順序は「情報資産の棚卸し・リスク評価→参照規格の確認→文書の起草→レビュー・承認→教育と運用」の5ステップです。

文書は「基本方針・対策基準・実施手順」に分けます。対策基準には守るルールと責任部署を、実施手順には担当者の具体的な作業を書きます。まず違いと記載例を確認し、自社の組織・SaaS・業務に合わせて整えましょう。

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

基本方針は組織の姿勢、対策基準は守るルール、実施手順は現場での作業を示します。同じアクセス管理でも、どの文書に何を書くかを分けると、作業手順の変更だけで基本方針まで改訂する負担を抑えられます。起草前に3階層の役割をそろえておきましょう。

上の表は文書の書き分け例です。実際の対象範囲や承認者は、自社の運用に合わせて記載してください。

SaaSについて点検する項目を具体化したい場合は、関連記事：SaaSセキュリティ チェックリストと評価基準も参照できます。

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

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

社外公開する場合にも、用語の定義と適用範囲が曖昧にならないようにします。

第2階層：対策基準（Standard）｜書き方と具体例

対策基準は、基本方針を実現するための部門別・領域別の管理ルールです。アクセス制御、暗号化、物理セキュリティ、人的セキュリティ、外部委託、インシデント対応などのテーマ別に整理します。

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

各基準には「対象範囲」「ルール本体」「責任部署」「例外時の手続き」の4要素をそろえます。上の表を項目例として使い、次の点を確認してください。

• 対象範囲：対象の組織・人・情報資産を特定できるか
• ルール本体：何を許可し、何を禁止するか判断できるか
• 責任部署：管理や確認を担う部署が明記されているか
• 例外時の手続き：申請・承認・見直しの方法が決まっているか

基準を書いた後は、SaaSの利用状況やアクセス権を継続的に確認できるかも点検します。ツールで支援できる範囲を調べたい方は、5分でわかるJosysの製品資料をダウンロードするをご利用ください。リンク先はJosysの機能概要を確認する資料です。

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

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

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

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

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

策定は情報資産の棚卸しから始め、承認後の教育・モニタリングまでを一続きで設計します。文書の起草前に自社のリスクと適用する要件を確認し、現場の担当者と経営層の合意を取る順序です。各段階で確認することを一覧にまとめます。

特にリスク評価と合意形成を省かず、自社で実行できるルールに整えてから運用を始めます。

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

情報資産を業務プロセス単位で洗い出し、機密性・完全性・可用性の観点で価値を評価します。各資産の脅威と脆弱性を特定し、リスクレベルを算出します。SaaSの利用実態やシャドーITも確認し、管理対象から漏れる領域を減らしましょう。

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

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

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

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

基本方針は経営層と合意して起草し、対策基準は責任部署と内容を詰めます。実施手順は現場の運用担当が中心となって書きます。IPAやJIPDECのひな形を出発点に、自社の業務・組織・利用システムに合わせて調整してください。

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

法務・人事・情シス・経営層で、就業規則や業務委託契約、教育訓練計画との整合を確認します。経営会議または取締役会で正式承認を取り、全従業員に周知します。承認プロセスも文書として残します。

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

適用日を決め、eラーニングや集合研修で周知し、理解度テストで定着を確認します。運用開始後は内部監査で遵守状況を点検します。改訂サイクルは通常1〜2年ごとですが、重大な事案発生時は臨時改訂を行います。

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

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

必須項目は、規格・法令の要件と自社のリスクから決めます。適用範囲、情報の扱い、アクセス管理、各種セキュリティ対策、インシデント対応を点検し、書き漏らしを防ぎましょう。改訂・参照頻度の高い項目は独立した対策基準にすると管理しやすくなります。

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

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

責任分担は、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）と接続し、災害・サイバー攻撃・サプライチェーン障害などの中断シナリオに対する復旧目標を含めます。

Josysでセキュリティポリシー運用を支援する方法

ポリシーで定めたSaaSの利用状況確認やアクセス権の管理には、継続的な点検が必要です。Josysはジョーシス株式会社が提供するAI駆動のアイデンティティセキュリティ基盤です。文書で定めた管理対象と、ツールで把握・操作できる範囲を照合して運用を設計します。

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

Josysは350以上のアプリと連携します。SaaS Discoveryはログイン・ブラウザ活動からSaaS利用状況を検出します。SaaS Insightsによるアクセス情報の把握やライセンスレビューと合わせて、利用状況の継続的な確認を支援します。

IDライフサイクル管理と退職時のアカウント対応

Access Automationは入退社ライフサイクルの自動化を支援します。アカウントの付与・削除などは連携対象の範囲で対応するため、自社のSaaSで実行できる処理と、担当者が別途行う作業を確認し、実施手順に分けて記載しましょう。

アクセス権レビューと監査対応

Access Reviewsは監査対応コンプライアンスサーベイを支援します。アクセス権を確認する運用と、監査で必要な記録を準備する手順を組み合わせます。必要な証跡の取得範囲は、自社の要件と照合してください。

Josysは国内外1,000社以上に導入されています。導入企業ではIT工数を最大50%、ITコストを最大75%削減した事例があります。これらは導入事例の成果であり、自社のポリシー運用における効果は対象業務や連携範囲を確認して検討します。

退職時のアカウント対応やアクセス権レビューを具体化したい方は、Josysの無料デモを予約し、自社SaaSの連携範囲を確認するをご利用ください。

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

情報セキュリティポリシーとは、組織が情報資産を保護するために定める基本方針・対策基準・実施手順を体系化した文書群です。部門ごとに業務が分かれる中堅企業でも、誰がどの基準で情報を扱うかを明文化し、判断を一貫させる役割があります。

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

基本方針で経営層の意思を示し、対策基準で管理ルールや責任部署、実施手順で作業を定めます。「機密情報の社外持ち出し禁止」という方針だけで終わらせず、USB持ち出し、私用クラウド共有、スマートフォン撮影などの場面で判断できる内容にします。

規格・法令との関係

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

複数規格に対応する場合は、共通の管理策を一本化し、規格ごとの追加要件を整理すると改訂負荷を抑えられます。

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

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

抽象的な規程や形式的な教育は、運用が形骸化する原因になります。策定時に具体的な手順、教育の機会、例外の承認方法、改訂責任者まで決め、現場が実行できる負荷に収めましょう。運用開始前の確認には、次の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必須項目
• インシデント対応：セキュリティ事象の発見から復旧・再発防止までの一連の対応プロセス

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

ひな形の使い方や改訂のタイミングは、自社の業務・組織・利用システムに合わせて判断します。策定期間を見込む際も、起草だけでなくレビュー・承認・教育・運用開始までを含めましょう。文書を整えるときの確認事項を質問別に整理します。

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：ポリシー違反時の処分は記載すべきですか

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

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

まず、自社の情報資産とSaaSの利用実態を洗い出しましょう。その結果をもとに基本方針・対策基準・実施手順を分け、対策基準の「対象範囲・ルール本体・責任部署・例外時の手続き」を埋めます。承認後の教育、点検、改訂の担当まで決めておくと、作った文書を日常業務につなげられます。