Your security team should not be reading logs
Resource · 9 minute read · AEGYS DATALYTICS
In short: When an organisation decides it needs visibility into its own network traffic, the first question is almost always about people. Who is going to look at this? That question leads nowhere useful, because it tries to expand a constraint that does not expand. The workable answer divides the work differently: machines do the reviewing, people do the deciding. This article covers where that line sits and where we deliberately stop.
The instinct is to hire
A mid-sized company running 400 to 600 connected devices produces network traffic continuously. Laptops, servers, printers, cameras, building controls, industrial equipment, phones, the guest network. Everything talks, most of it around the clock.
The team responsible for all of it is usually small, and network visibility arrives as an addition to backups, endpoints, licensing, access requests and whatever broke this morning. So the natural response to a new monitoring requirement is to look for someone to own it.
The ISC2 Cybersecurity Workforce Study 2025 suggests that instinct is aimed at the wrong target. For the first time, ISC2 stopped publishing a headline workforce gap figure, because participants consistently reported that missing skills, not missing headcount, were the more pressing problem. In the same study, roughly a third of respondents said their organisation still could not fund security staffing adequately, while a similar share said they could not hire the expertise they needed even when budget existed.
Hiring is slow, expensive and competitive. And a hire is still one person: eight hours a day, against traffic that does not stop.
The constraint is attention, not volume
Producing network data is trivial. A capture at a single switch generates more lines in an afternoon than a person will read in a career. The constraint sits one level up, at attention.
Attention is the scarcest resource in security operations and the only one that cannot be purchased. It also degrades in a specific way: it wears out against repetition. Someone reviewing a hundred alerts a day, ninety-eight of which are routine, will eventually wave through the other two. That is not carelessness. It is a well-documented property of human perception under sustained load.
This is where technically sound programmes quietly fail. The data is collected, the rules fire, the alerts accumulate. Nobody opens them any more.
What belongs to the machine, and what does not
The workable division follows from what each side is actually good at.
| Task | Where it belongs |
|---|---|
| Capturing network traffic completely, without gaps | Machine |
| Learning normal behaviour and flagging deviation from it | Machine |
| Correlating events across sources in time and logic | Machine |
| Filtering out recurring noise | Machine |
| Judging whether an anomaly has an ordinary explanation here | Person |
| Deciding whether to isolate, block, escalate or wait | Person |
| Carrying accountability to executives, auditors and insurers | Person |
The line runs between reviewing and deciding. Anything that demands completeness, endurance and pattern recognition across volume belongs to a machine. Anything that demands knowledge of how this particular business operates stays with a person, and will for the foreseeable future.
Why that holds: a server moving large volumes of data to an overseas address at three in the morning is technically the same event whether it represents a backup job configured last week or intellectual property leaving the building. The system can find it, correlate it and surface it. Only someone who knows what was authorised last week can say which of the two it is.
The question changes shape
So the question stops being “who reads the data” and becomes “what reaches the two people we already have, and in what condition”.
The difference is practical. The first version searches for capacity that the market does not supply. The second moves existing capacity to where it changes the outcome.
This has consequences for tool selection. A platform that only becomes useful after someone has defined use cases, written detection rules and tuned thresholds has not removed the constraint. It has moved it to the beginning of the project, where it demands exactly the resource that is missing. CardinalOps reported in 2025 that production SIEM rule sets cover roughly 21 percent of MITRE ATT&CK techniques on average, despite an average of more than 13,000 active rules. Effort and coverage are only loosely related — we break that down in does “no alert” really mean “no incident”.
Where we stop
This deserves plain language, because the market tends to overreach here.
Automated detection and correlation across network traffic are established capability and work without a dedicated security team. What often gets promised on top of that is different: a layer that investigates the incident, assesses it, prioritises it and in some cases remediates it. Vendors offering that layer generally run it in their own cloud, and it requires access to customer data in that environment.
AEGYS does not offer that layer, and the reason is structural rather than technical. Our customers choose where their data is processed, in the United States or in Germany, and that choice is only meaningful if the analysis stays inside the environment they selected. What the system delivers is a view of what is happening, with correlation and priority attached. Interpreting that view in context and deciding what follows stays with the customer or their service provider.
The same applies to the network itself. The system observes and reports. It does not block, it does not isolate, and it replaces neither a firewall nor endpoint protection. That is the premise the whole design rests on: something that only observes can sit alongside everything already deployed, without displacing any of it.
For organisations working towards SOC 2, PCI DSS 4.0, HIPAA or NYDFS Part 500, this matters in a specific way. Those frameworks ask for evidence that monitoring exists and that anomalies are reviewed. Evidence of review is easier to produce when the reviewing is systematic and the record of it sits where you control it.
Four questions worth answering internally
No tooling required:
- If a device on your network started communicating with an unfamiliar overseas destination today, how long before someone noticed?
- Who last looked at your network traffic, and what prompted it?
- When an auditor or insurer asks for evidence of threat detection, what do you show them?
- Of the alerts your systems generate, how many are opened, and how many are closed without being opened?
If two of those answers are uncomfortable, the problem is rarely the people doing the work. It is that the work was scoped in a way no individual can complete.
Three sentences to take away
- The constraint in reviewing network data is human attention, not data volume, and attention cannot be bought.
- The division that holds is capability-based: capture, correlation and noise reduction by machine, interpretation and decision by people.
- Anything promised beyond that, particularly automated assessment and remediation, requires access to your data inside someone else's environment and deserves separate scrutiny.
Common questions about reviewing network data
Not sure how your own review process holds up?
Five minutes gives you a read on where the gap sits. Eight questions, immediate result, no sign-up.
Or fifteen minutes on a call to work out whether this fits. If it does not, we will say so. Contact
What continuous network visibility looks like in practice is described on the AEGYS Pulse page.
Sources
- ISC2 Cybersecurity Workforce Study 2025 — skills shortages, staffing constraints and funding
- CardinalOps, State of SIEM Detection Risk 2025 — MITRE ATT&CK coverage in production SIEM rule sets