What PCI DSS 10.2 audit log implementation requires
Requirement 10.2 asks for audit logs that are enabled and active on every system component and across the cardholder data environment, and that record the events an assessor will test for. Those events are individual user access to cardholder data, all administrator actions, access to the audit logs themselves, invalid logical access attempts, changes to identification and authentication credentials, initialization and stopping of the logs, and creation and deletion of system-level objects. Each log entry also has to carry a defined set of fields: the event type, date and time, success or failure, origin, and the identity of the affected data, component, resource or service. A QSA or internal assessor will usually start by picking a sample of systems and asking the team to show those entries. If the entries are missing or incomplete, the requirement is not met, however good the monitoring tools look on the dashboard.
The risk is simple: an event that was never recorded cannot be investigated, and it cannot be proven later that a payment record was not altered. The difficulty is coverage. Logging is configured separately at the operating system, database, application and cloud control plane layers, and each layer has its own defaults, file locations and field formats. A common gap is a database that logs connections but not the queries against cardholder tables, or a cloud account where administrative API calls are logged but the workload's own access is not. Start with an inventory of in-scope components and, for each one, record which layers log, where the output goes and which of the 10.2 events it covers. Confirm the field content with a test event on each system rather than trusting the vendor's default.
The requirement is organized as 10.2.1 with sub-requirements 10.2.1.1 to 10.2.1.7, one for each category of event listed above, plus 10.2.2 for the entry fields. Practically, 10.2.1 sets the overall expectation that logging is switched on everywhere in scope, and each sub-requirement is a checkbox the assessor will tick against evidence. For operating system, database and application logs, PCI SSC FAQ 1081 confirms these layers may be combined as appropriate, and that database logging may be unnecessary where other logs already capture all individual access to cardholder data. Confirm that position with your assessor before you rely on it. For system-level objects, PCI SSC FAQ 1034 explains that the scope includes executables, configuration files, shared libraries and device drivers, so file-level change events matter as well as application events.
Which systems, logs and teams fall under 10.2 scope
Requirement 10.2 applies to every system component in the cardholder data environment and to the systems that could affect its security, so the scope question comes before the logging design. The cards below cover the sources that must produce logs and the teams that own them, with the scoping decisions that change the work.
CDE servers and endpoints
Application, web and batch servers that store, process or transmit cardholder data are the core of 10.2. Each one needs audit logging enabled and active, covering individual user access to cardholder data, administrator actions and invalid access attempts. Check that every server in your CDE inventory has logging turned on, and that no build image or autoscaled instance is created without it. Platform teams usually own this, and the inventory is the first control assessors test.
Network and security devices
Firewalls, routers, load balancers and VPN concentrators that sit at the CDE boundary generate access and configuration events that 10.2 expects you to capture. Confirm which devices are in scope from your network diagram, and whether administrative logins and rule changes are forwarded to a log store. Network teams often run these devices on vendor tooling, so confirm which event types the device can export and in what format before you commit to a design.
Databases and database logging
PCI SSC FAQ 1081 says operating system, database and application logging may be combined as appropriate. It also says database logging may be unnecessary when other logs already capture all individual access to cardholder data. The DBA team should document which access paths are captured by OS or application logs, and which queries or privileged sessions still need database-level auditing. This decision is a common source of gaps, so record it in writing and have the assessor review it.
Applications and business logic
Applications often hold the only record of which user viewed or changed a card-related record. Application teams need to log individual user access to cardholder data, administrator actions inside the application, and changes to authentication settings. Review whether your application writes events for failed logins and role changes, and whether support or back-office tools that reach cardholder data are also in the logging scope. Shared service accounts that act for many users are a frequent gap.
Identity systems and credential changes
Directory services, single sign-on and privileged access tools produce the events 10.2 associates with invalid access attempts and changes to identification and authentication credentials. The identity team should confirm that password resets, MFA enrollment changes, group membership changes and account creation or deletion are all recorded. Identity systems are also often the source of the user identity fields that each log entry must carry, so their timestamps and user identifiers need to match the rest of the estate.
Cloud control planes and containers
Cloud control plane activity, such as API calls that create, modify or delete compute, storage, networking or identity resources, falls within 10.2 when it affects the CDE. Container platforms add audit events for cluster administration and workload creation. Cloud and platform teams should confirm which control plane audit trails are enabled for each account or subscription in scope, and whether container runtime and orchestration audit events reach the same log store. Creation and deletion of system-level objects, such as configuration files and shared libraries, is part of the requirement, so image and configuration pipelines also belong in this inventory.
How each 10.2.1 event type is captured in practice
This family covers individual user access to cardholder data (CHD). In practice, the event is a record that a named account read, queried, exported or modified a record that contains primary account numbers, whether through an application screen, an API call or a direct database query. Most gaps appear because application logs record the page or endpoint hit but not the record identity, or because service accounts read CHD in batch jobs that nobody logs individually. Logging the application layer, the database layer or both can satisfy this need, and PCI SSC FAQ 1081 explains how operating system, database and application logs may be combined where they capture the same individual access.
- Named user identity: Confirm that each entry carries the individual's account, not a shared application account, and that SSO or proxy identity is passed through.
- Record-level detail: Check whether a query or API call logs which cardholder records were touched, not only that the endpoint responded.
- Batch and service accounts: Identify scheduled jobs and integration accounts that read CHD and confirm they produce attributable entries.
- Database access: Where application logging cannot show direct database reads, confirm whether database auditing is needed or whether other logs already cover it.
- Reporting and exports: Verify that bulk exports, reports and downloads generate events.
Check this family by picking one cardholder data store, tracing a single user's read through every tier, and confirming the event appears with identity, time and object.
This family covers every action taken with administrative privilege, including changes to configuration, user rights, firewall rules, encryption settings and logging itself. A real event looks like an entry showing an administrator account escalating privileges, changing a policy, or running a command as root or through a management console. Gaps usually come from privileged access that bypasses the normal logging path, such as direct shell sessions, break-glass accounts, or vendor support tools that run outside the audited interface.
- Privileged sessions: Confirm that sudo, root shells and console logins are recorded with the originating user and the commands or actions taken.
- Break-glass accounts: Check that emergency accounts are logged on every use and that their use triggers a review.
- Management consoles: Verify that changes made through cloud, hypervisor and container management planes appear in the logs your team reviews.
- Vendor and support access: Identify remote support tools and confirm whether their administrative actions reach your logs.
- Automation: Confirm that configuration management and CI/CD pipelines record which identity made each administrative change.
Check this family by making a controlled administrative change on each in-scope platform and confirming the change, the actor and the time all appear in the central log.
This family covers any access to the audit logs themselves, along with the initialization, stopping and pausing of logging. A real event is a record that an account opened, searched, exported or deleted log files, or that the logging service was disabled or reconfigured. Gaps are common when log stores sit on hosts whose administrators can read and modify files without generating any record. Logs written to a local file that an administrator can edit may show nothing about who changed them.
- Reads of audit data: Confirm that queries against the central log platform and direct reads of local log files are attributable to a user.
- Logging service state: Check that stopping, pausing or reconfiguring the logging agent or daemon produces an entry before or after the change.
- Log file changes: Verify that deletion, truncation or rotation events are recorded, and that the log store is protected from silent modification (requirement 10.3 covers this in depth).
- Forwarding failures: Confirm that a stopped forwarder generates a visible signal rather than simply ceasing to send.
- Platform audit trails: For self-hosted tools, check whether the platform records its own administrative access, for example the audit devices or admin audit apps that many open-source platforms offer, and confirm their settings.
Check this family by attempting a read and a stop on a test host and confirming that both leave a record in a store the host's administrators cannot alter.
This family covers invalid logical access attempts and any change to identification or authentication credentials, including password resets, MFA enrollment changes, key rotations and new account creation. A real event is a failed login with the account name, source address and reason, followed by a password change or a new privileged account. Gaps appear where authentication runs through a shared identity provider but the connected applications do not forward failure events, or where API keys and tokens are rotated without a log entry.
- Failed logins: Confirm that failures are logged at every entry point, including VPN, SSH, web applications and APIs, not only at the identity provider.
- Lockout and throttling: Check that account lockouts and rate-limit triggers produce an entry.
- Credential changes: Verify that password changes, MFA device changes, certificate and API key rotations are recorded with the actor and the affected account.
- Service credentials: Identify secrets used by applications and confirm that rotation is logged, since these are often missed.
- Failure details: Confirm that each entry records the success or failure outcome and the origin, as requirement 10.2.2 expects.
Check this family by generating a deliberate failed login, a password change and a key rotation on a test system and confirming each produces a complete entry.
This family covers the creation and deletion of system-level objects, which PCI SSC FAQ 1034 describes as anything needed for system operation, such as executables, configuration files, shared libraries, DLLs and device drivers. A real event is an entry showing that a binary was added to a system path, a configuration file was created or removed, a shared library was loaded from a new location, or a device driver was installed. Gaps are frequent because file integrity tooling may cover some paths while container images, ephemeral nodes and package installs create objects that nothing records.
- Executables and libraries: Confirm that new or removed binaries and shared libraries in system directories are logged, including those installed by package managers.
- Configuration files: Check that creation and deletion of configuration files that control security or logging are recorded.
- Device drivers and kernel modules: Verify that driver installation and module loading produce events on in-scope hosts.
- Container and image changes: For Kubernetes and container platforms, confirm that object creation and deletion in the cluster and image registry are captured.
- Coverage map: Document which paths and object types are monitored and where a gap is accepted with a rationale.
Check this family by installing a test package and creating a test configuration file on a sample host, then confirming both events reach the central log with the correct object name and time.
How to implement 10.2 logging step by step
This sequence turns the 10.2 event requirements into a working logging set-up: every in-scope source is known, each event type is mapped to a sub-requirement, each source is configured and tested, and the result is written down so an assessor can trace it. Each step names the output that closes it.
Inventory log sources against the cardholder data environment
Start with the scoped system inventory and data-flow diagrams from your scope validation, then list every system component that stores, processes or transmits cardholder data, plus the systems that can affect its security. Include operating systems, databases, applications, identity providers, administrative consoles, network devices and cloud control planes. Record for each source who owns it, where its logs are generated and whether logging is currently on. The step is complete when every in-scope component appears in one register with a logging status. Ask your QSA early whether they expect the register in a specific format.
Build the event catalog mapped to 10.2.1.1 to 10.2.1.7
Write a catalog that lists the events each source must record, grouped by the seven sub-requirements in 10.2.1: individual access to cardholder data, administrator actions, access to audit logs, invalid logical access attempts, changes to identification and authentication credentials, initialization and stopping of logs, and creation and deletion of system-level objects. For system-level objects, use the scope described in the standard's FAQ on that topic, which covers executables, configuration files, shared libraries and device drivers. Assign each event type to the sources that generate it. The output is a catalog where every event type has a sub-requirement reference, a source list and a named owner.
Configure audit logging on each source
Turn on the audit features each platform provides for the events in the catalog, and confirm that logging starts at boot or service start so the start and stop of logs is itself recorded. Where a platform writes application-level audit data to its own file, such as an administration audit module that writes to a dedicated log file, point the output to a known path and confirm the setting in the platform's configuration documentation. Where operating system, database and application logs overlap, decide which layer captures each event type, using the guidance on combining logs in the standard's FAQ. The output is a configuration record per source showing the settings changed and the event types now captured.
Normalize entries to the 10.2.2 data elements
Check that each log entry carries the details 10.2.2 requires: the event type, the date and time, whether the action succeeded or failed, where it originated, and the identity of the affected data, component, resource or service. Many sources record these fields in different formats, so decide whether to normalize them in a collector or accept native formats and document the mapping. Time values must align with the synchronization approach you will later document under 10.6. Where a source cannot produce a required element, record the gap and the planned fix. The output is a field mapping table and a sample entry from each source that shows every element present.
Forward logs to a central collector
Route entries from every source to a central collection point so that the events are searchable together and protected from local deletion. This step is the handoff to the protection and review requirements, so agree the transport, the collector and the access model with the owners of 10.3 and 10.4 before you build it. Confirm that each source keeps delivering after a restart or a network interruption, and record what happens to buffered entries when the link fails. The output is a data-flow diagram of log paths and a test showing an event on a source arriving at the collector with its fields intact.
Test event generation for every catalog entry
Run a controlled test for each event type in the catalog. Create a test user, perform a failed login, change a test credential, start and stop a log service, create and delete a test system-level object, open an audit log, and access a test cardholder data record through the normal application path. Use test accounts and non-production data where possible, and record the time, the actor and the expected result for each action. Search the central store for each event and check its fields against 10.2.2. The output is a test log showing a pass or a documented gap for every catalog entry, retained as assessment evidence.
Document the configuration and retain evidence
Write up the final state so that an assessor can trace each sub-requirement to a source, a setting, a sample entry and a test result. The document should include the register, the event catalog, the configuration records, the field mapping, the data-flow diagram and the test log, with version numbers and dates. Assign an owner who reviews the document when systems change, such as a new platform, a new cardholder data path or a logging agent upgrade. The output is a versioned logging configuration baseline that the organization owns. An implementation partner can prepare this package, but the organization approves it, and the independent assessor decides whether it meets the requirement.
How a QSA tests audit log coverage under 10.2
This table compares what a QSA does, what they ask you to produce, and where audit log coverage most often falls short under Requirement 10.2. Read each row as a test the assessor will run against your cardholder data environment, then check your own evidence before the assessment starts. The main takeaway is that coverage is judged against your CDE inventory, so every log source you cannot account for is a likely finding.
| Test area | Evidence requested | Common findings |
|---|---|---|
| Sampling log sources against the CDE inventory | Current system component inventory, network and data-flow diagrams, and a list of logging status for each component in scope | Systems in the CDE with logging disabled, or components missing from the inventory that never appear in the log source list |
| Sampling individual events for required fields | Raw log extracts for a sample of events, showing event type, date and time, success or failure, origin, and affected resource | Entries that omit origination or the affected resource, or timestamps that cannot be tied to a single time source |
| Reviewing logging configuration | Exported configuration files, audit policy settings, and change records showing when logging was enabled or altered | Audit settings that capture only some event classes, or configurations that differ between similar systems with no documented reason |
| Checking administrator and log-access events are present | Sample of administrator sessions and privileged commands, plus records of access to the audit log files themselves | Privileged actions performed through shared accounts that leave no attributable entry, or no logging of reads on the audit trail |
| Checking invalid access attempts and credential changes | Failed login records, account lockout events, and logs of password, key, or authentication factor changes for sampled accounts | Failed logins logged on the application but not the operating system or directory, or credential changes with no event record |
| Checking log start and stop events | Records showing logging initialization and shutdown on sampled systems, including restarts and service changes | Gaps in log history with no corresponding stop or start entry, which assessors treat as possible tampering or a configuration failure |
| Checking creation and deletion of system-level objects | Event samples for executables, configuration files, libraries, and drivers changed on sampled systems | Changes to system objects that are not captured, often on containers, virtual machines, or appliances outside the standard image |
| Confirming individual access to cardholder data is logged | Logs from the operating system, database, or application that show user-level access to stored or processed account data | Access logged only at the database service account level, so individual users cannot be identified |
Which evidence shows 10.2 logging is working
An assessor testing 10.2 wants proof that logging is configured, covers every required event, produces readable entries and has not been quietly switched off. The cards below cover the artifacts that prove each of those points, and the routine that keeps them accurate between assessments.
Logging configuration exports per component
Export the active audit logging settings from every system component in scope, including operating systems, databases, applications and cloud services. Assessors compare these exports against the systems listed in your network and data-flow diagrams to confirm that no component in the cardholder data environment is missing from logging. Record the export date, the host name and the person who ran the export, so the file can be traced back to a specific point in time.
Event catalog mapped to 10.2.1
Build a catalog that lists each event your systems log and maps it to the matching 10.2.1 sub-requirement, from individual access to cardholder data through to creation and deletion of system-level objects. Note which component produces each event and where the entry is stored. Where the same event is captured by more than one source, say so, since PCI SSC guidance allows operating system, database and application logging to be combined as appropriate. Review the catalog whenever a new component or application is added.
Sample log extracts showing each 10.2.2 field
Pull representative entries from each log source and check that every entry shows the event type, date and time, success or failure, origin, and the identity of the affected data, component, resource or service. A single extract that is missing one field can fail the requirement for that source, so review them field by field rather than by eye. Keep the extracts alongside the catalog so an assessor can match each event type to a real example.
Evidence of log start and stop
Logging that stops silently is one of the most common gaps assessors find. Keep records showing when audit logging was initialized, stopped or paused on each component, including the reason and the person who authorized it. Pair these records with the system start-up and shutdown history, so any gap in the log stream can be explained. Ask whether your platform writes its own start and stop events, because the answer determines where you look for this evidence.
Change records for logging configuration
Every change to logging settings, such as a new event type, a changed log path or a disabled source, needs a ticket with the requester, the approver, the reason and the before and after values. Store the configuration files in version control so differences between releases are visible. Assessors often ask for these records to show that logging was not reduced without review, so link each change to the change management process used for the rest of the environment.
Keeping evidence current between assessments
Schedule a recurring evidence refresh, with an owner named for each artifact and a fixed review point, rather than rebuilding the file set before each assessment. Compare the latest exports with the previous set and investigate every removed or disabled event. Confirm that the catalog still matches the current system inventory. Ask any implementation partner to deliver these artifacts in a form your own team can regenerate without them.
What meeting 10.2 costs in money and effort
This table breaks down the spending behind Requirement 10.2 by component, showing who gets paid, whether the cost is one-time or recurring, and what moves it up or down. Use it to build a quote request, since no figures are published here and each cost depends on your environment and scope.
| Cost component | One-time or recurring | Cost drivers | How to reduce it |
|---|---|---|---|
| Logging tool licenses or open-source hosting | Licenses are recurring for commercial tools; open-source software has no license fee but hosting is recurring | Number of log sources, retention design, whether you run the stack yourself or pay a provider to host it | Choose tools whose licensing fits your source count; confirm license terms for each component in writing before you commit |
| Engineering time to configure log sources | One-time for initial setup, recurring for changes when systems are added or upgraded | Number of system components, mix of operating systems, databases and applications, how many events must be mapped to 10.2.1.1 through 10.2.1.7 | Inventory system components first, standardize logging configurations, and reuse templates across similar hosts |
| Storage and infrastructure for logs | Recurring, growing with volume and retention period | Event volume, retention period, redundancy, backup copies and whether logs are stored in one or more regions | Filter noise at the source only where your policy allows, compress and tier older logs, and confirm the retention period with your assessor |
| Detection rules and alert tuning | One-time for initial rule sets, recurring for tuning and review | Choice of prepackaged or custom rules, number of log types correlated, volume of false positives | Start from vendor-maintained rule sets, document each tuned rule, and review rule changes on a fixed schedule |
| Evidence upkeep | Recurring, usually tied to each assessment cycle | Number of systems in scope, frequency of configuration changes, how much evidence is collected manually | Automate evidence exports such as logging configuration snapshots, and keep a single owner for the evidence index |
| External review or testing | Recurring, typically once per assessment cycle, with ad hoc work after major changes | Scope size, prior findings, whether a QSA review or an independent test of log coverage is requested | Ask for a written scope that names the systems, log types and sample sizes to be tested before work starts |
| Auditor sampling and testing | Recurring, set by the assessor's testing during each assessment | Number of sampled systems, number of sampled events, gaps found in earlier assessments, quality of evidence on request | Prepare a sample-ready evidence set for each system, and ask the assessor which evidence formats they accept before the assessment starts |
Who owns 10.2: your team, a partner and the assessor
Your organization remains accountable for PCI DSS compliance, and that accountability covers audit logging. Your team decides which systems are in scope, which events the business needs to see, how long event details are kept, and who reviews them. The standard expects these decisions to be documented and to be carried out by people who know the cardholder data environment. A partner can draft the configuration, but the decisions and the sign-off stay with you.
- Scope decisions: Confirm which system components and cardholder data flows fall under 10.2.1, including components that could affect the cardholder data environment.
- Event catalog ownership: Approve the list of events you capture for individual access, administrator actions, failed logins, credential changes and system-level objects.
- Log content standards: Agree which fields each entry must carry under 10.2.2, such as event type, time, outcome, origin and affected resource.
- Operational owners: Name the people who run the logging platform, handle changes to log settings and respond when logging stops.
- Evidence custody: Keep the configuration baselines, change records and sample logs that show the controls operate.
Before any assessment, check that your named owners can explain each logged event type and show a recent sample without help from a vendor.
An implementation partner does the technical preparation under a written scope. Typical work includes enabling audit logging on operating systems, databases, applications and cloud services, mapping each 10.2.1 sub-requirement to a configured source, and building the event catalog that your team approves. The partner also produces the evidence an assessor will sample, such as configuration exports and test records. A partner prepares systems and evidence. It does not decide whether your controls meet the standard and does not issue any report or attestation.
- Logging configuration: Enable and harden audit logging on each in-scope component, including system-level object changes.
- Event mapping: Produce a table that links each event type to its source, field set and retention location.
- Test evidence: Generate controlled events, such as a test failed login or credential change, and record that they appear in the log.
- Documentation: Write runbooks and configuration baselines your team can maintain after the engagement.
- Handover: Train your operators and confirm in writing what the partner delivered and what remains with your team.
When you ask for a proposal, confirm that the partner will not sign or attest the assessment and that the written scope names each component to be configured.
A Qualified Security Assessor (QSA) or other authorized assessor tests the logging controls against the standard and records the result in a Report on Compliance (ROC) or, for eligible entities, an Attestation of Compliance (AOC) on the relevant self-assessment questionnaire. The assessor selects samples, reviews configurations and checks that logged events match your documented event catalog. Only the assessor issues the report. The PCI SSC does not accept certificates as validation.
- Sampling: The assessor chooses systems and time periods, then inspects log entries for the required events and fields.
- Configuration review: The assessor compares live settings with your baselines and the partner's documentation.
- Independence: The assessor should not design or configure the logging it later tests, because that would weaken its own assessment.
- Findings: Gaps are recorded as findings that you must remediate before the report is issued.
- Report issuance: Only the assessor's ROC or AOC counts as the validation output.
Before engaging an assessor, confirm its qualification, its independence rules for advisory work and which SAQ or ROC applies to your entity.
Where 10.2 implementations usually fall short
Most 10.2 failures are not missing logging products. They are gaps in coverage, event content and monitoring of the logging itself. The cards below describe the gaps assessors most often find and how to close each one before the assessment begins.
Logging enabled on only some components
Requirement 10.2.1 expects audit logs to be enabled and active for all system components and cardholder data. Teams often turn logging on for the servers they manage directly and miss load balancers, jump hosts, containers, database servers and cloud control planes that were added later. Build a component inventory from the cardholder data environment diagram, then compare each entry against a log source list. Treat any component without a confirmed log source as a finding until it is closed.
Administrator actions not captured
Sub-requirement 10.2.1.2 covers all actions taken by anyone with administrative access. Gaps appear when privileged actions run through shared accounts, break-glass access, sudo or database roles that log only at the session level. Confirm that each privileged path produces an entry tied to a named individual, and test it by performing a sample administrative change and locating the resulting record.
Access to audit logs not logged
Sub-requirement 10.2.1.3 requires a record of access to audit logs. Teams protect log storage but do not log reads, exports or queries against the log platform itself, so an insider could review or copy logs without a trace. Enable read and export auditing on the log store and its dashboards, and restrict which accounts can query raw logs. Assessors often ask for a sample of these access records, so confirm they can be produced on request.
Incomplete event fields
Requirement 10.2.2 sets the minimum content of each entry: event type, date and time, success or failure, origination, and the identity of the affected data, component or resource. Many default log formats omit origin or outcome, or record local time without a consistent zone. Sample entries from every log source and check each field against the list. Where a source cannot supply a field, add an enrichment step or document why the field is not applicable.
System-level object changes not captured
Sub-requirement 10.2.1.7 requires logging of the creation and deletion of system-level objects. Under PCI SSC FAQ 1034, these include executables, configuration files, shared libraries and device drivers, not only user accounts. Many environments log user activity but not file or package changes on hosts. Define the set of system objects for each platform, enable file creation and deletion monitoring for those paths, and confirm the events reach the central log store.
Logs that stop silently
A logging agent that crashes, a full disk or an expired forwarding certificate can stop audit records without any alert, and the gap only appears when someone searches for an event that should exist. Monitor the logging pipeline itself: heartbeat checks for each source, alerts when a source goes quiet, and disk thresholds on collectors. Record each outage and its resolution, since assessors may ask how stopped logging was detected.
Questions buyers ask about PCI DSS 10.2 audit logging
How much effort does PCI DSS 10.2 audit logging take?
The effort depends mostly on how many system components sit in the cardholder data environment and how much of their logging is already switched on. Requirement 10.2.1 expects audit logs to be enabled and active for all system components and cardholder data, so the work is usually a sweep of every in-scope host, database, application and network device, followed by a check that each one records the events listed in 10.2.1.1 to 10.2.1.7. Teams with a current asset inventory and centralized logging move faster. Ask any provider to split its quote into inventory and gap analysis, logging configuration, event-field validation and evidence capture, because those phases scale differently.
Can an in-house team implement PCI DSS 10.2 logging on its own?
Often yes, if the team already administers the systems and can read its own configuration. The harder part is knowing what the standard expects in each event category, such as administrator actions, invalid access attempts and creation or deletion of system-level objects, and then proving it. Internal teams commonly struggle with logs that record events but omit the event type, date and time, success or failure, origin, or affected resource that 10.2.2 requires. An independent review before the assessment helps catch these gaps. The organization owns its controls, and only a Qualified Security Assessor can validate them in a Report on Compliance.
How long does it take to get 10.2 logging in place?
No duration is fixed by the standard, and any timeline should come from a written scope. Elapsed time is usually set by change windows for production systems, the number of platforms that need new logging rules, and how long the log data takes to appear in a central store where it can be checked. Ask for milestones that cover discovery, configuration changes in non-production first, a test that each required event produces a complete entry, and a dated evidence package for the assessor. Plan for the assessor's sampling period as well, because logging has to run consistently over time, not only on the day it is switched on.
What does the work need from the team, and who is paid for what?
The work needs system administrators who can change logging settings, a security owner who approves the event list, and someone who can answer for the cardholder data environment's boundaries. An implementation partner is paid to prepare systems, configuration and evidence. An independent assessor is paid separately to test the controls and issue the report. Quotes should separate one-time work, such as building the logging baseline and central collection, from recurring work, such as reviewing log health and handling changes when new systems join scope. Ask each provider which of these it performs and which it leaves to your team or your assessor.
Is open-source software acceptable for PCI DSS 10.2 logging?
The standard does not require a particular product. It asks for the right events, with the right fields, protected and reviewed, so open-source tools can produce the evidence if they are configured and documented properly. Nextcloud's admin_audit app writes additional event information to a file that can be placed in a chosen path, OpenBao audit devices keep a detailed JSON log of every API request and response with most sensitive values hashed, and Wazuh decodes and alerts on collected events. Confirm with your assessor how each tool's output maps to the 10.2.2 fields, and verify any capability you depend on in your own environment before you rely on it.
Can a partner issue the PCI DSS validation for 10.2?
No. An implementation partner can prepare logging configuration, documentation and evidence, but it cannot issue validation. Under PCI DSS, validation is documented on official Council templates: a Report on Compliance completed by a Qualified Security Assessor, or a Self-Assessment Questionnaire with an Attestation of Compliance, depending on the entity. Certificates are not recognized as validation. The PCI Security Standards Council does not enforce compliance itself; the individual payment brands decide which entities must validate and run any enforcement programs. Ask your acquirer or the relevant brand which validation type applies to you.
What should a buyer ask a logging partner before signing?
Start by asking for the written scope, the list of systems and log sources covered, and the event categories mapped to each 10.2.1 sub-requirement. Then ask how the partner validates that each event carries the fields 10.2.2 requires, how it handles system-level objects, and how logs are protected from alteration, which connects to Requirement 10.3. Request examples of the evidence package, a named owner for open items, and a clear statement of what remains with your team after handover. A vague answer about evidence is usually the strongest warning sign.
How self-hosted open-source platforms produce 10.2 evidence
Open-source platforms can generate much of the raw record that 10.2 expects, but each tool covers a different slice of the picture, and none of them decides on its own whether the record is sufficient. Start by mapping each event type in 10.2.1.1 to 10.2.1.7 to a named source. In a self-hosted stack, the question is which component writes the event, where it lands and who can read it, not whether a product has a logging feature. Nextcloud's admin_audit app writes additional event information to audit.log in the data directory, or to a path set with logfile_audit, which makes it a candidate source for administrator actions and user activity on the file platform. Confirm in your own configuration which events the app records, because the facts supplied here do not list them.
OpenBao audit devices keep a detailed JSON log of every API request and response, including errors, with most sensitive values hashed with HMAC-SHA256. This is a useful source for credential and secrets activity, since it records who asked for what and whether it failed, while keeping secret values out of the log itself. Confirm that at least one audit device is enabled on every OpenBao cluster in scope, because an audit device that is not enabled records nothing. OpenSearch Security Analytics and Wazuh sit downstream: OpenSearch runs detectors that match ingested logs against Sigma rules and records findings with rule, log type and severity, while Wazuh decodes collected logs, compares each event against a ruleset of over 3,000 built-in rules and decoders plus custom rules, and writes alerts to alerts.log and alerts.json. Both show whether suspicious events were noticed, which is different from showing that every required event was captured.
Plan for the assessor's question of sufficiency. Tools can show that a log exists, but the assessor will check the field content against 10.2.2, the completeness of event coverage and whether logging is active on every system component in scope. Ask your QSA which samples they will pull and confirm that the platform's timestamps, success or failure fields and origin data appear in them. Licensing affects this plan: Nextcloud is licensed under AGPL-3.0-only, OpenBao under MPL-2.0, OpenSearch under Apache-2.0 and Wazuh under GPL-2.0-only. Review the obligations of each license with counsel before you modify or redistribute these components, since your assessment file must describe what you actually run.
How DeployOpen works on this
DeployOpen plans and builds the audit logging that 10.2 expects inside your own infrastructure, using self-hosted open-source platforms, then documents the evidence for your assessor. Your organization owns the logging controls and decides what is in scope, and only your independent QSA can assess and validate them.
How we scope
- Inventory every system component and cardholder data flow that must generate audit logs under 10.2.1.
- Map each 10.2.1.1 to 10.2.1.7 event type to the systems that produce it, and record any gaps.
- Agree the scope, deliverables and timelines in writing before any work starts, as fixed-scope engagements do.
- Confirm with your QSA which logs they expect to sample, including database and application logs under FAQ 1081.
How we build
- Enable and verify audit logging on in-scope operating systems, applications and databases inside your environment.
- Configure each log entry to capture the 10.2.2 fields: event type, date and time, outcome, origin and affected resource.
- Set up audit devices and admin audit logging for platforms such as OpenBao and Nextcloud where they fit the design.
- Test that logging stays active by simulating administrator actions, failed logins and credential changes, then checking the output.
How we hand over
- Document the logging configuration, event coverage matrix and system-level object list as evidence for the assessor.
- Provide runbooks that show how logs are enabled, changed and checked, with named roles your team can maintain.
- Deliver test results showing each event category was captured, so your QSA can trace evidence to each requirement.
- Walk your internal owners through the evidence package and record open items that remain with your organization.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer if your logging stack changes after handover.
- Re-check event coverage when new systems enter the cardholder data environment or existing configurations change.
- Confirm with your organization and your QSA what evidence is needed for each assessment cycle before the audit begins.
- Keep the decision on whether logging meets 10.2 with your organization and its independent assessor, not with DeployOpen.
