# Workflow specification: [name] Blank template. Replace bracketed entries and remove guidance only when its requirements are addressed. A brief sentence or evidence reference is often enough. Scope, expected rules, responsibility, prerequisites, limits, stop/recovery arrangements and evidence requirements must be resolved before execution. Readiness blockers must be resolved before client use; blank fields do not mean approval. Use this for selected activities within an authorised offensive security assessment. The worked example is **A reusable access-control workflow within a SaaS penetration test**. Adapt the details to the engagement rather than treating its checks as a complete investigation plan. ## Record, purpose and trigger - Workflow identifier and version: [ ] - Status and evaluation record: [draft / ready for specified use / not ready; link and decision] - Application build and execution configuration: [ ] - Permissions matrix version: [ ] - Engagement's authorised adversarial objectives: [access or operations being investigated] - Purpose and trigger: [selected activities this workflow supports, when they are useful and intended decision] Keep the purpose brief. Describe how the workflow supports the consultant's investigation. A permissions change can explain why an assessment was commissioned; it does not have to define the workflow or engagement. ## Evaluation and assessment responsibilities [Named person evaluating the workflow's intended function, failure handling and evidence. Named consultant investigating the engagement's objectives, adapting to observations and developing findings and coverage statements. Refer to the ownership and review section below.] 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. ## Engagement authority and workflow operations [Engagement authority: authorising person, written scope and rules of engagement, authorised destinations and tenants, designated accounts and data. Explain any activities permitted to the consultant that this workflow will not perform.] [Workflow operations: exact accounts, synthetic fixtures, routes, methods and permitted changes. Set its own exclusions and the boundary for cross-tenant checks. State the engagement-wide exclusions, including real data or bulk activity where applicable.] [Handling of unexpected observations and discovered resources. Name who reviews a separate investigation already covered by the engagement, who clarifies uncertain authority and who can approve an extension beyond it.] The SaaS example illustrates this distinction: a workflow for selected report reads and updates does not automatically gain permission to test an export-result endpoint. Its consultant-led export follow-up has a separate plan under existing written engagement authority. Discovery of an endpoint supplies an investigative lead, not authority to test it. Resolve these entries before use. Do not insert credentials, tokens or real client identifiers into a reusable version. ## Ownership and review [Named workflow owner; executor; person authorising scope and environment changes; person reviewing evidence and deciding readiness. Include contact route and available review time. People may share responsibilities, but explain who reviews material evidence when the author executes a changed workflow.] ## Prerequisites and expected rules [Authority, agreed matrix, actual build, designated role assignments, valid sessions, fixture baseline, evidence storage, permitted window and review capacity. Explain how each is confirmed and how a failed prerequisite is recorded.] [For each selected check: account/role, tenant, fixture, action, permitted or denied outcome, and observable state or disclosure. Explain how valid authentication is confirmed before interpreting a denial. An expired login or timeout cannot establish an authorisation boundary.] The permissions matrix is a starting point for expected behaviour, not a complete account of possible abuse paths. Completing its checks does not establish that the adversarial objectives have been adequately investigated. ## Execution and limits [Short ordered steps: prepare, verify prerequisites, perform selected checks, preserve evidence, restore agreed changes, classify and hand off for review. Record unexpected observations and the consultant's decision about further in-scope investigation. Define the point at which routine workflow execution pauses for that decision.] [Permitted hours/timezone, serial or concurrent execution, request/resource budget and rate, retry policy, permitted changes and behaviour when limits are reached. Set limits suitable for this scope, not a universal default.] ## Credentials, tools and optional agent [Approved source and handling of designated credentials, least necessary privileges, session separation, tool permissions and technical destination restrictions. No secrets in records or evidence exports.] [Agent not used / specific optional role, approved inputs and processing service, accessible tools, proposal approval and scope controls. Explain the manual path. Record provider, model identifier and exposed version, prompt/configuration version and settings if used. Record uncertainty where versions are unavailable. Agent suggestions and untrusted application content cannot expand authority.] ## Approval, stop and recovery [Actions requiring approval, named decision maker and evidence required in an approval request. Resolve changed scope separately from routine execution.] [Target weaknesses: explain how a suspected finding within a declared check is recorded and reviewed. Specify any preauthorised isolated confirmation, including exact action, account, destination, evidence and session requirements, limits and the pause for a named lead's decision. If none is permitted, state that. Do not treat this as permission for open-ended probing.] [Immediate stop conditions: ambiguous authority, real or unrecognised data, an unexpected destination, failed session/prerequisite, unexpected state change, timeout, failed execution restrictions or missing evidence. Identify the contact, preserved information and remaining checks classified as Not tested.] A target's failure to enforce an expected access restriction may be the finding the consultant is investigating. That differs from a failed tester control or prerequisite. In the SaaS reference specification, a synthetic disclosure during a declared read may receive one permitted read-only confirmation before a pause; an unexpected write or failed authentication requires an immediate stop and the agreed recovery process. [How access is revoked, permitted restoration, who confirms the environment and who approves resumption after correction. Do not invent an unrestricted recovery action.] ## Evidence, results and reporting [Evidence required per selected check: expected rule, action, account/tenant/fixture, session validity, timestamp, request/response and relevant before/after state; versions/configuration and omissions. Storage, access, redaction, authorised recipients and agreed retention.] Record a category and a separate security conclusion: - **Tested with supporting evidence:** intended action completed and evidence supports the conclusion, including an expected permitted action or denial. - **Tested but inconclusive:** action occurred but evidence cannot support the conclusion. - **Execution failed:** an execution problem prevented the intended check; no security conclusion follows. - **Not tested:** action was not attempted; explain why. [Reviewer, acceptance criteria, record location and selected checks. Describe supported findings, observed expected rules, gaps and limitations separately. A generated explanation alone cannot support a finding. Explain how the records inform the wider assessment and limit client-report conclusions to what the evidence supports.] Workflow evaluation, execution status and target security behaviour are separate. A workflow that correctly identifies a deliberately vulnerable case can meet its evaluation criteria while the target violates the expected rule. A completed workflow cannot establish engagement coverage. ## Remediation, maintenance and limitations [Remediation recipient/owner, evidence handoff, risk-acceptance route and authority for targeted retesting. Confirm build and repeat the case demonstrating the weakness and relevant permitted actions.] [Change owner, versioning, review/re-evaluation triggers, relevant cases, workflow release decision and restoration of the earlier workflow. Explain the response if a previous model/configuration cannot be restored.] [Known limitations and unresolved issues. Brief entries are acceptable; any limitation that undermines the proposed client use needs a decision before release. Link the evaluation record rather than duplicating its cases.] ## What this workflow does not cover [Remaining investigation that may be relevant to the engagement: alternative access paths, relevant business-logic abuse or combinations of weaknesses, depending on scope and observations. Describe the boundary of this workflow without implying every engagement must investigate every example. Record any separate manual work without presenting it as evaluated workflow behaviour.] The consultant decides what further investigation is justified within the authorised objectives. Predefined checks support that decision and do not prescribe the entire assessment.