> For the complete documentation index, see [llms.txt](https://docs.linuxguard.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.linuxguard.io/audit-and-comply/audit-comply/pci-dss.md).

# PCI-DSS v4.0.1

> **Note**: This page maps LinuxGuard against **PCI-DSS v4.0.1** (effective 2024-06-01). Last verified against the framework on 2026-05-31. Canonical framework document: [PCI Security Standards Council — PCI-DSS v4.0.1](https://www.pcisecuritystandards.org/document_library/). For the vocabulary contract used here, see [Audit & Comply](/audit-and-comply/audit-comply.md).

## Scope

This page maps LinuxGuard's agent and console capabilities against PCI-DSS v4.0.1. The mapping is scoped to controls in audit logging, file integrity monitoring, configuration management, identity and access tracking, and behavioral monitoring on Linux systems within the Cardholder Data Environment (CDE). Controls in cardholder data environment scope definition, network segmentation, application-layer authentication, key management, anti-malware, encryption-in-transit, physical access, and information security policy administration are out of scope for this product and are listed in the mapping table as `Out of scope` rather than omitted. This mapping is informational and not a substitute for an independent audit by a qualified assessor.

Customers remain responsible for defining CDE boundaries (PCI-DSS scope), implementing and validating network segmentation, completing the annual self-assessment questionnaire or Report on Compliance, and engaging a Qualified Security Assessor (QSA) where required by their merchant level or service provider tier.

## Shared responsibility

> LinuxGuard is a security monitoring agent and console. Compliance with any framework requires customer-side controls in addition to LinuxGuard's capabilities. This mapping is informational and not a substitute for an independent audit by a qualified assessor.

The shared-responsibility framing for PCI-DSS v4.0.1:

* **LinuxGuard responsibility.** Produce continuous audit log generation, file-integrity monitoring telemetry, configuration baselines and drift detection, eBPF-based behavioral monitoring, and identity intelligence for Linux systems in the CDE. Maintain the framework version pin and per-control evidence pointers.
* **Customer responsibility.** Define CDE scope, implement network segmentation between CDE and out-of-scope networks, administer cardholder data flows, operate application-layer authentication and authorization, manage cryptographic keys, deploy anti-malware on in-scope systems, validate quarterly vulnerability scans (ASV scans for external-facing systems), and engage a Qualified Security Assessor (QSA) where the merchant level or service provider tier requires.
* **Out-of-scope domains for this framework.** Network segmentation enforcement, key management, encryption-in-transit, anti-malware, physical access controls, information security policy administration, and the contractual and training elements of Requirement 12.

## Control mapping

The Tier column uses one of three labels and only those three: `Satisfies`, `Supports`, `Out of scope`. The Evidence column points to a row of the canonical [Evidence Location](/concepts/concepts/console/compliance-expansion.md#evidence-location) table or to a specific console page. See [Audit & Comply](/audit-and-comply/audit-comply.md) for the three-tier vocabulary contract.

| Control ID     | Description                                                                                              | Tier           | Evidence                                                                                   | Notes                                                                                                                                                                                                                                                              |
| -------------- | -------------------------------------------------------------------------------------------------------- | -------------- | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `Req 2.2`      | Configuration standards for all system components — secure configuration baseline maintenance            | `Supports`     | Console Compliance Expansion → framework → control detail; Config Drift events             | LinuxGuard surfaces drift against SSH config, SSHD config, account, group, sudo aliases, sudo defaults, and sudo rules baselines. Customer responsible for defining the baseline content itself and for hardening application-layer configuration.                 |
| `Req 6.4.3`    | Inventory of payment page scripts and configuration management — change detection                        | `Supports`     | Console Zero Trust Enforcement → Config Drift; Agent log (raw events)                      | Drift detection surfaces unauthorized changes to monitored configuration files. Customer responsible for the application-layer script inventory (payment pages) outside LinuxGuard's monitored file set.                                                           |
| `Req 7.1`      | Define and document access control policy by business need to know                                       | `Supports`     | Console Audit pillar → Authorizations audit; Console Compliance Expansion → control detail | SUDO rule baselines, authorization audit, and account/group inventory provide evidence of access posture. Customer responsible for defining the access control policy and for application-layer role enforcement.                                                  |
| `Req 7.2`      | Establish role-based access control model for system components                                          | `Supports`     | Console Audit pillar → Authorizations audit                                                | LinuxGuard observes and audits OS-level access (sudo rules, group membership, SSH access). Customer responsible for the role model definition and for application-layer authorization.                                                                             |
| `Req 8.2`      | Strong authentication — unique user identification                                                       | `Supports`     | Agent log (raw events) with `loginUID` attribute; Console Identity Intelligence            | `loginUID` capture survives sudo/su escalation for non-repudiation. Customer responsible for the IAM platform, account provisioning workflow, password policy, and MFA enforcement.                                                                                |
| `Req 8.3.1`    | All access to system components is authenticated using multi-factor authentication                       | `Supports`     | Agent log (raw events); Console Identity Intelligence                                      | LinuxGuard captures authentication events including method (password, publickey, keyboard-interactive). Customer responsible for MFA enforcement at the IdP or PAM layer.                                                                                          |
| `Req 10.2.1`   | Audit logs are enabled and active for all system components                                              | `Satisfies`    | Agent log (raw events) at `/var/log/linuxguard/agent.log`; Support bundle                  | The LinuxGuard agent generates structured audit logs continuously on every enrolled Linux host in the CDE. Log rotation defaults: 50 MB per file, 14-day retention, 5 backups, gzip compression. See [Log Management](/operate/operate/log-management.md).         |
| `Req 10.2.1.1` | Audit logs capture all individual user access to system components                                       | `Satisfies`    | Agent log (raw events) with `auth.event` attribute and `loginUID` field                    | eBPF-based authentication event capture records every login (success and failure) with user, source IP, method, and timestamp.                                                                                                                                     |
| `Req 10.2.1.2` | Audit logs capture all actions taken by any individual with administrative access                        | `Satisfies`    | Agent log (raw events); Console Audit pillar → SUDO execution audit                        | SUDO execution audit and process attribution with `loginUID` survive privilege escalation for non-repudiation.                                                                                                                                                     |
| `Req 10.2.1.4` | Audit logs capture invalid logical access attempts                                                       | `Satisfies`    | Agent log (raw events); Console Identity Intelligence → Brute Force Detection              | Authentication failure events captured at kernel level via eBPF auth probes; brute force pattern detection surfaces in the console.                                                                                                                                |
| `Req 10.2.1.7` | Audit logs capture creation and deletion of system-level objects                                         | `Supports`     | Console Zero Trust Enforcement → Config Drift; Agent log (raw events)                      | Drift detection across accounts and groups surfaces creation and deletion of system-level identity objects. Customer responsible for application-layer object lifecycle logging.                                                                                   |
| `Req 10.3.1`   | Audit logs are protected from unauthorized modification                                                  | `Supports`     | Agent log on disk with logrotate integration                                               | LinuxGuard writes to `/var/log/linuxguard/agent.log` with standard UNIX permissions; logrotate close+reopen via SIGHUP. Customer responsible for forwarding logs to write-once-read-many (WORM) storage or central log management for tamper resistance.           |
| `Req 10.4`     | Audit log review — daily review of security events                                                       | `Supports`     | Console Compliance Expansion → History; Console Audit pillar                               | Console surfaces drift events, signals, and authorization audit for daily review workflow. Customer responsible for assigning the review process and documenting reviewer sign-off.                                                                                |
| `Req 10.5.1`   | Retain audit log history for at least 12 months with the most recent 3 months immediately available      | `Supports`     | Agent log rotation; Console Compliance Expansion → History                                 | Default agent retention is 14 days locally; customers ship to central log management for the 12-month / 3-month retention requirement. See [Log Management § Central Log Collection Patterns](/operate/operate/log-management.md#central-log-collection-patterns). |
| `Req 10.7`     | Failures of critical security control systems are detected, alerted, and addressed promptly              | `Supports`     | Console Notifications; Agent probe status                                                  | Agent health, eBPF probe status, and connectivity errors are visible via the `probe` command and console. Customer responsible for the alerting routing and incident response workflow.                                                                            |
| `Req 11.5.1`   | Change-detection mechanism is deployed to alert personnel to unauthorized modification of critical files | `Satisfies`    | Agent log (raw events); Console Zero Trust Enforcement → Config Drift                      | File monitoring with eBPF tracks writes to sudoers, sshd\_config, passwd, shadow, authorized\_keys, and operator-configured paths. Drift events feed the console. See [Security Architecture](/concepts/concepts/security-architecture.md).                        |
| `Req 11.5.2`   | Change-detection mechanism alerts on modifications, additions, and deletions of critical system files    | `Satisfies`    | Agent log (raw events); Console Zero Trust Enforcement → Config Drift                      | eBPF Configuration File Write Detection and file baseline drift events surface modify, add, and delete operations on monitored paths.                                                                                                                              |
| `Req 11.6.1`   | Change- and tamper-detection mechanism for payment page header and script changes                        | `Out of scope` | n/a                                                                                        | Payment page tamper detection is an application-layer / browser-side concern not addressed by LinuxGuard.                                                                                                                                                          |
| `Req 1`        | Install and maintain network security controls                                                           | `Out of scope` | n/a                                                                                        | Network segmentation and firewall rule management are not addressed by LinuxGuard.                                                                                                                                                                                 |
| `Req 3`        | Protect stored account data                                                                              | `Out of scope` | n/a                                                                                        | Cardholder data storage protection, key management, and tokenization are not addressed by LinuxGuard.                                                                                                                                                              |
| `Req 4`        | Protect cardholder data with strong cryptography during transmission                                     | `Out of scope` | n/a                                                                                        | Encryption-in-transit for cardholder data is not addressed by LinuxGuard.                                                                                                                                                                                          |
| `Req 5`        | Protect all systems and networks from malicious software                                                 | `Out of scope` | n/a                                                                                        | Anti-malware deployment and signature management are not addressed by LinuxGuard.                                                                                                                                                                                  |
| `Req 9`        | Restrict physical access to cardholder data                                                              | `Out of scope` | n/a                                                                                        | Physical access controls are not addressed by LinuxGuard.                                                                                                                                                                                                          |
| `Req 12`       | Support information security with organizational policies and programs                                   | `Out of scope` | n/a                                                                                        | Information security policy administration, security awareness training, incident response program management, and third-party risk management are organizational responsibilities not addressed by LinuxGuard.                                                    |

> **Important**: Every Satisfies claim cites a specific agent feature and a specific evidence pointer. Every Supports claim states what the customer must implement to achieve full satisfaction. Every Out-of-scope row carries a one-line note explaining why — silence is interpreted as an implicit Satisfies claim.

## How to share with auditor

Three export paths are available, depending on the QSA's evidence preference:

* **Console Compliance Expansion reports.** Console pillar → Compliance Expansion → Reports produces dated, signed, auditor-shareable evidence packages (PDF / CSV / JSON) per [Compliance Expansion](/concepts/concepts/console/compliance-expansion.md#reports). Each report includes the framework version (PCI-DSS v4.0.1), last-verified date, per-control coverage, per-server pass / fail breakdown, suppressions in effect, and a manifest with SHA-256 verification.
* **Support bundles for host-level evidence.** `support-bundle collect` on each host in the CDE produces a tar.zst archive with agent logs, redacted configuration, and a bundle manifest — see [Support Bundles](/operate/operate/support-bundles.md). Bundles are useful when the QSA wants raw host-level telemetry rather than a console-rendered report.
* **Console CSV / JSON export per control.** Compliance Expansion → PCI-DSS v4.0.1 → control detail → Evidence tab exports per-control evidence in machine-readable form for QSAs who want to ingest evidence into their own GRC tooling.

> **Security Note**: Support bundles include the raw `agent.log` and rotated segments. Attribute-key redaction (api\_key / \*\_token / \*\_secret) is applied; PII (hostnames, IPs, usernames, paths, command args) is NOT additionally redacted. Review every evidence package before sharing externally — particularly relevant for CDE evidence where hostnames and process command-line arguments may correlate to systems handling cardholder data. See [Support Bundles](/operate/operate/support-bundles.md) for the per-file redaction status table.

## Cross-references

* [**Audit & Comply**](/audit-and-comply/audit-comply.md) — vocabulary contract, framework version pin reference, forbidden-words list, scope statement template.
* [**Compliance Expansion**](/concepts/concepts/console/compliance-expansion.md) — console pillar; canonical Evidence Location pointer set.
* [**Audit**](/concepts/concepts/console/audit.md) — authorizations and SUDO execution audit feeding compliance evidence.
* [**Support Bundles**](/operate/operate/support-bundles.md) — per-file redaction status table; pre-share PII warning.
* [**Log Management**](/operate/operate/log-management.md) — log retention and rotation relevant to the 12-month audit-period retention requirement (Req 10.5.1).
* [**Glossary**](/reference/reference/glossary.md) — framework acronyms and compliance vocabulary definitions.

***

*Last reviewed: 2026-05-31 against PCI-DSS v4.0.1 published 2024-06-01.*


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.linuxguard.io/audit-and-comply/audit-comply/pci-dss.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
