Case study / Cybersecurity
From alert volume to owned findings.
A security operation that was producing more alerts than it could assess was rebuilt around the clinical services it protects — with triage against written playbooks, remediation routed into owned change records, and the control evidence created by the work rather than assembled for the audit.
- 24 / 7
- assessed operating view
- 71%
- fewer raw alerts reaching the client team
- 100%
- of findings routed to an owned change record
Situation
The context
Capable products had been bought and were emitting continuously. Nobody could state what was covered and what was not, findings arrived as recommendations rather than as work, and each audit was answered by reconstructing six months of activity from memory and mailboxes.
The tooling was not the problem. Nothing turned what it produced into a decision anybody owned.
The first task was not a product change. It was to establish which clinical services were being protected, what coverage actually existed against them, and where a finding was supposed to go once somebody had assessed it.
Intervention
The intervention
Coverage was mapped against clinical services rather than against the estate as a whole, triage moved onto written playbooks so findings arrived assessed, and remediation was routed into the change process the organisation already ran instead of into a separate security backlog.
Coverage
Detection mapped to clinical services, with the gaps named
Triage
Written playbooks, analyst assessment before escalation
Remediation
Findings routed as owned change records to closure
Evidence
Control record produced by the work, not for the audit
Delivery path
Coverage first, then confidence, then automation.
The sequence was deliberate. Automating triage before coverage was understood would have produced faster answers to the wrong question, so each phase had to leave the operation able to state more about itself than it could before.
Weeks 01–04
Baseline
Established which clinical services mattered, what telemetry existed against them, and where coverage was absent rather than merely noisy.
Decision gateCoverage baseline and gap list acceptedWeeks 05–10
Playbooks
Wrote triage playbooks for the recurring finding types, defined escalation thresholds, and agreed what an assessed finding must contain before it leaves the analyst.
Decision gatePlaybook set approved for live useWeeks 11–18
Routing
Connected findings to the change and problem processes so remediation had an owner, a record and a closure state rather than a recommendation.
Decision gateClosure path proven end to endOngoing
Operate and tune
Ran the co-managed operation, reviewed detection quality against outcomes, and retired rules that produced volume without producing decisions.
Decision gateQuarterly detection and exception review
Operating shift
The products stayed. What changed was where a finding goes.
The engagement joined detection, assessment and remediation into one path with an owner at every step. These are the practical shifts the case study is designed to make visible.
FromCoverage described as tooling
→ToCoverage stated per service
What is protected — and what is not — became a sentence somebody could say out loud, including the gaps.
FromAlerts forwarded
→ToFindings assessed
Triage against written playbooks meant the client team received judgements with reasoning, not queue overflow.
FromRecommendations issued
→ToChange records owned
A finding entered the same workflow as any other change, so closure was a state rather than an assumption.
FromAudits reconstructed
→ToEvidence accrued
The control record was created as work proceeded, which made the audit a query rather than a project.
Evidence record
A result with its provenance attached.
The published story keeps the result, the supporting artefact and its limit together.
- 24 / 7
- assessed operating view
- 71%
- fewer raw alerts reaching the client team
- 100%
- of findings routed to an owned change record
Evidence attached
- Service-to-detection coverage map, including named gaps
- Triage playbook set and escalation thresholds
- Finding-to-change-record closure reporting
- Quarterly detection quality and exception review
Capabilities involved
- Continuous security monitoring
- Threat detection and triage
- Vulnerability management
- Incident-response enablement
- Compliance and control evidence
- Security operations enablement
- Nature of the work
- Automation only — rule-based correlation and enrichment. No AI model made or influenced a triage decision.
- Baseline
- Raw alerts forwarded to the client team, and findings closed as change records, over the eight weeks before the playbook set went live.
- Data sources
- The client’s existing SIEM, endpoint and identity telemetry, plus the service-management platform’s change and problem records.
- Human-control point
- Escalation and remediation were approved by the client’s security lead; the change process retained its existing approvers throughout.
- Technology used
- The security products already licensed by the client, the service-management platform, and correlation rules written during the engagement.
- Measured result
- Raw alerts reaching the client team fell by 71%; every finding raised in the measurement period carried an owned change record with a closure state.
- Evaluation period
- Twelve weeks following the routing gate.
How to read these figures
Bring your context
Producing more alerts than you can assess?
Tell us what you are monitoring, what happens to a finding once it exists, and how the last audit was answered. We will start with your environment and be precise about which experience transfers.
- Response
- One working day, Monday to Friday