- ホーム
- 情報セキュリティ
- 情報セキュリティガバナンスと文書体系
- 方針・規程・基準・ガイドラインの比較
方針・規程・基準・ガイドラインの比較
Section titled “方針・規程・基準・ガイドラインの比較”情報セキュリティの文書は、方針で方向性を定め、規程で責任と義務を定め、基準で実施条件を具体化し、手順書で作業につなげると整理しやすくなります。ガイドラインは理解や判断を補助し、記録は実施した結果を示します。
この分類は、本カテゴリで採用する実務上の整理です。組織や外部機関によって名称・階層は異なります。「セキュリティポリシー」が基本方針だけを指す場合も、規程や基準を含む体系全体を指す場合もあります。
文書ごとの役割
Section titled “文書ごとの役割”| 文書 | 答える問い | 主な内容・表現例 | 本カテゴリでの扱い | 承認者の例 |
|---|---|---|---|---|
| 方針(Policy) | なぜ守るか、何を大切にするか | 経営の約束。「必要な資源を確保する」 | 組織全体の基本原則 | 経営層・取締役会等 |
| 規程(Internal rules / Rules) | 誰が、何を守るか | 責任・義務・承認。「承認を受けなければならない」 | 社内の必須ルール | 職務権限に基づく決裁者 |
| 基準(Standard) | どの状態なら適合か | 対象・設定・期限・確認方法。「対象サービスにMFAを適用する」 | 適用対象の必須要件 | 権限を委任された責任者 |
| ガイドライン(Guideline) | どう判断するとよいか | 推奨・事例。「宛先を最後に入力することを推奨する」 | 原則として補助的な指針 | 所管責任者 |
| 手順書(Procedure / Manual) | どう実行するか | 操作・確認・失敗時の連絡。「申請番号を入力する」 | 指定業務の実行手順 | 運用責任者 |
| 記録(Record) | 実際に何をしたか | 申請、承認、作業、結果、是正 | 証跡。保存・アクセス条件を定める | 記録の種類に応じた確認者 |
ガイドラインという名前でも、法令・契約や社内規程から遵守を求められる場合があります。 必須性は名称や語尾だけで決まりません。本カテゴリでは、必須要件の根拠を規程・基準に置き、ガイドラインから参照します。
基本方針 ── 経営の目的・基本原則 └ 管理規程 ── 責任・義務・承認の仕組み └ 基準 ── 具体的な適合条件 └ 手順書 ── 実行・確認方法 └ 記録 ── 実施結果と証跡
ガイドライン ── 規程・基準・手順の理解と判断を補助ガイドラインを必ず基準と手順書の間に挟む必要はありません。また、下位文書だけを変更して上位の義務を弱めることは避け、矛盾があれば上位文書の所管者へ確認します。
同じテーマを各文書でどう書き分けるか
Section titled “同じテーマを各文書でどう書き分けるか”同じ対策でも、文書によって書く内容を変えます。まず目的・責任と義務・適合条件・判断の補助・作業・実施結果のどれを伝えたいかを考えると、配置先を決めやすくなります。
以下は架空の組織を想定した5つの例です。数値・頻度・期限は説明用であり、自組織のリスクや要求に合わせて決めます。各テーマ専用の基本方針を5冊作る意味ではなく、共通の基本方針や規程に記載する内容を、テーマごとに比較しています。
1. アクセス管理
Section titled “1. アクセス管理”| 文書 | 記載例 |
|---|---|
| 基本方針 | 業務上必要な人に必要な範囲で情報を提供し、不正な利用を防ぐ。 |
| 管理規程 | アクセス権の付与・変更は情報責任者の承認を要する。IT担当者は承認内容に基づき設定し、退職・異動時に削除・変更する。 |
| 基準 | 顧客情報システムは個人識別可能なIDを用い、MFAを適用する。権限は四半期ごとに確認する。退職者のアクセスは退職時刻までに無効化する。 |
| ガイドライン | 権限を選ぶ際は、役職だけで判断せず、閲覧・編集・出力の各業務が必要かを確認する。 |
| 手順書 | 申請内容と承認を確認し、指定の権限を設定する。テスト結果と設定履歴を申請に添付する。 |
| 記録 | 申請番号、対象ID、権限、承認者、作業者、実施日時、確認結果を保存する。 |
書き分けのポイント: 「誰が権限を承認するか」は規程、「どのシステムにMFAを適用し、いつ権限を確認するか」は基準、「承認内容を確認して設定する作業」は手順書です。ガイドラインは権限の選び方を補助します。
2. 機密情報の外部共有
Section titled “2. 機密情報の外部共有”| 文書 | 記載例 |
|---|---|
| 基本方針 | 情報の重要度に応じた保護を行い、必要な情報共有と機密性の確保を両立する。 |
| 管理規程 | 機密情報を社外へ共有する者は、情報責任者の承認を受けなければならない。情報責任者は共有の必要性と相手を確認し、共有者は承認された方法を使用する。 |
| 基準 | 機密情報の共有は、受信者を指定できる承認済みサービスを用いる。匿名で閲覧できるリンクは使用しない。共有期限は30日以内とし、継続する場合は再承認を受ける。 |
| ガイドライン | ファイル全体を送る前に、相手が必要とする項目だけに絞ることを推奨する。氏名を削除しても、契約番号や内容から相手を特定できないか確認する。 |
| 手順書 | 共有申請と承認内容を確認し、対象ファイル・受信者・有効期限を設定する。共有範囲が承認内容と一致することを確認して相手へ通知し、期限後にアクセス終了を確認する。 |
| 記録 | 対象情報、共有目的、相手、承認者、共有方法、設定した期限、共有・終了の確認結果を保存する。 |
書き分けのポイント: 「外部共有には承認が必要」は規程、「匿名リンク不可・有効期限30日以内」は基準です。設定画面で受信者や期限を指定する方法は手順書に書きます。「必要な部分に絞る」は判断を助ける推奨として示しています。必須にする場合は規程・基準で要件化します。
3. クラウドサービスの導入
Section titled “3. クラウドサービスの導入”| 文書 | 記載例 |
|---|---|
| 基本方針 | 外部サービスの利用に伴うリスクと責任を把握し、適切に管理する。 |
| 管理規程 | 利用部門はクラウドサービスの導入前に利用審査を申請する。情報セキュリティ担当者が評価し、指定の決裁者が利用可否を承認する。用途や取扱情報の重要な変更は再審査する。 |
| 基準 | 機密情報を保存するサービスは、組織によるアカウント管理、MFA、受信者を限定した共有、操作ログの取得、終了時のデータ出力・削除が可能であることを導入条件とする。 |
| ガイドライン | 機能一覧だけでなく、実際の契約プランで必要な管理機能を使えるかを確認する。無料試用でも業務データを入力する前に利用審査が必要なことを、規程の参照先とともに説明する。 |
| 手順書 | 申請票に用途・情報分類・契約プランを入力する。担当者が利用条件と設定を確認し、評価結果を決裁者へ回付する。承認後、初期設定を検証して承認サービス一覧へ登録する。 |
| 記録 | 申請票、利用条件の確認日、評価結果、承認者、利用条件、初期設定の確認結果、次回評価日を保存する。 |
書き分けのポイント: 「導入前に誰が審査・承認するか」は規程、「採用に必要な機能・条件」は基準、「審査票をどう作成し回付するか」は手順書です。ガイドラインは審査で見落としやすい点と、既存の必須ルールを説明します。
4. バックアップと復旧
Section titled “4. バックアップと復旧”| 文書 | 記載例 |
|---|---|
| 基本方針 | 重要な情報と業務を事故や障害から復旧できるように備え、事業の継続を図る。 |
| 管理規程 | 業務責任者は復旧目標を定め、IT担当者は目標を満たすバックアップ・復旧方法を整備する。復元試験を実施し、不備と是正計画を業務責任者へ報告する。 |
| 基準 | 受注サービスはRTO(復旧時間目標)4時間、RPO(復旧時点目標)1時間を満たす構成とする。バックアップの認証・削除権限は本番と分離し、四半期ごとの復元試験で所要時間と復元データを確認する。 |
| ガイドライン | データだけでなく、認証・ネットワーク・接続先サービスが使えない状況も想定して試験内容を選ぶ。バックアップ取得の成功だけで復旧可能と判断しない。 |
| 手順書 | 承認された隔離環境を準備し、対象の復旧用データを選択して復元する。データの整合性と受注処理の動作を確認し、開始から業務利用可能までの時間を測定して結果を報告する。 |
| 記録 | 使用した復旧用データの時点、復元対象、開始・完了時刻、失われたデータの範囲、動作確認結果、不備、是正担当者と期限を保存する。 |
書き分けのポイント: 「目標を決める人・復旧を整備する人」は規程、「何時間で、どの時点まで戻せる必要があるか」は基準、「どの順番で復元し動作確認するか」は手順書です。実測値と目標の達成結果は記録に残します。
5. インシデントの報告と初動対応
Section titled “5. インシデントの報告と初動対応”| 文書 | 記載例 |
|---|---|
| 基本方針 | 事故やその疑いを早期に把握し、影響の抑制、復旧、再発防止に取り組む。 |
| 管理規程 | 対象者は事故またはその疑いを直ちに指定窓口へ報告する。対応責任者は初動を指揮し、重大な事故を経営へ報告する。サービス停止や社外通知の判断権限を定める。 |
| 基準 | 顧客情報の漏えいの疑い、特権アカウントの不正利用、重要業務の全面停止を重大事象に分類する。窓口は重大事象の受報後15分以内に対応責任者へ連絡し、連絡不能なら代理者へ連絡する。 |
| ガイドライン | 原因や被害が確定していなくても、分かっている事実を先に報告する。例えば不審なログイン通知は、通知の時刻と内容を伝え、自己判断で記録を消さない。規程の報告義務と関連手順を参照する。 |
| 手順書 | 指定窓口へ連絡し、発見時刻・対象・状況を伝える。窓口担当者は受付票を作成し、分類基準に沿って対応責任者へ連絡する。権限のある担当者が指示を受けて影響抑制とログ保全を行う。 |
| 記録 | 発見・受付・連絡・初動の日時、報告内容、分類、判断者、指示、実施内容、証拠の保管先、結果を時系列で保存する。 |
書き分けのポイント: 「報告義務・指揮と決定の権限」は規程、「重大事象の判定条件・連絡期限」は基準、「連絡先や受付・保全の作業」は手順書です。ガイドラインは報告時の迷いを減らす説明を加え、独自に義務や期限を変更しません。
書く場所に迷ったときの判断
Section titled “書く場所に迷ったときの判断”例えば「四半期ごとに権限を確認する」は、周期という適合条件を定めるため基準に置きます。「責任者が権限を確認する義務を負う」は規程、「一覧を出力して不要な権限を確認する」は手順書、「確認した一覧と是正結果」は記録です。
ひとつの文章に義務・数値・操作が混ざっている場合は、内容を分けて配置します。同じ期限を各文書に重複して書かず、基準を唯一の管理元として手順書やガイドラインから参照すると、改訂時の不一致を防げます。
統合と分割の判断
Section titled “統合と分割の判断”文書の役割を分けることと、ファイルを分けることは別です。 上の例は内容の配置を示していますが、6種類すべてを独立したファイルにする必要はありません。この節は、書き分けた内容をどのような単位で管理するかを決めるために使います。
- 統合しやすい場合: 小規模な組織で対象・責任者が共通。管理規程に共通ルールをまとめ、数値や設定を別紙の基準にする。
- 分割した方がよい場合: 改訂頻度、担当者、公開範囲が異なる。例えば対外公表する基本方針と、内部のログ設定・事故対応手順は分ける。
- 別文書を参照する場合: 個人情報保護、開発、委託先、BCPのルールが既にある。関連箇所と責任者を明記し、同じ義務を複製しない。
例えば「情報セキュリティ管理規程」の本文に責任と義務、別紙に具体的な基準を置く構成でも役割を分けられます。ひとつのファイルにまとめる場合も、必須要件と推奨事項、各部分の承認者・改訂管理を識別できるようにします。
日本語の「規程」はルールを体系化した文書全体、「規定」は個々の条項・定めを指す使い分けができます。本カテゴリでは規程の英語表記をInternal rulesとし、組織内で守るべき正式なルールを指すことを明記します。
作成前の確認
Section titled “作成前の確認”- この文書は原則・義務・適合条件・推奨・作業・証跡のどれを扱うか。
- 適用対象と必須性が明記されているか。
- 上位文書の根拠と、下位文書の参照先があるか。
- 責任者・承認者・例外の扱いが一致しているか。
- 改訂で影響する文書・設定・教育を追跡できるか。
関連ページ・参考資料
Section titled “関連ページ・参考資料”- 情報セキュリティ管理規程
- 文書の策定・承認・見直し
- IPA:中小企業の情報セキュリティ対策ガイドライン — 基本方針・関連規程・ハンドブック等のサンプルを参照できます。