Log System-Level Object Changes

To meet the PCI DSS log system-level object changes requirement, you must configure audit logging so every creation and deletion of system-level objects is captured in immutable, reviewable audit logs across all in-scope systems. Treat “system-level objects” as privileged OS, directory, database, and platform objects that can change security posture or access. (PCI DSS v4.0.1 Requirement 10.2.1.7)

Key takeaways:

• Log both creation and deletion events for system-level objects, not just user activity. (PCI DSS v4.0.1 Requirement 10.2.1.7)
• Define “system-level objects” for your environment, then map required events to each platform’s native audit sources.
• Prove it with evidence: event samples, configurations, centralized collection, and operational checks that show logs are complete and tamper-resistant.

“Log system-level object changes” is a narrow-sounding requirement that often fails in practice because teams don’t agree on what counts as a “system-level object,” or they assume default logging already covers it. PCI DSS is explicit: your audit logs must capture all creation and deletion of system-level objects. (PCI DSS v4.0.1 Requirement 10.2.1.7) That means you need a defensible definition, platform-specific audit settings, and centralized log handling that preserves integrity and makes these events searchable during investigations.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to operationalize this as a control with three parts: (1) scope and object taxonomy, (2) technical logging configuration by platform, and (3) ongoing verification and evidence retention. Your assessor will look for completeness (are you missing common object types), consistency (does every in-scope system behave the same), and auditability (can you demonstrate real event records for creation and deletion). This page gives you requirement-level guidance you can hand to IT/security to implement quickly and defend during an assessment.

Regulatory text

Requirement: “Audit logs capture all creation and deletion of system-level objects.” (PCI DSS v4.0.1 Requirement 10.2.1.7)

What the operator must do: Configure logging across the PCI DSS scope so that whenever a system-level object is created or deleted, an audit event is generated, collected, retained, and can be produced during an assessment. The key operator burden is deciding what “system-level object” means in your environment and proving you capture those events everywhere that stores, processes, or transmits cardholder data, plus connected security systems in scope.

Plain-English interpretation (what counts and what doesn’t)

This requirement is about security-relevant objects at the system/platform layer, not business records. A “system-level object” is any object that, if created or deleted, can change access paths, privilege boundaries, authentication/authorization behavior, system integrity, or logging/monitoring coverage.

Use this pragmatic definition in your control narrative:

A system-level object is an OS, directory, platform, database, or security control object that governs identity, privilege, configuration, connectivity, or enforcement. We log events for the creation and deletion of these objects across all in-scope systems. (PCI DSS v4.0.1 Requirement 10.2.1.7)

Examples you typically should treat as system-level objects (adapt to your environment):

• Identity and access objects: local users, local groups, directory users/groups, service accounts, machine accounts.
• Privilege and policy objects: sudoers entries, RBAC roles, IAM roles/policies, GPOs, security profiles.
• Security control objects: firewall rules/objects, WAF policies, endpoint protection policies, IDS rules (where the platform logs these as create/delete events).
• Platform objects that enable/disable access: SSH authorized keys entries (where represented as managed objects), API keys, access tokens (if managed as objects by a control plane).
• Database platform objects: database users, roles, grants/permissions objects, schemas (depending on how your DB logs object DDL).

Non-examples (usually): customer records, payment transactions, application-level entities like “store locations,” unless your application treats those as access control objects that impact system authorization.

Who it applies to (entity and operational context)

PCI DSS applies to merchants, service providers, and payment processors operating environments that store, process, or transmit cardholder data, plus connected systems within the PCI scope boundary. (PCI DSS v4.0.1 Requirement 10.2.1.7)

Operationally, this requirement hits:

• OS platforms (Windows, Linux, network appliances) in the cardholder data environment (CDE) and in-scope segments.
• Identity systems (AD/Azure AD/LDAP, IAM) used to administer or access in-scope systems.
• Databases and middleware hosting payment components.
• Security tooling that enforces access or network controls for the CDE (where object changes can materially affect security).

If you rely on a third party (cloud provider, managed security service, managed database), you still own demonstrating the requirement is met for your scope. Your contract and attestations can support the story, but assessors typically still want your evidence that logging is enabled and events are available.

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

1) Write a one-page control definition that engineering can implement

Create a control statement that includes:

• Your definition of “system-level objects”
• In-scope platforms and log sources
• Event types required: create and delete
• Central collection destination (SIEM/log platform)
• Ownership: system owners implement; security monitors; compliance validates

Keep this aligned to the requirement language. (PCI DSS v4.0.1 Requirement 10.2.1.7)

2) Build an object-and-event mapping table

Make a table that links “object type” → “where it’s created/deleted” → “what log proves it.”

Example structure (fill with your platforms):

System-level object type	Platform(s)	Create events	Delete events	Log source
Local user/group	Windows/Linux	useradd/New-LocalUser	userdel/Remove-LocalUser	OS security audit logs
Directory user/group	AD/Azure AD/LDAP	user created	user deleted	Directory audit logs
Privileged role/policy	IAM / RBAC	role created	role deleted	Control plane audit logs
Database role/user	DB engine	CREATE ROLE/USER	DROP ROLE/USER	DB audit logs

This mapping becomes your assessor-ready proof that you understood “system-level objects” and implemented logging accordingly. (PCI DSS v4.0.1 Requirement 10.2.1.7)

3) Turn on the right native auditing per platform (don’t rely on defaults)

Implementation is platform-specific, but the pattern is consistent:

• Enable auditing for account management / security group management / policy changes / object management categories that emit create/delete events.
• Ensure the logs record who performed the action, target object, timestamp, source host, and outcome (success/failure) where available.
• Confirm admin actions performed through control planes (cloud consoles, directory admin portals) generate audit events.

Your test is simple: create a representative system-level object, then delete it, and verify both events appear end-to-end in your central log store. (PCI DSS v4.0.1 Requirement 10.2.1.7)

4) Centralize collection and protect log integrity

Operationalize collection so logs are:

• Forwarded off-host (reduce attacker tampering risk)
• Normalized with consistent fields (object name, action=create/delete, actor, system)
• Retained per your PCI DSS logging/retention program

Even though this requirement is about capturing events, assessors often evaluate whether the capture is credible without centralized, protected collection.

5) Create detection and review hooks (so it’s not dead data)

Add basic alerting or review queries for:

• Creation of privileged accounts/roles
• Deletion of logging-related objects (agents, policies, forwarding configs)
• Deletion bursts (many objects deleted quickly)
• Object changes outside approved change windows

This is where Daydream can fit naturally: use it to manage the control mapping table, assign implementation tasks to system owners, and maintain an evidence checklist tied directly to PCI DSS v4.0.1 Requirement 10.2.1.7 so you can produce consistent artifacts each assessment cycle without rebuilding the story.

Required evidence and artifacts to retain

Maintain artifacts that prove design, implementation, and operating effectiveness:

Design

• Logging standard/control narrative that defines “system-level objects” and required create/delete logging. (PCI DSS v4.0.1 Requirement 10.2.1.7)
• Scope list: in-scope systems, identity platforms, databases, security controls.

Implementation

• Screenshots/exports of audit policy settings per platform (or infrastructure-as-code configs showing audit settings enabled).
• Log forwarding configuration (agent config, syslog settings, cloud log sinks).
• The object-and-event mapping table described above.

Operating effectiveness

• Sample log events showing a create and a delete for each major platform class (OS, directory/IAM, database). Redact sensitive data, but keep object identifiers. (PCI DSS v4.0.1 Requirement 10.2.1.7)
• Change tickets or approvals tied to real object changes (where your process requires it).
• Evidence of periodic verification (a runbook plus a recorded test or review notes).

Common exam/audit questions and hangups

Expect these questions from a PCI assessor:

1. “Define system-level objects for your environment.” Have your definition and mapping ready. (PCI DSS v4.0.1 Requirement 10.2.1.7)
2. “Show me events for create and delete.” They will ask for real log entries, not just configs.
3. “Is this enabled everywhere in scope?” Be ready to show coverage across representative samples, including jump hosts, directory services, and cloud control plane logs where used for administration.
4. “What about third-party managed systems?” Provide your contractual/log access evidence plus sample events you can retrieve.

Hangups that slow assessments:

• Teams confuse “configuration changes” with “object creation/deletion.” This requirement is narrower: it wants create/delete of system-level objects. (PCI DSS v4.0.1 Requirement 10.2.1.7)
• Logging exists on-host but is not forwarded, or forwarding fails silently.

Frequent implementation mistakes (and how to avoid them)

1. Only logging successful changes. Capture failures too where possible, but at minimum ensure create/delete events are consistently captured. Validate with negative testing.
2. Ignoring cloud control plane logs. If object management happens in a console/API, you need those audit events available.
3. Treating database DDL as “application logging.” Ensure the database audit source records CREATE/DROP of roles/users/schemas that affect access.
4. No single owner for “system-level objects.” Assign ownership by platform (Windows team, IAM team, DBAs) and central accountability to security/compliance.
5. Evidence that doesn’t match scope. Audit settings from non-CDE systems do not help. Tag artifacts to in-scope asset inventory.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific actions. Practically, failing to log creation/deletion of system-level objects weakens investigations and containment. If an attacker creates a privileged account, creates a new IAM role, or deletes a security object, you need a reliable audit trail to reconstruct the sequence and demonstrate control operation during an assessment. (PCI DSS v4.0.1 Requirement 10.2.1.7)

Practical 30/60/90-day execution plan

You can run this as three phases without waiting for a full logging program redesign.

First 30 days (baseline and scope alignment)

• Confirm PCI scope systems and admin planes where system objects are managed.
• Publish the control definition and “system-level object” taxonomy.
• Build the object-and-event mapping table and assign platform owners.
• Run a proof test in a lower environment: create/delete representative objects; confirm logs appear centrally. (PCI DSS v4.0.1 Requirement 10.2.1.7)

Next 60 days (implement and standardize)

• Enable/adjust audit settings on all in-scope platforms per the mapping.
• Ensure central forwarding works for each log source; fix gaps (agents, permissions, sinks).
• Create saved SIEM searches (or equivalent) for privileged object create/delete events.
• Start collecting evidence bundles per platform (configs + sample events). (PCI DSS v4.0.1 Requirement 10.2.1.7)

Next 90 days (operationalize and make it audit-proof)

• Add a recurring verification runbook: spot-check that create/delete events are still arriving after patches and upgrades.
• Tie object changes to change management where applicable (especially for privileged roles/accounts).
• Conduct an internal “assessor-style” walkthrough: pick an in-scope system and demonstrate create/delete events end-to-end, including who can access logs and how integrity is protected. (PCI DSS v4.0.1 Requirement 10.2.1.7)

Frequently Asked Questions

What exactly is a “system-level object” under this requirement?

PCI DSS requires logging creation and deletion of system-level objects, but you must define the object set for your environment. A good definition covers identity, privilege, policy, and security enforcement objects at the OS/platform layer. (PCI DSS v4.0.1 Requirement 10.2.1.7)

Do I need to log changes to files and folders?

Only if your program defines certain filesystem objects as system-level objects (for example, security policy files or privileged configuration artifacts) and your assessor agrees the definition is reasonable for your environment. The requirement text itself focuses on creation and deletion of system-level objects, so anchor your approach to access/privilege-impacting objects. (PCI DSS v4.0.1 Requirement 10.2.1.7)

Does this apply to cloud environments and SaaS admin consoles?

Yes if those control planes administer in-scope systems or security controls. You need the provider’s audit logs (for example, IAM role/user create/delete) available and retained so you can show the events during assessment. (PCI DSS v4.0.1 Requirement 10.2.1.7)

What evidence will an assessor accept to prove compliance?

Expect to provide both configuration evidence (audit settings enabled) and operational evidence (sample create and delete log events from in-scope platforms). A mapping table that ties object types to log sources speeds the review. (PCI DSS v4.0.1 Requirement 10.2.1.7)

We outsource infrastructure to a third party. Can we inherit this requirement?

You can rely on third-party controls for parts of the stack, but you still need to demonstrate that audit logs capturing object creation/deletion are available for your PCI scope and can be produced on request. Keep contracts, attestations, and sample events you can access. (PCI DSS v4.0.1 Requirement 10.2.1.7)

How do we keep this from breaking after upgrades?

Add a recurring verification step that tests a create/delete event path after major OS, directory, database, or agent changes. Treat missing object-change events as a logging defect that triggers incident-style response until restored. (PCI DSS v4.0.1 Requirement 10.2.1.7)