> For the complete documentation index, see [llms.txt](https://docs.firefly.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.firefly.ai/detailed-guides/workflows/creating-guardrail-rules/policy-guardrail-criteria.md). # Policy Guardrail Criteria: Frameworks, Categories, and Severity > **Related Guides and Examples:** > > * [Creating Guardrail Rules in Firefly](/detailed-guides/workflows/creating-guardrail-rules.md): The full Guardrail creation wizard, covering all four rule types. > * [Creating Policy-as-Code Governance Rules](/detailed-guides/policy-and-governance/creating-policy-as-code-rules.md): How the policies referenced here are defined. > * [Wiz Policy Integration](/detailed-guides/workflows/wiz-policy-integration.md): Delegating IaC policy evaluation to Wiz instead of Firefly's built-in policy engine. > * [Overview: Firefly Workflows and Guardrails](/detailed-guides/workflows.md): 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](https://292727710-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkD89Ravlokn4JL0Be27O%2Fuploads%2Fgit-blob-74dfeb7f33111ba859372e7db3b53d0d46d79a78%2Fguardrail-policy-criteria.png?alt=media) 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](https://292727710-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkD89Ravlokn4JL0Be27O%2Fuploads%2Fgit-blob-5268250a1cb38700e06a0e95e00fdd44dca3b5d9%2Fguardrail-policy-frameworks.png?alt=media) The available frameworks reflect your account's governance configuration and are kept in sync with the [Governance](/detailed-guides/policy-and-governance.md) 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](https://292727710-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkD89Ravlokn4JL0Be27O%2Fuploads%2Fgit-blob-e3612df2ea2cf4672d2730cbdcbb5dc42fa5ac7e%2Fguardrail-policy-categories.png?alt=media) 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](/detailed-guides/policy-and-governance.md) 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.firefly.ai/detailed-guides/workflows/creating-guardrail-rules/policy-guardrail-criteria.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.