Deployment evidence, read carefully.

A Red Hat audit produces a finding only against material the audit team has accepted as evidence of deployment under the contract. Evidence is the precise category of material that the contract obliges the customer to maintain and that the audit team is contractually entitled to review. Everything else the customer holds about its own deployment is context. Context can shape the audit team's model. It does not, on its own, support a finding. Red Hat audit deployment evidence in 2026 is the formal subset; the contractual question is which of the customer's tools produce evidence in that sense and which produce context only.1

The line between evidence and context matters because most enterprises operate Red Hat at the scale where the operational tooling produces more material than the contract requires. Insights, Satellite, Subscription Watch, ITSM databases, configuration management archives, monitoring platforms, and CMDB entries each describe parts of the deployment estate. The audit team's contractual reach into each of these tools is different. Where the audit team can subpoena content out of one and only request access to another, the response that treats both identically gives away the contractual distinction.

The companion notes on the compliance letter response and Red Hat Insights data and the audit treat related questions on the data sharing posture. The present note focuses on what the audit team treats as evidence in the formal sense.

Three Red Hat operated tools sit closest to the evidence question. Insights collects system level telemetry into Red Hat's own platform. Satellite manages content and configuration for Red Hat systems and exports on demand. Subscription Watch aggregates entitlement consumption into a dashboard the customer's account team can read. Each is governed by a different contractual posture and each produces a different category of material in an audit.

Insights data sits on Red Hat infrastructure. The audit team has direct visibility into the data the customer's environment has chosen to send. Where the customer has registered systems with Insights, the audit team treats the registered systems as part of the deployment evidence. Where systems are not registered, Insights produces no evidence on them. The decision to register is not a decision to share with the audit team specifically; it is a decision to share with Red Hat, which the audit team is part of in the contractual sense. The note on Insights data sharing implications treats this question in detail.2

Satellite data sits on the customer's infrastructure. The audit team has no direct visibility; the contract obliges the customer to produce Satellite reports on request. The format the customer produces is rarely the format the audit team prefers. The contract typically does not require a specific export format. The response that produces a Satellite report in the contract's defined format produces less context than a wholesale Satellite database export. The note on Satellite content views and audit posture treats the export format question.

Subscription Watch is a hybrid. The data is held by Red Hat, but the customer's account team is the primary user. The audit team has access to the same data. Subscription Watch produces evidence on what Red Hat's own systems have recorded against the customer's account; it does not produce evidence on what the customer has actually deployed unless the customer has actively reconciled the two. Where Subscription Watch is treated by the audit team as evidence of deployment, the response is to assert the distinction in the response language and reconcile actively rather than passively.

The response shares as evidence what the contract obliges the customer to produce and no more. The first question on a Red Hat audit is therefore not what the customer can produce but what the contract requires. The contract typically requires an inventory of Red Hat entitled systems under the agreement, in a format that allows the audit team to reconcile against the entitlement record. The contract typically does not require the customer's full configuration management database, the full Insights inventory, the full Satellite export, or any operational artefact that exceeds the inventory definition.

The figure below sets out the practice's reading of which operational sources produce evidence versus context in a typical Red Hat audit, with the contractual basis for each line.

Context is everything the customer holds about the deployment estate that the contract does not oblige the customer to produce. The response holds context by referencing the contractual basis on which the material is not produced, not by refusing to acknowledge the material exists. Refusal produces escalation. Reference produces a narrowed scope read.

CMDB entries are the most common source of context that customers volunteer. The CMDB describes deployment as the operations team understands it. The audit team's contractual reach into the CMDB is typically zero. Producing a CMDB extract introduces material into the audit record that the contract did not require, and which the audit team's finding can then treat as evidence. The response that holds the CMDB cites the contractual scope of the inventory request and produces the inventory in the format the contract defines.

Monitoring platform telemetry is similar. The monitoring tool sees what is running; the contract does not oblige the customer to produce that view. Where the audit team requests telemetry on the basis that it would help reconcile the entitlement record, the response asserts the contractual scope of the reconciliation obligation and produces material accordingly. The note on socket pair against virtual datacenter treats the counting mechanic that the reconciliation should apply.

Support case history is the most ambiguous source. Support cases the customer has filed with Red Hat are documents Red Hat already holds; they are evidence in the procedural sense. The response treats support history as evidence and reviews the case archive before producing or referencing it, because some past support cases inadvertently document deployments at scale that the entitlement record does not match. A response that has not read the customer's own support case archive before answering the letter is one move behind the audit team, which has already read it.

The evidence read is the first technical work of a Red Hat audit defense and the work that most shapes the eventual settlement. It is operational rather than contractual; the contractual reading sits on top of the evidence read. A defense that does the contractual work without first running the evidence read tends to assert positions the operational data does not support, which the audit team then breaks at the response stage.

The practice runs the evidence read in the first seventy two hours after engagement. The output is a per source classification of the customer's operational tooling against the contract's inventory definition, a reconciliation of Subscription Watch against Insights against Satellite, and a flagged list of support cases and configuration archives that require review before any response is filed. The note on Red Hat audit defense as a service sets out the protocol; the present note treats the evidence read at the centre of it.5

If the audit notice is in hand, the first useful hour is a call with the practice. The companion note on the first response window treats the timing; the present note treats the evidence work that happens inside the window.

Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.