Policy Guardrail Criteria: Frameworks, Categories, and Severity

Related Guides and Examples:

• Creating Guardrail Rules in Firefly: The full Guardrail creation wizard, covering all four rule types.

• Creating Policy-as-Code Governance Rules: How the policies referenced here are defined.

• Wiz Policy Integration: Delegating IaC policy evaluation to Wiz instead of Firefly's built-in policy engine.

• Overview: Firefly Workflows and Guardrails: High-level concepts and options.

A Policy-type Guardrail decides which policy violations in a plan should block a deployment. The Criteria section is where you express that decision.

You can select policies three ways — by framework, by category, or by picking individual policies — and you can combine them. You can also exclude specific policies and set a minimum severity.

The Criteria section of a new Policy Guardrail

Selecting a framework or category is the recommended approach for broad compliance goals. Rather than hand-picking every policy in CIS, you select CIS once, and the Guardrail continues to enforce the framework's full contents as policies are added to or removed from it over time.

The Criteria Fields

Field	Purpose
Also enforce on no-op assets	Extends enforcement to resources present in the plan but not being created, changed, or destroyed.
Frameworks	Include every policy belonging to the selected compliance frameworks.
Categories	Include every policy belonging to the selected policy categories.
Policies	Include specific, individually chosen policies.
Exclude Policies	Never enforce these policies, whatever else selects them.
Lowest Severity	Minimum severity a violation must have to be enforced.

All fields are optional. A Guardrail with no criteria at all enforces every policy.

Selecting Frameworks

The Frameworks field lists the compliance frameworks available to your account, along with the number of enabled policies behind each. Select one or more; every policy in them is included.

Selecting frameworks in the Policy Guardrail criteria

The available frameworks reflect your account's governance configuration and are kept in sync with the Governance page, so the list you see here matches the Frameworks filter there. Typical entries include PCI DSS, SOC 2, CIS, HIPAA, NIST, Resiliency Posture, and versioned benchmarks such as CIS-AWS-v7.0.0 and CIS-Azure-v3.0.0.

Selecting Categories

The Categories field works the same way, grouping policies by what they protect against rather than by which standard mandates them — for example Access Control, Misconfiguration, Encryption, Networking and Firewall, Reliability, Insecure Configurations, Observability, and Optimization.

Selecting categories in the Policy Guardrail criteria

Frameworks and categories combine as a union: a policy is included if it belongs to any selected framework or any selected category.

Policies Already Covered Cannot Be Picked Again

Once a framework or category is selected, the Policies field shows how many policies that selection already covers — 554 covered by framework/category in the screenshot above — and those policies are no longer individually selectable. This prevents the same policy from being listed twice through two different routes.

You can still add individual policies that fall outside your framework and category selections. What you cannot do is select all policies (*) together with a framework or category; the Guardrail is rejected on save, because the wildcard would make the framework selection meaningless.

Membership Is Dynamic

Firefly stores your framework and category selections, not a snapshot of the policies they contained when you saved the rule. Membership is resolved fresh on every run.

A policy added to CIS next month is automatically enforced by a Guardrail that selects CIS, with no edit required. A policy removed from CIS stops being enforced by it. This is the main advantage of selecting a framework over listing its policies by hand.

Exclude Policies Always Wins

A policy listed in Exclude Policies is never evaluated. Exclusion is checked before anything else, so it takes precedence over every form of inclusion:

• Excluding a policy that belongs to a selected framework removes it from that framework's enforcement.

• Excluding a policy that belongs to several selected frameworks or categories removes it from all of them.

• If a policy is later added back to a framework upstream, your exclusion still holds.

There is no combination of criteria that re-includes an explicitly excluded policy.

How Lowest Severity Is Applied

Lowest Severity means different things depending on what else the Guardrail selects. This is the part most worth reading carefully.

What the Criteria contains	What the Guardrail enforces
Frameworks and/or categories, with a Lowest Severity	Only policies in the selected frameworks/categories, at or above that severity.
Frameworks and/or categories, without a Lowest Severity	Every policy in the selected frameworks/categories, at any severity.
Individually selected policies	Exactly those policies, at any severity. Lowest Severity does not filter them.
A Lowest Severity only, nothing else selected	Every enabled policy at or above that severity.
Nothing at all	Every policy.

Two consequences follow, and both surprise people:

Selecting a framework narrows the severity filter's reach. On a Guardrail with no framework or category, Lowest Severity: High means "block on any High or Critical violation anywhere". The moment you add a framework, it means "block on High or Critical violations within that framework". A Critical violation of a policy outside your selection no longer blocks the deployment. If you want both, create two Guardrails.

Individually selected policies ignore the severity threshold. If you select the policy S3 Buckets Must Have Server-Side Encryption Enabled and set Lowest Severity: Critical, that policy still blocks the deployment even though it is rated Medium. Picking a policy by name is treated as a deliberate decision to enforce it. The threshold only filters the set derived from frameworks and categories.

Attribution and Deduplication

A policy that belongs to more than one of your selections is evaluated once, not once per selection.

The selection it is attributed to — the one shown against the violation — is the first one listed, reading frameworks in the order you added them, then categories. If a policy belongs to both PCI DSS and the Encryption category, and PCI DSS was selected first, the violation is reported under PCI DSS. Reordering your selections changes the label on the violation, never whether it fires.

Also Enforce on No-Op Assets

By default, a Policy Guardrail only evaluates resources the plan is actually creating, changing, or destroying. Resources that appear in the plan but are unchanged are skipped.

Enable Also enforce on no-op assets to evaluate those unchanged resources too. This gives comprehensive coverage of everything in the plan, and is useful for driving existing infrastructure towards compliance rather than only holding new changes to the standard.

Expect it to surface pre-existing violations that previous runs never reported. Introduce it on a narrow scope first, or pair it with Flexible Block, so a backlog of historical violations does not block unrelated deployments on day one.

What a Violation Shows

When a Guardrail is triggered, the Guardrails step of the run lists each violated policy with:

• The violated policy name, its severity, and the framework or category it was selected through.

• The address of the offending resource.

• The expected value the policy requires.

Look for the Tinkerbell icon beside a violation for AI-generated remediation suggestions.

Examples

Enforce a compliance standard, high severity only

• Frameworks: PCI DSS

• Lowest Severity: High

• Result: High and Critical PCI DSS violations block the deployment. Medium PCI DSS violations, and violations outside PCI DSS at any severity, do not.

Enforce a standard with a known exception

• Frameworks: CIS

• Exclude Policies: EC2 Instance Has Public IP

• Result: every CIS policy is enforced except that one, including CIS policies added in future.

Combine a broad standard with one non-negotiable policy

• Frameworks: SOC 2

• Lowest Severity: High

• Policies: S3 Buckets Must Have Server-Side Encryption Enabled

• Result: High and Critical SOC 2 violations block, plus that specific S3 policy regardless of its severity.

Cover several risk areas regardless of standard

• Categories: Access Control, Encryption

• Result: every policy in either category is enforced, at any severity.

Troubleshooting

The Guardrail never fails, even on violations I expect.

Check whether its frameworks or categories resolve to any policies at all for your account. A selection that matches no enabled policies gives the Guardrail nothing to enforce, so it reports passed on every run. This happens when a framework has no enabled policies behind it in your account's governance configuration. Compare the counts shown in the Frameworks and Categories dropdowns against what you expect, and confirm the relevant policies are enabled on the Governance page.

A Critical violation got through.

If the Guardrail selects a framework or category, only policies inside that selection are enforced. A Critical violation of a policy outside it is not a miss — it is outside the rule's scope. Add the relevant framework or category, or add a second Guardrail with a Lowest Severity and no framework selected.

A violation below my Lowest Severity blocked the deployment.

The policy was almost certainly selected individually in the Policies field, where the severity threshold does not apply. Remove it from that field if you want it governed by the threshold, or exclude it outright.

I cannot save the Guardrail after selecting a framework.

Selecting all policies (*) together with a framework or category is not allowed. Clear the wildcard from the Policies field and save again.