Create or import, deduplicated
A finding is one vulnerability on one asset. On create and import, a recurrence with the same fingerprint updates the existing finding instead of opening a duplicate.
PMAP capability
Vulnerability Lifecycle
Move every finding through one governed path from triage to closure. PMAP enforces a status state machine, assigns severity-based SLA deadlines and ownership, and drives remediation through tickets, gates and automation.
From triage to closure, on rails
When status lives in spreadsheets and inboxes, findings stall and SLAs slip quietly. There is no single place that says what is open, who owns it and when it is due.
PMAP puts the whole lifecycle on rails. Status changes follow an enforced model, deadlines and owners are assigned automatically, and closure requires the steps your policy demands.
From free-text status to an enforced lifecycle
The same finding, tracked four different ways across spreadsheets and inboxes, becomes one governed record that only ever moves through allowed states.
Status in spreadsheets and inboxes
- Analyst A fixed? api-gw-02
- Analyst B wont fix api-gw-02
- Email patched last week api-gw-02
- Ticket still open api-gw-02
One governed finding
Unpatched RCE on api-gw-02
- in_progress
- SLA 6d left
- 4-eyes gate
Every status change follows the nine-state machine, is gated where it matters, and is written to an audit-logged history.
What the lifecycle covers
Enforced status state machine
Findings follow a status state machine, so invalid transitions are rejected at the API level and the record always reflects a real, allowed state.
- Invalid transitions blocked at the API
- Auditable status history
- No silent or out-of-order changes
Severity-based SLA deadlines
Each finding gets a severity-based SLA deadline on ingest, with pause, resume and escalation acknowledgement so the clock matches reality.
- Deadlines set automatically at ingest
- Pause, resume and escalation built in
- Severity and status override rules apply
Ownership across users and teams
Findings are assigned to users and teams, so every item has a clear owner and analyst queues surface prioritized work from the start.
- Assign to users and teams
- Prioritized analyst queues
- Multi-assignee ownership
Closure through tickets, gates and runbooks
Remediation runs through tickets, CI/CD gates and event-triggered runbooks, so closing a finding is a tracked action rather than a manual note.
- Ticketed remediation
- CI/CD gates on new critical or high findings
- Runbook automation on subscribed events
How the lifecycle works end to end
Every finding, scanner-imported or analyst-authored, moves through one governed path from discovery to verified closure.
Triage and assign an owner
New findings land in open. Owners are attached across users and teams, and assignment promotes the finding to assigned, so every item has a clear owner from the start.
Move only through allowed states
Status follows a nine-state machine. Illegal transitions are refused outright, and the interface offers only the moves a finding is allowed to make next.
Govern severity and evidence
The scanner severity is preserved while the effective severity stays adjustable. Structured steps and live SAST, SCA, and DAST artefacts travel with the finding as proof.
Gate sensitive decisions
Closing, accepting risk, or marking a false positive routes through a four-eyes approval. The requester cannot approve their own request, and every decision is recorded.
Track SLA to verified closure
Each active finding carries a severity-based SLA deadline that can pause and resume. A passing re-test closes the finding, a failure reopens it and bumps the reopen count.
What your team gets
One queue for every finding
Scanner imports and manual pentest findings sit in the same governed grid, with the same severity rules and the same closure path, so the team runs one triage queue instead of one per tool.
Decisions that hold up to audit
Risk-acceptance and false-positive calls pass through a second reviewer, and every status change is written to an audit-logged history, so closure stays defensible long after the fact.
SLAs that reflect reality
Severity-based deadlines pause and resume with the work, escalations are recorded as the clock runs down, and reopen counts make persistent issues impossible to miss.
Frequently asked questions
What stops the same vulnerability being triaged twice?
Deduplication. On create and import, PMAP rejects a new finding when an open finding with the same fingerprint already exists in the same company, and recurrences update or reopen the existing finding. An analyst can override with force when a distinct record is genuinely wanted.
Can an analyst overwrite the scanner severity?
The effective severity can be adjusted, but the scanner value is never lost. It is preserved as the original severity, so any reviewer sees both the source assessment and the effective value, and a rule-driven change records an override message.
Who can close a finding or accept its risk?
When the approval workflow is enabled, transitions to closed, accepted risk, and false positive require a second reviewer. The requester cannot approve their own request, and each decision is timestamped with notes from both parties.
Do bulk operations skip the rules to go faster?
No. Each bulk operation applies the same state machine, scope checks, and approval gate as a single edit, item by item, and returns a per-item success or failure list, so nothing is transitioned illegally for throughput.
See the lifecycle end to end
Bring a finding and watch PMAP carry it from triage through SLA to a tracked closure.