# Reference Policy Best Practices
## Baseline your applications using the reference policy that comes with Lifecycle
- Around 90-95% of our customers use the default reference policies out-of-box as they are a solid indicator of open source risk.
- The reference policies are organized into 4 main categories listed below.
| Policy category | Details |
|-----------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------|
| Security Risk | - security policies aligned with the NIST [National Vulnerability Database](https://nvd.nist.gov/).
- including Sonatype's exclusive identification of release integrity and namespace conflicting components |
| License Obligations | - Sonatype's legal team has reviewed each license for business-critical obligations
- they are organized licenses into threat groups by legal obligations |
| Architectural Rules | - components flagged for cleanup or poor quality
- including Sonatype exclusive hygiene rating |
| Other | - details around component identity or matching
- proprietary or unknown components |
## Customize policies to match your existing open-source governance practices
- Around 90-95% of our customers use the default reference policies out-of-box.
- Most variations are to better align with pre-establish governance policies or to prioritize specific architectural risks.
- Rather than deleting the default policies, we recommend scoping them to an unused application category to make them easier to restore later.
## Use application categories to create specific policies for a subset of your applications
- Your applications may have different levels of risk aversion due to regulatory requirements or exposure.
- Create and manage policies at the root organization while using application categories to scope them to these applications.
## Turn on enforcement to block security-malicious components at every lifecycle stage
- Malicious components should never be allowed in your applications.
- Set your policy action to FAIL at all stages of development.
- Do not waive these violations nor allow the components to remain in your application.
## Sign up for Sonatype's policy workshop
- Partner with a Sonatype Customer Success Engineer to design your open-source governance policies.
- Our Customer Success Engineers will get your team up to speed with open-source governance best practices.
- During the workshop, you will amend the reference policy based on your organization's needs and goals.
## Modifying Policies in Production
### Importing policies to a production instance is very destructive
- All policy elements use internal IDs for violations, waivers, license threat groups, and component labels.
- Importing policies will break any references to these IDs and destroy your governance data.
- Only import policies into new instances.
### Avoid deleting the reference policies
- Replacing the reference policies later can be time-consuming and difficult.
- Change the policy scope to an unused Application Category instead.
- You can just change the scope again when you need it back.
### Avoid creating multiple policies for the same risk
- Multiple policies for the same threat result in wasted effort for your developers.
- Reduce the noise by first testing complementing or competing policies in a test environment.
### Frequent changes to policies will result in noisy violations and poor metrics
- Adding and removing policies will pollute the metrics used to measure your efforts.
- Appearing and disappearing violations will frustrate your developers; leading them to ignore future results.
- Avoid making multiple changes to the policy in production environments.
- When you must make a change, temporarily suspend notifications and socialize the expectations beforehand.
- Document policy changes to production to later explain strange peaks and dips in metrics.
### Making changes to a policy may reset the waivers associated with the violation
- Waivers are scoped to the policy constraints at the time the waiver was created.
- Changing enough of the policy's constraints may trigger a new violation not covered by the waiver.
- Where possible, review changes to the policy in a test environment before enabling them in production.