Compliance Expansion

Compliance Expansion pillar — frameworks browser, evidence collection, compliance history, reports, suppressions, and evidence location reference.

The Compliance Expansion pillar provides the deeper compliance surface beyond the v3.0 Compliance & Audit pillar's framework score view. Where Compliance & Audit answers "what is our score?", Compliance Expansion answers "what evidence supports that score, where is it stored, how has it moved over time, and what is suppressed?" This is the surface auditors, internal control owners, and compliance program managers spend most of their time inside.

Note: The LinuxGuard Console is the canonical reference for screen-by-screen layout. This page describes the conceptual scope and integration points.

The pillar is organized around the auditor workflow: select a framework (frameworks browser), examine the controls and how LinuxGuard satisfies / supports / does not cover them (evidence collection), track the trend over the audit period (compliance history), produce auditor-shareable evidence packages (reports), and document the controls that have been intentionally accepted out of scope (suppressions).

Frameworks browser

The Frameworks browser is the entry point. It lists every compliance framework enabled on the tenant — PCI-DSS, HIPAA, SOC 2, NIS2, DORA, GDPR, NIST CSF, ISO 27001, CIS Controls, CIS Benchmarks, FedRAMP, HITRUST / FFIEC — with the framework version pin, last-verified date, and current pass / fail / not-applicable counts.

Selecting a framework opens a control-level view. For each control LinuxGuard exposes a three-tier coverage indicator (Satisfies / Supports / Out of scope), the per-server pass / fail breakdown, and the evidence pointer set (see Evidence Location below). Framework views support search and filter on control ID, status, and per-server scope.

The frameworks browser is read-only at the framework definition level — control definitions and framework versions are managed by LinuxGuard, not by tenants. What the tenant configures is the framework's enablement, which servers are in scope, and which controls are intentionally suppressed.

Evidence collection

Evidence collection is the systematic gathering of the artifacts an auditor needs to verify each control. LinuxGuard packages evidence per control and per server, with cryptographic integrity verification (SHA-256 over each file) so the evidence chain is tamper-evident.

Evidence categories collected:

Category
Examples

Configuration state

sshd_config, sudoers content, account / group inventory, file permissions on sensitive paths

Behavioral evidence

Signal logs, drift event history, authorization audit trail, sudo execution audit trail

Operational evidence

Log retention validation, support-bundle history, console audit log entries

Cryptographic evidence

SHA-256 of each artifact, manifest signing where enabled

Evidence is collected continuously as agent telemetry arrives. The console assembles per-control evidence views on demand. There is no separate "scan now" step for evidence — every framework check is a query against the existing telemetry surface.

Evidence Location

Phases 23-25 per-framework pages reference this section for the canonical evidence pointer set. Every framework control mapping cites at least one evidence source from this list, and the per-framework pages link back here rather than duplicating the table.

Evidence type
Source location
How to retrieve
Retention

Agent log (raw events)

/var/log/linuxguard/agent.log and rotated segments

Direct read on host, or via support bundle

14 days default, configurable via logging.max_age_days

Agent configuration (redacted)

/etc/linuxguard/agent.config

Direct read on host, or via support bundle (config.redacted.json)

Until next config change

Support bundle

Default path: /var/lib/linuxguard/support/<unix_timestamp>.tar.zst (overridable with --out)

support-bundle collect on host; console Evidence tab on the support-bundles page

Per tenant retention policy

Console Evidence tab (per server)

Server detail page → Evidence tab

Console UI; CSV / JSON export

Per tenant retention policy

Console Evidence tab (per control)

Compliance Expansion → framework → control detail → Evidence tab

Console UI; CSV / JSON export

Per tenant retention policy

Signals (security events)

Agent log + console Zero Trust Enforcement → Signals

Direct via agent log; console UI; CSV / JSON export

Per tenant retention policy

Config Drift events

Console Zero Trust Enforcement → Config Drift

Console UI; CSV / JSON export

Per tenant retention policy

SUDO execution audit

Console Audit pillar → SUDO execution audit

Console UI; CSV / JSON export

Per tenant retention policy

Compliance history

Console Compliance Expansion → History

Console UI; CSV / JSON export

Per tenant retention policy

Compliance reports

Console Compliance Expansion → Reports

Console UI; PDF / CSV / JSON export

Per export

Manifest of bundle contents

BUNDLE-MANIFEST.json inside any support bundle

Extract from bundle archive

Lifetime of bundle

When a per-framework mapping page (e.g., audit-comply/pci-dss.md) cites evidence, it points to a row of this table by name. The convention keeps per-framework pages concise and ensures the evidence-pointer set stays consistent across all 12 frameworks.

Security Note: Support bundles and agent.log files include attribute-key redaction only — they do not redact PII (hostnames, IPs, usernames, paths, command args). Review and approve every evidence package before sharing externally. See Support Bundles for the per-file redaction status table.

Compliance history

Compliance history shows pass / fail / not-applicable trends per framework over configurable time windows. It supports the audit period question — "how did our compliance posture move over the last quarter / fiscal year?" — and provides the trend evidence many auditors require alongside point-in-time snapshots.

The view includes annotation events: framework version bumps, control definition updates, server enrollment changes, and suppression changes. Annotations let the operator (and the auditor reviewing the history) distinguish between posture changes driven by remediation work and changes driven by definitional updates.

Reports

Reports produces compliance evidence packages for external sharing. Each report is a snapshot, dated and signed, including:

  • Framework version and last-verified date

  • Per-control coverage indicator and evidence pointers

  • Per-server pass / fail breakdown

  • Suppressions in effect during the report period, with each suppression's reason and expiration

  • Manifest of included evidence with SHA-256 verification

Export formats: PDF (auditor-shareable presentation), CSV (machine-readable per-control table), JSON (full structured evidence including pointers). Reports are immutable once generated — they are evidence artifacts and need to be reproducible by reference.

Suppressions

Suppressions documents the controls that have been intentionally accepted as not in scope for a given audit period. Each suppression captures:

Field
Purpose

Framework + control

Which control is suppressed

Scope

Tenant-wide, environment-wide, server-set, or single server

Reason

Free-text justification (required)

Approver

Identity of the person who approved the suppression

Effective date

When the suppression takes effect

Expiration date

When the suppression auto-expires (optional but recommended)

Suppressions are first-class audit evidence — they appear in compliance reports, in the history view (as annotation events), and are subject to the tenant's audit log. A suppression is not "ignoring" a control; it is documenting the deliberate decision that the control does not apply to a specific scope for a specific time.

Suppressions can be reversed (a control returns to active scope when its suppression expires or is explicitly removed) and reactivated. The suppressions page maintains the full history of every suppression event — when it was created, by whom, with what reason, when it expired, and when it was reactivated.

Data sources

Compliance Expansion draws on:

  • Agent telemetry — every signal, drift event, authorization, and execution event that LinuxGuard collects feeds compliance evidence

  • Framework definitions — managed by LinuxGuard, version-pinned, with last-verified dates on each control

  • Tenant configuration — framework enablement, scope (which servers / environments are in scope per framework), and suppressions

No external evidence sources feed Compliance Expansion. All evidence cited in framework views and reports originates from LinuxGuard agent telemetry or tenant-configured scope decisions.

Module gating

The Compliance module gates Compliance Expansion. Subscription gating documented in console — the number of frameworks a tenant can enable, the retention window on compliance history, and reporting export cadence vary by tier. Suppressions, frameworks browser, and per-control evidence views are available wherever the Compliance module is present.

Cross-references

  • Related CLI commands: support-bundle (evidence collection at the host level), config (agent retention configuration)

  • Related Concepts: Compliance & Audit (the v3.0 pillar this expansion builds on), Audit (authorizations and SUDO execution audit feed compliance evidence)

  • Related How-to: Support Bundles (per-file redaction status table; pre-share PII warning), Log Management (retention configuration)

  • Related Audit & Comply pages: see Audit & Comply for the per-framework mapping pages (Phases 23-25)


Related: Console | Compliance & Audit | Audit | Support Bundles | Glossary

Last updated

Was this helpful?