Overview
The service starts with what you already have. Telemetry sources are reviewed for coverage gaps, noisy rules are tuned or removed, and detections are engineered against the techniques that apply to your stack and sector, rather than shipping a vendor default ruleset and calling the resulting noise “visibility”.
From there, alerts are triaged by analysts before they reach you. What arrives is an investigated conclusion with evidence and a recommended action, not a notification asking you to go and look. Threat intelligence feeds the process continuously, but only in the form that helps: as new detection content, not as a report nobody has time to read.
Engagement at a glance
- Model
- Detection engineering and triage on your existing SIEM or EDR
- Onboarding
- 2 to 4 weeks: telemetry review, baselining, detection build
- Coverage
- Business hours or 24/7, agreed at contract
- You keep
- All detection content: it is written into your platform, not ours
- Intelligence
- Sector and stack-specific, translated into detections rather than PDFs
- Reporting
- Monthly detection coverage against MITRE ATT&CK
What is covered
Every item below is tested and recorded, so the report shows what held as clearly as what failed.
- Telemetry and log source coverage assessment
- SIEM tuning and false-positive reduction
- Detection engineering against MITRE ATT&CK
- Alert triage and investigation
- Threat intelligence enrichment
- Sector-specific intelligence monitoring
- Escalation with recommended containment
- Monthly detection coverage reporting
- Detection content handover and ownership
- Purple-team validation of detections
- Onboarding of new log sources
- Incident escalation into DFIR
Test matrix
What is attempted in each class, and what it means when it works.
| Class | What is attempted | Typical impact |
|---|---|---|
| Coverage | Which ATT&CK techniques your current telemetry could evidence at all | Blind spots identified before an adversary finds them |
| Signal quality | Every existing rule assessed for true-positive rate; noisy rules tuned or retired | An alert queue small enough that alerts get read |
| Detection depth | Behavioural detections written for your stack, not signature defaults | Detection that survives an attacker changing tools |
| Triage | Alerts investigated against context before escalation | Escalations that arrive with a conclusion attached |
| Intelligence | Sector and stack threats translated into detection content | Relevance instead of a feed of unactionable indicators |
| Validation | Detections tested by simulating the technique they claim to catch | Proof the rule fires, rather than an assumption |
What we commonly find
Ninety per cent of alerts from three rules
Almost every estate has a small number of rules generating the volume that makes the rest invisible.
Log sources that stopped six months ago
Ingestion silently broken, discovered only when someone asks a question the missing data would have answered.
Detections nobody ever tested
Rules assumed to work that do not fire when the technique is executed. Validation is not optional.
Intelligence with no route to action
Feeds consumed and filed, never converted into a detection. Intelligence that does not change a rule changed nothing.
How the engagement runs
Scoping and threat modelling
Map the asset, the attacker profile, and what “compromised” actually means for this business. Rules of engagement, testing windows, excluded techniques and an escalation contact are agreed in writing before anything is sent.
Reconnaissance and surface mapping
Enumerate everything reachable: subdomains from multiple passive sources, every endpoint referenced in JavaScript bundles, exposed services, third-party integrations, and the assets nobody remembers deploying. Coverage is recorded per host, so what was not tested is as visible as what was.
Manual exploitation
Authenticated testing from every role, with at least two accounts per role. Business logic, authorisation boundaries, injection, race conditions and state transitions, with each candidate reproduced live before it is written down. Automated tooling contributes coverage; it never contributes findings.
Verification and impact
Every finding is reproduced in a fresh session, isolated to the single parameter that causes it, and pushed to its maximum realistic impact. A finding that cannot survive a clean-room reproduction does not appear in the report.
Reporting and retest
The report is written twice over: once for the engineer who has to fix it, once for the auditor who has to file it. A walkthrough session follows, then a retest of every finding, closed only when re-exploitation fails.
What you receive
Executive summary
One page for the people who approve budget: what was tested, what was found, what it means in business terms.
Technical findings
Each finding with severity, CVSS, affected component, full request and response, reproduction steps and a working proof of concept.
Attack chains
Where findings combine, the chain is written out end to end, from first request to demonstrated impact.
Remediation guidance
A specific fix for your stack and framework, with the corrected pattern, not a link to a generic reference page.
Audit mapping
Findings mapped to SOC 2, ISO 27001, PCI DSS, HIPAA and OWASP ASVS as applicable, so the report drops straight into an audit pack.
Retest and attestation
Every finding retested in a clean session after remediation, with a signed attestation letter for customers and auditors.
When to run it
- When you have tooling and telemetry but not the headcount to watch it.
- When alert volume has reached the point where alerts are routinely ignored.
- After an incident, when detection gaps have become concrete and funded.
- When a customer, regulator or insurer expects continuous monitoring.
Questions
Do we have to change our SIEM?
No. The service runs on your existing platform, Sentinel, Splunk, Elastic, Chronicle, or an EDR-native console. You keep the data and the detection content; there is no proprietary platform to migrate onto and none to be locked into if the relationship ends.
What happens if you find a real incident?
You are contacted immediately with what we know and a recommended containment action, and the engagement can escalate straight into forensics and incident response without a new procurement cycle, which matters when the clock is the expensive part.
Is this 24/7?
Both models are available and it is a genuine cost decision, so we scope it honestly: 24/7 makes sense when your exposure is continuous, and business-hours coverage with defined out-of-hours escalation is sufficient for many organisations.
What do we keep if we stop the service?
Everything. Detection content is written into your platform as we build it, documented, and yours permanently. We do not hold your detection capability hostage to the contract.
How much does managed detection cost?
Pricing follows log volume, estate size and coverage hours. Business-hours coverage with a defined out-of-hours escalation path costs materially less than 24/7, and for many organisations it is the right answer. We will say which applies to you rather than defaulting upward.
How quickly do you respond to an alert?
Response times are agreed in the service definition and reported against, not promised loosely. Critical alerts are triaged and escalated to your named contact immediately; lower-severity alerts follow the agreed schedule. You receive the measurement, including the times we missed.
Do you replace our security team?
No. The service covers detection engineering, triage and escalation so your team stops reading raw alerts and starts acting on qualified ones. Decisions about your systems stay with you, because they should.
How do you reduce false positives?
By engineering detections against your environment rather than shipping a vendor rule set unchanged. Every rule is tuned to your estate and validated by executing the technique it claims to catch. A rule that has never been tested against the behaviour it targets is an assumption, not a detection.
Can you integrate threat intelligence?
Yes, filtered to what applies to your sector and stack. Generic feeds generate volume; intelligence that reflects who actually targets organisations like yours generates detections. The difference is whether the output changes what your team does on a Tuesday.