They should do both, but workflow redesign should be prioritised when the queue consistently outruns analyst time. Tuning removes avoidable noise, while workflow changes preserve decision quality for the alerts that still require human judgment. If capacity is the bottleneck, tuning alone only postpones the problem.
Why this is a workflow question before it is a tuning question
If alert volume regularly exceeds analyst capacity, the limiting factor is the operating model, not just rule quality. Tuning can reduce avoidable noise, but it does not fix queue design, handoff friction, prioritisation logic, or the amount of human judgment required per alert. A SOC that preserves the same workflow while trimming detections usually delays overload rather than removing it.
Good tuning and workflow redesign solve different problems. Tuning improves signal quality at the source, while workflow redesign changes how the team absorbs, routes, enriches, and closes work. When those two layers are aligned, analysts spend less time on low-value review and more time on decisions that actually need expertise.
SANS Security Resources is a useful reference point for the practical side of detection engineering and SOC operations because the answer depends on both alert quality and execution flow. The right order is rarely either-or in the abstract; it is usually capacity first, then detection refinement in parallel.
What tuning can fix, and what it cannot
Tuning is the right lever when detections are noisy, duplicate each other, or trigger on known benign activity. It improves precision, reduces analyst fatigue, and makes triage more defensible. That said, tuning only helps if the team still has time to review the remaining alerts with care. If the queue is already unmanageable, cleaner detections alone will not restore service quality.
Workflow redesign becomes necessary when the bottleneck sits in triage logic, case routing, enrichment, or escalation. In that situation, the SOC may already be spending too much time deciding what to do with each alert, even after obvious false positives are removed. A better queue structure, clearer severity rules, or narrower ownership boundaries can create more capacity than further rule tuning.
MITRE D3FEND is relevant here because detections only create value when they map cleanly to defensive actions. If an alert does not lead to a repeatable response path, the issue is not just signal quality, it is the absence of a usable operational workflow.
How to decide which lever to pull first
The deciding factor is where the delay comes from. If analysts are drowning in false positives, start with tuning because it removes waste. If alerts are already mostly credible but the team still cannot process them on time, start with workflow redesign because the queue itself is the constraint. In mature SOCs, both are usually required, but the order matters when capacity is tight.
- If the same benign pattern repeatedly drives investigations, tune the detection first.
- If alerts are waiting because of enrichment, ownership, or approval bottlenecks, redesign the workflow first.
- If analysts are missing time-sensitive cases, reduce queue friction before adding more detection logic.
FIRST is relevant because incident response practice is fundamentally about coordination, prioritisation, and handoff discipline. The more fragmented the workflow, the less useful even good detections become under load.
Risk and Threat Considerations
A SOC that relies on tuning alone can create a false sense of control: the alert stream may look cleaner while the underlying process still cannot keep up. When the queue outruns analyst time, delayed triage can let real incidents age unreviewed, increase missed escalations, and push responders into reactive work instead of controlled investigation.
Failure mechanism: Excess alerts consume analyst time, create backlog, and compress the time available for enrichment, correlation, and decision-making. If the workflow still expects too much manual handling per alert, the team loses decision quality even after noise is reduced.
Impact: Material alerts can be delayed, deprioritised, or inconsistently handled, which raises the chance of missed attacker activity, slower containment, and weaker operational resilience.
Practitioner takeaway: The real risk is not noisy detections by themselves, it is a queue model that makes every remaining alert too expensive to handle well.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-8 — Audit Log Management | SOC queue quality depends on usable event visibility and triage signal. |
| CIS-17 — Incident Response Management | The question is about operational response flow under alert pressure. | |
| Recommendation — Centralize and review logs to reduce noisy alerts and speed investigation. Define escalation paths and response roles to keep alerts moving. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitor networks and environments for potential threats | Detection tuning changes how continuously threat signals are monitored. |
| RS.CO-02 — Coordinate response activities with internal and external stakeholders | Workflow redesign is about coordination, handoffs, and ownership under load. | |
| Recommendation — Tune monitoring logic to improve the signal-to-noise ratio. Clarify handoffs and coordination steps to reduce triage bottlenecks. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Analyst queue management depends on how logs and alerts are reviewed and reported. |
| Recommendation — Streamline audit review so high-value alerts receive timely analysis. | ||
Practitioner Guidance
What to prioritise: First measure where time is actually lost, in false positives, enrichment, routing, approvals, or final decisioning. That tells you whether the main constraint is signal quality or workflow capacity.
Decision rule: If backlog is persistent and analysts cannot keep pace, redesign the workflow before chasing another round of tuning. If the queue is manageable but wasteful, tune detections first because you will get faster gains with less operational disruption.
What to measure: Track queue age, analyst touches per alert, escalation delay, and the share of alerts closed as benign. Those signals show whether the SOC is getting cleaner output or merely moving the bottleneck elsewhere.
Practitioner takeaway: The best SOCs do not treat tuning and workflow as competing fixes; they use workflow changes to restore control of the queue, then tune detections to keep that capacity from being consumed again.
Related resources from NHI Mgmt Group
- Should organisations prioritise external exposure or internal credential governance first?
- Should organisations sandbox every risky LLM workflow or redesign it first?
- How should security teams govern non-human identities for SOC 2 compliance?
- How do organisations operationalise NHI ownership at scale?