Security operations: an operating model beyond alert queues

Design around outcomes

Define protected services, likely threat paths, response expectations and required coverage. Align detections to attacker behaviour and business impact rather than vendor alert counts.

Create service-level objectives for high-priority triage, escalation and containment, with realistic differences between business hours and on-call coverage.

• Critical service coverage
• Threat-informed detection priorities
• Triage and escalation targets
• Named containment authority

Build the operating functions

Core functions include telemetry engineering, detection engineering, alert triage, investigation, threat intelligence, incident coordination and automation. They may sit in one team or several, but handoffs must be explicit.

Keep detection content under version control with tests, owners and review dates. Treat runbooks as products that improve after use.

• Telemetry onboarding
• Detection content lifecycle
• Case management and evidence
• Threat hunting and intelligence
• Incident command and communications

Balance people, process and technology

Analysts need protected time for engineering and learning, not an endless queue. Automate enrichment and repeatable low-risk actions while keeping human judgement for ambiguity and impact.

Shift design to reduce noisy sources and improve context. Hiring more analysts to absorb bad alerts is an expensive workaround.

• Tierless collaboration for complex cases
• Automation with rollback and audit
• Regular analyst calibration
• Healthy on-call and shift design

Measure whether operations changes risk

Measure detection coverage, data health, investigation quality, containment time, recurrence and control improvements. Alert volume alone rewards noise.

Review missed and low-value detections. Connect incident findings to owners in engineering, identity, cloud and business operations.

• Time to reliable scope
• Time to containment
• Useful detection rate
• Repeat incident reduction
• Control improvements closed

A practical 30-day field plan

Week one — Observe. Collect reliable, relevant telemetry. Put one accountable owner in the room, agree which business service or decision is in scope, and record the assumptions the team is making. Resist the urge to begin with a technology purchase; the first deliverable is a shared view of the problem and the authority to change it.

Week two — Detect. Identify behaviour that deserves investigation. Walk through the current process with the people who operate it. Compare the written design with real access paths, data flows, exceptions and on-call practice. Mark every point where an owner is missing or where the team cannot produce evidence that a control works.

Week three — Decide. Triage, scope and choose containment. Choose a narrow pilot that can be observed safely. Define the expected result, the rollback path and the person who may accept a trade-off. Capture operational friction as product feedback; controls that are difficult to use will eventually be bypassed.

Week four — Improve. Recover, learn and strengthen controls. Review the pilot with engineering, operations, security and the service owner. Close urgent gaps, assign longer work to a funded backlog and set the next evidence review. The month should end with a repeatable operating rhythm, not a one-time presentation.

Evidence worth keeping

Good evidence is understandable outside the team that created it. Keep a concise record that connects the decision, owner, technical implementation and observed result. Screenshots can support evidence, but configuration, logs, test output and approved records are stronger because another person can reproduce or challenge them.

• Critical service coverage — owner, current state, last validation and any open exception
• Telemetry onboarding — owner, current state, last validation and any open exception
• Tierless collaboration for complex cases — owner, current state, last validation and any open exception
• Time to reliable scope — owner, current state, last validation and any open exception
• Decision log showing who approved residual risk and when it will be reviewed
• Test or exercise result with the actual outcome, not only a pass label

Questions for the leadership review

Use these questions to keep the discussion connected to operating risk rather than tool activity. A useful answer names a person, a service and evidence.

• Who is accountable for the security operations outcome when teams disagree about delivery and risk?
• Which critical service or customer promise would be affected by a failure in this area?
• What evidence would tell us the design is working in production today?
• Which exception creates the largest concentration of access, dependency or recovery risk?
• What would the team contain first, and how would it restore a trustworthy service?
• Which improvement can be completed in the next 30 days without waiting for a large programme?