Skip to main content

How scoring works

A compliance score is the number the whole platform exists to produce: where do we stand against this framework? SolveGRC is deliberate about that number in two ways — it counts only what you've genuinely earned, and it shows enough of its own arithmetic that you can reproduce it. A score you can't explain is a score you can't defend to an auditor, so the design goal is a number that explains itself.

What the score measures​

The score is the fraction of the framework's in-scope requirements you've satisfied. Two things make that honest:

  • The denominator is in-scope only. Requirements you've marked not applicable, scoped out, or retired are removed from the denominator, not silently counted as passing or failing. The excluded count and the reasons are shown, so the denominator is reproducible — you can see exactly what the percentage is of.
  • The numerator is the parts on screen. The headline is the sum of the credited buckets divided by that denominator. You can add up what's displayed and arrive at the same percentage, with no hidden term.

That reproducibility is a property we test for, not a nicety: if the headline ever stopped equalling its own disclosed fraction, that's a bug.

Earned versus provisional — the honesty rule​

Not every signal that a requirement might be met is allowed to move the number. SolveGRC splits credit into two buckets and only counts one:

  • Earned — counts toward the score. A requirement you've assessed as compliant, and a requirement satisfied through a human-approved crosswalk mapping (an implemented control that an approver has confirmed also satisfies this requirement). This is what the percentage is built from.
  • Provisional — shown, never counted. Credit that would come only from an unapproved, AI-suggested mapping. The platform surfaces it as potential — a purple "not counted yet" marker — but it contributes exactly zero to the score until a person reviews and approves the mapping.

This is the platform's design law made arithmetic: credit is earned, never assumed. A machine noticing a possible connection is a helpful lead; it is not a compliance claim. The upside is a live to-do list — every provisional item is a "review this → earn back the points" opportunity, and approving a suggested mapping is one of the highest-leverage things you can do to move a score honestly.

Coverage and assurance are two different questions​

The score answers are the requirements satisfied? — call that coverage. It does not by itself answer how strong is the proof behind them? — that's assurance, and SolveGRC tracks it separately. A requirement can be credited toward coverage while the evidence under it is thin or aging.

That's why a framework position shows both, side by side. A high coverage number with weak assurance is a real state the product will not hide from you — it means "you've claimed these, now make the proof hold up." Reading coverage without assurance is how green numbers become audit surprises; showing both is how they don't.

What moves the score​

  • Assessing requirements moves coverage directly.
  • Approving a suggested mapping flips its credit from provisional to earned — the score goes up by exactly what was being withheld.
  • Scope changes move the denominator: excluding a requirement removes it from the fraction (with the reason recorded), so the number reflects your real obligations, not a padded list.
  • Freshness and exceptions feed the assurance and burden signals shown next to the score, so a position that was solid last quarter honestly reflects proof that has since aged.

A score is a point in time, and it says so​

Every score is a snapshot: computed from your evidence and assessments as of a moment, recomputed on the platform's regular cadence (and on demand), and stamped with when it was calculated and which calculation version produced it. Reports and audit packets cite that same snapshot, so the number in an exported document and the number in the live product are the same number — provably the same, because they came from the same stamped computation, not two separate recalculations.

What this means for you​

  • Trust the fraction, then check it. The headline is derivable from the counts on screen — if a number ever surprises you, the parts that make it are right there.
  • Work your provisional queue. Reviewing AI-suggested mappings is how you turn the platform's leads into defensible, counted compliance.
  • Read coverage and assurance together. A high score with weak proof is a prompt, not a victory — shore up the evidence before someone tests it.
What we don't expose

You can see what the score counts, what it excludes, and the parts it's built from. What stays internal is the deeper machinery — the exact assurance and exception weightings, the band thresholds, and the analysis behind a "likely" judgment. You get a defensible, reproducible number and the receipts behind it; the tuning that turns inputs into it stays in the platform, so the signal is consistent across every tenant and can't be gamed.