「情報セキュリティ方針を出してください」と取引先から言われて、慌てて雛形を検索している——この状態から始まる相談が非常に多いです。 そして多くの場合、雛形の空欄を埋めた1枚を提出して、その場は収まります。問題はその後です。翌年、取引先の確認が一段深くなり、「方針に書かれている点検は、いつ、誰が実施しましたか」と聞かれたとき、答えられない。
情報セキュリティ方針は、それ単体では意味を持たない文書です。意味を持つのは、方針の下にある規程と手順、そしてそれらに沿って残った記録とセットになったときだけです。取引先が本当に見ているのは、文言の立派さではなく、この構造が回っているかどうかです。
本記事は、専任の情シスがいない中小・中堅企業を前提に、提出できる方針を作り、かつ形骸化させないための順序を整理します。取引先からのセキュリティ要求全般についてはセキュリティ事業、運用まで含めた体制づくりはセキュリティ運用伴走で扱っています。
目次
- 結論：方針だけ作っても意味がない理由
- 方針・規程・手順という3階層
- 情報セキュリティ方針に必ず入れる7要素
- 公開してよい内容と、社内限定にすべき内容
- ISMS認証を取るべきか
- 作った方針を形骸化させないための条件
- 取引先から要求されたときの返し方
- よくある失敗
- 着手前チェックリスト
- よくある質問（FAQ）
- 体制づくりで迷ったら
<a id="conclusion"></a>
結論：方針だけ作っても意味がない理由
情報セキュリティ方針は、経営者が「当社は情報をこう扱う」と宣言する最上位の文書です。分量にすればA4で1〜2枚、内容も抽象度が高く、正直なところどの会社が書いてもよく似た文章になります。
だからこそ、この1枚だけを提出しても、相手には何も伝わりません。取引先の担当者が見たいのは、次の連鎖が成立しているかです。
- 経営者が方針を宣言している（方針）
- その方針を具体的なルールに落としている（規程）
- ルールを日々の作業手順にしている（手順）
- 手順どおりに実施した証拠が残っている（記録）
4番まで到達していれば、方針の文言が平凡でも問題ありません。逆に1番だけが立派でも、2〜4が空白なら、確認が深まった時点で必ず露見します。方針づくりを「文書作成」だと思うと1番で止まり、「運用設計」だと思えば4番まで届く——この違いが、提出できる方針とそうでない方針を分けます。
<a id="layers"></a>
FREE DOWNLOAD
中小企業のDX推進「失敗を防ぐ5ステップ」ガイドを無料でお送りします
多くの企業がつまずくポイントを着手順に整理した無料ガイド。相談する前に、自社の現在地と進め方を掴めます。
方針・規程・手順という3階層
用語が混同されがちなので、先に整理します。
横にスクロールして確認できます
| 階層 | 何を書くか | 分量の目安 | 決める人 | 公開の可否 |
|---|---|---|---|---|
| 情報セキュリティ方針 | 経営としての姿勢と約束 | A4で1〜2枚 | 経営者 | 公開してよい |
| 各種規程 | 守るべきルール（持出、パスワード、委託先、事故対応など） | 領域ごとに数枚 | 責任者 | 原則社内限定 |
| 手順・様式 | 実際の作業手順と記録の様式 | 業務ごと | 現場 | 社内限定 |
ここでよくある誤解が、**「方針に細かいルールを書き込んでしまう」**というものです。方針にパスワードの文字数や具体的な製品名まで書くと、ルールを変えるたびに経営者の承認が必要になり、実態と文書が乖離していきます。
正しくは、方針には変わらないことを書き、変わるものは規程・手順に置きます。「機密情報を適切に管理する」は方針、「持ち出す場合は責任者の承認を得る」は規程、「承認は申請書◯号で行い、台帳に記録する」は手順です。この分離ができていると、ルール変更のたびに方針を書き直す必要がなくなります。
<a id="seven"></a>
情報セキュリティ方針に必ず入れる7要素
雛形は世の中に多数ありますが、入っていないと提出時に指摘されやすい要素は次の7つです。
横にスクロールして確認できます
| # | 要素 | 書くときの注意 |
|---|---|---|
| 1 | 目的（なぜ守るのか） | 「法令遵守のため」だけでなく、事業として何を守るのかを書く |
| 2 | 適用範囲 | どの組織・どの拠点・どの業務が対象か。範囲を絞ってよい |
| 3 | 経営者の責任表明 | 経営者が責任を負うことの明示。署名または代表者名を入れる |
| 4 | 従業員の遵守義務 | 委託先・派遣を含むかどうかを明記する |
| 5 | 法令・契約要求事項の遵守 | 個人情報保護法など、自社に適用される法令に触れる |
| 6 | 教育と周知 | 誰に、どの頻度で行うか（頻度は規程側でもよい） |
| 7 | 見直しの実施 | 年1回など、方針そのものを見直す約束 |
2番の適用範囲は、意図的に絞ってよい項目です。 全社・全業務を範囲にすると、その全てで記録を残す義務を自ら負うことになります。取引先が求めているのが特定の業務に関する管理なら、まずその範囲から始めて、後から広げるほうが現実的です。範囲を絞ることは手抜きではなく、運用できる約束だけをするという誠実さです。
7番の見直しは、最も忘れられる項目です。 「年1回見直す」と書いた以上、見直した記録が必要になります。書いておいて実施しないのは、書いていないより悪い状態です。
<a id="scope"></a>
公開してよい内容と、社内限定にすべき内容
方針は自社サイトで公開しても構いませんし、公開している会社も多数あります。ただし方針より下の階層は公開しないでください。
横にスクロールして確認できます
| 公開してよい | 公開しないほうがよい |
|---|---|
| 情報セキュリティ方針そのもの | 使用している製品名・バージョン |
| 経営者の責任表明 | ネットワーク構成、拠点の設備情報 |
| 対象範囲の大枠 | 具体的な監視方法・検知ルール |
| 問い合わせ窓口 | インシデント時の連絡先個人名 |
公開しないほうがよい列は、攻撃者にとっての下調べ材料になります。「当社は◯◯社の△△を導入しています」という記載は、その製品に脆弱性が公表されたときに、自社が標的リストに入る理由を自ら提供することになります。信頼を示したい気持ちは分かりますが、示し方は「何を使っているか」ではなく「どう管理しているか」であるべきです。
<a id="certification"></a>
ISMS認証を取るべきか
ISMS（情報セキュリティマネジメントシステム）は、情報の機密性・完全性・可用性を維持し改善するための仕組みで、その国際規格がISO/IEC 27001です。日本国内の認証制度についてはISMS適合性評価制度の公式サイトで、制度の概要と認証取得組織を確認できます。
認証を取るかどうかは、次の軸で判断してください。
取る価値が高いケース
- 取引先や入札の参加要件として明示されている（この場合、判断の余地はほぼない）
- 同業他社が軒並み取得しており、無いこと自体が選定で不利になる
- 顧客の個人情報や機密データを大量に預かる事業構造である
急がなくてよいケース
- 取引先が求めているのが「方針の提出」や「チェックシートへの回答」にとどまる
- 対象にしたい業務範囲が限定的で、認証まで取ると費用対効果が合わない
- そもそも社内の記録が残っておらず、認証審査に耐える運用が今はない
最後のケースが実は最も多いです。認証取得を目標に据えると、審査に通すことが目的化し、審査後に運用が止まる——という失敗が起きます。順序としては、まず方針・規程・記録を回せる状態を作り、それが定着してから認証を検討するほうが、費用も労力も無駄になりません。
なお、認証を取得していなくても、方針と規程を整備し記録を残していれば、取引先のチェックシートには十分に回答できます。「認証がないと何も答えられない」というのは誤解です。
<a id="operation"></a>
作った方針を形骸化させないための条件
方針が形骸化する会社と、しない会社の違いは、次の3点に集約されます。
条件1：記録の様式を先に作る。 「年1回教育を行う」と決めたら、教育の実施記録の様式を同時に作ります。様式がないと、実施しても記録が残らず、翌年「やりましたか」に答えられません。規程を1本作るたびに、対応する記録様式を1枚作るを原則にしてください。
条件2：担当者を名前で決める。 「情報セキュリティ委員会」のような組織名だけでは動きません。誰が、いつまでに、何をするのかを個人名で決めます。兼務で構いませんが、業務として時間を確保することが前提です。
条件3：既存の仕組みに寄せる。 新しい台帳を作るより、既に運用されている仕組み（入退社手続き、資産管理、稟議）に組み込むほうが続きます。人が辞めるときのチェックリストに「アカウント停止」を1行足すのは、独立した台帳を作るより確実です。
逆に、形骸化する典型は「立派な規程一式を一度に作る」です。作った量に運用が追いつかず、半年で誰も見なくなります。最初は薄くてよいので、回る量から始めるほうが結果的に早い。
<a id="response"></a>
取引先から要求されたときの返し方
実際に要求が来たときの実務手順です。
手順1：何を求められているかを確認する。 「情報セキュリティ方針」なのか、「ISMS認証の写し」なのか、「チェックシートへの回答」なのか。この3つは要求水準がまったく違います。曖昧なら、文書で照会して回答を記録に残してください。
手順2：期限と提出先を確認する。 期限が近い場合、認証取得は間に合いません。方針の整備で暫定対応できるかを相手に確認します。
手順3：現状で答えられる範囲を洗い出す。 チェックシートの場合、「できている」「一部できている」「できていない」「該当しない」で正直に埋めます。できていない項目を「できている」と書くのが最悪の対応です。後で実態と食い違えば、取引そのものへの信頼を失います。
手順4：できていない項目に期限を付ける。 「未実施」だけで出すのと、「未実施だが◯月までに整備予定」と出すのでは、受け取る側の評価が変わります。無自覚な未対応と、計画のある未対応は同じではありません。
手順5：自社の委託先にも同じ確認をする。 自社が外注しているなら、その先も含めて初めて実態の回答になります。
<a id="failure"></a>
よくある失敗
- 雛形をそのまま提出する。 適用範囲や自社の実態と合っておらず、深掘りされた時点で答えられなくなる。
- 方針に細かいルールを書き込む。 ルール変更のたびに経営者承認が必要になり、実態と乖離する。
- 記録の様式を作らない。 実施はしているのに証明できず、「やっていない」と同じ評価になる。
- 認証取得を目的化する。 審査を通すことが目標になり、審査後に運用が止まる。
- 適用範囲を全社に広げすぎる。 全業務で記録を残す義務を自ら負い、回らなくなる。
- できていない項目を「できている」と回答する。 実態との食い違いが露見したときの損失が最も大きい。
- 委託先を確認していない。 自社だけ整えても、データが置かれている外注先が抜けている。
<a id="checklist"></a>
着手前チェックリスト
- 取引先の要求が方針／認証／チェックシートのどれかを確認した
- 提出期限を確認し、間に合う対応方法を相手と握った
- 方針の適用範囲を、運用できる大きさに絞って決めた
- 方針に7要素（目的・範囲・経営者責任・遵守義務・法令・教育・見直し）が入っている
- 方針には変わらないことだけを書き、細則は規程へ分けた
- 規程1本ごとに、対応する記録様式を用意した
- 担当者を個人名で決め、業務時間を確保した
- 既存の手続き（入退社・資産管理）に組み込めるものは組み込んだ
- 公開する範囲と社内限定の範囲を分けた（製品名・構成は非公開）
- 自社の委託先にも同じ確認を行う計画を立てた
- 「年1回見直す」と書いたなら、その実施日を決めた
<a id="faq"></a>
よくある質問（FAQ）
Q. 情報セキュリティ方針は公開すべきですか。 A. 公開は任意です。公開すると取引先への説明が省けるという利点があります。ただし公開してよいのは方針までで、規程・手順・使用製品・構成情報は公開しないでください。攻撃側の下調べ材料になります。
Q. 雛形を使ってはいけませんか。 A. 構成の参考として使うのは問題ありません。ただし適用範囲と、自社が実際に守れる約束の2点は必ず自社で書き換えてください。この2点が実態と合っていない方針は、深掘りされた時点で機能しません。
Q. ISMS認証がないと取引できませんか。 A. 取引先の要求次第です。入札や契約の要件として明示されている場合を除けば、方針・規程・記録が整っていればチェックシートには回答できます。「認証がないと何も答えられない」というのは誤解です。
Q. 社内に情シスがいません。誰が作るべきですか。 A. 技術者である必要はありません。社内の情報の所在を把握でき、他部署に依頼でき、記録を続けられる人が適任です。総務・管理部門の担当者が担うケースが多く見られます。ただし兼務でも名前で特定し、時間を確保することが前提です。
Q. どこから手をつければ効率がよいですか。 A. 方針の文章より先に、適用範囲の決定です。範囲が決まれば、必要な規程の本数も、記録すべき対象も自動的に絞られます。範囲を決めずに文章から入ると、際限なく広がります。
Q. 規程は何本くらい必要ですか。 A. 本数に決まりはありません。取引先の要求と自社の業務から必要な領域を洗い出し、回る量から始めるのが原則です。最初から網羅的に作ると、運用が追いつかず半年で形骸化します。
Q. 既に方針だけは作ってあります。次は何をすべきですか。 A. 方針に書いた約束を一つずつ拾い、それぞれに「誰が・いつ・何を記録するか」を割り当ててください。約束と記録の対応表を作ると、抜けている箇所がそのまま次の作業リストになります。
<a id="cta"></a>
体制づくりで迷ったら
情報セキュリティ方針を「提出のための書類」と捉えると1枚で終わり、翌年に困ります。「約束と記録の対応表」と捉えれば、取引先の確認が深まっても答えられる状態になります。違いは文章力ではなく、範囲を絞る判断と、記録様式を先に作る順序にあります。
そして範囲を絞る判断は、外部には代行できません。自社のどの業務が、どの取引に関わり、何を預かっているのか——これを把握しているのは社内だけです。
GXOは特定のセキュリティ製品の販売元ではないため、「今ある仕組みで満たせる部分」と「本当に投資が必要な部分」を分けて整理できます。買わずに済む提案ができる立場です。
- 取引先の要求にどう答えるか、範囲の整理から相談したい → セキュリティ事業
- 規程整備と運用を継続的に任せたい → セキュリティ運用伴走
- 万一の侵害が疑われる状況にある → インシデント対応支援
- サプライチェーンからの要求で困っている → 防衛産業サイバーセキュリティ基準への対応
- 自社のIT・DXの現在地から把握したい → DX成熟度診断
「立派な方針を1枚」ではなく「守れる約束と、その記録」。その設計から、ご一緒します。
参考（一次ソース）
- ISMS適合性評価制度（ISMS-AC）（一次・認定機関。制度概要と認証取得組織の確認）
- 一般財団法人 日本情報経済社会推進協会（JIPDEC）（一次・関連制度の運営団体）
- IPA「情報セキュリティ10大脅威」（一次・公的機関。想定すべき脅威の把握）
- IPA「中小企業の情報セキュリティ対策ガイドライン」（一次・公的機関。専任者のいない企業向けの進め方）
※認証制度の要求事項および規格は改定されます。認証取得を検討する場合は、上記の公式情報および認証機関に最新の要件をご確認ください。本記事は方針整備の実務手順を整理したもので、規格適合性の判定や法的助言を行うものではありません。
