PCI DSS 7 and 10 on Linux turn sudo and auditd into evidence

At a glance

What this is: This is a Linux-focused interpretation of PCI DSS Requirements 7 and 10, with the key finding that sudo governance and auditd logging carry most of the control burden on in-scope hosts.

Why it matters: It matters because IAM teams, PAM teams, and auditors must be able to show least privilege, review cadence, and tamper-resistant logging across Linux systems that touch card data.

👉 Read LinuxGuard's analysis of PCI DSS Requirements 7 and 10 on Linux

Context

PCI DSS Requirements 7 and 10 become identity controls once the cardholder data environment lands on Linux. The practical question is not whether Linux is named in the standard, but whether accounts, sudo rules, service accounts, and audit trails can prove who had access and what they did.

The governance gap is completeness across the in-scope estate. A single well-configured host is not evidence for the environment, and a control that cannot be shown consistently across jump boxes, management hosts, and application servers is not ready for assessment.

Key questions

Q: What breaks when privileged users are not tightly controlled in PCI DSS scope?

A: When privileged users are not tightly controlled, organisations lose separation between administrative activity and ordinary access, which weakens both prevention and evidence collection. That creates gaps in audit trails, increases the chance of unauthorized configuration changes, and makes it harder to prove who accessed what. In PCI DSS environments, those gaps directly undermine accountability and control assurance.

Q: When should teams prioritise access reviews over more Linux hardening work?

A: Prioritise access reviews when privileged Linux accounts, third-party access, or service accounts are not clearly owned and recertified. PCI DSS makes access governance a direct control requirement, so unclear account ownership is not a secondary hygiene issue. It is a current compliance and security exposure that can undermine the whole CDE boundary.

Q: What do security teams get wrong about Linux audit logging for PCI DSS?

A: They often log too little, trust the logs too much, or fail to prove the logs are complete across the whole CDE. Requirement 10 is not satisfied by enabling auditd on one host. Teams need consistent rules, protected retention, and daily review evidence across every in-scope Linux system.

Q: How should assessors judge whether a Linux CDE is actually compliant?

A: They should look for environment-wide evidence, not isolated screenshots. The meaningful test is whether every in-scope Linux host shows least-privilege access, complete audit coverage, retained logs, and a documented review cadence. If any of those exist only on the golden image, the control is not proved in practice.

Technical breakdown

How Requirement 7 maps to Linux accounts and sudo

PCI DSS Requirement 7 is a least-privilege control, and on Linux that usually means explicit account assignment, group-based privileges, and tightly scoped sudoers rules. The standard's deny-all posture matters because Linux privilege often accumulates through group membership, inherited admin habits, and broad elevation rules that become invisible over time. Service accounts are not exempt. If a non-human identity can reach cardholder data or privileged functions, its access must be justified and reviewed on the same governance basis as user access.

Practical implication: Prune sudoers, privileged groups, and service-account grants until every privilege has a named business purpose.

Why Requirement 10 depends on auditd and time synchronisation

Requirement 10 is about reconstructability, not just logging volume. On Linux, auditd is the mechanism that records privileged actions, account changes, access to audit logs, and other events an assessor will expect to see, while time synchronisation makes those events usable across hosts. Without consistent clocks, a central log stream still leaves investigators guessing about sequence. Without tamper protection and retention, a log exists but cannot be trusted as evidence. The control only works when collection, integrity, and correlation are all present.

Practical implication: Verify auditd coverage and clock sync together, because one without the other weakens incident reconstruction.

Why the CDE boundary decides the control scope

PCI DSS does not apply to Linux in the abstract. It applies to the systems in the cardholder data environment and to connected systems that can affect it, which is why segmentation is a governance decision as much as a network one. Hosts outside the boundary are out of scope, but jump boxes, management systems, and connected administrative systems are often pulled in because they can influence in-scope assets. If the boundary is fuzzy, the control set becomes fuzzy too, and evidence collection loses its precision.

Practical implication: Document the CDE boundary before you map access and logging duties, or assessment scope will drift.

NHI Mgmt Group analysis

Linux turns PCI DSS into identity governance, not just system hardening: Requirement 7 is really about who may act, and Requirement 10 is about whether those actions can be reconstructed. On Linux, that puts accounts, groups, sudo rules, and auditd at the center of assessment evidence. Practitioners should treat the host as an identity enforcement point, not a generic server.

Service accounts are a governance blind spot unless they are reviewed like user access: PCI DSS v4.0.1 explicitly includes application and system accounts in the review model. That matters because Linux estates often accumulate long-lived service accounts with broad reach and weak ownership. The implication is that service-account governance belongs in the same access-review process as human accounts, not in a separate operational cupboard.

Identity evidence is only credible when it is environment-wide: A secure configuration on one Linux host does not prove the CDE is controlled. PCI assessments test completeness, consistency, and retention across the full scope, which means drift between golden images and real hosts is itself a governance problem. Practitioners need evidence that survives host count, change pace, and assessor scrutiny.

Denial by default and log integrity are the two controls that make Linux auditable: Requirement 7 assumes access is granted deliberately, while Requirement 10 assumes the resulting activity cannot be quietly altered or lost. Those assumptions fail when sudo policy is broad or audit logs are mutable. The practical conclusion is that Linux privilege and logging should be governed as one control chain, not two separate checklists.

What this signals

Linux PCI evidence is a control-chain problem: access review, sudo design, audit integrity, and time synchronisation have to work together, or the evidence trail collapses under assessment. The programme implication is that IAM, PAM, and Linux operations cannot be managed as separate silos when card data is in scope.

Linux access governance belongs in the same review rhythm as compliance evidence: six-month account reviews are only useful if privileged groups, service accounts, and connected management hosts are included. Teams should expect assessors to test whether the review process reaches the full CDE, not just a subset of servers.

For practitioners

• Tighten sudo to named commands Replace blanket admin elevation with command-level sudo rules, role-based groups, and explicit exception handling for any NOPASSWD use.
• Inventory Linux service accounts separately Track every non-human account in the CDE, document ownership and business justification, and include those accounts in recurring access reviews.
• Prove auditd coverage on every in-scope host Confirm audit rules capture privileged execution, account changes, and audit-log access, then verify the ruleset is active and immutable.
• Synchronise host clocks before relying on logs Use a consistent time source across the CDE so audit records can be correlated across servers during assessment and incident review.
• Evidence the CDE boundary explicitly Document which Linux hosts are in scope, which are connected systems, and which are out of scope because segmentation genuinely isolates them.

Key takeaways

• PCI DSS on Linux is fundamentally an identity and logging governance problem, not just a host configuration exercise.
• The standard's real test is whether access and activity can be proven across every in-scope Linux system, including service accounts.
• Strong evidence comes from consistent sudo policy, complete auditd coverage, protected logs, and documented review cadence.

Key terms

• Cardholder Data Environment: The cardholder data environment is the set of systems, users, and processes that store, process, or transmit payment card data. For NHI governance, it includes every machine identity that can influence those systems, even when the identity itself is invisible to end users.
• Least Privilege: A security principle requiring that every identity, human or non-human, is granted only the minimum permissions necessary to perform its function. Least privilege is the single most effective control for reducing NHI blast radius.
• Auditd: Auditd is the Linux audit subsystem used to record system events such as file changes, command execution, and authentication-related activity. In privileged access environments, it provides detailed evidence, but the rules must be scoped carefully so the resulting logs remain reviewable and operationally useful.
• Service Account: A special-purpose account used by applications, automated tools, or services rather than a human user to interact with systems, APIs, and infrastructure. Service accounts are a primary category of NHI and one of the most frequently exploited attack vectors.

What's in the full article

LinuxGuard's full article covers the operational detail this post intentionally leaves for the source:

• Exact sudoers mappings for Requirement 7, including how to evidence least privilege on Linux
• auditd rule examples that capture privileged execution, credential changes, and audit-log access
• Assessment-ready retention and review expectations for Requirement 10 on Linux hosts
• Boundary-setting guidance for deciding which Linux systems are in the cardholder data environment

👉 The full LinuxGuard article covers sudo mapping, auditd rule examples, and assessor evidence expectations for Linux hosts.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.