セキュリティポリシーの作り方｜現場で機能するポリシーを作る実務フローとテンプレート

「セキュリティポリシー、ありますか？」「あります」「最後に更新したのはいつですか？」「……5年前です」——この会話、現場でよく起きます。

ポリシーが「ある」ことと「機能している」ことは別物です。作って棚に入れたまま誰も読まないポリシーは、セキュリティ事故が起きたときに「あったのになぜ守られなかったのか」という問題を生むだけです。

この記事では、セキュリティポリシーの考え方と、現場で機能するポリシーを作るための実務フローを整理します。

セキュリティポリシーとは——「何を守るか」を組織で決める文書
ポリシーの3層構造を理解する
現場で最低限整備すべきポリシーの種類
ポリシー作成の実務フロー——「書いて終わり」にしない4ステップ
よくある失敗パターン——ポリシーが形骸化する現場
実務チェックリスト——セキュリティポリシー整備の確認ポイント
まとめ——今日確認すべきことは1つです

セキュリティポリシーとは——「何を守るか」を組織で決める文書

セキュリティポリシー（Security Policy） 組織が情報資産を守るために「何を・なぜ・どのように守るか」を定めた文書群の総称。経営層が定める方針から現場の作業手順まで、複数の階層で構成される。

セキュリティポリシーは「守るべきルールを文書化したもの」ですが、それ自体が目的ではありません。目的は「組織全体で一貫したセキュリティの判断・行動ができる状態を作ること」です。

ポリシーがない組織では、担当者が変わるたびにセキュリティの水準がばらつき、インシデントが起きても「誰が何をすべきだったか」が不明確になります。

ポリシーの3層構造を理解する

セキュリティ文書は「ポリシー・スタンダード・プロシージャ」の3層で構成するのが標準的な考え方です。

ポリシー（方針）——経営層が定める最上位の方針

ポリシー（Policy） 組織のセキュリティに関する最上位の方針文書。「何を守るか・なぜ守るか」を定める。具体的な手段には踏み込まず、抽象度が高い。経営層が承認し、全従業員に適用される。

ポリシーの例：「当社は情報資産を適切に保護し、機密性・完全性・可用性を確保する」

特徴：

抽象度が高く・長期間有効（技術が変わっても変わらない内容）
経営層・役員が承認する
全従業員が対象

スタンダード（標準）——ポリシーを実現するための具体的な基準

スタンダード（Standard） ポリシーを実現するために「具体的に何をすべきか」の基準を定めた文書。数値・技術的な要件が含まれる。

スタンダードの例：「パスワードは12文字以上・複雑性要件を満たすこと」「MFAを全管理者アカウントに適用すること」

特徴：

具体的な基準値・技術要件が含まれる
技術の変化に合わせて定期的に更新が必要
IT部門・セキュリティ担当が作成

プロシージャ（手順）——現場が実際に行う作業手順

プロシージャ（Procedure） スタンダードを実現するための具体的な作業手順書。「誰が・いつ・どのように実施するか」をステップバイステップで記述する。

プロシージャの例：「新入社員のアカウント作成手順」「パスワードリセット対応手順」「インシデント発生時の初動対応手順」

特徴：

最も具体的・詳細
担当者が変わっても同じ作業ができることが目的
現場の担当者が作成・更新

比較項目	ポリシー	スタンダード	プロシージャ
抽象度	高い	中程度	低い（具体的）
承認者	経営層	IT部門責任者	現場担当者
更新頻度	低い（数年に1回）	中程度（年1回）	高い（随時）
対象読者	全従業員	IT担当者	作業担当者

現場で最低限整備すべきポリシーの種類

すべてを一度に整備しようとすると進まなくなります。以下の5種類から優先して着手してください。

情報セキュリティ基本方針

組織のセキュリティに関する最上位の方針です。「当社はなぜ・何を守るか」を宣言します。ISO 27001やプライバシーマーク取得時にも必要になります。

最低限含めるべき内容：目的・適用範囲・経営層のコミットメント・違反時の対応・見直し頻度

アクセス制御ポリシー

「誰が何にアクセスできるか」のルールを定めます。最小権限の原則に基づき、業務上必要なアクセスのみを許可することを明文化します。

最小権限の原則については「最小権限の原則とは？」を参照してください。

最低限含めるべき内容：アクセス権の付与・変更・削除の手続き・定期レビューの頻度・特権アカウントの管理方法

パスワードポリシー

パスワードの複雑性・有効期限・ロックアウト条件を定めます。技術的な設定値（ADのグループポリシー等）とセットで管理します。

ADでのパスワードポリシーの技術的な実装については「ADのパスワードポリシー設計」を参照してください。

インシデント対応ポリシー

セキュリティインシデントが発生したときの対応フロー・報告ルート・エスカレーション先を定めます。インシデント対応の全体フローについては「セキュリティインシデント対応入門」を参照してください。

最低限含めるべき内容：インシデントの定義・報告先・初動対応の手順・外部通報の判断基準

許容可能利用ポリシー（AUP）

AUP（Acceptable Use Policy：許容可能利用ポリシー） 会社のIT資産（PC・ネットワーク・メール・インターネット等）を従業員が利用する際のルールを定めた文書。「やっていいこと・やってはいけないこと」を明確にする。

最低限含めるべき内容：業務外利用の可否・SNS投稿のルール・個人デバイスの利用可否・情報持ち出しの条件

ポリシー作成の実務フロー——「書いて終わり」にしない4ステップ

ステップ1：スコープと保護対象を決める

最初に「このポリシーは何に・誰に適用されるか」を明確にします。スコープが曖昧なポリシーは「自分には関係ない」と解釈されます。

確認すべき項目：

適用対象：全従業員か・IT担当者のみか・委託先も含むか
対象資産：社内システム全体か・特定のシステムか
適用期間：いつから有効か

ステップ2：リスクを洗い出して優先度をつける

保護対象が決まったら、そこに存在するリスクを洗い出します。すべてのリスクに同じレベルで対応しようとすると現場の負担が大きくなります。「発生可能性×影響度」でリスクを評価し、優先度の高いものからポリシーに反映してください。

	影響度：低	影響度：高
発生可能性：高	優先度：中	⚠️ 優先度：高（最優先）
発生可能性：低	優先度：低	優先度：中

ステップ3：文書を作成して承認を得る

ポリシーの効力は「経営層が承認した」という事実によって生まれます。IT担当者だけで作ったポリシーは「担当者のガイドライン」にしかなりません。

文書作成のポイント：

平易な言葉で書く（専門用語は最小限に）
「なぜそのルールが必要か」の理由を添える
違反した場合の対応を明記する
バージョン番号・作成日・承認者・次回レビュー日を記載する

ステップ4：周知・教育・定期レビューを運用に組み込む

ポリシーは作って終わりではありません。従業員への周知・教育・定期的な見直しがなければ形骸化します。

周知・運用のポイント：

項目	内容
周知方法	入社時研修・社内ポータルへの掲載・年1回の確認サイン
教育	フィッシングメール訓練・セキュリティ研修の実施
定期レビュー	年1回・インシデント発生後・法令改正時に見直す
違反時の対応	違反事例が発生したらポリシーの見直しにフィードバック