PCI DSS Requirements 7 and 10 on Linux

What Do PCI DSS Requirements 7 and 10 Require on Linux?

PCI DSS — currently version 4.0.1 — governs any system in the cardholder data environment (CDE): the systems that store, process, or transmit payment card data, and the systems connected to them. Like other frameworks it does not name an operating system, but the CDE is overwhelmingly built on Linux, so its access and logging requirements land on your Linux hosts. Two requirements matter most for Linux identity and audit: Requirement 7, which restricts who can reach the environment, and Requirement 10, which records what they did once they were in.

The two are deliberately paired. Requirement 7 is preventive — it limits access to the minimum each role needs. Requirement 10 is detective — it ensures that every use of that access leaves a trail an assessor and an investigator can follow. On Linux, Requirement 7 is largely a story about accounts and sudo, and Requirement 10 is largely a story about auditd. Getting both right, and being able to prove it across the whole CDE, is what a PCI assessment tests.

Scope is worth settling first, because it decides which Linux hosts carry these controls. The requirements apply to the systems in the cardholder data environment and anything connected to or able to affect it; strong network segmentation is what keeps that boundary small. A Linux host isolated from the CDE is out of scope, while the servers that process card data, and the jump boxes and management hosts that reach them, are firmly in. Defining that boundary accurately keeps the access and logging effort focused where a failure would actually expose card data.

Requirement 7: Restrict Access by Need to Know

Requirement 7 is titled "Restrict access to system components and cardholder data by business need to know." Its principle is least privilege: each person and each process gets only the access their role genuinely requires, and everything else is denied. The standard is explicit that the access control system must default to "deny all" (7.3.3), so access is granted deliberately rather than inherited by accident.

Two operational duties follow. Access must be assigned by role and kept to least privilege (7.2.2), and it must be reviewed: PCI DSS v4.0.1 requires that all user accounts and their access privileges are reviewed at least once every six months (7.2.4) to confirm the access is still appropriate, with third-party and vendor accounts included. Application and system accounts — the non-human identities that run services — are managed and reviewed as well (7.2.5), with the review frequency for those driven by a targeted risk analysis. On Linux this is where sudo, group membership, and service accounts come under direct scrutiny: a blanket sudo grant or a shared root login is the opposite of need-to-know, and an unreviewed service account is exactly what 7.2.5 exists to catch.

Requirement 10: Track and Monitor All Access

Requirement 10 is titled "Log and monitor all access to system components and cardholder data," and its objective is to track and monitor all such access so that anomalies can be detected and an incident reconstructed. It is specific about what must be logged. The events include each individual user's access to cardholder data, all actions taken by administrators or root, all access to the audit logs themselves, invalid logical access attempts, changes to identification and authentication credentials, the starting, stopping, or pausing of the audit logs, and the creation or deletion of system-level objects (10.2.1). Each log entry has to capture enough to be useful: who did it, what type of event, the date and time, whether it succeeded or failed, where it originated, and which data, component, or resource was affected (10.2.2).

Logging is only trustworthy if the logs cannot be quietly altered, so Requirement 10 also protects them: read access is limited to those with a need (10.3.1), the logs are protected from modification (10.3.2), they are promptly backed up to a secure, central location (10.3.3), and file-integrity or change-detection mechanisms flag tampering (10.3.4). The logs must be reviewed — critical logs at least daily, increasingly through automated mechanisms (10.4.1) — and retained: PCI DSS requires audit log history to be kept for at least twelve months, with at least the most recent three months immediately available for analysis (10.5.1).

Two supporting controls make the rest of Requirement 10 dependable. The logs are only comparable across hosts if their clocks agree, so PCI DSS requires time to be synchronised across systems (10.6) — on Linux, a consistent NTP or chrony configuration — otherwise correlating an event across two servers becomes guesswork. And the standard expects failures of critical security controls, including the audit logging itself, to be detected and responded to promptly (10.7): if auditd stops on a CDE host, that is an event someone has to notice, not a silence that goes unremarked until the next assessment.

Mapping to sudoers and auditd

On Linux, Requirement 7 is enforced largely through sudo. Least privilege means granting specific commands rather than blanket ALL=(ALL) rights, tying grants to named users through groups rather than shared accounts, and avoiding broad NOPASSWD rules that let elevation happen silently. The "deny all" default maps to the fact that a user has no privileged access unless a sudoers rule or group membership explicitly grants it, so the security of Requirement 7 is only as good as your control over /etc/sudoers, everything in /etc/sudoers.d, and the membership of privileged groups such as wheel and sudo. Those three artefacts, reviewed and attested, are the evidence behind the six-monthly access review.

Requirement 10 maps onto auditd, the Linux Audit daemon, which is purpose-built to record the events 10.2.1 asks for. Rules watch the files and syscalls that matter — for example, watching the sudoers configuration for change, logging privileged command execution, and recording writes to the account and credential files:

-w /etc/sudoers   -p wa -k pci_access     # changes to sudo policy
-w /etc/sudoers.d/ -p wa -k pci_access
-w /etc/passwd    -p wa -k pci_identity   # account changes
-w /etc/shadow    -p wa -k pci_identity   # credential changes
-w /var/log/audit/ -p wr -k pci_logaccess # access to the audit logs
-a always,exit -F arch=b64 -S execve -F euid=0 -k pci_rootcmd  # root command execution

Running auditd with its configuration made immutable (the -e 2 flag) helps satisfy the requirement that logs are protected from modification (10.3.2), because the rules cannot be changed without a reboot that is itself logged. Shipping the audit trail to a central, write-once store addresses the backup and retention duties (10.3.3 and 10.5.1), and tools such as ausearch and aureport support the daily review (10.4.1). The point is not that auditd is exotic — it ships with every enterprise Linux — but that its rules must be complete, consistent across every CDE host, and provably unchanged, which is exactly where manual configuration drifts.

Evidence an Assessor Accepts

For Requirement 7, an assessor wants a current listing of every account on each in-scope Linux host together with its sudo and group privileges, evidence that access is least-privilege and defaults to deny, records of the six-monthly reviews with a named reviewer's sign-off, and an inventory of the service accounts and how their access was justified. For Requirement 10, they want proof that auditd is enabled and active on every CDE host, that it captures the full 10.2.1 event set, that the logs are protected and centrally retained for at least twelve months with three months immediately available, and evidence that the daily review actually happens.

The difficulty, as ever, is completeness and consistency across the whole environment. A screenshot from one server proves nothing about the other fifty, an auditd ruleset that is correct on the golden image may have drifted on the hosts built from it, and a listing printed today says nothing about who had access three months ago. Evidence produced continuously — host-level discovery that inventories accounts, sudo rules, group membership, and SSH keys, verifies the audit configuration on every host against a baseline, and records every change as it happens — turns each of these requirements from an anxious annual reconstruction into a question you can answer on demand, for any date in the assessment period.

For how PCI DSS access evidence fits alongside NIS2, DORA, and the wider compliance picture, see the Linux access controls evidence guide, which walks through the access-control expectations across frameworks for IT teams.

FAQ

Do PCI DSS Requirements 7 and 10 apply to Linux servers?

They apply to any system in the cardholder data environment, which is overwhelmingly built on Linux. Requirement 7 restricts access by business need to know — on Linux, largely through accounts, groups, and sudo — and Requirement 10 requires all access to be logged and monitored, on Linux largely through the auditd daemon. Neither names Linux, but both are enforced and evidenced on your Linux hosts.

What must Requirement 10 log on a Linux host?

Under PCI DSS v4.0.1, the events include each user's access to cardholder data, all actions by administrators or root, all access to the audit logs, invalid logical access attempts, changes to authentication credentials, the starting or stopping of the audit logs, and creation or deletion of system-level objects. On Linux these are captured by auditd rules that watch the relevant files and syscalls, with each entry recording who, what, when, success or failure, origin, and the affected resource.

How long must PCI DSS audit logs be retained?

PCI DSS v4.0.1 Requirement 10.5.1 requires audit log history to be retained for at least twelve months, with at least the most recent three months immediately available for analysis. On Linux this usually means shipping auditd output to a central, protected log store that enforces the retention period and keeps recent logs quickly searchable.

How often must access be reviewed for Requirement 7?

PCI DSS v4.0.1 Requirement 7.2.4 requires that all user accounts and their access privileges — including third-party and vendor accounts — are reviewed at least once every six months to confirm the access remains appropriate. Application and system (service) accounts are managed under 7.2.5, with their review frequency determined by a targeted risk analysis. On Linux the review covers sudo rules, group membership, and service accounts.