Use case

Stop reinventing change-control evidence every audit cycle

Most teams under SOX or SOC 2 build their Linux change-control evidence manually: a wiki page of Jira tickets, screenshots of approved PRs, exported Slack threads, and a prayer that the auditor doesn’t ask “and how do you know nothing elsechanged on those servers between approvals?” Blackglass closes that gap.

What auditors actually want

Whether the framework is SOX ITGC 1.4, SOC 2 CC8.1, ISO 27001 A.12.1.2, or a sector-specific equivalent, the underlying question is the same: can you prove that every change to a production system was approved, and that no unapproved changes happened? The evidence package needs to:

1. Identify a known-good baseline state with operator approval and timestamp.
2. Show every deviation from that baseline since approval.
3. For each deviation: who acknowledged it, when, with what context.
4. Be reproducible — auditors return next year and ask for the same view.

How Blackglass produces audit-ready evidence

1. Baseline approval. An operator with the appropriate role captures a baseline of the host (or fleet group) and explicitly approves it. The approval is signed, timestamped, and audit-logged.
2. Every drift becomes a record. Subsequent scans (push or pull) detect changes against the approved baseline. Each drift event has a stable ID, severity, before/after diff, and a status field.
3. Acknowledgement is the change-control bridge. When a drift event is acknowledged, the operator records the rationale (free text + tag), links the relevant change ticket (Jira / Linear / GitHub PR URL), and the audit log captures the actor + timestamp.
4. Evidence bundle export. One click produces a per-host PDF summary plus a JSON archive containing baseline content, every drift event, acknowledgement metadata, and the audit log slice for the period. The PDF is readable by a non-technical auditor; the JSON is machine-parseable for evidence platforms.

Where this lands in your audit narrative

For a SOX walkthrough, the auditor traditionally pulls a sample of changes from your Jira export and asks you to demonstrate, for each, that the change was approved before being applied. The Blackglass evidence bundle inverts that: it shows every change that occurred on the host, with the corresponding approval (acknowledgement) attached. Sample-of-one becomes population-of-everything, with much less work.

For SOC 2, the relevant control is typically CC8.1 (“the entity authorises, designs, develops or acquires, configures, documents, tests, approves, and implements changes”). Auditors look for evidence that configuration changes — not just code changes — follow the same approval discipline. Blackglass directly answers that question.

What the workflow actually feels like

• Engineer ships an approved change → Blackglass detects the resulting drift → operator opens the drift event → links the Jira / GitHub URL → adds a one-line note → marks the event acknowledged.
• Engineer makes an out-of-band hotfix during an incident → drift surfaces → on-call acknowledges it with the incident ticket as the bridge → post-incident review reassesses whether the change should be retroactively approved or rolled back.
• Quarterly audit review → operator opens the host → exports the evidence bundle for the audit period → hands it to the auditor. Total time per host: under a minute.

Related use cases

• Linux configuration drift detection — the underlying detection model.
• File integrity monitoring (FIM) — overlapping coverage that satisfies PCI-DSS 11.5.
• CIS benchmark monitoring — pin a CIS profile as your baseline.

Need a sample evidence bundle for your auditor? Email [email protected] and we’ll send a redacted one.