What 'SIEM' actually means, and why the term gets stretched thin

SIEM stands for security information and event management, and in its original, narrow definition it is a specific kind of system: something that ingests log and event data from many sources — firewalls, endpoints, identity providers, cloud platforms — normalizes it into a common format, correlates events across sources to find patterns a single log stream would never reveal, retains that data for a compliance-relevant window, and alerts a human when a correlation crosses a threshold worth looking at. That is a real, well-defined category of software, with real engineering behind the correlation logic and real cost behind the storage and query performance it takes to run correlation across months of multi-source data at MSP scale.

The problem is that 'SIEM' gets used in vendor marketing to describe almost anything that shows you a list of alerts. A tool that surfaces failed logins from one identity provider is not a SIEM. A dashboard that shows open ports from your own scans is not a SIEM. Endpoint detection with a timeline view is not a SIEM. None of those are bad things to have — they are just not what the term historically means, and calling them a SIEM either because it sounds more impressive or because the buyer won't check the definition is exactly the kind of vague vendor language we try not to do.

What actually separates a SIEM from an alert list

• Correlation across independent sources — a SIEM's value is in connecting a login anomaly on one system to a process anomaly on another, not in showing either alone.
• Normalization — pulling heterogeneous log formats into a queryable common schema is most of the unglamorous engineering work, and it's what makes correlation possible at all.
• Retention with query performance — compliance frameworks generally expect months of searchable history, not a rolling seven-day buffer, and searching that history fast is a distinct engineering problem from just storing it.
• A tuned alerting layer — raw correlation produces enormous alert volume; a mature SIEM's real value shows up in how well it's been tuned to surface what matters without burying a human in noise.

Where does that leave a platform like Nexus, or most MSP-facing security tooling generally? Today, Nexus's security module aggregates findings from the sources it directly touches — the monitoring agent, the integrations it holds credentials for — into one tenant-isolated record alongside tickets and compliance evidence, and an AI agent drafts triage and response recommendations against those findings for a human to approve. That is real correlation within Nexus's own data, and it is a genuinely useful signal. It is not the same claim as full multi-source SIEM correlation across every log source a client might have, including ones Nexus has no visibility into, and we're not going to call it that just because the category name carries more weight.

If you're evaluating any vendor's SIEM claim — ours included — the honest question to ask is narrower than 'do you have a SIEM': which sources does it actually correlate across, how long is data retained and searchable, and what specifically triggers an alert versus what a human still has to notice on their own. Ask for a walkthrough of one real correlated alert from raw log to conclusion. If a vendor can't show you that chain, the word 'SIEM' in their pitch deck isn't describing an architecture — it's describing a hope.