Configuring Policies
Policies can be created at multiple levels in the hierarchy.
Root Organization - Policies at this level are inherited by all repositories, organizations, and applications. Use this level when you want to apply policies to every repository, application, and organization.
Organization - Policies at this level are inherited by all applications attached to the organization. Use this level when you want to narrow the implementation of policies to a particular set of applications.
Application - Policies at this level apply to an individual application only. Use this level when you want to apply policies to a single, unique application.
Repository Managers - Policies applied to all repository managers. Use this level to scope policies for all your repository managers.
Repository Manager - Policies applied to a specific repository manager. Use this level to apply policies to a specific repository manager.
Proxy Repository - Policies applied to a specific proxy repository.
Tip
As a best practice, policies should be created as high up in the hierarchy as possible.
We recommend keeping your policies at the Root Organization and using application categories to create policy for specific use cases. Application categories provide a way to apply policies to a subset of select applications in an organization that require more stringent risk management.
Overrides may be used to add and remove enforcement and notifications at any level of the hierarchy.
Policy Permissions
Viewing policies require the View IQ Elements
permissions. The user may only view policies at the highest level they are granted permission in read only mode. Inherited policies are displayed in read only mode.
Adding, changing or deleting policies require Edit IQ Elements
permissions at the level the policy has been created on. When enabled, you may be able to override actions and set notifications depending on if overrides are enabled on the parent policy.
Override Policy Actions
It is possible to override policy actions for inherited policies without changing the reference policy set at the parent level.
Learn more about Policy Overrides
Creating Policies
Once you decide at which level to apply policies, you can proceed with creating custom policies. The overall process is only a few steps. However, the extent of customizable settings available to you can complicate the process.
Select
Add a Policy
from thePolicies
section at the hierarchy level to add the policyName the policy and provide a threat level
Select the inheritance scope and override options
Add the desired constraint with conditions. All included fields are required when adding conditions
Update actions and/or notifications at a desired stage in the application lifecycle
Select Create
Editing Policies
Keep in mind that making changes to a policy's constraints may invalidate any waivers that had been previously applied. When testing policy changes, start with a new policy with a limited scope using application categories until you are ready to make any changes.
Navigate to the hierarchy level the policy was created
Select the policy you want to edit from the
Policies
section underLocal
Make the desired changes to the policy
Select
Update
Deleting Policies
Deleting a policy cannot be undone.
Navigate to the hierarchy level the policy was created
Select the policy you want to delete from the
Policies
section underLocal
Select
Delete Policy
from theEdit Policy
viewSelect
Continue
to permanently delete the policy