Part 1: Audit Trails in PCI DSS v3.0 – Logging in Windows

What should I be logging in Windows to pass PCI DSS assessment v3.0? – this and similar questions come up rather often when it comes to fulfilling Section 10 of PCI DSS v3.0.

In Part 1, we are looking at Microsoft Windows  and in Part 2 we will investigate CentOS. Note. This article is describing local logs configuration settings. If you are interested in the centralized logging and PCI DSS, please read the following article: Free Log Management and PCI DSS 3.0. 

Microsoft Windows comes with very detail and comprehensive logging mechanism. Get it right and you will end up with very useful information, not only helping you to secure the environment but also to achieve high availability and spot things before the real disaster happens. In opposite, enable every possible auditing option and you will end up with thousands records per second, which may hinder the real attack.

The key is to optimize the settings and tweak the system, so it’s compliant with PCI DSS but also provides useful information to the staff involved in monitoring of such logs.

Lets have a look at what events must be logged to satisfy PCI DSS v3.0:

10.2 Implement automated audit trails for all system components to reconstruct the following events:
10.2.1 All individual user accesses to cardholder data
10.2.2 All actions taken by any individual with root or administrative privileges
10.2.3 Access to all audit trails
10.2.4 Invalid logical access attempts
10.2 5 Use of and changes to identification and authentication mechanisms?including but not limited to creation of new accounts and elevation of privileges?and all changes, additions, or deletions to accounts with root or administrative privileges
10.2.6 Initialization, stopping, or pausing of the audit logs
10.2.7 Creation and deletion of system-level objects

The screenshot below presents what Audit Policy Settings must be configured in the Group Policy Object to achieve the above PCI DSS requirements. In the example below it is configured on the Local GPO,  but the same settings apply to the Domain Level GPOs.

Note. Windows offers much more granular auditing configuration settings, which can be found in Computer Configuration -> Windows Settings – > Security Settings -> Advanced Audit Policy Configuration. The advanced settings are beyond the scope of PCI DSS v3.0. As always, PCI DSS is a bare minimum, if you wish to log more, please investigate the advanced logging further.

2014-04-03 15_20_18-Console1 - [Console Root_Local Computer Policy_Computer Configuration_Windows Se







The second part is to enable the above settings on the right directories. The screenshot below presents how to enable the Audit Policy (Object Access) on chosen directories:

2014-04-03 15_41_28-Program Manager






The level of logging for each directory /file (screenshots below) will vary, depending on what directory/user the settings are applied to. For example:

For 10.2.2 all actions on all directories / files must be logged for Administrators. In such case all boxes would be ticked:

2014-04-04 15_17_02-Auditing Entry for GLOBAL

For 10.2.7 only creation and deletion of system-level objects would be ticked:

2014-04-04 15_17_41-Auditing Entry for GLOBAL


At minimum the following Windows directories should have the  ‘Auditing’ settings enabled:

– [PCI DSS 10.2.1] Any directories/files, which store cardholder data – for Everyone

– [PCI DSS 10.2.2] All directories/files – for Domain Administrators, Enterprise Administrators, Local Administrators

– [PCI DSS 10.2.3 and 10.2.6] All directories/files, which store Windows event files (Default – %SystemRoot%\System32\Winevt\Logs\) – for Everyone

– [PCI DSS 10.2.7] All system directories (example: %SystemRoot%\System32\) – for Everyone. Note. System-level object: Anything on a system component that is required for its operation, including but not limited to database tables, stored procedures, application executables and configuration files, system configuration files, static and shared libraries and DLLs, system executables, device drivers and device configuration files,and third-party components.


Lastly, PCI DSS lists what entry should be logged for each event:

10.3.1 User identification
10.3.2 Type of event
10.3.3 Date and time
10.3.4 Success or failure indication
10.3.5 Origination of event
10.3.6 Identity or name of affected data, system component, or resource.

The screenshot below presents an example of event with highlighted fields after the Audit Policy Settings have been enabled. As you can see, there is no need to configure any additional settings in order to fulfill PCI DSS Req. 10.3.x.

2014-04-03 16_12_35-Event Properties - Event 4663, Microsoft Windows security auditing.



Part 2: Audit Trails in PCI DSS v3.0 – Logging in Linux -> Coming soon.



  1. Hi Jake,

    Thank you for the article, this is very useful. I noticed the article referred to the local GPO which would mean the log files are recorded in the local Windows Security logs of each device where this is setup. If the GPO was configured on the Domain Controller across a domain, would these logs be written back to the DC Windows Security Logs (centralised) and/or the local Windows Security logs for each device?

    • Hi – even if you set Domain Level GPO, logs would be still stored on each individual device. The authentication logs (when a user logs in to the domain) would be visible on each domain controller in the domain.

  2. After following the above steps, we are now being inundated by access of objects by the System (such as anti-virus which is running as a local system service). Is there a way to filter out such object access to prevent this type of audit log flooding?

  3. Do you have a Audit Trail in PCI DSS v3.2 for windows? Does not seem like to much has changed but want to make sure we don’t have any gaps.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.