> 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/fedramp-stateramp.md).

# FedRAMP / StateRAMP

> **Note**: This page maps LinuxGuard against **FedRAMP Rev 5 baselines** (released 2023-05-30) and **StateRAMP**, both of which derive from **NIST Special Publication 800-53 Revision 5**. Last verified against the framework on 2026-05-31. Canonical framework documents: [FedRAMP — Rev 5 Baselines](https://www.fedramp.gov/rev5/), [NIST SP 800-53 Rev 5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final), [StateRAMP](https://stateramp.org/). For the vocabulary contract used here, see [Audit & Comply](/audit-and-comply/audit-comply.md).

> **Important**: **LinuxGuard is a component, not a full system.** Customers seeking FedRAMP authorization integrate LinuxGuard into their authorization boundary as one of many system components. The authorization boundary — defined per NIST SP 800-37 Rev 2 and FedRAMP guidance — encompasses the complete information system being authorized, including all interconnections, supporting infrastructure, and inherited controls. LinuxGuard's per-control coverage applies to the agent and console functions within that boundary; the Cloud Service Provider (CSP) remains responsible for the complete System Security Plan (SSP), the authorization-boundary diagram, the data flow diagram, and the inherited-vs-customer-implemented control allocations across the full boundary.

> **Important**: StateRAMP draws on FedRAMP Rev 5 baselines with state-government scope adjustments. Where this page references FedRAMP control allocations, StateRAMP customers apply the equivalent allocation under StateRAMP's adopted baseline (Low, Moderate, or High Impact) with state-specific overlays where applicable. The control IDs and content map one-to-one for the families covered; differences arise in the authorization process (3PAO assessment, PMO review, authorization body), not in the control text.

## Scope

This page maps LinuxGuard's agent and console capabilities against FedRAMP Rev 5 and StateRAMP, both derived from NIST SP 800-53 Rev 5. The mapping is scoped to controls within the families that LinuxGuard's telemetry, baselines, drift detection, and audit features address: AC (Access Control), AU (Audit and Accountability), CM (Configuration Management), CP (Contingency Planning) — narrow subset, IA (Identification and Authentication), IR (Incident Response), SC (System and Communications Protection) — narrow subset, SI (System and Information Integrity), and SR (Supply Chain Risk Management) — supplier-side documentation only. Controls in the families AT (Awareness and Training), CA (Assessment, Authorization, and Monitoring) — assessment-process administration, MA (Maintenance) — outside the OS layer, MP (Media Protection), PE (Physical and Environmental Protection), PL (Planning), PM (Program Management), PS (Personnel Security), PT (PII Processing and Transparency), RA (Risk Assessment) — risk-assessment-process administration, and SA (System and Services Acquisition) — outside the OS layer, 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 3PAO independent assessment.

Customers remain responsible for the System Security Plan (SSP) including the authorization-boundary definition under NIST SP 800-37 Rev 2; the control implementation summary and customer-responsibility matrix; the inherited-control allocations from underlying IaaS / PaaS providers; engagement of a Third Party Assessment Organization (3PAO) for FedRAMP Moderate / High assessments or the StateRAMP equivalent; the System Assessment Report (SAR) and Plan of Action and Milestones (POA\&M); the Authorization to Operate (ATO) package; continuous monitoring per NIST SP 800-137; and the Significant Change Authorization process for changes affecting the authorization boundary.

## 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 FedRAMP Rev 5 + StateRAMP:

* **LinuxGuard responsibility.** Produce telemetry, baselines, drift detection, audit trails, and evidence artifacts on Linux systems within the customer's authorization boundary supporting the AC, AU, CM, IA, IR, SC, SI, and SR control families. Maintain the framework version pin and per-control evidence pointers. Capture authentication events, file integrity events, configuration drift events, behavioral signals, SUDO execution audit, and support-bundle evidence that feed the customer's continuous monitoring obligations and incident response workflow.
* **Customer responsibility.** Define the authorization boundary per NIST SP 800-37 Rev 2 and FedRAMP guidance; draft the System Security Plan and the customer-responsibility matrix; allocate controls between inherited (from underlying IaaS / PaaS), shared, system-specific, and component-specific (LinuxGuard) implementations; engage the 3PAO; produce the SAR and POA\&M; obtain and maintain the ATO; operate the continuous monitoring programme per NIST SP 800-137 including monthly POA\&M updates and annual control reassessments; and administer the Significant Change Authorization process. For StateRAMP customers, follow the StateRAMP authorization process and PMO review workflow.
* **Out-of-scope domains for this framework.** Authorization boundary definition, SSP authoring, 3PAO engagement, ATO maintenance, AT family (training), MP family (media protection), PE family (physical protection), PL family (planning), PM family (program management), PS family (personnel security), PT family (PII processing and transparency at the application layer), and the assessment-process administration aspects of CA and RA.

## 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.

### Access Control (AC)

| Control ID | Description                                                                                   | Tier       | Evidence                                                                                                                                           | Notes                                                                                                                                                                                                                          |
| ---------- | --------------------------------------------------------------------------------------------- | ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `AC-2`     | Account Management — establish, enable, modify, disable, remove accounts                      | `Supports` | Console Audit pillar → Authorizations audit; Console Compliance Expansion → Config Drift on accounts baseline; Agent log (raw events)              | LinuxGuard surfaces account inventory and drift on accounts baseline supporting account-management evidence. Customer responsible for IAM workflow (provisioning, modification, deprovisioning) and account-management policy. |
| `AC-3`     | Access Enforcement — enforce approved authorizations                                          | `Supports` | Agent log (raw events) with `loginUID` attribute; Console Audit pillar → SUDO execution audit                                                      | `loginUID` capture surviving sudo/su escalation provides evidence of access enforcement at the OS layer. Customer responsible for the access-enforcement mechanism (PAM, LDAP, SSO) and the policy administered through it.    |
| `AC-6`     | Least Privilege — principle of least privilege for accounts and processes                     | `Supports` | Console Audit pillar → SUDO execution audit; Console Compliance Expansion → control detail; Config Drift on sudo rules and sudo defaults baselines | SUDO rule baselines, sudo defaults baseline, and SUDO execution audit support least-privilege evidence. Customer responsible for the privilege-allocation decisions and the broader least-privilege policy.                    |
| `AC-7`     | Unsuccessful Logon Attempts — automatic account lockout after configurable number of attempts | `Supports` | Agent log (raw events); Console Identity Intelligence → Brute Force Detection                                                                      | Authentication failure capture and brute-force detection surface unsuccessful logon patterns. Customer responsible for the account-lockout enforcement (PAM `pam_faillock` or equivalent) and lockout policy.                  |

### Audit and Accountability (AU)

| Control ID | Description                                                                                         | Tier        | Evidence                                                                            | Notes                                                                                                                                                                                                                                                                                       |
| ---------- | --------------------------------------------------------------------------------------------------- | ----------- | ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `AU-2`     | Event Logging — identify event types selected for logging                                           | `Satisfies` | Agent log (raw events) at `/var/log/linuxguard/agent.log`; Support bundle           | LinuxGuard generates structured audit logs continuously on every enrolled Linux host, covering authentication, file integrity, configuration changes, and SUDO execution. See [Log Management](/operate/operate/log-management.md).                                                         |
| `AU-3`     | Content of Audit Records — record content of events sufficient for after-the-fact investigations    | `Satisfies` | Agent log (raw events) with `loginUID`, source IP, user, method, timestamp, command | Agent log records carry user identity (`loginUID`), source, method, and timestamp on each event supporting investigation reconstruction.                                                                                                                                                    |
| `AU-6`     | Audit Record Review, Analysis, and Reporting — review and analyse audit records                     | `Supports`  | Console Compliance Expansion → History; Console Zero Trust Enforcement → Signals    | Console surfaces signals, drift events, and authorization audit for the review workflow. Customer responsible for the review cadence, reviewer assignment, and analysis reporting.                                                                                                          |
| `AU-9`     | Protection of Audit Information — protect audit records from unauthorised modification              | `Supports`  | Agent log on disk with logrotate integration; Support bundle                        | LinuxGuard writes to `/var/log/linuxguard/agent.log` with standard UNIX permissions; logrotate close+reopen via SIGHUP. Customer responsible for forwarding to write-once central log management for tamper resistance and for the WORM / hash-chain configuration on the receiving system. |
| `AU-11`    | Audit Record Retention — retain audit records consistent with records retention policy              | `Supports`  | Agent log rotation (`logging.max_age_days`); Console Compliance Expansion → History | Default agent retention is 14 days locally; customers ship to central log management for the federal records retention requirement. See [Log Management § Central Log Collection Patterns](/operate/operate/log-management.md#central-log-collection-patterns).                             |
| `AU-12`    | Audit Record Generation — provide audit record generation capability for the events defined in AU-2 | `Satisfies` | Agent log (raw events)                                                              | Continuous audit record generation by the agent on every enrolled host.                                                                                                                                                                                                                     |

### Configuration Management (CM)

| Control ID | Description                                                                               | Tier       | Evidence                                                                        | Notes                                                                                                                                                                                                                                         |
| ---------- | ----------------------------------------------------------------------------------------- | ---------- | ------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `CM-2`     | Baseline Configuration — develop, document, and maintain a current baseline configuration | `Supports` | Console Compliance Expansion → control detail; Config Drift events on baselines | LinuxGuard surfaces drift against SSH config, SSHD config, accounts, groups, sudo aliases, sudo defaults, and sudo rules baselines. Customer responsible for defining the baseline content and for application-layer baseline configurations. |
| `CM-3`     | Configuration Change Control — determine and document configuration changes               | `Supports` | Console Zero Trust Enforcement → Config Drift; Agent log (raw events)           | Drift detection surfaces configuration changes against the established baseline. Customer responsible for the change control board, change authorization workflow, and change documentation.                                                  |
| `CM-6`     | Configuration Settings — establish and document configuration settings                    | `Supports` | Console Compliance Expansion → control detail; Config Drift events              | Baseline content captures configuration settings; drift events surface deviations. Customer responsible for the settings content and the policy authorising deviations.                                                                       |
| `CM-7`     | Least Functionality — configure system to provide only essential capabilities             | `Supports` | Console Compliance Expansion → control detail; Agent log (raw events)           | Process activity capture and configuration baselines support least-functionality evidence. Customer responsible for the prohibited-software policy, port and protocol restrictions, and disabling-unnecessary-services workflow.              |
| `CM-8`     | System Component Inventory — develop and document an inventory of system components       | `Supports` | Console Infrastructure; Agent log (raw events)                                  | LinuxGuard inventory of enrolled hosts and per-host metadata (kernel, distro, arch, agent version) contributes to component inventory at the OS layer. Customer responsible for the broader inventory across all system components.           |

### Identification and Authentication (IA)

| Control ID | Description                                                                                   | Tier           | Evidence                                                                        | Notes                                                                                                                                                                                                                     |
| ---------- | --------------------------------------------------------------------------------------------- | -------------- | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `IA-2`     | Identification and Authentication (organizational users) — uniquely identify and authenticate | `Supports`     | Agent log (raw events) with `loginUID` attribute; Console Identity Intelligence | `loginUID` capture provides unique identity attribution surviving sudo/su escalation. Customer responsible for the IAM system, account-provisioning workflow, password policy, and MFA enforcement (IA-2(1) and IA-2(2)). |
| `IA-5`     | Authenticator Management — manage system authenticators                                       | `Out of scope` | n/a                                                                             | Authenticator content management (password policies, key rotation, certificate provisioning) is outside the OS-layer telemetry domain. Customer's IAM and PAM configuration administers authenticators.                   |

### Incident Response (IR)

| Control ID | Description                                                              | Tier       | Evidence                                                                                                                 | Notes                                                                                                                                                                                                                                                                                                |
| ---------- | ------------------------------------------------------------------------ | ---------- | ------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `IR-4`     | Incident Handling — implement incident handling capability for incidents | `Supports` | Agent log (raw events); Console Zero Trust Enforcement → Signals; Support bundle; Console Compliance Expansion → History | LinuxGuard provides the technical detection and timeline surface supporting the customer's incident handling capability. Customer responsible for the incident response procedure, role assignments, training, and the broader handling workflow.                                                    |
| `IR-6`     | Incident Reporting — report incidents within reporting timeframes        | `Supports` | Agent log (raw events) with timestamps; Console Zero Trust Enforcement → Signals; Support bundle                         | Agent log timestamps and signal records provide the technical timeline supporting incident reports. Customer responsible for US-CERT reporting (FedRAMP requires reporting per agency-specific procedures and the FedRAMP PMO Incident Communications Procedure) and the broader reporting workflow. |

### System and Communications Protection (SC) — narrow subset

| Control ID | Description                                                                                      | Tier           | Evidence | Notes                                                                                                                                                                                      |
| ---------- | ------------------------------------------------------------------------------------------------ | -------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `SC-7`     | Boundary Protection — monitor and control communications at external and key internal boundaries | `Out of scope` | n/a      | Boundary protection (firewalls, network segmentation, perimeter enforcement) is a customer responsibility outside the OS-layer telemetry domain.                                           |
| `SC-13`    | Cryptographic Protection — implement FIPS-validated cryptography                                 | `Out of scope` | n/a      | FIPS-validated cryptographic module deployment is outside the OS-layer telemetry domain. Customer responsible for FIPS-validated module deployment (OpenSSL FIPS, Linux kernel FIPS mode). |

### System and Information Integrity (SI)

| Control ID | Description                                                                                            | Tier        | Evidence                                                                                                        | Notes                                                                                                                                                                                                                                                                                                 |
| ---------- | ------------------------------------------------------------------------------------------------------ | ----------- | --------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `SI-3`     | Malicious Code Protection — implement signature-based or non-signature-based malicious code protection | `Supports`  | Agent log (raw events); Console Zero Trust Enforcement → Signals                                                | LinuxGuard provides behavioural detection supporting non-signature malicious-code protection. Customer responsible for signature-based anti-malware deployment where required by the baseline.                                                                                                        |
| `SI-4`     | System Monitoring — monitor system to detect attacks and indicators of potential attacks               | `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 system monitoring with attack-indicator detection at the OS layer. See [Security Architecture](/concepts/concepts/security-architecture.md). |
| `SI-7`     | Software, Firmware, and Information Integrity — employ integrity verification tools                    | `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 feeding the integrity verification capability.                                                                                                                      |

### Supply Chain Risk Management (SR) — supplier-side documentation only

| Control ID | Description                                                                                               | Tier           | Evidence                                                                   | Notes                                                                                                                                                                                                                                                                          |
| ---------- | --------------------------------------------------------------------------------------------------------- | -------------- | -------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `SR-3`     | Supply Chain Controls and Processes — establish process for identifying and addressing supply chain risks | `Supports`     | Audit & Comply per-framework pages; Console Compliance Expansion → Reports | LinuxGuard provides supplier-side documentation: framework version pins, per-framework mapping pages, evidence chain integrity (SHA-256 manifests on collected evidence packages). Customer responsible for the supply chain risk management programme covering all suppliers. |
| `SR-11`    | Component Authenticity — develop and implement anti-counterfeit policy                                    | `Out of scope` | n/a                                                                        | Component authenticity policy administration (covering hardware procurement, anti-counterfeit verification, suspect-component handling) is outside the OS-layer telemetry domain.                                                                                              |

### Out-of-family controls

| Control ID         | Description                           | Tier           | Evidence | Notes                                                                                                                                                                                            |
| ------------------ | ------------------------------------- | -------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `AT family`        | Awareness and Training                | `Out of scope` | n/a      | Training programme administration is an organisational responsibility not addressed by LinuxGuard.                                                                                               |
| `MP family`        | Media Protection                      | `Out of scope` | n/a      | Media protection (digital and non-digital media handling, marking, storage, transport, sanitisation) is outside the OS-layer telemetry domain.                                                   |
| `PE family`        | Physical and Environmental Protection | `Out of scope` | n/a      | Physical and environmental controls (facility access, environmental monitoring, fire protection, temperature and humidity control) are not addressed by LinuxGuard.                              |
| `PS family`        | Personnel Security                    | `Out of scope` | n/a      | Personnel security (position categorisation, screening, termination, transfer, sanctions) is an organisational responsibility not addressed by LinuxGuard.                                       |
| `PT family`        | PII Processing and Transparency       | `Out of scope` | n/a      | PII processing and transparency requirements (data tagging, consent management, redaction at the application layer) are outside the OS-layer telemetry domain.                                   |
| `CP family` (most) | Contingency Planning — most controls  | `Out of scope` | n/a      | Contingency planning, backup management, alternate processing sites, and disaster recovery are not addressed by LinuxGuard. Limited support via support-bundle archives for forensic continuity. |

> **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.

## Authorization boundary considerations

The authorization boundary is the central organising concept for FedRAMP and StateRAMP authorization. NIST SP 800-37 Rev 2 defines the boundary as "all components of an information system to be authorized for operation by an authorizing official." For cloud service providers, the boundary encompasses the application, supporting infrastructure, interconnections with external systems, and inherited controls from underlying IaaS / PaaS providers.

LinuxGuard sits within the authorization boundary as a system component when deployed on hosts in the boundary. The customer's SSP allocates control implementations across:

* **Customer-implemented controls.** Controls the CSP implements directly within the boundary. LinuxGuard contributes to customer-implemented controls in the AC, AU, CM, IA, IR, SI families per the table above.
* **Inherited controls.** Controls implemented by an underlying provider (e.g., the IaaS provider's PE family for physical controls). LinuxGuard does not produce evidence for inherited controls — the underlying provider's authorization package supplies that evidence.
* **Shared controls.** Controls partially implemented by the CSP and partially inherited. LinuxGuard's telemetry may contribute one input to a shared control where the OS-layer activity is one part of the broader implementation.
* **Customer-responsibility controls.** Controls the consumer of the cloud service is responsible for (e.g., application-layer access control). LinuxGuard does not produce evidence for customer-responsibility controls — those are implemented by the agency or customer consuming the CSP's service.

The customer-responsibility matrix in the SSP documents the allocation explicitly. LinuxGuard's mapping above states what the agent and console produce as evidence; the SSP allocation states where in the customer-responsibility matrix that evidence lives.

## Baseline considerations

FedRAMP defines three baselines reflecting impact level: Low, Moderate, and High. StateRAMP adopts the same three baselines with state-government scope adjustments. The control selection per baseline derives from NIST SP 800-53 Rev 5 with FedRAMP-specific parameter values, additional controls beyond the NIST baselines, and tailoring guidance.

This page maps LinuxGuard's coverage at the control level without distinguishing baseline; the customer's SSP records the per-baseline applicability. Practical observations across baselines:

* **Low Impact.** A smaller control set with less granular implementation evidence. LinuxGuard's `Satisfies` claims on AU-2, AU-3, AU-12, SI-4, and SI-7 typically map directly into the customer's Low baseline SSP.
* **Moderate Impact.** A more granular control set including additional control enhancements. LinuxGuard's `Supports` claims become more important — the customer's implementation must also address the additional enhancements that LinuxGuard does not directly address.
* **High Impact.** The most granular control set with the most stringent enhancements. The customer's implementation typically includes additional controls (e.g., AU-6 enhancements requiring automated review) for which LinuxGuard provides telemetry but the customer adds review automation.

The 3PAO assessment evaluates implementation evidence against the per-baseline applicable controls. LinuxGuard's evidence pointers feed the assessment for the controls covered above; the 3PAO determines control satisfaction at the assessment level.

## Continuous monitoring considerations

FedRAMP authorization is followed by ongoing continuous monitoring per NIST SP 800-137. The CSP submits monthly POA\&M updates, monthly vulnerability scan results, and annual control reassessments to the authorizing official.

LinuxGuard's compliance dashboard supports the continuous monitoring obligations:

* **Monthly POA\&M evidence.** Console Compliance Expansion → History surfaces per-control posture trends supporting POA\&M remediation evidence.
* **Vulnerability monitoring.** LinuxGuard does not perform vulnerability scanning. Customer's vulnerability scanning solution feeds the monthly scan submission separately.
* **Annual control reassessment.** The 3PAO's annual reassessment scope includes the OS-layer controls in the mapping above. LinuxGuard's framework version pin and last-verified date on this page support the reassessment cadence.
* **Significant change authorization.** Changes affecting the authorization boundary require Significant Change Authorization. LinuxGuard's version updates within the agent are reflected in the customer's component version inventory; major version bumps may trigger Significant Change review.

## FedRAMP vs StateRAMP differences

FedRAMP (federal) and StateRAMP (state and local government) share the same underlying control catalog (NIST SP 800-53 Rev 5) and the same three impact baselines (Low, Moderate, High). The differences are procedural and audience-related, not control-text-related, for the families this page covers.

| Dimension                        | FedRAMP                                                                                       | StateRAMP                                                                   |
| -------------------------------- | --------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- |
| Authorizing body                 | Federal agency Authorizing Official (AO) or FedRAMP Joint Authorization Board (JAB) for P-ATO | StateRAMP Program Management Office and individual state authorizing bodies |
| Target consumers                 | Federal agencies and federal contractors                                                      | State and local government entities, public sector consumers                |
| Assessment organization          | 3PAO accredited by A2LA                                                                       | 3PAO accredited by A2LA (often the same accreditation supports both)        |
| Continuous monitoring submission | FedRAMP PMO Marketplace and consuming agency                                                  | StateRAMP PMO and consuming state                                           |
| Reuse model                      | Inheritance via FedRAMP Marketplace authorizations                                            | Reciprocity across StateRAMP participating states                           |
| Reauthorization cadence          | Annual ATO maintenance with 3-year reassessment cycle                                         | Annual posture renewal aligned with FedRAMP cadence                         |

For the controls in this page's mapping, the customer's implementation evidence and the assessment evidence are structurally identical between the two programs. Customers operating in both federal and state markets commonly produce one unified evidence package satisfying both programs' assessment requirements with program-specific submission packaging.

## Cross-framework considerations

Customers in scope of FedRAMP or StateRAMP are commonly also in scope of agency-specific overlays (DoD CC SRG for defense systems, IRS Publication 1075 for tax-data systems, CJIS Security Policy for criminal-justice-data systems) and adjacent frameworks (NIST CSF 2.0 for the broader risk-management view, ISO/IEC 27001:2022 for international expansion).

Operational alignment patterns customers commonly adopt:

* **Unified evidence package.** Maintain one evidence package satisfying FedRAMP, StateRAMP, NIST CSF 2.0, and ISO/IEC 27001:2022 for the OS-layer controls covered above. The three-tier vocabulary consistency across LinuxGuard's per-framework pages supports the unified packaging.
* **Overlay-specific addenda.** Where agency-specific overlays apply (DoD CC SRG, IRS 1075, CJIS), add overlay-specific evidence as an addendum to the base NIST SP 800-53 Rev 5 evidence rather than rebuilding evidence from scratch.
* **Continuous monitoring consolidation.** Use Console Compliance Expansion → History as the single posture-trend source feeding the FedRAMP / StateRAMP continuous monitoring submissions and the customer's broader posture reporting.

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 3PAO's, PMO's, or authorizing official'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 (FedRAMP Rev 5 + StateRAMP), 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 3PAO wants raw host-level telemetry rather than a console-rendered report, particularly during the SAR-supporting evidence-collection phase.
* **Console CSV / JSON export per control.** Compliance Expansion → FedRAMP → control detail → Evidence tab exports per-control evidence in machine-readable form for the 3PAO'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 federal-system evidence where hostnames and process command-line arguments may correlate to system identifiers within the authorization boundary. 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 AU-11 audit record retention.
* [**Glossary**](/reference/reference/glossary.md) — framework acronyms and compliance vocabulary definitions.

***

*Last reviewed: 2026-05-31 against FedRAMP Rev 5 baselines (released 2023-05-30) and StateRAMP; both derived from NIST SP 800-53 Revision 5 (released 2020-09-23, updates per NIST errata).*


---

# 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/fedramp-stateramp.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.