A while back one of our customers asked us a fair question. When was the last time we came under real attack, and did you defend us? Then he answered it himself. He didn't know, because he couldn't see it.
He wasn’t complaining. He was describing a problem the entire detection and response market category has. Detection and response works best when it interrupts an attack early, and an attack interrupted early produces no story. There is no outage to point at, no ransom note, no board update. The service is working and the evidence is a quiet month.
The trouble is that a broken service also produces a quiet month.
So the question is not whether things have been quiet. It is whether you can tell the difference between quiet and blind. That’s a question you can answer, and it should just take one email. I’ll tell you exactly what that one email is below.
Most security spending leaves something you can point at. A firewall has a rule set you can read. A vulnerability scanner produces a number that moves week to week. A backup either restores or it does not, and you can test that on a Tuesday afternoon.
Detection and response is different. Its product is an absence. When it’s working, an intrusion attempt is identified and stopped somewhere in the first few steps, before it becomes an incident anyone outside IT would recognize.
That means the usual instinct, judging a service by how much you hear from it, is exactly backwards. A provider that sends you a lot of alerts is not necessarily catching more. They may simply be forwarding raw output and letting you sort it.
Judge the service by what it can show you on demand instead. Not what it sends you unprompted, and not what it says in a quarterly business review. What it can produce when you ask.
There are three explanations for a quiet month, and from the outset they look identical:
Only the third one should worry you. It’s the one that leaves no trace. Telling the three apart requires evidence.
One thing to be careful about here. If you ask a provider what they saw in some part of your environment and they tell you plainly that they see nothing there, that's probably an honest answer and honesty is worth something. It's not coverage. Credit the candor and then go measure the gap.
Measuring it isn’t difficult. Ask how many assets are actively monitored, then compare that number against something independent: your DHCP lease count, your switch port inventory, your identity provider's user count. If the numbers diverge materially, part of your quiet is a blind spot, not a defended perimeter.
Four things. If your provider can’t produce these for the last ninety days within a few days to a week, that is the finding.
We don't clear all four of these completely ourselves yet. We're publishing the list anyway. Most vendors only publish a checklist they already pass, which is exactly what makes those lists useless.
A current list of the telemetry sources being ingested, by type. Endpoint, network, identity, SaaS, cloud, email. Not which ones are supported, which ones are live in your environment.
Then the count of monitored assets, and how it changed since last month. Then the part most providers do not volunteer: what stopped reporting, and when. Sensors go quiet. Agents fall off during hardware refreshes. A log source breaks after a firewall upgrade and nobody notices for six weeks. Silent sources are the most common failure in this category and they are invisible unless somebody is watching for them specifically.
Validated incidents, not raw alert volume. Alert counts measure how noisy your environment is, not how well it’s being defended.
For each validated incident you should be able to see the technique involved, mapped to a public framework such as MITRE ATT&CK, so the finding means the same thing to you, to your provider, and your cyber insurer (if you have one).
You should also see disposition. Contained, escalated to you, determined benign, or tuned out as a known-good behavior. And, you should see how long it took to go from first signal to confirmation that it was real.
This is where the word 'managed' either means something. Or doesn’t.
For each incident where action was taken, you should see what the action was. A host isolated. A process killed. A domain or IP blocked at the firewall. An account disabled or its tokens revoked.
You should see which system executed it, because response happens through enforcement points you already own.
And you should see who authorized it. Automated under a policy you approved in advance, directed by a named analyst, or handed to your team as a recommendation. All three are legitimate models. Not knowing which one you have isn’t.
Detection logic goes stale. Your environment changes, your users change what they do, and attacker techniques move.
Ask what rules were added, what was retired, and what sources of recurring false positives were removed. A service with no tuning record is running roughly the same logic it started with, which means its accuracy has a half-life.
Send one email. Ask for the last ninety days across those four categories. Don't schedule a meeting, Don't accept a slide summarizing it. Ask for the underlying records.
Three things to watch:
Then run a second, smaller test. Pick one incident and ask to walk it end to end. What was the first signal? What other telemetry corroborated it? What did the analyst conclude and why? What action followed? What changed afterward so the same thing is caught faster next time? A provider who can do that for one incident can almost certainly do it for all of them.
Alert counts with no dispositions attached.
A dashboard screenshot in place of a record. Dashboards show current state. You asked for history.
"No incidents this period," presented without a coverage figure next to it. On its own that sentence is unfalsifiable.
Response described entirely as recommendations, when the contract implied containment.
Nothing attributable to a person.
A tuning section that says "ongoing."
None of these prove the service is bad. They prove you can’t verify it. When you are the one who has to answer for the environment, unverifiable and unknown are the same condition.
Is a quiet month a bad sign?
No. Quiet is the intended outcome. It’s only a problem when you have no way to confirm the quiet is real, which is what the four requests above are for.
How long should this take my provider?
A few days to a week for a ninety-day summary. The material is a byproduct of doing the work, so it should already exist rather than need building.
Is this different from my monthly report?
Usually. Monthly reports (in our case Monthly Touch Points which are Zoom calls, not an email or voice mail from a customer service bullpen) tend to summarize activity. This asks for underlying records, particularly coverage changes and response authorization, which summaries often leave out.
What if my provider only monitors endpoints?
Then coverage is the first thing to check. Ask what percentage of your identity, network, and SaaS activity is in scope. An endpoint-only service can be excellent in and of itself, but still leave the majority of your attack surface unobserved.
Can I ask for this mid-contract?
Yes. It is a request for records of work already performed and paid for. A provider treating it as an unusual ask is telling you something.
What does Gradient Cyber produce today?
Every validated incident becomes a SitRep from a verifiable system judgment or named Cyber Analyst: the telemetry that supported it, the technique mapped to MITRE ATT&CK, a severity and confidence rating, the containment actions taken or recommended, and who authorized them. The record exists per incident, in detail.
Quorum AI handles detection and correlation across endpoint, network, identity, SaaS, and cloud. What gets human review is governed by confidence and severity rather than by volume: QAI resolves what it can resolve with high confidence, and a Cyber Analyst reviews anything ambiguous and anything that would change your environment.
Coverage is reported source by source, including sources that went quiet and who owned the fix, and it names us when the fix was ours. Data feed monitoring is not a static business. We are always finding new ways to improve on this one.
Where we are still building: the rolled-up ninety-day view across all four. The detail lives in the SitReps today and we assemble the summary on request. Detection logic is tuned continuously, and a customer-visible tuning log is the next piece of that reporting.
Run these four requests against whoever watches your environment today, including us if we are the ones watching it. The answers are more useful than any quarterly review, and the time it takes to get them tells you nearly as much as the answers do.