Vulnerability finding state lifecycle
open through closed on one continuous record
Every vulnerability finding moves through a state lifecycle: open, in progress, resolved by an engineer, verified by retest, sometimes reopened on a regression, eventually closed with the proof attached, or set false positive when reproduction fails. Most programmes run this in a spreadsheet where the cell colour is the state and the audit trail is a Slack search. Run the state lifecycle as a defensible workflow on the workspace: explicit status transitions on the finding record, named actors on every change, evidence captured at each transition, and an activity log that survives from intake through audit.
No credit card required. Free plan available forever.
A defensible state model is the spine of vulnerability management
Every security finding moves through a lifecycle. A vulnerability arrives from an external scan, an authenticated DAST run, a code scan, a manual pentest write-up, a third-party report, a disclosure submission, or a developer escalation. Somebody accepts the work, somebody else deploys a fix, a retest confirms the fix held, the finding closes with proof on file, and occasionally a regression brings the issue back. Most programmes track this chronology in a spreadsheet where the cell colour is the state, the owner is a name in a comment, the evidence is in a folder, and the audit trail is a Slack search. The first external assurance review usually surfaces the cost: time-to-remediate cannot be reconstructed, the resolved-but-never-retested findings are uncounted, the reopened regressions live as parallel tickets, and the false-positive dismissals never made it into the workspace suppression register. The state lifecycle workflow fixes the spine by making every state change an explicit transition on the finding record with the named actor, the timestamp, and the evidence attached.
The lifecycle composes with the rest of the vulnerability management operating model. The upstream vulnerability finding intake workflow delivers findings to the open state with normalised severity, named owners, and provenance. The downstream fix verification workflow gates the resolved-to-verified transition with retest evidence. The SLA management workflow reads the time-in-state telemetry against the workspace policy. The exception management workflow is the register the closure check reads against where compensating controls or accepted risks reach the lifecycle. The state lifecycle sits at the centre as the spine every adjacent workflow reads against.
Seven canonical states on the SecPortal finding record
The findings management surface ships a typed status taxonomy that covers the canonical vulnerability lifecycle. The seven states below are the operational core every workspace runs against. The state definition, the entry conditions, and the permitted exit transitions are explicit so the workflow can be audited rather than improvised.
| State | What it means | Entry conditions | Permitted exit transitions |
|---|---|---|---|
open | A new vulnerability finding has landed on the queue with normalised severity, an asset binding, an owner of record, and the intake provenance attached. The finding is awaiting acceptance by the named owner and has not yet entered active remediation. | Reaches the open state after the intake workflow has captured the source, the asset, the severity, the owner of record, and the activity log entry. The intake exception filter has confirmed no active acceptance matches the finding. | Moves to in_progress when the named owner acknowledges and accepts the remediation work, to false_positive when reproduction fails on initial triage, or to closed when an exception register match is reconciled after intake. |
in_progress | The named owner of record has accepted the work, recorded the planned remediation approach, and is actively driving the fix toward deployment. The target remediation date is on the record and the SLA clock is running. | Transitions from open when the owner acknowledges, sets a target remediation date, and stamps the activity log with the acceptance event. The asset tier, the severity, and the workspace SLA policy determine the documented remediation window. | Moves to resolved when the owner reports the fix is deployed with the evidence attached, to false_positive when in-depth analysis disproves the original triage, or stays in_progress while remediation work continues across cycles. |
resolved | The engineering side has reported the fix is in place with the proof-of-fix evidence on the record: the commit SHA or pull request, the deployment reference (build, image digest, configuration identifier), and the affected environments. Resolved is the engineering-side claim, not the security-side close. | Transitions from in_progress when the remediation owner attaches the proof-of-fix evidence and stamps the activity log. The named engineer is recorded; the change reference is on the finding. | Moves to verified when the retesting workflow passes the post-fix scan or manual reproduction, back to in_progress when the retest fails and the engineer must re-work, or to closed when the workspace policy permits direct closure on documented evidence with named approver. |
verified | The retesting workflow has re-run the original attack path or scanner module against the remediated target and confirmed the fix held. The verification scan ID, the verification module, the date, the named verifier, and the evidence body are on the record. | Transitions from resolved when the retest passes. The retesting workflow records the verification scan and binds it to the original finding so the lineage is one continuous record. | Moves to closed when the workspace closure policy is satisfied (proof on file, retest passed, watch window expired without regression), or to reopened when a regression event is detected after verification. |
reopened | A previously verified or closed finding has returned: a refactor undid the patch, a base image regressed, a configuration drift overrode the hardening, a dependency upgrade reintroduced the vulnerable code path, or a customer or third-party assessment caught the recurrence. | Transitions from verified or closed when the regression evidence and the source that detected it are attached. The named reporter, the regression timestamp, and the impact assessment are on the record. Priority is restored to the original severity unless the workspace policy explicitly downgrades by exception. | Moves to in_progress when a new remediation cycle begins, to resolved when an immediate fix is deployed and proof is attached, or stays reopened until a named owner accepts the new cycle. |
closed | A verified finding has met the workspace closure policy: proof-of-fix on file, retest passed, regression watch window expired without recurrence, and any compensating-control attestation current. The named closer, the timestamp, and the closure rationale are stamped on the activity log. | Transitions from verified when the closure policy is satisfied. The activity log captures the closer, the rationale, and the evidence references the auditor reads against. | Moves to reopened only when regression evidence is attached. Closed findings do not silently re-open; every reopening cites the prior closure and the regression evidence so the chronology reads as one continuous record. |
false_positive | Reproduction failed: the scanner pattern matched a benign string, the rule was overly broad, the asset binding pointed to a third-party-controlled surface the workspace cannot remediate, or the supposed evidence does not reproduce against the live target. The finding is dismissed with documented rationale. | Transitions from open, in_progress, or resolved when reproduction fails. The named triager, the reproduction attempt, the failure mode, and the rationale are on the record. Workspace-wide false-positive suppressions update the intake exception register so the next scan cycle does not re-open the dismissed pattern. | Stays false_positive unless new evidence proves the original triage wrong. A re-derivation as a real finding is captured as a fresh intake record citing the prior false_positive entry rather than a silent state change. |
Six failure modes that quietly break the finding lifecycle
Most lifecycle failures look like sensible defaults: track states in a spreadsheet, close when the engineer says fixed, dismiss false positives by deletion. The cost arrives weeks later as a queue the team cannot defend, a closure count that does not survive a verification audit, and a regression pattern nobody catches because the reopened lineage is split across parallel tickets.
States are tracked in a spreadsheet where the cell colour is the audit trail
The finding lives in a row, the status is a coloured cell, the named owner is in the comments, and the evidence is in an inbox. The next audit cycle asks for the chain of custody from open through closed; the team rebuilds it from Slack history and engineering Jira tickets. The fix is the typed FindingStatus enum on the workspace record with the activity log capturing every transition, so the audit reads the chronology rather than reconstructing it.
Resolved is treated as closed and the retest never happens
An engineer marks the finding resolved when the pull request lands, the security side does not run the verification scan, and the closed count climbs without proof. The deployed environment may or may not carry the patch; the audit cycle later flags the missing verification. The fix is the explicit resolved-to-verified gate with the retesting workflow attached, so the closure step requires the retest evidence to be on the record.
Reopened findings open a parallel ticket and the lineage is lost
A regression brings the issue back, an operator opens a new finding with a new ID, and the prior closure context evaporates. The retest count is wrong, the SLA clock restarts as if this were a fresh discovery, and the audit cannot trace the original closure rationale. The fix is the reopened transition on the original record citing the regression evidence so the lineage stays one continuous record rather than splitting into parallel tickets.
False positives are silently deleted and the suppression is invisible
A triager dismisses a scanner finding as a false positive, deletes the record, and moves on. The next scan cycle produces the same finding again because the dismissal never made it into the workspace exception register. The fix is the false_positive state on the record (not a deletion) with the workspace-wide false-positive suppression updated so the intake check filters the pattern before it lands as a fresh open ticket.
State transitions land without named actors and the audit trail is anonymous
The finding moves from open to in_progress without a captured owner; the resolved transition has no engineer attached; the closure note says "fixed" with no name. The audit asks who did what and when, and the answer is reconstruction from chat. The fix is requiring the named actor on every transition under the workspace RBAC so each row in the activity log carries the person on the hook.
Severity changes mid-lifecycle without an override rationale
A high-severity finding sits in the queue for a sprint, an operator quietly downgrades it to medium so the SLA clock no longer breaches, and the audit reads a low-priority issue that never appeared on the leadership report. The fix is requiring a named reason on any severity override mid-lifecycle, with the original CVSS vector, the new CVSS vector, and the calibration approver captured on the activity log so the chronology of the severity decision is auditable.
Ten permitted transitions and the evidence each requires
The transition matrix below documents the permitted state changes and the evidence each change requires. Workspace state policies extend or constrain the matrix (some workspaces permit a direct resolved-to-closed path on documented evidence with a named approver, others require the verified gate before any closure), but the underlying discipline is the same: every transition is explicit, every transition has a named actor, and every transition attaches evidence the next reader and the next auditor can cite.
| From | To | Evidence and conditions |
|---|---|---|
open | in_progress | Named owner of record acknowledges; target remediation date recorded; activity log stamps the acceptance with the actor and timestamp. |
open | false_positive | Triager attempts reproduction and fails; reproduction failure mode and rationale are captured; workspace false-positive suppression is updated. |
in_progress | resolved | Remediation owner attaches the proof-of-fix evidence: commit SHA or pull request, deployment reference (build number, image digest, configuration identifier), affected environments, and named engineer. |
in_progress | false_positive | Deeper analysis during remediation disproves the original triage; rationale and named triager captured; workspace suppression updated where the pattern is reusable. |
resolved | verified | Retesting workflow re-runs the original attack path or scanner module; passing retest binds to the finding with scan ID, module, date, named verifier, and evidence body. |
resolved | in_progress | Retest fails or follow-up evidence shows the fix did not deploy; failed-retest evidence stays on the record; named follow-up cycle is captured. |
verified | closed | Workspace closure policy is satisfied: proof on file, retest passed, regression watch window expired without recurrence, and any compensating-control attestation current. Named closer and rationale stamped. |
verified | reopened | Regression evidence attached with the named source (next scan cycle, manual retest, customer report, third-party assessment) and the regression timestamp. |
closed | reopened | New regression evidence cites the prior closure; the reopened transition stamps the original finding rather than creating a parallel ticket; severity restored to the original unless explicit downgrade exception is documented. |
reopened | in_progress | New remediation cycle begins with a named owner accepting the work and a fresh target remediation date; SLA clock restarts under the workspace reopen policy. |
Six fields the lifecycle captures on every state change
A defensible lifecycle is six concrete fields on the finding record at every transition, not a status column and a vague timestamp. The fields make the next triage cycle, the next verification, the next audit, and the next leadership report reconstructable from the record rather than from email.
Current state and prior state
The current value of the FindingStatus field (open, in_progress, resolved, verified, reopened, closed, false_positive) and the prior state captured in the activity log so the lifecycle reads as a chronology rather than as a snapshot.
Transition timestamp and named actor
Each state change records the date and time of the transition and the named actor under the workspace RBAC who performed it. The activity log row links the actor to the role they held at the time so a later role change does not erase the historical attribution.
Evidence references attached to the transition
The proof on the in_progress transition (target date and named owner), on the resolved transition (commit SHA, pull request, deployment reference, environments), on the verified transition (retest scan ID, module, evidence body), on the reopened transition (regression source and evidence), on the closed transition (closure rationale and any compensating-control attestation), and on the false_positive transition (reproduction failure mode and rationale).
Time-in-state telemetry
The elapsed time the finding spent in each state across the lifecycle: time-from-open-to-in_progress (acceptance latency), time-from-in_progress-to-resolved (engineering throughput), time-from-resolved-to-verified (verification latency), time-from-verified-to-closed (closure latency), and the total wall-clock from open to closed. The series feeds the leading indicators leadership reads against.
Severity overrides during the lifecycle
Any change to the calibrated severity mid-lifecycle records the original CVSS 3.1 vector and base score, the new CVSS vector and base score, the named calibration approver, and the override rationale so the severity decision history is queryable rather than silent.
Reopen history and regression source
When a finding reopens, the activity log captures the prior closure event, the regression evidence, the named reporter, and the regression source so the lineage is preserved rather than rebuilt as a parallel ticket. Repeat reopens produce a clear pattern the workspace can read against in the leadership reporting.
Eight operating queues the lifecycle runs in parallel during the operating week
Live lifecycle work runs eight queues concurrently. Each queue has a named owner, a documented cadence, and an escalation rule so acceptances, remediations, verifications, closures, reopens, and false-positive dismissals do not silently fall behind between standups.
- Open intake queue with every finding that has landed in the last twenty-four hours, the named owner of record, and the acknowledgement window remaining. The view the on-call security operator reads against the morning standup.
- Acceptance-pending queue with every open finding whose named owner has not yet acknowledged within the documented window. The view that catches dropped routing before the finding ages.
- Active remediation queue with every in_progress finding, the target remediation date, the elapsed time-in-state, and the SLA breach signal where the date is at risk. The view the security operations lead reads against the weekly status.
- Verification-pending queue with every resolved finding awaiting a retest, the engineer-supplied proof, and the scheduled retest date. The view the verification operator reads to schedule the validation scans.
- Closure-eligible queue with every verified finding whose watch window has expired and whose closure policy is satisfied, ready for the named closer to stamp the record. The view that prevents verified findings from aging in a pseudo-closed limbo.
- Reopen queue with every reopened finding, the regression source, and the named owner of the new cycle. The view that distinguishes recurring failure modes from one-off regressions.
- False-positive queue with every false_positive transition in the last cycle, the workspace suppression update, and the named triager. The view the security operations lead reads to validate the suppression policy is being applied consistently rather than to absorb scanner noise silently.
- State-aging queue with every finding whose time-in-state exceeds the workspace policy threshold (a stale open, a hung in_progress, an unverified resolved). The view that surfaces lifecycle stalls before the SLA breach makes them visible to leadership.
How the lifecycle runs in SecPortal
The lifecycle rides on the platform surfaces the security programme already uses. Findings management is the canonical record with the typed FindingStatus enum, the retesting workflow gates the resolved-to-verified transition with binding retest evidence, team management RBAC governs who can perform each transition, the activity log captures every state change with the named actor and the evidence reference, and notifications surface state changes to the owner of record. No bespoke integration is required for the lifecycle itself; the platform capabilities below are enough.
Findings management as the canonical record
Findings management ships the typed FindingStatus enum (open, in_progress, resolved, verified, reopened, closed, false_positive) with auto-calculated CVSS 3.1, 300+ remediation templates, and the activity log of every state change.
Retesting workflows for the verified gate
Retesting workflows re-run the original attack path or scanner module against the remediated target and bind the verification evidence to the original finding so the resolved-to-verified transition stamps with the scan ID, module, date, and named verifier.
Activity log for the transition chronology
Activity log with CSV export captures every state transition with the prior state, the new state, the named actor, the timestamp, and the evidence reference so the auditor reads the chronology rather than reconstructing it from chat.
RBAC for transition authority
Team management role-based access control governs who can perform each transition: the owner accepts work, the engineer attaches proof-of-fix, the verifier confirms the retest, the named closer seals the record, and the triager handles false_positive dismissals.
Notifications on state changes
Notifications and alerts push state changes to the named owner of record, the engagement lead, and the escalation chain where the asset tier or the elapsed time-in-state requires it.
Document management for transition evidence
Document management holds the proof-of-fix artefacts (deployment manifests, configuration changes, vendor advisories) and the retest evidence as versioned attachments the finding cites rather than duplicating in the description body.
Engagement record as the lifecycle anchor
Engagement management holds the lifecycle policy per engagement type (pentest, vulnerability assessment, ISO 27001, SOC 2, bug bounty, security review, incident response) so the permitted transitions and the required evidence match the engagement context rather than collapsing to a single global policy.
Compliance tracking on closures
Compliance tracking maps each lifecycle event to ISO 27001 Annex A 8.8, SOC 2 CC7.1 and CC8.1, PCI DSS 6.3.1 and 11.3, NIST 800-53 RA-5 and SI-2, NIST CSF 2.0 Respond and Recover, and CIS Controls v8.1 control 7 so the audit chain reads continuous from open through closed.
AI reports for lifecycle narrative
AI report generation summarises the lifecycle telemetry (time-in-state, closure cadence, reopen rate, false positive rate) into a stakeholder narrative without inventing data the activity log does not support.
Audit frameworks that read against the lifecycle
Enterprise audit and certification cycles ask for evidence that the vulnerability management programme moves findings through a defined lifecycle with documented transitions, named actors, and evidence references. The lifecycle workflow produces the evidence those audits read against.
ISO 27001:2022
Annex A 8.8 (management of technical vulnerabilities) reads against the state lifecycle as the discipline that tracks every vulnerability finding from open through closed with documented state transitions, named actors, and evidence references. Clause 9.1 (monitoring and measurement) reads against the time-in-state telemetry and the closure cadence. Clause 9.2 (internal audit) and clause 10 (improvement) read against the activity log of state transitions as the evidence chain that supports continual improvement of the vulnerability management process.
SOC 2 Trust Services Criteria
CC7.1 (system operations and monitoring) reads against the lifecycle as the operational discipline that channels detected vulnerabilities through a defined state model with documented transitions. CC8.1 (change management) reads against the resolved transition (the engineering change that produced the fix) and the verified transition (the verification that the change held). CC9.1 (risk mitigation) reads against the reopened state and the regression source so the audit reads recurring failure modes rather than a single moment of remediation.
PCI DSS v4.0
Requirement 6.3.1 (security vulnerabilities are identified and managed) and Requirement 11.3 (vulnerabilities are identified and addressed) read against the state lifecycle as the workflow that takes vulnerabilities from initial detection through documented remediation with evidence-bound closure. Requirement 12 (information security policy) reads against the workspace state policy that defines permitted transitions and required evidence for each state change.
NIST SP 800-53 Rev. 5
RA-5 (vulnerability monitoring and scanning) reads against the open state and the intake provenance. SI-2 (flaw remediation) reads against the in_progress, resolved, and verified transitions and the proof-of-fix evidence on the record. CA-7 (continuous monitoring) reads against the reopened state and the regression watch window so the audit reads the durability of the closure rather than the moment of the patch.
NIST CSF 2.0
The Respond (RS) and Recover (RC) functions read against the lifecycle as the operational record of vulnerability response and recovery. The Identify (ID) function reads against the open and reopened states for asset-bound vulnerability inventory. The Govern (GV) function reads against the workspace state policy and the audit log of every transition as the evidence the policy is operated rather than aspirational.
CIS Controls v8.1
Control 7 (continuous vulnerability management) reads against the state lifecycle as the operating record of the continuous workflow. The time-in-state telemetry feeds the metrics Control 7 measures against (time-to-remediate, percentage of high-severity findings closed within policy). Control 17 (incident response management) reads against the reopened state and the false_positive transition as the structured channel for handling regression events and dismissed signal.
Where the lifecycle fits in the wider operating model
The state lifecycle is the spine every adjacent workflow reads against. The references below trace how the structured transition record carries into the rest of the programme. Each adjacent workflow reads against the same finding record rather than rebuilding a parallel register.
Vulnerability intake
The vulnerability finding intake workflow delivers findings to the open state with normalised severity, named owners, and provenance so the lifecycle starts on a defensible record rather than on a freeform queue.
Fix verification
The security finding fix verification workflow gates the resolved-to-verified transition with retest evidence so the closure count is the count of remediations that survived verification rather than the count of engineer claims.
Reopen and regression handling
The security finding reopen and regression handling workflow governs the verified-to-reopened and closed-to-reopened transitions with the same-asset-same-CWE rules, the regression-class taxonomy, the restored-severity default, and the reopen-SLA policy that keeps lineage continuous across closure cycles.
SLA management
The SLA management workflow reads the time-in-state telemetry against the workspace policy and surfaces breach signals on the operating queue before leadership reads the breach in the monthly report.
SLA-breach escalation
The SLA-breach escalation workflow reads the same lifecycle data with the escalation lens, routing breached findings to the named escalation owner under the workspace RBAC.
Acceptance and exceptions
The acceptance and exception management workflow is the register the closure check reads against where compensating controls or accepted risks reach the lifecycle.
Prioritisation
The prioritisation workflow reads the open and reopened states with the asset criticality multiplier to decide what the team works first.
Backlog management
The backlog management workflow reads the rate of open and reopened state entries against the closure cadence to keep the long tail bounded.
Asset ownership mapping and routing
The asset ownership mapping workflow supplies the named owner each open-to-in_progress transition routes against, and the ownership and routing workflow applies the documented routing rule so the lifecycle does not stall on owner-discovery rebuilt every morning.
Security leadership reporting
The security leadership reporting workflow reads the closure cadence, the reopen rate, and the time-in-state telemetry as the leading indicators the leadership pack cites against the programme commitments.
Buyer audiences for the lifecycle workflow
The state lifecycle workflow serves the operators and leaders responsible for the end-to-end discipline that moves vulnerability findings from detection to defensible closure. Each audience reads the lifecycle with a slightly different lens.
Internal security teams
Internal security teams read the lifecycle as the operating spine that keeps the queue defensible across many concurrent workstreams.
AppSec teams
AppSec teams read the lifecycle as the chain that turns SAST, SCA, DAST, and manual review findings into resolved, verified, and closed records the engineering side cannot quietly skip the verification step on.
Vulnerability management teams
Vulnerability management teams read the lifecycle as the operating record of the queue they triage, drive, verify, and close across the operating week.
Security operations leaders
Security operations leaders read the lifecycle as the time-in-state telemetry that distinguishes a healthy queue from a stalled one before leadership reads the breach in the monthly report.
GRC and compliance teams
GRC and compliance teams read the lifecycle as the audit-defensible chain ISO 27001 Annex A 8.8, SOC 2 CC7.1 and CC8.1, and PCI DSS 6.3.1 and 11.3 cite as evidence for technical vulnerability management.
CISOs and security leaders
CISOs read the lifecycle as the leading indicator of whether the vulnerability programme is operating against a defined policy or a coloured spreadsheet whose audit trail is a Slack search.
Frequently asked questions
What is the vulnerability finding state lifecycle?
The vulnerability finding state lifecycle is the defined series of states a security finding moves through from initial detection to final closure, with documented transitions, named actors, and evidence captured at each state change. SecPortal ships a typed FindingStatus enum that covers the canonical vulnerability lifecycle: open, in_progress, resolved, verified, reopened, closed, and false_positive. The lifecycle workflow defines which transitions are permitted from which state, which transitions require evidence, and which transitions require a named actor under the workspace RBAC. The activity log captures every transition so the chronology is reconstructable from the record rather than from chat history.
What is the difference between resolved and verified?
Resolved is the engineering-side claim that the fix is deployed: the commit SHA or pull request, the deployment reference, the affected environments, and the named engineer are on the record. Verified is the security-side confirmation that the retest passed: the retest scan ID, the retest module, the date, the named verifier, and the evidence body are bound to the original finding. Resolved without verified is an open claim; verified without resolved is impossible under the workspace state policy. The two-stage gate prevents the "marked fixed but never re-tested" failure mode that drives a phantom closed-count in spreadsheet-based programmes.
When should a finding move to false_positive versus closed?
A finding moves to false_positive when reproduction fails: the scanner pattern matched a benign string, the rule was overly broad, the asset binding pointed at a surface the workspace cannot remediate, or the supposed evidence does not reproduce against the live target. The false_positive state captures the reproduction attempt, the failure mode, and the rationale; workspace-wide false-positive suppressions update the intake exception register. A finding moves to closed only after the verified state: the retest passed, the watch window expired without regression, and the closure policy is satisfied. False positives are dismissals of the original triage; closed findings are verified remediations of a real issue.
How does the workflow handle reopened findings?
Reopened is a state transition on the original finding, not a new ticket. When a previously verified or closed finding returns (a refactor undoes the patch, a base image regresses, a configuration drift overrides the hardening, a dependency upgrade reintroduces the vulnerable code path, or a third-party assessment catches recurrence), the reopened transition captures the regression source, the regression evidence, the named reporter, and the impact assessment. Priority restores to the original severity unless the workspace policy explicitly documents a downgrade by exception. The lineage stays on one continuous record so the audit reads the chronology of the failure rather than parallel tickets for the same issue.
Who can move findings between states?
Team management RBAC defines the permitted transitions per role. The owner of record on the finding can accept work and move open to in_progress. The named engineer can attach proof-of-fix and move in_progress to resolved. The verification operator (or the retest workflow) moves resolved to verified on a passing retest. The named closer (typically an admin or the security operations lead) moves verified to closed once the closure policy is satisfied. The triager can move open, in_progress, or resolved to false_positive on documented reproduction failure. The activity log records the role each actor held at the time of the transition so a later role change does not erase the historical attribution.
What evidence is required at each state transition?
Open to in_progress requires a named owner of record, a target remediation date, and an activity log entry. In_progress to resolved requires the proof-of-fix evidence: the commit SHA or pull request, the deployment reference, the affected environments, and the named engineer. Resolved to verified requires the retest scan ID, the retest module, the date, the named verifier, and the evidence body the retest produced. Verified to closed requires the closure policy condition (watch window expired without regression, compensating-control attestation current where applicable) and the named closer with the closure rationale. Reopened transitions require the regression source and the regression evidence. False_positive transitions require the reproduction attempt and the failure-mode rationale.
How is time-in-state used in the workflow?
Time-in-state telemetry captures the elapsed wall-clock the finding spent in each state across the lifecycle: time-from-open-to-in_progress (acceptance latency), time-from-in_progress-to-resolved (engineering throughput), time-from-resolved-to-verified (verification latency), and time-from-verified-to-closed (closure latency). The series feeds the leading indicators security leadership reads against, surfaces stalled findings before the SLA breach makes them visible, and provides the longitudinal evidence ISO 27001 and SOC 2 audits cite when evaluating whether the vulnerability management programme is operating against documented timelines.
How does the lifecycle integrate with SLA management?
The SLA clock runs against the in_progress state in most workspace policies: open is acceptance-pending, in_progress is remediation-active, and resolved through verified is verification-active. The workspace SLA policy defines the permitted remediation window per severity per asset tier. The vulnerability SLA management workflow reads the time-in-state against the policy and surfaces breach signals on the operating queue before the breach becomes visible to leadership. SLA-breach escalation reads the same lifecycle data with a different lens, routing breached findings to the named escalation owner under the workspace RBAC.
Does the workflow require integration with engineering ticketing systems?
No. The state lifecycle runs on the workspace finding record itself. Findings management is the canonical record; the activity log captures every transition; team management RBAC controls who can perform which transition; notifications and alerts surface state changes to the named owner of record. Teams that route findings to engineering ticketing run the scanner-to-ticket handoff governance workflow as a downstream discipline that keeps the security finding canonical while the engineering ticket carries the workstream metadata. SecPortal does not ship native Jira, ServiceNow, or SIEM integrations, and the lifecycle does not depend on them.
How does the lifecycle support audit and assurance reads?
Every state transition stamps the activity log with the prior state, the new state, the named actor, the timestamp, and the evidence reference. The activity log CSV export delivers the chronology as a structured evidence pack auditors and assurance teams cite by line for ISO 27001 Annex A 8.8, SOC 2 CC7.1 and CC8.1, PCI DSS 6.3.1 and 11.3, NIST 800-53 RA-5 and SI-2, NIST CSF 2.0 Respond and Recover, and CIS Controls v8.1 control 7. AI report generation can summarise lifecycle telemetry into a stakeholder narrative, but the activity log remains the source of truth audits read against.
How it works in SecPortal
A streamlined workflow from start to finish.
Define the workspace state model against the verified status taxonomy
The findings management surface ships a typed FindingStatus enum that covers the canonical vulnerability lifecycle: open (the new finding is on the queue), in_progress (an owner is actively remediating), resolved (the engineer reports the fix is in place), verified (a retest confirmed the fix), reopened (a regression brought the issue back), closed (the verified-fixed finding is sealed with proof on file), and false_positive (reproduction failed and the finding is dismissed with documented rationale). The workspace state policy decides which transitions are permitted from which state, which transitions require evidence, and which transitions require a second named actor. A documented state model is the first artefact every audit reads against.
Move from open to in_progress only with a named owner on the record
A finding that arrives from intake lands on the queue as open with the asset binding, the normalised severity, and the named owner of record. The transition from open to in_progress is the moment the owner accepts the work, sets the target remediation date, and stamps the activity log. Transitions without a named owner stay blocked. Transitions where the named owner has not acknowledged within the documented window escalate to the secondary on-call or to the security operations lead the workspace defines.
Record the resolved transition with the engineer-supplied evidence
When the remediation owner reports the fix is deployed, the finding moves from in_progress to resolved with the proof-of-fix evidence attached: the commit SHA or pull request that contains the change, the deployment reference (build number, container image digest, configuration change identifier), the affected environments (staging, production, regional rollout), and the named engineer. Resolved is not closed; it is the engineering-side claim that the fix is in place and the cue for the security side to verify. The activity log captures the actor, the timestamp, and the evidence reference so the auditor reads engineering attestation rather than reconstructing it from chat history.
Verify the fix and move to verified with retest evidence on the record
The retesting workflow re-runs the original attack path or the original scanner module against the remediated target and attaches the result to the same finding record. A passing retest moves the finding from resolved to verified with the retest scan ID, the retest module, the date, the named verifier, and the evidence body (scanner output, manual reproduction transcript, or both). A failing retest does not advance the state; it stays at resolved with the failed-retest evidence and a named follow-up cycle so the engineering side knows the claim did not survive verification.
Reopen with the regression evidence and the named source that caught it
A previously verified finding occasionally returns: a refactor undoes the patch, a base image regresses, a configuration drift overrides the hardening, a dependency upgrade reintroduces the vulnerable code path. The reopened state captures the regression: the source that caught it (next scan cycle, manual retest, customer-reported issue, third-party assessment), the evidence of the regression, the named reporter, and the impact assessment. Reopened findings re-enter the queue with priority restored to the original severity unless the workspace policy explicitly downgrades by exception.
Close verified findings with the proof attached and the rationale stamped
Verified findings move to closed when the workspace policy is satisfied: the proof-of-fix is on the record, the retest passed, the regression watch window expired without a regression event, and any compensating-control attestation is current. Closure stamps the activity log with the named closer, the timestamp, and the rationale. Closed findings do not silently re-open; a future reopen creates a new state transition entry, citing the prior closure and the regression evidence, so the chronology reads as one continuous record rather than as a parallel re-opened ticket.
Dismiss false_positive transitions with documented reproduction failure
Some intake findings do not survive reproduction: the scanner pattern matched a benign string, the rule was overly broad, the asset binding pointed to a third-party-controlled surface the workspace cannot remediate, or the supposed evidence does not reproduce against the live target. The false_positive transition closes the finding with the named triager, the reproduction attempt, the failure mode, and the documented rationale. Workspace-wide false-positive suppressions update the intake exception register so the next scan cycle does not re-open the same dismissed finding without an explicit override.
Read the lifecycle against the activity log for every audit cycle
The activity log captures every state transition with the actor, the timestamp, the previous state, the new state, and the evidence reference. ISO 27001, SOC 2, PCI DSS, NIST 800-53, and CIS Controls audits read the lifecycle against the activity log as the chronology that proves vulnerability findings move through the defined states with the documented evidence rather than aging in a spreadsheet. CSV export of the activity log delivers the evidence pack auditors and assurance teams cite by line.
Features that power this workflow
Vulnerability management software that tracks every finding
Verify fixes and track reopens on the same finding record
Every action recorded across the workspace
Orchestrate every security engagement from start to finish
Collaborate across your entire team
Notifications and alerts for the people who carry the work
Document management for every security engagement
Compliance tracking without a full GRC platform
AI-powered reports in seconds, not days
Bulk finding import bring your scanner data with you
Run the finding state lifecycle on one continuous record
Explicit status transitions, named actors, evidence at every change, and a continuous activity log from intake through closure. Start free.
No credit card required. Free plan available forever.