Here’s an incident report that is entirely realistic. Read it slowly.
Incident Report: Draft v1
Incident ID: IR-2026-0147 Prepared for: Board Risk Committee, Regulator, Cyber Insurer
1. What happened Our network detection tool flagged unusual outbound traffic from an internal application server at 02:47. The server was later confirmed to be compromised.
2. Initial point of entry Unknown. Possibly the VPN gateway. Possibly a phished credential. We can’t confirm either.
3. Time of initial compromise Unknown. The earliest log we have is from 19 days ago. The attacker may have been present before that.
4. Systems accessed Confirmed: 1. Suspected: several. Cannot rule out others.
5. Data accessed or exfiltrated Unknown. We can see that roughly 4 GB left the network. We cannot say what it contained.
6. Is the attacker still in the environment? We believe not. We cannot prove it.
7. Recommended notification to affected customers Pending. We don’t know who was affected.
If you’ve worked in security for more than a few years, you know this document isn’t far-fetched. Maybe you’ve signed one like it. The painful part is that the detection worked. The alert fired, the tool did its job, and the report still came out full of blanks.
Let me explain why that keeps happening, and what the second version of the same report looks like.
The detection wasn’t the problem
Most NDR buying decisions are made on detection quality: how many threats it catches, how clever the models are, how few false positives it throws. That’s a reasonable thing to care about. But look at that report again. Not one blank is a detection failure. Every one of them is an evidence failure.
Detection answers “is something wrong?” Evidence answers “what exactly happened, to what, and for how long?” Boards, regulators, insurers, and customers only ever ask the second question.
And the clock on that second question is short. India’s CERT-In directions expect certain cyber incidents to be reported within six hours of noticing them. Data protection law expects organizations to be able to explain what happened to personal data. Cyber insurers have started asking pointed questions before they pay. None of these parties will accept “we think so” as a root cause.
Why the blanks happen now more than ever
Attackers aren’t leaving files behind: Modern intrusions lean on stolen credentials, remote admin tools, and legitimate protocols. There may be no malware sample to analyze, only behavior on the wire. If you didn’t record the wire, the behavior is gone.
The entry point often has no agent: VPN concentrators, firewalls, routers, and other edge devices have repeatedly been the way in. You can’t install EDR on them. The only thing watching that door is the network itself.
Encryption hides the contents but not the story: Even when payloads are encrypted, session behavior, handshake details, timing, and destinations carry a lot of meaning, but only if you kept the full record and not a summary of it.
Dwell time outlasts retention: Intrusions often go unnoticed for weeks. If your logs roll over at 14 or 30 days, the first chapter of the story is already deleted by the time you start reading.
Summaries can’t be re-asked: Flow records and metadata are a digest of what happened, written by a system that didn’t know what question you’d ask later. Tomorrow a new indicator is published and you ask, “Did this ever touch us last quarter?” With a digest, you get a maybe. With the original packets, you get an answer.
Now read the same report again
Same incident, same alert at 02:47, but this time the network evidence behind it is complete.
Incident Report: Draft v1 (with full packet evidence)
1. What happened Unusual outbound traffic from an application server, flagged at 02:47. Packet-level review confirmed a staged data transfer to an external host.
2. Initial point of entry Authenticated session on the VPN gateway using a valid but stolen credential, 21 days ago, confirmed by session replay.
3. Time of initial compromise Reconstructed from retained traffic. The first malicious session is identified and timestamped.
4. Systems accessed Four internal systems, with every connection traced and mapped. Nothing else was touched.
5. Data accessed or exfiltrated Specific files and records identified from the actual transferred content. Scope confirmed, not estimated.
6. Is the attacker still in the environment? No active sessions. Retroactive search for the attacker’s infrastructure across all retained traffic returned no further contact.
7. Recommended notification Affected customer list generated. Notification can begin immediately.
Read the two reports side by side. The attacker is the same, the intrusion is the same, and even the detection tool is the same. The only difference is whether anyone kept the receipts.
“Isn’t storing all that traffic expensive?”
It is, and it would be dishonest to pretend otherwise.
Storage is not getting cheaper right now. A large 30TB enterprise hard drive that cost about $495 a year ago now lists above $1,200, and the rise is linked to AI infrastructure demand tightening supply. Flash storage has climbed even faster. If someone tells you storage is cheap, check a current quote.
The answer isn’t to skip capture. It’s to design it sensibly. Nobody serious is suggesting you keep every packet from every segment forever at maximum depth. Good designs are tiered:
- Full packets for a meaningful recent window on high-capacity disk
- Automatic preservation of everything linked to an alert, so key evidence never rolls over
- Priority capture on critical segments: internet edge, data center core, crown-jewel applications
- Indexed metadata for the long tail
Rising prices make that discipline more important, not less. They also make “how efficiently does your platform use storage?” a fair question for any vendor.
Then set the cost against the alternative. The real comparison isn’t “storage versus no storage.” It’s the price of a tiered capture budget versus the price of one incident you can’t explain: over-notified customers, weeks of outside forensics, systems rebuilt unnecessarily, and a regulator or insurer who gets estimates instead of facts. For most organizations, one avoidable incident outweighs the capture budget.
What to ask before you buy any NDR
Take these into your next vendor call. They cut through a lot of dashboards.
- Show me an alert, then show me the exact packets behind it. If the answer is “reconstructed” or “inferred,” note that.
- If a new indicator drops today, can I search traffic from last month? Retroactive hunting is where full packets pay for themselves.
- What can I hand to a regulator, insurer, or court? Evidence and estimates are not the same thing.
- long is the window, and what happens when storage fills? Ask for specifics, not reassurances.
- How does your platform keep storage needs under control? Ask about tiering, retention policies, and how alert-linked traffic is preserved.
The shift in thinking
Stop evaluating NDR as an alarm system and start evaluating it as an evidence system that also raises alarms. The alarm gets your attention. The evidence lets you act, report, recover, and learn.
The teams that come through incidents best are rarely the ones with the most alerts. They’re the ones who can fill in every blank, quickly and with confidence.
Where Vehere comes in
At Vehere, full packet capture (PCAP) isn’t an add-on. It sits at the foundation of our NDR. Every detection is backed by the raw network evidence behind it, so your analysts can go from “something looks wrong” to “here is exactly what happened” without switching tools or piecing together guesses. That means faster triage, retroactive threat hunting across stored traffic, forensic-grade investigation, and a report you can sign without a single “unknown.”
The next time an alert fires at 02:47, make sure the report that follows has no blanks.
Talk to the Vehere team to see how NDR with full packet capture (PCAP) works on your network, including a realistic retention and storage plan, and what your next incident report could look like.
