> 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.md). # Audit & Comply LinuxGuard publishes 13 per-framework compliance mapping pages. This hub defines the binding vocabulary, version pin reference, scope-statement template, shared-responsibility statement, and per-framework page template that every mapping page in the set instantiates. Compliance officers, internal auditors, GRC analysts, and security engineers use this hub as the reference for what the per-framework pages do and do not assert. > **Note**: This hub is reference material for compliance and security teams. It is not legal advice, an audit attestation, or a substitute for an independent audit performed by a qualified assessor. Customers remain responsible for their own compliance assessments. ## What this hub covers The hub is the source of truth for four contract elements that bind every per-framework page in this directory: * **Three-tier vocabulary contract** — strict definitions of *Satisfies*, *Supports*, and *Out of scope* with usage examples per tier. Every per-framework mapping table uses these three tier labels and only these three. * **Framework version pin reference** — single source-of-truth table listing the 13 frameworks documented in this set, with version, effective date, last-verified date, and notes. Per-framework pages cite this table in their front-matter and at the top of the page. * **Scope statement template** — sentence template that every per-framework page instantiates at the top of the page to declare what is in scope and what is not in scope for that framework. * **Per-framework page template** — section-by-section shape that every per-framework page follows. Maintained as `audit-comply/_template.md` for direct copy-paste. The forbidden-words list (see [Forbidden words](#forbidden-words)) is enforced by a CI grep gate against `audit-comply/*.md`. The shared-responsibility statement (see [Shared responsibility](#shared-responsibility)) is canonical text that per-framework pages reference rather than paraphrase. ## Three-tier vocabulary contract Every per-framework control-mapping table uses one of three tier labels per control: **Satisfies**, **Supports**, or **Out of scope**. No fourth tier exists. Pages must not invent new tier names ("partially satisfies", "alternative control", "compensating") — the three-tier vocabulary is intentionally strict because audit conversations turn on it. ### Tier 1 — Satisfies *Definition.* LinuxGuard, as deployed per documented configuration, materially fulfills the control requirement. The customer must still demonstrate operational evidence to an auditor — the tier indicates that the agent's behavior alone is sufficient to address what the control text asks for, not that the auditor will treat the documentation as the evidence. A "Satisfies" claim requires: * A specific agent feature, console page, or API surface that produces the behavior the control text asks for. * A specific evidence pointer the customer can retrieve and show to an auditor (see [Evidence Location](/concepts/concepts/console/compliance-expansion.md#evidence-location) for the canonical pointer set). * A specific framework requirement number with version (e.g., PCI-DSS v4.0.1 Requirement 10.2.1.1). Usage examples (illustrative — not authoritative; per-framework pages own the actual mappings): * **PCI-DSS v4.0.1 Req 10.2.1.1 (audit log generation for individual user access to system components).** Satisfies via eBPF-based authentication event capture; evidence is the agent log entry with `auth.event` attribute and `loginUID` field per [Security Architecture](/concepts/concepts/security-architecture.md). * **NIST CSF 2.0 DE.CM-01 (the network is monitored to detect potential cybersecurity events).** Satisfies via the agent's behavioral telemetry pipeline; evidence is the signal record on the [Zero Trust Enforcement](/concepts/concepts/console/zero-trust-enforcement.md) page. * **ISO/IEC 27001:2022 Annex A 8.16 (monitoring activities).** Satisfies via continuous agent telemetry on enrolled hosts; evidence is the per-server signal history. ### Tier 2 — Supports *Definition.* LinuxGuard provides telemetry, controls, or evidence that contributes to satisfying the control requirement, but full satisfaction depends on additional customer-side controls. The customer must implement those additional controls (identity management, network segmentation, physical security, policy administration, contractual measures) — LinuxGuard provides one input to the customer's control surface, not the complete control. A "Supports" claim requires: * A specific agent feature that produces partial evidence relevant to the control. * An explicit statement of what the customer must implement to achieve full satisfaction. * A specific framework requirement number with version. Usage examples (illustrative): * **PCI-DSS v4.0.1 Req 7 (restrict access to system components and cardholder data by business need to know).** Supports via SUDO rule baselines and authorization audit; full satisfaction also requires customer-administered IAM, role definition, and access review processes outside LinuxGuard. * **HIPAA 45 CFR §164.312(a)(1) (access control — unique user identification).** Supports via `loginUID` capture surviving sudo / su escalation; full satisfaction also requires the customer's IAM system, account-provisioning workflow, and identity governance program. * **SOC 2 TSC CC6.1 (logical access security software, infrastructure, and architectures).** Supports via SSH config baselines, account inventory, and configuration drift detection; full satisfaction also requires the customer's identity store, network access policy, and key management. ### Tier 3 — Out of scope *Definition.* The control concerns a domain LinuxGuard does not address. Silence is not equivalent to *Out of scope* — silence is interpreted by auditors and procurement teams as an implicit *Satisfies* claim. Every control mapping table therefore lists out-of-scope controls explicitly with a one-line note explaining why the control is out of scope for this product. An "Out of scope" claim requires: * A specific framework requirement number with version. * A one-line note stating which domain the control concerns (physical access, application-layer authentication, key management, contract management, employee training, etc.) and that the domain is not addressed by LinuxGuard. Usage examples (illustrative): * **PCI-DSS v4.0.1 Req 9 (restrict physical access to cardholder data).** Out of scope — physical access controls are not addressed by LinuxGuard. * **ISO/IEC 27001:2022 Annex A 6.3 (information security awareness, education, and training).** Out of scope — security training is a customer program responsibility not addressed by LinuxGuard. * **HIPAA 45 CFR §164.310 (physical safeguards).** Out of scope — physical safeguards (facility access, workstation security, device controls) are not addressed by LinuxGuard. ## Shared responsibility Every per-framework page includes the canonical shared-responsibility statement below verbatim. The statement frames the entire mapping set and is the basis on which auditors should read each per-framework page. > 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 statement is non-negotiable. Per-framework pages do not paraphrase the statement, abbreviate it, or merge it with framework-specific language. The same wording appears on every per-framework page so that procurement teams and auditors comparing pages see consistent framing rather than per-framework variance. The three responsibility layers implied by the statement: * **LinuxGuard responsibility.** Produce the telemetry, baselines, drift detection, audit trails, and evidence artifacts that the agent's features generate. Maintain framework version pins. Publish per-framework mappings using the three-tier vocabulary. * **Customer responsibility.** Deploy LinuxGuard per documented configuration. Operate the customer-side controls (IAM, network policy, key management, training, physical security, policy administration) that complete the control surface. Maintain evidence retention, suppression decisions, and audit-period scoping. Engage a qualified assessor for audit attestation. * **Out-of-scope domains.** Controls in framework domains LinuxGuard does not address (physical access, application-layer logic, contract management, employee training, business continuity, third-party risk, and others depending on the framework). ## Framework version pin reference This is the binding version pin reference for the 13 frameworks documented in this set. Per-framework pages cite the row corresponding to their framework in their front-matter (`version`, `effective_date`, `last_verified` keys) and in a callout at the top of the page. Bumping a framework version is a deliberate change recorded in the page's `last_verified` date and the table below. | Framework | Version | Effective Date | Last Verified | Notes | | ----------------------- | ---------------------------------------- | -------------------- | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | PCI-DSS | 4.0.1 | 2024-06-01 | 2026-05-31 | v3.2.1 retired 2024-03-31. Cite v4.x requirement numbers. | | HIPAA | 45 CFR §164 | 2013-03-26 (Omnibus) | 2026-05-31 | Cite specific CFR sections (Privacy / Security / Breach Notification Rules). | | SOC 2 | TSC 2017 (rev 2022) | 2022-12-15 | 2026-05-31 | Distinguish Type I vs Type II in reporting language. | | NIS2 | Directive (EU) 2022/2555 | 2024-10-17 | 2026-05-31 | Member-state transposition varies — note the specific transposing national law for each customer jurisdiction. | | DORA | Regulation (EU) 2022/2554 | 2025-01-17 | 2026-05-31 | Direct-effect regulation — no member-state transposition required. | | EU AI Act | Regulation (EU) 2024/1689 | 2024-08-01 | 2026-05-31 | Direct-effect regulation. Phased applicability: prohibited AI 2025-02-02, GPAI 2025-08-02, high-risk Annex III 2026-08-02, high-risk Annex I 2027-08-02. LinuxGuard supports Art 12 (record-keeping) and Art 15 (cybersecurity) at the host layer. | | GDPR | Regulation (EU) 2016/679 | 2018-05-25 | 2026-05-31 | Cite Article + paragraph. IP addresses are PII under EU case law — relevant to log shipping decisions. | | NIST CSF | 2.0 | 2024-02-26 | 2026-05-31 | CSF 1.1 still widely cited externally — note distinction when customers cross-reference. | | ISO/IEC 27001 | :2022 (Annex A: 93 controls) | 2022-10-25 | 2026-05-31 | :2013 transition deadline 2025-10-31. Annex A controls restructured from 114 to 93 across 4 themes. | | CIS Controls | v8.1 | 2024-06-01 | 2026-05-31 | v8 dropped from 20 to 18 controls vs v7.1. | | CIS Benchmarks | Latest per distro (pin per audit period) | varies | 2026-05-31 | Distro-specific Benchmarks (Ubuntu, RHEL, SUSE, Alpine) versioned independently. Pin a specific Benchmark version per audit period rather than tracking "latest". Distinct from CIS Controls. | | FedRAMP | Rev 5 (May 2023 baselines) + StateRAMP | 2023-05-30 | 2026-05-31 | Rev 4 phased out by ATO renewal cycle. StateRAMP draws on FedRAMP Rev 5 baselines with state-government scope. | | HITRUST CSF + FFIEC CAT | HITRUST CSF v11.x + FFIEC CAT 2017 | varies | 2026-05-31 | HITRUST versioned annually — pin a specific minor version per audit period. FFIEC CAT 2017 is the current Cybersecurity Assessment Tool; FFIEC IT Handbook booklets may also be cited. | The `Last Verified` column tracks the date each row's version pin was last reviewed against the canonical framework document. Per-framework pages MUST NOT carry a `last_verified` date older than the date in this table for their framework — a stale row blocks publication. The table is reviewed at every framework release cycle and at every milestone end. ## Forbidden words Compliance content uses precise, neutral, factual language. Marketing-tone words break the contract by implying coverage or completeness that the three-tier vocabulary intentionally refuses to assert. The following words are forbidden in `audit-comply/*.md`: * `comprehensive` * `complete coverage` * `industry-leading` * `industry leading` * `best-in-class` * `best in class` * `full coverage` * `achieves compliance` The CI grep gate at `scripts/check-compliance-tone.sh` and `.github/workflows/compliance-tone.yml` enforces zero matches across every Markdown file in this directory. The gate runs on every pull request and every push to `main`. Authors who introduce a forbidden word ship a failing CI run; the gate must pass before merge. Why the words are forbidden, grouped by category: * **Coverage-implying words** (`comprehensive`, `complete coverage`, `full coverage`). The three-tier vocabulary explicitly refuses "complete" framing — the only honest statement is per-control, per-tier, with evidence pointers. Coverage-implying words override the tier vocabulary and mislead auditors into reading the page as a global Satisfies claim. * **Marketing superlatives** (`industry-leading`, `best-in-class`). Comparative claims are unverifiable in a compliance context and damage the page's standing as audit-ready reference material. Procurement teams and auditors discount documents that read as sales collateral. * **Compliance-as-outcome wording** (`achieves compliance`). LinuxGuard, like any product, cannot "achieve compliance" — only a customer can be compliant, and only an auditor can attest to compliance. Wording that suggests otherwise misrepresents the product-customer-auditor relationship. Authors who feel a forbidden word is the right fit for a passage are encouraged to rewrite the passage around the three-tier vocabulary instead. The vocabulary itself carries the precision that the marketing word was reaching for. The HTML-comment markers `` and `` above are recognized by the grep gate as allowlist regions — content between the markers is exempt from the check. Markers exist exclusively so this hub and the per-framework template can NAME the forbidden words to declare the policy. Per-framework pages do not use the markers; using the markers in per-framework content is itself a policy violation reviewed by the human reviewer at PR time. ## Per-framework page template Every per-framework mapping page in `audit-comply/` instantiates the template at [`audit-comply/_template.md`](https://github.com/linuxguardx/linuxguard-documentation/blob/main/audit-comply/_template.md). The template is the authoritative shape — the structure below restates the template for reference. ### Section sequence 1. **YAML front-matter.** Description (one sentence ≤160 chars), keywords (5-10 entries), `framework` (canonical name), `version`, `effective_date`, `last_verified`. The version pin matches the row in the [Framework version pin reference](#framework-version-pin-reference) above. 2. **H1 title.** Framework name + version (e.g., `# PCI-DSS v4.0.1 Control Mapping`). 3. **Framework version callout.** A `> **Note**:` blockquote restating the framework version, effective date, last-verified date, and link to the canonical framework document. Reader sees the version pin without scrolling. 4. **Scope statement.** One paragraph at the top declaring what this mapping is scoped to address and what is out of scope. Uses the [Scope statement template](#scope-statement-template) below. 5. **Shared responsibility.** The canonical shared-responsibility statement from this hub, verbatim. No paraphrase. 6. **Control mapping table.** Columns: Control ID, Description (or short citation), Tier (`Satisfies` / `Supports` / `Out of scope`), Evidence, Notes. One row per control or per control group. The Tier column uses one of the three tier labels and only those three. The Evidence column points to a row in the canonical [Evidence Location](/concepts/concepts/console/compliance-expansion.md#evidence-location) table or to a specific console page; per-framework pages do not duplicate the evidence pointer set. 7. **How to share with auditor.** A short section describing the export path (PDF report from the Compliance Expansion console, support-bundle for host-level evidence, console CSV export) and the pre-share PII warning. References the [Support Bundles](/operate/operate/support-bundles.md) per-file redaction status table. 8. **Last reviewed.** Trailing line: `_Last reviewed: YYYY-MM-DD against [framework version] published [effective date]._` The template at [`audit-comply/_template.md`](https://github.com/linuxguardx/linuxguard-documentation/blob/main/audit-comply/_template.md) is the copy-paste source. Per-framework page authors copy the template, replace placeholders, and never delete a section. A page missing a section is incomplete by this contract. ## Scope statement template Every per-framework page declares scope with one paragraph at the top. The paragraph instantiates this template: > This page maps LinuxGuard's agent and console capabilities against \[FRAMEWORK NAME and VERSION]. The mapping is scoped to controls in \[FRAMEWORK DOMAIN — e.g., logging, access control, configuration management, network monitoring] that LinuxGuard's telemetry, baseline, drift detection, and audit features address. Controls in \[OUT-OF-SCOPE DOMAINS — e.g., physical safeguards, application-layer authentication, contractual measures, employee training] 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. The template is instantiated, not paraphrased. The specific in-scope and out-of-scope domain lists vary per framework but the sentence shape stays constant so procurement and audit reviewers can compare pages mechanically. ## When-to-use guide The 13 framework pages split into three categories. Customers use the categories to decide which mapping pages apply to their deployment scenario. ### Regulated frameworks (industry-specific compliance) | Framework | When it applies | | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | PCI-DSS v4.0.1 | Customers processing, storing, or transmitting payment card data. Applies to any system component in the cardholder data environment (CDE) scope. | | HIPAA 45 CFR §164 | Covered entities and business associates handling protected health information (PHI) in the United States. | | SOC 2 (TSC 2017 rev 2022) | Service organizations producing SOC 2 attestation reports for customers. Common scope: Security TSC; expanded scope adds Availability, Confidentiality, Processing Integrity, Privacy. | | GDPR (EU 2016/679) | Controllers and processors handling personal data of EU residents. Relevant to log shipping decisions because IP addresses are PII under EU case law. | ### Emerging-region and government frameworks | Framework | When it applies | | ------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | NIS2 (Directive (EU) 2022/2555) | Essential and important entities operating in the EU, transposed via national law per member state. Applies to a broader entity scope than the original NIS Directive. | | DORA (Regulation (EU) 2022/2554) | EU financial entities (banks, insurance, investment, crypto-asset service providers) and their critical third-party ICT providers. Direct-effect regulation — no member-state transposition. | | EU AI Act (Regulation (EU) 2024/1689) | Customers placing on the EU market or putting into service high-risk AI systems (Annex III) or AI systems embedded in regulated products (Annex I); also deployers operating high-risk AI systems within the EU. LinuxGuard's mapping is scoped to the host-layer logging (Art 12) and cybersecurity (Art 15) requirements. | | FedRAMP Rev 5 + StateRAMP | U.S. federal cloud service providers (FedRAMP) and state-government cloud providers (StateRAMP). StateRAMP draws on FedRAMP Rev 5 baselines with state-government scope. | | HITRUST CSF + FFIEC CAT | Healthcare organizations adopting HITRUST CSF as a unified control framework; U.S. financial institutions using the FFIEC Cybersecurity Assessment Tool. | ### Technical and standards frameworks | Framework | When it applies | | ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | NIST CSF 2.0 | Voluntary risk-management framework applicable to any organization. Commonly used as a parent framework that customers map their other compliance work back to. | | ISO/IEC 27001:2022 | Organizations seeking ISO/IEC 27001 certification. Annex A controls restructured from 114 (2013) to 93 (2022) across 4 themes. | | CIS Controls v8.1 | Prescriptive control set (18 controls in v8 vs 20 in v7) suitable for organizations adopting a defense-in-depth posture. Distinct from CIS Benchmarks. | | CIS Benchmarks (Linux) | Distro-specific hardening guides (Ubuntu, RHEL, SUSE, Alpine — and others) versioned independently. Used as a configuration baseline reference. Distinct from CIS Controls. | The 13 framework pages share the same vocabulary contract, the same template, and the same evidence pointer surface. Customers commonly apply two or three of these pages in parallel — e.g., a U.S. healthcare SaaS provider runs HIPAA + SOC 2 + HITRUST + (depending on customer base) PCI-DSS. The vocabulary contract makes parallel adoption cleaner because the tier labels are constant across frameworks. ## Glossary references Framework acronyms and compliance-specific terms are defined in [`reference/glossary.md`](/reference/reference/glossary.md). Per-framework pages link to the glossary for first-mention definitions of: * **Framework acronyms.** PCI-DSS, HIPAA, SOC 2, NIS2, DORA, GDPR, EU AI Act, NIST CSF, ISO/IEC 27001, CIS Controls, CIS Benchmarks, FedRAMP, StateRAMP, HITRUST CSF, FFIEC CAT. * **Vocabulary tiers.** Satisfies (compliance vocabulary tier), Supports (compliance vocabulary tier), Out of scope (compliance vocabulary tier). * **Compliance-specific terms.** Control mapping, scope statement, shared responsibility, evidence location, framework version pin. A glossary entry exists for every term used in this hub and in the per-framework pages. New terms introduced by a per-framework page are added to the glossary in the same change. ## Cross-references * [**Compliance Expansion**](/concepts/concepts/console/compliance-expansion.md) — console pillar surfacing the frameworks browser, evidence collection, compliance history, reports, and suppressions. The canonical [Evidence Location](/concepts/concepts/console/compliance-expansion.md#evidence-location) table lives there; per-framework pages link to that table rather than restating it. * [**Audit**](/concepts/concepts/console/audit.md) — console pillar covering authorizations audit and SUDO execution audit, which feed compliance evidence. * [**Support Bundles**](/operate/operate/support-bundles.md) — per-file redaction status table and pre-share PII warning. Per-framework "How to share with auditor" sections reference this page. * [**Log Management**](/operate/operate/log-management.md) — log retention, rotation, and redaction scope. Relevant to audit-period log evidence retention. *** **Related**: [Compliance Expansion](/concepts/concepts/console/compliance-expansion.md) | [Audit](/concepts/concepts/console/audit.md) | [Support Bundles](/operate/operate/support-bundles.md) | [Log Management](/operate/operate/log-management.md) | [Glossary](/reference/reference/glossary.md)