Does local logging happen per-host?
Central collection needs something to collect. Host logging is the source, and several of the most useful events are off by default.
What the carrier is actually asking
The carrier is asking whether individual systems generate their own security logs: authentication events, process creation, privilege use, and configuration changes. It is the foundation the centralization question depends on.
Why it is underwritten
Investigations reconstruct what happened on specific machines. Without host-level events, the timeline has gaps precisely where the attacker operated. Several of the most valuable events, including command-line arguments in process creation, are disabled by default and produce no evidence unless someone enabled them.
Where the answer lives in Microsoft 365, Entra ID, and Azure
Host logging is configured by endpoint policy and is mostly attested. Cloud resource logging is directly measurable.
| Platform | Where the setting lives | What has to be true |
|---|---|---|
| Endpoint policy | Audit policy configuration for process creation, logon events, and privilege use | Process creation auditing enabled with command line included, which is off by default. Attested |
| Endpoint policy | Local log size and retention before rollover | Sized so logs survive long enough to be collected, since small defaults roll over in hours on busy systems |
| Azure | Resource logging across services | Diagnostic settings on resources rather than the subscription only |
| Azure | Guest configuration or agent-based log collection on virtual machines | Host logs actually leaving the machine |
| Coverage | Systems generating no security logs at all | Known gaps, particularly appliances and legacy systems |
Process creation events with command-line arguments turn an unreadable timeline into a readable one, because modern intrusions are largely command-line driven. It is a policy setting, it is off by default, and enabling it costs almost nothing.
What a defensible yes requires
- Security auditing is configured beyond defaults, including process creation with command line.
- Local log sizes are large enough to survive until collection.
- Logs are forwarded rather than only stored locally.
- Cloud resources have diagnostic settings, not only the subscription.
- Systems that cannot log are known and compensated for.
How this answer goes wrong
Default audit policy is in place, so authentication events exist and process creation does not. The investigation can establish that an account logged on and not what it did, which is the part that determines scope.
Frequently asked
What events matter most?
Process creation with command line, logon and logoff, privilege use, account and group changes, and service installation. Those five cover most of an intrusion timeline.
Does this generate a lot of data?
Process creation is the largest volume. Filtering at collection rather than at the host keeps the local record complete while controlling storage.
What about PowerShell?
Script block logging is specifically valuable and specifically off by default. A separate question asks about command-line monitoring directly.
Does the endpoint agent replace this?
It supplements it. Detection tooling keeps its own telemetry with its own retention, and native host logs remain the neutral record.
Related questions
Stop answering this from memory
Connect Microsoft 365, Entra ID, and Azure read-only. Insurance Posture reads the live configuration behind each application answer and shows you which ones you can prove before you sign.
Assess your posture