情報セキュリティ方針は、ISMSで最初に作る文書であり、最も短時間で作られ、最も読まれない文書でもあります。ひな形を持ってきて社名を入れ、代表取締役の名前と日付を入れて完成。A4で1枚。そのままウェブサイトに掲載して、以後3年間手を触れない——この扱いをしている組織は少なくありません。
形式としてはそれで審査を通ることもあります。問題は、方針が本来果たすべき役割を果たしていないことです。方針は、リスク対応の判断が割れたときに立ち返る基準であり、情報セキュリティ目的（箇条6.2）の上位にある枠組みです。「顧客への影響と社内の利便性のどちらを優先するか」といった判断は、日常的に発生します。方針に何も書かれていなければ、その判断は毎回ゼロから議論することになります。
本記事は、方針に規格が求める要素、社外版と社内版の作り分け、そして目的とのつながりを整理します。方針が参照する計画の詳細は 箇条6 計画｜リスクアセスメントと情報セキュリティ目的、規格全体は ISMS（ISO/IEC 27001）とは をご覧ください。
免責：本記事は一般的な情報提供です。規格の要求事項の解釈、認定・認証の取扱いは、ISO/IEC 27001（JIS Q 27001）の規格本文および認定機関・審査機関の公表資料が正本です。実際の対応はそれらに基づいて行ってください。
なぜここでつまずくのか
1. 「宣言」だけで済ませてしまう
方針という言葉から連想されるのは、経営者による理念の表明です。そのため「当社は情報セキュリティを重要な経営課題と認識し、全社を挙げて取り組みます」という宣言文が並び、何一つ決めていない文書ができあがります。宣言は必要ですが、それだけでは方針の役割を果たしません。
2. 社外公開を前提に書きすぎる
ウェブサイトに掲載することを前提に書くと、具体的な記述ができなくなります。「多要素認証を必須とする」「本番環境の患者データへのアクセスは原則禁止とする」といった記述は、社外に出すには詳細すぎる。結果として、社外向けの抽象度で社内の判断基準まで賄おうとして、どちらにも使えない文書になります。社外版と社内版を分けるのが正解です。
3. 目的（箇条6.2）とのつながりが切れている
規格は、情報セキュリティ目的が方針と整合していることを求めています。ところが方針が抽象的すぎると、整合しているかどうかを判定できません。「セキュリティを重視する」という方針と、「年次教育の受講完了率100%」という目的の間に、論理的なつながりを見出すのは困難です。目的の上位に立つ枠組みとして方針を書くという発想が必要です。
4. 改訂されない
方針は、ISMSの変更に応じて見直されるべき文書です。適用範囲が広がった、扱う情報の性質が変わった、重大なインシデントがあった——こうした変化が方針に反映されていないと、実態と乖離します。
何を決めるのか
規格が方針に求める要素は、要旨として次のとおりです。逐語ではなく、実務の言葉で整理します。
| 規格が求める要素 | 実務での書き方 |
|---|---|
| 組織の目的に対して適切であること | 自社の事業内容と、扱う情報の性質に言及する。ひな形の一般論で終わらせない |
| 情報セキュリティ目的の枠組みを与えること | 「何を優先するか」の順序や原則を書く。目的はここから導かれる |
| 適用される要求事項を満たすコミットメント | 法令・規制・契約上の要求への適合を明示する |
| ISMSの継続的改善へのコミットメント | PDCAを回し続けることを明示する |
| 文書化した情報として利用可能であること | 版管理された文書として維持する |
| 組織内に伝達されること | 全従業者が読める状態にし、周知の記録を残す |
| 必要に応じて利害関係者が入手可能であること | 「必要に応じて」であり、全文公開の義務ではない |
最後の点が、社外版・社内版の作り分けの根拠です。規格は方針の全文公開を求めていません。 利害関係者が必要とする範囲で入手可能であればよい。したがって、詳細を含む社内版を正本とし、社外向けには抜粋または要約版を掲載するという設計が成立します。
社外版と社内版の作り分け
| 社外公開版 | 社内版（正本） | |
|---|---|---|
| 目的 | 取引先・利用者に姿勢と体制を示す | 従業者の判断基準になる |
| 分量 | A4で1枚程度 | A4で2〜4枚。下位規程への参照を含む |
| 記述の粒度 | 原則と体制まで | 優先順位、禁止事項、例外の扱いまで |
| 掲載先 | ウェブサイト | 社内ポータル、文書管理システム |
| 承認 | トップマネジメント | トップマネジメント |
| 改訂頻度 | 大きな変化があったとき | 年1回のマネジメントレビューで見直し |
社内版に書くべきで、社外版に書かないものの例を挙げます。
- 顧客データと社内の利便性が衝突した場合の優先順位
- 本番環境の顧客データへのアクセスに関する原則と例外の条件
- 私物端末（BYOD）の可否
- 生成AIサービスへの業務情報の入力に関する原則
- 委託先に再委託を認めるかどうかの原則
- インシデント発生時に、報告を優先するか復旧を優先するかの原則
これらは「判断が割れる論点」です。 方針に書いておけば、現場が毎回議論せずに済みます。逆に言えば、方針に書くべきことは「判断が割れる論点についての、組織としての立場」です。
実務の手順
手順1：判断が割れる論点を洗い出す
方針を書く前に、社内で判断が割れた、あるいは今後割れそうな論点を集めます。過去のインシデント、ヒヤリハット、現場からの問い合わせが素材になります。この作業をせずにひな形から書き始めると、必ず抽象的な文書になります。
手順2：それぞれに組織としての立場を決める
洗い出した論点に対し、トップマネジメントが立場を決めます。ここが方針作成の本体で、文章を書く作業ではなく意思決定の作業です。決められない論点は、方針には書かず、下位規程で個別に扱う形にします。
手順3：リスクアセスメントの結果を反映する
方針は、リスクアセスメントより先に作られることもあれば、後になることもあります。**理想は「先に暫定版を作り、リスクアセスメント後に確定させる」**という順序です。リスクアセスメントで見えた自社固有のリスクが、方針に反映されていると、目的との整合が取りやすくなります。前工程は リスクアセスメントの進め方｜評価基準の設計 と リスク対応計画とリスク受容の判断 をご覧ください。
手順4：社内版を書く
構成の例を示します。
| 節 | 内容 |
|---|---|
| 1. 目的 | 何のためにこの方針を定めるか。自社の事業と扱う情報に言及する |
| 2. 適用範囲 | ISMSの適用範囲と、方針が拘束する対象者（雇用形態を含む） |
| 3. 基本原則 | 機密性・完全性・可用性の維持。自社にとっての優先順位を明示する |
| 4. 遵守事項 | 法令・規制・契約・業界ガイドラインへの適合 |
| 5. 体制と責任 | トップマネジメント、ISMS責任者、部門、全従業者の責任 |
| 6. 判断の原則 | 判断が割れる論点への立場（前述の一覧） |
| 7. 目的の設定 | 情報セキュリティ目的を設定し、定期的に見直すこと |
| 8. 教育 | 全従業者への教育と、遵守の義務 |
| 9. 違反時の扱い | 就業規則との関係 |
| 10. 継続的改善 | PDCAを回すこと。見直しの頻度 |
| 11. 制定・改訂履歴 | 版、日付、承認者 |
第3節と第6節が方針の中核です。ここに具体性がなければ、残りは定型文で足ります。
手順5：社外版を作る
社内版から、原則と体制に関する部分を抜き出して構成します。社外版に必要なのは、次の4点です。
- 経営としてのコミットメント
- 適用範囲（どの事業・どのサービスが対象か）
- 基本原則（何を守るか、何を優先するか）
- 法令・規制・業界ガイドラインへの適合の表明
ヘルスケア企業であれば、4番目に3省2ガイドラインへの言及を入れることが有効です。 顧客である医療機関が委託先を評価する際、この一文があるかどうかで印象が変わります。ガイドラインの全体像は既存記事の 3省2ガイドラインとは をご覧ください。
手順6：周知し、記録を残す
方針を全従業者に伝達し、伝達した記録を残します。教育の受講記録に「方針の説明を含む」と明記する、あるいは方針の閲覧・同意の記録を取る形が一般的です。審査では「従業者が方針を知っているか」が現場で確認されるため、周知の方法と記録は設計しておく必要があります。従業者教育の設計は 従業者教育の設計｜受講率100%の運用 で扱います。
手順7：目的（箇条6.2）と紐づける
方針の第3節・第6節から、情報セキュリティ目的を導きます。紐づけの例を示します。
| 方針の記述 | そこから導かれる目的 | 指標と目標値 |
|---|---|---|
| 顧客から預かる医療情報の機密性を最優先する | 本番環境の顧客データへのアクセスを統制下に置く | 統制外アクセスの件数：0件／四半期 |
| 全従業者が自らの責任を理解した状態を維持する | 全従業者が年次教育を修了する | 受講完了率：100%（年度末時点） |
| 委託先に対しても同等の管理水準を求める | 対象委託先の年次評価を完了する | 評価実施率：100% |
| インシデントは隠さず、速やかに報告する | 検知から初動着手までの時間を短縮する | 平均時間：4時間以内 |
| 事業継続に必要な可用性を維持する | バックアップからの復旧可能性を確認する | 復旧テスト：年1回実施し記録を残す |
この表が作れるかどうかが、方針の具体性のテストになります。 左列に「セキュリティを重視する」しか書けないなら、方針が抽象的すぎます。目的の立て方は 情報セキュリティ目的とKPIの立て方 で詳しく扱います。
よくある失敗
抽象的すぎて何も決めていない
最も多い失敗です。典型的な文言と、その改善例を挙げます。
| 何も決めていない記述 | 判断基準になる記述 |
|---|---|
| 情報セキュリティを重要な経営課題と認識します | 当社が顧客から預かる医療情報について、機密性の維持を社内の業務効率に優先する |
| 適切なアクセス管理を行います | 本番環境の顧客データへのアクセスは原則として禁止し、例外は申請・承認・期限・記録を伴う場合に限る |
| 従業員教育を実施します | 全従業者は年1回の情報セキュリティ教育を受講する義務を負い、未受講は就業上の問題として扱う |
| 委託先を適切に管理します | 医療情報を取り扱う委託先には、当社と同等の管理水準を契約で求め、無断の再委託を禁止する |
| インシデントに適切に対応します | インシデントの疑いがある事象は、確証がなくとも直ちに報告する。報告したことによる不利益な取扱いは行わない |
| 法令を遵守します | 個人情報保護法および医療情報システムの安全管理に関するガイドラインへの適合を維持する |
右列の共通点は、読んだ人が行動を変えられることです。左列は読んでも何も変わりません。
社外版と社内版を分けていない
1つの文書で両方を賄おうとすると、社外に出せる抽象度に引きずられ、社内の判断基準として機能しなくなります。分けるのが正解です。
下位規程への参照がない
方針だけで全部を書こうとすると、長大になり読まれません。方針は原則を示し、詳細は下位規程に委ねる構造にします。文書体系の設計は ISMS文書体系｜何をどこまで作るか で扱います。
承認者が明記されていない／日付が古い
方針はトップマネジメントが承認する文書です。承認者名と承認日が入っていない方針は、それだけで指摘の対象になります。また、数年前の日付のまま更新されていない方針は、「実態と合っているか」を問われます。
ひな形の一般論のまま、自社の事業に言及していない
規格は方針が組織の目的に対して適切であることを求めています。どの業種でも通用する文面は、この要求を満たしているとは言いにくい。扱う情報の性質（医療情報、要配慮個人情報など）に1行でも言及することで、大きく変わります。
周知の記録がない
文書は存在するが、従業者が読んだ記録がない。審査では現場の従業者に方針の内容が確認されます。周知の方法と記録を設計しておく必要があります。
目的との整合が説明できない
方針が抽象的だと、目的との整合を問われたときに答えられません。手順7の紐づけ表を作っておくと、審査での説明がそのまま済みます。
ヘルスケア企業の例
医療機関向けSaaSを提供する企業
社内版の第3節（基本原則）に入れるべき固有の一文は、機密性・完全性・可用性の優先順位です。医療機関向けSaaSの場合、単純に機密性が最優先とは言い切れません。診療時間中にシステムが止まれば診療が止まるため、可用性の毀損も患者に直接影響します。**「診療業務の継続に必要な可用性と、患者情報の機密性を、いずれも事業運営上の最優先事項とする」**といった記述で、両者の重みを明示しておくと、リスク対応での判断が安定します。
第6節（判断の原則）には、本番データへのアクセス原則を必ず入れます。これが最も判断の割れる論点であり、方針で立場を決めておく価値が最も高い項目です。
PHR事業者
利用者本人からデータを預かる構造上、同意の範囲を超えた利用を行わないことを方針レベルで明記するのが有効です。個人情報保護法の要請と重なるため、法務と共同で文言を決めます。詳細は PHR事業者のISMS｜個人情報保護法との関係 をご覧ください。
治験・臨床研究システムを扱う企業
完全性を機密性と並べて最優先に置く記述が必要です。「データの完全性と監査証跡の保全を、事業運営上の最優先事項の一つとする」という一文が、リスク評価の尺度設計（完全性を別軸で定義する）の根拠になります。
SaMDを開発する企業
情報セキュリティ方針と、品質方針（ISO 13485）が並存します。両者の関係を方針の中で言及しておくと、二重管理の整理がしやすくなります。「本方針は情報資産の保護を対象とし、製品の安全性および有効性に関する事項は品質方針および関連手順に従う」といった切り分けです。SaMDとISMS・QMSの関係 で扱います。
共通：社外版に入れる一文
顧客である医療機関は、委託先の方針を実際に読みます。社外版に 「医療情報システムの安全管理に関するガイドラインをはじめとする業界ガイドラインへの適合を維持する」 という趣旨の一文があると、調達時のやり取りが短くなります。ガイドライン対応の実務は 3省2ガイドライン対応の実務ステップ、医療機関側のクラウド利用の論点は 医療機関のクラウドセキュリティ をご覧ください。
まとめ
- 方針は宣言ではなく、判断が割れたときに立ち返る基準。書く作業の本体は文章ではなく意思決定
- 社外公開版と社内版を分ける。規格は全文公開を求めていない。社内版を正本とし、社外には抜粋を出す
- 方針に書くべきは**「判断が割れる論点についての組織の立場」**。本番データへのアクセス、BYOD、生成AIの利用、再委託の可否など
- 「セキュリティを重視します」型の記述は何も決めていない。読んだ人が行動を変えられる記述に置き換える
- 方針の記述から情報セキュリティ目的が導ける構造にする。紐づけ表が作れないなら方針が抽象的すぎる
- トップマネジメントの承認、周知の記録、年1回の見直しを欠かさない
方針が固まったら、そこから 情報セキュリティ目的とKPIの立て方 で目的を導き、ISMS文書体系｜何をどこまで作るか で下位規程を整備します。方針の前提となる範囲の設計は ISMS適用範囲の決め方 をご覧ください。
ポテックは、ヘルスケア領域に特化してISMS認証取得を支援しています。方針のひな形提供に加え、「判断が割れる論点」の洗い出しと、ヘルスケア固有の記述の設計をご支援できます。支援内容と料金は ISMS認証取得支援サービス、個別のご相談は お問い合わせ から承ります。
参考・出典
- 情報マネジメントシステム認定センター（ISMS-AC）
- ISO/IEC 27001 Information security management systems｜ISO
- 日本産業標準調査会（JISC）
- 医療情報システムの安全管理に関するガイドライン｜厚生労働省
- 個人情報保護委員会
※規格の要求事項の解釈、認定および認証の取扱いは、規格本文および認定機関・審査機関の公表資料をご確認ください。改定や運用の見直しにより取扱いが変わる場合があります。