「社長の承認はもらってあります」。ISMS構築の相談で、箇条5の話になるとよく返ってくる言葉です。しかし規格が経営層に求めているのは、方針に署名することではなく、ISMSが機能していることに責任を負うことです。この差が、審査の結果と運用の定着を分けます。
実際、認証取得後にISMSが形骸化する組織には共通のパターンがあります。担当者が一人で回し、経営会議で情報セキュリティの議題が上がらず、リソース要求が「今期は難しい」で止まる。箇条5はまさにこの状態を防ぐために置かれた要求です。
本記事は、箇条5が経営層に何を求めているかを実務に翻訳し、情報セキュリティ方針の書き方、役割と権限の割り当て方、審査での経営層インタビューで確認されることを整理します。前提となる適用範囲の決め方は ISO/IEC 27001 箇条4｜組織の状況、規格全体の見取り図は ISMS（ISO/IEC 27001）とは をご覧ください。
免責：本記事は一般的な情報提供です。規格の要求事項の解釈、認定・認証の取扱いは、ISO/IEC 27001（JIS Q 27001）の規格本文および認定機関・審査機関の公表資料が正本です。実際の対応はそれらに基づいて行ってください。
この箇条が求めていること
箇条5は3つの部分に分かれます。
1. リーダーシップおよびコミットメント
トップマネジメントが果たすべき事柄が列挙されています。要旨をまとめると次のようになります。
- ISMSの方針と目的を定め、組織の事業戦略と整合させること
- ISMSの要求事項を日常の事業プロセスに組み込むこと
- ISMSに必要な資源（人・時間・予算・ツール）を確保すること
- 情報セキュリティマネジメントの重要性と、規格適合の重要性を組織に伝えること
- ISMSが意図した成果を達成することを確実にすること
- ISMSに貢献するよう人々を指揮し支援すること
- 継続的改善を促進すること
- 管理職が自分の責任領域でリーダーシップを発揮できるよう支援すること
ここで決定的なのは**「事業プロセスへの統合」**です。ISMSが通常業務と別立ての活動になっている限り、この要求は満たせません。たとえば新機能の企画レビューにセキュリティ観点のチェックが組み込まれている、委託契約の締結フローにセキュリティ要件の確認が入っている、といった状態が「統合されている」ということです。
2. 方針
情報セキュリティ方針を定め、文書化し、組織内に伝達し、必要に応じて利害関係者が入手できるようにすること。方針には、組織の目的に適していること、情報セキュリティ目的の枠組みを与えること、適用される要求事項を満たすコミットメント、継続的改善のコミットメントが含まれている必要があります。
3. 組織の役割、責任および権限
情報セキュリティに関する役割について、責任と権限を割り当て、組織内に伝達すること。とくに、ISMSが規格に適合していることを確実にする責任と、ISMSのパフォーマンスをトップマネジメントに報告する責任が明確に割り当てられている必要があります。
実務で作る成果物
| 成果物 | 目的 | 誰が承認するか |
|---|---|---|
| 情報セキュリティ方針 | ISMSの方向性を宣言し、目的設定の枠組みを与える | トップマネジメント |
| 方針の周知記録 | 全従業者に伝達したことを示す（配信ログ、受講記録、掲示記録など） | ISMS責任者 |
| ISMS体制図 | 誰がどの役割を担うかを可視化する | トップマネジメント |
| 役割・責任・権限一覧 | 各役割の責任範囲と決定権限を文言で定義する | トップマネジメント |
| 選任・任命の記録 | ISMS責任者・内部監査責任者などの任命を証跡として残す | トップマネジメント |
| 資源提供の記録 | 予算承認、人員配置、ツール導入の決裁記録 | トップマネジメント |
| マネジメントレビュー議事録 | 経営層がISMSの状態を確認し指示を出した記録 | トップマネジメント |
表を見ると分かるとおり、箇条5の成果物はそのほとんどをトップマネジメントが承認します。ここを担当者の代理承認で済ませている組織は、審査で必ず突かれます。
情報セキュリティ方針の書き方
方針は長ければよいものではありません。実務的にはA4で1枚、多くても2枚です。盛り込むべき要素は次のとおりです。
- 何のために情報セキュリティに取り組むのか（事業目的との接続）
- 何を守るのか（適用範囲との接続）
- 適用される法規制・契約上の要求を守るという宣言
- 情報セキュリティ目的を設定し、レビューするという宣言
- 継続的改善のコミットメント
- 全従業者が遵守する義務があること
- 制定日・改定日・承認者（代表者名）
避けるべきなのは、どこの会社にも当てはまる文章だけで構成することです。ヘルスケア企業であれば「医療情報・患者情報を扱う事業者としての責任」を一文入れるだけで、方針は自社のものになります。詳しい書き方は 情報セキュリティ方針の書き方 で扱います。
役割の割り当て
小規模組織では、社長がISMS責任者を兼任するケースがあります。これ自体は禁止されていませんが、「報告する人」と「報告を受ける人」が同一になる構造は、パフォーマンス報告の実効性を説明しにくくなります。実務的には、経営層の別のメンバー、あるいは部門長をISMS責任者に置き、社長がトップマネジメントとして受ける形が整理しやすくなります。
なお、内部監査責任者と内部監査員は外部に委託できます。少人数組織での体制設計は 少人数組織のISMS｜50名以下で取得するときの考え方 を参照してください。
つまずきやすい点
方針に署名しただけで終わっている
もっとも多いパターンです。方針書には代表者の署名があるが、経営会議の議事録には情報セキュリティの議題が一度も登場しない。この状態は審査で見抜かれます。四半期に一度でよいので、経営会議の定例議題にISMSを入れるのが最小の対策です。
「事業プロセスへの統合」を文書の話だと誤解している
統合とは、既存の業務フローの中にセキュリティの判断点が組み込まれることです。文書を作ることではありません。具体例を挙げます。
| 既存の業務フロー | 統合された状態 |
|---|---|
| 新サービスの企画承認 | 企画書にリスク評価欄があり、承認条件になっている |
| 委託先の選定 | 選定基準にセキュリティ要件が含まれ、チェックシートの結果が稟議に添付される |
| 入社手続き | アカウント発行前に教育受講と誓約書提出が完了する運用になっている |
| 退職手続き | 退職日にアカウント無効化とデバイス回収が必ず走る |
| 障害・事故の報告 | 情報セキュリティインシデントの判定基準が同じフローの中にある |
資源の要求が経営層まで届いていない
規格は「必要な資源を確保する」ことを求めますが、そもそも担当者が要求を上げられていないケースが多くあります。必要な資源を要求する経路と、その判断を記録する仕組みを決めておくことが、箇条5とマネジメントレビュー（箇条9）の橋渡しになります。
役割はあるが権限がない
「ISMS責任者」という肩書だけ与えられ、予算執行も人員配置も決められない。この状態では有効性を担保できません。役割一覧には責任だけでなく権限（何を決められるか）を明記します。
方針が従業員に届いていない
社内ポータルに置いただけでは「伝達した」とは言いにくい面があります。教育の中で必ず読ませる、受講記録を残す、といった形で到達を確認できる伝達方法にしておくと確実です。教育の設計は 従業者教育の設計｜受講率100%の運用 をご覧ください。
審査で見られること
箇条5の確認は、多くの場合2次審査での経営層インタビューという形を取ります。30分から1時間程度、トップマネジメントに直接質問が行われます。よく聞かれる論点は次のとおりです。
| 質問の趣旨 | 確認されていること |
|---|---|
| 自社にとっての情報セキュリティリスクは何か | 経営層自身がリスクを把握しているか（担当者任せでないか） |
| なぜISMSに取り組むのか | 事業戦略との接続を経営層の言葉で説明できるか |
| 今期の情報セキュリティ目的は何か | 目的が経営層の関心事になっているか |
| ISMSにどんな資源を提供したか | 予算・人員の具体的な提供実績があるか |
| 直近のインシデントについて報告を受けたか | 報告経路が機能しているか |
| マネジメントレビューで何を指示したか | 指示が出され、追跡されているか |
答えの巧拙よりも、具体性が見られています。「セキュリティは重要だと考えています」で終わる回答と、「昨年度は委託先の管理が弱点だったので、今期はチェックシートの改訂に工数を割り当てました」という回答では、評価が変わります。
経営層インタビューの準備は、事前に想定質問を渡して読み合わせをするだけで質が大きく変わります。2次審査の全体像は 2次審査（実地審査）で見られること、指摘されやすい点は 審査でよくある不適合と対策 にまとめています。
ヘルスケア企業での具体例
医療SaaS事業者の場合
この業態では、経営層の関与が取引条件そのものに直結します。医療機関の調達では、セキュリティに関する説明責任を負う経営層の体制を問われることがあり、「担当者レベルでは回答できない」場面が実際に発生します。方針には、医療情報を預かる事業者としての責任を明記し、経営会議で顧客からのセキュリティ照会件数と対応状況を定期的に確認する運用にしておくと、営業と運用の両方が回ります。
PHR事業者の場合
利用者本人から直接データを預かるため、方針に**「本人の同意の範囲を超えて利用しない」という宣言**を含めるかどうかが実質的な論点になります。含める場合は、それが守られていることを示す運用（データ利用の申請・承認フロー、ログ）まで設計する必要があります。宣言と運用が食い違えば、方針そのものが不適合の根拠になり得ます。
治験システムを扱う企業の場合
規制当局の査察と審査機関の審査という二重の外部確認を受ける立場になります。役割一覧では、品質保証部門とISMS責任者の責任境界を明確にしておかないと、どちらの権限で記録を承認したのかが曖昧になります。
SaMD開発企業の場合
QMSの管理責任者とISMS責任者を別人が務める場合、同じ設計変更に対して二つの承認ルートが走ることになります。役割一覧の段階で、どの文書はどちらの承認を要するかを表にしておくのが有効です。関連する論点は SaMDとISMS・QMS（ISO 13485）の関係 で扱います。
いずれの業態でも共通するのは、経営層が「うちの情報資産で最も守るべきものは何か」を自分の言葉で言えることです。ヘルスケア企業の適用範囲設計は ヘルスケア企業のISMS適用範囲設計、医療機関側が委託先の体制をどう見ているかは ベンダーへのセキュリティチェックシート が参考になります。
まとめ
- 箇条5が求めるのは署名ではなく、ISMSの有効性に対する経営層の責任。事業プロセスへの統合が中核
- 成果物のほとんどをトップマネジメントが承認する。代理承認で済ませている組織は審査で指摘される
- 情報セキュリティ方針はA4で1〜2枚。自社固有の一文があるかどうかで質が決まる
- 役割一覧には責任だけでなく**権限（何を決められるか）**を書く
- 箇条5の審査は経営層インタビューが中心。答えの巧拙ではなく具体性が見られる
- 最小の実装は、経営会議の定例議題にISMSを入れること。四半期に一度でも運用は変わる
方針で示した方向性は、次の 箇条6 計画｜リスクアセスメントと情報セキュリティ目的 で具体的な目的とリスク対応に落とし込まれ、箇条7 支援｜力量・認識・文書化した情報 で人と文書の基盤が整います。実行は 箇条8 運用、点検は 箇条9 パフォーマンス評価、改善は 箇条10 改善 です。
ポテックは、ヘルスケア領域に特化してISMS認証取得を支援しています。経営層インタビューの想定質問の準備や、方針・体制図の設計もご支援の範囲です。支援内容と料金は ISMS認証取得支援サービス、個別のご相談は お問い合わせ から承ります。
参考・出典
- 情報マネジメントシステム認定センター（ISMS-AC）
- ISO/IEC 27001 Information security management systems｜ISO
- 日本産業標準調査会（JISC）
- 医療情報システムの安全管理に関するガイドライン｜厚生労働省
※規格の要求事項の解釈、認定および認証の取扱いは、規格本文および認定機関・審査機関の公表資料をご確認ください。改定や運用の見直しにより取扱いが変わる場合があります。