コントロールを管理

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

コントロールを合理化

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

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

注:

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

コントロールを統合

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

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

事前に定義したビジネスルールは、後で GRC 構成設定を確立します。次の準備をしてください。

• コントロールとコントロールオーナーを識別する
• コントロールテストと予期される結果の定義
• テストおよびコントロール頻度を確立
• リスクを識別：影響度と可能性
• 証明書、アセスメント、アンケート、および必要な証拠を準備する
• 想定されるユースケースを作成する (GRC システムのコンテンツを操作または表示する必要があるユーザーおよび目的)
• 信頼できるソースをポリシー、手順、コントロール、リスクにマップする

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

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

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

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

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

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

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