The successful run that tested nothing useful
A pentest workflow’s completion status cannot support a coverage statement when its authenticated activity did not execute as intended.
Fictional illustrative situation
During a SaaS penetration test, supplied credentials stop working partway through an authenticated workflow. It continues, records authentication errors as denied access and produces a “no unauthorised access observed” summary. That summary enters the draft client report. This situation and result are fictional.
What has gone wrong
Finishing the run has been mistaken for investigating the intended access-control objective. An expired session does not demonstrate that a role or tenant boundary held. Earlier valid activity may remain usable, but subsequent checks need separate classification. The unsupported summary risks concealing a material coverage gap.
Evidence the lead should inspect
The technical lead should locate the last confirmed valid session using the account identity, permitted baseline action and retained requests and responses, then identify subsequent activity and dependent checks. They should compare the workflow version, application build and settings with the plan. An attempted check whose authentication cannot be established is Tested but inconclusive. Where the records show that failed authentication prevented the intended check, it is Execution failed. Neither supports a boundary-denial conclusion.
A proportionate correction
The workflow owner should ensure that execution requires a valid designated session and permitted baseline action, with rechecks after authentication errors or relevant session changes. The operating consultant stops or escalates when either fails, records activity that could not execute as “Execution failed” and marks skipped activity as “Not tested”.
The technical lead should withdraw unsupported statements and agree which affected activity must be repeated with valid credentials, within the authorised scope and remaining time. If repetition is unavailable, state the limitation in the client report. Keep a supported authorisation denial separate from an execution failure; neither supports a conclusion about checks that were never performed.
Check whether the correction worked
Evaluate the revised workflow with synthetic data in an authorised evaluation environment, including a session that expires partway through. Another practitioner should verify the stop, classifications and affected activity record. Confirm that repeated checks have usable evidence and that the report describes only supported coverage and remaining limits.
The SaaS penetration-test workflow pack’s fictional evaluation demonstrates these distinctions. Use the framework’s result recording guidance when reporting coverage.