Where the time goes today
The report is a snapshot
Your application keeps changing after an assessment. A fixed permission or session workflow can regress in a later release.
Retesting competes with feature work
Someone has to prepare accounts, repeat the original steps and check that the fix did not block legitimate users.
The finding never becomes coverage
A closed ticket does not give the next pull request a repeatable check for the same browser behavior.
Turn the finding into an expected outcome
Take a browser-reproducible finding from your security team or pen tester. Prepare the affected roles and test data, then write the allowed and denied outcomes as a Scenario.
Define the retest as a ScenarioVerify the fix with browser evidence
Run against the fixed preview and inspect what happened for each role. Keep exploit research, network testing and the assessment itself with your security specialists; use Composal for the repeatable browser workflow.
Run and review the retestCarry the check into development
Run the Scenario from your CLI or CI after relevant changes. If the behavior regresses, send the Finding and reproduction evidence to the engineer or coding agent working on the fix.
Run verification from the CLIA repeatable retest
The browser workflow survives beyond the original ticket and assessment.
Both sides of access
Check that the restricted account is denied and the intended user can still complete the task.
Evidence between assessments
Keep run results and reproduction steps available to engineering and the security team.
