> For the complete documentation index, see [llms.txt](https://docs.stepsecurity.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stepsecurity.io/workspace/settings/control-evaluation.md).
# Control Evaluation
Control Evaluation is where you configure which security controls are evaluated on your GitHub organization, and how strictly. Settings here apply org-wide, and are reflected in the [Overview](/workspace/overview.md) dashboard and the control detail pages.
**To reach this page:** open the sidebar and go to Settings > Control Evaluation.
## **Control Options**
The **Control options** card holds org-wide exemptions for individual workflow controls. Changes in this card take effect when you click **Save Changes** at the top of the page.
#### **Exempted Actions from Pinning Control**
The [Actions should be pinned to a full-length commit SHA](/workspace/overview.md#actions-should-be-pinned-to-a-full-length-commit-sha) control normally flags every third-party GitHub Action referenced by a branch or tag instead of a commit SHA. Use this field to exempt specific Actions from that control.
* Type an action name (e.g., `actions/dependency-review-action`) and press Enter to add it.
* Wildcards are supported, e.g. `actions/*` exempts every Action under that owner.
* Exemptions apply across the security scan and build-log analysis for the org, and are also honored by the automated pinning pull requests, so an exempted Action is never flagged or auto-pinned.
#### **Low Score Action Exemptions**
The Third-party GitHub Actions with high scores should be used control normally flags every GitHub Action with a security score below 6. Use this field to exempt specific Actions from that control, for example an Action your team has reviewed and accepted, or one with no maintained alternative.
* Type an action name (e.g., `example-org/example-action`) and press Enter to add it.
* Wildcards are supported, e.g. `example-org/*` exempts every Action under that owner.
* Scores are calculated per Action, not per version, so any version ref you include (such as `@v2`) is ignored. Adding an Action exempts every version of it.
{% hint style="info" %}
Where a StepSecurity Maintained Action exists, replacing the low-scoring Action is usually a better fix than exempting it. Reserve exemptions for Actions you have reviewed, and remove entries that are no longer needed.
{% endhint %}
Click **Save Changes** to apply changes.
## **PAT Governance Controls**
This card configures the org's PAT Governance policy, which is evaluated against your GitHub personal access token inventory on every scan. Violations appear as findings on the token controls in [All Controls](/workspace/overview.md#all-controls), and per-control notification toggles live under [Settings > Notifications](/workspace/settings/notifications.md).
Use the toggle at the top of the card to turn the whole policy on or off. While it's off, none of the controls below are evaluated, no findings are generated, and no notifications fire, regardless of how the individual toggles below are set. Turning it back on resumes evaluation on the next scan.
Once enabled, each control can be configured independently:
| Control | Severity | Setting |
| ------------------------------------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Tokens should be rotated within max age** | High | **Fine-grained max age** and **Classic max age** set separate maximum ages, in days, per token class. Set either to `0` to disable that class's age check. Owners get pre-expiry reminders at the bands configured under [Reminders & Automation](#reminders-and-automation). |
| **Tokens should have an expiration** | High | Toggle on to flag tokens created with no expiration, or with an expiration further out than the configured max age allows. |
| **Tokens should have minimum scopes** | Critical | Toggle on to flag classic tokens with a coarse scope such as `repo`, `admin:org`, or `workflow`, fine-grained tokens with all-repository write access, and full-scoped or global Azure DevOps PATs. |
| **Tokens should be actively used** | Medium | **Idle limit (days)** flags a token with no use for longer than this window. Set to `0` to disable the staleness check. A never-used token is measured from when it was granted. |
**Open a GitHub issue per alert (optional)**: enter a repository in this organization to have each PAT Governance alert file one living summary issue there, in addition to any other configured notification channels. The issue is closed automatically when every finding it tracks resolves. Leave the field empty to disable.
**Exempted tokens**: a token with an active exemption is skipped by these controls, by pre-expiry reminders, and by automated revocation until the exemption expires, then re-enrolls automatically. An exemption applies to one organization or, as a [tenant-wide exemption](/github/apps-and-pats.md#tenant-wide-exemptions), to every organization in your tenant. Add and remove exemptions on the [Exemptions](/github/apps-and-pats.md#exemptions) tab of Apps & PATs.
### **Reminders & Automation**
The **Reminders & Automation** section of the same card controls when pre-expiry reminders are sent, who receives them, and what the reminder email says.
#### **Pre-expiry reminders**
Each band sends one reminder per token.
* **Remind at**: a comma-separated list of days before expiry at which a reminder is sent (e.g. `30, 7, 1`). This is the shared schedule for both token classes.
* **Classic override** and **Fine-grained override**: an optional per-class schedule. Leave a field at `shared` to use the shared schedule for that class. When you enter a value, it replaces the shared schedule for that class rather than adding to it.
#### **Reminder delivery**
Reminders are sent to the organization's notification address.
* **CC every reminder to**: a comma-separated list of email addresses (for example a security or platform distribution list) that is copied on every reminder the organization sends.
#### **Email content**
Reminder emails use StepSecurity's built-in content unless you customize them. Click **Customize** to open the **Customize email content** dialog. The card shows **Using built-in emails** while no customization is in place.
The dialog has a section for **Classic reminder emails** and a section for **Fine-grained reminder emails**. Within each section, every reminder band (for example **30 days before expiry**, **7 days before expiry**, **1 day before expiry**) has its own subject line and body editor, so you can change the wording for a single class and band without affecting the others.
* Each editor is prefilled with the default content, so you can start from the built-in email and edit only what you need.
* A field left equal to the default, or emptied, keeps the built-in email for that class and band.
* The following placeholders are substituted when the email is sent: `{{owner}}`, `{{token_name}}`, `{{organization}}`, `{{days_left}}`, `{{expires_at}}`, and `{{manage_url}}`.
* Click **Done** to close the dialog. Changes apply when you save the card.
Click **Save** to apply changes.
## **Repository Selection**
Control which repositories are included in control evaluation. When a repository's **Controls** checkbox is on, its workflows are evaluated against the enabled controls; when off, that repository is excluded from control checks (Harden-Runner and other scans are unaffected).
* Use the search box to find a repository by name.
* Archived repositories are marked with an **Archived** badge.
* The refresh icon on a row re-evaluates that repository's controls immediately, without waiting for the next scheduled scan. It's only available while controls are enabled for that repository.
---
# 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.stepsecurity.io/workspace/settings/control-evaluation.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.
