The scoping rules tab can be found in the "Frameworks" section of your Secureframe instance. Scoping rules allow you to filter your integrations that populate your asset inventory to only the assets that are relevant to your current audits. These rules can be run point in time but also will automatically detect and scope any new resources that you pull into your system. 

Default Scoping Rules

When you first enter the page, you will note a set of default rules created for you by the Secureframe system. Historically, assets that were pulled in to the system through your intergrations would be automatically marked as in scope for your various audits until you manually marked them as out of scope. The default rules exist as a transition mechanism between the former system where assets are automatically marked as in scope and the new system where you have full control over what assets are considered in your audits. 

Scoping Rule Structure

When you click on "edit rule" you will be taken to a page that can be broken up into 3 sections: rule attributes, conditions, and results table. 

The rule attributes are the metadata for the rule and dictate what impact the scoping rule will have on your different audits. The "applicable frameworks" selector will determine what frameworks your current rule will be scoping assets to.

Conditions

The conditions are the where you can apply the logic for the rule to set what assets are "in scope" for the applicable frameworks you selected in the attributes section. In this section you want to create conditions that will find the assets relevant to these frameworks which will populate in the table below as you build your conditions.

Results table

The results table will give you live feedback on the conditions that are being updated. Anything that "hits" the condition will be shown in the table and upon saving will be pulled into the tests relevant for the frameworks selected in the applicable frameworks field above.

**reminder** these rules dictate what is IN SCOPE not what is OUT OF SCOPE or Excluded

Applying Rule Logic 

Here are some real life examples to help you understand how rule logic can be structured to set your system up for success.

Example 1 - I have all my cloud resources that process credit card data relevant for my pci audit in a specific AWS account 756181438366. 

1. Ensure that PCI ROC 4.0 is selected in the applicable frameworks selector
2. Add Vendor = AWS and Account = 756181438366
3. Check that the resource you are trying to add to your PCI audit is in the results table
4. Click "Save"
   (see below for screenshot showing this logic)
   

Example 2 - I only want to pull in production assets from my single AWS account because those are the only assets that process real data.  I have tagged these resources with "tag1" and they are exist in "us-west-2" region.

Organizing your resources using tags and accounts are often the easiest way to scope them into the right report. Secureframe recommends that you build a business process using one of these methods and write your rules accordingly. 

Rule Latency

Rules change how assets get pulled into your different tests and frameworks. Scoping rules will process all new assets that get pulled into the system as well so that you can truly set and forget your framework scoping logic.  Given a rule change COULD greatly alter the scope of your tests, upon "save" the relevant tests will be refreshed automatically to reflect the changes in your asset scope. These test refreshes may take up to a couple of minutes to complete depending on the number of assets tested.

Manual Scoping vs Rule-based Scoping

Scoping rules were designed to work well with any sort of manual scoping that you have done on the asset pages. If you have manually removed assets from certain framework scopes, you can avoid "undoing" the manual scopes by selecting "No, do not apply" in the save rule flow. This will ensure that the rule will only impact assets that have not been manually scoped previously in the system. The default rules did not change any scope for the current customers - anything that was manually scoped before was left untouched by the default rules.  If you want to transition from manually tagging to a rule-based approach, you can select "Yes, apply and override manually scoped resources" and this will permanently removed the manual framework scope from the assets and allow the rules to hit all assets.