Assessment Methodology
The evidence pipeline
Five collectors run independently, every outcome is recorded in a manifest, and one failing degrades the assessment rather than aborting it.
The collectors
| Collector | Captures |
|---|---|
| Account metadata | Which account was scanned, its alias, and its organisation membership |
| Security Hub posture | Whether Security Hub is enabled, whether a delegated administrator exists, whether cross-region aggregation is on, and the count of active failed findings |
| Cost telemetry | 30-day spend from your own billing data, and evidenced waste from demonstrably idle resources |
| Resilience posture | Coverage ratios over real resources for five configuration signals |
| Control checks | The scanner's control results across every enabled region |
A sixth, delivery evidence, runs only when a source repository is supplied. It is collected but not scored. See Delivery, and why it is out of scope.
One failing does not abort the rest
Each collector runs independently. A collector that fails, is denied a permission, or is skipped does not stop the others.
That is only defensible because of the next part.
Every outcome is recorded
An evidence manifest is written capturing what each collector actually did, and it is written whatever the outcome of the run. The engine reads it and reports each collector's state in the pack.
This is what makes a partial assessment visible. Without it, a collector that silently failed would look identical to an account with nothing of that kind in it.
And the engine refuses thin evidence
Collecting partial evidence is acceptable; publishing a confident rating from it is not. The engine will not emit a deliverable pack when evidence confidence is below High. See Confidence and INSUFFICIENT EVIDENCE.
Provenance is recorded too
The exact scanner version, the severity scope, the regions scanned and the engine version are all recorded with the run, so the assessment can be reconstructed later.