--- title: "Policy Center: Adding Scope and Rules" url: "https://atlan.com/demos/adding-scope-and-rules/" description: "Define Atlan policies with precision, setting asset scope and compliance rules based on metadata attributes for robust data governance and incident prevention." format: "Video" video: "https://videos.ctfassets.net/nwa1c00rtgxb/2ommfXmLBDSVGWkrzKeuW9/d2db15daac14e9bd56a1f0d0c3a62de8/Adding_Scope_and_Rules.mp4" content_purpose: ["Product Overview"] target_persona: ["Data Steward"] journey_stage: ["S2 - Discovery", "C1 - Onboarding", "C3 - Adoption"] use_case_context: ["Training"] product: ["Data Marketplace - Data Governance"] content_type: "video transcript" transcript_source: "contentful" --- # Policy Center: Adding Scope and Rules Transcript of the video at https://atlan.com/demos/adding-scope-and-rules/ Adding Scope and Rules [00:00] Clicking on the scope and rules tab brings the input for setting the scope and rules for the policy. The first step is to set the asset scope. The asset scope defines the population of assets for which this policy applies. The scope is created by using different attribute filters, creating and statements. When multiple are applied. There are many different options for attribute selection similar to playbooks. These allow for filtering based on larger scope attributes like connector or asset types, down to the granular level of owners or custom end data, allowing for immense flexibility in targeting the exact scope that you want the policy to apply to. Once the attribute is selected, you then choose the operator allowing for selections like is one of or is empty. Finally you enter in the value or values to filter on based on the operator. In our case, we want to ensure that data retention policies are in place on our critical assets. So we first [01:00] select the connector attribute, selecting Snowflake as our value. Then as our data retention policy is custom metadata on tables and view assets, we select asset type and table and view. Finally, we already linked a glossary term of customer data to our views and tables, along with some columns designating customer data, which is the data our policy applies to. This can be accomplished through other means, such as tags, custom ended data, or even if there's a specific naming convention or warehouse that identifies this, all of which could also be used as a filter. Since we used a term, we add the attribute of linked terms and select customer data. Since the data retention rules are set at the table and view level only our asset type filter ensures that columns without this metadata won't be flagged as incidents. Our scope is now properly defined throughout the process of adding and adjusting filters. The assets match value updates dynamically, allowing [02:00] us to not only see the total number of assets within the scope. But also allowing us to click the view all hyperlink, bringing up the asset sidebar. With a listing of each and every asset included in the scope, We can quickly do a validation check that the filters we applied are producing the scope that we want. Now that we have validated clicking save applies the scope in the compliance rules tab updates a single rule automatically applies once the scope is saved, wherein if any of the assets defined the scope fall out of it in the future. They are no longer seen as complying and create an incident, but adding additional rules is the key to the power of the policy as we are able to define the exact rules that the assets within the scope must follow without adding additional rules, it lacks in the ability to create a baseline scope that the policy will apply to, and then check for specific metadata attributes on those assets. So we will create our rules to ensure that [03:00] our assets comply to the policy. The compliance rules work in a similar fashion to the scope, but are centered around the metadata of the assets. Here you can define your rules based on certification status, ownership tags, linked terms, and custom metadata values. In our case, we have a custom metadata field called data retention that has a property for retention time period. We select this as our attribute. And since our data retention must be filled out, we go ahead and select is not null. In this case, if we wanted to get more specific on the value, such as certain assets must have a six month retention, while others are a year, we would actually need to do these as two separate policies with the scope for each of the policies limiting to only the assets for which the specific period of data retention applied. Additionally, if there were additional metadata properties required on our assets or values, we can add an additional [04:00] rule to the policy specifying that metadata. This allows you to create multiple requirements on a single scope of assets. I. An aspect to note here is that both rules and scope filters are combined together with and statements, meaning that if there are three rules, then all three rules must be adhered for assets in the scope to comply to the policy. I. Once you have defined your rules, if no assets in scope actually match the rules condition, a warning will show alerting you to the fact that none of the assets in scope comply to these rules. Meaning that all those assets will be included in an incident. It's a great check to ensure that you have the right rules and the right scope. If this occurs, now that we have our rule defined, clicking Save confirms our rules. We now have both our policy scope and rules, and the last thing we have to do before we can submit it for approval is associate the approval workflow that should apply to this policy.