🚧 Scoping rules are currently in beta. Functionality and behavior may change as we continue to refine the experience based on customer feedback. If you run into issues or have suggestions, please reach out to your Customer Success Manager.
Scoping Rules
Scoping rules let you filter the assets pulled in by your integrations so that only the resources relevant to a given framework are evaluated by that framework's tests. Rules are set-and-forget: once you save one, it automatically evaluates any new assets the system ingests going forward, so your scoping stays accurate without manual upkeep.
You'll find scoping rules under the Frameworks module of your Secureframe instance, in the Scoping Rules tab.
Default rules
When you first open the Scoping Rules tab, you'll see a set of default rules that Secureframe created for you. These rules mark every asset as in scope for all of your frameworks, giving you a starting point you can refine over time.
How a scoping rule is structured
Click Edit rule on any rule to open the editor. Every rule has three parts:
Rule attributes: Basic settings for the rule, including its name and the Applicable frameworks field. The frameworks you select here are the ones the rule will scope assets into.
Conditions: The logic that decides which assets are in scope. Build conditions (vendor, account, region, tag, etc.) that match the assets relevant to the frameworks you selected above.
Results table: A live preview of every asset that currently matches your conditions. As you add or change conditions, the table updates so you can confirm the rule is doing what you expect before saving.
Note: Scoping rules define what is in scope. They do not define what is out of scope or excluded.
Narrowing scope for a framework
Because rules only define what's in scope, narrowing scope can feel counterintuitive. There's no "exclude" rule. Instead, you adjust which rules cover a given framework and resource type.
The default rule for each resource type covers all of your frameworks at once, so adding a new rule alongside it for the same resource type and framework causes the two to overlap. The default wins, and your new rule has no effect. (The Status column will flag this as Overlapping rules.)
Three options, depending on what you want:
Narrow scope across all frameworks on a default rule (or on a single-framework setup). Edit the default rule directly and tighten its conditions. This is the simplest path and works whenever you want the same scope for every framework the rule covers, including when you only have one framework.
Narrow scope for one framework while keeping the default for the others. Remove that framework from the default rule, then create a custom rule assigned only to that framework with the conditions you want. This only makes sense if you have multiple frameworks.
Replace the default entirely. Delete the default rule and create your own custom rules. Anything that doesn't match an active rule for a framework is automatically out of scope, so make sure your custom rules cover the assets you want included.
Manual scoping is separate. If you've already scoped specific assets in or out manually on the asset pages, those decisions stay intact when you save a new rule (unless you choose to override them). See Manual scoping vs. rule-based scoping for details.
Building rule logic
The clearest way to understand scoping rules is to see them in action. Here are two common patterns.
Example 1: Scope a single AWS account into PCI
Scenario: All of your cloud resources that process cardholder data live in one AWS account (756181438366), and you want them in scope for PCI.
In Applicable frameworks, select PCI ROC 4.0.
Add the conditions:
Vendor = AWSAccount = 756181438366
Confirm the expected resources appear in the Results table.
Click Save.
Example 2: Scope only production assets in a specific region
Scenario: Within a single AWS account, only your production resources process real data. They're tagged tag1 and run in us-west-2.
In Applicable frameworks, select the relevant framework(s).
Add the conditions:
Vendor = AWSRegion = us-west-2Tag = tag1
Confirm the expected resources appear in the Results table.
Click Save.
Tip: Tags and account boundaries are usually the cleanest ways to organize resources for scoping. We recommend picking one of these conventions, applying it consistently as a business process, and writing your rules to match.
Rule statuses
The Status column tells you whether each rule is doing what you expect. Click a status to see details and a recommended next step.
Active:The rule is healthy and scoping assets into the frameworks it covers. No action needed.
Overlapping rules: Another rule targets the same resource type for one or more of the same frameworks. The default rule wins, so this rule has no effect. Remove the overlapping framework from the conflicting rule, or delete it.
Not linked: The rule has no frameworks assigned, so it isn't scoping anything. Assign a framework, or delete the rule.
No resources: The rule's conditions don't match any assets. Check that the integration is connected and syncing, or loosen the conditions.
How quickly rules take effect
Because a rule change can shift the scope of your tests significantly, Secureframe automatically refreshes the affected tests when you save. Depending on how many assets are involved, the refresh can take a few minutes to complete.
After the initial refresh, the rule continues to evaluate new assets as they're ingested. There's no need to re-run it manually.
Manual scoping vs. rule-based scoping
Scoping rules are designed to coexist with any manual scoping you've already done or will do on the assests page. When you save a rule, you'll be asked how it should interact with manually scoped assets:
No, do not apply: The rule will skip assets you've already manually scoped, leaving those decisions intact.
Yes, apply and override manually scoped resources: The rule will overwrite any manual scoping. This permanently removes the manual scope from those assets so the rule governs them going forward.