Skip to main content

Findings to frameworks

A finding on its own is just a fact about a resource. The value comes from the bridge this page describes: findings arrive already citing the compliance standards they relate to, you map each failing check to one of your controls once, and from then on posture flows into your frameworks continuously.

Reviewing findings​

Every finding — live or imported — lands in one table: status (pass, warn, fail), severity, the rule that fired, the affected resource, whether it is mapped to a control, and when it was last seen. Findings that know how to be fixed carry a How to fix expander with remediation steps and, where the provider publishes one, a link to the vendor's remediation guide.

ScreenshotThe All findings table: status and severity badges, the rule ID, the affected resource, the mapped-control column, and a How to fix expander open on one row.

Standards references come built in​

Findings arrive with their compliance-standard references attached — the framework and reference code the cloud provider or scanner associates with the check. You will see these listed on each unmapped rule (for example, the SOC 2 or CIS references a failing check relates to), which is usually all the context you need to decide which of your controls it belongs to.

Mapping failing checks to controls​

Mapping happens per rule, not per finding. Map a rule once and every finding citing it — now and in the future — connects to control assurance. The Needs mapping queue lists failing checks not yet linked to a control, and each row offers two paths:

  • Map it yourself. Pick the control from the dropdown and click Map.
  • Ask for a suggestion. Suggest produces an AI recommendation with a confidence percentage and its reasoning, which you Accept or Reject. The AI proposes; a person decides.

A coverage bar tracks how much of your failing surface is mapped, and each cloud's card shows its own mapping coverage so an unmapped provider stands out.

ScreenshotThe Needs mapping queue: a failing rule with its standards references, the manual map-to-control picker, and an AI suggestion banner showing the proposed control, confidence, and reasoning with Accept and Reject actions.

How posture becomes framework evidence​

Once a rule is mapped, the loop closes on its own:

  • A failing finding whose rule is mapped to a control opens a control finding automatically — drift in your cloud becomes a tracked exception against the control it contradicts, with no manual triage step.
  • Each asset carries a framework disposition: the controls it touches and the active frameworks behind them, colored by whether its configuration currently passes or fails.
  • Where a policy document claims a control is implemented but a system's live configuration fails the mapped check, the contradiction is called out explicitly — the "say versus do" gap, surfaced per asset.

The net effect is that posture findings count toward control and framework satisfaction the same way any other evidence does. See Assess controls for how assessments consume this.

Map the rule, not the noise

Resist mapping finding-by-finding in your head. The queue is finite — one decision per rule — and once it is clear, new findings arrive pre-connected. The per-cloud coverage percentage is the honest measure of whether posture is actually feeding your frameworks.

Findings are half the picture. The same sync also builds your asset inventory and attack surface. Continue to Assets and attack paths.