The approval nobody can meaningfully review
Approval of an exploitation step needs a specific proposal that the named reviewer can assess against the rules of engagement.
Fictional illustrative situation
A consultant is asked to approve an exploitation step against a live, in-scope internal system during a penetration test. The request says “validate access” but omits the proposed operation, evidence justifying it and likely disruption. Similar requests have become routine. This situation is fictional; no exploitation has taken place.
What has gone wrong
Being in scope does not make every action permissible. The reviewer cannot establish whether this operation meets the rules of engagement or whether its likely impact is acceptable. Repeated vague prompts encourage rubber-stamping, while the approval record gives no defensible account of what was authorised.
Evidence the lead should inspect
Before approving, the lead needs to see the proposed operation, target, starting access, objective and supporting observation. The request should explain anticipated effects, possible disruption or data changes, operating limits, stop conditions and recovery arrangements. It must identify the relevant rule of engagement and the person authorised to decide. After execution, the lead compares the recorded activity with the approved action and limits.
A proportionate correction
The workflow owner should pause the action and provide that context in a short approval record. The authorised reviewer may approve only the specified operation and limits. If the proposal exceeds the agreed rules, the engagement lead must obtain the required client authorisation before proceeding. A reachable system or new observation does not extend scope.
For repeated use, record which routine activities are already authorised and which need a separate decision. Bind each approval to its operation, target, limits and configuration. A shared template and a clear owner are sufficient to start; an approval button alone is insufficient.
Check whether the correction worked
Give another practitioner a representative request. They should explain the intended operation, identify missing justification and recognise when client authorisation is required. Confirm that execution pauses without the required decision and that the recorded activity matches its limits. The engagement lead can then explain the decision during client review.
Use the SaaS penetration-test workflow pack and the framework’s execution controls to define approval boundaries.