The assessment in six steps

1. Authorize. The assessment assumes the read-only role in your account through GitHub OIDC, with a session named so your CloudTrail can attribute it. Before that, the run refuses to proceed if the offering is not one this backend can deliver, and refuses to assume any role other than the hardened assessment role.
2. Collect. Five collectors run: account metadata, Security Hub posture, cost telemetry, resilience posture, and, only when a repository is supplied, delivery evidence. Each runs independently, and one failing does not abort the assessment.
3. Check. Control checks run across every enabled region at critical, high and medium severity. Both passing and failing results are collected, because the security domain is scored as a pass rate and a rate needs a denominator.
4. Record. An evidence manifest is written capturing what every collector actually did: succeeded, failed, was skipped, or was denied permission. This happens whatever the outcome, so a partial assessment is visible rather than absorbed.
5. Score. The engine collapses records to distinct controls, scores the three governance domains, applies the ceilings and gates, and refuses to emit a deliverable pack when evidence confidence is below High.
6. Deliver. The board pack is rendered and uploaded, separately from the raw evidence and separately from the comparison snapshot. The API retrieves the pack, stores it, and emails you a link to your own portal.

What never happens

Nothing is created, modified or deleted in your account. No agent is installed. No data-plane content, meaning object contents, database rows, log events and secrets, is read at all, because the role denies those actions outright.