VMware ESXi Audit Logs for ISO 27001 Compliance (2026)

VMware ESXi audit logging is not just about keeping a few host log files somewhere on disk. A stronger model identifies which records carry audit value, makes them persistent, sends them to a central platform, and ties them to access review and incident analysis. The short answer is this: for ISO 27001, ESXi audit logging becomes defensible when persistent logging, local audit record storage, remote syslog, privilege review, and validation routines are operated as one control set.

This guide is especially useful for:

VMware and vSphere administrators
information security and compliance teams
SOC, SIEM, and centralized logging teams
IT managers preparing for ISO 27001 audits

Quick Summary

Broadcom states that ESXi logs are stored by default on scratch volume or ramdisk, so persistent disk or remote syslog design matters for auditability.
Syslog.global.logDir, Syslog.global.logHost, and Syslog.global.logDirUnique are central to durable and separated host logging.
Broadcom KB 408693 shows that local audit logging requires a specific disable-change-enable flow and that the target audit folder must not exist beforehand.
Broadcom KB 386607 shows that audit record storage can silently become inactive after scratch reconfiguration or upgrade.
SSL-based remote syslog should use FQDN instead of IP when certificates are involved.
If multiple ESXi hosts write to the same datastore path without unique directories, log locking and unreliable audit trails can occur.

What Does ESXi Audit Logging Cover in ISO 27001 Terms?
Why Is Persistent Logging the First Control?
How Should Local Audit Records Be Designed?
How Should Remote Syslog and SIEM Flow Be Built?
What Mistakes Are Most Common?
Related Content
How Should the ISO 27001 Evidence Set Be Built?
Checklist
Next Step with LeonX
Frequently Asked Questions
Sources

VMware ESXi audit log ISO 27001 image

Image: Wikimedia Commons - NetworkOperations.

What Does ESXi Audit Logging Cover in ISO 27001 Terms?

ISO/IEC 27001 does not require one vendor checkbox. It requires a risk-based control model for confidentiality, integrity, and availability. In that context, ESXi audit logging should not be reduced to hostd.log or vmkernel.log alone. The real questions are:

which events are retained persistently
which records reach a central platform
who reviews the records
how a broken logging path is detected
how the design can be demonstrated during audit

That is why ESXi audit logging should include:

persistent local logging
local audit record storage
remote syslog forwarding
retention and rotation logic
visibility into access and privilege changes
periodic test and review records

From an ISO 27001 standpoint, a strong position is not “we generate logs,” but “we know which logs matter, how long they last, who reviews them, and how logging failures are detected.”

Why Is Persistent Logging the First Control?

Broadcom KB 302451 explains that ESXi logs internally to ramdisk and that persistent logging requires either a persistent scratch location or remote syslog forwarding. That matters because purely temporary logs can lose audit value after reboot, storage changes, or host issues.

Broadcom KB 318939 identifies five main syslog settings:

Syslog.global.logDir
Syslog.global.logHost
Syslog.global.logDirUnique
Syslog.global.defaultRotate
Syslog.global.defaultSize

These should be read in two layers:

1. Local persistence

Keeping logs on persistent scratch or datastore supports short-term troubleshooting and host-local review.

2. Remote transmission

For long-term retention, central correlation, and stronger audit evidence, remote syslog or SIEM flow is needed. Broadcom also states clearly that retention and splitting of remotely received logs are controlled by the syslog server, not by ESXi. So forwarding alone is not enough; the receiving platform’s retention rules must be defined separately.

Without persistent logging, the audit chain becomes fragile. During an ISO 27001 review, that weakens the organization’s ability to reconstruct events.

How Should Local Audit Records Be Designed?

Broadcom KB 408693 shows that local audit logging uses /scratch/auditLog by default and that moving the audit directory requires a strict operational sequence. Specifically:

local audit logging cannot be moved while it is active
existing local audit logging must be disabled first
the new target folder must not already exist
ESXi creates the directory automatically during enablement

This matters operationally because teams often see an Internal error in the UI and assume the feature is still functioning.

Broadcom KB 386607 highlights another risk: after ESXi 8.0 U3e upgrades or scratch reconfiguration, audit record storage can become inactive. If esxcli system auditrecords get shows:

Audit Record Storage Active: false

the audit-record chain is effectively broken. In ISO 27001 terms, that is not only a platform warning. It is a gap in evidence generation and post-incident review capability.

For that reason, local audit records should at minimum include:

periodic validation of auditrecords status
post-upgrade and post-scratch-change verification
path accessibility and writability checks
central alerting for disabled audit record storage

How Should Remote Syslog and SIEM Flow Be Built?

An ESXi audit logging model should not stop at local storage. Broadcom KB 318939 documents tcp://, udp://, and ssl:// formats for remote syslog, requires esxcli system syslog reload after changes, and recommends connectivity testing.

In practice, the right model includes:

1. Explicit remote host definition

If Syslog.global.logHost is blank, no forwarding exists. This setting should be standardized through host profiles or an agreed host baseline.

2. Reachability and live-path testing

Broadcom recommends port testing such as nc -z <RemoteHostname> 514. A live test message can also be generated with:

esxcli system syslog mark --message "Syslog Test Message"

That validates real transport, not only saved configuration.

3. FQDN discipline for SSL syslog

Broadcom KB 432290 shows that SSL syslog can fail when ESXi is configured with an IP address while the certificate is issued for FQDN only. In other words:

ssl://ip:6514 can fail
ssl://fqdn:6514 is the stronger pattern

4. SIEM integration

Audit logging becomes much more valuable when centrally correlated. That is why this topic should be connected to Hardware & Software Services and specifically to SIEM and Security Incident Management Integration. On the virtualization side, Enterprise Virtualization Platforms Sales and Licensing supports standardization of host profiles and logging baselines.

What Mistakes Are Most Common?

Not using unique directories on shared datastore targets

Broadcom KB 387609 explains that if multiple ESXi hosts write logs to the same location, file locking and Device or resource busy errors can occur. That is why Syslog.global.logDirUnique matters in multi-host environments.

Assuming syslog is working because the setting exists

A saved configuration does not prove that logs are arriving. A mark test and central visibility check are necessary.

Ignoring disabled local audit-record status

If Audit Record Storage Active: false is visible only to a CLI user, the control is immature. That state should be tied to central review and alerting.

Treating retention as an ESXi responsibility

Broadcom states clearly that remote retention is handled by the syslog server, not ESXi. Retention, archive, and export policy must therefore be managed on the receiving platform.

How Should the ISO 27001 Evidence Set Be Built?

A strong audit package should include more than screenshots. A better ESXi audit-logging evidence set combines:

esxcli system syslog config get outputs
esxcli system auditrecords get outputs
proof that test syslog messages arrived centrally
host-profile or baseline documentation
retention and review responsibility matrix
incident or ticket records for logging failures
privilege review records

The strongest examples usually include:

syslog validation records from the last 12 months
post-upgrade checks for auditrecords state
documented standards for unique log directory usage
SIEM correlation examples based on ESXi logging

At this stage, governance matters too, which is why Cybersecurity Assessment Service can complement the technical rollout with control review and audit-readiness work.

Checklist

Syslog.global.logDir, logHost, and logDirUnique were standardized
esxcli system auditrecords get was validated across relevant hosts
Local audit-record storage path and writability were tested
Audit record status was revalidated after scratch changes or upgrades
Remote syslog destination was verified with a live test message
FQDN and certificate alignment were checked for SSL syslog
ESXi audit events were correlated in SIEM or central logging
Retention, review, and audit export procedures were documented

Next Step with LeonX

VMware ESXi audit logging is not only about collecting files. It is about building a record chain that remains useful during incidents and defensible during audits. LeonX helps design host logging standards, central correlation, retention policy, and audit evidence workflows together so the VMware environment becomes more observable and more audit-ready.

Relevant pages:

Frequently Asked Questions

Are ESXi audit logs and syslog the same thing?

No. ESXi audit logging includes local audit records, syslog forwarding, persistence design, and central review. Syslog is only one part of the model.

Is local scratch storage alone enough?

Not strongly. Reboots, scratch changes, or host issues can reduce visibility. Remote syslog and SIEM integration make the control much more reliable.

Why is using an IP address risky for SSL syslog?

Broadcom KB 432290 shows that certificate validation can fail when ESXi connects by IP while the certificate is issued for FQDN only.

Can all ESXi hosts use the same log folder on shared storage?

That is not recommended. Broadcom KB 387609 shows that shared paths can lead to file locks and unreliable logging behavior.

Which records help most during ISO 27001 audit?

Persistent logging settings, auditrecords state, test-message validation, retention policy, and review records form the most defensible evidence set.

Sources

Share this article

Facebook

Twitter