Best Practices for Policy Creation

Using the policy wizard is straightforward, but there are some best practices to consider when defining policies for your organization:

• Build your policies from the bottom-up
  Your default policy (at the bottom of your list of policies) is the catch-all for identities you haven't defined a specific policy for. Try to make your default policy the one you want to be enforced if an unknown or unexpected device or user attempts to access the internet. As such, we recommend that you always either make your default policy the most restrictive or make your default policy the one that you would want the majority of your users and devices to be governed by.
• Build your additional policies as exceptions, from least specific to most specific
  From there, you want to layer on policies from least to most specific. An example of this might be to make your first additional policy be for "All Roaming Computers," then layer another policy on top of that for a small number of roaming computers that have slightly different needs than the general population of roaming computers. By taking this "exceptions-based" approach you are less likely to encounter any unintended results.
• Utilize the top-level groups of identities when possible
  Top-level groups like "All networks" and "All Roaming Computers" are special because they dynamically inherit new identities. This means that if you create a policy for "All Roaming Computers," and then provision a number of new mobile devices after the fact, they automatically have that policy applied without you doing anything. As a best practice, these policies should be lower in priority than more specific policies. Otherwise, they will take precedence over any policies which include those types of identities that they are above, and render those policies useless.
• Use tags for groups of roaming computers
  A tag is a way to group roaming computer identities together to create policies for a group of roaming computers. If you expect to have hundreds or thousands of roaming computers in your deployment, using a tag when creating a policy is a good way to go. For more information, see Group Roaming Computers with Tags.
  Note: Tags are only available for roaming computer identity types. We are planning to expand this to cover additional identities in future Umbrella releases.
• Organize policy settings for re-use
  Policy settings can be re-used in multiple policies, so keep that in mind when you create, name, and update these settings. A good example of this is destination lists. It is best to organize them so that multiple policies might use a general-use destination list (for example, "Block social networks") and create exception lists for one-off situations where the destination list is unlikely to be used elsewhere.
• Layer your policies according to location
  If you are using Cisco Umbrella with roaming or mobile features, you have the ability to create location-based policies. The most common example of this would be to first create a security-only (for example, no content filtering) policy for all of your roaming laptops, then create a more restrictive policy for your corporate network (which would be placed above the roaming laptop policy). This is counter-intuitive due to above statements regarding organizing your policies from least to most specific. However, in this case, what it means is that when your roaming laptops enter your corporate network, they must adhere to the more stringent policies of the workplace. While they are outside of the network, however, as many users often use work laptops for some amount of personal browsing, they will have a layer of security wherever they go but are free to visit whatever websites they choose.

---

Policy Settings < Best Practices for Policy Creation > Policy Precedence