文書化されたセキュリティポリシーは、ネットワークセキュリティを直接向上させるものではない。そのため、セキュリティ専門家の中には、文書化されたポリシーの要件を軽視する者もいる。しかし、成熟した組織のセキュリティ専門家は、文書化されたポリシーの重要性とメリットを理解しているだけでなく、正式に策定されたポリシーをセキュリティ成熟度向上への第一歩における基本要件と定める規定を起草し、その導入を推進している。
ポリシーは、各組織が情報をどのように管理、保護、配布するかを定める指示、規則、ルール、実務の基盤となる。さらに、規制当局は、正式なポリシーの欠如を過失とみなし、情報漏えい後の罰金や処分が重くなる原因として指摘することも多い。
この記事では、以下のトピックを通じてITセキュリティポリシーを解説する。
- ITセキュリティポリシーの究極の目的とは？
- ITセキュリティポリシーの重要性と目的
- ITセキュリティポリシーの主な6つのメリット
- セキュリティポリシーの3つの種類
- ITセキュリティポリシーを作成する5つのベストプラクティス
- 4ステップでセキュリティポリシーを作成する方法
- 結論：集中力を高めるためにポリシーを作成する
ITセキュリティポリシーの究極の目的とは？
ITセキュリティポリシーの究極の目的は、組織のITおよびサイバーセキュリティ態勢を評価する基準となる、正式なルールとポリシーの一式を提供することだ。この基準はさまざまな目的に利用できるが、最も多く使われるのは次の用途である。
- リスクが管理・統制されていることを示す
- コンプライアンス上の義務を果たす
- 統制と担当者の品質・能力を測定する
- 情報漏えい発生時の責任リスクを軽減する
ITセキュリティポリシーの重要性と中核的な目的
米国国立標準技術研究所（NIST）は、情報セキュリティ入門（NIST SP 800-12）を公開し、次のように定義している。
「情報セキュリティポリシーとは、組織が情報をどのように管理、保護、配布するかを規定する指示、規則、ルール、実務の総体である。」
文書化されたポリシーに不慣れな組織にとって、セキュリティポリシーの策定を始めることは気が重いかもしれない。しかし、すべての組織は、文書化されていない非公式な戦略として機能するセキュリティ戦略を導入している。こうした非公式のセキュリティ戦略の大きな欠点は、リソースの保護に失敗した際、ITチームとセキュリティチームが適切かつ十分なサイバーセキュリティ戦略を実行したことを、規制当局や陪審に証明するのが難しくなることだ。
文書化されたポリシー、特に定期的な報告を求めるポリシーは、コンプライアンスの証拠を自然に生み出す。また、企業経営陣が承認した正式なセキュリティ戦略であることも示せる。
最も重要なのは、文書化されたポリシーによって、ITセキュリティ戦略、目標、目的を正式化し、ユーザーの行動を管理し、ITセキュリティの成果を測定するという、組織に日々影響を与える重要なITセキュリティ目標を実現できることだ。
ITセキュリティ戦略・目標・目的を正式化する
文書化されたポリシーは、組織が意図する戦略を示すために利用できる文書化された指示を提供する。多くの戦略は、情報セキュリティの主要な目的に重点を置いている。
- 機密性：アクセスする必要があるユーザーだけに特定のデータへのアクセスを許可する
- 完全性：保存中または転送中のデータが誤って、あるいは不正に変更されるのを防ぐ
- 可用性：正当なユーザーがデータとシステムに継続的にアクセスできるようにする
ただし、既存の実務が常にベストプラクティスを取り入れているとは限らず、これらの主要な目的に十分対応できているとも限らない。セキュリティポリシーの策定プロセスでは、ITセキュリティチームは実務を文書化し、目標やコンプライアンス要件と照らし合わせることを求められるため、現在の実務を振り返り、改善することができる。
ポリシーの作成プロセスは、ポリシーの影響を受ける技術部門以外の経営幹部がレビューすることで、ITセキュリティの目標と目的を事業の目標・目的に合わせる助けにもなる。最終的に組織は、検証済みのITセキュリティ戦略による保護の下で事業成長を可能にする、正式な戦略、目標、目的を備えたポリシーのメリットを享受できる。
ユーザーの行動を管理する
ポリシーは、パブリックWi-Fiネットワークのゲストユーザーからデータセンターサーバーへの管理者アクセスまで、あらゆる種類のユーザーを対象に、許容される利用方法、アクセス方法、違反時の罰則に関するルールを定める。こうした文書化されたポリシーは、ID・アクセス管理（IAM）や特権アクセス管理（PAM）ツールの設定にも反映される。
もちろん、IAMやPAMのツールは文書化されたポリシーなしでも導入できる。しかし、文書化されたポリシーがあれば、組織全体に一貫したルールを適用できる。正式なポリシーは、実務が十分でコンプライアンスの範囲内にあるかを判断するため、実務と比較できる基準にもなる。
ITセキュリティの成果を測定する
有効なポリシーは、ITセキュリティチームに明確な期待値を設定する。ポリシーで義務付けられた報告書は、ポリシーへの準拠を示し、ITセキュリティチームがポリシーの目標達成に向けた成果を測定できるようにする。
従業員は常に成果を上げようと努力するが、目標未達もリソース増強の根拠として利用できる。例えば、パッチ管理ポリシーで義務付けられた報告書から、重要な更新プログラムの適用に想定以上の時間がかかっていることが分かれば、経営陣はリソースの追加や一部機能の外部委託を検討できる。
ITセキュリティポリシーの主な6つのメリット
組織の規模を問わず、文書化には手間がかかり、作業が膨大で退屈、かつ制約になると考えて避ける傾向がある。しかし、有効なセキュリティポリシーは、IT環境の強化、従業員の防御、経営幹部や取締役の安心感、訴訟対策、コンプライアンス対応の簡素化、業務効率とレジリエンスの向上という6つの主要なメリットをもたらす。
IT環境の強化
有効なセキュリティポリシーを策定すると、攻撃に対してIT環境を強化するセキュリティプロセスが自然に構築される。文書化されたポリシーの主な動機はコンプライアンスだと考える人もいるが、ポリシー作成のプロセスによってセキュリティチームはシステムをより厳密に評価し、日常業務で見落とされがちな問題に対処することを迫られる。
従業員の防御
ITチームが最大限努力しても、フィッシングリンクをクリックする人はなくならず、ゼロデイ脆弱性も発見され続ける。また、企業のリソース制約により、一部の脆弱性をさらしたままにせざるを得ない場合もある。セキュリティポリシーを遵守すればリスクは低減できるが、攻撃によって組織が被害を受ける可能性は残る。
多くの場合、経営幹部はまず、インシデントの責任を負うスケープゴートを探し、ITチームやセキュリティチームがその対象になることも少なくない。経営幹部が承認したセキュリティポリシーを遵守していたことを示せるITチームやセキュリティチームは、侵害の可能性を防ぐために最大限の努力を払ったことも証明できる。この文書は、侵害後の従業員に対する不当な扱いを防ぎ、雇用を守るのに役立つ。
経営幹部と取締役の安心感
有効なセキュリティポリシーでは、技術部門以外の経営幹部と共有できる報告書を作成し、ITチームとセキュリティチームへの信頼を高める。ポリシーは技術的な詳細を数値レポートや分かりやすい指標に置き換え、技術に詳しくない経営幹部にもセキュリティプロセスの状況を理解しやすくする。
明確な報告書によって経営幹部や取締役会との円滑なコミュニケーションが可能になり、組織のセキュリティ態勢への信頼を築ける。こうした報告書は、組織が情報セキュリティを最優先事項と考えていることを示すだけでなく、追加リソースへの支援強化につながる信頼感も生み出す。
訴訟対策
侵害やサイバー攻撃が成功した場合、政府機関や利害関係者が組織に対して法的措置を取ろうとする可能性がある。幸い、法的基準では一般に「合理的な努力」だけが求められるため、有効なセキュリティポリシーの文書や、ポリシーが実施されていることを示す報告書によって、その努力を裏付けられる。
正式な報告とプロセスを備えていない組織は、過去の取り組みを裏付けるためにどの文書が必要かを急いで確認し、その文書を作成するためのアーカイブ済みログやその他のデータがまだ残っていることを願う必要がある。正式な文書化と報告の仕組みを持つ組織なら、証拠の大部分がすでに準備されているため、最小限の労力と業務中断で提示できる。
コンプライアンス対応の簡素化
有効なセキュリティポリシーは、組織のコンプライアンス要件を反映するよう設計すべきだ。監査人は、組織の目的と、どのような証拠の提示が期待できるかを容易に理解するため、必ず文書化されたポリシーを求める。
コンプライアンスフレームワークにすでに適合している文書化されたポリシーを履行すれば、組織は規制要件を容易に満たせる。組織が定期的に作成する内部報告書によって、追加の作業や手順なしにコンプライアンスの証拠も自然に提供される。
業務効率とレジリエンスの向上
有効なセキュリティポリシーのポートフォリオは、組織が次のことを行う助けになる。
- 寿命を迎えたハードウェアやソフトウェアを認識し、交換する
- 攻撃、障害、負荷によって過負荷になったインフラを迅速に認識する
- システム間の設定と連携を検証する
- ダウンタイムを最小限に抑えるため、システムのレジリエンスを確保する
- データの完全性と可用性を確保する
- 社内および顧客とのサービスレベル合意（SLA）における稼働時間を文書化する
事業の存続は、稼働時間と保護された資産にかかっている。セキュリティプロセスを正式に文書化すれば、資産を保護し、稼働時間を維持し、ミスを最小限に抑えるための社内チェックリストになる。
文書化されたポリシーは、期待事項の記録と過去の活動報告を提供することで、IT担当者の交代にも役立つ。これらを組み合わせることで、新しいIT従業員が少ない研修で組織の状況と期待事項を把握でき、時間を節約できる。
セキュリティポリシーの3つの種類
包括的なセキュリティポリシー一式を策定する際、組織は細部に迷い込む可能性がある。SANS Instituteだけでも、60種類を超えるポリシーのテンプレートを提供している。こうした細分化されたポリシーは成熟した組織には役立つが、取り組みを始めたばかりの組織には、もう少し焦点を絞る必要がある。
米国国立標準技術研究所（NIST）が定義するポリシーの3種類には、プログラムポリシー、課題別ポリシー、システム固有ポリシーがある。Special Publication 800-12には、プログラムポリシー、課題別ポリシー、システム固有ポリシーが含まれている。
プログラムポリシーは、情報セキュリティプログラム全体に関する戦略的かつ高水準の指針を提供する。単独のプログラムである場合もあり、例えばこのプログラムポリシーはUniversity of Arizonaのセキュリティプログラムの目標と目的を概説している。これらのポリシーは恒久的に利用できるよう意図されており、頻繁な更新を必要としないことが多い。また、付録で他の種類のポリシーを参照し、それらをプログラムポリシー自体を更新せずに、より頻繁に更新できるようにすることも多い。プログラムポリシーは、測定や検証には抽象的すぎる傾向がある。セキュリティ以外のプログラムポリシーには、事業継続やリスク管理などがある。
課題別ポリシーは、情報セキュリティプログラムの特定の構成要素に関する具体的な指針を提供する。ただし、具体的なツール、手法、設定を指定するのではなく、目標、目的、報告要件を記述する抽象度にとどまる。組織、技術、コンプライアンスの変化に対応できるよう、常に最新の内容であることを定期的に確認する必要がある。課題別セキュリティポリシーの例には、ネットワークセキュリティ、パスワード、エンドポイント、暗号化の各ポリシーがある。データバックアップ（セキュリティ、事業継続）や従業員向けの許容利用ポリシー（セキュリティ、人事）のように、複数のプログラムポリシーにまたがる課題別ポリシーもある。
システム固有ポリシーは、特定のシステム上で課題別ポリシーをどのように適用・実施するかを記述する。例えば、データセンター内の特定のファイアウォールやサーバー群に対して、ネットワークセキュリティ、ユーザーアクセス、脆弱性管理、変更管理の各ポリシーをどのように適用するかを定める。こうした詳細なポリシーは、デバイスの設定や、デバイスを管理できる集中型ソフトウェアを通じて実施される。
一般的な課題別ポリシー
セキュリティポリシーの導入を始める組織は、関連性の高い課題別ポリシーから着手すべきだ。具体的に重要なポリシーは組織によって異なる。多くの組織はアクセス、ネットワーク、エンドポイント、パスワードのポリシーから始めるが、こうした優先順位は従来型のIT環境を前提としている。SECおよびFINRAの要件に準拠する、Google Workspaceを利用する5人の株式ブローカーによる小規模な仮想オフィスであれば、データセキュリティ、データバックアップ、リモートアクセスのポリシーを優先する可能性がある。
一般的な課題別ポリシーおよび関連ポリシーを10個紹介する。
- 許容利用ポリシー（AUP）
- エンドユーザーがITシステムやサービス（コンピューター、ネットワーク、データ、インターネット、メール）をどのように利用できるかを組織に指示する
- 関連ポリシー：セキュリティ意識向上トレーニングポリシー、経営幹部・管理者アクセスポリシー
- アクセス・ポリシー
- さまざまなシステムおよびデータの分類にわたり、ユーザーのアクセス、認証、アカウンティングをどのように分類、適用、管理するかを組織に指示する
- 関連ポリシー：物理アクセス・ポリシー、システムアクセス・ポリシー、特権アクセス・ポリシー、リモートアクセス・ポリシー（リモートデスクトップ［RDP］または仮想プライベートネットワーク［VPN］のポリシーを含む場合がある）、パスワード・ポリシー、ID・アクセス管理ポリシー、多要素認証（MFA）ポリシー、ベンダー管理ポリシー
- アプリケーションセキュリティポリシー
- コード開発と他の企業リソースへの接続をどのように保護するかを組織に指示する
- 関連ポリシー：アプリケーション・プログラミング・インターフェース（API）セキュリティポリシー、データベースセキュリティポリシー、アプリケーション開発ポリシー
- クラウドセキュリティポリシー
- クラウドベースのリソース上で、アクセス、データ、ネットワーク、アプリケーションをどのように保護するかを組織に指示する
- 関連ポリシー：クラウド利用ポリシー、サービスとしてのソフトウェア（SaaS）セキュリティポリシー、サービスとしてのインフラストラクチャ（IaaS）ポリシー
- データ管理ポリシー
- さまざまな分類のデータについて、保持、管理、セキュリティ確保の方法を組織に指示する
- 関連ポリシー：データ保持ポリシー、内部脅威対策ポリシー、暗号化・暗号技術ポリシー、情報セキュリティポリシー、データ・資産分類ポリシー、規制対象データポリシー
- 災害復旧計画
- さまざまな緊急事態において、事業をどのように復旧するかを組織に指示する
- 関連ポリシー：バックアップ・ポリシー、冗長化ポリシー、キャパシティプランニング・ポリシー、ストレステスト・ポリシー
- エンドポイントセキュリティポリシー
- 組織のネットワークやその他のリソースに接続する、ユーザーがアクセスするエンドポイント上のアクセス、データ、アプリケーションをどのように保護するかを組織に指示する
- 関連ポリシー：エンドポイントセキュリティポリシー、私物デバイス持ち込み（BYOD）セキュリティポリシー、モバイルデバイスポリシー、サーバーセキュリティポリシー、コンテナセキュリティポリシー
- インシデント対応・監視ポリシー
- 潜在的なセキュリティインシデントを検知、特定、検証、追跡、緩和、修復、管理する方法を組織に指示する
- 関連ポリシー：ログ追跡・監査ポリシー、攻撃別ポリシー（ランサムウェア、DDoSなど）、データ侵害対応ポリシー
- ネットワークセキュリティポリシー
- アクセスとデータフローを保護し、ユーザーとデータ間の接続を監視する方法を組織に指示する
- 関連ポリシー：ファイアウォールセキュリティポリシー、ネットワークセキュリティポリシー、メール保護・セキュリティポリシー、無線ネットワーク・ゲストアクセス・ポリシー
- 脆弱性管理ポリシー
- 脆弱性を発見、検証、優先順位付け、緩和、追跡する方法を組織に指示する
- 関連ポリシー：パッチ管理ポリシー、変更管理ポリシー、脆弱性スキャン・ポリシー、侵入テスト・ポリシー
ITセキュリティポリシーを作成する5つのベストプラクティス
組織は、5つの重要なベストプラクティスに従うことで、効果的なセキュリティポリシーを作成できる。つまり、方法ではなく実施すべきことに焦点を当てる、実用的なポリシーにする、ポリシーの長さを適正化する、ポリシーを分離しておく、ポリシーを検証可能にする、という5つだ。
方法ではなく、実施すべきことに焦点を当てる
テクノロジーの変化は非常に速いため、セキュリティツールやITアーキテクチャの詳細など、技術的な細部にポリシーが追いつけないことが多い。IT関連のポリシーを作成する際は、高レベルの目標、主要な成果物、コンプライアンス要件に焦点を当てるべきだ。
ITチームはその後、要件を予算や人員の制約と組み合わせ、適切なソリューションを開発する。詳細を盛り込みすぎると、ポリシーを常に更新しなければならなくなるか、ITチームが時代遅れのツール、慣行、見方に縛られ、セキュリティの強化ではなく、最終的に弱体化を招く可能性がある。必要に応じて、ポリシー自体より頻繁に変更される可能性のある詳細を、別紙や追加レポートで示すことができる。
システム固有ポリシーについては、ツール、設定、許可されたユーザーを詳細に記述する必要がある例外と考える組織もある。しかし、システム固有ポリシーを高レベルにとどめ、詳細を記した具体的な作業手順書を別途整備する組織もある。これは各組織の判断に委ねられる。
ポリシーを実用的なものにする
ポリシーを担当するチームにとって機能せず、理解しにくく、組織に適合しないセキュリティポリシーは成功しない。場合によっては、これらの目的が衝突するため、ポリシー作成チームは関係者と協力し、効果的なバランスを実現する必要がある。
関係者に配慮したポリシー
関係者に配慮したポリシーは、ポリシーの実施を担うIT・セキュリティチームや、ポリシーの影響を受けるユーザーに、より容易に受け入れられる。ポリシーがあまりにも多くの変更や非現実的な要件を求めたり、リソースの制約を超えたりすると、ポリシーが骨抜きにされたり、回避されたり、無視されたりする可能性がある。
関係者に配慮したポリシーにするには、慣行を大幅に変更したり、不要な詳細や指示を追加したりしないこと。コンプライアンスやベストプラクティスで求められていない限り、既存の慣行を土台にして、影響を受けるユーザーとポリシーを実施するチームの双方による迅速な導入を可能にする。
また、個人名ではなく役職名を使い、具体的なセキュリティツール名ではなくツールのカテゴリを使う。これにより、ツールの変更、人員の変更、外部委託の開始のたびにポリシーを変更する必要がなくなる。
理解しやすいポリシー
特に世界各地でポリシーの標準化を進める国際企業では、すべての読者が英語を母語としているわけではない。ポリシーを起草する際は、技術分野や法律分野の専門家でない読者にも明確に伝わる、平易な言葉を使う。
起草の過程では、文書を経営幹部、法務顧問、ポリシーの実施を担う主要なスタッフに配布する。混乱、曖昧さ、不確実性があれば、ポリシーを承認する前に解消する。
組織のニーズに適合させる
ツールやプロセスは組織の真のニーズに適合させる必要があり、盲目的に、あるいは考えずに従うべきではない。すべての組織は既存の慣行や能力を基にポリシーの起草を始めるべきだが、それによって不完全なプロセスを文書化したポリシーとして温存する落とし穴に陥る可能性がある。組織は自らの環境を慎重に検討し、ポリシーが真のニーズを反映していることを確認すべきだ。
例えば、病院のITチームがIT環境の脆弱性スキャンを実施するために市販ツールを使っているとする。しかし、そのツールがPC、ネットワークデバイス、サーバーしかスキャンできない場合、膨大な数の医療技術デバイスが脆弱性スキャンの対象外になる。ポリシー要件は現在スキャンしているデバイスの範囲ではなく、脆弱性管理プロセスに含める必要があるすべてのデバイスを反映すべきだ。
ポリシーの例外も最小限にとどめ、例外は文書化すべきだ。C-suiteの経営幹部がパスワードポリシーの適用除外を要求するなら、会社が情報漏えいに見舞われた際に、その適用除外を法廷で正当化する準備もしておくべきだ。従業員と同様に、上級管理職もセキュリティポリシーを理解し、同意し、遵守しなければならない。
ポリシーの長さを適正化する
ポリシーは必要以上に長くも短くもすべきではない。IT・セキュリティチームは、要件が明確に定義されていないことで実行時の柔軟性が最大になるため、短いポリシーを好むことが多い。しかし、要件が明確に定義されていないと、要件に抜け漏れが生じたり、経営陣やコンプライアンス担当者がポリシーを検証しにくくなったりする。
一方、弁護士は、検証を容易にし、できるだけ多くの点を明確にするため、可能な限り多くの詳細を規定しようとすることが多い。残念ながら、これは過度に細かい要件につながり、ITチームをその時点の要件に縛り付け、動的に変化するIT環境への対応余地をほとんど残さない傾向がある。
これら相反する力のバランスを取らなければならない。ITチーム、経営幹部、弁護士は協力し、ITチームがポリシーへの準拠を明確に示せるだけの十分な詳細を盛り込みつつ、ポリシーが脆弱性管理プロセスの足かせになるほど詳細にはしない文書を作成する必要がある。
ポリシーを分離しておく
セキュリティ・コンプライアンスチームは、想定されるポリシーから情報を探す。例えば、エンドポイント保護に関するポリシーを調べる場合、まず全体的なセキュリティポリシーや、エンドポイント保護に特化したポリシーを探す人が多い。脆弱性管理ポリシーに情報を埋め込むのは直感に反し、混乱を招く可能性がある。
セキュリティポリシーの作成チームは、完全性を高めるために、パスワードポリシーなど既存の他のポリシーの要素を、リモートアクセスやエンドポイント保護などの半関連的なポリシーにコピー＆ペーストする誘惑も避けるべきだ。文書が自動更新できるようリンクされていない限り、コピーした情報はすぐに古くなる。他の既存ポリシーのセクションを挿入するのではなく、必要に応じて参照する。
ポリシーは個別に包括的な内容とし、重複は最小限にすべきだ。他のポリシーとの重複は、文言の衝突、不確実性、コンプライアンスやセキュリティ上の抜け漏れにつながる可能性がある。組織がポリシーを統合することを決めた場合は、チームメンバーがポリシー情報を迅速に見つけられるよう、索引やガイドを作成すべきだ。
ポリシーを検証可能にする
成果物が曖昧で定義されていない曖昧なポリシーは、ポリシーを保有するという要件を満たすだけで、役に立つポリシーを保有するという要件は満たさない。効果的なポリシーでは成果物を明確に定義するため、IT・セキュリティチームはポリシー要件を容易に満たせる。
セキュリティプロセスは、ポリシーおよび関連するコンプライアンスフレームワークへの準拠を証明できるよう、測定可能かつテスト可能であるべきだ。報告要件では、測定指標、必要な証拠（ログファイル、脆弱性スキャンなど）、報告頻度、報告の受け手を定めるべきだ。
4ステップでセキュリティポリシーを作成する方法
組織の規模を問わず、4つの重要なステップに従うことで、実用的なセキュリティポリシーを作成できる。つまり、セキュリティポリシーの原則を決定する、脆弱性管理ポリシーを検証する、脆弱性管理ポリシーを承認する、脆弱性管理ポリシーを見直して修正する、というステップだ。
セキュリティポリシーの原則を決定する
ポリシーを起草する担当者またはチームは、まず脆弱性管理ポリシーに含める重要なルールと手順を決定する必要がある。例えば、以下のような基本的な問いに答える。
- セキュリティプロセスまたは標準の責任者は誰か。
- セキュリティプロセスまたは標準の対象となる人、資産、システムは何か。
- それぞれのセキュリティプロセス、標準、構成要素、優先順位は何か。
- セキュリティプロセスまたは標準をどのように検証・確認できるか。
- セキュリティプロセスまたは標準の成功とコンプライアンスを確立・測定するために必要なレポートは何か。
どこから始めればよいかわからない場合は、現在の慣行を書き出す。ほとんどのITチームには、文書化や監視が行われていない場合でも、ほぼすべてのセキュリティ慣行について、少なくとも非公式のプロセスがある。この最初の草案は、単なるメモで構わない。基本原則をまとめた後で、正式な段落や文言を整えればよい。
セキュリティポリシーを検証する
基本的なルールや原則を定めたら、ポリシー開発チームは外部要件や実務上の制約に照らして検証する。
外部のセキュリティポリシー要件
すべての組織は、国際、連邦、州、地方の各政府による一般的または固有の規制に直面する。また、コンプライアンスフレームワーク（NIST、PCI DSSなど）や業界標準への準拠を義務付けられたり、自ら選択したりする場合もある。
コンプライアンス基準には、広範で曖昧なものもあれば、詳細なものや具体的な要件を持つものもある。ポリシー開発チームはこうした外部規制を確認し、コンプライアンス要件を満たさないルールを修正する必要がある。
実務上のセキュリティポリシーの制約
ほとんどの組織にはリソースの制約があり、理想化されたポリシーではこうした制約が考慮されていないことが多い。セキュリティポリシー開発チームは、提案するルールをIT・セキュリティチームとともにテストすべきだ。現在のリソースでは基準や要件に準拠できない場合、組織は必要に応じてルールまたはリソースを調整する必要がある。
例えば、パッチ管理ポリシーを策定する際、ITチームは現在のツールや人員ではパッチ管理スケジュールの要件を満たせない可能性がある。その場合、組織はスケジュールの調整（コンプライアンス要件で認められる場合）や、追加のリソース（ツールのアップグレード、人員の増強、外部委託など）の投入を検討する必要がある。
セキュリティポリシーを承認する
提案したセキュリティポリシーのルールを検証したら、ルールを正式化し、組織の経営陣が承認する必要がある。ここで、走り書きのメモを正式な段落、表、付録に仕上げる。
起草後は、ポリシーを経営陣と法務顧問に回してレビューと承認を受ける。必要に応じてポリシーを修正し、最終草案には組織の経営幹部が署名して、要件を正式に承認・確認すべきだ。
セキュリティポリシーを見直して修正する
セキュリティポリシーはステップ3で承認されるが、組織、ITリソース、規制は時間とともに変化する。すべてのポリシーは、組織の変化に応じて進化する生きた文書であり、定期的に見直して更新すべきだ。一般に、ポリシーは一定のスケジュール（四半期ごと、年次、半年ごとなど）で見直される。ただし、ITアーキテクチャの大幅な変更、大きく異なるセキュリティツールの導入、セキュリティ侵害などの注目すべき事象があれば、予定外の見直しが必要になる場合がある。
結論：集中力を高めるためにポリシーを作成する
組織は正式な書類作成を負担と捉えがちだが、効果的なITセキュリティポリシーによって、セキュリティ態勢を改善し、コンプライアンスに費やす時間を減らし、多くの懸念を解消できる。最新かつ効果的なポリシーがあれば、大企業から中小企業、非営利組織、さらには政府機関まで、想定していたセキュリティ態勢を検証し、本来の使命にとってより重要な課題に集中する自信を得られる。
関連トピックの詳細については、以下を参照されたい。