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, appears in the Issues view, grouped by provider and rule. Open a group to see each affected resource with its status, severity, and Last observed time. Each resource also offers Open asset & dependencies and Remediation guidance. Expand Remediation guidance for fix steps and, where the provider publishes one, a Provider remediation guide link.

The Issues view: failing and warning observations grouped by provider and rule.

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. Findings whose standard references match a requirement in an active framework map to a control automatically. The rest wait in the Needs mapping queue. Find it under Control objectives > Review rule mappings and suggestions, or in Failing checks to map on a connection's detail view. 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.

The Needs mapping queue: each failing rule offers a manual map-to-control picker and, where SolveGRC is confident, an AI suggestion showing the proposed control, its confidence, and the reasoning — with Accept and Reject. Map a rule once and every finding citing it connects to control assurance.

How posture findings reach your controls

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.

A failing mapped finding shows as an open finding on the control, titled "Posture:" followed by the finding's title, and lowers that control's assurance score. When a later sync sees the fix, the failing finding is set to pass and the control finding closes automatically. A passing check does not satisfy a control or change its compliance status, and posture findings are not registered as evidence. As the product itself says, mapping does not prove compliance. 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.