Security Finding Evidence Package Template twelve sections that turn a vulnerability finding into a developer-ready evidence packet the closure decision and the audit walkthrough both read against
A free, copy-ready evidence package template for AppSec leads, product security leads, security engineering leads, vulnerability management programme leads, GRC partners, internal security teams, and CISOs. Twelve structured sections covering document control and finding identification, calibrated finding context with CVSS 3.1 vector and source pipeline, affected asset binding for code findings and runtime findings, reproducible evidence with prerequisites and numbered steps and request-response or SAST trace, impact narrative in business language, fix expectations stated as verifiable claims, closure-evidence acceptance criteria per source pipeline, retest plan with verifier and environment and closure window, handoff acknowledgement with named engineering owner and target date, override scope for non-fix dispositions with the eight-field override decision chain, audit-evidence framework crosswalk, and known failure modes with structural fixes. Aligned with ISO/IEC 27001:2022 Annex A 8.8 and A.8.16 and Clause 9.1, SOC 2 CC4.1 and CC7.1 and CC7.2, PCI DSS 6.3.1 and 11.3 and 12.10, NIST SP 800-53 RA-5 and SI-2 and CA-7, NIST CSF 2.0 DE.AE and RS.AN and ID.RA, CIS Controls v8.1 Control 7, NIS2 Article 21, DORA Article 8 and Article 9, and HIPAA 164.308.
Run the evidence packet against the live finding record, not against a free-text writeup
SecPortal pairs the per-finding evidence packet to the finding record so the calibrated context, the asset binding, the reproduction artefacts, the fix expectations, the closure-evidence criteria, the retest plan, the override decision chain, and the audit-evidence framework crosswalk all live on one workspace with a named-actor activity log. Free plan available.
No credit card required. Free plan available forever.
Twelve sections that turn a vulnerability finding into a developer-ready evidence packet
A security finding evidence package is the per-finding artefact a security engineer attaches to a vulnerability before it leaves the security team for engineering remediation. It captures the calibrated context, the reproducible evidence, the affected asset binding, the fix expectations stated as verifiable claims, the closure-evidence acceptance criteria, and the retest plan on one record. The packet replaces the one-line ticket plus a screenshot with a structured record the developer can act on without rediscovering the work, and turns the closure decision from a hallway agreement into a record the audit walkthrough reads cleanly.
Copy the full evidence package template (all twelve sections) as one block.
1. Document control and finding identification
Open the evidence package with the finding identifier, the engagement reference, the named packager, and the publication timestamp. A reviewer should be able to read in the first lines which finding the packet describes, which engagement it belongs to, who packaged it, and when the current version was published. ISO/IEC 27001 Clause 7.5 expects documented information for the management system with controlled identification, format, and review; the document control header turns the per-finding evidence packet into a traceable artefact rather than a freeform writeup.
Finding identifier (the workspace finding record reference): {{FINDING_IDENTIFIER}}
Finding title (the short structured name the workspace search reads against): {{FINDING_TITLE}}
Finding-template identifier (the workspace finding template the packet adopts): {{FINDING_TEMPLATE_IDENTIFIER}}
Parent engagement reference (the engagement record the finding was opened against): {{ENGAGEMENT_REFERENCE}}
Programme reference (the chartered vulnerability management programme the engagement is bound to): {{PROGRAMME_REFERENCE}}
Packet version: {{PACKET_VERSION}}
Initial publication date: {{INITIAL_PUBLICATION_DATE}}
Current revision date: {{CURRENT_REVISION_DATE}}
Document classification (per the data classification policy): {{DOCUMENT_CLASSIFICATION}}
Retention period (per the audit evidence retention policy): {{RETENTION_PERIOD}}
Named packager (the security engineer or AppSec lead who triaged and packaged the finding):
- Role: {{PACKAGER_ROLE}}
- Named person at time of publication: {{PACKAGER_NAME}}
Named reviewer (the second reviewer who validated the packet before handoff, where the policy requires two-person review):
- Role: {{REVIEWER_ROLE}}
- Named person at time of review: {{REVIEWER_NAME}}
Named engineering owner (the engineer or team that will accept the packet and execute remediation):
- Role: {{ENGINEERING_OWNER_ROLE}}
- Named person at time of handoff: {{ENGINEERING_OWNER_NAME}}
- Engineering manager accountable for the owner queue: {{ENGINEERING_MANAGER_NAME}}
Named verifier (the security engineer who will run the retest against the closure-evidence acceptance criteria):
- Role: {{VERIFIER_ROLE}}
- Named person at time of handoff: {{VERIFIER_NAME}}
Revision history (each row carries: version, revision date, summary of change, revision trigger, named actor):
- v1.0 {{V1_REVISION_DATE}}: Initial packet published by {{V1_PACKAGER_NAME}}. Trigger: finding triaged for engineering handoff.
- v{{VN_VERSION}} {{VN_REVISION_DATE}}: {{VN_CHANGE_SUMMARY}}. Trigger: {{VN_TRIGGER}}. Named actor: {{VN_ACTOR}}.
Revision trigger that produced this version (one of: initial publication, severity recalibration against new threat intelligence, asset binding change, fix expectations refresh, closure-evidence criteria refinement, retest plan revision, override decision applied, audit-evidence framework crosswalk update):
- {{CURRENT_REVISION_TRIGGER}}
Workspace pairing:
- The packet is held as a versioned attachment on the finding record through document management.
- The named packager, reviewer, engineering owner, and verifier are workspace users captured under team management with role-based access control.
- The activity log captures each revision with named actor and timestamp.
2. Calibrated finding context
Calibrated context is the section that turns the finding from a one-line description into a structured record the developer can interpret without rediscovery. The calibration here is the difference between a CVSS line lifted from scanner output and the same finding read against environmental modifiers, source pipeline, and asset criticality. Capture the title, the severity band with the CVSS 3.1 vector, the source pipeline, the prior-cycle status, and the named asset owner inherited from the asset ownership map so the engineering owner reads the same calibration the security team uses.
Finding title (the same structured title carried in document control): {{FINDING_TITLE}}
Short description (one paragraph that explains the issue in plain language without scanner jargon): {{SHORT_DESCRIPTION}}
Severity band at detection (one of: critical, high, medium, low, informational): {{SEVERITY_AT_DETECTION}}
CVSS 3.1 vector at detection (frozen at the moment of detection): {{CVSS_VECTOR_AT_DETECTION}}
CVSS 3.1 base score at detection: {{CVSS_BASE_SCORE_AT_DETECTION}}
CVSS 3.1 environmental score at detection (after the workspace environmental modifiers): {{CVSS_ENVIRONMENTAL_SCORE_AT_DETECTION}}
EPSS at detection (where available, frozen at moment of detection): {{EPSS_AT_DETECTION}}
CISA KEV listing at detection (yes or no, with KEV date): {{KEV_FLAG_AT_DETECTION}}
Source pipeline (one of: external scanner, authenticated scanner, code scanner SAST, code scanner SCA, code scanner secret scanner, manual pentest, code review, threat-model output, bug bounty submission, customer disclosure, regulator notification, internal escalation):
- {{SOURCE_PIPELINE}}
Source pipeline detail (scanner module, manual test type, bug bounty programme name, or escalation source): {{SOURCE_PIPELINE_DETAIL}}
Source identifier (scanner finding identifier, pentest writeup section, bug bounty report identifier, or disclosure ticket reference): {{SOURCE_IDENTIFIER}}
Named asset owner at detection (inherited from the asset ownership map):
- Owner team: {{ASSET_OWNER_TEAM_AT_DETECTION}}
- Named individual: {{ASSET_OWNER_INDIVIDUAL_AT_DETECTION}}
- Business unit or product line: {{ASSET_BUSINESS_UNIT_AT_DETECTION}}
Workspace finding state at handoff (one of: new, triaged, accepted, in-progress, awaiting-fix, awaiting-retest):
- {{FINDING_STATE_AT_HANDOFF}}
Prior cycle history (where the finding has been detected in prior cycles, capture the prior-cycle reference):
- Prior cycle detection reference: {{PRIOR_CYCLE_REFERENCE}}
- Prior cycle disposition: {{PRIOR_CYCLE_DISPOSITION}}
- Prior cycle closure or override reference: {{PRIOR_CYCLE_CLOSURE_REFERENCE}}
Workspace pairing:
- Findings management captures the title, severity band, CVSS 3.1 vector, source pipeline, and named owner as structured fields.
- Activity log captures the calibrated context revisions with named actor and timestamp.
3. Affected asset binding
Asset binding is the section that puts the finding next to the asset the developer owns. For code findings the binding reads the repository connection, the file path, the line range, and the commit reference; for runtime findings the binding reads the verified domain, the URL or endpoint, the HTTP method, and the authenticated role used during testing. Without explicit binding the developer searches for the location of the issue, the routing primitive cannot evaluate ownership, and the retest cannot reproduce the conditions. The binding is the contract that says where in the estate the finding lives.
Asset class (one of: web application, web API, mobile application, infrastructure host, network device, container image, cloud configuration, code repository, dependency, secret in source, configuration file, document, identity, IaC template, Kubernetes workload):
- {{ASSET_CLASS}}
Code finding binding (fill where the asset class is code repository, dependency, secret in source, or IaC template):
- Repository connection (the GitHub, GitLab, or Bitbucket OAuth connection on the workspace): {{REPOSITORY_CONNECTION}}
- Repository identifier (owner and repository name): {{REPOSITORY_IDENTIFIER}}
- Branch reference: {{BRANCH_REFERENCE}}
- Commit reference (the commit the finding was opened against): {{COMMIT_REFERENCE}}
- File path (full path from repository root): {{FILE_PATH}}
- Line range (start line and end line, inclusive): {{LINE_RANGE}}
- Function or method signature where the issue lives: {{FUNCTION_SIGNATURE}}
- Dependency reference (where the asset class is dependency, capture the package name, the affected version, and the manifest file): {{DEPENDENCY_REFERENCE}}
- SAST or SCA trace reference (the analyzer rule identifier the finding fired against): {{SAST_OR_SCA_TRACE_REFERENCE}}
Runtime finding binding (fill where the asset class is web application, web API, mobile application, infrastructure host, network device, container image, cloud configuration, identity, or Kubernetes workload):
- Verified domain (the workspace verified domain the testing operated under): {{VERIFIED_DOMAIN}}
- URL or API endpoint (full path including query string where relevant): {{URL_OR_ENDPOINT}}
- HTTP method (where applicable): {{HTTP_METHOD}}
- Affected parameter or header (where the finding is parameter-bound): {{AFFECTED_PARAMETER}}
- Authenticated role used during testing (where authenticated scanning was used): {{AUTHENTICATED_ROLE}}
- Credential class used during testing (one of: bearer token, cookie session, basic auth, mTLS client certificate, API key, OAuth token, SAML assertion, NTLM session): {{CREDENTIAL_CLASS}}
- Environment (one of: production, staging, pre-production, development, test, isolated lab): {{TEST_ENVIRONMENT}}
- Infrastructure host reference (IP address or hostname, where the finding lives at the network or host layer): {{INFRASTRUCTURE_HOST_REFERENCE}}
- Cloud configuration reference (cloud account, region, resource type, resource identifier where applicable): {{CLOUD_CONFIGURATION_REFERENCE}}
Data sensitivity tier of the affected asset (per the data classification policy: tier 1 regulated, tier 2 confidential, tier 3 internal, tier 4 public): {{DATA_SENSITIVITY_TIER}}
Asset criticality tier of the affected asset (per the asset criticality scoring: tier 0 mission critical, tier 1 high, tier 2 medium, tier 3 low): {{ASSET_CRITICALITY_TIER}}
Workspace pairing:
- Findings management binds each finding to the engagement record and the asset reference.
- Repository connections capture the GitHub, GitLab, or Bitbucket OAuth binding so the file-path-and-line-range read resolves to the code.
- Authenticated scanning captures the credential class and the authenticated role under encrypted credential storage; code scanning binds the SAST or SCA trace to the repository connection.
4. Reproducible evidence
Reproducible evidence is the section that lets the developer rerun the finding without asking the security team to demonstrate it again. Capture the steps in the order a developer can replay, the request and response pair or the SAST trace as the static evidence, the supporting screenshot or video that confirms the behaviour, and the environmental conditions the reproduction depends on. Without reproducible evidence the developer reproduces the finding from scratch and the retest reads against a moving target rather than against the original reproduction.
Reproduction prerequisites (the conditions that must be true before the reproduction runs):
- Required authenticated user role (where the finding is behind authentication): {{REPRO_REQUIRED_ROLE}}
- Required dataset state (where the finding depends on specific data in the system): {{REPRO_REQUIRED_DATASET}}
- Required configuration state (where the finding depends on specific configuration): {{REPRO_REQUIRED_CONFIGURATION}}
- Required network position (internal network, external network, VPN, specific egress source): {{REPRO_REQUIRED_NETWORK_POSITION}}
- Required browser, client, or tool version (where the finding is client-dependent): {{REPRO_REQUIRED_CLIENT}}
Reproduction steps (numbered, in the order a developer can replay):
- Step 1: {{REPRO_STEP_1}}
- Step 2: {{REPRO_STEP_2}}
- Step 3: {{REPRO_STEP_3}}
- Step 4: {{REPRO_STEP_4}}
- Step 5: {{REPRO_STEP_5}}
- Step N (continue as needed): {{REPRO_STEP_N}}
Request and response evidence (for runtime findings, capture the full HTTP request the security engineer issued and the response the application returned):
- Request:
{{REPRO_REQUEST}}
- Response (status code, response headers, and response body excerpt):
{{REPRO_RESPONSE}}
SAST or SCA trace evidence (for code findings, capture the analyzer rule identifier, the analyzer output excerpt, and the call graph or data flow path that produced the finding):
- Analyzer: {{REPRO_ANALYZER_NAME}}
- Rule identifier: {{REPRO_ANALYZER_RULE_IDENTIFIER}}
- Analyzer output excerpt: {{REPRO_ANALYZER_OUTPUT_EXCERPT}}
- Call graph or data flow path: {{REPRO_CALL_GRAPH}}
Supporting media (the screenshot or video that confirms the behaviour, attached to the workspace finding through document management):
- Media identifier: {{REPRO_MEDIA_IDENTIFIER}}
- Media description: {{REPRO_MEDIA_DESCRIPTION}}
Negative reproduction (the cases where the reproduction does not fire, to confirm the failure is bounded and not random):
- Negative case 1 (input or condition that does not trigger the finding): {{REPRO_NEGATIVE_CASE_1}}
- Negative case 2: {{REPRO_NEGATIVE_CASE_2}}
Workspace pairing:
- Document management holds the reproduction artefacts as versioned attachments on the finding record.
- Activity log captures the reproduction-evidence revision chain with named actor and timestamp.
5. Impact narrative
Impact narrative is the business-language section the engineering owner reads to understand why the finding matters to the organisation rather than to the scanner that produced it. Capture the risk in plain language, the data class exposed, the affected user roles, and the realised-versus-theoretical distinction so the engineering manager and the product owner can read the same impact statement the security team reads. Without an impact narrative the engineering queue ranks the finding by severity band alone and reads the work as scanner output rather than as business risk.
One-paragraph plain-language risk statement (what an attacker who exploits this finding can do, written so the engineering owner and product owner can read it without security vocabulary):
- {{IMPACT_RISK_STATEMENT}}
Data class exposed (the categories of data the finding can put at risk, per the data classification policy):
- Primary data class: {{IMPACT_PRIMARY_DATA_CLASS}}
- Secondary data classes: {{IMPACT_SECONDARY_DATA_CLASSES}}
Affected user roles (the role classes whose accounts or data can be affected):
- Affected user roles: {{IMPACT_AFFECTED_USER_ROLES}}
Realised versus theoretical distinction (capture whether the security team observed the impact, whether the impact is plausible from the reproduction, or whether the impact is the standard theoretical risk of the vulnerability class):
- Realised impact observation: {{IMPACT_REALISED_OBSERVATION}}
- Plausibility statement: {{IMPACT_PLAUSIBILITY_STATEMENT}}
Pre-exploitation conditions (the conditions an attacker would need to satisfy to exploit the finding):
- Authentication requirement: {{IMPACT_AUTH_REQUIREMENT}}
- Network position requirement: {{IMPACT_NETWORK_POSITION_REQUIREMENT}}
- Prior compromise requirement: {{IMPACT_PRIOR_COMPROMISE_REQUIREMENT}}
- User interaction requirement: {{IMPACT_USER_INTERACTION_REQUIREMENT}}
Business context (where the affected asset sits in the business operating model):
- Business process the asset supports: {{IMPACT_BUSINESS_PROCESS}}
- Customer-facing or internal-only: {{IMPACT_CUSTOMER_FACING}}
- Regulatory framework anchoring (where the asset is in scope of a specific regulatory expectation): {{IMPACT_REGULATORY_FRAMEWORK}}
Workspace pairing:
- Findings management captures the impact statement on the finding record so the leadership read and the engineering read share one source.
- AI reports drafts the executive-narrative section of per-engagement reports against the impact statements of the engaged findings.
6. Fix expectations as verifiable claims
Fix expectations stated as verifiable claims replace generic remediation recommendations with explicit statements of the change the developer is expected to make and the rationale anchored in the secure-baseline policy. Without verifiable claims the developer guesses what counts as a fix, the closure decision reads against the security engineer who happens to be on call, and the retest evaluates the engineers intent rather than the evidence the security team committed to read. Verifiable claims make the closure decision deterministic.
Primary recommended fix (the single named change the security team recommends as the primary remediation, written as a verifiable claim the retest can read against):
- Verifiable claim: {{FIX_PRIMARY_VERIFIABLE_CLAIM}}
- Rationale anchored in the secure-baseline policy or the framework citation: {{FIX_PRIMARY_RATIONALE}}
- Estimated effort band (one of: under one hour, under one day, under one week, multi-week, programme-level change): {{FIX_PRIMARY_EFFORT_BAND}}
Alternative remediation options (where there are credible alternative remediations the developer can choose between, capture them so the engineering decision is informed rather than forced):
- Alternative 1: {{FIX_ALTERNATIVE_1_CLAIM}}
Rationale: {{FIX_ALTERNATIVE_1_RATIONALE}}
- Alternative 2: {{FIX_ALTERNATIVE_2_CLAIM}}
Rationale: {{FIX_ALTERNATIVE_2_RATIONALE}}
Compensating control option (where a code or configuration fix is not feasible within the SLA window, capture the compensating control the security team would accept under a documented exception):
- Compensating control: {{FIX_COMPENSATING_CONTROL_CLAIM}}
- Rationale: {{FIX_COMPENSATING_CONTROL_RATIONALE}}
- Expected expiry: {{FIX_COMPENSATING_CONTROL_EXPIRY}}
Explicit do-not-do list (the remediation patterns the security team will not accept as a fix, captured to prevent the developer from spending time on a fix that will be rejected at retest):
- Do not item 1: {{FIX_DO_NOT_DO_1}}
- Do not item 2: {{FIX_DO_NOT_DO_2}}
- Do not item 3: {{FIX_DO_NOT_DO_3}}
Vendor patch context (where the finding is in a dependency or a vendor product, capture the upstream advisory and the available patch):
- Vendor advisory reference: {{FIX_VENDOR_ADVISORY_REFERENCE}}
- Available fixed version: {{FIX_VENDOR_FIXED_VERSION}}
- Vendor patch release date: {{FIX_VENDOR_PATCH_RELEASE_DATE}}
Workspace pairing:
- Findings management holds the fix expectations as structured fields on the finding record.
- The activity log captures revisions to fix expectations with named actor and timestamp so the engineering team can read the calibration history.
7. Closure-evidence acceptance criteria
Closure-evidence acceptance criteria are the contract the retest reads against. The developer reads them at handoff so the fix they submit is the fix the security team will accept; the verifier reads them at retest so the closure decision is deterministic rather than discretionary. Capture the evidence types the security team will accept, the rejection criteria, and the per-source-pipeline closure-evidence shape so the developer is not asked to assemble new evidence at the retest moment.
Accepted closure-evidence types (one or more of the following; capture which ones apply to this finding):
- Pull request reference (the merged pull request that contains the fix): {{CLOSURE_PR_REFERENCE_ACCEPTED}}
- SAST re-run output (the analyzer no longer fires on the affected file path and line range): {{CLOSURE_SAST_ACCEPTED}}
- SCA re-run output (the dependency manifest reflects the fixed version and the SCA analyzer no longer reports the advisory): {{CLOSURE_SCA_ACCEPTED}}
- Dependency manifest delta (the manifest change that upgrades the vulnerable dependency): {{CLOSURE_DEPENDENCY_DELTA_ACCEPTED}}
- Configuration diff (the configuration value change that closes the finding): {{CLOSURE_CONFIGURATION_DIFF_ACCEPTED}}
- Unit test that proves the new behaviour (a unit test exercising the previously vulnerable path that fails on the unfixed code and passes on the fixed code): {{CLOSURE_UNIT_TEST_ACCEPTED}}
- Manual reproduction failure (the original reproduction steps no longer produce the vulnerable response under the original reproduction conditions): {{CLOSURE_MANUAL_REPRO_FAILURE_ACCEPTED}}
- Authenticated re-scan against the original verified domain (the authenticated scanner re-run no longer reports the finding): {{CLOSURE_AUTHENTICATED_RESCAN_ACCEPTED}}
- External re-scan against the original verified domain: {{CLOSURE_EXTERNAL_RESCAN_ACCEPTED}}
Closure-evidence per source pipeline (capture which evidence shape this finding's source pipeline maps to, so the developer is not asked to assemble evidence the pipeline does not produce):
- For external scanner findings: {{CLOSURE_EVIDENCE_FOR_EXTERNAL_SCANNER}}
- For authenticated scanner findings: {{CLOSURE_EVIDENCE_FOR_AUTHENTICATED_SCANNER}}
- For code scanner SAST findings: {{CLOSURE_EVIDENCE_FOR_SAST}}
- For code scanner SCA findings: {{CLOSURE_EVIDENCE_FOR_SCA}}
- For code scanner secret-scanner findings: {{CLOSURE_EVIDENCE_FOR_SECRET_SCANNER}}
- For manual pentest findings: {{CLOSURE_EVIDENCE_FOR_MANUAL_PENTEST}}
- For bug bounty submissions: {{CLOSURE_EVIDENCE_FOR_BUG_BOUNTY}}
Rejection criteria (the closure submissions the security team will not accept, captured explicitly so the engineering submission is the right shape on first attempt):
- Rejection criterion 1: {{CLOSURE_REJECTION_1}}
- Rejection criterion 2: {{CLOSURE_REJECTION_2}}
- Rejection criterion 3: {{CLOSURE_REJECTION_3}}
Closure approval authority (who is named to make the closure decision against the closure-evidence):
- Primary verifier role: {{CLOSURE_PRIMARY_VERIFIER_ROLE}}
- Secondary verifier role (where two-person verification is required by the policy): {{CLOSURE_SECONDARY_VERIFIER_ROLE}}
Workspace pairing:
- Findings management carries the closure-evidence criteria as structured fields on the finding record.
- Document management holds the engineering-side closure-evidence as versioned attachments at the retest moment.
- The activity log captures the closure decision with named verifier, prior state, new state, and timestamp.
8. Retest plan
The retest plan names the verifier, the retest method, the retest environment, the closure window, and the contingency path if the retest produces a regression. Without an explicit retest plan the retest happens whenever the security engineer remembers, runs against a different environment than the original detection, and reads against unwritten closure criteria. The retest plan turns verification from an ad-hoc event into a paired transaction with the original finding.
Retest method (one of: re-run the original reproduction steps, automated retest via scheduled scan, manual verification by the named verifier, fresh authenticated test against the original verified domain, code-level review of the merged pull request, dependency manifest review of the merged pull request):
- {{RETEST_METHOD}}
Named verifier (the security engineer accountable for running the retest):
- Role: {{RETEST_VERIFIER_ROLE}}
- Named individual at time of handoff: {{RETEST_VERIFIER_NAME}}
Retest environment (the environment the retest must run against, matched against the original detection environment where possible):
- {{RETEST_ENVIRONMENT}}
Retest conditions (the conditions under which the retest produces a valid result):
- Authenticated user role: {{RETEST_AUTHENTICATED_ROLE}}
- Credential class: {{RETEST_CREDENTIAL_CLASS}}
- Dataset state: {{RETEST_DATASET_STATE}}
- Configuration state: {{RETEST_CONFIGURATION_STATE}}
- Network position: {{RETEST_NETWORK_POSITION}}
Closure window (the elapsed time inside which the retest must run after the engineering owner submits the closure-evidence, anchored to the vulnerability remediation SLA policy):
- {{CLOSURE_WINDOW}}
Retest result classification (one of: verified-fixed, verified-not-fixed, fixed-with-residual-risk, false-positive-on-retest, evidence-insufficient):
- {{RETEST_RESULT_CLASSIFICATION_FIELD}}
Regression-on-retest path (where the retest finds the issue is not fixed, capture the reopen-versus-new-record decision rule):
- Reopen rule: {{RETEST_REGRESSION_REOPEN_RULE}}
- Severity recalibration: {{RETEST_REGRESSION_SEVERITY_RECALIBRATION}}
- New SLA clock behaviour (continued from original or reset on regression): {{RETEST_REGRESSION_SLA_CLOCK_RULE}}
Workspace pairing:
- Retesting workflows pair each retest record to the original finding so the lineage from open through verified-fixed lives on one record.
- The activity log captures the retest event with named verifier, retest result, and timestamp.
- Findings management holds the closure or reopen state transition.
9. Handoff acknowledgement
The handoff acknowledgement section captures the moment the packet leaves the security team and enters the engineering queue as a named owner with an acknowledged target date. Without an explicit acknowledgement the handoff lives in a Slack message or an email thread and the activity log reads silent on the most consequential lifecycle transition the finding has. The acknowledgement is the signed transition the audit reads as the named-owner moment.
Handoff date and time (the workspace timestamp when the packet was published to the engineering owner):
- {{HANDOFF_DATETIME}}
Handoff channel (one of: workspace assignment notification, client portal share, engagement record state transition, scheduled handoff meeting, ad-hoc meeting):
- {{HANDOFF_CHANNEL}}
Engineering owner acknowledgement (capture the explicit accept-the-packet acknowledgement from the named engineering owner):
- Acknowledgement timestamp: {{ENG_OWNER_ACK_TIMESTAMP}}
- Acknowledged by (named individual): {{ENG_OWNER_ACK_INDIVIDUAL}}
- Acknowledged target date for closure-evidence submission: {{ENG_OWNER_ACK_TARGET_DATE}}
- Acknowledged with caveats (where the engineering owner is accepting the packet with caveats on the asset binding, the fix expectations, or the closure-evidence criteria): {{ENG_OWNER_ACK_CAVEATS}}
Engineering manager visibility (the engineering manager accountable for the owner queue is on notice when the packet lands):
- Engineering manager named individual: {{ENG_MANAGER_INDIVIDUAL}}
- Engineering manager notification timestamp: {{ENG_MANAGER_NOTIFICATION_TIMESTAMP}}
Rejection path (where the engineering owner rejects the packet, capture the rejection cause code and the routing back to the security team for repackaging):
- Rejection cause (one of: asset binding wrong owner, asset binding stale, fix expectations infeasible, closure-evidence criteria infeasible, severity disputed, calibrated-context insufficient, evidence not reproducible, scope outside engineering ownership):
{{REJECTION_CAUSE}}
- Rejection rationale: {{REJECTION_RATIONALE}}
- Re-route owner (the security engineer who will repackage and re-handoff): {{REJECTION_REROUTE_OWNER}}
SLA clock behaviour at handoff (where the vulnerability remediation SLA policy starts the clock at the calibrated handoff event versus at the detection event, capture which one applies):
- SLA clock start: {{SLA_CLOCK_START_REFERENCE}}
- SLA acknowledgement window (within which the engineering owner must acknowledge): {{SLA_ACKNOWLEDGEMENT_WINDOW}}
- SLA remediation window (within which the closure-evidence must arrive): {{SLA_REMEDIATION_WINDOW}}
Workspace pairing:
- Findings management captures the assignment state transition with named owner.
- Notifications and alerts push the assignment event to the named owner; the acknowledgement-rejection signal is observable in the lifecycle log.
- The activity log captures the handoff event with named actor, prior state, new state, and timestamp.
10. Override scope for non-fix dispositions
Override scope is the section the packet uses when the finding will not be remediated through a fix and verified retest, but through accepted risk, deferral, false-positive, or severity-downgrade disposition. The override block is the eight-field decision chain that gives the disposition explicit authority, rationale, scope, expiry, and renewal cadence rather than letting the finding sit in an open state with no decision attached. The override scope is what turns a non-fix outcome from silent staleness into a documented decision the exception register and the audit walkthrough read.
Override applies to this packet (yes or no):
- {{OVERRIDE_APPLIES}}
Override class (one of: accepted-risk, deferral, false-positive, severity-downgrade, compensating-control, scope-removal):
- {{OVERRIDE_CLASS}}
Eight-field override decision chain (fill where override applies):
- Named approver (the role and individual authorised to grant the override per the chartered decision authority): {{OVERRIDE_APPROVER}}
- Named compensating control (where the override is a deferral or accepted risk, the control that reduces the residual risk in the interim): {{OVERRIDE_COMPENSATING_CONTROL}}
- Named expiry (the date after which the override is no longer valid and the finding returns to the live queue): {{OVERRIDE_EXPIRY}}
- Named renewal cadence (the review cadence under which the override is re-evaluated before expiry): {{OVERRIDE_RENEWAL_CADENCE}}
- Named residual risk owner (the role and individual who carries the residual risk on the workspace risk register): {{OVERRIDE_RESIDUAL_RISK_OWNER}}
- Named scope (the bounded scope the override applies to, captured so the override does not silently expand to neighbouring findings): {{OVERRIDE_SCOPE}}
- Named justification (the rationale captured against the security exception register policy and the framework crosswalk): {{OVERRIDE_JUSTIFICATION}}
- Named evidence-of-acceptance (the artefact that demonstrates the override was reviewed and accepted by the named approver, including a meeting reference or a signed approval record): {{OVERRIDE_EVIDENCE_OF_ACCEPTANCE}}
False-positive disposition detail (fill where the override class is false-positive):
- Reproduction failure mode: {{FALSE_POSITIVE_REPRO_FAILURE_MODE}}
- Workspace-wide suppression update (the intake suppression rule the false-positive disposition produced so the pattern does not return on the next scan cycle): {{FALSE_POSITIVE_SUPPRESSION_UPDATE}}
Severity-downgrade disposition detail (fill where the override class is severity-downgrade):
- Original severity band and CVSS vector: {{SEVERITY_DOWNGRADE_ORIGINAL_VECTOR}}
- New severity band and CVSS vector: {{SEVERITY_DOWNGRADE_NEW_VECTOR}}
- Calibration rationale (the environmental modifiers or context that warrants the downgrade): {{SEVERITY_DOWNGRADE_RATIONALE}}
Workspace pairing:
- Finding overrides captures the eight-field override decision chain on the finding record.
- The security exception register holds the cross-finding view of the overrides for programme-level reporting.
- The activity log captures the override event with named actor, prior state, new state, and timestamp.
- Compliance tracking pairs the override class to the relevant framework controls.
11. Audit-evidence framework crosswalk
The audit-evidence framework crosswalk maps the packet to the controls that read against it during an audit walkthrough. The crosswalk is the section the GRC partner reads to know which control the packet evidences and which evidence it supplies; it is the section the audit walkthrough reads to reconstruct the closure chain. Without an explicit crosswalk the audit reads the packet as a free-text writeup and the framework citation becomes a hallway conversation between security and GRC.
ISO 27001:2022 control citations:
- Annex A 8.8 management of technical vulnerabilities: {{ISO_27001_A_8_8_EVIDENCE}}
- Annex A 8.16 monitoring activities: {{ISO_27001_A_8_16_EVIDENCE}}
- Clause 9.1 monitoring, measurement, analysis and evaluation: {{ISO_27001_CLAUSE_9_1_EVIDENCE}}
SOC 2 Trust Services Criteria citations:
- CC4.1 monitoring of controls: {{SOC_2_CC4_1_EVIDENCE}}
- CC7.1 detection and monitoring of unauthorised activities: {{SOC_2_CC7_1_EVIDENCE}}
- CC7.2 system monitoring against thresholds: {{SOC_2_CC7_2_EVIDENCE}}
PCI DSS v4 control citations:
- Requirement 6.3.1 security vulnerabilities are identified and managed: {{PCI_DSS_6_3_1_EVIDENCE}}
- Requirement 11.3 external and internal vulnerabilities are regularly identified, prioritised, and addressed: {{PCI_DSS_11_3_EVIDENCE}}
- Requirement 12.10 incidents are responded to immediately: {{PCI_DSS_12_10_EVIDENCE}}
NIST SP 800-53 Rev 5 control citations:
- RA-5 vulnerability monitoring and scanning: {{NIST_800_53_RA_5_EVIDENCE}}
- SI-2 flaw remediation: {{NIST_800_53_SI_2_EVIDENCE}}
- CA-7 continuous monitoring: {{NIST_800_53_CA_7_EVIDENCE}}
NIST CSF 2.0 control citations:
- DE.AE security continuous monitoring: {{NIST_CSF_DE_AE_EVIDENCE}}
- RS.AN response analysis: {{NIST_CSF_RS_AN_EVIDENCE}}
- ID.RA risk assessment: {{NIST_CSF_ID_RA_EVIDENCE}}
CIS Controls v8.1 citation:
- Control 7 continuous vulnerability management: {{CIS_CONTROL_7_EVIDENCE}}
EU regulatory framework citations:
- NIS2 Article 21 cybersecurity risk management measures: {{NIS2_ARTICLE_21_EVIDENCE}}
- DORA Article 8 ICT risk management framework: {{DORA_ARTICLE_8_EVIDENCE}}
- DORA Article 9 management of ICT-related incidents and vulnerabilities: {{DORA_ARTICLE_9_EVIDENCE}}
HIPAA Security Rule citation (where the affected asset is in scope of HIPAA):
- 164.308(a)(1)(ii)(B) risk management: {{HIPAA_164_308_EVIDENCE}}
Workspace pairing:
- Compliance tracking pairs the finding record to the cited framework controls so the audit walkthrough reads against the same crosswalk the workspace operating record uses.
- AI reports drafts the per-engagement audit-evidence narrative from the cited framework controls and the per-finding closure chronology.
12. Known failure modes and structural fixes
Evidence packages fail the closure read in recognisable patterns. Each failure has a structural fix that the template above is designed to enforce. Read this list before customising the template so the customisation does not weaken the discipline that makes the packet defensible across engineering, security, GRC, and audit reads.
Failure mode 1: Packet ships as a CVSS line plus a screenshot.
- Symptom: Developer spends two days reproducing the finding before remediation starts; the security team is asked to clarify scope; the closure decision is discretionary because the closure criteria were never written.
- Structural fix: Sections 2 through 7 capture calibrated context, asset binding, reproducible evidence, impact narrative, fix expectations as verifiable claims, and closure-evidence acceptance criteria so the packet leaves the security team complete.
Failure mode 2: Asset binding is generic and the developer cannot locate the issue.
- Symptom: The finding says the asset is the application or the API without naming the file path, URL, or endpoint; the developer searches for the location; the routing primitive cannot evaluate ownership; the retest cannot reproduce the conditions.
- Structural fix: Section 3 carries a parallel code-finding and runtime-finding binding so the developer reads the finding next to the code or next to the live behaviour with the repository connection or verified domain explicit.
Failure mode 3: Reproduction is non-deterministic.
- Symptom: The reproduction works on the security engineers laptop and not on the developers laptop; the retest reads against a moving target; the closure decision drifts between verifiers.
- Structural fix: Section 4 captures reproduction prerequisites, numbered steps, request and response or SAST trace, and supporting media, plus negative reproduction cases so the failure is bounded.
Failure mode 4: Fix expectations are written as generic recommendations.
- Symptom: The packet says use prepared statements or validate input without naming the change the developer is expected to make; the engineering submission is rejected at retest; the fix expectations drift between cycles.
- Structural fix: Section 6 names the primary fix as a verifiable claim, captures alternative remediations, and lists explicit do-not-do items so the closure decision is deterministic.
Failure mode 5: Closure-evidence criteria are written after the engineering submission arrives.
- Symptom: The retest reads against unwritten closure criteria; the security engineer who happens to be on call decides whether the evidence is sufficient; the closure decision is discretionary and the audit walkthrough finds no contract.
- Structural fix: Section 7 captures the accepted closure-evidence types per source pipeline and the explicit rejection criteria before the packet leaves the security team.
Failure mode 6: Retest runs against a different environment than the original detection.
- Symptom: The retest is run against staging when the original detection was against production; the issue does not reproduce in staging and the finding closes; the issue persists in production.
- Structural fix: Section 8 names the retest environment, the retest conditions including authenticated role and credential class, and the retest method anchored to the original detection conditions.
Failure mode 7: Handoff is a Slack message and the activity log reads silent on the most consequential transition.
- Symptom: The packet leaves the security team in a chat thread; the named owner is whoever was on the chat; the engineering manager has no visibility; the activity log shows no assignment event.
- Structural fix: Section 9 captures the handoff datetime, the channel, the engineering owner acknowledgement with named individual and target date, the engineering manager visibility, and the rejection path with cause codes.
Failure mode 8: Override decisions live in chat threads instead of on the finding record.
- Symptom: A finding is silently deferred or marked false-positive in a meeting; the exception register reads incomplete; the audit walkthrough finds open findings with implicit decisions attached.
- Structural fix: Section 10 names the eight-field override decision chain (named approver, compensating control, expiry, renewal cadence, residual risk owner, scope, justification, evidence-of-acceptance) and ties it to the security exception register through finding overrides.
Failure mode 9: Audit walkthrough reconstructs the framework citation from memory.
- Symptom: The GRC partner reads the finding record and constructs the framework citation in conversation with the security team during fieldwork; the audit citation is rebuilt every cycle from chat history.
- Structural fix: Section 11 captures the audit-evidence framework crosswalk on the packet at publication time and pairs each control citation to the named evidence so the walkthrough reads from the workspace record without manual reconstruction.
Failure mode 10: Packet is treated as a one-shot writeup and revisions are silent.
- Symptom: The packet is published once at handoff; severity recalibration, asset binding changes, and fix-expectation revisions do not update the packet; the audit walkthrough reads against the original packet and the current finding state simultaneously.
- Structural fix: Section 1 captures the revision history and the revision trigger, the activity log captures each revision with named actor and timestamp, and the per-cycle review reads the packets whose calibration has drifted from the current finding state.
Eight failure modes the template is designed against
Evidence packages fail the closure read in recognisable patterns. Each failure has a structural fix the template above is designed to enforce. Read this list before customising the template so the customisation does not weaken the discipline that makes the packet defensible across engineering, security, GRC, and audit reads.
Packet ships as a CVSS line plus a screenshot
A finding pushed to engineering as a one-line description, a CVSS number, and a screenshot costs the developer two days of rediscovery before remediation starts. The closure decision becomes discretionary because the closure criteria were never written. The fix is Sections 2 through 7, which capture calibrated context, asset binding, reproducible evidence, impact narrative, fix expectations as verifiable claims, and closure-evidence acceptance criteria so the packet leaves the security team complete.
Asset binding is generic and the developer cannot locate the issue
The finding says the asset is the application or the API without naming the file path, URL, or endpoint. The developer searches for the location, the routing primitive cannot evaluate ownership, and the retest cannot reproduce the conditions. The fix is Section 3, which carries a parallel code-finding and runtime-finding binding so the developer reads the finding next to the code or next to the live behaviour with the repository connection or verified domain explicit.
Reproduction is non-deterministic and the retest drifts
The reproduction works on the security engineers laptop and not on the developers laptop. The retest reads against a moving target and the closure decision drifts between verifiers. The fix is Section 4, which captures reproduction prerequisites, numbered steps, request and response or SAST trace, supporting media, and negative reproduction cases so the failure is bounded.
Fix expectations are written as generic recommendations
The packet says use prepared statements or validate input without naming the change the developer is expected to make. The engineering submission is rejected at retest. The fix is Section 6, which names the primary fix as a verifiable claim, captures alternative remediations, and lists explicit do-not-do items so the closure decision is deterministic.
Closure-evidence criteria are written after the submission arrives
The retest reads against unwritten closure criteria. The security engineer who happens to be on call decides whether the evidence is sufficient. The fix is Section 7, which captures the accepted closure-evidence types per source pipeline and the explicit rejection criteria before the packet leaves the security team.
Retest runs against a different environment than the original detection
The retest is run against staging when the original detection was against production. The issue does not reproduce in staging and the finding closes, but persists in production. The fix is Section 8, which names the retest environment, the retest conditions including authenticated role and credential class, and the retest method anchored to the original detection conditions.
Handoff lives in a chat thread and the activity log reads silent
The packet leaves the security team in a chat message; the named owner is whoever was on the chat; the engineering manager has no visibility; the activity log shows no assignment event. The fix is Section 9, which captures the handoff datetime, the channel, the engineering owner acknowledgement with named individual and target date, the engineering manager visibility, and the rejection path with cause codes.
Override decisions live in chat threads instead of on the finding record
A finding is silently deferred or marked false-positive in a meeting. The exception register reads incomplete and the audit walkthrough finds open findings with implicit decisions attached. The fix is Section 10, which names the eight-field override decision chain and ties it to the security exception register through finding overrides.
Ten questions a per-cycle review of evidence packet quality has to answer
Run these ten questions at every per-cycle review of evidence packet quality (weekly for high-volume programmes, biweekly for mid-volume, monthly for steering) and capture the answers on the activity log so the per-cycle drift is visible to the AppSec lead, the head of vulnerability management, the security engineering lead, and the engineering counterpart at the next review.
1.What share of findings handed off in the cycle shipped with a complete packet (all twelve sections populated) versus a partial packet, and how does the share move against the prior cycle.
2.What share of engineering rejections at handoff were caused by asset binding errors versus calibrated-context insufficiency versus fix-expectations infeasibility versus evidence not reproducible, and which root cause is the largest contributor.
3.What share of retests in the cycle accepted the engineering closure-evidence on first submission versus required additional evidence rounds, and how does the share move against the prior cycle.
4.What share of closure-evidence rounds were rejected because the evidence did not match the criteria captured in Section 7, and how many of those rejections were preventable by tightening the criteria at packet publication time.
5.How many findings in the cycle had their reproduction marked non-deterministic at retest, and which source pipelines produce the highest non-determinism rate.
6.How many handoffs in the cycle were acknowledged by the named engineering owner within the acknowledgement window captured in Section 9, and how many drifted into the half-window or full-window escalation chain.
7.How many findings in the cycle moved to override scope (accepted-risk, deferral, false-positive, severity-downgrade, compensating-control, scope-removal) versus fix-and-verify, and how does the mix compare against the prior cycle and the policy expectation.
8.How many packets were revised mid-lifecycle, by revision trigger (severity recalibration, asset binding change, fix expectations refresh, closure-evidence criteria refinement, retest plan revision, override decision applied, framework crosswalk update), and how often did the revision change the engineering-side commitment.
9.How many engineering rejections at handoff cited scope-outside-engineering-ownership as the cause, and what does that suggest about the asset ownership map freshness or the routing rule library accuracy.
10.How many closed findings in the cycle had a complete audit-evidence framework crosswalk in Section 11 at the moment of closure, and which controls were most often left blank.
How the template pairs with SecPortal as a workspace operating record
The template above is copy-ready as a standalone artefact for security teams that operate without a dedicated workspace. If the security team already runs finding tracking, document storage, exception management, and framework evidence packaging on a workspace, the template becomes the per-finding evidence layer of the platform rather than a separate document. SecPortal carries the calibrated context section as structured fields on findings management (title, severity band, CVSS 3.1 vector, source pipeline, finding-template identifier, named owner). The engagement management feature binds each packet to its originating engagement so the engagement reference and the per-engagement narrative are reproducible.
The affected asset binding section maps to the workspace through repository connections (GitHub, GitLab, or Bitbucket OAuth) for code findings, capturing the repository identifier, branch, commit, file path, and line range. For runtime findings the binding maps to the verified domain through domain verification and to the credential class through authenticated scanning with encrypted credential storage holding the AES-256-GCM-protected credential lifecycle. For code findings, the SAST or SCA trace reference maps through code scanning.
The reproducible evidence section lives as versioned attachments under document management so the request and response pair, the SAST trace excerpt, the supporting screenshot or video, and the negative reproduction cases sit on the same record as the finding. The fix expectations and closure-evidence acceptance criteria sit on the finding record as the contract the retest reads against. The retest plan section maps to retesting workflows that pair each retest to the original finding so the lineage from open through verified-fixed runs on one record. The handoff acknowledgement event is a state transition the activity log with CSV export captures with named actor and timestamp at 30, 90, or 365 day retention depending on plan, supplying the per-cycle review with the assignment chronology and the acknowledgement-window distribution.
The override scope section maps to finding overrides where the eight-field exception decision chain (named approver, named compensating control, named expiry, named renewal cadence, named residual risk owner, named scope, named justification, named evidence-of-acceptance) is recorded for accept-risk, defer, false-positive, and severity-downgrade dispositions. Team management with role-based access control supplies the workspace user catalogue (owner, admin, member, viewer, billing roles) that the named packager, reviewer, engineering owner, and verifier reference, with the role gate applied to publish and approve access. Multi-factor authentication on the workspace provides authentication assurance on the named-actor fields the audit citation reads against. Notifications and alerts push the assignment event to the named engineering owner and the engineering manager so the acknowledgement-rejection signal is observable in the lifecycle log. Compliance tracking pairs the packet to the cited framework controls in Section 11 (ISO 27001 A.8.8 and A.8.16 and Clause 9.1, SOC 2 CC4.1 and CC7.1 and CC7.2, PCI DSS 6.3.1 and 11.3 and 12.10, NIST 800-53 RA-5 and SI-2 and CA-7, NIST CSF 2.0 DE.AE and RS.AN and ID.RA, CIS Controls v8.1 Control 7, NIS2 Article 21, DORA Article 8 and Article 9, HIPAA 164.308).
The AI reports workflow drafts the per-engagement executive narrative, the per-finding closure chronology, and the audit-evidence framework crosswalk summary from the live workspace record so the leadership view, the developer-facing read, and the audit lookback all read against the same source. The client portal serves the developer-facing read of the packet when the engineering owner is in a different organisation (white-labelled on the tenant subdomain through tenant subdomain isolation). Bulk finding import normalises Nessus, Burp, OWASP ZAP, Semgrep, SCA, and CSV scanner output against the workspace finding template library so imported findings land in canonical shape before packet generation begins.
Honest scope: SecPortal does not ship native Jira, ServiceNow, Slack, Microsoft Teams, PagerDuty, SIEM, SOAR, or GRC platform integrations, does not ship SSO, SCIM, or SAML, does not provide asset inventory or CMDB sync, does not auto-generate the closure-evidence from a pull request, does not validate that the engineer assigned to a finding is the right owner, does not enforce a packet completeness threshold at handoff, and does not provide customer-logo or ROI or adoption-metric or compliance-guarantee claims. The packet design, approval, and closure decisions belong to the security organisation operating the discipline; the workspace keeps the per-finding evidence trail, the activity log, and the override register on one record so the closure question is reproducible at any moment between cycles.
GRC and compliance teams and internal audit teams read Section 11 as the audit-evidence framework crosswalk that maps the packet to ISO 27001 A.8.8 and Clause 9.1, SOC 2 CC4.1 and CC7.1, PCI DSS 6.3.1 and 12.10, NIST 800-53 RA-5 and SI-2, NIST CSF 2.0 DE.AE and RS.AN, CIS Controls v8.1 Control 7, NIS2 Article 21, DORA Article 8 and 9, and HIPAA 164.308. Pair the template with the audit fieldwork evidence request fulfilment use case.
Engineering owners and engineering managers
Engineering owners read the packet as the contract the closure decision will read against; the engineering manager reads Section 9 as the assignment-and-acknowledgement record the queue management discipline relies on. Pair the template with the security finding translation into developer language use case for the impact narrative discipline that turns a CVSS line into a business-language risk statement.
CISOs, internal security teams, and security leadership