Most teams describe vulnerability management as a four word slogan. Scan, prioritize, fix, repeat. That slogan hides the part that actually decides whether a program works. The hard part is what happens to a single finding between the moment a scanner reports it and the moment someone can prove it is closed. That journey is the vulnerability management lifecycle, and it is where programs either build trust or quietly lose it.
This guide walks the full lifecycle one stage at a time. It covers how findings arrive, how duplicate noise is removed at the door, how severity is governed instead of inherited, how triage moves a finding through a controlled status workflow, how ownership and SLA deadlines are assigned, how enrichment accelerates decisions, and how a fix is proven real before anything is marked closed. Every claim here is grounded in how PMAP actually models a finding, because a lifecycle description is only useful if the platform behind it behaves the way the description promises.
If you are building or rebuilding a vulnerability management program, treat this as a reference map. You can read it top to bottom, or jump to the stage that hurts the most right now.
What the Vulnerability Management Lifecycle Actually Covers
The vulnerability management lifecycle is the full set of states and transitions a single vulnerability passes through on a single asset. It begins at intake, when a vulnerability is first observed, and it ends at a terminal state, when the issue is closed, accepted as risk, or marked as a false positive. Everything in between is the work that turns raw scanner output into accountable remediation.
It helps to be precise about the unit of work. In PMAP a finding is one vulnerability observed on one asset. That asset might be a host, a web application, a source code repository, or a software dependency. The vulnerability might come from a network scanner, a dynamic application security test, a static analysis run, a software composition analysis scan, or a pentester typing it in by hand. The model is the same in every case. One real issue on one real asset becomes one record that owns its entire life, including creation, deduplication, triage, assignment, status workflow, SLA tracking, re-testing, evidence, external ticketing, and reporting export.
This matters because the lifecycle is not a pipeline that pushes findings forward and forgets them. It is a stateful record. A finding can be reopened when it recurs. It can be paused when remediation is blocked. It can carry its scanner reported severity alongside the severity your team actually decided on. Industry guidance reflects this same shift toward a continuous, evidence-driven process. The NIST SP 800-40 Rev. 4 guidance on enterprise patch and vulnerability management frames remediation as an ongoing risk reduction activity rather than a one-time scan and patch event, and ISO/IEC 27001:2022 treats technical vulnerability management as a control that must be operated and evidenced continuously.
The rest of this article follows the four motions that the PMAP narrative is built on. Findings are ingested, correlated, triaged, and remediated. Each section below maps to one part of that arc, and each one describes behavior you can verify rather than aspiration.
Intake: Manual Findings and Scanner Findings in One Model
The lifecycle starts at intake, and intake is where most programs accidentally fragment. Scanner output lives in one place, pentest results live in spreadsheets, and the two never reconcile. PMAP closes that gap by serving both through the same finding model.
A scanner-imported finding and an analyst-authored pentest finding are the same kind of record. The model carries scanner specific fields such as scanner_source, scanner_ref, and fingerprint for results that arrive from automated tools, and it carries the same title, description, severity, taxonomy, and evidence fields that a pentester fills in by hand. Manual findings and scanner findings do not branch into separate systems. They share one schema, one status workflow, one SLA engine, and one reporting export.
This single-model approach has a direct operational payoff. A manager reviewing open work does not need to remember which findings came from Nessus and which came from a manual web application assessment. They all appear in the same filterable, paginated list, scoped by tenant, and they all obey the same rules. When you later assign owners, set deadlines, or generate a report, the source of the finding stops being a special case.
Intake also carries rich context for application and supply chain findings. When a result arrives from a static analysis or software composition analysis tool, the model preserves source detail such as file path, line numbers, code snippet, taint flow, dependency path, component version, ecosystem, and license identifier. That detail is not discarded at the door, because the people who eventually fix the issue need it. The point of intake is not just to record that a vulnerability exists. It is to record it once, completely, in a form the rest of the lifecycle can act on.
How a Manual Finding Enters the Lifecycle
A manual finding is the cleaner of the two intake paths to picture, because a human controls every field. Consider an analyst finishing a web application assessment. They open the finding form and author a record with a title, a description, and a chosen severity. They classify it with a vuln_type drawn from a canonical set of eleven values, so a web flaw is recorded as web, a database misconfiguration as database, and a vulnerable library as dependency. They attach structured evidence rather than a wall of prose. The steps to reproduce are stored as structured data, the tools used are recorded as an array, the accounts used are recorded as an array, and the access point and exploit status are discrete fields. Each of those is searchable later, which is the whole reason they are not free text.
The moment that finding is created, it inherits the same machinery a scanner result would. It receives a governed severity, an SLA deadline resolved from configuration, and a place in the status workflow. From the system’s point of view there is no second class of record. A pentester’s manual entry and a Nessus import are peers, and the rest of this article treats them as one.
How a Scanner Finding Enters the Lifecycle
The scanner path is busier because volume is higher and the data arrives pre-parsed by an importer rather than typed by a person. PMAP supports a wide set of scanner importers, including Nessus, Qualys, Rapid7, Acunetix, Invicti, Nuclei, SonarQube, and TenableSC, plus a generic connector for normalized results. Each importer parses its vendor format, then emits one correlation request per result into a shared engine.
That request is not a thin title and severity. It carries the full extended field set so nothing is lost at the door. For an application result it includes file path, line and column numbers, a code snippet, a taint flow, a rule key, and a hotspot flag. For a supply chain result it includes the component name, the current version, the fix version, the ecosystem, the dependency path, the SPDX license, and whether the dependency is transitive. For continuous integration context it can include the commit SHA, the branch name, the pull request number, and the repository URL. A scanner finding therefore arrives as complete as a careful manual one. The difference is only who assembled it.
Picture a security team running a weekly authenticated network scan across a few hundred hosts. The scan completes overnight, the importer runs in a background job, and each result flows through correlation before it ever becomes a finding. By the time an analyst opens the queue in the morning, the new and recurring issues are already separated, severity rules have already fired, and the count they see reflects real work rather than raw scanner volume. That separation is the job of deduplication, and it is why deduplication has to live at intake rather than downstream.
Why Deduplication Belongs at Intake
If intake simply accepted everything, the lifecycle would drown in duplicates. The same vulnerability gets reported by the same scanner on every weekly run. The same web flaw shows up in both a dynamic scan and a manual test. Without deduplication, every one of those becomes a new record, and your open count inflates with noise that no one can triage.
PMAP puts deduplication at the door rather than treating it as cleanup later. On create, the finding domain rejects a new finding when an open finding with the same fingerprint already exists in the same company, unless the caller explicitly forces it. The duplicate is not silently created and then merged. It is refused, and the existing record is returned, so the lifecycle keeps one record per real issue.
For scanner-driven intake, the work runs through a dedicated correlation engine that every importer calls for each inbound result. That engine answers one question for every scanner result. Does this vulnerability already exist, or is it new? It uses a two stage lookup. First it tries the scanner’s own unique reference key, which makes re-ingesting a repeated weekly scan idempotent. If that key is absent or differs, it falls back to a SHA-1 fingerprint built from the normalized title, the asset, and the endpoint. The fingerprint lookup spans any status, including closed, which is what lets a recurrence reopen the original finding instead of spawning a new one.
The result is a four case pipeline. A matching open finding is updated in place. A matching closed finding is updated and reopened, preserving its history. A result with no match becomes a brand new finding. Repeated ingestion of an already-known issue is absorbed quietly.
Two details make this robust rather than fragile. The first is normalization. Before any fingerprint is computed, the engine lowercases and trims the title and rewrites the endpoint into a stable host:port form, stripping the scheme and the URL path. That means the same vulnerability does not produce two different fingerprints just because one scan reported https://app.example/login and another reported app.example:443. The second detail is fingerprint granularity. The engine can build a fingerprint from the normalized title, the asset, and the endpoint, and it can add a template or definition identifier to sharpen the match. When a company-scoped definition is present, it takes priority over a global template identifier, which gives a team finer dedup control over its own catalogued vulnerabilities without losing the cross-vendor baseline.
There is one more behavior worth naming, because it ties intake back to severity governance. On the create and reopen branches, and only those, the engine immediately runs the rule engine against the affected finding. That means a severity or status rule fires at ingest time, not on a later sweep. A team can therefore encode a policy such as raising the effective severity of a particular weakness class, and that policy applies the moment the finding lands. Rule failures are deliberately non-blocking, so a misconfigured rule never aborts an otherwise successful import.
This is the part of the lifecycle that decides whether your open count means anything, and it is covered in more depth in the dedicated correlation engine discussion. For now the principle is enough. Deduplication is an intake responsibility, not a reporting afterthought.
Severity Governance: Never Trust External Severity Blindly
A scanner hands you a severity. The temptation is to trust it and move on. That is how a low priority informational finding ends up consuming an urgent SLA, and how a genuinely critical issue gets buried because one vendor under-rated it. Severity governance is the discipline of treating the scanner’s rating as input, not as the final word.
PMAP encodes this directly into the finding model. Every finding tracks two distinct values. The original_severity field preserves exactly what the scanner reported. The severity field holds the governed value your program actually operates on, which may have been adjusted by an analyst or by an automated rule. The scanner’s opinion is never overwritten and never silently trusted. It is recorded, and then your governance sits on top of it.
This separation is what makes prioritization defensible. When a CISO asks why a particular finding was downgraded, the answer is in the record. The original rating is still there, the adjusted rating is there, and if a rule changed it, the override is attributed. Severity governance also gives you a clean basis for scoring. Many teams align their governed severity with a common standard, and the FIRST Common Vulnerability Scoring System provides the shared vocabulary that lets external scores be compared and adjusted consistently across vendors. The model stores the CVSS vector and score alongside the finding, so the governed severity can be traced back to a transparent calculation rather than a vendor’s private heuristic.
How a Governed Severity Ripples Downstream
Severity is not a cosmetic label inside the lifecycle. It drives the SLA deadline a finding inherits, it weights the risk scoring that ranks assets and projects, and it shapes which findings rise to the top of a triage queue. The risk scoring is concrete about this. An asset’s risk score is built from weighted severity counts, where an urgent finding counts far more than a low one, and that base is then multiplied by the asset’s criticality and adjusted for SLA breaches and exposure. A single mis-rated severity therefore does not just mislead one analyst. It distorts an asset’s rank, a project’s weighted score, and a company’s aggregate. Governing severity correctly at intake means every one of those downstream numbers rests on a value your team owns and can defend.
There is also an attribution trail when a rule changes a severity. The finding records the rule’s override message, the value it moved from, the value it moved to, and the rule’s name. So when a governed severity differs from the scanner’s original, the record explains not just that it changed but which rule changed it and why. For a deeper look at how enrichment and templates refine severity and taxonomy at scale, the finding triage discussion goes further.
Triage and the Status Workflow State Machine
Once a finding exists and carries a governed severity, triage begins. Triage is the act of moving a finding through a controlled sequence of states until it reaches a resolution. The danger here is the free text status field, where one analyst writes “in progress,” another writes “WIP,” and a third writes “looking into it.” None of that is reportable, and none of it is enforceable.
PMAP replaces free text with an enforced state machine. A finding moves through a fixed set of statuses, and only specific transitions are allowed from each one. The platform recognizes nine status values across its analytics and workflow layers. They are open, assigned, in progress, retest, closed, reopened, false positive, accepted risk, and not accessible. Three of those are terminal. A closed finding, a false positive, and an accepted risk do not transition further.
The transition rules are explicit. An open finding can move to assigned, in progress, false positive, accepted risk, or not accessible. An assigned finding can move to in progress or to one of the terminal or blocked states. An in progress finding can move to retest, or be classified as a false positive, accepted risk, or not accessible. A finding in retest can move to closed, reopened, or not accessible. A reopened finding goes back to in progress or retest. A not accessible finding can return to open or be resolved. Any move outside these rules is rejected with an invalid transition error. The platform also surfaces the allowed next statuses on every read, so the user interface can present only the valid choices rather than letting an analyst guess.
A Status Workflow Walkthrough
Rules on paper are easy to nod at and hard to picture, so it helps to trace a single finding through them. Imagine a high severity finding that has just been created by a scanner import. It starts in open. An analyst reviews the morning queue and assigns it to an engineer, which moves it to assigned automatically. The engineer begins work and the finding moves to in progress. The engineer cannot mark it closed from here, because the state machine does not allow that jump. They apply a fix and move the finding to retest, which is the only path toward closure. Verification passes, so the finding moves from retest to closed, a terminal state. Nothing more happens to it unless it recurs.
Now imagine the same finding takes a less clean path. The engineer applies a fix, moves the finding to retest, but the verification fails. From retest the finding moves to reopened rather than closed. From reopened it goes back to in progress, the engineer revises the fix, returns it to retest, and this time it passes to closed. The record now carries that whole loop in its history, including the failed first attempt, which is exactly the kind of detail an auditor asks about and a spreadsheet loses.
The blocked and rejected states round out the picture. Suppose triage determines the finding is not real. From open or in progress it can move to false positive, a terminal state, and it leaves the active queue without pretending to be remediated. Suppose instead the business decides to live with the risk. The finding moves to accepted risk, also terminal, and the decision is recorded rather than implied by silence. And suppose the asset simply cannot be reached during a scan window. The finding moves to not accessible, which is not terminal. It can return to open when the asset is reachable again, or be resolved once its real disposition is known. Each of these is a deliberate outcome the state machine recognizes, so the queue never has to overload one status to mean several different things.
Two behaviors are worth calling out because they remove manual bookkeeping. When an analyst assigns an open finding to an owner, the status automatically becomes assigned. The act of giving the work to someone is itself a state transition, so the queue stays honest without anyone remembering to flip a field. And every transition is audit logged, which means the status history is not a guess reconstructed after the fact. It is a recorded sequence you can replay through the finding’s history endpoint.
Why Nine States Beat a Free Text Field
It is fair to ask why nine states rather than three or thirty. The answer is that each state earns its place by being the target of a real decision. Open, assigned, and in progress track the forward motion of remediation. Retest enforces verification before closure. Closed, false positive, and accepted risk are the three honest endings, and keeping them distinct matters because they mean very different things to a metric. A false positive should not count against remediation performance, and an accepted risk should not look like an unfixed problem. Reopened captures recurrence as a first class event rather than a quiet edit. Not accessible captures the real world fact that some assets drop off the network without implying anyone failed.
This is the spine of the lifecycle. The state machine is what lets a program say, with confidence, how many findings are genuinely open versus assigned versus waiting on retest. Because the analytics layer reports a status distribution across exactly these nine values, the dashboard counts and the workflow rules describe the same reality. When triage is governed this way, the dashboard counts stop being approximations. For teams moving off spreadsheets, this controlled workflow is the single largest source of trust, and the broader case for it is covered in the spreadsheets versus a VM platform comparison.
Assignment and Ownership: Users and Teams
A finding without an owner is a finding that no one is accountable for. Assignment is the lifecycle stage that connects a vulnerability to the people responsible for resolving it, and the real world rarely fits a single owner per issue.
PMAP models assignment as polymorphic. A finding can be assigned to users and to teams at the same time, through an assignees collection, alongside a legacy single assignee field kept for backward compatibility. This reflects how remediation actually distributes. A database vulnerability might belong to the database team as a unit, while a specific host issue belongs to a named engineer. Both can be expressed on the same record without forcing the work into one box.
The same polymorphism applies to attribution. The “found by” relationship is also a collection of users and teams, so a finding discovered jointly by an internal analyst and an external pentest firm records both. Attribution matters more than it first appears. It feeds vendor performance reporting, it supports audit questions about who identified an issue, and it keeps credit and accountability separate from remediation ownership.
Assignment is not a dead end field. It interacts with the rest of the lifecycle. Assigning an open finding transitions it to the assigned status automatically, as described above. Multi-assignee fan-out feeds the notification layer, so the right people are alerted when something lands in their queue. And ownership is one of the inputs that team performance analytics use to measure open load and mean time to remediate per team. The team performance view reports, for each team, the open load it is carrying, how many findings it closed this month, its average days to remediate, and its most common root cause, all keyed off the team assignment on the finding. When assignment is structured rather than informal, the question of who owns a finding always has an answer the system can produce, and the question of how a team is performing has an answer the system can chart.
This is also where attribution and ownership pay off in vendor accountability. Because a finding can record an external consulting firm among its discoverers, the analytics layer can produce a per firm scorecard covering projects completed, findings closed, average closure time, and re-test pass rate. A program that engages outside testers can therefore measure them on the same evidence the lifecycle already captures, rather than on impressions.
SLA Tracking Across the Lifecycle
A deadline is what turns a prioritized finding into a commitment. SLA tracking is the lifecycle mechanism that attaches a resolution clock to every finding and watches it across the entire journey from open to closed.
The Severity to Hours Waterfall
In PMAP, an SLA deadline is resolved by severity, and the resolution is a waterfall rather than a single lookup. For a given severity the platform checks the project level threshold first. If that level has no value for that severity, it checks the company level threshold. If that is also absent, it checks the global defaults configured in admin settings. If those are absent too, it falls back to built-in values, and a final safety net of 168 hours catches any case the chain somehow misses.
Those built-in fallbacks are concrete. An urgent finding defaults to 24 hours, critical to 72 hours, high to 168 hours, medium to 720 hours, and low to 2160 hours. The key behavior is that each step in the waterfall is evaluated per severity, not per config. A level is skipped if its row is absent or if the specific severity field is null or zero. The first positive value wins. This means an administrator can override only the severities that matter and let the rest cascade. A project might tighten only its urgent and critical thresholds while leaving high, medium, and low to inherit from the company, and the resolver stitches those two sources together one severity at a time.
This layering is what lets a single platform serve very different contractual realities. A managed service provider can set tighter deadlines for one client’s project than another’s, while a holding company can apply one baseline across all subsidiaries and tune individual ones. Because the threshold lives in configuration rather than code, changing it does not require a release. The save operation is also an upsert, so an administrator does not need to read the existing config before writing a new one. Writing the config either creates or updates it in a single idempotent call.
Recomputing the Backlog When Policy Changes
A policy change that only applies to new findings is barely a policy at all. PMAP avoids that trap. When a company or project SLA configuration is saved, the platform immediately recomputes the deadline for every open finding in scope and reports how many it touched. The recompute is scoped to findings that are still active, meaning their status is not closed, false positive, accepted risk, or not accessible, and it skips any finding without a deadline to recompute. There is also an explicit recalculate action that re-runs the same sweep without changing the stored config, which is what an administrator uses after adjusting the global defaults in admin settings.
Consider a security team that has been operating with a 168 hour high severity SLA and decides the contract now demands 72 hours. They update the company config once. The platform recomputes the deadline on every open high severity finding in that company, and any finding whose new deadline still sits in the future has its notification flag reset so the alerting pipeline fires again as the tighter deadline approaches. The change lands across the existing backlog, not only on findings discovered after the edit.
Pause, Resume, and the Deadline Formula
The SLA clock is also realistic about how remediation actually flows. A finding’s deadline can be paused and resumed, and the accumulated pause hours are carried on the record. That prevents a finding from breaching its SLA while it was legitimately blocked, for example waiting on a vendor patch, a change window, or a dependent fix. The math is deliberately transparent. The deadline equals the finding’s creation time plus the resolved SLA hours plus any accumulated pause hours. Because pause time is added back rather than estimated, a finding that spent two days blocked gets exactly two days of credit when it resumes, and the recomputed deadline reflects that. The formula is reproducible, which matters when someone later asks why a particular finding’s clock reads the way it does.
Three Tiers of Escalation
A deadline without consequence is a suggestion. Escalation is what gives the deadline teeth, and it lives in the same configuration as the thresholds. Each company or project config can name up to three escalation contacts, and each contact carries a number of days after a breach that triggers their notification. That structure builds a tiered chain rather than a single alarm.
Picture a critical finding that breaches its 72 hour deadline. The configuration might set the first escalation contact to fire on the day of the breach, naming the remediation owner’s lead. The second contact might fire three days after the breach, naming a department head, on the assumption that three days past a critical deadline means the first nudge did not land. The third contact might fire seven days after the breach, naming a security director, because a critical finding a full week past SLA is now a leadership problem. Each tier targets a specific person at a specific delay, so the pressure rises in proportion to how long the breach has gone unaddressed. The finding also records escalation acknowledgement and an escalation history, so the chain is auditable rather than a fire and forget email.
SLA tracking is where governance meets operations. It is also where two different audiences read the same data differently. Operations teams care about the clock on each finding. Leadership cares about breach rates and average days to close across the program, which is the analytics view covered in the risk analytics and reporting discussion. The analytics layer reports breach and compliant counts, an overall breach rate, and average days to close broken out per severity, and it can surface a per company and per project health breakdown so a holding company sees which subsidiary is slipping. Both the operational and leadership views draw from the same SLA fields that the lifecycle maintains on every finding.
Enrichment and Taxonomy That Speeds Triage
Raw findings are not decisions. A title and a severity tell you something exists, but they do not tell you what kind of weakness it is, what caused it, or how to fix it. Enrichment is the lifecycle stage that adds that structure, and it is what makes large scale triage fast instead of forensic.
Coded Taxonomy Instead of Free Text
PMAP enriches findings along a canonical taxonomy. Every finding can carry arrays of effects, root causes, and remediation techniques, expressed as canonical codes rather than free text. This is deliberate. Free text descriptions cannot be aggregated, but coded taxonomy can. Once findings are coded, the platform can answer questions like which root cause is most common across the estate, which effect drives the longest remediation times, and how a particular weakness class is trending. The analytics layer turns each of those three dimensions into a distribution with a severity breakdown, a mean time to remediate per code computed on closed findings, and a weekly trend series suitable for a sparkline. None of that analysis is possible when every finding describes itself in its author’s own words.
The three dimensions answer different questions. Effects describe what the weakness lets an attacker do. Root causes describe why the weakness exists. Remediation techniques describe how to remove it. Coding all three means a manager can ask not only which problems are most common but which underlying causes are most expensive to fix and which fixes recur most often, and the platform answers from data rather than anecdote.
How Smart Match Backfills a Finding
The enrichment that accelerates triage most is template matching, which the platform calls Smart Match. Findings can be linked, automatically or manually, to external vulnerability templates that carry CWE identifiers, MITRE technique references, CVSS data, and a curated taxonomy. When a finding links to a template, that structured knowledge backfills onto the finding, including the taxonomy codes and the weakness classification. A single low confidence scanner title becomes a finding that knows it is a particular CWE category mapped to a known technique.
The flow is worth tracing because the transparency is the point. A scanner emits a result with a terse title and a vendor severity. Smart Match compares that result against the template library and proposes a link. The match is not silent. It records a confidence score and the method used to make it, so an analyst can see how strong the link is and how it was reached. If the match is right, the template’s CWE classification, MITRE technique references, and taxonomy codes flow onto the finding, which now carries structure it never had at intake. If the match is wrong, the analyst can re-match it or apply a different template by hand. The result is enrichment that an analyst can trust because they can audit it, rather than a black box that decorates findings with classifications no one can question.
Why Enrichment Changes Triage Economics
This enrichment changes the economics of triage. An analyst facing a thousand fresh findings does not need to research each one from scratch. The ones that matched a template arrive pre-classified, and bulk operations let the analyst re-match or apply templates across many findings at once rather than one row at a time. The unmatched remainder is a much smaller pile to reason about by hand. Picture an analyst who imports a large scan and finds that the bulk of results already carry a CWE classification and taxonomy codes from Smart Match. Their real work shrinks to the handful of novel or low confidence findings, which is where human judgment actually adds value.
Mapping weaknesses to a shared framework also connects your findings to external intelligence. The MITRE ATT&CK framework gives those technique references a common meaning that your detection and response teams already share, so an enriched finding speaks the same language as the rest of your security program. The deeper mechanics of template libraries and Smart Match are explored in the vulnerability intelligence discussion linked earlier.
Re-Test and Evidence: Proving a Fix Is Real
The most common failure mode in vulnerability management is closing a finding that was never actually fixed. Someone applied a patch, ticked a box, and moved on. Months later the same issue reappears, and the program has lost credibility. Re-test and evidence is the lifecycle stage that prevents this, by requiring proof before a finding reaches a terminal state.
PMAP builds re-testing into the status workflow itself. A finding does not jump straight from in progress to closed. It passes through a retest state, and only from retest can it move to closed or be reopened. That single rule encodes a policy. Nothing is closed without a verification step. If the re-test fails, the finding reopens and re-enters the remediation flow rather than disappearing into a falsely closed pile, and the reopen is counted so a chronically recurring issue is visible rather than hidden.
Analyst Re-Test Versus Vendor Re-Test
The platform supports two complementary kinds of re-test, and the difference between them is who performs the verification. An analyst-driven re-test is a human verification. The analyst confirms by hand that the fix holds, and the platform produces a retest record stamped with a timestamp, the outcome, and the analyst’s identity. A pass moves the finding from retest to closed. A fail moves it to reopened. This track suits any finding a person needs to confirm, including manual pentest findings that no scanner can reverify.
A vendor-driven re-test is automated and evidence-rich, and it applies to findings whose source scanner supports it. For application and supply chain findings, the platform can present a code snippet, a taint flow, and a dependency graph drawn from static analysis and software composition analysis sources. These artifacts are not copied into the finding row. They are fetched live from the linked integration on demand, so the scanner remains the source of truth and the finding stays a lightweight pointer to it. For dynamic application findings, the platform can start an asynchronous vendor re-test against the scanner itself.
The practical distinction is timing and authority. An analyst re-test is immediate and rests on human judgment. A vendor re-test is asynchronous and rests on the scanner re-running its own check. There is also a governance switch between them. An integration setting controls whether a positive vendor re-test result closes the finding directly or only moves it to retest for an analyst to sign off. When that setting is off, which is the default, a vendor pass still requires a human to close the loop. A team that wants a machine result to count as final can turn it on, and a team that wants a person in the loop can leave it off.
Why a Vendor Re-Test Has to Be Asynchronous
Async behavior matters because a dynamic re-scan is not instant. A scanner asked to reverify a web vulnerability may take minutes to crawl, probe, and report. PMAP starts the job and returns a job identifier immediately rather than blocking the analyst’s screen while the scanner works. The lifecycle then tracks the job’s status and surfaces the result when it returns. The analyst polls for completion instead of waiting on a frozen request. Consider a security team running re-tests across a batch of application findings near a release deadline. They start the vendor re-tests, move on to other triage, and return as each job resolves. The lifecycle absorbs the latency rather than forcing the team to sit through it.
Evidence is not just for closing a finding. It is the artifact an auditor asks for. When a program can show, finding by finding, that a fix was verified, who verified it, when, and what the verification consisted of, the audit conversation changes from assertion to demonstration. Importantly, the original evidence is preserved when a finding reopens rather than reset, so a recurring issue carries its full verification history rather than starting blank each time. The detailed mechanics of re-test cycles and evidence bundles are covered in the re-test and evidence discussion. The lifecycle principle is simple and strict. A fix is not real until it is proven, and the workflow refuses to pretend otherwise.
Closing the Loop: Tickets, Notes and Reporting
A vulnerability management program does not live in isolation. Remediation work happens in systems your engineering teams already use, conversations accumulate around each finding, and leadership needs a periodic account of where things stand. Closing the loop is the lifecycle stage that connects the finding record to those external realities.
Ticketing Without Drift
Ticketing is the first connection. A finding can be linked to a Jira or ServiceNow ticket, and the finding model carries the external ticket reference along with the integration’s identity, type, name, and base URL, so the link points to a real system rather than a bare string. Status synchronizes between the two and webhook-driven notes flow back into the finding. This is what keeps the security view and the engineering view from drifting apart. When the ticket moves in the engineering tool, the finding hears about it through the webhook, and a note records what changed.
The lifecycle also guards against duplicate tickets. Before a bulk ticket push, the platform can summarize which of the selected findings already have a ticket, so an operator does not create a second ticket for an issue that is already tracked. Picture a team selecting two hundred findings to push into a project’s ticket queue. The summary flags the forty that already carry a ticket, and only the remaining hundred and sixty are pushed. The remediation owner works in their own tool, and the finding stays current without anyone copying status by hand.
The Finding’s Biography
The second connection is the running record around each finding. Every finding carries its own notes, including notes sourced from webhooks, and a combined activity and history feed. That feed is the finding’s biography. It records status transitions, assignments, escalations, and comments in one chronological view, and because every transition is audit logged the feed is a recorded sequence rather than a reconstruction. When a question arises about why a finding sat open for three weeks, the answer is in the activity feed rather than in someone’s memory. An analyst can open the history and see that the finding was assigned on day two, blocked on day five while a change window was awaited, resumed on day twelve, and verified on day nineteen, each step with its own timestamp.
This biography is also what makes ownership and attribution legible after the fact. Because assignment can name both users and teams, and attribution can record both an internal analyst and an external pentest firm as discoverers, the activity feed answers the two questions that always surface in a review. Who found this, and who owns fixing it. Neither question depends on memory when the record carries the answer.
From Record to Report
The third connection is reporting. Because every finding carries governed severity, status, taxonomy, SLA state, and evidence in a structured form, the program can export that data into reports without a manual scramble. Findings stream to CSV and XLSX for analysts who want the raw rows, and they feed the analytics and reporting layer that produces management and board level summaries. The same structured fields power the dashboard counts, the SLA breach analytics, the per team performance view, and the recurring and chronic rollup, all of which read from the finding rather than from a separate ledger someone maintains by hand.
The closing of the loop is not a separate system bolted on at the end. It is the natural consequence of having modeled every finding completely from intake forward. Bulk operations across status, assignment, and template linking make this loop efficient even at enterprise scale, which the bulk operations discussion explores in detail.
How PMAP Models the Whole Lifecycle
Step back from the individual stages and a pattern emerges. PMAP is positioned as an enterprise vulnerability management platform and a multi-vendor scan orchestrator, and the finding domain is the core that the rest of the platform is built around. Intake feeds it. Correlation protects it from duplicates. Enrichment makes it actionable. Analytics and reporting consume it. The lifecycle is not a feature. It is the organizing principle of the product.
What makes this model durable is that the finding is a stateful, governed record rather than a row in a queue. It remembers its original severity and its governed severity. It enforces a state machine instead of trusting free text. It resolves an SLA deadline from a layered configuration and recomputes it when policy changes. It can be paused, reopened, re-tested, and evidenced. It links to external tickets without losing its own identity. And it sits inside a multi-tenant boundary, so every list, export, and aggregate is scoped to the caller’s tenant and cross-tenant access is blocked.
That last point is easy to overlook and expensive to retrofit. The lifecycle described here runs identically whether you are a single security team or a holding company running many subsidiaries, because tenancy scoping is applied on every path rather than added as an afterthought. The same finding model that serves one team serves a managed service provider running many clients from one console.
The practical takeaway is this. A vulnerability management lifecycle only delivers value if the platform behind it treats a finding as a first class, governed object across every stage. PMAP does, and the behaviors in this article are the evidence. If you want to map your own lifecycle against a working model, the Modern Vulnerability Management Lifecycle ebook walks the same arc with worked examples, and the Vulnerability Finding Lifecycle datasheet summarizes the finding behaviors stage by stage.
Frequently Asked Questions
What is the vulnerability management lifecycle?
The vulnerability management lifecycle is the full sequence of states a single vulnerability passes through on a single asset, from the moment it is first observed at intake to the moment it reaches a terminal state such as closed, accepted risk, or false positive. In between it is deduplicated, severity-governed, triaged through a controlled status workflow, assigned to owners, tracked against an SLA deadline, enriched with taxonomy and template data, and verified by re-test before closure. In PMAP this lifecycle is owned by a single finding record that carries every one of those concerns rather than scattering them across separate tools.
How is a finding different from a vulnerability?
A vulnerability is a class of weakness, for example a particular CVE or a CWE category. A finding is one observation of that weakness on one specific asset. The same vulnerability can produce many findings if it appears on many assets, and each finding has its own lifecycle, owner, SLA deadline, and evidence. PMAP models the finding as the unit of work precisely because remediation happens per asset, not per abstract vulnerability class.
How does deduplication keep my open count accurate?
Deduplication runs at intake rather than as later cleanup. When a new finding is created, an open finding with the same fingerprint in the same company is rejected, so the same issue is not recorded twice. For scanner imports, a correlation engine checks the scanner’s own reference key first and a SHA-1 fingerprint second, then either updates a matching finding, reopens a matching closed finding, or creates a new one. Before the fingerprint is computed, the title and endpoint are normalized to a stable form, so the same vulnerability is not split into two records just because two scans formatted the URL differently. The effect is one record per real issue, which keeps the open count meaningful instead of inflated by repeated weekly scans.
Can manual pentest findings and scanner findings live in the same workflow?
Yes. PMAP uses one finding model for both. An analyst-authored pentest finding and a scanner-imported finding share the same status workflow, the same SLA engine, the same enrichment, and the same reporting export. Scanner findings carry source-specific fields such as scanner reference and fingerprint, and manual findings carry the same title, severity, taxonomy, and evidence fields. Managers triage both in one list without treating either as a special case.
What are the SLA deadlines for each severity?
SLA deadlines are resolved by severity from a layered configuration that behaves like a waterfall. The platform checks any project level override first, then a company level override, then global defaults, and finally built-in fallbacks, evaluating each step per severity rather than per config. The built-in fallback values are 24 hours for urgent, 72 hours for critical, 168 hours for high, 720 hours for medium, and 2160 hours for low. Administrators can override any single severity at the company or project level and let the rest inherit, and saving a new configuration recomputes the deadline for every open finding in scope. The clock can also be paused while a finding is legitimately blocked, and the paused hours are added back when it resumes, so a finding does not breach its SLA over time it spent waiting on a change window or a vendor patch.
Why does a finding have to pass through a retest state before closing?
The status workflow does not allow a direct jump from in progress to closed. A finding moves into a retest state, and only from retest can it be closed or reopened. This encodes a verification policy. A fix must be proven before the finding is considered resolved. PMAP supports both an analyst-driven re-test that produces a verification record stamped with the tester’s identity and a timestamp, and an automated vendor re-test that can return code-level evidence and runs asynchronously against the scanner. An integration setting decides whether a positive vendor result closes the finding directly or still requires an analyst to sign off, so a team can choose how much human judgment sits between a passing re-test and a closed finding. Either way, closure rests on demonstrated proof rather than an unverified claim.
How does severity governance prevent prioritizing the wrong findings?
Every finding stores two severities. The original severity preserves exactly what the scanner reported, and the governed severity holds the value your team actually operates on after analyst or rule adjustment. The scanner’s rating is never silently trusted or overwritten, so a vendor that over-rates or under-rates an issue does not distort your queue. Because the governed severity drives SLA deadlines and risk scoring, governing it correctly means every downstream prioritization decision rests on a number your program owns and can defend.
Download the lifecycle datasheet and see how PMAP carries a finding from intake to closed.
