ポリシーとコンプライアンス管理 の構造の概要により、ServiceNow の ポリシーとコンプライアンス管理 アプリケーションを構成するさまざまなモジュールがどのように統合および相互にやり取りするかを理解できます。

各種法令・基準等

ポリシーとコンプライアンス管理 アプリケーションは、各種法令・基準等を特定することから始めます。これらの文書は、組織が準拠する必要がある法律、規制、および標準を含む外部規制であり、組織が行うビジネスのタイプとその場所によって異なります。規制要件は通常、法律または特定の業界によって概説された要件を提供する規制機関によって公開されます。これらの要件は、医療保険の相互運用性と説明責任に関する法律 (HIPAA) などの連邦または州の規制、一般データ保護規則 (GDPR) などの国際規制、ペイメントカード業界 (PCI) などの業界規制から取得される場合があります。HIPAA、GDPR、PCI などの各ドキュメントは、各種法令・基準等です。

たとえば、ペイメントカード業界データセキュリティスタンダード (PCI DSS) は、情報セキュリティ標準であり、ペイメントカード詐欺を減らすことを目的とした各種法令・基準等です。クレジットカード支払いを受け入れるすべての組織に一連のセキュリティ標準を提供します。フィナンシャルサービスプロバイダーは、不正行為を防止し、カード所有者データを保護し、ビジネスサービスの安全性と合法性を確保するために、PCI 標準に準拠する必要があります。

引用

引用は、ビジネスが明確に準拠する必要がある各種法令・基準等 (Unified Compliance Framework (UCF) など) からの一節または文言です。これは、各種法令・基準等内の個別の要件です。たとえば、パブリックネットワーク全体でのカード所有者データの送信の暗号化は、ペイメントカードトランザクションによる消費者の個人財務情報の盗難を防ぐための PCI DSS の要件の 1 つです。

引用は、手動で作成することも、UCF を介してインポートすることもできます。

エンティティタイプ

エンティティタイプは、一連のフィルター条件に一致するエンティティをグループ化します。インスタンス内の任意のテーブルに対する条件付きクエリに基づいて、エンティティを自動的に生成できます。たとえば、銀行に口座を持っている顧客をエンティティタイプとして考えてみましょう。顧客には、名前、顧客 ID、口座のタイプ、収入ソースなどの属性があり、顧客情報テーブルに格納され、任意の属性に基づいてクエリできます。

エンティティ

エンティティは、人、部門、アプリケーション、オブジェクト、サーバー、外部ネットワーク機器、さまざまな場所、データサーバー、データウェアハウスなど、基本的にコントロールテストを実行する対象となるすべてのものであり、本質的にポリシーとコンプライアンスです。たとえば、名前と関連する財務情報を持つ銀行の口座を持っている人などです。

エンティティは、エンティティタイプが作成されると自動的に生成されます。

ポリシー

各種法令・基準等が特定された後、企業は、事業部門が各種法令・基準等に準拠する方法を指定するポリシーを作成します。ポリシーステートメントは、ビジネスで何をすべきか、また何をすべきでないかを高レベルで定義します。たとえば、組織は、顧客の機密情報を保護するための要件を定義するデータ保護ポリシーを設定できます。ポリシーは組織の内部ドキュメントであり、ファイアウォールポリシー、ネットワークポリシー、受け入れ可能な使用ポリシー、情報セキュリティ、ネットワークセキュリティ、環境保護などがあります。これらは、ビジネスの特定の側面を扱うさまざまなコントロールとコントロール目標の集計です。

ポリシーの確認応答

ポリシー確認応答モジュールを使用すると、ポリシー所有者またはコンプライアンスチームは、コンプライアンス要件を満たすために、従業員によるレビューと確認のためにポリシーを送信できます。

ポリシー例外

これにより、ポリシーに例外を設定できます。何らかの理由でポリシーまたはコントロールに準拠できない場合は、例外をログに記録できます。

ポリシー例外モジュールは、組織が文書化されたコントロールに従うことができない状況を文書化します。ポリシー例外には独自のライフサイクルと承認があります。

コントロール目標

コントロール目標は、コントロールが達成することを意図した特定の目標です。たとえば、データ保護ポリシーを確保するために、会社は安全なネットワークをビルドして維持できます。受け入れ可能な使用ポリシーの場合、ユーザーがアクセスしている Web サイトを常に制御するプロキシを設定するというコントロール目標があります。ネットワークポリシーには、強力なパスワードを設定するというコントロール目標がある可能性があります。

コントロール目標を通じて、各種法令・基準等とポリシーを結び付けてコンプライアンスの負担を軽減できます。1 つのコントロール目標で、複数の内部要件と外部要件を強制できます。引用は、1 つ以上のコントロール目標に関連付けることもできます。また、コントロールとポリシーはコントロール目標レベルで互いに関連付けられています。あるいは、コントロール目標を参照し、目標で示されているアクションを行う理由を示す権限ドキュメントとポリシーへのマッピングを確認することもできます。

コントロール目標モジュールは、ポリシーとコンプライアンス管理 アプリケーションのメインハブです。各種法令・基準等は規制目標を記載し、ポリシーは組織がすべきこと、すべきでないことを文書化しますが、コントロール目標は、これらのポリシーや各種法令・基準等に準拠する方法を正確に定義します。

コントロール

コントロールは、コントロール目標の特定の実装です。たとえば、データ保護ポリシーの場合、会社はデータが確実に定期的にバックアップされるようにしたり、自動バックアップシステムを設定したりすることができます。

ポリシーをエンティティタイプに関連付けるか、エンティティタイプをコントロール目標に関連付けると、コントロールが自動的に生成され、コントロールはコントロール目標のエンティティタイプにリストされている各エンティティに対して作成されます。ただし、コントロールは手動で作成することもできます。コントロールをテストして、意図したコントロール目標を達成できるかどうかを確認します。

コントロールテスト

コントロールは、コントロール目標の達成に有効であることを確認するためにテストされます。たとえば、ペネトレーションテストにより、データ暗号化が適切に実装されていることを確認します。

インジケーター

インジケーターを使用すると、コントロールに対してテストを実行でき、テストは、日次、週次、月次、または四半期ごとにスケジュールできます。インジケータータスクが作成され、コントロールが準拠しているかどうかを確認するためにユーザーに送信され、インジケーターを合格または不合格としてマークできます。タスクが失敗した場合、コントロールは準拠しておらず、問題が作成されます。インジケーターがテストに合格した場合、コントロールは次にスケジュールされているテストまで準拠しています。

インジケーターテンプレートを使用すると、類似するコントロールに複数のインジケーターを作成できます。インジケーターテンプレートはインジケーターのパラメーターを定義し、監視するインジケーターのタイプに応じてリスクステートメントまたはコントロール目標にマッピングされます。

インジケーターが実行されるたびにタスクが作成され、インジケーターの結果が収集されます。スケジュールに従ってインジケータータスクが作成され、インジケーターフォームで事前設定された頻度に従って確実に監視されます。

証明書

証明書は、コントロールを評価してコンプライアンスを継続的に監視します。インジケーターとは異なり、証明書はほとんどがアドホックであり、スケジュールされない場合があります。

問題

コントロールのテスト中にギャップが特定された場合、そのギャップは問題と呼ばれます。問題には、監査からの運用上の観察事項、規制コンプライアンス違反、セキュリティ違反、またはその他の否定的な結果が含まれます。または、コントロールテストが失敗し、非準拠である場合、問題が作成されます。問題は、ポリシーとコンプライアンス管理、リスク管理、監査管理 GRC アプリケーション間で共有できます。会社のリスク管理プログラムの有効性は、リスクとコンプライアンスの問題をどのぐらい迅速かつ完全に特定して対処するかによって測定できます。

修復タスク

問題が確認された後、組織は問題を修正するために必要な手順を特定します。リスクを軽減するために、修復タスクを作成して修正作業を追跡できます。トリアージが実行された場合、トリアージ問題は実際の問題またはリスクイベントに変換されます。問題を推奨事項として追跡するか、問題ではないとしてクローズすることもできます。