# Evaluation record: [workflow name and version]

Blank template. Use a small set of cases relevant to the proposed work and consequences of failure. Brief observations and evidence references are enough when another practitioner can inspect them. Missing evidence, material failures and unresolved release blockers need an explicit decision before client use.

This records evaluation of a reusable offensive security workflow, such as **A reusable access-control workflow within a SaaS penetration test**. Evaluation checks whether it performs its intended function, handles known conditions appropriately and produces usable evidence. Conducting the assessment separately means investigating authorised adversarial objectives, adapting to observations and developing defensible findings and coverage statements.

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.

If this is a worked example, label the context, all observations, results and evidence as fictional and illustrative. If recording a real evaluation, describe only what actually happened; do not fill gaps with assumed outcomes.

## Context and scope

- Workflow identifier/version and specification: [ ]
- Engagement's authorised adversarial objectives and selected activities supported by this workflow: [ ]
- Engagement authority and narrower workflow operations: [written scope/rules of engagement; exact evaluated routes and actions; separately authorised investigative activity excluded from this evaluation]
- Application build, permissions matrix and execution configuration: [ ]
- Authorised application/tenants, designated account labels and synthetic fixtures: [ ]
- Executor, reviewer and person deciding readiness: [names and responsibilities]
- Evaluation date/run identifier and scope reference: [ ]
- Agent use: [none / provider, model identifier and exposed version, prompt version, settings, available tools and authorised processing service; note unavailable version details]
- Declared cases and limits: [what this evaluation covers, its exclusions and acceptance criteria]

Record versions and authority before evaluation. Keep secrets and client identifiers out of reusable records. Evidence references can point to a separate, authorised storage location.

## Case [identifier]: [descriptive title]

Copy this short section for each selected case. Include a permitted action, a prohibited role action, an authorised cross-tenant denial, failed authentication, an execution problem requiring a stop, and insufficient evidence where relevant. Include a known vulnerable case when the workflow is intended to detect that issue.

**Purpose and prerequisites:** [workflow function being evaluated, exact account/tenant/fixture/action, agreed matrix rule, valid session or deliberate failure condition]

**Expected target behaviour:** [permitted or denied action and observable state/disclosure; identify any deliberately vulnerable fixture]

**Expected workflow behaviour:** [execution, evidence capture and classification criteria; handling of a target weakness versus a failed tester control or prerequisite; any bounded confirmation and pause, or immediate stop and recovery]

**Observed behaviour:** [what happened, including partial execution, stop and restoration; do not confuse expectation with observation]

**Evidence:** [references for session/role check, request/response, before/after state and versions; what is missing and whether the reviewer inspected it]

**Result category:** [choose one for each selected action]

- Tested with supporting evidence.
- Tested but inconclusive.
- Execution failed.
- Not tested.

**Security conclusion:** [expected rule observed / supported finding / no conclusion, with a brief explanation]

**Workflow evaluation decision and follow-up:** [whether the workflow met this case's criteria, with evidence; accept or reject the security conclusion; corrective action, named owner and required repeat cases; unattempted checks after a stop]

Expected denial with valid authentication and evidence can be Tested with supporting evidence. An expired login or timeout is Execution failed, not proof of denial. An action with inadequate evidence is Tested but inconclusive. Missing initial prerequisites or checks not attempted after a stop are Not tested. A reported finding requires supporting evidence; generated text alone is insufficient.

A workflow that correctly identifies and records a deliberately vulnerable case can meet its evaluation criteria while the target violates its security rule. Specify whether any use of “success”, “pass” or “fail” describes workflow behaviour, execution or target security behaviour. The agreed matrix is a starting point for expected rules, not a complete account of possible abuse paths.

If the specification permits an isolated confirmation after a synthetic read disclosure, include a case that demonstrates its exact boundary and subsequent pause for the lead's decision. Also check that confirmation is refused when authentication, evidence capture or authority is uncertain. An unexpected write, real data or failed execution restriction still requires the specified stop and recovery process.

Record separately any consultant-led investigation already authorised by the engagement but outside the evaluated workflow. For example, a known-identifier disclosure through an authenticated export endpoint does not become a result of evaluating report-route checks. State what the investigation demonstrated and what remains untested, including identifier discoverability where relevant.

## Issues and readiness decision

For each issue, record [identifier, operational consequence, owner, correction, evidence needed for closure and current state]. One sentence per issue is enough if it makes the release consequence clear. Unresolved issues must remain visible.

**Decision:** [ready for the specified use / not ready for client use].

**Reason and boundaries:** [supported workflow behaviour, rejected claims, material gaps and uses excluded from the decision].

**Decision maker and date:** [ ].

**Required work before release:** [blocking issues and cases to repeat; link updated workflow/configuration].

**Re-evaluation triggers:** [application, matrix, workflow, authentication, tools, evidence capture, agent model/configuration changes or material failure].

**Version/recovery arrangement:** [previous version retained / cannot restore it; explain how reliance on earlier results is suspended and the replacement evaluated].

A small set of cases that meet the workflow's criteria cannot establish comprehensive assessment capability. Readiness applies only to the declared workflow, configuration, functions and conditions. The consultant separately decides whether further in-scope investigation is justified and limits client-report conclusions to what the evidence supports.