A security operations center produces thousands of alerts a day. Most of them mean nothing. A failed login from a tired employee, a scanner probing a public IP, a backup job that triggered a file-integrity rule, an antivirus quarantine that already did its job. The hard part of detection is not collecting these events. Collection is easy and most tools do it well. The hard part is deciding which handful of those events describe an actual person trying to do harm inside your environment, and then acting before that person reaches anything that matters. That decision, made correctly and quickly, is the entire value of threat detection and response. Everything else is overhead.
We run threat detection and response for regulated companies, and we will be direct about what the work actually is. It is not a dashboard. It is not a feed of red and yellow tiles that someone glances at between meetings. It is the disciplined separation of signal from noise, repeated every hour of every day, by people and tuned systems that know your environment well enough to tell the difference. This post explains how that separation works, what you should expect to receive, where the trade-offs sit, and how detection ties into the regulatory obligations now in force across the EU. The point is not to sell you alerts. The point is to find the one event that matters and contain it before it becomes an incident you have to report.
What threat detection and response actually means
Threat detection and response is the continuous practice of watching your environment for evidence of an attacker, confirming whether that evidence is real, and taking action to stop the attacker before damage spreads. The category goes by several names. Managed detection and response, or MDR, describes the service when an outside team runs it for you. Extended detection and response, or XDR, describes the technology that correlates signals across endpoints, identity, network, and cloud. The label matters less than the function. You are paying for someone to notice an intrusion in progress and to do something about it while there is still time to act.
This is different from prevention and different from testing. Prevention tools try to block known bad things at the door. Testing, such as penetration testing, tells you where the doors are weak before an attacker finds them. Detection assumes that prevention will sometimes fail and that an attacker will get inside, because over a long enough timeline both of those things happen to everyone. Detection is the layer that catches what made it past the wall. If you want to understand how detection complements offensive work, our overview of managed detection and response goes deeper on the operating model, and pentest versus scan explains why point-in-time testing alone leaves a gap that only monitoring can close.
Why most alerts are noise
Security tools are tuned to be sensitive because vendors are judged on what they miss, not on what they over-report. A tool that stays quiet during a real attack is a failed product. A tool that fires constantly is merely annoying. So the default settings on every detection product lean loud. The result is that a mid-sized environment generates tens of thousands of events per day, and the overwhelming majority describe normal behavior that happens to match a broad rule. An administrator running PowerShell looks a lot like an attacker running PowerShell. A developer spinning up cloud resources looks a lot like an attacker establishing persistence. Without context, the tool cannot tell them apart, so it flags both.
Noise is not a minor inconvenience. It is the mechanism by which real attacks succeed. When a team faces a flood of low-quality alerts, it stops reading them carefully. Analysts triage by reflex, close tickets in bulk, and learn to assume that the next alert is also nothing. The single alert that described the actual breach sits in the same queue as nine hundred that did not, and it gets closed with the rest. Alert fatigue is the most reliable ally an attacker has, and it is entirely self-inflicted by environments that buy tools and never tune them.
An alert no one trusts is not a control. It is a record that the signal was available and was not acted on.
The signals that actually matter
The job is to find the events that describe an attacker progressing toward a goal, and those events have a shape. They are rarely loud on their own. A real intrusion shows up as a sequence of small, individually plausible actions that only become alarming when you read them together and in order. The skill is correlation across time and across data sources, mapped against how real attackers actually operate. We use the MITRE ATT&CK framework as the shared vocabulary for this, because it describes attacker techniques as observed in the wild rather than as theory.
- Identity anomalies, such as a successful login from a new country followed within minutes by the creation of a new privileged account or a change to multi-factor settings, which together suggest an account takeover rather than a traveling employee.
- Lateral movement, where one machine suddenly begins authenticating to many others it has never touched, often using valid stolen credentials that no prevention tool will flag because the credentials are technically correct.
- Persistence behavior, including new scheduled tasks, registry run keys, or cloud service principals created outside normal change windows, which an attacker establishes so they can return after you reboot or rotate a password.
- Command and control traffic, meaning a host beaconing to an external address on a regular interval with small, consistent payloads, a pattern that looks nothing like a human browsing and everything like malware phoning home.
- Data staging and exfiltration, where large volumes of files are compressed, moved to a single location, and then pushed to an external destination, frequently the final step before a ransomware demand or a regulatory breach notification.
- Defense evasion, such as security logging being disabled, endpoint agents being stopped, or audit policies being changed, which is almost never something a legitimate user does and almost always something an attacker does to buy time.
How the process works, step by step
Detection and response is a pipeline, and each stage exists to reduce volume and increase confidence. The goal of the early stages is to throw away noise responsibly. The goal of the later stages is to act fast on what remains. Here is the sequence we run, and what each step is for.
- Collection, where we ingest telemetry from endpoints, identity providers, firewalls, cloud control planes, and critical applications, because you cannot detect what you cannot see and gaps in coverage are where attackers live.
- Normalization and correlation, where raw events from different tools are translated into a common format and stitched into timelines, so that a login, a process launch, and a network connection become one story instead of three unrelated tickets.
- Detection logic, where rules and behavioral models flag sequences that match known attacker techniques, tuned to your environment so that your administrators and your automation do not trip the same rules every day.
- Triage, where an analyst examines a flagged sequence, gathers surrounding context, and decides within minutes whether it is benign, suspicious, or confirmed malicious, which is the step that separates a service from a software license.
- Investigation, where a confirmed or strongly suspicious event is expanded into its full scope, answering how the attacker got in, what they touched, and whether they are still active.
- Response, where we contain the threat by isolating a host, disabling an account, or blocking a destination, and then work through eradication and recovery so the attacker is removed rather than merely paused.
- Tuning, where every closed case feeds back into the detection logic, so a false positive seen once becomes a rule that never fires again and a missed technique becomes a rule that catches it next time.
What you actually get as a buyer
When you buy detection and response, you are buying outcomes and evidence, not access to a console you will never open. A serious engagement should hand you concrete deliverables that hold up under audit and under pressure. Vague promises of round-the-clock monitoring are not deliverables. The following are.
- Defined coverage, meaning a written inventory of which systems, identities, and cloud accounts are monitored, because undocumented coverage is the same as no coverage when an incident reaches the part you forgot to onboard.
- Service level commitments for time to acknowledge and time to respond, stated in minutes for critical detections, so you know the actual speed you are paying for rather than a marketing phrase.
- Documented response authority, specifying exactly what actions the team may take on your behalf without waiting for approval, which is the difference between containing a breach at 3am and watching it spread while someone tries to reach an on-call manager.
- Investigation reports for every confirmed incident, written so a regulator, an auditor, and your board can each understand what happened, what was contained, and what remains to be fixed.
- Regular detection coverage reviews mapped to MITRE ATT&CK, showing which attacker techniques you can currently see and which you cannot, so the gaps are a decision you made rather than a surprise you discover during a breach.
- Tuning metrics over time, including false positive rates and the volume of alerts suppressed, which prove the service is getting quieter and sharper rather than simply forwarding raw tool output to your inbox.
In-house, outsourced, or hybrid
Building detection in-house gives you control and deep knowledge of your own environment, but it is expensive and hard to staff. Continuous monitoring requires coverage around the clock, which means several skilled analysts, a tuned platform, and a manager who keeps the detection logic current as your environment and the threat landscape change. For most mid-market companies, that team is difficult to hire and harder to retain, because experienced analysts leave for larger employers and the night shift burns people out. The math rarely favors building from scratch unless detection is core to what you sell.
Outsourcing to a managed service trades some control for coverage, speed, and a team that sees attacks across many environments and brings that pattern recognition to yours. The risk is a provider that ships you raw alerts and calls it a service, which simply relocates the noise problem to your inbox. A hybrid model, where your staff own business context and incident decisions while an external team runs the around-the-clock watch and the tuning, works well for regulated firms that need control over response but cannot justify a full internal operation. Whichever you choose, the test is the same. Ask how they separate signal from noise, and ask to see the false positive rate. The honest answer to both questions tells you almost everything.
How often and how fast
Detection is continuous by definition. There is no monthly cadence, because attackers do not schedule themselves for business hours, and many deliberately choose nights, weekends, and holidays precisely because they expect no one to be watching. What does run on a cadence is the work around the watch. Detection rules should be reviewed and tuned continuously as cases close, coverage against ATT&CK should be reassessed at least quarterly, and the whole response process should be tested with a realistic exercise at least twice a year. Speed is the metric that matters most during an actual event. The gap between when an attacker gains access and when you contain them determines whether you have a contained intrusion or a reportable breach, and under current EU rules that distinction carries a clock you cannot stop.
Common mistakes and red flags
Most failed detection programs fail in predictable ways. We see the same patterns across companies that bought good tools and still got breached, and the patterns are almost always about people and process rather than technology. Watch for these.
- Buying a platform and assuming it works out of the box, when in reality an untuned detection tool produces noise that trains your team to ignore it within weeks.
- Monitoring endpoints but not identity and cloud, which leaves the most common modern attack paths invisible because credential abuse and cloud misconfiguration leave no endpoint trace.
- Treating detection as separate from response, so an alert is confirmed as a real attack and then sits in a queue because no one has the authority or the runbook to contain it.
- Measuring the service by alert volume, which rewards noise, when the metric that matters is how quickly confirmed threats are contained and how few false positives the team has to wade through.
- Skipping the regular test, so the first time anyone runs the response process end to end is during a genuine incident, when mistakes are expensive and everyone is improvising under pressure.
- Ignoring the connection to testing, when in practice findings from external attack surface management and offensive engagements should directly shape what your detection looks for.
What detection costs, in money and effort
Detection and response is priced on the volume of data ingested, the number of assets and identities monitored, and the response authority you grant. It is an operating cost, not a project, because the threat does not end. The larger and quieter cost is internal. Detection only works when the external or internal team understands your environment, which requires your engineers to explain what normal looks like, to keep asset inventories current, and to respond when the team asks whether an unusual action was authorized. A provider with no context produces noise no matter how good their analysts are. Budget for the relationship, not just the license. The way to think about cost is to compare it against the cost of a breach you detect on day ninety instead of hour one. For a structured view of how security spend scales, our guide to penetration testing cost covers the testing side of the same budget conversation.
How detection ties into compliance
Detection is no longer optional for regulated companies in the EU, and the regulations are specific about timing. The NIS2 Directive requires essential and important entities to detect and handle incidents and to report significant ones, with an early warning due within 24 hours of becoming aware. For financial entities, DORA, in force since January 2025, sets detailed requirements for detecting, managing, and reporting ICT-related incidents on strict timelines. You cannot report what you did not detect, and you cannot meet a 24-hour clock if you find out about the incident from a customer or a journalist three weeks later. Detection is the control that makes the reporting obligation achievable. For the differences between the two regimes, NIS2 versus DORA lays them side by side.
Certification frameworks treat detection as a baseline expectation rather than a maturity bonus. ISO/IEC 27001:2022 addresses monitoring, logging, and event management within its 93 Annex A controls across four themes, and an auditor will expect evidence that you watch your environment and act on what you see. The same is true for the security availability and confidentiality criteria under SOC 2. The distinction worth keeping in mind is that passing an audit is not the same as being able to detect an attacker, a point we make plainly in why SOC 2 is not security. The framework tells you to have detection. It does not make your detection good. That part is engineering.
The work of detection is not collecting alerts. It is finding the one event in a hundred thousand that describes a real attacker, and containing it before it becomes the incident you have to report and explain. That is a discipline of tuning, correlation, and fast decisions, run continuously by people who know your environment. If you want detection that produces contained incidents rather than a louder inbox, start with our threat detection and response service, and when you are ready to scope coverage for your environment, book a scoping call.