中小企業が情報セキュリティポリシーを作る手順

取引先からセキュリティチェックシートが届いた際、「情報セキュリティポリシーを添付してください」と指示されたことはありませんか？
大企業や官公庁との取引において、セキュリティ体制の証明を求められる機会は着実に増えており、「うちは小さい会社だから関係ない」という状況ではなくなっています。

官公庁の案件に応募しようとした段階で、情報セキュリティ体制を証明する文書の提出を求められ、自社にはそういった文書がないことに初めて気づくケースも珍しくありません。

この記事では、情報セキュリティポリシーをゼロから整備したい中小企業の経営者・担当者に向けて、作成の5つのステップと、テンプレートを活用する際に押さえるべき点をお伝えします。

ISMSやプライバシーマークなどの認証制度への対応を目指すものではなく、自社の取り組みを正確に言語化するための実務的な手順です。

情報セキュリティポリシーとは何か、どんな役割を持つのか

「情報セキュリティポリシー」を簡単にいえば「社内のセキュリティルールを文書化したもの」という説明になるのですが、ただそれだけではその実態と必要性が伝わりにくいと思います。
そこで、なぜ今この文書が必要なのか、何をカバーするものなのかを整理します。

ポリシー・規程・手順書の違いを整理する

「情報セキュリティポリシー」という言葉は、文脈によって指す範囲が異なります。実務的に望ましいのは、経営方針を示す「基本方針（ポリシー）」、具体的なルールを定める「規程」、実際の操作手順を記した「手順書」という三層構造で整理するのが大切です。

取引先への提出を求められる「情報セキュリティポリシー」は、多くの場合この基本方針の文書を指しています。３つを混同したまま作業を始めると、求められている文書と実際に作るものがずれるという事態が起きます。整備を始める前に、この三層構造を頭に入れておくことが、作業全体の見通しをよくします。

社内向けと対外向け

情報セキュリティポリシーには、社内の従業員に対する行動指針としての役割と、取引先や審査機関への証明文書としての役割の二つがあります。セキュリティチェックシートや入札要件で「添付してください」と求められるのは後者の文脈です。

この二つの機能を最初に整理しておくことが、実効性のある文書設計の前提になります。「対外提出のために作った文書が社内では誰も読んでいない」という状態や、逆に「細かすぎる社内向け手順書を取引先に提出してしまった」という状態は、どちらも目的とずれた使い方です。

中小企業に求められるのは大企業並みの文書ではない

ISMSのような認証体制を前提とした文書と、「取引先に提出できる基本的な方針文書」とは、求められる水準が異なります。後者であれば、従業員数名の企業でも整備は十分に可能です。

「情報セキュリティポリシーを作る」と聞くと、分厚いマニュアルを作成しなければならないという印象を持つ方もいますが、そうではありません。この記事では、中小企業が現実的に着手できる範囲に絞って手順を示します。

ポリシーがないことで生じる、具体的な場面と影響

なぜ今整備する必要があるのかを、実際に起きていることとして示します。

取引・入札の場面で「提出できない」ケースが増えている

大企業のサプライチェーン管理強化と、官公庁のセキュリティ要件の厳格化は、着実に進んでいます。数年前であれば問われなかった場面でも、今は情報セキュリティポリシーの提出が前提になっているケースが増えています。

「文書がないから提出できない」という状況が、新たな取引機会の喪失に直結するという経営上のリスクとして認識しておく必要があります。「いつかは作ろう」という判断が、「この案件では間に合わなかった」という結果になることが、実際に起きています。

インシデントが起きたとき、対応の根拠がない状態になる

個人情報漏洩や不正アクセスが発生した際、「どう対応すべきか」の基準がなければ、対応は担当者のその場の判断に委ねられます。後から「ポリシーに従った対応をした」と説明できない状態は、法的責任と対外的な説明責任の両面で問題が生じます。

個人情報保護法の規定により、漏洩等が発生した場合に個人情報保護委員会への報告義務が生じるケースがあります。その際に「社内にどのようなルールがあり、どう対応したか」を示せるかどうかは、事後対応の質に直結します。

社員に「何をしてはいけないか」を正式に伝える根拠がない

ポリシーがなければ、社員への周知・教育の根拠が曖昧になります。「言った・言わない」という属人的な運用が続く状態は、インシデント発生時の内部責任の所在を不明確にします。

組織として取り組んでいたことを証明する手段がない、という問題でもあります。
「社員がSNSに業務関連の情報を投稿してしまった」
「個人のUSBメモリを業務端末に挿した」
という事案が起きたとき、禁止されていることを知っていたか否かを問う根拠となる文書の存在が、対応の出発点になります。

情報セキュリティポリシーを作る5つのステップ

各ステップの意味と、特に留意すべき点を順に説明します。手順の列挙ではなく、なぜそのステップが必要なのかを理解した上で作業を進められるよう、補足を加えながら整理します。

ステップ1：自社が扱う情報を棚卸しする

まず「どのような情報を、誰が、どのような形で扱っているか」を一通り書き出します。顧客の個人情報、取引先との契約情報、社内の財務データ、従業員の給与情報など、情報の種類と重要度を整理することが出発点です。

この棚卸しを省くと、ポリシーの適用範囲が曖昧なまま文書化が進むことになります。「何を守るべきか」が明確でなければ、どれだけ体裁の整った文書を作っても、実態との乖離が生じます。クラウドストレージに保存しているファイルの種類、メールで送受信する情報の内容なども、この段階で洗い出します。

ステップ2：適用範囲と対象者を決める

「全社員を対象とする」という記述だけでは、現代の多様な就労形態には対応しきれません。派遣・パート・業務委託など、雇用形態の異なる関係者がいる場合、誰が対象に含まれるかを明確にする必要があります。

また、クラウドサービスの利用状況や在宅勤務の有無、個人端末での業務利用の実態など、自社の業務環境に応じた範囲設定が求められます。特に「個人のスマートフォンで会社のメールを確認している」「業務に関する連絡をLINEで行っている」といった状況がある場合は、それを前提とした適用範囲の設計が必要です。

ステップ3：基本方針を策定する

「基本方針」は、経営者が情報セキュリティに対してどのようにコミットするかを表明する文書です。分量は1〜2ページ程度が一般的で、取引先への提出や入札要件の充足を目的とする場合は、この基本方針が主な提出対象になる場合が多いようです。（※例外もあります）

重要なのは、経営者自身がこの文書の内容をしっかり把握した上で、自身の名の下で発行することです。実務上は担当者が作成した文書であっても、最終的には経営者名で発行することが、対外的な証明力を持たせる条件になります。

「情報セキュリティの確保は経営課題である」という認識を、経営者が文書の形で示すということがこのステップの核心です。
こちらの記事も参考にしてください→セキュリティ対策に消極的な経営者が問われる責任とは？任せるだけでは守れない法的リスク

ステップ4：規程を文書化する

「規程」は基本方針を具体的なルールとして落とし込んだものです。情報の取り扱い方法、システム利用のルール、インシデント発生時の対応手順など、社員が実際の業務で参照できる内容に仕上げます。

この段階でテンプレートを活用する企業が多いですが、そのまま流用することで生じる問題については、次の章で詳しく扱います。なお、基本方針と規程を別文書として管理すると、対外提出用と社内運用用の使い分けがしやすくなります。取引先には基本方針のみを提出し、具体的なルールを記した規程は社内で管理するという運用が実務的には機能します。

ステップ5：経営者による承認と社員への周知

作成した文書は、経営者が正式に承認した上で社員に周知する手続きが必要です。承認のないポリシーは単なる案に過ぎず、対外的な証明力を持ちません。作っただけで満足してしまうという状態を防ぐ最初の関門がこのステップです。

承認の記録（署名や日付入りの決裁文書）を残しておくと、取引先や審査機関への説明の際に有効に機能します。周知については、全社会議での説明、イントラへの掲示、入社時オリエンテーションへの組み込みなど、規模に応じた方法で行います。社員全員がルールが存在することを知っている状態を作ることが、最初の目標です。

テンプレートの使い方と、カスタマイズが必要な理由

情報セキュリティポリシーの作成に限られませんが、文書作成にあたってテンプレートを探すこと自体は合理的な判断だといえます。ただし、そのまま使うことで生じる問題については、具体的に把握しておく必要があります。

公的機関のテンプレートをまず確認する

IPA（独立行政法人 情報処理推進機構）や中小企業庁が無償で公開しているテンプレートは、作成の出発点として有用です。ゼロから書き起こすよりも、これらを土台として活用することで作業時間を大幅に短縮できます。

ただし、「活用できる部分」と「そのままでは使えない部分」を区別することが、効果的な利用の前提です。テンプレートはあくまでも骨格であり、自社の状況に合わせて肉付けしていく作業が必要になります。

テンプレートをそのまま使ってはいけない２つの理由

一つ目は、法令対応の問題です。

テンプレートは汎用的に設計されているため、最新の法令改正に追いついていない場合があります。
個人情報保護法は2022年に大きく改正されましたが、古いテンプレートではこの改正に対応しておらず記述が不十分なものが少なくありません。
また、特定の業種に適用されるガイドライン（金融・医療・EC事業者向けなど）の要求事項は、一般向けテンプレートには通常含まれていません。

二つ目は、自社のシステム・業務環境との不整合です。

どのクラウドサービスを使っているか、社員が個人端末で業務メールを確認しているか、在宅勤務の仕組みはどうなっているかといった具体的な環境は、テンプレートには当然反映されていません。「クラウドストレージの利用ルール」「個人端末での業務利用の可否」が明記されていないポリシーは、作成した時点で実態と乖離した文書になります。

さらに言えば、実態と乖離したポリシーは、ポリシーがない状況より問題が大きくなる場合があります。たとえば、インシデント発生時に「ポリシーには毎日バックアップすると書いてあるが、実際はしていなかった」という状態が明らかになれば、自社のポリシー違反として対外的な説明責任が生じます。形式を整えることと、実態に即した内容にすることは、切り離せない問題です。

最低限カスタマイズすべき項目

テンプレートを土台にする場合でも、以下の項目は必ず自社の情報に置き換えることが必要です。

  • 経営者名・会社名・作成日・版番号
  • 適用範囲（対象者・対象システム・対象情報の具体的な列挙）
  • インシデント発生時の連絡先と対応フロー
  • 利用するクラウドサービスや業務システムに関するルール
  • 個人情報の取り扱いと、外部委託先への管理に関する記述

これらが「テンプレートのまま」になっている文書は、実態との乖離が生じやすい箇所です。特に連絡先や対応フローが架空の情報のままになっているケースは、実際のインシデント対応時に文書が機能しないことを意味します。

将来的な認証取得を見据えた構造設計という考え方

現時点でISMSやプライバシーマークの取得を目指していない企業でも、最初から「認証に対応できる構造」で文書を作っておくことには、実際的なメリットがあります。

ISMSの要求事項に沿った三層構造（基本方針・規程・手順書）で整備しておくと、将来的に取引先からISMS取得を求められた際に、文書を一から作り直す必要がなくなります。中小企業でよく見られる「取得を求められてから慌てて整備する」という状況は、コストと時間の両面で非効率です。今の段階で「認証に耐えうる骨格」を持たせておくことが、中長期的には合理的な選択です。これは文書設計と技術要件の両方を理解していないと判断しにくい領域であり、専門家への相談が特に効果を発揮しやすい部分です。

作成後に必要な運用の最低ライン

作っただけで放置されているという状態を防ぐために、いくつか留意しておくべき点があります。高度な仕組みではなく、中小企業が現実的に続けられる最小限の運用を示します。

年1回の見直しと版管理を習慣にする

法改正・業務環境の変化・インシデントが見直しのタイミングです。文書には「版番号」と「最終改定日」を記載することで、取引先への提出時に「最新の文書です」と説明できるようになります。

年1回を目安としつつ、大きな変化、たとえば新しいクラウドサービスの導入、在宅勤務の開始、スタッフの大幅な入れ替えなどがあった際に随時更新する体制が望ましいです。

見直しの記録自体が、ポリシーを実際に運用している証拠にもなりますし、「定期的に見直している」という事実は、取引先への説明においても信頼の根拠になります。

形式より「社員も知っている状態を作ること」が目的

全社会議での読み合わせ、入社時オリエンテーションへの組み込み、定期的な研修実施、イントラへの掲示など、規模に応じた方法で社員全員に周知させることが大切です。

重要なのは、精緻な研修体制を構築することよりも、まず社員全員が「情報セキュリティに関するルールが存在することを知っている」状態を作ることです。

署名や確認票などにより確認した記録を残せると、万が一の際の内部説明に有効に機能します。ただし、小規模な組織においては周知の事実が確認できれば、最初の一歩としては十分です。完璧な体制を最初から構築しようとするよりも、まず動かすことが先決です。

まとめ

情報セキュリティポリシーの整備は、大企業だけが取り組むべき話ではなくなっています。取引要件として求められる機会が増えている現状は、これからもその方向に進み続けると見るのが現実的な判断です。

同時に、「完璧なものを一度に作ろうとしない」という姿勢も大切です。
最初は基本方針と最低限の規程からでも十分です。
大切なのは、テンプレートを流用して形式を整えたり、生成AIでそれっぽい文書をつくることよりも、自社の実態に即した内容になっているかどうかです。そしてできれば、将来の拡張を見据えた構造で最初から作っておくことが、後からの手間を省くことにつながります。

5つのステップを順に踏めば、専門知識がなくても骨格となる文書は作れます。ただし、法令への適合性と技術環境との整合性を同時に確認するためには、両方の視点を持つ専門家に見てもらうことが、後から手直しするよりも結果的に効率的です。

情報セキュリティポリシーの作成・見直しについてご不明な点があれば、まずはご相談ください。

法令への適合性という行政書士の視点と、自社のIT環境に即した内容かどうかという登録セキスペの視点。この両面から確認することで、取引先への提出にも社内運用にも機能する文書に仕上げます。具体的なサービス内容については、セキュリティ支援サービスのページをご覧ください。

取引先からセキュリティチェックシートが届いた場合の具体的な対応手順については、こちらの記事で詳しく解説しています。

・セキュリティチェックシートとは？届いたときの見方・よくある項目・対応の流れ