PCI DSS 10.2.1.7: Creating or deleting a system-level object is logged.
PCI DSS v4.0.1 control 10.2.1.7: the requirement in full, the 1 testing procedure an assessor uses to verify it, and the related controls in section 10.2.
PCIComplianceHubLast updated Last reviewed against PCI DSS v4.0.1
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data › Section 10.2
Audit logs capture all creation and deletion of system-level objects.
Summary
Creating or deleting a system-level object is logged.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 10.2.1.7 | Examine audit log configurations and log data to verify that creation and deletion of system level objects is captured. |
The least familiar of the seven, but Appendix G defines it: anything on a system component that is required for its operation, including but not limited to 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. Creation and deletion are singled out because they are how persistence and cleanup happen. A new scheduled task is how access survives a reboot; a deleted table is how evidence stops existing. Note the pairing with 11.5.2, change detection on critical files: that alerts on unauthorised changes, additions and deletions of critical files, and this logs every creation and deletion of a system-level object, authorised or not.
What to prepare
- The system-level objects in your environment, mapped to the Appendix G definition: application and system executables, configuration files, libraries and DLLs, device drivers, and third-party components.
- Configuration showing creation and deletion are captured for each class.
- Real entries for a creation and a deletion.
How to implement it
1. Start from the Appendix G definition. It names application and system executables, configuration files, static and shared libraries and DLLs, device drivers and third-party components; database schema objects, scheduled tasks and services can be added, and writing the list down is what makes the rest assessable.
2. Turn on database DDL auditing. It is usually separate from the data-access auditing behind 10.2.1.1 and may be off by default.
3. Use the cloud audit trail. Resource creation and deletion is exactly what it records, so the work is collecting and retaining it rather than enabling it.
4. Watch deletions particularly. Creation is noisy and mostly legitimate; deletion of a system-level object is rarer and much more likely to matter.
Where this commonly fails
- No definition of system-level object, so the control is claimed without anyone knowing what it covers.
- Database DDL auditing off, leaving schema changes unrecorded.
- Cloud resource events generated and never collected, because the trail is enabled by default and retention is not.
- Scheduled tasks and services excluded, which is one place persistence is established.
Related controls
Others in section 10.2:
| Control | What it requires |
|---|---|
| 10.2.1 | Audit logs are enabled and active for all system components and cardholder data |
| 10.2.1.1 | Audit logs capture all individual user access to cardholder data |
| 10.2.1.2 | Audit logs capture all actions taken by any individual with administrative access… |
| 10.2.1.3 | Audit logs capture all access to audit logs |
| 10.2.1.4 | Audit logs capture all invalid logical access attempts |
| 10.2.1.5 | Audit logs capture all changes to identification and authentication credentials… |
| 10.2.1.6 | Audit logs capture… |
| 10.2.2 | Audit logs record the following details for each auditable event… |
Terms
Glossary entries that name this control, each with its own example, limits and sources:
← 10.2.1.6 · All controls · 10.2.2 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.