社内セキュリティポリシーの作り方。基本方針・対策基準・実施手順の三層で実効性をつくる

「うちにもセキュリティポリシーはあります」。そう言われて出てくる文書が、数年前に作って以来一度も開かれていない、あるいは中身が「情報資産を適切に管理する」といった抽象論で埋め尽くされている、というのはよくある光景です。ポリシーは作ること自体が目的ではありません。日々の業務のなかで実際に判断のよりどころとして使われ、守られて初めて意味を持ちます。

セキュリティポリシーが形だけになってしまう原因の多くは、構成の設計にあります。経営の意思表明と、現場の具体的な手順を一枚の文書に詰め込もうとすると、抽象的すぎて使えないか、細かすぎて経営層が承認できないかのどちらかに陥ります。これを避ける定番の考え方が、基本方針・対策基準・実施手順という三層構造です。

この記事では、三層それぞれの役割と書き分け方、策定をどう進めるか、そして最大の難所である「作ったあとに実際に守られる仕組み」をどう担保するかを、経営層と情報システム責任者の双方が同じ絵を見られるよう整理します。テンプレートを埋めて終わりにせず、自社のリスクと体力に合った実効性のあるポリシーをつくることを目指します。

三層構造の早見表#

まず全体像を一枚で押さえます。三つの層は、対象読者・更新頻度・承認者がそれぞれ異なります。ここを混同すると、文書がうまく回りません。

広義の「情報セキュリティポリシー」はこの三層全体を指すことも、狭義に基本方針だけを指すこともあります。社内で言葉の指す範囲を合わせておくと、議論の行き違いを防げます。

総務省の「国民のためのサイバーセキュリティサイト」でも、組織における情報セキュリティポリシーの策定の必要性と、経営層が責任を持って体制を整えることの重要性が示されています。

第一層: 基本方針（変わりにくい意思表明）#

基本方針は、組織が情報セキュリティにどう取り組むのか、その姿勢と目的を宣言する文書です。経営層の名前で出され、社内だけでなく、取引先や顧客、社会に対しても公開されることがあります。Webサイトに「情報セキュリティ基本方針」として掲載している企業を見たことがあるはずです。

基本方針に書くのは、具体的な手順ではなく、原則です。たとえば次のような要素です。

• なぜ情報セキュリティに取り組むのか（事業継続・顧客の信頼・法令遵守など目的の明示）
• 何を守るのか（顧客情報、技術情報、システムといった保護対象の大枠）
• 誰が責任を持つのか（経営層の責任表明、推進体制の存在）
• 継続的に改善していく姿勢

ここでありがちな失敗が二つあります。一つは、基本方針に具体的な製品名や設定値を書き込んでしまうこと。「ウイルス対策ソフトとして製品Xを導入する」のような記述は、製品を乗り換えるたびに経営層の承認を取り直すことになり、文書が硬直化します。具体策は下の層に委ねるのが鉄則です。

もう一つは、他社の基本方針をそのまま写すこと。文章としては立派でも、自社の事業の言葉になっていないと、社員にとって他人事になります。短くてよいので、自社が何を大切にしているかが伝わる言葉で書くことが、後の対策基準・実施手順への納得感につながります。

組織として認証取得まで視野に入れるなら、ISMS（情報セキュリティマネジメントシステム）の枠組みを参照すると、基本方針に求められる要素を体系的に確認できます。認証取得の流れは

で詳しく扱いますが、ここでは個別の技術対策とは別に、組織統制の観点で押さえておく価値があるという点を意識しておきます。

第二層: 対策基準（守るべきルール）#

対策基準は、基本方針を実現するために「何を守るべきか」を定めた、社内ルールの集合です。三層のなかで最も分量が多くなる中核であり、社員が日常的に参照するのもこの層です。アクセス権限の付与ルール、パスワードの要件、持ち出しの可否、外部サービス利用の基準、委託先管理の基準など、テーマごとに規程として整理します。

対策基準を書くときの判断基準は、「具体的だが、特定の製品や手順には踏み込みすぎない」ことです。たとえばパスワードについて、対策基準では「推測されにくい十分な長さのパスワードを設定し、使い回しを禁止する」「多要素認証を業務システムで必須とする」と定めます。一方、「どの認証アプリをどう設定するか」は実施手順に書きます。この境界の引き方が、文書を使いやすくも使いにくくもします。

対策基準を設計する際に避けて通れないのが、情報資産の棚卸しです。何を、どれだけ重要なものとして守るのかが決まっていないと、基準の厳しさを決められません。すべてを最高レベルで守ろうとすると現場が回らず、結局守られなくなります。

この棚卸しを省いてテンプレートをそのまま採用すると、自社にとって過剰だったり、逆に手薄だったりする基準が出来上がります。テンプレートは「考える項目の抜け漏れチェック」として使い、中身は自社のリスク評価で埋めるのが正しい使い方です。

規程を一度に完璧に作ろうとして、半年たっても公開できないという声をよく聞きます。最初から100点を狙うより、影響の大きい領域から最小限の基準を出して回し、運用しながら穴を埋めていく方が、結果的に守られるルールになります。

第三層: 実施手順（どうやるか）#

実施手順は、対策基準で定めたルールを「具体的にどう実行するか」を示したマニュアルです。新入社員アカウントの作成手順、退職者のアカウント停止手順、バックアップの取得・復旧手順、ウイルス感染が疑われるときの初動手順などが該当します。担当者がその通りに作業すれば基準を満たせる、という具体性が求められます。

この層は、対象が製品・システム・組織体制に強く依存するため、最も頻繁に更新されます。クラウドサービスを乗り換えれば設定手順は変わり、ツールがバージョンアップすれば画面も変わります。だからこそ、基本方針や対策基準とは別文書に切り出しておき、現場の判断で機動的に改訂できるようにします。実施手順の改訂のたびに経営層の承認を求める運用は、現実には回りません。

実施手順でとくに価値が高いのが、インシデント発生時の対応手順です。平時に整備されていないと、いざというときに連絡先も分からず初動が遅れます。誰に・どの順で連絡し、何を保全し、どう外部（必要に応じて関係機関や取引先）へ報告するかを、平易な手順として用意しておきます。

三層をつなぐ: 整合性と外部要求の確認#

三層は独立した文書ではなく、上から下へ筋が通っている必要があります。基本方針で「顧客情報を適切に保護する」と宣言したなら、対策基準に顧客情報のアクセス制御や暗号化の基準があり、実施手順にその具体的な設定方法がある、というつながりです。どこかの層が抜けていると、宣言が宙に浮くか、現場が独自判断で運用してばらつきます。

策定の初期段階で必ず確認したいのが、外部からの要求との整合です。代表例が法令です。個人データを取り扱う個人情報取扱事業者であれば、個人情報保護法が求める安全管理措置を、対策基準と実施手順に落とし込む必要があります。委託先の管理や、一定の類型に該当する漏えい等が起きた場合の本人への通知・個人情報保護委員会への報告といった対応は、ポリシーの中で具体的な手順として用意しておくべき事項です。

個人データを取り扱う場合は、個人情報保護委員会が示す安全管理措置やガイドラインを確認し、ポリシーの対策基準・実施手順に反映します。委託先管理や、報告対象となる漏えい等が発生した場合の対応など、法令上の義務を手順として具体化しておくことが重要です。

取引先から「ISMS認証の取得」や「セキュリティ基準への準拠」を求められるケースも増えています。そうした外部要求がある場合は、要求事項を最初に整理し、対策基準のどの規程で満たすかを対応づけておくと、後から大きな手戻りを避けられます。中小規模であれば、ゼロから作るより、公的機関が提供するひな形を出発点にするのが効率的です。

IPAの「中小企業の情報セキュリティ対策ガイドライン」には、情報セキュリティ基本方針や関連規程、各種台帳のサンプル・ひな形が付録として用意されています。自社のリスクに合わせて編集する出発点として活用できます（執筆時点で第4.0版が公開されています）。

最大の難所: 作ったあとに守られる仕組み#

ポリシーづくりの本当の難所は、文書を完成させることではなく、それが現場で守られ続けることです。立派な規程があっても、誰も読まず、例外が黙認され、何年も見直されなければ、実効性はありません。実効性は次の三つで担保します。

第一に、教育と周知です。ルールは、存在を知られ、理由が腹落ちして初めて守られます。なぜその基準があるのかを背景のリスクとともに伝える教育が欠かせません。一度きりの研修ではなく、入社時・定期・インシデント発生時など、繰り返し触れる機会を設けます。周知と教育の具体的な進め方は

のような技術テーマと同じく、組織にとって継続的な取り組みです。

第二に、例外と違反の扱いを明確にすることです。現実には、業務上どうしてもルールを満たせない場面が出てきます。そのとき「黙って破る」のではなく、「申請して承認を得たうえで一時的に例外を認める」仕組みがあれば、運用の実態とルールの乖離を可視化できます。違反時の扱い（指導か懲戒かなど）も、就業規則との整合を取って定めておきます。罰則だけを強調すると萎縮や隠蔽を招くため、報告しやすい雰囲気づくりとセットで考えます。

第三に、定期的な見直しです。事業もシステムも脅威も変わり続けるため、ポリシーは作ったら終わりではなく、生き物として維持します。年に一度など周期を決めて棚卸しし、実態と合わない基準を直し、新たなリスクに対応します。インシデントや大きなシステム変更があったときも、臨時に見直すきっかけにします。この継続的な改善のサイクルこそが、ISMSの考え方の核心でもあります。

ポリシーを「監査のためだけの文書」にしてしまうと、現場は監査前だけ取り繕い、普段は実態と乖離します。逆に、現場の困りごとを吸い上げて毎年少しずつ直していくと、ルールが自分たちのものになり、守る理由が腹落ちしていきます。

策定を進める順番と体制#

実際に着手するときは、いきなり文書を書き始めず、体制と順番を整えます。まず経営層が責任者を明確にし、推進する担当（または委員会）を置きます。情報セキュリティは情報システム部門だけの仕事ではなく、人事・法務・各業務部門にまたがるため、横断的に意見を吸い上げられる体制が望ましいです。

進め方としては、上の層から大枠を決め、下の層を具体化していくのが基本です。ただし、実務では下の層（現場の実態）から見えてくる課題が、上の層の見直しを促すこともあります。一方通行ではなく、行き来しながら整合を取っていくものと捉えるとよいでしょう。

最初の版は、完璧を目指さず「守れる範囲」で出すことが大切です。守れないほど厳しいルールは、形骸化の最大の原因です。影響の大きい領域から最小限の基準を整え、運用しながら育てていく姿勢が、結果として実効性の高いポリシーにつながります。

よくある質問#

まとめ#

社内セキュリティポリシーは、作ること自体がゴールではありません。三層構造で抽象論と細則を両立させ、自社のリスクに合った中身を入れ、そして何より現場で守られ続ける仕組みまで設計して、初めて意味を持ちます。完璧な一枚を目指して塩漬けにするより、守れる範囲から出して運用しながら育てていく方が、結果として組織を守る力になります。技術的な対策の優先順位づけとあわせて、組織統制の土台としてのポリシーを着実に整えていきましょう。