10.3 Audit log protection: requirements and evidence

What PCI DSS 10.3 audit log protection requires and why it is hard

Requirement 10.3 asks you to make audit logs hard to read by the wrong people, hard to change, copied off the system quickly, and watched for alteration. A QSA or internal assessor will ask how you know the logs from your cardholder data environment have not been tampered with, and they will expect an answer for each part of the requirement. The four sub-requirements are 10.3.1, which limits read access to people with a job-related need; 10.3.2, which protects log files from modification; 10.3.3, which promptly backs up logs, including those from external-facing technologies, to a secure central server or to media that is difficult to modify; and 10.3.4, which requires file integrity monitoring or change detection on the audit logs themselves.

The reason this matters is simple. An attacker who gets administrative access to a payment system will often try to erase the trail of how they got in and what they touched. If the only copy of the logs sits on the compromised host, and anyone with root can read or edit it, the investigation starts without evidence. Copying logs to a central store moves the evidence out of the attacker's reach, and integrity monitoring tells you when someone changed it anyway. Teams often miss the gap because each piece works on its own: logs are written, a SIEM receives some of them, and a monitoring agent runs on some hosts. The gaps appear when an assessor asks which accounts can read the logs, whether backups cover every in-scope component, and what the monitoring output looks like for the log directory.

Before the assessment, confirm three things with your team. List every account and group that can read or write log storage, and document the business reason for each. Map every in-scope system and external-facing technology to its central log destination, and check that the destination is protected from modification. Then ask your integrity monitoring tool to show a recent alert or report for the audit log path, since assessors examine both the settings and the monitoring results. Your QSA or assessor should confirm the exact expectations for your environment, including how they will test each sub-requirement.

Which log sources, people and third parties fall under 10.3

Requirement 10.3 applies to every log store that holds audit logs for the cardholder data environment, not only the primary SIEM. The cards below map the scoping decisions that determine which systems, accounts and providers the protection controls must reach.

In-scope systems that generate logs

Start with every system component in or connected to the cardholder data environment that writes audit logs: operating systems, databases, application servers, network devices, cloud control planes and security tools. Each source that feeds a log store is part of the 10.3 scope, because the protections must cover the stored logs wherever they land. Ask for a current inventory that links each log source to its log destination, so no source is missed when logging is later changed.

Log stores and SIEM tiers

Map every place audit logs are kept: local disks, collection agents, intermediate forwarders, the SIEM, and any cold archive. Each tier needs read restriction, protection from modification and backup to a secure central server or media that is difficult to change. A common gap is a short-term local buffer or an analyst workspace copy that is outside the protection controls. Treat each copy as a log store in its own right.

Administrator and service accounts

Identify every human administrator, shared account, service account and automation identity that can read, change, delete or move audit logs. Requirement 10.3.1 limits read access to people with a job-related need, so these accounts must be listed and justified. Pay particular attention to backup operators, cloud root or owner roles and logging agents that run with elevated rights. Each of these is a route to altering the record.

External-facing technologies

Logs from internet-facing systems such as web servers, VPN gateways, remote access services and load balancers are explicitly covered by Requirement 10.3.3, including their backup. These sources are often exposed to attack first, so their logs are the ones most likely to be deleted by an intruder. Confirm that logs from these technologies are copied promptly to the central store, not only kept on the device.

Third-party hosted log services

When a SaaS SIEM, managed detection provider or cloud logging service stores your audit logs, the provider's controls become part of your evidence. Confirm in writing which 10.3 protections the provider performs, such as access restriction, immutability and backup, and which remain your responsibility. Request the provider's own assessment evidence and the responsibility matrix, and note any gap for the assessor. The organization still owns the requirement, even when a provider runs the platform.

Log integrity and change detection points

File integrity monitoring under Requirement 10.3.4 must watch the audit log files and directories themselves, not only system binaries. Confirm which hosts and log paths are included, how baselines are created, and who receives alerts when a log file is modified, deleted or replaced. Open-source tools such as Wazuh can record checksums and attributes for monitored paths, but coverage must be set and verified for each in-scope log location.

How to implement audit log protection step by step

This sequence turns Requirement 10.3 from a policy statement into working controls: known log sources, restricted access, protected storage, prompt copies on a central server and monitored log files, each documented so an assessor can trace it.

Inventory log sources and storage locations
Your team lists every system component that produces audit logs in the cardholder data environment and in any connected system that can affect it, including the paths where each log is written, rotated and copied. Include external-facing technologies, since 10.3.3 covers them too. Done means you have a log source register that names each host, log file path, owner and whether the log is shipped off the host. Ask your assessor early which systems they expect to see on the list, because gaps here carry through every later step.
Restrict read access by job need
Using the register, your administrators remove broad read permissions on log directories and grant access only to named roles with a job-related need, such as security operations or the team that reviews logs under 10.4. Shared administrative accounts and general user groups should not hold read access. The output is an access list per log location, reviewed against your role documentation and your access control records under Requirement 7. Confirm that the log platform's own administrative roles are included in this list.
Enforce write protection and separation of duties
Set file permissions so that ordinary users and service accounts cannot modify or delete existing audit log files, and make sure the people who administer the systems generating logs are not the same people who can alter the log store. Where the platform supports it, make appended records append-only. The output is a permission baseline for each log path and a short statement of who can administer the log store. Verify by attempting a modification with each role in a test environment and recording the result.
Configure prompt forwarding to a central server
Configure each log source to forward its audit records to a secure central log server or to media that is difficult to modify, with transport protection and an interval short enough to meet the promptly backed up expectation in 10.3.3. Your team defines the forwarding interval in writing and documents the transport method. The output is a forwarding configuration per source and a test record showing an event on the source appearing on the central server. Ask your platform vendor to confirm which forwarding options and tamper protections its audit subsystem supports.
Lock down the central log store
Restrict administrative access to the central log store, apply the same read and write limits from the earlier steps, and enable retention and deletion controls so that no single administrator can silently remove records. Where backups of logs are taken, store them under the same protections. The output is a configuration record for the central store that lists its access roles, protection settings and backup locations. Keep this record with the forwarding configuration so an assessor can trace a log from source to store.
Deploy file integrity monitoring on log files
Deploy file integrity monitoring or change detection to watch the audit log files and their directories, as 10.3.4 requires. A file integrity tool records a baseline of checksums and attributes, then alerts when a user or process creates, modifies or deletes a monitored file. Set the monitoring to real time or to a schedule your team documents. The output is a monitored file list, alert routing to a responsible role, and a test showing that a deliberate change to a log file raises an alert with the actor and time. Open-source options such as Wazuh and Bareos verify jobs can support this, but confirm the fit for your environment.
Document each setting and collect assessor evidence
Your team records every setting from the earlier steps in one document: the log source register, access lists, permission baselines, forwarding configurations, central store settings and integrity monitoring rules, each with an owner and the date of last review. Collect the test records and alert samples that show each control works. Assessors typically examine system settings, the monitored files and the results of monitoring activity, so this evidence pack is what they will request. A qualified assessor, not your implementation partner, decides whether the evidence meets the requirement.

How a PCI DSS assessor tests 10.3.1 to 10.3.4

This table compares each sub-requirement of Requirement 10.3 by the test approach an assessor typically takes, the evidence they request and the findings that most often come up. Read each row as a checklist: prepare the artifact named in the evidence column before the assessment starts, and confirm the wording of each sub-requirement against your own copy of PCI DSS v4.0.1. The main takeaway is that a configured control is not enough; assessors also want proof that the control runs and that someone acts on its output.

Sub-requirement	How the assessor tests it and evidence requested	Common findings
10.3.1 Read access to audit logs	Assessor reviews the access control lists on log storage, the group memberships that grant read rights, and the job roles that justify each grant. They compare the list against the HR or role register and ask for proof of recent access reviews.	Shared administrator accounts hold log read rights; former staff or service accounts keep access; no documented job-related need for some grants.
10.3.2 Log files protected from modification	Assessor checks file permissions, ownership and append-only or immutable settings on log directories, and whether administrators can edit or delete entries. They may ask for a demonstration that a privileged user cannot alter a log file without a trace.	Log directories writable by the application or by general administrators; logs stored on the same host with the same root access as the systems they record.
10.3.3 Prompt backup to a central server	Assessor reviews log forwarding or backup job configurations, the destination server or write-once media, the backup schedule and transfer logs. They check that external-facing technology logs are included and sample a log entry to confirm it reached the central store.	Forwarding agents silently stop and nobody notices; external-facing systems excluded from the forwarding list; central store writable by the same accounts that manage source systems.
10.3.4 File integrity monitoring on audit logs	Per the SAQ D testing expectations, the assessor examines system settings that enable file integrity monitoring or change detection, the list of monitored log files, and the results of monitoring activities such as alerts and the responses recorded. Expect requests for alert samples and tickets showing who investigated them.	FIM installed but log files missing from the monitored list; alerts generated but never reviewed; no record of how alerts were resolved; baseline not updated after approved changes.

Evidence that passes 10.3 and how to keep it current

An assessor testing Requirement 10.3 looks for proof that audit logs are readable only by people with a job need, cannot be altered, are copied to a central location, and are watched for changes. The cards below list the artifacts that show each of those controls, and the recurring routines that keep them accurate between assessments.

Access listings for log locations

Export the effective read permissions for every directory, database table and log platform index that holds audit logs, including the groups and service accounts that can reach them. Compare each entry against a documented job-related need for access under 10.3.1. Flag broad groups, shared administrator accounts and any user who can read logs without an assigned role. Keep the export dated and tied to the ticket that approved each grant.

File permission and ownership settings

Capture the owner, group and mode of log files and their parent directories, plus any access control lists. Logs should be writable only by the logging service and not by the applications that generate them, so that 10.3.2 can be shown. Store command output such as directory listings with numeric modes as evidence, and rerun the capture after every host rebuild or configuration change to show the setting persisted.

Central log server configuration and replication records

Keep the configuration of the central log collector, including the listening interface, transport encryption, retention settings and write-once or immutable storage options where the platform supports them. Pair it with replication or forwarder logs that show each source shipping events under 10.3.3. Confirm with each product's documentation which immutability features exist before you claim them to an assessor.

FIM baseline and alert records

File integrity monitoring on log files needs two artifacts: the baseline of checksums and attributes taken when monitoring began, and a sample of alerts showing that a changed or deleted log file was detected and investigated. Wazuh, for example, records baselines and raises alerts on creation, modification or deletion with the user or process involved. Assessors also expect evidence of the monitoring scope and of the results of monitoring activities.

Change approvals for monitoring changes

Any change to logging settings, forwarder rules, FIM scope or log file paths should have an approved change record that names the reviewer and the reason. Link these records to the configuration diffs they produced. Without them, a gap in logging or a narrowed FIM scope looks like an undocumented control failure, so keep the approval, the change and the post-change verification together.

Recurring refresh between assessments

Schedule the exports above so they run on a fixed calendar rather than only before an audit, and store each run in a read-only evidence repository. Recertify log-access rights on a set cadence, removing grants that no longer match a role. Review FIM baselines after approved changes and re-verify central server replication after patches. Record who ran each task and what exceptions were raised, so the history itself shows the control operating.

What meeting 10.3 costs in money and effort

This table compares the cost components of protecting audit logs under Requirement 10.3, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to structure a quote request and to see where self-hosted open-source tooling removes license spend while leaving configuration, tuning and evidence work in place.

Cost component	One-time or recurring, and who is paid	What drives it up or down	Where open source changes the bill
Tooling or licenses	Recurring for commercial SIEM, FIM or log store licenses, paid to the vendor. One-time or recurring for hosting, paid to your cloud or data center provider.	Log volume, number of sources, retention tier and whether FIM is priced per host or per event	Self-hosted open-source components such as Wazuh or Bareos remove license fees, but hosting, storage and support still carry cost. Confirm each license terms with the vendor.
Engineering time to configure access and forwarding	One-time, paid to your platform team or an implementation partner for scoped work	Number of log sources, number of distinct access groups, and how many systems forward logs to the central server	Standard Linux and container log forwarding reduces custom work. Ask the partner which sources need bespoke parsing.
Restricting read access and file permissions	One-time setup, with recurring review, paid to your identity and operations staff	Number of administrators and service accounts with log access, and how often roles change	No license change. Access reviews run on existing identity tooling, so the main cost is staff time.
FIM baseline and tuning	One-time baseline, then recurring tuning, paid to your security engineers or a partner	Number of monitored log paths, churn from rotation and compression, and how many exclusions are needed	Open-source FIM such as Wazuh's checksum baseline avoids license spend, but baselines and exclusions must be designed for each environment.
Alert triage for log file changes	Recurring, paid to your security operations staff	Frequency of legitimate rotation events, number of alert rules and time-of-day coverage	Fewer false positives after tuning lower triage time. The effect depends on your own log rotation design.
Evidence upkeep	Recurring, paid to your compliance and security staff	Frequency of evidence collection, number of systems in scope and how much is generated automatically	Automated exports from open-source tools reduce manual screenshots. Define the evidence set before the assessment begins.
Backup to central server or hard-to-modify media	Recurring storage and transfer costs, paid to your infrastructure provider	Log volume, backup frequency, retention period and whether write-once media is used	Open-source backup tools such as Bareos avoid license cost, but storage and media remain paid items.
External review and assessor sampling	Recurring at each assessment cycle, paid to the independent QSA or assessor	Number of sampled systems, number of log sources in scope and how well evidence is organized	Open source does not change assessor fees. Clear, reproducible evidence usually reduces sampling effort.

Which self-hosted open-source tools support 10.3 evidence

Wazuh is the most direct fit for Requirement 10.3.4, which asks for file integrity monitoring or change detection on audit logs. Its file integrity monitoring module records a baseline of checksums and attributes for the directories you choose, then raises an alert when a user or process creates, modifies or deletes a monitored file. Alerts can run on a schedule or in real time and include how and when the change happened and who made it, which is the detail an assessor will look for when examining monitored files and monitoring results.

Baseline capture: Confirm that the log directories, such as the one holding your audit logs, are included in the monitored paths and that the baseline is taken before logging begins.
Real-time versus scheduled checks: Choose real-time monitoring for log directories where a silent edit would matter most, and document the scan schedule for anything else.
Who-changed-what detail: Test that an alert identifies the user or process behind a change, using a controlled test edit that you record in your evidence.
Alert routing: Confirm that alerts reach a team that reviews them, and keep the alert history and responses as evidence.
License: Wazuh is distributed under GPL-2.0-only. Confirm with your legal team how that license applies to your deployment and any modifications you make.

Before relying on Wazuh, confirm in your own environment which paths it monitors, that the agent runs on every host holding audit logs, and that your alert retention meets your own policy.

Nextcloud is relevant when the audit logs in question come from a self-hosted file or collaboration platform. Its admin_audit app writes additional event information to an audit.log file in the data directory, or to a path you set with the logfile_audit configuration key. That gives you a file you can point a central collector at, but the app is a logging source, not a protection mechanism, so the protection controls for 10.3.1 through 10.3.3 must come from the surrounding system.

Log location: Set logfile_audit to a path that your separate protection controls cover, and document where the file lives in your data-flow diagrams.
Enabling the app: Confirm that the admin_audit app is installed and enabled, then test that a sample administrative action produces an entry.
Read restriction: The file inherits operating system permissions. Confirm that only the logging service account and authorized reviewers can read it, which supports 10.3.1.
Backup and integrity: Forward the file promptly to a central server, then apply file integrity monitoring to the local copy as described for 10.3.4.
License: Nextcloud is distributed under AGPL-3.0-only. Confirm the obligations that apply if you modify and offer the software to users over a network.

Before relying on this tab, check the current Nextcloud admin manual for the logging configuration that matches your version, and test that entries are complete enough for your 10.2 event requirements.

Where teams fall short on audit log protection

Requirement 10.3 fails in predictable places: too many people can change the logs, copies stay on the machine that produced them, and integrity checks watch the wrong files. The cards below cover the gaps assessors most often find and a closing action for each. Check them against your own environment before an assessment begins.

Broad read and delete rights on logs

Administrators often hold rights to the whole log directory, including delete and rotate permissions, because that is how the operating system was set up. Requirement 10.3.1 asks for read access limited to people with a job-related need, and 10.3.2 asks that log files be protected from modification. Check who can read, write, truncate or remove log files, and confirm that the list matches a documented need. Make the log directory owned by a logging service account, not by an administrator's shared login.

Logs kept only on the source host

When logs live only on the server that wrote them, anyone who compromises that server can erase the evidence of the compromise. Requirement 10.3.3 expects logs, including those from external-facing technologies, to be promptly backed up to a secure central server or to media that is difficult to modify. Confirm that forwarding is running for every in-scope system, that the forwarded copy is written somewhere the source host cannot administer, and that gaps in forwarding raise an alert.

File integrity monitoring on the wrong paths

Teams often point file integrity monitoring at application binaries and configuration files but leave out the audit log directory itself. Requirement 10.3.4 asks for file integrity monitoring or change detection on the audit logs, and assessors examine the system settings, the monitored files and the monitoring results to test it. Confirm that the audit log paths, the forwarding agent configuration and the rotation scripts are all in the monitored set, and that a test change produces an alert.

Backups that were never restored

A backup job that reports success does not prove that log copies can be read back. Teams discover during an incident that archives are incomplete, encrypted with lost keys, or stored in a location that the same administrators can overwrite. Requirement 10.3.3 depends on the backup being secure and difficult to modify, so the check is operational. Ask for a restore test of a sample log set, confirm the hash or verify result matches the original, and record who approved the restore.

Alerts nobody reviews

Integrity alerts and forwarding failures can land in a mailbox or dashboard that no one checks, so the protection exists on paper but never triggers a response. Assessors ask who receives each alert, how quickly it is handled and what evidence shows the handling. Under Requirement 10.3 this matters because a changed or deleted log is only useful if someone acts on it. Assign a named owner for each alert type, route critical alerts to an on-call channel, and keep the ticket trail as evidence.

Audit trails of the audit tools

Secrets managers, admin consoles and file sharing platforms often write their own audit logs, and those logs are sometimes exempt from the same protections. An administrator who can change the platform's audit settings can switch off the trail for their own actions. Review the audit device or audit app settings, confirm that changes to them are themselves logged and monitored, and confirm that the log destination is outside the platform's administrative control. Examples include OpenBao audit devices and the Nextcloud admin_audit app, where the log path is set in configuration.

How much work and time does 10.3 take to meet

Can we meet requirement 10.3 in-house without outside help?

Yes, many organizations do, provided the team has engineers who can configure log storage, access control and integrity monitoring and someone who can gather evidence in the format an assessor expects. Requirement 10.3 has four sub-requirements: restricted read access, protection from modification, prompt backup to a secure central server or hard-to-modify media, and file integrity monitoring or change detection on the logs themselves. The work is mostly configuration and documentation, so the main risk is not technical difficulty but gaps nobody owns. Outside help makes sense when the in-house team lacks log platform experience or when the assessor's expectations are unclear. Confirm your readiness with your QSA or internal assessor before committing to a plan.

What effort drives the work for audit log protection?

The biggest drivers are the number of log sources, how many systems feed a central server, and how far those systems already restrict access. Effort rises with:

Log sources, including external-facing technologies, each needing a verified backup path
Access models, where every role with read access must be justified by a job-related need
Integrity monitoring scope, meaning how many log directories and files are watched and how alerts are triaged
Legacy systems that cannot forward logs or enforce file permissions natively

Smaller, well-documented environments with a single log pipeline are faster to validate. Ask your team to inventory log sources before estimating any effort, since that inventory sets most of the workload.

What does the team need to provide for 10.3?

The team needs named owners for log storage, access approvals and integrity monitoring, plus someone who can read system settings and explain them to an assessor. Expect to supply the list of accounts with read access to audit logs, the justification for each, the backup configuration and its destination, and the monitoring rules and alert records for log files. Security engineers handle the technical configuration, while compliance leads own the evidence file. Recurring time goes to access reviews and alert follow-up, so assign that work to a named role rather than leaving it to whoever notices an alert first.

Is file integrity monitoring mandatory for audit logs under 10.3.4?

Requirement 10.3.4 asks for file integrity monitoring or change detection on audit logs, so some form of detection is required. The standard describes the outcome, not a particular product, so a tool that detects changes to log files and alerts on them can satisfy the need. Open-source options such as Wazuh, which keeps a baseline of checksums and attributes and alerts on creation, modification or deletion, or Bareos verify jobs, which compare files against cataloged attributes, are examples to evaluate. Assessors typically examine the system settings, the monitored files and the results of monitoring activity. Confirm with your assessor which method they will accept for your environment.

How do we keep evidence current between assessments?

Evidence stays current when collection is automated and tied to routine operations, not rebuilt before each assessment. Export access lists on a schedule, retain backup job reports, and keep integrity monitoring alert records in a central location with consistent naming. Configuration baselines should be version-controlled so changes to log settings produce a record. Review evidence on a fixed calendar, and document who signed off each review. Teams that treat evidence as a byproduct of operations find assessments shorter, because the material already exists when the assessor asks for it.

What should we ask an implementation partner for in a written scope?

Ask for a written scope that names each sub-requirement under 10.3, the systems and log sources in scope, and the deliverables for each. Good scopes list the configuration changes to be made, the evidence artifacts produced, and the handover of documentation to your team. Clarify what the partner will not do: the partner prepares systems and evidence, while your organization owns its controls and only the independent QSA issues the assessment result. Ask how the work is priced and what changes trigger a scope revision. Most engagements are fixed-scope, so agree deliverables and timelines in writing before work starts, and request a quote that follows directly from that scope.

Which parts of 10.3 are usually outsourced?

Organizations most often outsource the initial design of log protection, the configuration of integrity monitoring, and the preparation of evidence packages. Retained in-house work usually includes access approvals, ongoing alert triage and decisions about who may read logs, because those decisions reflect the organization's own risk acceptance. Splitting the work this way keeps ownership clear. Confirm with your assessor which artifacts they need to see, since a partner can prepare them but cannot issue any validation.

How DeployOpen prepares audit log protection for assessment

DeployOpen plans, implements and documents the self-hosted open-source platforms that protect audit logs for Requirement 10.3, inside your own infrastructure. We prepare the systems and evidence an assessor will examine, while your organization owns the control and an independent QSA issues the report.

How we scope

Inventory every log source in the cardholder data environment, including external-facing technologies that write audit logs.
Define which accounts and roles need read access to audit logs and document the job-related need for each.
Agree in writing which log stores, backup targets and integrity monitoring points fall within the fixed scope.

How we build

Configure log file permissions and immutable storage paths so logs cannot be modified by ordinary users.
Set up prompt backup of audit logs to a secure central server or media that is difficult to modify.
Deploy file integrity monitoring on audit log files, with baselines, alert routing and documented monitoring schedules.

How we hand over

Test access restrictions, backup timing and integrity alerts against the 10.3 sub-requirements before handover.
Document settings, monitored file lists and alert samples in a form an assessor can examine directly.
Deliver runbooks that explain who reviews integrity alerts and how exceptions are investigated and recorded.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Review integrity monitoring coverage when log sources, platforms or cardholder data flows change.
Confirm with your QSA which evidence they expect before each assessment, so the package matches their testing.