Remediation and verification

A finding is not closed because someone changed a status field. It is closed when the fix has been applied and the finding no longer reproduces. This document covers how that loop is tracked and evidenced.

From validation to a plan

Once a finding is validated, it becomes work:

Ownership — an owner is assigned rather than implied.
Task and milestone boards — the work is scheduled alongside other delivery work, with deadlines and completion state.
Ticket sync — with Jira, GitHub, GitLab or Azure DevOps, so the fix lands in the system engineering already uses. See Integrations.
Severity-aware targets — remediation windows follow severity, so critical items are not queued behind cosmetic ones.

Proof of fix

Closure requires evidence, not assertion:

Reproduction re-run by the tester or reviewer against the affected asset.
Retest — for expert engagements, a retest step confirms the fix within the engagement scope.
Regression check — the same technique is attempted against related endpoints or components, because a fix applied in one place is often missed in a sibling.
Evidence attachment — retest output is stored with the finding under the same access controls as the original report.
Signed closure — the person confirming the fix is recorded.

Retesting is part of the workflow rather than a separate purchase on Professional and Enterprise tiers; lower tiers close findings with the reporter's or reviewer's confirmation.

Retest loops

Some fixes need more than one pass. A retest loop keeps the finding open while the fix is iterated:

Fix reported as complete.
Retest attempted against the documented reproduction.
If the issue persists, the finding returns to remediation with the new evidence attached — state and history are preserved rather than restarted.
When the retest passes, the finding moves to verified/closed with the closure evidence recorded.

Delta and regression reporting

Scheduled engagements produce a delta view rather than a fresh report each time:

New findings introduced since the last engagement.
Resolved findings confirmed by retest.
Recurring findings that were reported as fixed and have reappeared — the most valuable signal in the set, because it points at a process problem rather than a code problem.
Carried over findings still awaiting a fix, with ageing.

This view is what makes an engagement defensible to stakeholders: it shows movement, not just a snapshot.

Keeping the reporter in the loop

The reporter of a validated finding can follow remediation state without asking:

State changes on the finding.
The disclosure decision once the fix is verified, per the program's disclosure policy.
Recognition for the fix, where the program grants it.

Disclosure timing is governed by the program's policy — see Disclosure and safe harbor.

Availability and limits

Remediation tracking, task boards and ticket sync are available on all tiers.
Retesting, source code review and VPN-assisted verification are Professional-tier.
Certification artifacts and compliance report exports are Professional-tier; contracted SLA response guarantees are Enterprise-tier.

Triage pipeline — the states before remediation begins
Integrations — how findings reach your delivery tooling
PTaaS engagement lifecycle — retest and certification in an engagement
Evidence and file security — how retest evidence is stored