A vulnerability that nobody owns never gets fixed. That is the quiet failure mode of most security programs. Scanners produce thousands of findings, the security team triages them, and then the work stalls because no one knows who is actually responsible for the affected server, the cloud instance, or the application repository. The finding sits in a queue. The clock on its deadline keeps running. By the time someone asks who owns it, the answer is a chain of forwarded emails.
This article is written for the people on the other side of that handoff. If you are an asset owner, a remediation team lead, or part of an IT operations group that receives findings and is expected to close them, your job is not to discover vulnerabilities. Your job is to finish them. PMAP is built so that the path from a new finding to a verified fix is short, accountable, and measurable. It does this through two tightly connected ideas. The first is owner resolution, which decides who should receive a finding before it is even assigned. The second is the remediation campaign, which groups related work into a tracked program with a clear lifecycle and live closure metrics.
If you want the upstream view of how assets get into the inventory in the first place, the attack surface and asset inventory pillar covers that ground. This piece picks up where ownership and remediation begin.
The Remediation Team’s Real Job
Remediation is not triage. Triage is the security analyst deciding whether a finding is real, how severe it is, and whether it deserves attention. Remediation is the downstream act of changing something in the environment so the vulnerability no longer exists, then proving that change held. These are different jobs done by different people, and the most common reason remediation lags is that the two functions are stitched together with manual coordination.
PMAP treats the asset inventory as the backbone of the whole platform. Every finding, every scan, and every risk score ultimately resolves to an asset. An asset in PMAP is any manageable entity in your environment. That includes servers, workstations, network devices, cloud instances, applications, source-code repositories, databases, and IoT or SCADA devices. The point of anchoring everything to assets is that remediation work has a natural home. You do not chase a floating finding. You look at an asset you own, you see what is wrong with it, and you act.
The campaign domain sits one level higher. A campaign is the mechanism for coordinating remediation work across many vulnerabilities at once, so a security manager can track progress toward closure at the program level rather than finding by finding. The combination matters. Assets tell you what you are responsible for. Campaigns tell you how a body of related work is progressing. Together they replace the spreadsheet that most teams use to track remediation status, and they replace it with something that updates itself.
Knowing What You Own
Ownership in PMAP is not a single name field. Real environments are messier than that. A database might have one team that runs it day to day and a separate person who signs off on changes. A cloud account might have an engineer who maintains it and a manager who is accountable for it. PMAP models this with polymorphic ownership, which means an asset can have multiple owners and those owners can be either individual users or entire teams.
Each ownership binding carries a role. The available roles are owner, custodian, and approver. The owner is the party responsible for the asset. A custodian typically operates or maintains it. An approver is the party who needs to sign off before certain actions proceed. This three-role model lets you describe how your organization actually divides responsibility instead of forcing everyone into a single owner slot.
Every binding also carries a notify flag. This is a small detail with a large operational effect. Setting notify to false on a binding silences notifications for that owner without removing the ownership record. The relationship is preserved for audit and reporting purposes, but that person stops receiving alerts. This matters when, for example, a team is listed as a custodian for completeness but you only want the named owner to be paged when a new finding lands.
Behind the scenes PMAP keeps a denormalized primary owner slot alongside the full owner list. That detail is invisible in daily use, but it is the reason you can sort and filter an asset list by owner quickly even though the underlying model supports many owners per asset. The platform gives you a flexible model without paying a performance cost on the list view.
Who Gets the Finding: Owner Resolution
The most valuable piece of this for a remediation team is the part that runs before assignment happens at all. When a new finding is created against an asset, the question is always the same. Who should this go to? PMAP answers it with the OwnerResolver, and it exposes that answer as a dry-run endpoint.
A dry run means the resolver tells you who it would notify without committing anything. The finding-create form calls this resolution to pre-populate the assignee picker, so the person filing the finding sees a suggested owner already filled in based on the asset’s actual ownership records. There is a single-owner endpoint that returns the primary owner the resolver would pick, and a multi-owner endpoint that returns the full list. By default the resolver considers owners whose notify flag is true. If you need to see the muted owners as well, the multi-owner endpoint accepts an include_muted parameter that widens the result.
The resolver is multi-strategy. It does not just read the asset’s explicit owner and stop. It can fall back to a project-level owner and then to a company default, so a finding still lands on a responsible party even when an individual asset has no named owner yet. For a remediation team this closes the gap that usually swallows findings. The owner is decided by data the platform already holds, not by a human guessing who should handle a server they have never heard of.
Understanding Your Asset Risk
Once you know which assets are yours, the next question is which ones need attention first. PMAP gives every asset a risk_score and a finding summary broken down by severity. The finding summary counts active findings on the asset by severity tier, from urgent and critical down through high, medium, and low. An owner opening an asset sees at a glance whether they are looking at a quiet box with one low finding or a hot spot with several critical issues.
The asset list itself comes with a faceted filter sidebar. The facets aggregate counts across asset type, class, environment, criticality, company, internal versus external exposure, active versus inactive state, and whether the asset has findings at all. The clever part of the implementation is that each facet excludes its own filter when it computes its counts, so multi-select filtering stays coherent. If you select two environments, the environment facet still shows you the counts for the others rather than collapsing to only what you picked. For a remediation lead who wants to slice the inventory down to, say, all internet-facing production assets with open findings, the sidebar makes that a few clicks.
PMAP also canonicalizes IP and hostname searches before it queries. An exact search normalizes IP addresses to their canonical form and hostnames to lowercase punycode, which eliminates a category of false positives where a loose text match would otherwise pull in unrelated addresses. When you search for the exact host you are responsible for, you get that host and not a near-miss.
For deeper background on how risk scores are constructed and how asset criticality feeds them, the asset risk scoring breakdown within the pillar coverage is the place to go. The takeaway for an owner is simpler. Risk score plus severity summary tells you where to spend your next hour.
Grouping the Work Into a Campaign
A single finding rarely travels alone. A patch cycle, a quarterly hardening push, or the response to a newly disclosed CVE class all produce sets of findings that belong together. PMAP’s remediation campaign is the container for that. A campaign is a named, time-bounded grouping of findings assigned to a responsible owner, and it is company-scoped so it never reaches across tenant boundaries.
Creating a campaign captures the basics you would expect. It has a name, an optional description, an owner, and optional start and due dates. The name is required. The platform rejects a create request with an empty name before it ever touches the database. The campaign also enforces tenant boundaries at creation. If the target company is deactivated, PMAP refuses to create a campaign under it and returns a conflict. This is the company active-state gate, and it prevents work from being scheduled against a tenant that has been soft-paused.
Findings become part of a campaign through explicit membership. You add a set of findings to the campaign by their identifiers, and you can remove them the same way. The membership is integrity-checked at the database layer, which means the platform only links findings that actually belong to the campaign’s own company. You cannot accidentally pull a finding from another tenant into your campaign even if you supply its identifier. The linked-findings view is paginated and enriched, so each row shows the finding’s title, severity, status, the asset it belongs to, and its current assignee. That gives a campaign owner a single working surface for the whole program.
For a complete walkthrough of building a campaign from an empty draft to a finished program, the remediation campaigns from draft to done guide covers the mechanics step by step. This section focuses on what the campaign means for the team carrying it.
The Campaign Status Lifecycle
A campaign is not a static folder. It moves through a defined lifecycle, and PMAP enforces that lifecycle as a state machine rather than letting status be set to anything at any time. The states are draft, active, review, completed, and cancelled, and the allowed transitions between them are fixed.
A campaign starts in draft. From draft it can move to active or be cancelled. Once active, it can move to review or be cancelled. From review it can advance to completed, drop back to active if more work surfaced, or be cancelled. Both completed and cancelled are terminal states. There is no path out of them. Any transition that is not in this allowed set is rejected with an invalid-transition error, and an unrecognized current status is rejected as an invalid status.
This structure does real work for a remediation team. The draft state is where you assemble the campaign and decide which findings belong, without yet committing the team to it. The active state signals that the work is in flight. The review state is the verification stage, where the team confirms that fixes actually held before the campaign is declared done. The ability to bounce a campaign from review back to active is the honest acknowledgment that remediation sometimes fails verification and needs another pass. The state machine encodes a remediation discipline that teams usually have to enforce by convention.
Assigning Findings to the Right People
A campaign owner does not want to open dozens of findings individually to hand them out. PMAP provides bulk assignment for exactly this. In a single request you can assign one user to all of the findings in a campaign, or to a specified subset of them. If you leave the subset empty, the assignment covers every finding linked to the campaign.
The scoping on this operation is careful. Bulk assignment only affects findings that are actually linked to the campaign through its membership join. If a request includes finding identifiers that are not part of the campaign or belong to another tenant, those identifiers simply produce zero affected rows rather than leaking data or assigning across boundaries. The operation fails safe.
Each assignment also emits an event. For every finding that the bulk operation touches, PMAP dispatches a FindingAssigned notification event through its events dispatcher. That means the people receiving the work are told about it through the platform’s notification pipeline, not through a manual message from the campaign owner. The dispatch happens after the database write completes, so the assignment is durable before anyone is notified. A campaign owner can take a freshly assembled campaign, hand the entire body of work to one engineer in a single click, and trust that the engineer will be notified for each finding.
This is the operational heart of the remediation team workflow. The owner resolver decided who should receive findings as they were created. The campaign gathered the related findings into one program. Bulk assignment now distributes that program to the people who will do the fixing, and the notification pipeline tells them. The handoff that usually loses findings in email is replaced by a tracked, event-backed action.
Tracking Progress Toward Closure
The reason to organize remediation into campaigns is so you can measure it. When you open a campaign’s detail view, PMAP computes a set of progress counters on the spot. It returns total_findings, closed_findings, and overdue_findings, and it derives a closure_rate as a fraction of the total.
These four numbers answer the questions a remediation lead and their management actually ask. How big is this program. How much of it is done. How much of it is past its deadline. And what proportion of the whole is closed. Because the metrics are computed from live finding state at read time, they are never stale. There is no separate progress field that someone has to update by hand and inevitably forgets. The closure rate is a direct reflection of the underlying findings as they stand at the moment you look.
For a team, the overdue_findings count is the one to watch most closely. It is the early warning that a campaign is slipping. A program can have a healthy closure rate overall and still have a cluster of overdue items that need escalation. Surfacing overdue work as its own counter, separate from the closure percentage, keeps that signal from being averaged away.
These campaign-level metrics complement the broader risk and SLA analytics PMAP produces for leadership. The difference in lens matters. Leadership analytics answer how the whole organization is trending. The campaign counters answer how this specific remediation effort is doing right now, in the hands of the team running it.
Owner Detail Inside a Finding
Zoom in from the campaign to a single finding and the ownership model continues to do work. A finding in PMAP supports multiple assignees, which mirrors the reality that more than one person sometimes has to touch a fix. When a finding is assigned, the act of assignment promotes its status. A finding sitting in the open state moves to assigned the moment it gains an owner, so the workflow status reflects that someone now holds it.
Every finding also carries its own notes and activity feed. As the assigned owner works through a fix, the notes record the running history of what was done, and the activity feed captures the sequence of status changes and actions. This is the working memory of the remediation effort. When a finding moves into the verification stage, the person checking the fix is not starting from a blank slate. They can read what the owner did and why. When an auditor later asks how a particular vulnerability was handled, the trail is already there.
The combination of multi-assignee support, automatic status promotion on assignment, and a per-finding activity record means the granular work stays accountable even as the campaign view tracks the aggregate. The team gets both the wide angle and the close-up.
Coverage and the Wave Matrix for an Asset
There is one more capability that remediation teams come to rely on, and it answers the hardest question in the whole cycle. Did the fix actually hold? Closing a finding is not the same as fixing the underlying problem. A finding can be marked resolved and then reappear in the next scan because the patch did not take, the configuration drifted back, or the fix was applied to the wrong host.
PMAP’s Wave Matrix is built for exactly this verification. For a single asset it produces a cross-tab of findings against scan waves. Each row is a finding, each column is a scan, and each cell shows the finding’s state in that scan. The states are open, closed, reopened, and absent. Reading across a row tells you the history of a finding over successive scans. A finding that shows closed and then absent in the scans after a fix was applied gives you real confidence that the remediation held. A finding that shows closed and then reopened is the platform telling you the fix did not work and the work is not actually done.
Alongside the Wave Matrix, PMAP offers a Scan Coverage view that aggregates which integrations and scanners have produced findings for a given asset. Together these views let a remediation team verify their own work against the evidence of subsequent scans rather than taking a status field at face value. For a team that is measured on closure, this is the difference between a number that looks good and a number that is true.
How PMAP Turns Findings Into Finished Work
Step back and the shape of the remediation team workflow is clear. It is a chain, and PMAP holds every link.
The inventory is the foundation. Every finding resolves to an asset, and assets carry polymorphic ownership with owner, custodian, and approver roles and per-binding notification control. Owner resolution runs before assignment, using a multi-strategy resolver that falls back from explicit owner to project owner to company default, so a finding always reaches a responsible party. The asset’s risk score and severity summary tell the owner where to focus.
The campaign is the coordination layer. It groups related findings into a named, time-bounded, company-scoped program governed by a strict status state machine that moves from draft through active and review to completed or cancelled. Bulk assignment distributes the whole program to the right people in one action and notifies them through FindingAssigned events. Live closure metrics report total, closed, and overdue findings and a closure rate computed from the findings themselves.
The finding detail keeps the granular work accountable with multi-assignee support, automatic status promotion on assignment, and a notes and activity trail. And the Wave Matrix closes the loop by proving across successive scans whether a fix held or quietly reopened.
That is what it means to turn findings into finished work. Not a queue that someone hopes will drain, but an owned, grouped, assigned, tracked, and verified path from new to closed. If your team is the one expected to close findings, that path is the whole point.
To see how the inventory and risk side feeds this workflow, read the asset inventory datasheet. To build your first campaign end to end, follow the remediation campaigns from draft to done guide. For broader remediation practice, the guidance in NIST SP 800-40 Rev. 4 and CIS Controls v8 Control 7 on continuous vulnerability management both reinforce the ownership and closure discipline PMAP encodes.
