---
title: "Does local logging happen per-host?"
url: https://insuranceposture.com/questions/network-and-logging/local-logging-happen-per-host
category: "Network, logging and monitoring"
canonical_key: q_aud_007
evidence_state: partial
updated: 2026-08-24
---

# Does local logging happen per-host?

URL: https://insuranceposture.com/questions/network-and-logging/local-logging-happen-per-host
Section: Network, logging and monitoring
Evidence state: Partly verifiable from your tenant

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 |

**Command-line auditing is the highest-value setting**

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.

## If this answer turns out to be wrong

Remote access exposure and log retention are what a forensic report describes first, which makes them the answers most often revisited after a loss. Whether anything follows from an inaccuracy depends on materiality, on the policy wording, and on the law of the governing state: [how an application answer ends in a denied claim](https://insuranceposture.com/glossary/claim-denial). The other consequence terms are collected in the [glossary](https://insuranceposture.com/glossary).

## 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

- [Is command-line activity in command shells (e.g. PowerShell, bash) logged and monitored?](https://insuranceposture.com/questions/network-and-logging/command-line-activity-command-shells-logged-monitored)
- [Does the Applicant employ SIEM, log centralization, and audit logging across firewalls + IDS?](https://insuranceposture.com/questions/network-and-logging/applicant-employ-siem-log-centralization-audit-logging-across-firewalls)
- [How long are audit logs maintained (30 / 90 / 1 year)?](https://insuranceposture.com/questions/network-and-logging/long-audit-logs-maintained)
- [Are administrator privileged access activities audited?](https://insuranceposture.com/questions/access-control/administrator-privileged-access-activities-audited)

---

Insurance Posture by SecValley. https://insuranceposture.com
The question library is written in our own wording to reflect the control topics that recur across US cyber application and ransomware supplemental forms. No carrier form is republished.
SecValley is not a law firm, an insurance broker, an agent, or a carrier, and holds no producer licence. Nothing here is insurance advice, legal advice, or a coverage determination, and no attorney-client relationship arises from reading it. Statements about what a party to a cited case did, knew, or intended are allegations drawn from court filings and contemporaneous reporting, not findings of fact.
Your organization's authorized signer remains responsible for the accuracy of any application. Consult a licensed broker and qualified counsel before binding.