Best Practices for Policies

A single policy can contain multiple policy rules. As you develop your policies, think about what belongs under one policy umbrella, versus what should be distinct. For example, you might create one policy for Finance Department Role Conflicts that could include many individual rules defining which roles cannot be shared within the Finance department. If your policies do not fit logically into categories, individual policies for each unique use case might be the right approach.

Always provide user-friendly and intuitive names and descriptions for each policy and policy rule. The description of the policy (though not of the policy rules) can also be localized if you need multilingual translations. A good rule of thumb is that the policy name should indicate the purpose of the policy, and the policy rule name should indicate what the rule actually does.

Whether or not to alert requestors or approvers that granting certain access will result in a policy violation is something you can configure in the Lifecycle Management business process for provisioning. There may be some cases when you do not want to let users know which access combinations can provide an opportunity for fraud or for circumvention of security controls.

Fully testing policies before making them live is an essential step. See Testing Policies

Every policy should include clear language about the policy's purpose, and how to manage violations. Policy rules include fields for giving important information and guidance to users. Be sure to provide meaningful and complete information with each rule, so that users have a clear understanding of the purpose of the rule and how to manage violations. See Compensating Controls and Correction Advice.