コントロールを管理

コントロールは、コントロール目標の特定の実装です。廃止されたコントロールはリストに表示されません。コントロールを定義する前に、時間をかけて組織内の重要なコントロールを合理化し、統合し、定義します。

コントロールを合理化

すべてのコントロールを一括でアップロードすると、コントロールセットを改善して合理化する機会が失われます。ビジネスが変化し IT データ、プロセス、およびテクノロジーが改善されると、 GRC アプリケーションを実装するときに古いコントロールと手順が置き換えられます。次の点を考慮してください。

• このコントロールは事業達成目標にどのように影響するか。
• このコントロールは実際にリスクを防止または検出しているか。
• ビジネスをより適切に保護するために配置できる別のコントロールはありますか?
• リスクを軽減しながら、プロセスのオーバーヘッドを削減し、IT パフォーマンスを向上させるコントロールはあるか。
• 複雑なコントロールをよりシンプルで効果的なコントロールに置き換えることはできるか。

注:

コントロールを手動で定義するか、Unified Compliance Framework (UCF) からインポートすると、エンティティがコントロールに関連付けられます。これはコントロールフォームの必須フィールドです。ただし、UCF 以外のソースからコントロールをインポートする場合は、エンティティが関連付けられていない可能性があります。コントロールフォームに戻り、コントロールにエンティティを追加することが重要です。エンティティが欠落していると、信頼性の低い結果が生じる可能性があります。また、無効になっているエンティティを含むコントロールを検出した場合は、そのコントロールを廃止する必要があります。

コントロールを統合

コントロールを統合する機会を探します。たとえば、フレームワークの複数の規制当局間で繰り返される共通のコントロール (SOX、GLBA、、AML など) に対してook できます。コントロールを相互にマッピングし 冗長なコントロールを排除することで規制ごとに 1 つのコントロールを複数回操作することを避けます。このプロセスにより、単一の統合されたコントロール = コントロールフレームワークが確立されます。コントロールのクロスマッピング形成と保存は、監査にとって重要です。

図 : 1. 業界の規制と要件の重複

コントロールとビジネスルールの定義

ビジネスルール 事前定義により、後でGRC構成設定が確立されます。次のタスクを実行する準備をしてください

• コントロールとコントロールオーナーを特定する
• コントロールテストと期待される結果定義します
• テストと制御の頻度確立
• リスク:Iimpactと可能性を特定する
• 証明書、アセスメント、アンケート、および必要な証拠を準備します
• 作成 使用 可能性がある ケース (誰がどのような目的で GRC システムのコンテンツを操作または表示する必要があるか)
• 信頼できるソースをポリシー、手順、コントロール、またはリスク にマッピングします

エンティティベースのアクセス (EBA)

EBA は、エンティティに関連付けられている) オブジェクトへのデータアクセスを管理するためのより詳細なアプローチ のフレームワークを提供します。アドミニストレーターは、ユーザーまたはユーザーグループを追加するか エンティティベースのアクセス構成にエンティティユーザーフィールドを使用して、エンティティの関連レコードへのアクセスを許可できます。詳細については、「エンティティベースのアクセス」を参照してください。

ユーザーがこれらの構成に基づいて認定され、最低限必要なロールを持っている場合、次のテーブルにアクセスできます。

• コントロール
• 証明書
• コントロールに対するポリシー例外

EBA ルール

[エンティティベースのアクセス構成プロパティ] ページでエンティティベースのレコードアクセスルールが有効になっている場合、構成されたエンティティに関連付けられた新しい コントロール、コントロール証明書、インジケーター、およびインジケータータスク そのエンティティからエンティティベースのアクセス (EBA) 値を自動的に継承します。以前は、新しいオブジェクトが作成されるたびに、ユーザーは一括アクセス更新を実行して EBA 制限を適用する必要がありました。

詳細については、「 新しいレコードを保護するためのエンティティベースのレコードアクセスルール」を参照してください。