Apply the framework during an engagement
Start with the authorised objective, then choose where a maintained workflow will help the consultant investigate it. These examples connect preparation, execution and evidence review to the decisions that shape the client report.
A SaaS investigation supported by a reusable workflow
In the illustrative SaaS penetration-test walkthrough, a consultant investigates whether an ordinary customer user can retrieve another tenant's reports. A maintained workflow helps compare selected requests using designated accounts and synthetic data, and retain the evidence needed to interpret the results.
A supported denial on the ordinary report route leaves a separate download path unexamined. The consultant decides to investigate that path under the engagement's existing authority, then limits the finding to the access actually demonstrated. The walkthrough shows what goes into the client's report and what remains untested.
The pack's Markdown specifications and evaluation records describe the narrower workflow. Its completed records are fictional, and their unresolved issues still block client use. The blank templates help a team record its own operating boundaries and readiness decision.
The delivery failure modes address problems that can arise when introducing or maintaining these capabilities, including unsupported coverage, poor handover and overloaded reviewers.
Illustrative internal infrastructure penetration test
Fictional situation and reporting examples. No assessment has taken place.
A client commissions a fixed-duration internal infrastructure penetration test from an agreed low-privilege workstation and standard account. The objective is to investigate whether an attacker could reach the designated sensitive system, records-test, or obtain read access to its synthetic restricted folder. The rules of engagement define the permitted systems and actions, including exploitation approvals, disruption limits and the test window.
The consultant uses a maintained enumeration procedure to collect account, group and service relationships, retaining the queries and results with their starting context. One observation links the standard account's group membership to an in-scope management service with delegated access to records-test. The consultant prioritises examining what that group actually permits and whether the service could provide a path to the objective, rather than continuing broad enumeration. The workflow makes the observation inspectable; it does not choose the next step.
Before attempting to use the service's delegated access, the consultant describes the specific validation action to the engagement lead. The lead checks what the service would do on records-test, possible disruption and recovery against the rules of engagement, and obtains any required approval. If that action is outside the agreed authority, the consultant can inspect permitted configuration evidence or record the untested path. Discovering the relationship does not authorise additional systems or operations.
In this fictional outcome, a permitted connection demonstrates network reachability to records-test, but the test window ends before the service path or restricted folder access is validated. The report distinguishes that demonstrated reachability from the plausible, untested path to data. It states the starting account, supporting evidence and time limitation. It does not describe restricted access as achieved or imply that no other paths exist.
Controls to settle before execution
Before execution, the engagement lead and consultant agree how the written authority will be applied to the selected activity. They need to know what the workflow can reach, which actions need approval and what will happen if a prerequisite or execution control fails. Instructions alone do not enforce that boundary.
Targets and permissions
The lead confirms permitted assets, accounts and operations against the rules of engagement. The consultant restricts tool destinations and credentials where feasible, and records how newly discovered resources will be handled. Specified exploitation or disruptive actions need the agreed approval before execution. An agent, if used, operates under the same authority.
Operating limits
The consultant plans the selected activity within the permitted hours, request rates and relevant resource or cost limits. The lead agrees which potentially disruptive actions are prohibited or require a separate decision. When a limit is reached, record the remaining work as untested rather than allowing a retry to extend the run.
Intervention
Agree who receives a stop notification, who can revoke access and who confirms recovery before work resumes. The consultant stops on failed authentication, missing evidence capture or unclear authority and contacts the agreed lead. A supported observation of a target weakness follows the specified finding-review or bounded-confirmation procedure; it does not authorise open-ended probing.
Client data and untrusted inputs
The engagement lead agrees evidence storage, permitted processing services, recipients and retention with the client. Keep engagement records separate from reusable material. If application content proposes an instruction or another destination, the consultant treats it as evidence to assess; it cannot change the authorised activity.
Maintain and evaluate the workflow
Controlled changes
The workflow owner versions the procedure, relevant code and execution configuration so another practitioner can identify what was used. For AI-enabled work, include prompts, tool permissions, settings and model identity or version where exposed. Record unavailable details as uncertainty, and preserve enough context to investigate a failure without assuming an identical run can be reproduced.
Checks before wider use
The owner evaluates representative conditions for the workflow's intended function, including known weaknesses, expected permitted or denied behaviour, failed prerequisites and missing evidence. A competent reviewer inspects those records and decides whether that version is suitable for the proposed use. Correct detection of a deliberately vulnerable case can meet the workflow's criteria even though the target violates its security rule.
Agree a recovery option before relying on a changed configuration. If a previous version cannot be restored, use a suitable evaluated alternative or hold the affected activity while the replacement is evaluated. Evaluation establishes whether a workflow performs its intended function under the conditions tested. It does not establish that an engagement is complete or that the assessed environment is secure. The consultant must still investigate the authorised objectives and justify findings and coverage statements.
Record the outcome accurately
The consultant records a category for each selected activity and a separate security conclusion supported by its evidence. A valid authenticated denial can support the expected access restriction. An expired login, timeout or failed prerequisite cannot. In the report, tie coverage statements to the declared assets or objectives and describe their limits. Any percentage needs a defined denominator and must not imply that the whole objective has been investigated.
- Tested with supporting evidence. The intended action took place and its artefacts support the conclusion, whether a permitted action, an expected denial or a finding. Other vulnerabilities may still exist.
- Tested but inconclusive. The action took place, but missing or ambiguous evidence prevents a defensible conclusion.
- Execution failed. A prerequisite failure during execution or another execution problem prevented a valid check. The execution error cannot support a claim that the attempted attack was unsuccessful.
- Not tested. The activity was not attempted, including missing initial prerequisites or work left after a stop. Record the reason.
Workflow readiness checklist
The technical lead uses these prompts to review the proposed workflow use against its specification and evaluation evidence. Record the decision and any limits; ticking the entries does not establish engagement completeness or provide a certification.
- The authorised adversarial objectives and workflow contribution are clear.
- Targets and operating limits are documented and reflected in access controls.
- A named person owns the workflow and its maintenance.
- Approval and intervention conditions are defined.
- Relevant evaluation evidence supports the intended use; material blockers are resolved and remaining limitations recorded.
- Failures can be distinguished from completed tests.
- Evidence supports the conclusions being reported.
- Client data handling and external processing are authorised.
- Review capacity is available in the delivery plan.
- Changes are reviewed and have an agreed recovery option if the previous version cannot be restored.
Address any material gap before using the workflow for that purpose. Record investigative gaps separately: workflow readiness does not establish engagement completeness. A different engagement may require additional controls.
Back to the framework
Review the capabilities and proposed discussion levels on the definition page.
Back to definition