When a security test was completed but no retest occurred, auditors should determine whether management is making unsupported closure claims, relying on implementation evidence, accepting risk or simply delaying verification. Ask what was found, what changed, who validated deployment, what remains open, why retesting was omitted, which requirement applies and when independent closure will occur.

Start with the assurance requirement

Identify whether policy, contract, customer commitment or audit criteria require retesting. Clarify whether the objective is remediation governance, independent closure or both.

Record the requesting party, framework or contract clause, assessment boundary, evidence period, due date and decision the evidence must support. Confirm the interpretation with the auditor, assessor or customer where possible. A penetration test can contribute strong assurance, but a report cannot guarantee an audit outcome or replace the organization’s wider control evidence.

Create a traceable evidence index

  • Requirement or control identifier and the assertion being supported.
  • In-scope systems, interfaces, environments, identities and important exclusions.
  • Assessment dates, methodology, tester identity or competence evidence and authorization.
  • Finding identifiers, severity rationale, remediation owner, status and exception reference.
  • Retest evidence, closure date, residual risk and the location of protected technical detail.

Collect original report and findings, remediation tickets, root-cause analysis, code review, build and deployment records, QA regression, scanner results, compensating controls, risk acceptances, owner attestations, reasons for no retest, vendor correspondence, planned date and current exposure.

Define the risk question

Establish the true status of every material finding without inferring closure from ticket workflow.

  • List original finding IDs.
  • Preserve original severity.
  • Identify remediation claim.
  • Confirm deployed version.
  • Separate open and accepted risk.

Connect the conclusion to a named asset, threat, control objective and decision owner. Separate observed evidence from assumptions and management judgment.

Challenge the evidence quality

Assess the strength and limits of internal implementation and QA evidence.

  • Review root-cause change.
  • Check deployment proof.
  • Inspect security regression.
  • Verify positive controls.
  • Identify missing adversarial validation.

Record missing, stale, inconsistent or inaccessible evidence as a limitation. Absence of a reported finding is not proof that the risk was tested.

Test the risk conclusion

Challenge management’s closure language and evaluate current exposure pending independent verification.

  • Ask why retest was omitted.
  • Assess environment changes.
  • Review alternative paths.
  • Check monitoring and incidents.
  • Confirm residual risk rating.

Use independent review and counter-evidence. Document why alternative explanations were accepted or rejected.

Govern exceptions and residual risk

Turn the gap into an owned, dated action or a formally accepted exception.

  • Assign accountable owner.
  • Book retest.
  • Set target date.
  • Document interim safeguards.
  • Escalate overdue closure.

Every exception needs an accountable owner, rationale, expiry, monitoring, review trigger and route back to remediation or reassessment.

Create decision-ready reporting

Make the difference between fixed, internally tested, independently retested and risk accepted unmistakable.

  • Use precise status labels.
  • State evidence source.
  • List missing proof.
  • Record management response.
  • Define follow-up procedure.

Keep technical detail protected while making scope, status, uncertainty and required management action visible to the authorized reader.

Operate the evidence workflow

  1. Confirm the requirement, evidence owner, reviewer and deadline.
  2. Freeze a versioned scope and record every approved change or exclusion.
  3. Collect assessment artifacts through a controlled, access-limited repository.
  4. Map findings and closure evidence without changing the tester’s original conclusion.
  5. Perform a completeness and consistency review before external sharing.

Interview security, engineering, GRC and the system owner against one finding register. Reconcile conflicting statuses and verify a sample of deployment evidence.

Preserve evidence integrity and confidentiality

Keep the original signed or versioned report, evidence manifest and retest artifacts. Redact copies rather than overwriting the source. Restrict exploit steps, credentials, personal data and internal architecture to approved recipients. Record who received which version, under what authorization and for what purpose.

Quality checks before reliance

  • Scope, dates and environment agree across the report, statement of work and evidence index.
  • Every closure claim points to a finding identifier and retest result.
  • Exceptions name an owner, rationale, review date and compensating controls.
  • Control mappings distinguish direct evidence from supporting context.
  • Sanitized summaries do not imply broader coverage or stronger closure than the source report.

Use framework language carefully

Use the applicable official control text and assessor guidance as the authority. The NIST Technical Guide to Information Security Testing and Assessment supports disciplined assessment planning and reporting, while the OWASP Web Security Testing Guide provides application testing context. Neither substitutes for framework-specific interpretation by the responsible auditor or assessor.

Report the assurance conclusion

Issue an audit observation or follow-up record showing each finding’s original state, management action, available validation, retest gap, residual exposure, owner and committed closure date.

State observed facts, limitations and management decisions separately. Do not use “compliant,” “certified,” “secure” or “all vulnerabilities fixed” unless the authorized assessor and evidence genuinely support that precise claim.

The GRC decision

Without a retest, management can demonstrate responsible remediation work but should not claim independent technical closure. The audit response must expose that distinction and drive time-bound verification.

Ask WIMD to close the retest gap with finding-specific verification and evidence suitable for audit follow-up.