When should teams use security campaigns instead of individual remediation tickets?

When a campaign is the right unit of work

A campaign is the better choice when the real problem is a shared control failure, not a pile of unrelated one-off bugs. Treat the campaign as one coordinated remediation effort when multiple findings collapse to the same fix pattern, the same ownership boundary, or the same release window. That lets teams plan once, execute in sequence, and measure closure against a clear scope.

Campaigns also fit situations where the remediation work has dependencies that make isolated tickets inefficient. For example, a single configuration change, library upgrade, credential rotation, or policy update may resolve many findings at once. In those cases, ticket-by-ticket handling creates duplicate coordination and makes it harder to see whether the underlying control gap is actually being closed.

Use this model for work that benefits from a named owner, a defined finish line, and a shared delivery cadence. When fixes need to land in a sprint, a change window, or a release train, a campaign gives engineering and security the same operating container. That is usually more effective than letting each finding compete separately for attention.

When individual tickets are still the better choice

Individual remediation tickets work best when findings are genuinely independent, have different owners, or follow different remediation paths. If one issue can be fixed without touching the others, bundling it into a campaign can slow down closure rather than improve it. Separate tickets also help when the work is routine, low effort, and unlikely to benefit from joint planning.

Tickets are also the right choice when the findings differ in urgency or blast radius. A high-severity issue that needs immediate action should not wait for a broader campaign to form. Likewise, if only part of the set can be remediated quickly and the rest depends on later architectural work, splitting the work can make prioritization clearer.

The practical test is whether combining the work improves delivery or merely adds process. If the only thing the findings share is a broad label, keep them separate. If they share a common root cause, common dependency, or common deployment path, a campaign usually creates better execution discipline.

How to draw the boundary between campaign and ticket

Start by asking whether the findings would naturally close together if the underlying control gap were fixed once. If the answer is yes, a campaign is usually the right wrapper. If closing one finding tells you almost nothing about the others, individual tickets preserve clarity and avoid false grouping.

Campaigns are most useful when the team can define scope in operational terms: which systems, teams, environments, and fixes are included, and what counts as done. That scope should be narrow enough to manage and broad enough to capture the shared remediation pattern. The point is not to centralize everything, but to reduce fragmentation where fragmentation adds no value.

For campaign-style work, the most important discipline is traceability. Each finding still needs to be attributable to the campaign, and the campaign still needs enough detail to show what was fixed, what remains open, and where exceptions were accepted. Without that discipline, a campaign becomes a reporting convenience instead of a control mechanism.

Risk and Threat Considerations

Campaigns reduce fragmentation, but they also create concentration risk if teams make them too broad or too slow. A large campaign can mask urgent items, delay high-priority fixes, or encourage the assumption that “work is underway” even when the most important exposure remains open.

Failure mechanism: Teams over-aggregate findings that do not truly share a control gap, then let the campaign inherit the weakest scheduling constraint. That can postpone remediation for critical issues, obscure ownership, and make progress look better than it is.

Impact: The organisation may carry a larger exposed surface for longer, miss due dates, or lose visibility into which findings are actually remediated versus simply grouped together. That matters most when the campaign bundles issues with different severities or different exploitation paths.

Practitioner Guidance

What to prioritise: Group findings only when the remediation action is materially the same, the owner can stay the same, and the delivery window is shared. If any of those three differ, the grouping should be questioned.

What to verify: A campaign should have a single root cause statement, a defined set of included findings, and a clear rule for exceptions. If you cannot explain why each finding belongs in the campaign, the campaign is probably too broad.

Practitioner takeaway: Use campaigns to manage one fix pattern at scale, not to hide unrelated work behind a common label; the best campaign is the one that makes remediation clearer, faster, and easier to verify.

Related resources from NHI Mgmt Group

• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams use IAST and RASP in NHI governance?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?