Connect identity first: the sign-in and audit logs from Microsoft Entra ID, or the Okta System Log. Then endpoint telemetry, then email audit activity, then firewall and VPN, then cloud control planes. Servers and line-of-business applications come last. The order follows how small companies are actually breached — a valid password used by the wrong person — and it keeps volume out of sources where you have no detection yet.
A SIEM arrives empty. Choosing one is a separate decision, and our page on SIEM for small business covers the criteria that matter at 10–300 people. This is about the weeks after you sign: which sources to connect, in what order, and how to know each one works before you add the next.
Why does identity come first?
Because the incident that reaches a 30-person company is usually a valid credential in the wrong hands, and identity logs are where it shows. Microsoft splits this into two activity logs. The sign-in logs cover four types — interactive user, non-interactive user, service principal and managed identity — and record who signed in, with which client, against which resource. The audit logs record changes applied to the tenant (users, groups, applications, licences) with the old and new values of the changed properties. Okta's equivalent is the System Log: one audit trail of org events, each with an actor, an event type and a target.
Without them you can show a machine did something, not that an account did it from an address nobody here has used. The volume driver is non-interactive sign-ins — background token refreshes — which Microsoft aggregates into one row with a count, since a client can request a token hourly per user. One caveat for your rules: for confidential clients the IP on a non-interactive sign-in is the one from the original token issuance, not the refresh. Keep location logic on interactive sign-ins.
Detection this enables: failed interactive sign-ins against one account, then a success from a different country, then any audit-log change to that account within the hour. A password-spray hit becoming an account takeover, and writable on day three.
What does endpoint telemetry add that identity logs cannot?
The executable, its parent and its arguments. Identity data says an account acted; endpoint data says what ran and what it talked to. Prefer your EDR's own event stream over raw Windows logs, because the agent filters and labels it already — the data behind EDR with live response.
If you collect Windows security events directly, check one thing first: in event 4688, "A new process has been created", the Process Command Line field is empty by default until you enable the "Include command line in process creation events" policy. Without arguments, a process feed cannot separate administration from attack. Process creation is also the highest-volume host source here, so this step moves your daily figure most.
Detection this enables: an office document process or an archive utility spawning a script interpreter — PowerShell, wscript, mshta — with an encoded argument or a download in the command line.
Email: why third, and what exactly?
Email is where the money leaves, and the fraud shows up in a few mailbox activities, not in message content. For Microsoft 365, Microsoft Purview audit log activities include the ones that matter for a compromised mailbox: MailItemsAccessed, New-InboxRule, Set-InboxRule and UpdateInboxRules, Add-MailboxPermission, and sends performed as another user. That set is small; full message tracking is far larger and buys nothing actionable in month one.
One documented detail saves a wasted afternoon: the audit log does not record cmdlets beginning with Get-, Search- or Test-. Test the connector by creating a rule, not by reading one. Mail filtering sits elsewhere, in email protection; the audit stream is what the SIEM needs.
Detection this enables: an inbox rule created or changed within an hour of a sign-in from an unfamiliar network, moving invoice or payment keywords into a folder nobody opens.
Firewall and VPN: full logs or filtered?
Filtered, and the split is in the vendor's own taxonomy. PAN-OS, as one example, separates its logs by type: Traffic logs record session start and end entries, while Threat, URL Filtering, Authentication, Config and GlobalProtect logs are each their own stream. Take the small streams in full: remote-access authentications and configuration changes are cheap and high-signal. Filter traffic down to perimeter denies and outbound sessions.
Detection this enables: a successful remote-access authentication for a user whose interactive sign-ins in the same 15 minutes come from another country. It works only because identity went in first.
Cloud control planes: the cheapest useful source
Control-plane logs are small and describe what an attacker does to keep access. AWS CloudTrail logs four types of events — management, data, network activity and Insights — and by default a trail logs management events but not data or Insights events. Management events are the ones you want. Data events, "often high-volume activities" in the same document, must be added per resource type; leave that switch alone.
Detection this enables: a new access key created for a principal that never had one, or logging itself being switched off.
Why do servers and applications come last?
One exception: if authentication still runs on on-premises Active Directory, the domain controller security log is your identity source and moves to step one. Everything else — file servers, hypervisors, the ERP, the app with its own log format — goes last because nothing parses its fields and no rule reads them yet. It produces storage, not detection.
The order, with the trade-offs
| Source | What it detects that nothing else does | Volume consideration | Priority |
|---|---|---|---|
| Identity (Entra ID, Okta) | Account takeover, password spray, privilege and MFA changes | Low once non-interactive sign-ins are aggregated | 1 — week 1 |
| Endpoint / EDR | What ran: process lineage, arguments, per-process connections | Highest host volume; filter at the agent | 2 — week 2 |
| Email audit activity | Inbox rules, delegate access, bulk mailbox reads | Small; message tracking is the large part | 3 — week 2 |
| Firewall and VPN | Remote-access logins, bad outbound, device config changes | Traffic logs dominate; keep denies | 4 — week 3 |
| Cloud control plane | Key creation, role changes, logging disabled | Low for management events; data events are not | 5 — week 3 |
| DNS resolver queries | Beaconing, lookups of known-bad domains | Large, and needs a list to match against | 6 — after day 30 |
| Servers and applications | Investigation context; audit evidence | Usually needs a parser you write | 7 — on demand |
What should you not ingest yet?
- Debug and trace levels. They answer engineering questions, and they are the fastest route to a volume surprise.
- Verbose flow records, east-west traffic and cloud data events. Useful in a mature detection programme, unreadable without one.
- Anything nobody can tie to a question. If no one can name the alert or search it feeds, it is storage with a parser to maintain.
The cost of an early source is not disk. It is a field mapping, a parser that breaks on the next firmware update, and alerts to tune.
How do you check a source is really working?
"Connected" in a console means data arrived once. Verify each source with an event you generate:
- Identity: fail a sign-in on a test account, then find that account and that failure reason. Check that interactive and non-interactive types both arrive.
- Endpoint: run a harmless command with a distinctive argument and search for the argument, not the binary.
- Email: create an inbox rule with a recognisable name on a test mailbox and search for that name.
- Firewall and VPN: trigger one denied outbound connection, edit a rule description, look for both entries.
- Cloud: create and delete a credential in a non-production account and look for both events.
- Every source: set a staleness alert. A source that stopped three weeks ago looks like a quiet week.
A 30-day sequence
- Days 1–2: list the candidate sources, name one owner for the SIEM, write down the question each source answers.
- Days 3–4: connect identity sign-in and audit logs; verify with a failed sign-in.
- Days 5–7: write three identity detections: unexpected-location sign-in, failure burst then success, and privilege or authentication-method change outside a change window.
- Days 8–11: connect endpoint telemetry, confirm command lines arrive, note the new daily volume.
- Days 12–14: connect email audit activity and ship the inbox-rule detection, correlated with the sign-in before it.
- Days 15–18: connect firewall and VPN with the traffic filter in place; add the remote-access-versus-sign-in-location rule.
- Days 19–22: connect cloud control-plane management events; add key creation and logging-disabled rules.
- Days 23–26: add staleness alerts, then walk one past alert end to end on SIEM data alone, noting what you could not answer.
- Days 27–30: review what fired. Rules with only false positives get tuned or deleted, not muted. Add the source the walkthrough proved you were missing.
What does "done" look like at day 30?
Four things. Identity, endpoint and email are feeding, each verified by an event you generated and each with a staleness alert. Every connected source has a named detection or search behind it. You can answer "where did this user sign in from last week" and "what did this process do" in one search instead of three consoles — what the SIEM and search module is for, and why we help prioritise sources during onboarding instead of connecting everything at once. And every alert from the last seven days reached a decision: acted on, tuned, or deleted.
Servers, applications and DNS are still unconnected; that is the correct state. Four understood sources with nine working rules beat twenty sources nobody reads — the second kind is what makes a team call its platform noisy when the real problem was the order they turned it on.