# 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) --- # Agent Instructions: 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: ``` GET https://docs.linuxguard.io/audit-and-comply/audit-comply.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.