Verify fixes and track reopens
on the same finding record
Retesting workflows on the FindingStatus lifecycle. Move findings through open, in_progress, resolved, verified, and reopened with separate resolved_at and verified_at timestamps, RBAC-gated transitions, and an activity log audit trail that survives any audit window.
No credit card required. Free plan available forever.
Closing a finding is a verification event, not a status change
Internal security teams, AppSec teams, vulnerability management teams, and GRC owners all share the same audit-grade question about every closed finding: when did the team claim the fix, when did someone verify it, and where is the evidence that the original attack path no longer reproduces. A vulnerability platform that collapses those three questions into a single closed flag cannot answer any of them, and the audit pack falls back on screenshots, chat threads, and best guesses.
Retesting workflows in SecPortal are built on the FindingStatus lifecycle. Open, in_progress, resolved, verified, and reopened are not labels in a dropdown; they are transitions captured in the activity log with the actor, the engagement, the previous status, and the new status. The platform records resolved_at when the owning team claims a fix and verified_at when the retest confirms it, so the audit trail tells a coherent story of remediation versus verification rather than a single ambiguous timestamp.
The FindingStatus lifecycle the platform actually models
The FindingStatus enum in SecPortal includes a security testing lifecycle aligned to the way internal AppSec and vulnerability management teams work. The states below cover the path most engagement records walk through; the platform also supports compliance and incident response statuses for engagements typed as audits or IR cases.
open
The finding has been logged on the engagement record with severity, evidence, and remediation guidance. The remediation clock is running.
in_progress
The owning team has accepted the finding and is working on a fix. The record stays attached to the engagement so progress is visible alongside scope and other findings.
resolved
The owner has reported a fix is in place. The platform records resolved_at and the finding moves to awaiting verification. The remediation work is claimed but not yet proven.
verified
Retest evidence confirms the original attack path no longer reproduces. The platform sets verified_at and the close-out is anchored to a date, an actor, and the evidence on the record.
reopened
A retest or a follow-on scan shows the issue still reproduces, or a previously closed finding has regressed. The platform clears verified_at, and the original record carries the regression history rather than spawning a parallel record.
false_positive
The finding has been investigated and does not reproduce in the real environment, or has been suppressed against an explicit policy. Suppression lives on the record so the audit trail captures the decision.
Four retest outcomes the platform represents as structured states
Free-text retest notes hide partial fixes inside paragraphs and let regressions slip through close-out reports. SecPortal uses structured statuses so the retest result is queryable, reportable, and auditable rather than narrative.
Verified fixed
The original attack path no longer reproduces, the fix matches the remediation guidance on the record, and no related variants have been introduced. The finding moves to verified, verified_at is set, and the close-out is anchored to the engagement record.
Partially fixed
The headline issue is mitigated but a sub-case, an edge condition, or a related variant still reproduces. The record stays open with the residual scope captured. Severity may drop, but the record stays attached so the next retest tests the residual rather than the whole chain.
Not fixed
The original attack path still reproduces. The finding moves back to in_progress or stays open. The retest evidence remains on the record so the next iteration starts with a clean trail rather than a fresh investigation.
Regressed
A previously closed finding now reproduces. The original record reopens via the reopened status, verified_at is cleared, and the original close-out timestamp stays in the audit log alongside the new attempt. Regressions are the strongest signal that a code change reintroduced the issue.
How the platform behaves around verify and reopen transitions
These behaviours are enforced in the finding API, not described in documentation. Auditors and security leaders read the platform state, not the brochure, so the rules below are the surface they actually land on.
verified_at and resolved_at are separate timestamps
The platform stores resolved_at when the owning team claims a fix and verified_at when the retest confirms it. The two timestamps tell different stories: how long the team took to ship the fix, and how long verification took to complete. A single closed_at field collapses both into one number that nobody trusts.
Status transitions are RBAC gated
Moving a finding to verified or reopened follows the team-management RBAC rules. A viewer cannot silently mark a finding verified, and a member without the right permission cannot reopen a closed regression. Verification authority is an explicit, assignable team capability.
Activity log entries land on every transition
Every status change writes an activity log entry with the actor user, the engagement, the finding, the previous status, and the new status. The activity log exports to CSV so the verification trail surfaces in any audit window without screen-scraping the UI.
Reopens preserve the original record
The reopened status keeps the regression on the original finding rather than creating a new one. Severity continuity, original evidence, original remediation guidance, and the full transition history live on one timeline. Auditors read one record per issue, not three.
Verification evidence belongs on the finding
Retest evidence (the proof-of-fix request and response, the configuration diff, the captured screenshot, the rerun scan reference) attaches to the finding record itself rather than living in a separate evidence folder. Document management binds the artefact to the source the auditor will land on.
Five ways retest evidence binds back to the original finding
Retest evidence has to attach to the same record the original finding lives on, or the audit trail snaps. SecPortal supports five retest pathways, all of which keep the binding intact.
Targeted manual retest
A tester or AppSec engineer reproduces the original attack path against the production fix, captures evidence on the finding, and moves the status to verified or reopened. The record carries the updated request/response payloads as proof of either outcome.
Authenticated scan as retest evidence
For findings produced by an authenticated scan, the next authenticated scan run against the same target generates evidence the platform binds to the existing record. Stored credentials in the encrypted credential vault keep the rerun reproducible without re-collecting secrets.
External scan as retest evidence
For findings produced by an external scan against a verified domain, the next external scan execution generates evidence on the same record. The 16 external modules cover the same surface, so a remediation in one module reads against the next module run rather than a fresh assessment.
Code scan as retest evidence
For findings produced by code scanning (Semgrep SAST and dependency analysis) against a connected repository, the next code scan execution against the post-fix commit generates evidence on the same record. The repository connection via GitHub, GitLab, or Bitbucket OAuth keeps the binding intact.
Scheduled rerun via continuous monitoring
A daily, weekly, biweekly, or monthly scheduled scan automatically reads against any open findings on the same target. A regression surfaces as a reopened transition rather than a manual one, and the schedule history shows when the regression first appeared.
Audit evidence the lifecycle preserves automatically
Auditors and second-line risk readers reading against ISO 27001 Annex A 8.8, SOC 2 CC4.1 and CC7.1, NIST SP 800-53 RA-5 and SI-2, and PCI DSS 6.3.3 and 11.3 expect evidence the verification happened and that regressions are tracked. The lifecycle produces that evidence without a separate evidence-pack workstream.
- Original detection date and detection source preserved on the finding record
- Severity and CVSS 3.1 vector preserved through the verify and reopen cycle
- resolved_at timestamp from the remediation claim plus verified_at from the retest, stored as separate fields
- Activity log entries for every status transition with actor, engagement, previous status, and new status
- Original evidence (request/response, screenshots, scanner output) plus retest evidence on one record
- Reopen history captured on the original finding rather than spread across new records
Six failure modes the lifecycle prevents by design
Closing findings without a verification step
A platform that lets the owner mark a finding closed without an independent verification step rewards optimism. SecPortal separates resolved (the owner claims a fix) from verified (the retest confirms it). The two states cannot collapse into one because the timestamps and the activity log entries are independent.
New finding instead of reopen
Creating a fresh finding when a regression hits hides the fact that a previous fix did not hold. The original severity, the original evidence, and the original close-out timestamp all live on the new record under different metadata. SecPortal uses the reopened status so the regression history stays attached to the source record.
Retest evidence in a separate folder
Treating retest evidence as a separate document outside the finding splits the audit trail. The auditor lands on the finding and finds remediation language without the proof, then has to chase the proof through a folder that may or may not match. SecPortal attaches retest evidence to the finding via document management so the trail is single-source.
Verification status hidden inside narrative notes
Recording verification as a free-text note inside the finding description hides partial fixes inside paragraphs. SecPortal uses the structured FindingStatus lifecycle so verified, partially fixed (open with residual scope), not fixed (back to in_progress), and regressed (reopened) are queryable states rather than prose.
No RBAC on verification authority
A workspace where any user can mark any finding verified is a governance defect. SecPortal gates status transitions through team-management RBAC so verification authority is assignable and the activity log captures who exercised it.
Missing reopen audit trail
A reopen that overwrites the previous close-out timestamp loses the lifecycle history. SecPortal preserves the activity log entries for the original close, the regression detection, and the new attempt, so the timeline survives even when the current status is back to open.
How retesting fits the rest of the platform
Findings management as the record
The verify and reopen transitions live on the same findings management record that captured the original detection. CVSS 3.1 vector, evidence, remediation guidance, and severity all carry through the cycle without a parallel record.
Activity log as audit trail
Every transition writes to the activity log with the actor, the engagement, the previous status, and the new status. The CSV export surfaces the verification chain in any audit window.
Continuous monitoring as retest engine
Daily, weekly, biweekly, and monthly continuous monitoring schedules read against the same target as the open findings, so a regression surfaces as a reopened transition rather than a fresh detection on a new record.
Engagement as scope anchor
Verification stays inside the original engagement so retest scope, retest evidence, and the original assessment scope read against the same record. The retest is a phase of the engagement, not a fresh project.
Where to read next
For the operational workflow that wraps the lifecycle (scope rows, retest passes included, regression handling, billing), see the retesting workflow use case.
For internal security teams running closure cadences against open backlogs, the remediation tracking workflow covers the named-owner routing and the SLA clock that retesting closes against.
For the practical retest playbook for testers and AppSec engineers, see the how to retest vulnerabilities guide.
For the end-to-end provenance from scan execution through closure, the scanner evidence chain covers how scanner-produced findings preserve the source link through verify and reopen.
For SLA discipline that the verify and reopen transitions stop the clock against, the vulnerability SLA management workflow covers the policy that defines when the lifecycle is on time and when it has breached.
Stop closing findings without verifying them
Separate the remediation claim from the verification evidence. Reopen regressions on the original record. Keep the audit trail intact through every cycle.
No credit card required. Free plan available forever.