Should cloud security findings be handled as tickets or as campaigns?

Why This Matters for Security Teams

Cloud findings rarely stay isolated. A misconfigured key, an over-permissioned role, or an exposed secret often shows up across many accounts, services, and pipelines, which makes one-off tickets a poor fit for the remediation work itself. Security teams that treat every finding as a separate queue item tend to lose the pattern behind the issue: the control gap is usually systemic, not individual. That is why campaign-based handling is often the better operating model for repeat cloud findings, while tickets remain appropriate for urgent, time-sensitive fixes. This aligns with the control-first approach reflected in NIST Cybersecurity Framework 2.0, which emphasizes outcomes over isolated tasks. NHIMG research on the Ultimate Guide to NHIs shows how non-human identity sprawl turns a single weakness into a repeated exposure pattern. In practice, many security teams discover the campaign after the same failure has already appeared in multiple clouds, rather than through intentional control design.

How It Works in Practice

A practical model is to route findings by remediation intent, not just by severity score. Tickets should be used when an issue has a clear owner, a narrow blast radius, and an immediate fix path, such as revoking an exposed secret or patching a critical internet-facing misconfiguration. Campaigns are better when the same root cause appears repeatedly and needs coordinated work across platform, security, and engineering teams. That usually means grouping findings by control objective, such as secret rotation, privilege reduction, logging coverage, or storage exposure. Then the campaign can track one remediation plan across many assets, with the ticketing system still used underneath to assign tasks. This is especially useful for NHI-related issues, where one leaked credential can drive follow-on abuse across cloud services, as seen in NHIMG coverage of the LLMjacking pattern and the DeepSeek breach. When secrets are involved, the operational problem is often not detection but containment and reuse prevention, which is consistent with the findings in The State of Secrets in AppSec. A useful structure is:

• One campaign owner for the control objective
• Child tickets for each asset, account, or team action
• Clear success criteria, such as 100% key rotation or removal of legacy privileges
• Time-boxed checkpoints to measure progress and residual exposure

This approach also improves executive reporting because leaders can see whether the organisation is reducing a class of risk, not just closing alerts. These controls tend to break down when ownership is fragmented across business units and no one can enforce a shared remediation deadline.

Common Variations and Edge Cases

Tighter campaign management often increases coordination overhead, so organisations have to balance speed of closure against the cost of cross-team dependency. That tradeoff becomes important when a finding is both urgent and thematic, because not every issue should wait for a broader program. There is no universal standard for this yet, but current guidance suggests using a hybrid model. Handle active exploitation, exposed credentials, and high-likelihood intrusions as tickets first, then roll repeated findings into campaigns once the immediate risk is contained. That avoids delaying emergency response while still preventing security teams from drowning in duplicate work. Campaigns also work best when the issue maps to a measurable control, not an abstract concern. For example, a cloud campaign can target excessive IAM permissions, exposed storage, or stale secrets across environments, while a ticket handles one specific broken resource. NHIMG research on the 230M AWS environment compromise illustrates how scale turns a single control weakness into an operational program. For governance, this lines up with the intent of NIST CSF 2.0: define the outcome, measure progress, and keep remediation tied to risk reduction rather than backlog volume.

Related resources from NHI Mgmt Group

• How should teams connect cloud security findings to IaC remediation workflows?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities in cloud environments?
• How can teams tell whether cloud data security controls are actually reducing risk?