情報セキュリティポリシーの作り方：3階層の構成と情シスが書く条文例・運用

情報セキュリティポリシーとは、会社が情報をどう守るかを文書で定めた社内規程の体系です。経営層が宣言する「基本方針」、全員が守る水準を決める「対策基準」、操作レベルまで書いた「実施手順」の3階層で構成するのが日本では一般的で、ウイルス対策ソフトの設定や製品の導入そのものはポリシーではありません。文書が存在しても、承認者と改定の手続きが決まっていなければ、監査では「運用されていない規程」として扱われます。

対象は、ISMSの取得や取引先のセキュリティチェックシートをきっかけに、ポリシーの新規作成か全面改定を任された情シス担当者です。読み終えると、既存のルールをどの階層に置くかの判断ルール、10テーマの条文例、稟議と監査を通る承認・改定の運用、守れないポリシーの直し方が手元に残ります。条文例はいずれもこの記事のために書いた架空の中小企業向けの文面で、そのまま使うのではなく、自社の実態に合わせて削り、書き換える前提です。

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

3階層に分ける理由は、読者と改定の頻度が階層ごとに違うからです。基本方針は社外にも公開する経営の約束で、5年変わらない文面を目指します。対策基準は全従業員が守る水準を「〜しなければならない」の形で列挙したもので、年1回の見直しで少しずつ変わります。実施手順は情シスが自分たちのために書く操作手順で、Entra IDやGoogle Workspaceの管理画面が変われば月単位で書き換わります。これを1つの文書にまとめると、画面のメニュー名が変わっただけで経営会議の承認が必要になり、改定が止まります。

どの階層に書くか迷ったら、次の3つの質問を順に当てます。第1に、製品を乗り換えたら書き換えが必要か。必要なら実施手順です。第2に、守られているかを第三者がはい／いいえで判定できるか。判定できるなら対策基準です。第3に、5年後も同じ文面のままでいられるか。いられるなら基本方針です。「社外から到達できるサービスへのサインインはMFAを必須とする」という文は、製品に依存せず、判定でき、しかし認証技術の変化で5年後には書き換わるので対策基準に置きます。

この質問を、情シスが守らせたい具体的なルールに当てはめると次の表になります。同じテーマが3階層すべてに1行ずつ書かれ、上に行くほど抽象的で、下に行くほど製品名が出てくるのが正しい状態です。

3階層を1つのWordファイルに混ぜると、管理画面のメニュー名が変わっただけで基本方針の改定稟議が必要になります。逆に対策基準を書かずに基本方針から実施手順へ飛ぶと、製品を入れ替えた瞬間に「守るべき水準」が文書から消えます。階層を分けるのは書式の問題ではなく、承認経路を分けるためです。

書き始める前に決めること：適用範囲・役割・用語・情報の分類

適用範囲は、組織（全社か特定の事業部か）、情報（会社が扱うすべての情報か顧客情報だけか）、対象者（役員、従業員、派遣社員、委託先要員、インターン）、機器（会社支給、私物、クラウド）の4軸で書きます。派遣社員と委託先要員を対象者から落とすと、そこだけルールが空白になり、監査で最初に指摘されます。ISMS認証を取る予定があるなら、認証の適用範囲と一致させておくと、審査用に別の文書を持たずに済みます。

役割は、実在する人に当てはまる名前だけを使います。従業員20名の会社に「情報セキュリティ委員会」「CISO」「内部監査室」を並べても、誰も動きません。少人数での割り当て例は、最高責任者＝代表取締役、情報セキュリティ責任者＝情シス担当者（兼務）、委員会＝代表・情シス・総務の3名、監査役割＝情シス以外の管理職1名です。基本方針には役職名だけを書き、氏名は別紙の「体制表」に置くと、人事異動のたびに基本方針を改定しなくて済みます。

対策基準の文体は、助動詞の意味を冒頭で定義してから使います。「原則として」だけで書かれた条文は、例外が何かを誰も答えられず、監査で「原則の例外はどこに記録されていますか」と聞かれて止まります。

情報の分類は3段階で足ります。例：「公開」はWebサイトに載せてよい情報、「社外秘」は従業員と契約した委託先だけが扱う情報、「機密」は名簿で指定した人だけが扱う情報（個人情報、未公開の財務情報、顧客から預かったデータ、認証情報）です。4段階以上にすると現場が迷い、結局すべてが「社外秘」に貼られます。分類はこのあとの条文すべての前提になるので、対策基準の最初のテーマに置きます。

情シスが書く条文例：小さな会社に必要な10テーマ

以下の条文例は、架空の中小企業（従業員50名、Microsoft 365利用、情シス1名）の対策基準を想定して書いたものです。番号は例示で、実際の規程ではテーマごとに1つの「条」にまとめ、実施手順と証跡を紐づけます。各テーマの前後に、なぜその水準にするか、実施手順に何を落とすか、監査に何を見せるかを添えました。

アカウントとMFA

アカウントの条文で決めるのは、発行と削除の期限、共有IDの扱い、特権IDの分離、パスワードの長さ、MFAの範囲の5点です。パスワードの定期変更は求めません。定期変更を義務化すると末尾の数字を増やすだけの運用になり、漏えいの疑いがあるときに即時変更させる条文の方が効きます。

アカウント管理の条文例（対策基準）

1. アカウントは、人事部門からの入社・異動・退職の連絡に基づいて情シスが発行・変更・無効化する。退職者のアカウントは退職日の当日中に無効化し、30日後に削除する。
2. 共有アカウントは、情シスが台帳に登録したものを除き作成してはならない。台帳には利用目的と管理責任者を記載する。
3. 管理者権限は日常業務用とは別のアカウントで行使し、利用のたびに操作ログを残す。
4. パスワードは12文字以上とし、他のサービスで使ったものを再利用してはならない。定期変更は求めないが、漏えいの疑いがある場合は直ちに変更する。
5. 社外から到達できるすべてのサービスで多要素認証を必須とする。SMSと音声通話による認証は認めない。

実施手順に落とすのは、Entra IDまたはGoogle Workspaceでの無効化手順、条件付きアクセスや2段階認証プロセスの必須化の設定、緊急用（ブレークグラス）アカウントの保管方法です。監査には、ある月の退職者リストと無効化日を突き合わせた記録と、MFAの登録状況レポートを出します。

端末管理（BYODを含む）

端末の条文は、会社支給と私物で条を分けます。私物端末を認めるかどうかの判断ルールは「会社のデータだけを消せるか」です。モバイルアプリ管理（MAM）でメールとチャットのアプリだけを管理下に置けるなら私物スマートフォンを許可し、私物PCから社内システムへ直接つなぐことは認めません。VDIやブラウザ隔離を用意できない会社では、私物PCの利用は例外申請の対象にします。

端末管理の条文例（対策基準）

1. 会社支給PCは、ディスク全体の暗号化、EDRの導入、10分以内の自動画面ロックを有効にした状態でのみ利用できる。利用者に管理者権限は付与しない。
2. OSとブラウザの更新は公開から30日以内に適用する。深刻度が「緊急」の修正は14日以内とする。
3. 私物スマートフォンでの業務利用は、情シスが指定するアプリ保護の設定に同意した場合に限り、メール・チャット・カレンダーに限定して認める。私物PCから社内システムへ直接接続してはならない。
4. 端末の紛失・盗難は、気づいた時点で直ちに情シスに報告する。会社は業務データを遠隔で消去でき、私物端末の場合は会社データの領域のみを消去する。

手順書側には、Intuneのコンプライアンスポリシー（BitLocker必須、OSの最低バージョン）と条件付きアクセスで準拠デバイスを要求する設定、アプリ保護ポリシー、紛失時の遠隔消去の操作を置きます。監査で見せるのは、準拠状態のレポートと、未準拠になった端末に何日以内に対応したかの記録です。

クラウド／SaaSの利用

SaaSの条文で防ぎたいのは、個人契約のサービスに顧客データが入ることと、退職者のアカウントが残ることの2つです。禁止だけでは申請されずに使われるので、申請すれば1週間以内に可否が出る手続きとセットにします。可否の判断軸は、扱う情報の分類、SSO対応、データの保存先の国、契約主体の4つで、これを台帳の列にしておけば、後から理由を説明できます。

クラウドサービス利用の条文例（対策基準）

1. 業務で利用するクラウドサービスは、情シスが管理する台帳に登録されたものに限る。登録前の利用申請には、扱う情報の分類、利用部門、管理責任者を記載する。
2. 「社外秘」以上の情報を扱うサービスでは、会社のIDによるシングルサインオンを有効にし、個人のメールアドレスでの登録を禁止する。
3. 個人名義で契約したサービスに業務情報を保存してはならない。
4. 台帳に登録したサービスは年1回、利用実態とアカウント一覧を棚卸しし、退職者と未使用のアカウントを削除する。

台帳の様式は実施手順に置きます。列は、サービス名、契約主体、情報分類、SSOの有無、保存先リージョン、管理責任者、最終棚卸し日の7つあれば足ります。証跡は台帳そのものと棚卸しの記録で、申請フォームの履歴が承認記録を兼ねます。

生成AIの利用

生成AIは、禁止するとシャドー利用に変わるテーマです。対策基準では「許可一覧にあるものを、入力禁止データを除いて使ってよい」という許可型の書き方にし、一覧は実施手順側で版管理します。入力禁止の区分は情報分類と連動させ、「機密」は一律禁止、「社外秘」は入力内容が学習に使われない契約（法人版）のサービスに限る、とすると判断が機械的になります。決めるべき項目の全体像は生成AIの社内利用ガイドラインの作り方に譲ります。

生成AI利用の条文例（対策基準）

1. 生成AIサービスは、情シスが公開する許可一覧に掲載されたものを、掲載された条件（アカウント種別、用途）の範囲で利用できる。
2. 「機密」に分類した情報は、いかなる生成AIサービスにも入力してはならない。「社外秘」に分類した情報は、入力内容が学習に利用されないことを契約で確認したサービスに限り入力できる。
3. 生成AIの出力を社外向けの成果物に使う場合、利用者が事実関係と権利関係を確認し、確認した旨を記録する。

許可一覧の列は、サービス名、契約形態、許可する用途、確認日、更新日です。一覧の更新は実施手順の改定として情シス責任者が承認し、対策基準本文は触らないので、新しいサービスを追加するたびに委員会を開く必要がなくなります。

バックアップ

バックアップの条文で決めるのは、対象、頻度、世代の分離、復元テストの周期の4つです。ランサムウェアは本番と同じネットワークにあるバックアップも暗号化するので、「1世代は書き換え不能な場所に置く」を必須条件として書きます。目標復旧時点（RPO）と目標復旧時間（RTO）は、システムごとの数値を対策基準に並べず、分類ごとの上限だけを書き、システム別の数値は実施手順側の一覧表に置きます。数値が対策基準にあると、サーバーを1台増やすたびに委員会の承認が要ります。

バックアップの条文例（対策基準）

1. 分類「機密」および「社外秘」の情報を保存するシステムは、1日1回以上バックアップを取得する。
2. 取得したバックアップは本番環境と異なる場所に少なくとも2つの複製を持ち、そのうち1つは書き換えと削除ができない設定で保管する。
3. 復元テストは半年に1回以上、システムごとに実施し、復元に要した時間を記録する。目標復旧時間を超えた場合は改善計画を作る。
4. 保管先へのアクセス権は情シスの管理者アカウントに限定し、日常業務用のアカウントからは到達できないようにする。

システム別の一覧（システム名、RPO、RTO、取得先、保持世代）は実施手順に置きます。例：基幹システムはRPO 24時間・RTO 2営業日、ファイルサーバーはRPO 24時間・RTO 1営業日、Microsoft 365のメールはサービス側の保持に加えて外部バックアップでRPO 24時間、という具合です。監査にはジョブの成功ログと復元テストの記録（実施日、対象、要した時間、担当者）を出します。

ログ

ログの条文は、何を、どれだけの期間、誰が見るかの3点で書きます。集めるだけで誰も見ないログは、監査で「レビューの記録はありますか」と聞かれて詰まります。保持期間は、SaaSの標準保持が短いことを前提に決めます。執筆時点のEntra IDでは、サインインログの標準保持はライセンスにより7日または30日で、それより長く残すにはLog Analyticsやストレージへのエクスポート設定が要ります。Google Workspaceの監査ログも無期限ではないので、管理コンソールで種類ごとの保持期間を確認してから条文の日数を決めます。

ログの取得と保管の条文例（対策基準）

1. 認証、管理者による設定変更、ファイルサーバーと主要SaaSの操作、EDRの検知、ファイアウォールとVPNの接続について、ログを取得する。
2. ログは取得元と分離した保管先に転送し、1年以上保管する。直近90日分は検索できる状態に置く。
3. すべての機器とサービスの時刻をNTPで同期し、ログの時刻表記はJSTまたはUTCのいずれかに統一する。
4. 管理者操作のログは月1回、情シス責任者以外の担当者がレビューし、結果を記録する。

月次レビューのチェック項目は実施手順に書きます。新規の管理者ロール付与、条件付きアクセスポリシーの変更、メール転送ルールの追加、大量ダウンロードの4つを見るだけでも、侵害されたアカウントの典型的な動きは拾えます。情シスが1名の会社では「情シス責任者以外」のレビュー担当を総務の管理職にし、見方をチェックリストにしておけば成立します。

インシデント報告

報告の条文で最優先するのは、疑いの段階で1時間以内に報告が上がることです。そのために「報告した人を不利益に扱わない」と「報告先は1か所」を明文化します。個人情報の漏えいは個人情報保護委員会への報告期限が法令で決まっており（執筆時点では速報と確報の2段階で、確報は原則30日以内。日数は同委員会の公表資料で確認してください）、社内の報告期限はそこから逆算して決めます。重大度の区分と対外報告を決める体制はCSIRTの作り方に書いたので、条文はそれを前提にしています。

インシデント報告と対応の条文例（対策基準）

1. 情報の漏えい、改ざん、消失、不正アクセス、マルウェア感染、端末の紛失は、疑いの段階でも情報セキュリティインシデントとして扱う。
2. 発見者は、発見から1時間以内に情シスの報告窓口（チャットの専用チャネルまたは緊急連絡先）に報告する。報告が遅れた場合も、報告したこと自体を理由に不利益な扱いをしない。
3. 感染が疑われる端末はネットワークから切り離し、電源は切らずに情シスの指示を待つ。
4. 顧客、監督官庁、警察への報告の要否と内容は代表取締役が決定し、情報セキュリティ責任者が案を作る。
5. 対応終了後2週間以内に、原因、影響範囲、再発防止策を記録し、対策基準の見直しが必要かを判断する。

重大度の判定表、連絡網、初動チェックリスト、記録様式は実施手順です。監査に出すのはインシデント台帳（疑いで終わった案件も含める）と、年1回の机上訓練の記録で、台帳が空欄だと「報告が上がらない仕組み」と解釈されます。誤検知や紛失後すぐ見つかった端末も1行として残してください。

委託先

委託先の条文は、クラウドサービスも委託先の一種として扱うと抜けが減ります。個人情報保護法は委託先の監督を委託元に求めているため、選定時の確認、契約条項、年1回の見直しを条文にします。確認の深さは扱う情報の分類で変えます。「機密」を渡す委託先は評価票と契約条項の両方、「社外秘」は契約条項のみ、というのが情シス1〜2名で回る線です。

委託先管理の条文例（対策基準）

1. 「社外秘」以上の情報を扱わせる委託先は、契約前に情シスが評価票で確認し、結果を委託先台帳に記録する。
2. 委託契約には、秘密保持、再委託の事前承認、事故発生時の通知期限、契約終了時の情報の返却または削除の証明を含める。
3. 「機密」を扱う委託先については、年1回、評価票の再確認または第三者認証（ISMS等）の有効性確認を行う。
4. 委託先の要員が社内システムを利用する場合、本規程の対象者として従業員と同じルールを適用する。

評価票の質問項目（第三者認証の有無、データの保存先、アクセス制御、事故時の連絡先と通知期限、契約終了時の削除手順）、台帳の様式、契約書ひな形の該当条項は実施手順に置きます。既存の契約に事故通知や削除証明の条項がない場合は、更新のタイミングで追加する計画を台帳の備考に書いておくと、監査で「把握している」と説明できます。

例外申請

例外の条文がないポリシーは、最初の守れない場面で全体が形骸化します。例外は「期限付き」「代替策付き」「リスクを引き受ける人が署名する」の3条件で認め、台帳で管理します。同じ条文に例外が3件以上たまったら、条文の方を見直す合図です。

例外申請と承認の条文例（対策基準）

1. 本規程を守れない業務上の理由がある場合、利用部門の責任者は例外を申請できる。申請には対象の条文、理由、期間（最長1年）、代替策を記載する。
2. 例外は情報セキュリティ責任者が承認する。「機密」の情報に関わる例外は委員会の承認を要する。
3. 承認された例外は台帳に記録し、期限が到来したら自動的に失効する。継続するには再申請を要する。
4. 同一の条文に対する例外が3件以上ある場合、情報セキュリティ責任者は次回の見直しでその条文の改定を検討する。

申請フォームと台帳（列：番号、対象の条文、部門、理由、代替策、承認者、期限、状態）は実施手順です。監査では例外台帳を見せ、期限切れの例外が残っていないことを説明します。例外がゼロ件の台帳は「守られている」ではなく「申請されずに破られている」と読まれるので、最初の年は数件あるのが自然です。

教育

教育の条文は、いつ、誰に、何を、どう記録するかを書き、教材の内容は実施手順に置きます。受講記録がないと、監査で周知の証明ができません。標的型メール訓練は、開封率で個人を責めると報告が止まるので、部門単位の集計と「開封後に報告した人の割合」を指標にします。

教育と訓練の条文例（対策基準）

1. 従業員、派遣社員、社内システムを利用する委託先要員は、着任後2週間以内に情報セキュリティ教育を受講する。
2. 全対象者は年1回、対策基準の改定内容を含む教育を受講する。受講記録は情シスが3年間保管する。
3. 標的型メール訓練を年1回以上実施し、結果は部門単位で集計する。個人の結果を人事評価に用いない。
4. 未受講者には受講期限後に情シスから督促し、1か月を超えて未受講の場合は所属長に通知する。

教材、受講管理の方法（LMSやフォームでの完了記録）、訓練の実施手順は実施手順側です。受講率の目標を条文に書くなら100%以外は意味がなく、未受講者をどう扱うか（上の第4項）が実質的なルールになります。

起案から承認まで：稟議と監査に耐える運用

誰が書き、誰が見て、誰が承認し、どう周知するかを階層ごとに決めておくと、改定のたびに手続きを考えずに済みます。対策基準のレビューに現場の責任者を入れるのは、守れない条文を施行前に見つけるためです。

稟議に回すのは基本方針だけにします。基本方針の本文に「対策基準および実施手順の制定・改廃は情報セキュリティ委員会に委任する」という一文を入れておくと、以後の対策基準の改定は委員会の議事録が承認記録になり、稟議を回さずに済みます。稟議書には、目的、適用範囲、施行日、従業員の業務に生じる変化（MFAの登録、私物PCの利用停止など）、必要な費用（ライセンスやEDR）、周知計画を書きます。費用がゼロでも「変化」の欄を省くと、施行後に現場から差し戻されます。

例：従業員50名、情シス1名、既存のルールが就業規則の服務規律だけ、という会社で新規に作る場合の8週間の進め方です。

1. 第1〜2週：現状の棚卸し。使っているSaaS、端末、委託先、既存のルールを一覧にし、3階層の表に振り分ける。空欄になったマスが作業リスト。
2. 第3〜4週：対策基準の草案。10テーマを1テーマ半頁で書く。並行して基本方針をA4で1枚書く。
3. 第5週：現場レビュー。部門責任者に「守れない条文」を挙げてもらい、例外で吸収するか条文を直すかを1条ずつ決める。
4. 第6週：委員会で対策基準を承認し、議事録を残す。
5. 第7週：基本方針の稟議。施行日は決裁の1か月後に設定する。
6. 第8週：周知と教育。受講記録を取り、施行日に条件付きアクセスなど技術的な強制を有効にする。

版管理は、文書番号、版数、改定履歴表、保管場所の4点を最初に決めます。文書番号の例：SP-1が基本方針、SP-2-01〜SP-2-10が対策基準の各テーマ、SP-3-xxが実施手順です。版数は「大版.小版」とし、承認が必要な内容の変更で大版を、誤字修正や部署名の変更だけなら小版を上げます。「小版の変更は承認不要で通知のみ」と対策基準の冒頭に書いておくと、部署名が変わるたびに委員会を開かずに済みます。改定履歴表の列は、版、改定日、施行日、改定内容の要約、起案者、承認者の6つです。

保管先は、履歴が自動で残る場所（SharePointやGoogleドライブの版履歴）にし、実施手順は情シスだけが閲覧できる権限にします。実施手順には設定値や緊急用アカウントの保管場所が書かれるため、全社公開すると攻撃者向けの手順書になります。廃止した版も削除せず「廃止」フォルダに残します。監査や事故調査では「その時点で有効だった版」を求められるので、ISMSの更新審査の周期に合わせて最低3年分は残してください。

承認から施行までの期間を空けずに施行日を決裁日と同じにすると、施行日にMFA未登録の人がサインインできなくなり、初日からポリシーの例外が量産されます。決裁から施行まで1か月以上を取り、技術的な強制（条件付きアクセスの有効化、準拠デバイスの要求）の開始日を条文か周知文に明記してください。

監査人が確認するのは、条文が存在することではなく、条文どおりに運用された記録です。対策基準の各テーマに対して、どの記録をどこから出すかを最初から対応表にしておきます。

証跡は後から作れません。「今月の退職者3名のアカウントを退職日当日に無効化した」ことを示すには、無効化の日時が残るログか、その日の日付で担当者が記入したチェックリストが要ります。上場準備やJ-SOX対応で求められるIT全般統制の記録も同じ出どころなので、IT全般統制の記事の証跡一覧と揃えておくと二重作業になりません。

守れないポリシーになる原因と直し方

ポリシーが形骸化するかどうかは、書き方の段階でほぼ決まります。自社の草案を次の表に当て、該当する行があれば施行前に直します。

もっとも多いのは1行目です。USBメモリの全面禁止は、製造装置の保守や来客からのファイル受け取りで破られます。「情シスが管理する暗号化USBのみ使用できる」「外部から受け取ったファイルは隔離端末で開く」のように、守れる形に書き換えた方が、結果として情報は守られます。同様に、パスワードの90日変更を残したまま新しい規程を作ると、現場は「どうせ守らない規程」として全体を読まなくなります。

罰則をポリシーに書いても、それだけでは懲戒の根拠になりません。就業規則の懲戒事由に会社の規程違反が含まれているか、違反の重さと処分の対応が定められているかを、施行前に総務・労務担当と確認してください。確認せずに「懲戒処分の対象とする」と書いた条文は、監査で根拠を聞かれたときに答えられません。

ISMS（ISO/IEC 27001）と公開サンプルとの関係

ISO/IEC 27001の認証を目指す場合、3階層はそのまま規格の要求に対応します。執筆時点の2022年版では、経営層が定める情報セキュリティ方針（本文の箇条5.2）が基本方針に、附属書Aの管理策5.1が求めるテーマ別の方針が対策基準に、手順書と記録が実施手順とその証跡に当たります。先に3階層で作っておけば、ISMSの文書体系を別に作る必要はなく、適用宣言書（SoA）の各管理策に対策基準のテーマ番号を対応させるだけで済みます。審査員が使う言葉は「方針」「規程」「手順」「記録」で、日本の3階層の呼び名と一対一ではない点だけ、審査の前に対応表で示しておきます。取得の進め方はISMS認証取得の進め方にまとめています。

構成を考えるうえで、公開されているサンプルを参照できます。IPA（情報処理推進機構）は中小企業向けの情報セキュリティ対策ガイドラインの付録として、基本方針や関連規程のひな形を公開しています。JNSA（日本ネットワークセキュリティ協会）も情報セキュリティポリシーのサンプルを公開しています。自治体向けには総務省が地方公共団体向けのガイドラインを、政府機関向けにはNISC（内閣サイバーセキュリティセンター）が対策基準策定のためのガイドラインを出しており、検索結果に「自治体」「地方公共団体」が並ぶのはこのためです。後者2つは民間企業がそのまま使う文書ではありませんが、テーマの網羅性を確認する用途には向きます。いずれも公式サイトで最新版を確認してください。

サンプルの使い方は「テーマの漏れを確認する」までにとどめ、条文は自社の実態から書き起こします。サンプルには自社に存在しない役割や書式が前提として入っており、そのまま採用すると前節の表の4行目に該当します。サンプルの条文ごとに「この条の証跡はどこから出るか」を書き込んでいき、答えられない条を削ると、残るのは自社で運用できる条文だけになります。

よくある質問

セキュリティポリシーの3つの要素は？

基本方針・対策基準・実施手順の3階層を指すのが一般的です。基本方針は経営層が宣言する目的と責任、対策基準は全従業員が守る水準、実施手順は情シスが使う操作手順です。総務省やNISCのガイドラインのように、上の2つを「ポリシー」と呼び、実施手順を別文書として扱う定義もあります。機密性・完全性・可用性の3つを指す文脈もあるので、質問した相手がどちらの意味かを確認してください。

セキュリティポリシーの例は？

対策基準の条文なら「社外から到達できるすべてのサービスで多要素認証を必須とし、SMSによる認証は認めない」「退職者のアカウントは退職日の当日中に無効化する」「本規程を守れない場合は期限と代替策を付けて例外を申請できる」のように、守られているかをはい／いいえで判定できる文が例です。「適切に管理する」のように判定できない文は、例としても避けます。

情報セキュリティポリシーのテンプレの例は？

IPAの中小企業向けガイドラインの付録、JNSAのポリシーサンプル、自治体向けの総務省ガイドラインが公開されており、いずれも公式サイトから入手できます。使い方はテーマの漏れの確認までにとどめ、条文は自社のシステム名・役職名・証跡の所在に合わせて書き直します。存在しない委員会や書式が残ったままのテンプレは、監査で最初に指摘されます。

情報セキュリティの3大原則は？

機密性（許可された人だけが読める）、完全性（勝手に書き換えられない）、可用性（必要なときに使える）の3つで、英語の頭文字からCIAと呼ばれます。条文に当てはめると、MFAと情報の分類は機密性、ログの改ざん防止とレビューは完全性、バックアップと復元テストは可用性を守る条文です。各テーマがどの性質を守るかを意識すると、抜けている条文が見つかります。

まとめ

情報セキュリティポリシーは、基本方針・対策基準・実施手順に分け、階層ごとに承認者と改定周期を変えることで運用に耐える文書になります。対策基準は、はい／いいえで判定できる条文と例外申請の手続きをセットで書き、各条に証跡の出どころを対応させておくと、稟議も監査もそのまま通ります。次の一歩は、今ある規程と実際の運用を3階層の表に振り分けることです。空欄になったマスが、今週書くべき条文の一覧になります。

次に読む

• ISMS（ISO 27001）認証取得の進め方：情シス主導のスケジュールと文書化
• 生成AIの社内利用ガイドラインの作り方：情シスが決めるべき10項目とテンプレート
• CSIRTとは？小さな組織で作るインシデント対応チームの現実解