Log Audit Log Changes

PCI DSS 4.0.1 Requirement 10.2.1.6 is narrow but operationally tricky: you are required to capture events about the audit logs themselves, not only “business” or “security” events. Specifically, your audit logs must capture “all initialization of new audit logs and all starting, stopping, or pausing of the existing audit logs.” ¹

In practice, assessors test this by asking, “If an admin (or attacker) disables logging on a critical system in the cardholder data environment (CDE), will we see a record of that action somewhere reliable?” Your job is to make the answer “yes,” consistently, across operating systems, databases, network/security devices, cloud control planes, and logging agents/collectors that are in scope.

This page translates the requirement into implementable steps: scoping, configuration patterns, alerting, access controls, and the evidence package you will need. It also flags where teams commonly fail (for example, collecting endpoint logs while forgetting the logging pipeline events, or sending “logging stopped” events only to the same system that just stopped logging).

Regulatory text

Requirement text (excerpt): “Audit logs capture all initialization of new audit logs and all starting, stopping, or pausing of the existing audit logs.” ¹

Operator interpretation: You must generate and retain audit records for any event that changes the state of audit logging itself. That includes:

• First-time creation/initialization of an audit log (for example, enabling a logging subsystem, creating a new log file/channel, initializing an audit policy).
• Transitions that reduce visibility (stop, pause) as well as transitions that restore visibility (start).
• Equivalent events in cloud/SaaS logging (for example, disabling an audit trail, changing log sinks, stopping an agent, or pausing collection) when those components are in scope for PCI.

This requirement is about anti-tamper visibility: if logs can be turned off without a trace, your entire monitoring and incident reconstruction capability collapses.

Plain-English requirement (what it means)

You need a dependable record of “who changed logging, what they did, and when,” even if the person changing logging has admin privileges on the system. The minimum bar is: attempts to initialize, start, stop, or pause audit logging create an auditable event. ¹

Who it applies to

Entities:

• Merchants, service providers, and payment processors with PCI DSS scope. ¹

Operational context (systems in scope): Apply this to any system component that produces, transports, stores, or governs audit logs for the CDE and connected in-scope environments, including:

• Operating systems and hypervisors hosting in-scope workloads.
• Databases and middleware processing cardholder data or providing security functions.
• Network and security appliances (firewalls, IDS/IPS, WAF) in the CDE path.
• Cloud control planes and native audit services used for in-scope workloads (where applicable).
• Logging agents, forwarders, collectors, and SIEM integrations that, if stopped/paused, would create blind spots.

If a component can stop producing security-relevant logs, treat it as in scope for this requirement.

What you actually need to do (step-by-step)

1) Define “audit log lifecycle events” for each platform

Create a short matrix for each in-scope technology covering:

• What counts as initialization (enabling audit logging, creating an audit channel, first-time configuration).
• What counts as start/stop/pause (service stop, agent disabled, audit policy turned off, sink removed, trail disabled).
• Where the event is written (local event log, control-plane audit trail, syslog, SIEM).
• How it is protected from suppression (forwarding, permissions, separate control-plane logs).

Deliverable: a platform-by-platform mapping that proves you did not guess.

2) Configure each system to emit those events into an auditable log

For each platform, implement the native setting that logs:

• Changes to audit policy/configuration.
• Service control events for the logging service/agent.
• Administrative actions affecting audit trails (enable/disable/pause).

Practical patterns that typically satisfy intent:

• OS-level auditing for policy changes and service start/stop events.
• Security device admin audit logs for “logging disabled,” “syslog destination removed,” or “buffer cleared.”
• Cloud audit trails capturing actions like disabling audit services or changing log exports/sinks.

The key is coverage of the four verbs in the requirement: initialize, start, stop, pause. ¹

3) Forward lifecycle events off-host to a more reliable store

Don’t rely on only local logs for “logging stopped” events. Forward to a centralized logging system or immutable storage pattern appropriate to your environment so:

• A local admin cannot delete the only copy.
• You retain a record even if the system becomes unavailable.

Operational check: confirm the “stop logging” event still arrives centrally when you perform the test in a controlled setting.

4) Restrict who can change logging state, and log their access

Implement least privilege for:

• Audit policy configuration.
• Starting/stopping logging services/agents.
• Changing log destinations and retention settings.

Then ensure those privileged actions themselves create audit records that are retained. This closes the loop: “who had the ability to stop logging” plus “who actually did.”

5) Alert on logging lifecycle events with clear severity rules

Create detection rules for:

• Logging service/agent stopped, paused, or disabled.
• Audit policy reduced or disabled.
• Audit trail deleted/cleared (where applicable to your platform and scope).
• Log forwarding disabled or destination removed.

Tune alerts so they route to the team that can act fast (SOC/IR/on-call). Your goal is quick containment if an attacker tries to reduce visibility.

6) Test the control and document the results

Run controlled tests for representative systems:

• Initialize a new audit log or enable auditing where it was off.
• Stop/pause and then start the logging service/agent.
• Attempt a change with an unauthorized account (should fail and still log the attempt where applicable).

Record:

• The event IDs/messages.
• The timestamp alignment.
• Proof the event reached central logging.
• The alert that fired (for stop/pause events).

7) Operationalize in change management

Require that any planned logging changes (agent upgrades, pipeline reconfigurations, maintenance windows) include:

• A change ticket.
• A backout plan.
• A validation step that confirms lifecycle events are still captured after the change.

This reduces “false positives” and helps auditors distinguish authorized maintenance from suspicious disablement.

Required evidence and artifacts to retain

Build an evidence package that an assessor can validate without guesswork:

Governance

• Logging standard or control narrative explicitly stating you log initialization, start, stop, and pause events for audit logging. ¹
• Role-based access control documentation for who can alter logging configuration.

Technical configuration

• Platform-specific configuration screenshots/exports showing:
  • Audit policy settings.
  • Logging service/agent settings.
  • Device/cloud audit configuration (where applicable).
• Central logging/SIEM ingestion proof for these event types.

Validation

• Test scripts and results showing each lifecycle event generated and was collected.
• Sample log entries for each event type (redact sensitive fields).
• Alert rule configuration and an example alert for “logging stopped/paused.”

Operations

• Change tickets for logging pipeline changes, with post-change validation notes.
• Incident records if a logging disablement occurred, showing response actions.

Common exam/audit questions and hangups

Assessors and internal audit commonly press on these points:

• “Show me the event when logging was stopped.” They will want an actual record, not a policy statement.
• “Is the event captured centrally or only locally?” Local-only is a frequent hangup because the same actor could erase it.
• “Does this cover endpoints, servers, and security devices?” Narrow coverage is a common gap.
• “What about the logging pipeline?” Stopping an agent/forwarder can be equivalent to stopping logging in effect.
• “Who can do this, and how do you know?” Expect requests for privilege listings and access reviews.

Frequent implementation mistakes (and how to avoid them)

1. Logging “security events” but not logging changes to logging

   • Fix: add explicit lifecycle event collection requirements to your logging standard and platform baselines. ¹

2. Capturing events only on the affected host

   • Fix: forward to central logging or a protected store; test that stop/pause events arrive.

3. Assuming “service start/stop” is enough

   • Fix: also log audit policy changes and log destination changes where those actions can effectively pause logging.

4. No alerting, or alerts routed to the wrong team

   • Fix: treat stop/pause/disable as high priority; define an on-call runbook and escalation path.

5. Ignoring third parties that manage your environment

   • Fix: for managed service providers or other third parties with administrative access, ensure their actions to alter logging state are auditable and reviewed under your third-party access governance.

Enforcement context and risk implications

No public enforcement cases were provided in the source set for this requirement, so don’t anchor your narrative to specific penalties. The practical risk remains straightforward: if an attacker can stop or pause audit logging without producing a durable audit event, you may not detect the intrusion promptly and may not be able to reconstruct what happened. That increases both operational impact and the chance you cannot demonstrate PCI DSS compliance during an assessment. ¹

Practical 30/60/90-day execution plan

First 30 days: establish coverage and proof on critical systems

• Inventory in-scope platforms and identify where audit logging can be started/stopped/paused.
• Implement or validate lifecycle event logging on your highest-risk systems (identity, SIEM/collectors, firewalls, core servers).
• Create SIEM searches/dashboards that show these events and save sample outputs as evidence.

Days 31–60: scale and operationalize

• Roll platform baselines through configuration management (GPO/MDM/IaC where applicable).
• Implement alerting rules and an incident runbook for logging disablement.
• Tighten permissions so only approved roles can alter logging state; document approvals and access reviews.

Days 61–90: validate end-to-end and harden against bypass

• Perform control tests across representative samples of each platform type and retain results.
• Add change-management gates: any logging pipeline change must include validation steps and evidence collection.
• Review third-party admin access paths and ensure their actions are captured and reviewable.

Where Daydream fits: If you struggle to keep evidence consistent across teams and technologies, Daydream can track control ownership, map platform-by-platform coverage, and package test evidence and change tickets into an assessor-ready record set without chasing screenshots at the last minute.

Frequently Asked Questions

Does “log audit log changes” mean I need to log every time someone views logs?

This specific requirement is about initialization and starting, stopping, or pausing audit logs, not log viewing. Keep “log access” questions separate so you don’t miss the lifecycle events required here. ¹

What counts as “pausing” audit logs?

“Pausing” includes any action that temporarily halts audit logging or collection, such as pausing an agent, disabling forwarding, or suspending an audit trail feature where the platform supports it. Your job is to define the platform equivalents and prove they are captured. ¹

If our SIEM is down, are we out of compliance?

PCI DSS 10.2.1.6 requires that the events are captured in audit logs; you still need a reliable record of log start/stop/pause actions. Design for buffering and resilient forwarding, and retain evidence of how you handle outages. ¹

Do I need to alert on “logging started” events too?

Alerting on stop/pause/disable events is usually the priority because it signals a loss of visibility. Logging started events are still required to be captured and can be helpful for correlating maintenance or recovery actions. ¹

How do I prove this to an assessor without giving them full SIEM access?

Prepare a controlled evidence set: sample events for initialize/start/stop/pause, SIEM ingestion proof, and test records with timestamps and system identifiers. Redact sensitive fields but keep enough context for the assessor to validate the event type and source. ¹

Our third party manages firewalls. Who owns this requirement?

You still own PCI compliance outcomes. Require the third party to provide evidence that firewall logging configuration changes and logging state changes are auditable and available to you, then include that in your evidence package. ¹

Footnotes

1. PCI DSS v4.0.1 Requirement 10.2.1.6