Remediation work breaks down into two very different shapes. Sometimes you need to track a single fix from assignment to verification. Other times you need to drive an entire program of fixes toward a deadline, watch how many are closing, and report on whether the effort is on track. These are not the same job, and trying to force one tool to do both is where remediation tracking usually falls apart.
The two tools that map to these shapes are the ticket and the remediation campaign. A ticket is a unit of work. A campaign is a unit of coordination. This article explains what each one is, where the conceptual line sits between them, and how to decide which to reach for. It is a definition piece, not a how-to. If you want the step-by-step mechanics of building and running a campaign, that lives in the operational guide linked throughout.
Two different tools for remediation
Before the comparison, it helps to name the confusion. Both tickets and campaigns “track remediation,” so they get treated as interchangeable. They are not. The difference is granularity and intent.
A ticket is granular. It represents one fix that one team or person owns, and it lives in the workflow of your IT service management (ITSM) tool. Its natural unit is a single finding or a tightly related cluster of work. Its lifecycle is the lifecycle of that fix: open, in progress, done.
A remediation campaign is coarse. It represents a coordinated effort across many findings, with an owner, a deadline, and a measurable sense of “how far along are we.” Its natural unit is the program, not the fix. Its lifecycle is the lifecycle of the effort, not of any single vulnerability inside it.
You can think of it this way. The ticket answers “is this one thing fixed yet.” The campaign answers “is this whole push succeeding.” Those questions need different containers, different metrics, and different owners. The rest of this article walks through each container in turn.
What is an ITSM ticket?
An ITSM ticket is a work item in a system of record like Jira, ServiceNow, or ManageEngine. It carries a description, an assignee, a priority, a status, and a history of comments and transitions. In a security context, that ticket is created from a finding and pushed into the ITSM tool so the team that actually performs the fix can work it inside their normal queue.
In PMAP the connection between a finding and a ticket runs through the integration layer. A single ITSM ticket can be created for a finding on Jira, ServiceNow, or ManageEngine, carrying the finding’s title, severity, description, and CVSS into the vendor system. From there the two sides stay in sync. PMAP reconciles vendor-side status back to the finding in two ways. A webhook pushes updates as they happen, and a background poller reconciles every active ITSM integration on a five-minute cadence to catch anything the webhook missed.
That synchronization is the heart of what a ticket does well. The fix happens where the work happens, in the ITSM tool, and the security platform learns about the outcome without anyone copy-pasting status by hand. When a ticket reaches a “done” status, the platform decides what to do with the finding based on configuration. With auto_close_on_resolve set to true, a resolved ticket closes the finding directly. With it left at the default of false, the finding moves to a retest state instead, so a security analyst verifies the fix before the record is closed for good.
The important conceptual point is the scope of a ticket: one fix. It tracks the work of resolving a finding inside the team’s own toolchain. It does not, by itself, tell you anything about the twenty other findings sitting next to it or whether the broader hardening effort is succeeding. For that, you need a different abstraction.
What is a remediation campaign?
A remediation campaign is a named, time-bounded grouping of findings assigned to a responsible owner. It is the primary mechanism for coordinating remediation across many vulnerabilities at once and tracking progress toward closure at the program level rather than finding by finding.
Read that definition slowly, because every word is doing work. Named means the effort has an identity you can refer to, such as “Q3 internet-facing critical reduction.” Time-bounded means it has a start and a due date, so progress can be measured against a deadline. Grouping of findings means it is a container that links existing findings together. A campaign does not create findings. It coordinates the ones you already have. Assigned to a responsible owner means one person is accountable for the whole effort, not just for individual line items.
A campaign is company-scoped, so it lives inside one tenant and never mixes findings across tenant boundaries. That scoping matters for any organization running multiple business units or clients on one platform, because the campaign view stays clean and the owner only sees the effort they are accountable for.
Campaign status workflow
A campaign moves through a defined lifecycle, and the states are enforced rather than freeform. The progression runs:
draft → active → review → completed / cancelledA campaign starts in draft while you assemble the findings and assign the owner. It moves to active when the work is underway. It enters review when the team believes the effort is essentially done and someone needs to confirm closure. From review it reaches completed or, if the effort is abandoned or superseded, cancelled. Both completed and cancelled are terminal. The platform validates each transition against an allowed set, so a campaign cannot skip from draft straight to completed or jump backward in ways that would corrupt the record of how the effort actually unfolded.
This lifecycle is what makes a campaign a program-level construct. The states describe the maturity of an effort, not the status of any single fix. A finding inside the campaign can be open while the campaign is active, and the campaign can be in review while a handful of stragglers are still being verified. The two layers move on their own clocks.
The core difference: granularity and coordination
Here is the distinction in one sentence. A ticket tracks the work of fixing one finding, while a campaign tracks the coordination of fixing many findings as a single effort.
That granularity gap drives everything else. Because a ticket is scoped to one fix, its status is binary in spirit: the fix is either done or it is not. Because a campaign spans many fixes, its status is a measurement: some fraction of the work is closed, some is overdue, some is still moving. A ticket has a status. A campaign has a closure rate.
The second axis is coordination. A ticket coordinates nothing beyond itself. It sits in a queue, gets worked, and closes. A campaign exists precisely to coordinate. It answers questions a pile of individual tickets cannot answer on their own: how many of these findings have we closed, how many are past their due date, and is the owner on pace to hit the deadline. Those are program questions, and they need a program-level container.
A useful test: if the answer to “who owns this” is a single engineer working a queue, you are describing a ticket. If the answer is a manager accountable for an outcome across a set of findings, you are describing a campaign.
How campaigns track progress
The reason a campaign can answer program questions is that it computes progress metrics across all the findings it contains. When you open a campaign’s detail view, PMAP returns a set of computed counters rather than a static list. Those counters are:
- total_findings is how many findings the campaign contains.
- closed_findings is how many of those have been resolved.
- overdue_findings is how many are past their due date and still open.
- closure_rate is the fraction of findings closed, expressed as a number you can track over time.
These metrics are the campaign’s reason for existing. None of them make sense at the level of a single ticket. A closure rate of one fix is either zero or one. A closure rate across two hundred findings tells you whether a hardening program is actually landing. The overdue count tells the owner where attention is slipping before the deadline arrives, not after.
Campaigns also support bulk assignment, which is the operational expression of their coordination role. Instead of assigning two hundred findings to an engineer one at a time, the owner assigns a single user to all of the campaign’s findings, or to a specified subset, in one action. Each affected finding emits an assignment event so notifications fire correctly, but the human only performed one operation. That bulk capability is something a ticket model has no equivalent for, because a ticket is already the unit of assignment.
How tickets track work in the ITSM tool
Tickets track progress in a completely different place and in a completely different shape. A ticket’s progress is its status inside the ITSM tool, and that status is owned by the vendor system, not by the security platform.
This is why the synchronization behavior matters so much. PMAP does not try to model the fix itself. It lets Jira, ServiceNow, or ManageEngine own the work item, then mirrors the outcome back. The webhook and the five-minute poller keep the finding’s view of the ticket honest, so when an engineer transitions an issue to “Resolved” in their tool, the corresponding finding reacts according to the auto_close_on_resolve setting described earlier.
The contrast with a campaign is sharp. A campaign’s progress is an aggregate the platform computes by counting findings. A ticket’s progress is a single state the platform reads from an external system. One is measured internally across many items. The other is mirrored externally for one item. That is the technical shape of the granularity difference, not just a description of it.
Do they compete? No, they compose
The most common misread of “campaign vs ticket” is treating it as an either-or choice. It is not. The two layers compose, and in practice they almost always run together.
A campaign groups findings. Many of those findings will need an actual fix performed by a delivery team, and that fix belongs in a ticket in the team’s ITSM queue. So a single finding can simultaneously be a member of a campaign and be linked to a Jira or ServiceNow ticket. The campaign tracks the program. The ticket tracks the individual fix. Neither one is redundant.
Picture the flow. A security manager creates a campaign for “external attack surface critical reduction” and adds the relevant findings. For each finding that a delivery team must remediate, a ticket is created on the ITSM side so the work lands in that team’s queue. As engineers resolve their tickets, the synced finding status updates, the campaign’s closed_findings counter rises, and its closure_rate climbs toward completion. The manager watches the campaign. The engineers watch their tickets. Both views are correct because they are answering different questions about the same underlying findings.
So the right mental model is not “choose one.” It is “a campaign is the program layer above the ticket layer.” Tickets are how work gets done inside delivery teams. Campaigns are how a security leader knows whether the overall push is succeeding. They stack.
When to use a campaign vs a ticket
With the conceptual line drawn, the decision becomes practical. Reach for a ticket when:
- You need a single finding fixed, and the work belongs in a delivery team’s existing queue.
- The unit of accountability is one engineer or one team working an item to done.
- You need the fix to live in the ITSM tool with full status sync back to the finding.
- There is no broader program you need to measure; the finding is its own scope.
Reach for a campaign when:
- You are coordinating remediation across many findings as one effort.
- One owner is accountable for the outcome of the whole set, not for individual items.
- You need program-level metrics such as closure rate and overdue count to know if the effort is on track.
- The effort has a deadline, and you need to measure progress against it.
- You want to assign a batch of findings to a team in one action rather than item by item.
In most real programs you use both, and the choice is really about which view you are working in at a given moment. The campaign is where you plan and report. The ticket is where the work happens. A finding can sit in both at once, which is exactly the point.
One more practical note. Whether the trigger for a campaign is a service-level deadline or an ad-hoc push changes how you run it, but not what it is. The distinction between deadline-driven and ad-hoc remediation is its own topic. For this article, the key takeaway is simpler. A campaign is the coordination layer; a ticket is the work layer; and the two are designed to compose rather than compete.
Where to go next
If you want the operational walkthrough of building a campaign, assigning findings in bulk, and driving it from draft to completed, read how remediation campaigns run from draft to done. For the mechanics of creating and syncing ITSM tickets from findings, see ITSM ticketing for vulnerability findings. To understand how PMAP connects to Jira, ServiceNow, and the rest of the toolchain, the security integration layer covers the connector model. And if your remediation is driven by service-level agreements, the difference between SLA-driven and ad-hoc remediation is worth reading next.
For broader context on coordinating fixes across an organization, the NIST guide to enterprise patch management (SP 800-40 Rev. 4) frames remediation as a program rather than a series of isolated fixes, which is exactly the gap a campaign fills. The ITIL 4 change and incident practices describe the ticket side of the same coordination problem.
Frequently Asked Questions
What is the difference between a remediation campaign and a ticket?
A ticket tracks one fix as a work item, usually inside an ITSM tool like Jira or ServiceNow. A remediation campaign tracks a coordinated program of fixes across many findings, with an owner, a deadline, and progress metrics such as closure rate. The ticket is the unit of work. The campaign is the unit of coordination.
Can a finding be in a campaign and a ticket at the same time?
Yes. The two layers compose rather than compete. A finding can be a member of a campaign that tracks the overall program while also being linked to an ITSM ticket that tracks the individual fix in a delivery team’s queue. The campaign measures the effort; the ticket carries the work.
What metrics does a remediation campaign track?
A campaign computes program-level counters across all the findings it contains: total findings, closed findings, overdue findings, and a closure rate. These aggregate metrics describe whether the overall effort is on track. None of them apply to a single ticket, because a ticket is one fix rather than a population of fixes.
What is the campaign status workflow?
A campaign moves through an enforced lifecycle: draft, then active, then review, then either completed or cancelled. Both completed and cancelled are terminal states. Transitions are validated against an allowed set, so the record of how an effort progressed stays accurate.
When should I use a campaign instead of a ticket?
Use a campaign when you are coordinating remediation across many findings as one effort, when a single owner is accountable for the outcome, and when you need program-level metrics or a deadline to measure against. Use a ticket when you need a single finding fixed inside a delivery team’s existing queue.
How do tickets stay in sync with findings?
When a ticket is created from a finding, the security platform mirrors the vendor-side status back to the finding. A webhook pushes updates as they happen, and a background poller reconciles every active ITSM integration on a five-minute cadence. When a ticket reaches a done status, the finding either closes automatically or moves to retest for analyst verification, depending on configuration.
Does using campaigns replace my ITSM tool?
No. A campaign is a coordination layer that sits above your tickets, not a replacement for them. The actual fixes still get worked in your ITSM tool, where delivery teams already operate. The campaign groups those findings, tracks closure across the set, and reports on the program while the tickets handle the work.
