Policies and drift, read against the configured state.

Red Hat Insights policies and drift monitoring describes two services delivered inside the standard Insights bundle that ship with the RHEL subscription. The policies service accepts declarative rules written against host facts (operating system version, package state, service status, kernel parameter values) and raises an alert when a connected host evaluates as out of compliance with the rule. The drift service captures a host baseline (either a specific point in time, a chosen host as the reference, or a system level baseline) and tracks deviation of every connected host against that baseline over time, surfacing the diff in the Insights dashboard. Both services are bundle features rather than add ons; both carry no incremental fee on the RHEL subscription.1

The entitlement reading is bundle inclusion and does not depend on a separate Smart Management entitlement. A buyer with a RHEL subscription and the Insights agent installed has access to the policies and drift services without any procurement action. The cross reading on the Insights bundle scope sits in the Red Hat Lightspeed for RHEL licensing note, which shows where the bundle line currently sits and where the buyer should expect Red Hat to lever the bundle composition at future cycles.

The relationship to the malware add on is the part of the bundle reading that frequently confuses the procurement register. The policies and drift services are inside the bundle and require no add on entitlement; the malware add on is outside the bundle and requires a discrete entitlement. A buyer that has authorised the malware add on but has not activated policies and drift is paying for a service while leaving included services unused. The sibling treatment sits in the Red Hat Insights malware detection add on note.

Three factors shape the policies and drift reading at the buyer side.

The first factor is the operational adoption. The services produce value only when the operations team has written meaningful policies and has chosen a defensible baseline for drift. A buyer who has activated the services but has zero policies authored is paying nothing for them (they are bundle inclusions) but is also receiving no value; the discipline is the activation programme that follows the procurement action. A free service unused is still a service unused. The discipline sits inside the broader frame of the 90 day subscription assessment.2

The second factor is the audit evidence value. A policy alert that the host went out of compliance, dated and logged, is a defensible audit evidence artifact. A drift report that documents a configuration change, dated and tied to a change ticket, is an audit evidence artifact. The buyer who has wired the policies and drift outputs into the audit evidence chain has converted a bundle feature into a structural audit defense. The cross cluster bridge sits in the audit clause anatomy and negotiation note, where the evidence types named in the audit clause frequently match the policies and drift output formats.

The third factor is the data flow to the hosted Insights service. Both services run against host state collected by the Insights agent and uploaded to the hosted service; the policy evaluation and the drift comparison happen on the hosted side. The residency posture is therefore the same as for the rest of the Insights bundle. A regulated estate that has not authorised the broader Insights data flow has implicitly not authorised the policies and drift flow either. The cross reading sits in the Insights data sharing implications note.

The audit reading on policies and drift walks four artifacts. The policy library actually authored against the host estate, the alert history showing where hosts went out of compliance, the drift baseline definition and the deviation log against it, and the change ticket trail tied to drift events. The reading is internally consistent when the policy library covers the audit relevant rules (kernel parameters, service state, package presence), the alert history shows the operations team responded to each alert, and the drift log ties every meaningful change to a change ticket.3

The most common audit reading misstep on the policies and drift services is the absence of a policy library covering audit relevant rules. A buyer can have Insights enabled across the entire RHEL estate and still have no policies authored against entitlement enforcement, host class segmentation, or change management state; the bundle is active but the evidence is empty. The remediation is the policy authoring programme inside the activation cycle. The discipline overlaps with the treatment in the deployment evidence in audit defense note.

The second misstep is the drift baseline tied to a host that has itself drifted. A buyer who chose a reference host as the drift baseline at activation and has not refreshed that baseline since is comparing every host to a baseline that no longer reflects the current authorised state. The drift reports therefore generate noise without signal; the audit reading on the drift output is consequently weak. The remediation is the baseline refresh discipline at every release cycle.

The renewal posture on policies and drift has three habits.

The first habit is the bundle feature inventory at the cycle. The Insights bundle features are enumerated; each is given a value reading and an activation state; gaps between value and state are named. The discipline keeps the buyer aware of what the bundle currently includes and prepares the buyer for any bundle composition shift Red Hat presents at the next cycle. The cross reading sits in the Satellite versus Red Hat Cloud Console economics note.4

The second habit is the policy authoring cadence. New policies are authored each cycle against the new audit relevant rules; existing policies are reviewed against current relevance; obsolete policies are retired. The discipline overlaps with the treatment in subscription assessment.

The third habit is the SIEM integration verification. The export of policy alerts and drift events to the buyer side SIEM is verified at the cycle; retention is reconciled; gaps are remediated inside the cycle. The discipline overlaps with the broader treatment in renewal negotiation.

The policies and drift reading sits inside the operational maturity of the team that runs the RHEL estate.

The first trade off is the in house alternative. A team that has built its own configuration management tooling (Ansible playbooks, custom checks, periodic audits) has a working substitute; the policies and drift services add complementary visibility without replacing the existing tooling. A team that has no equivalent tooling can reach a higher operational floor faster through policies and drift than through building from scratch. The discipline is the explicit read of the in house alternative's coverage. The bridge to the broader practice hub sits in the Satellite and Insights practice hub.

The second trade off is the operational team's bandwidth. The services produce alerts that require operational attention; a team without bandwidth to triage the alerts will silence the alerts and the evidence value evaporates. The discipline is the alert triage capacity check at activation. The cross reading sits in the Insights compliance and vulnerability reports note.

The third trade off is the regulatory pressure. A regulated estate that must demonstrate configuration management discipline at audit reads the policies and drift outputs as net new audit evidence; a less regulated estate reads them as operational hygiene. The buyer who has named the regulatory pressure explicitly reads the cycle posture correctly. The pattern overlaps with the treatment in the RHEL practice hub. For an engagement against the desk, see the contact form.

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.