> 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/hitrust-ffiec.md). # HITRUST + FFIEC > **Note**: This page maps LinuxGuard against **HITRUST CSF v11.x** (versioned annually — pin a specific minor version per audit period) and the **FFIEC Cybersecurity Assessment Tool (CAT) 2017** (still the current CAT publication as of last verification). Last verified against the frameworks on 2026-05-31. Canonical framework documents: [HITRUST Alliance — CSF](https://hitrustalliance.net/hitrust-csf), [FFIEC — Cybersecurity Assessment Tool](https://www.ffiec.gov/cyberassessmenttool.htm). For the vocabulary contract used here, see [Audit & Comply](/audit-and-comply/audit-comply.md). > **Important**: This page covers two frameworks on one mapping page intentionally. **Dual-framework rationale**: HITRUST CSF is the healthcare-sector integrated control framework deriving from HIPAA Security Rule, NIST SP 800-53, ISO/IEC 27001, PCI-DSS, COBIT, and additional source authorities. FFIEC CAT is the U.S. banking-sector self-assessment tool aligned with NIST CSF and the FFIEC Information Technology Examination Handbook booklets. Both frameworks derive from the same underlying control catalogs that LinuxGuard's per-framework pages already map (NIST CSF, ISO/IEC 27001, NIST SP 800-53). Customers in healthcare commonly adopt HITRUST as their unified control framework; customers in U.S. banking commonly adopt FFIEC CAT for the supervisory examination workflow. The two customer populations have known overlap (banks providing healthcare services, healthcare entities providing financial services), and the LinuxGuard evidence surface is the same for both. The dual-framework page reflects the shared evidence surface while preserving framework-specific control IDs. > **Important**: HITRUST CSF is **versioned annually** (v11.0 in 2023, v11.1 in 2024, v11.2 in 2024, with subsequent minor versions following). Customers pin a specific minor version per audit period and engage a HITRUST Authorized External Assessor (CSF Assessor Organization) for HITRUST e1, i1, or r2 assessments. FFIEC CAT 2017 has not been formally retired as of last verification; the FFIEC has signaled future replacement with a NIST CSF 2.0-aligned tool. Customers tracking FFIEC guidance updates should monitor the FFIEC examination procedures and the IT Examination Handbook booklets in parallel with this mapping. ## Scope This page maps LinuxGuard's agent and console capabilities against HITRUST CSF v11.x and FFIEC CAT 2017. The HITRUST mapping is scoped to control categories 01 (Information Protection Program — relevant sub-domains only), 06 (Configuration Management), 09 (Communications and Operations Management — audit and monitoring sub-domains), 10 (Information Systems Acquisition, Development, and Maintenance — security-relevant sub-domains), 11 (Information Security Incident Management), and 13 (Privacy Practices — minimal coverage) on Linux systems within the customer's HITRUST scope. The FFIEC CAT mapping is scoped to Domain 3 (Cybersecurity Controls — Preventive Controls, Detective Controls, Corrective Controls) and Domain 5 (Cyber Incident Management and Resilience — Incident Resilience Planning and Strategy, Detection, Response, and Mitigation, Escalation and Reporting). Controls in HITRUST categories 02 (Endpoint Protection — anti-malware emphasis), 03 (Portable Media Security), 04 (Mobile Device Security), 05 (Wireless Security), 07 (Vulnerability Management) — limited coverage, 08 (Network Protection), 12 (Business Continuity), 14 (Third Party Assurance) — partial coverage; and FFIEC CAT Domain 1 (Cyber Risk Management and Oversight), Domain 2 (Threat Intelligence and Collaboration), and Domain 4 (External Dependency Management) are out of scope for this product and are listed in the mapping table as `Out of scope` or `Supports` rather than omitted. This mapping is informational and not a substitute for a HITRUST Authorized External Assessor's review or an FFIEC examination. Customers remain responsible for engaging a HITRUST Authorized External Assessor for the customer's chosen HITRUST assessment level (e1, i1, or r2); maintaining the HITRUST corrective action plan (CAP) and the assessment-period scope definition; conducting the FFIEC inherent-risk-profile assessment; selecting the appropriate cybersecurity maturity level (baseline, evolving, intermediate, advanced, innovative) for each assessment factor; preparing for FFIEC examination cycles per the customer's prudential supervisor's examination schedule; and integrating both frameworks with the customer's broader compliance programme. ## 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 HITRUST CSF v11.x + FFIEC CAT 2017: * **LinuxGuard responsibility.** Produce telemetry, baselines, drift detection, audit trails, and evidence artifacts on Linux systems in the customer's HITRUST or FFIEC scope supporting the access control, audit, configuration management, monitoring, and incident response domains across both frameworks. Maintain the framework version pin (with explicit notation that the HITRUST minor version requires per-audit-period pinning) and per-control evidence pointers. * **Customer responsibility.** For HITRUST: engage a HITRUST Authorized External Assessor, select the assessment level (e1, i1, r2), define the assessment-period scope and the systems within scope, maintain the corrective action plan, administer the Privacy Practices controls outside the OS-layer telemetry domain, and integrate HITRUST with the customer's HIPAA programme where applicable. For FFIEC: complete the FFIEC inherent-risk-profile assessment, select the appropriate maturity level per assessment factor, prepare for the prudential supervisor's examination cycle, integrate FFIEC CAT with the FFIEC Information Technology Examination Handbook booklets the supervisor references, administer the broader cyber risk management and oversight programme (Domain 1) and threat intelligence programme (Domain 2), and operate the external dependency management programme (Domain 4). * **Out-of-scope domains for this framework.** HITRUST assessment-process administration, HITRUST Privacy Practices, HITRUST Business Continuity, HITRUST Third Party Assurance programme administration; FFIEC Domain 1 (Cyber Risk Management and Oversight), FFIEC Domain 2 (Threat Intelligence and Collaboration), FFIEC Domain 4 (External Dependency Management), and FFIEC examination-process administration. ## 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. ### HITRUST CSF v11.x — selected control objectives | Control ID | Description | Tier | Evidence | Notes | | ---------- | -------------------------------------------------------------------------------------------------------------------------- | -------------- | --------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `01.b` | User Registration — formal user registration and de-registration procedure | `Supports` | Console Audit pillar → Authorizations audit; Config Drift on accounts baseline | LinuxGuard surfaces account inventory and drift supporting user-registration evidence. Customer responsible for the registration workflow, identity proofing, and the broader IAM programme. | | `01.c` | Privilege Management — restrict and control the allocation and use of privileges | `Supports` | Console Audit pillar → SUDO execution audit; Config Drift on sudo rules and sudo defaults baselines | SUDO rule baselines, sudo defaults baseline, and SUDO execution audit support privilege-management evidence. Customer responsible for the privilege-allocation decisions and the broader least-privilege policy. | | `01.j` | User Authentication for External Connections — authentication for external network connections | `Supports` | Agent log (raw events); Console Identity Intelligence | LinuxGuard captures authentication events from external sources including SSH-from-internet patterns. Customer responsible for the external-connection authentication enforcement (PAM, IdP, VPN) and policy. | | `01.q` | User Identification and Authentication — unique identifier for each user with authentication mechanism appropriate to risk | `Supports` | Agent log (raw events) with `loginUID` attribute; Console Identity Intelligence | `loginUID` capture surviving sudo/su escalation provides unique-identifier evidence at the OS layer. Customer responsible for the IAM platform, authentication mechanism selection, and risk-based authentication policy. | | `06.h` | Technical Compliance Checking — periodically check information systems against published security implementation standards | `Supports` | Console Compliance Expansion → control detail; Config Drift events on baselines | LinuxGuard surfaces drift against configuration baselines supporting technical compliance checking. Customer responsible for defining the implementation standards content and the checking cadence. | | `09.aa` | Audit Logging — produce audit logs recording user activities, exceptions, and information security events | `Satisfies` | Agent log (raw events) at `/var/log/linuxguard/agent.log`; Support bundle | LinuxGuard generates structured audit logs continuously on every enrolled Linux host. See [Log Management](/operate/operate/log-management.md). | | `09.ab` | Monitoring System Use — establish procedures for monitoring use of information processing facilities | `Satisfies` | Agent log (raw events); Console Zero Trust Enforcement → Signals; Console Zero Trust Enforcement → Config Drift | eBPF-based behavioral telemetry, authentication event capture, drift detection, and signal classification provide continuous monitoring at the OS layer. | | `09.ad` | Administrator and Operator Logs — log system administrator and system operator activities | `Satisfies` | Agent log (raw events); Console Audit pillar → SUDO execution audit | SUDO execution audit and `loginUID` capture surviving privilege escalation provide administrator-activity logging for non-repudiation. | | `09.ae` | Fault Logging — log faults reported by users or system programs | `Supports` | Agent log (raw events); `linuxguard-agent probe` command | Agent log captures errors, warnings, and probe failures from the agent's own operation. Customer responsible for the broader fault-logging programme across the system stack. | | `09.af` | Clock Synchronisation — synchronise clocks of relevant information processing systems | `Out of scope` | n/a | Clock synchronisation (NTP / chrony configuration) is outside the OS-layer telemetry domain. LinuxGuard logs timestamps using the system clock; customer is responsible for NTP configuration. | | `10.k` | Change Control Procedures — formal change control procedures for changes to information processing facilities | `Supports` | Console Zero Trust Enforcement → Config Drift; Agent log (raw events) | Drift detection surfaces configuration changes. Customer responsible for the change control board, change authorization workflow, and change documentation. | | `11.a` | Reporting Information Security Events — formal reporting and escalation procedures | `Supports` | Console Notifications; Console Zero Trust Enforcement → Signals; Support bundle | LinuxGuard surfaces signals and supports the reporting workflow. Customer responsible for the reporting procedure, escalation matrix, and assignment. | | `11.b` | Reporting Security Weaknesses — formal reporting of observed or suspected security weaknesses | `Supports` | Console Zero Trust Enforcement → Signals; Agent log (raw events) | Signal records surface observed weaknesses (e.g., authentication anomalies). Customer responsible for the weakness reporting workflow. | | `11.c` | Responsibilities and Procedures — establish management responsibilities and procedures for incident management | `Out of scope` | n/a | Incident management responsibilities and procedures are organisational responsibilities not addressed by LinuxGuard. | | `13.x` | Privacy Practices category | `Out of scope` | n/a | HITRUST Privacy Practices controls (covering PHI handling, consent management, breach notification under HIPAA, GDPR-related provisions) are administered by the customer's privacy programme, not addressed by LinuxGuard. | | `14.x` | Third Party Assurance category | `Supports` | Audit & Comply per-framework pages; Console Compliance Expansion → Reports | LinuxGuard provides supplier-side documentation: framework version pins, per-framework mapping pages. Customer responsible for the third-party assurance programme covering all suppliers. | ### FFIEC CAT 2017 — Domain 3 (Cybersecurity Controls) | Assessment Factor | Description | Tier | Evidence | Notes | | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | -------------- | ------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `Preventive Controls` — Infrastructure Management — Network Security | Network security controls including firewalls, IDS/IPS, network segmentation | `Out of scope` | n/a | Network security controls are outside the OS-layer telemetry domain. | | `Preventive Controls` — Access and Data Management — Access Controls | Access control mechanisms including authentication and authorization | `Supports` | Console Audit pillar → Authorizations audit; Agent log (raw events) with `loginUID` attribute | LinuxGuard observes and audits OS-level access controls (SUDO rules, group membership, SSH access, authentication events). Customer responsible for the access-control policy and the IAM programme. | | `Preventive Controls` — Device/End-Point Security — Endpoint Protection | Endpoint protection including anti-malware, host-based intrusion prevention, file integrity monitoring | `Supports` | Agent log (raw events); Console Zero Trust Enforcement → Signals; Console Zero Trust Enforcement → Config Drift | LinuxGuard provides behavioural endpoint protection telemetry, file integrity monitoring, and signal-based detection at the OS layer. Customer responsible for the signature-based anti-malware deployment where required by the maturity level. | | `Preventive Controls` — Secure Coding | Secure software development lifecycle practices | `Out of scope` | n/a | Secure coding is an application-development responsibility outside the OS-layer telemetry domain. | | `Detective Controls` — Threat and Vulnerability Detection — Anomalous Activity Detection | Anomalous activity detection at network, endpoint, and user levels | `Satisfies` | Agent log (raw events); Console Zero Trust Enforcement → Signals | eBPF-based behavioural telemetry detects anomalous activity at the OS layer (authentication anomalies, file integrity events, privilege escalation patterns). | | `Detective Controls` — Event Detection — Logging | Audit logging of security-relevant events with sufficient detail | `Satisfies` | Agent log (raw events) at `/var/log/linuxguard/agent.log`; Support bundle | LinuxGuard generates structured audit logs continuously on every enrolled host with `loginUID`, source, method, and timestamp on each event. | | `Detective Controls` — Event Detection — Monitoring | Continuous security monitoring with established baselines and deviation detection | `Satisfies` | Console Zero Trust Enforcement → Signals; Console Zero Trust Enforcement → Config Drift; Console Compliance Expansion → History | Configuration baselines (SSH, SSHD, accounts, groups, sudo aliases, sudo defaults, sudo rules), drift detection, and signal classification provide continuous monitoring with baseline-deviation detection at the OS layer. | | `Corrective Controls` — Patch Management | Patch management programme including identification, testing, deployment | `Out of scope` | n/a | Patch management programme administration is outside the OS-layer telemetry domain. Customer's patch management solution feeds the programme. | | `Corrective Controls` — Remediation | Remediation of identified vulnerabilities and incidents | `Supports` | Console Compliance Expansion → control detail; Console Notifications | Console surfaces per-control pass/fail status feeding the remediation workflow. Customer responsible for the remediation process, accountability assignment, and timely action. | ### FFIEC CAT 2017 — Domain 5 (Cyber Incident Management and Resilience) | Assessment Factor | Description | Tier | Evidence | Notes | | --------------------------------------------------------------- | ------------------------------------------------------------------------- | -------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Incident Resilience Planning and Strategy` — Planning | Documented incident response plan and resilience strategy | `Out of scope` | n/a | Incident response plan documentation and resilience strategy administration are organisational responsibilities not addressed by LinuxGuard. | | `Detection, Response, and Mitigation` — Detection | Detection mechanisms to identify cyber incidents | `Satisfies` | Agent log (raw events); Console Zero Trust Enforcement → Signals; Console Zero Trust Enforcement → Config Drift | eBPF-based behavioural telemetry, authentication event capture, file integrity monitoring, drift detection, and signal classification provide continuous incident-detection capability at the OS layer. | | `Detection, Response, and Mitigation` — Response and Mitigation | Response and mitigation processes for cyber incidents | `Supports` | Agent log (raw events); Console Zero Trust Enforcement → Signals; Support bundle | LinuxGuard provides the technical detection and forensic-evidence surface supporting the response and mitigation workflow. Customer responsible for the response process, role assignments, and mitigation execution. | | `Escalation and Reporting` — Escalation | Internal escalation procedures for cyber incidents | `Supports` | Console Notifications | Console notification routing supports escalation. Customer responsible for the escalation matrix and the broader procedure. | | `Escalation and Reporting` — Reporting | External reporting to regulators, law enforcement, and other stakeholders | `Supports` | Agent log (raw events) with timestamps; Console Zero Trust Enforcement → Signals; Support bundle; Console Compliance Expansion → History | Agent log timestamps and signal records provide the technical timeline supporting external reports. Customer responsible for the regulator notification workflow (prudential supervisor, FinCEN where applicable), law enforcement engagement, and stakeholder communication. | > **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. ## Dual-framework rationale Healthcare and financial-services organisations frequently overlap in scope, vendor selection, and audit obligations. The dual-framework page reflects the operational reality that the same LinuxGuard deployment commonly satisfies both customer populations' assessment requirements, and the evidence surface (agent logs, signals, drift events, SUDO execution audit, support bundles) is identical between the two. The decision to combine HITRUST and FFIEC on one page is driven by: * **Shared underlying control catalogs.** HITRUST CSF integrates HIPAA Security Rule, NIST SP 800-53, ISO/IEC 27001, PCI-DSS, and COBIT. FFIEC CAT aligns with NIST CSF and the FFIEC IT Examination Handbook booklets, which themselves derive from NIST SP 800-53 and related publications. The control text in both frameworks ultimately traces back to the same underlying catalogs that LinuxGuard's per-framework pages already address. * **Overlapping customer populations.** Banks providing health savings accounts (HSAs), pharmacy benefit managers (PBMs), or healthcare-financing services face both HITRUST and FFIEC obligations. Healthcare organisations operating revenue-cycle services that fall under bank-secrecy-act-style reporting face FFIEC adjacent obligations. The combined page reduces page proliferation for customers who would otherwise reference both frameworks in parallel. * **Identical evidence surface.** Agent log, signals, drift events, SUDO execution audit, and support bundles are the same artifacts whether the customer is preparing for a HITRUST r2 assessment or an FFIEC examination. The mapping table preserves framework-specific control IDs while sharing the evidence pointer set. The dual-framework approach is deliberate. Customers seeking only HITRUST coverage (without FFIEC) use the HITRUST section of the mapping table; customers seeking only FFIEC coverage (without HITRUST) use the FFIEC Domain 3 and Domain 5 sections. Customers in scope of both reference the combined surface. ## HITRUST assessment level considerations HITRUST offers three assessment levels with increasing rigor. The customer's choice depends on the audience for the assessment report (internal stakeholders, business partners, regulators) and the customer's risk tolerance. LinuxGuard's evidence surface is the same across the levels; the difference is the assessor's evaluation depth. * **e1 (Entry-Level)** — 1-year validity, 44 controls, foundational cybersecurity hygiene assessment. Suitable for organisations beginning their HITRUST journey. * **i1 (Implemented)** — 1-year validity, 182 controls, broader cybersecurity assessment with maturity assessment. * **r2 (Risk-Based)** — 2-year validity (annual interim assessment), control selection driven by the organisation's risk factors, with full maturity scoring (Policy, Procedure, Implemented, Measured, Managed). The most rigorous HITRUST assessment, suitable for organisations seeking HITRUST CSF Certified status. The mapping above covers controls present across all three levels for the categories LinuxGuard addresses. Customers pursuing r2 certification produce additional evidence at each maturity tier; LinuxGuard's continuous telemetry supports the Implemented, Measured, and Managed tiers for the OS-layer controls in scope. ## FFIEC maturity level considerations FFIEC CAT defines five cybersecurity maturity levels per assessment factor: Baseline, Evolving, Intermediate, Advanced, Innovative. The customer's selection per assessment factor reflects the institution's cybersecurity programme maturity relative to the inherent risk profile. The mapping above applies across maturity levels with the following notes: * **Baseline maturity** for the assessment factors covered above is typically achievable with LinuxGuard's `Satisfies` claims plus the customer-implemented controls noted in `Supports` claims. * **Intermediate and Advanced maturity** require additional declarative statements (documented procedures, formal training, metrics) beyond the OS-layer telemetry. LinuxGuard's telemetry supports the technical-implementation aspect; the customer adds the procedural and metrics aspects. * **Innovative maturity** requires demonstrated practices beyond standard cybersecurity programme expectations. LinuxGuard's behavioural telemetry, drift detection, and continuous monitoring contribute to the Innovative-maturity narrative for the assessment factors in scope. The mapping above does not declare maturity levels — the customer's self-assessment determines maturity per factor. ### FFIEC CAT to NIST CSF mapping FFIEC published a CAT-to-NIST-CSF mapping in 2017 supporting institutions wishing to use either framework. The mapping identifies the NIST CSF Subcategories that each FFIEC CAT declarative statement aligns with. The FFIEC has signaled future replacement of CAT with a NIST CSF 2.0-aligned tool; the mapping work to date supports the transition path. For LinuxGuard customers, the practical implication is that the evidence supporting the FFIEC Domain 3 and Domain 5 mappings on this page also feeds the NIST CSF 2.0 mapping (Phase 25). Customers in scope of both frameworks produce evidence once and present it under the framework-specific narrative the audience expects. ## HITRUST scoring considerations HITRUST r2 assessments evaluate each control against five maturity tiers, each scored on a scale of 0 to 5: Policy (documented policy approving the control), Procedure (documented procedure operationalising the policy), Implemented (control implementation in place), Measured (metrics on control effectiveness), and Managed (continuous improvement based on metrics). The final control score is a weighted aggregate of the five tiers. LinuxGuard's continuous telemetry supports the Implemented, Measured, and Managed tiers for the OS-layer controls in scope: * **Implemented tier evidence.** Agent log, signals, drift events, and SUDO execution audit demonstrate the control is in place and operating on enrolled hosts. * **Measured tier evidence.** Console Compliance Expansion → History provides per-control posture trends supporting metrics on control effectiveness. Per-server pass / fail breakdowns over the assessment period feed the metrics narrative. * **Managed tier evidence.** Suppressions and remediation history (drift event resolution, signal triage outcomes) support the continuous-improvement narrative. The annotation events in Compliance Expansion → History distinguish posture changes driven by remediation from changes driven by definitional updates. The Policy and Procedure tiers are administered by the customer's compliance function outside LinuxGuard. The assessor evaluates the customer's documented policy and procedure alongside the implementation evidence LinuxGuard provides. ### FFIEC examination cycle considerations FFIEC-regulated institutions are examined by their prudential supervisor (OCC, FDIC, NCUA, Federal Reserve, or state banking regulator) on a cycle defined by the institution's risk profile and examination history. The cycle is typically annual for larger institutions, with risk-based extensions or accelerations. LinuxGuard's evidence surface supports the examination cycle: * **Examination preparation.** Console Compliance Expansion → Reports produces a dated evidence package at the start of the examination preparation period. The report serves as the per-server posture snapshot the examiner receives. * **In-examination evidence requests.** Console CSV / JSON export per control supports examiner requests for specific control evidence (e.g., authentication event evidence for the prior quarter, drift event evidence for the configuration baseline). * **Post-examination remediation tracking.** Where the examination produces findings affecting the controls in this page's mapping, Console Compliance Expansion → History tracks the remediation progress over time. Suppressions document any findings the institution intentionally accepts under risk-based criteria. The examination cycle is administered by the prudential supervisor — not by LinuxGuard. The customer's compliance function manages examination scheduling, scope, and response. ## Cross-framework considerations Customers in scope of HITRUST CSF or FFIEC CAT are commonly also in scope of one or more of: * **HIPAA 45 CFR §164** — for HITRUST customers handling PHI; the HITRUST CSF integrates HIPAA Security Rule requirements as one of its source authorities. See [HIPAA](/audit-and-comply/audit-comply/hipaa.md) for the HIPAA-specific mapping. * **PCI-DSS v4.0.1** — for HITRUST or FFIEC customers in the cardholder data environment scope. See [PCI-DSS](/audit-and-comply/audit-comply/pci-dss.md). * **SOC 2** — for HITRUST or FFIEC customers acting as service organisations producing SOC 2 reports. See [SOC 2](/audit-and-comply/audit-comply/soc2.md). * **NIST CSF 2.0** — for FFIEC customers tracking the FFIEC's signaled future alignment with CSF 2.0. The NIST CSF 2.0 mapping (Phase 25) is the canonical NIST CSF page; FFIEC CAT alignment with CSF carries through to that page. * **FedRAMP / StateRAMP** — for healthcare or financial-services customers also serving federal or state-government consumers. See [FedRAMP / StateRAMP](/audit-and-comply/audit-comply/fedramp-stateramp.md). * **GLBA Safeguards Rule** — for FFIEC customers in scope of the Gramm-Leach-Bliley Act Safeguards Rule. LinuxGuard does not currently publish a dedicated GLBA mapping page; FFIEC CAT alignment carries most of the same control surface. Operational alignment patterns customers commonly adopt: * **Unified evidence package.** Maintain one evidence package satisfying HITRUST, FFIEC, HIPAA, and SOC 2 for the OS-layer controls covered above. The three-tier vocabulary consistency across LinuxGuard's per-framework pages supports the unified packaging. * **Framework-specific narrative layering.** Use one evidence base and layer framework-specific narrative documents per audience (HITRUST Assessor for healthcare, FFIEC examiner for banking supervision, HIPAA OCR for breach response, SOC 2 auditor for service-organisation attestation). * **Suppression-tracking consolidation.** Use the Console Compliance Expansion → Suppressions surface to track intentional out-of-scope decisions across all applicable frameworks. Each suppression carries its framework + control reference, scope, reason, approver, effective date, and expiration date as first-class evidence. LinuxGuard's per-framework mapping pages share the same vocabulary contract and template. Customers operating against multiple framework pages in parallel benefit from the vocabulary consistency. ## How to share with auditor Three export paths are available, depending on the HITRUST Authorized External Assessor's, FFIEC examiner's, or audit firm'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 (HITRUST CSF v11.x and FFIEC CAT 2017), 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 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 assessor wants raw host-level telemetry rather than a console-rendered report, particularly for HITRUST r2 Measured / Managed maturity evidence or FFIEC Detection / Response factor evidence. * **Console CSV / JSON export per control.** Compliance Expansion → HITRUST or FFIEC → control detail → Evidence tab exports per-control evidence in machine-readable form for the assessor's 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 healthcare-sector deployments where hostnames and process command-line arguments may correlate to systems processing PHI, and for banking-sector deployments where similar correlations may apply to systems processing customer financial data. See [Support Bundles](/operate/operate/support-bundles.md) for the per-file redaction status table and [HIPAA](/audit-and-comply/audit-comply/hipaa.md) for the HIPAA cross-reference for healthcare customers. ## 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 audit-period evidence retention. * [**HIPAA**](/audit-and-comply/audit-comply/hipaa.md) — HIPAA Security Rule technical safeguards relevant to healthcare-sector HITRUST customers. * [**SOC 2**](/audit-and-comply/audit-comply/soc2.md) — TSC alignment relevant to healthcare and financial-services service organisations producing SOC 2 reports alongside HITRUST or FFIEC engagement. * [**FedRAMP / StateRAMP**](/audit-and-comply/audit-comply/fedramp-stateramp.md) — NIST SP 800-53 Rev 5 alignment relevant where the customer maps HITRUST or FFIEC findings to federal or state-government overlays. * [**Glossary**](/reference/reference/glossary.md) — framework acronyms and compliance vocabulary definitions. *** *Last reviewed: 2026-05-31 against HITRUST CSF v11.x (versioned annually — pin a specific minor version per audit period) and FFIEC CAT 2017 (current CAT publication as of last verification).* --- # 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/hitrust-ffiec.md?ask=&goal= ``` `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.