# Filters

> Narrowing a run to selected controls by ID, tag, or impact.

Source: https://refpoint.dev/docs/rules/filters

Filters select which controls a run executes. This page covers the four filter
flags, the ID pattern syntax, and how tag values are matched.

## Control filters

| Flag | Effect |
|------|--------|
| `--control LIST` | Keep only matching IDs |
| `--skip LIST` | Remove matching IDs |
| `--tag key=value` | Keep controls carrying that tag |
| `--impact FLOAT` | Keep controls at or above that impact |

## ID patterns

The pattern syntax is shared with dependency `include` and `exclude`, so profile
authors learn it once. All patterns are case-sensitive.

| Pattern | Meaning |
|---|---|
| `^prefix` | ID starts with `prefix` |
| `suffix$` | ID ends with `suffix` |
| `*`, `?`, `[...]` | Glob, via `path.Match` |
| anything else | Substring, equivalent to `*plain*` |

## Tag matching

Tag values may be comma-separated lists, for example
`iso27001 = "A.8.20, A.8.21"`. A filter matches if any token equals the query
case-insensitively, falling back to a case-insensitive substring match for plain
values such as `category = "ssh"`.

Watch that fallback when clause identifiers share a prefix. A query of `A.8.2`
finds no exact token in `"A.8.20, A.8.21"`, so it falls through to the substring
test and matches anyway. If you need clause-exact selection, keep one clause per
tag key or use control ID patterns instead.