The penetration test report has arrived with severity ratings and technical recommendations. A few weeks later, a manager asks what has actually been fixed. One team points to installed updates; another points to change requests still in progress. The missing connection is a working record linking each finding to an asset, an accountable owner, a deadline and verification evidence.

This article proposes a practical approach to the period after testing: confirm the findings, prioritize remediation in context, implement the change and verify closure. Adapt the fields and deadlines to organizational policy, applicable obligations and the agreed engagement. This is not a regulator’s official template or a guarantee that systems contain no vulnerabilities.

Confirm the finding and asset before assigning work

Start with a triage discussion involving the testing team, asset owner and remediation team. Match the finding identifier to the system, environment and version tested. Check that the evidence supports the finding and distinguish duplicates from findings sharing a root cause. One finding may affect several servers, while similar-looking findings may require different fixes.

Keep the report and detailed evidence in an access-controlled repository. Use a restricted reference in the tracker rather than distributing sensitive details widely. If clarification is needed, mark the finding as awaiting validation, with an owner and a due date. Disagreement is not grounds for silent closure. Any additional testing must remain within explicitly authorized scope.

Prioritize risk rather than relying on a score alone

FIRST explains that a CVSS Base score represents vulnerability severity rather than a complete measure of risk; threat and environmental context add information to the assessment. [1] Retain the score and its source, then document why the organization has assigned a particular remediation priority.

Consider service criticality, data sensitivity, asset exposure, evidence of known exploitation and the effectiveness of mitigating controls. Set the deadline through an approved policy and an accountable decision maker. Do not assign the same deadline to every finding or assume that an internal network or a firewall makes a finding low risk.

For example, a finding affecting a public portal supporting a critical service may require faster attention than a higher-severity finding on an asset with limited exposure. This hypothetical example illustrates context; it is not an automatic rule for reversing scores. Document the rationale, validate the isolation and controls, and reassess when exposure or threat information changes.

Remediation priority connects the affected asset, its exposure and the impact on the service.

Create a remediation record that remains traceable

Link each finding to its report, change request and retest. The following fields provide a starting point. Their purpose is to make ownership, timing and verification clear without requiring everyone to reread the entire report.

Field	What to record
Finding and asset	Finding ID, report reference, system, environment, version and restricted evidence link.
Priority and rationale	Severity and its source, exposure, impact, controls and the documented reason for priority.
Owner and deadline	Asset owner, remediation assignee, verifier, target date and any required approval.
Remediation plan	Proposed action, dependencies, change reference, test plan and rollback arrangements where needed.
Interim treatment	Compensating control and evidence of operation, residual risk, expiry and review date.
Verification	Authorized scope, asset and version checked, date, outcome and evidence references.
Status and closure	In progress, implemented awaiting verification, verified closed, or risk accepted by documented decision.

Separate responsibility for implementing a fix from authority to accept risk. If remediation is not feasible, a missed deadline does not turn the finding into a closed item. Record the reason, options and interim controls, then obtain a residual-risk decision from the authorized owner with a review date. Preserve the original deadline when recording an approved revision.

Implement the change while protecting service stability

Remediation may involve a patch, configuration change, access adjustment or removal of an unnecessary component. Use the change-management process and identify dependencies, suitable tests and rollback arrangements. Confirm that the action reached every affected asset: completing an update ticket for one server does not demonstrate remediation across the group.

NIST SP 800-40 Rev.4 describes patch management as a cycle that includes identifying, prioritizing and installing patches, then verifying installation. [2] The change record can document this work while keeping verification of the security outcome explicit and appropriate to the finding.

In Saudi Arabia, ECC 2–2024 addresses vulnerability management and penetration testing in sections 2-10 and 2-11. Its mandatory scope covers government entities and their affiliates, and private entities owning, operating or hosting critical national infrastructure. Applicability should therefore be checked rather than assuming every organization is subject to identical obligations. [3]

Close the finding with verification evidence

After implementation, first use a status such as implemented awaiting verification. Agree what the authorized retest must establish, then record the asset, environment, version, date and outcome. Compare the evidence with the original finding. Determine whether the action resolved the cause or only reduced the impact temporarily. A screenshot of a completed ticket is not automatically sufficient evidence of the security outcome.

Where verification succeeds within the tested scope, record the closure decision, evidence and limitations. If the problem persists or a dependency prevents closure, return the action to its owner with a precise description of the remaining issue. Risk acceptance has an authorized owner, duration and review requirement; it must not be reported as technical remediation.

Closure evidence links the implemented fix to the verification outcome and its limits.

Closure evidence links the implemented fix to the verification outcome and its limits.

Report what helps people decide

Track overdue findings, critical assets with pending treatment, reopened items and interim controls approaching review. Define each measure’s scope, source and reporting period, and show the accountable owner and next action. A closure count can mislead if it mixes technical fixes with accepted risks or conceals high-impact findings.

RMG’s penetration testing and vulnerability assessment services describe contextual analysis, remediation planning and retesting. [4] An organization can start by examining a sample of its latest findings: does each have an owner, a deadline, a reasoned priority and closure evidence? Discuss the required assessment and verification scope with RMG in relation to your assets, services and obligations.