> ## Documentation Index
> Fetch the complete documentation index at: https://conductorone-findings-decoys-followup.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Findings
> Detect and act on the things you care about in your organization's access data, from unowned service accounts to exposed credentials.
**Early access.** This feature is in early access, which means it's undergoing ongoing testing and development while we gather feedback, validate functionality, and improve outputs. Share feedback with the C1 Support team.
Stop hunting for risk by hand. Point C1 at the conditions you care about — unowned service accounts, exposed credentials, misclassified identities, and more. It surfaces them as findings the moment they occur, and rules let you triage, escalate, or resolve them automatically. C1 checks for these conditions every time a connector syncs. It reports back the moment it detects a match.
Go to **Identity security** > **Findings** to get started.
## Turn on finding types
C1 ships with a catalog of built-in finding types, grouped by category. None are required — you choose which conditions matter to your organization.
Findings don't appear until you turn on the finding types you want C1 to detect. There's no separate "create" or "new" control — everything starts from **Findings settings**.
From any tab in **Findings**, click the **settings** (gear) icon in the top right.
In **Findings settings**, toggle on the finding types you want C1 to detect. Each type shows a short description of what it looks for.
Click **Save changes**.
C1 starts creating findings of the types you turned on the next time each connector syncs.
Turning off a finding type stops C1 from creating new findings of that type. Findings of that type that are already open stay open — nothing re-checks them, so they won't resolve automatically.
### Finding catalog reference
The following finding types are available today, grouped by category:
| Category | Finding type | Detects |
| :------------------ | :-------------------------------- | :-------------------------------------------------------------------------------- |
| Ownership | Unowned non-human identity | Non-human identities with no assigned owner. |
| Ownership | Unowned service account | Service accounts with no assigned owner. |
| Ownership | Deactivated owner | Accounts and resources whose owner has been deactivated. |
| Identity resolution | Similar username match | App accounts that look like they belong to a known identity. |
| Identity resolution | Service account misclassification | Accounts labeled human that behave like service accounts. |
| Credentials | Decoy credential used | A planted [decoy credential](/product/admin/decoys) was used to attempt access. |
| Credentials | Unused secret | Secrets that have gone unused past the inactivity threshold. |
| Credentials | Credential publicly exposed | Credentials found published outside your organization. |
| Credentials | Decoy publicly exposed | A planted [decoy credential](/product/admin/decoys) was found published publicly. |
| Configuration | Anomaly detection disabled | Connectors running with sync anomaly detection turned off. |
## Work with a finding
Click a finding from the **Overview** or **All findings** tab to open its detail view, which includes:
* **Evidence** — why C1 flagged this finding, including any confidence score.
* **Activity** — an audit trail of everything that's happened to the finding, including when it was created, when routing rules evaluated against it, and any evidence updates.
From the detail view, you can take one of the following actions on a finding:
* **Accept risk** — formally acknowledge the finding as a known risk. Requires a justification and an expiration date. The finding reopens automatically when the acceptance period ends.
* **Suppress** — permanently hide the finding from the default view and exclude it from posture scores. Requires a reason.
* **Snooze** — temporarily hide the finding. Requires a duration (1, 7, 30, or 90 days, or a custom date) and a reason. The finding automatically returns to open status when the snooze period ends.
* **Remediate** — resolve and close the finding. This action only appears for finding types that support it. Its label also varies by finding type — for example, a service account misclassification finding offers **Confirm human** and **Mark as service** instead of a generic remediate button.
You can only act on findings one at a time today. Bulk actions are coming soon.
## Transformation rules
Transformation rules reshape a finding's data — for example, escalating its severity or adding annotations — before a routing rule acts on it. Use them to make sure the findings that matter most are marked that way consistently. Your routing rules can then act on severity or annotations directly, instead of re-deriving that context from scratch.
Go to **Findings** > **Transformation rules** to create or manage them. Each rule has:
* **A match condition** — narrow the rule to a specific app, finding type, or a [CEL expression](/product/admin/expressions) referencing `finding.severity`, `finding.state`, `finding.risk_score`, or `finding.annotations`. Leave everything unset to match every finding.
* **One or more transforms** — set severity, add annotations, or remove annotations.
For example, to flag every finding on a sensitive app as more urgent, create a rule matching `finding.app_id == ""` that sets severity to Critical. A routing rule can then match on that Critical severity and escalate automatically.
You can create as many transformation rules as you need. Every rule whose condition matches a finding is applied, in ascending order by the rule's **Order** value — later rules override earlier ones where they conflict.
## Routing rules
Routing rules turn triage into automation. Instead of someone opening every finding to decide what happens next, a routing rule matches on a condition and immediately suppresses, snoozes, accepts, remediates, or dispatches it. No manual review is required unless nothing matches.
Go to **Findings** > **Routing rules** to create or manage them. Each rule has:
* **A match condition** — the same app, finding type, or CEL expression matching used by transformation rules.
* **An action** — No action, Suppress, Snooze, or Accept risk. Remediate is also available for finding types that support it.
* **Dispatchers (optional)** — fire a webhook, invoke a function, or trigger an automation every time the rule matches.
For example, suppress low-severity noise automatically with a rule matching `finding.severity == FINDING_SEVERITY_LOW` and action Suppress. Escalate anything Critical with a rule matching `finding.severity == FINDING_SEVERITY_CRITICAL` that triggers an [automation](/product/admin/automations) to notify your team or open a ticket.
Unlike transformation rules, routing rules stop at the first match. C1 evaluates rules in ascending order by **Order** and applies only the first one that matches.
### Order rules effectively
Transformation rules and routing rules order in opposite directions, and mixing up the two is the most common way a rule set stops working as expected.
* **Transformation rules apply cumulatively** — every matching rule runs, and later rules override earlier ones. Put your general, default-setting rules early and your specific overrides later.
* **Routing rules stop at the first match** — only one rule ever runs. Put your specific, narrow rules early and your general, catch-all rules last. A broad rule placed too early will catch findings a later, more specific rule was meant to handle.
A few other tips for keeping a rule set maintainable:
* Test a routing rule's match condition with the **No action** action first, which matches the finding without changing its state. Confirm it's catching the right findings before wiring up Suppress, Snooze, or a dispatcher.
* Leave gaps between **Order** values (10, 20, 30 instead of 1, 2, 3) so you can insert a new rule later without renumbering the rest.
* If you want a default outcome for anything your specific rules don't catch, add a broad rule with no match condition (**Match all**) at the end of your routing rules.
## Example: catch and escalate decoy credential use
This walkthrough combines a finding type, a transformation rule, and a routing rule to automatically flag and escalate decoy credential use. It's a strong signal of compromise that shouldn't wait for someone to notice it in the findings list. See [Decoys](/product/admin/decoys) for how to plant a decoy credential.
In **Findings settings**, under **Credentials**, turn on **Decoy credential used**.
Save your changes.
Go to **Transformation rules** > **Create rule**.
Set **Finding type** to **Decoy credential used**, and leave **App** and the expression unset to match every app.
Add a **Set severity** transform and set it to **Critical**.
Save the transformation rule.
Go to **Routing rules** > **Create rule**.
Set **Finding type** to **Decoy credential used**.
Set **Action** to **No action**, so the finding stays open for review.
Add a **Trigger automation** dispatcher to notify your security team immediately.
Set this rule's **Order** so it runs before any broad catch-all routing rules. A general rule like "suppress low severity findings" could otherwise match first and prevent this one from running.
From now on, every decoy credential finding is marked Critical, and your security team is notified the moment it's created. No one has to find it in the findings list first.