Ansible infra.windows_ops Collection: DISA STIG and CIS Benchmark Drift Remediation

Keeping Windows servers aligned with DISA STIG and CIS benchmarks is one of those compliance chores that never actually finishes — a patch lands, a GPO gets overridden, an admin flips a registry key during an incident, and suddenly a "compliant" fleet has quietly drifted. At Red Hat Tech Day Netherlands 2026 (3 June 2026, Bunnik), the Ansible team addressed exactly this problem when it unveiled 12 new content collections for Ansible Automation Platform (AAP) 2.7. Among them, infra.windows_ops stands out as the collection purpose-built for Windows security baseline enforcement, DISA STIG alignment, CIS benchmark checks, and continuous drift remediation.

This article looks specifically at what infra.windows_ops is for, how it fits into the broader AAP 2.7 collection lineup, and how teams can start structuring compliance-as-code playbooks around it.

Why Windows Compliance Needs Its Own Collection

Linux configuration management has had mature, standardized compliance tooling (OpenSCAP, compliance-as-code content, ansible.posix) for years. Windows environments, by contrast, have historically relied on a patchwork of Group Policy Objects, PowerShell DSC scripts, and manual STIG checklists that are hard to version, hard to audit, and easy to drift out of alignment silently.

infra.windows_ops closes that gap by giving Windows fleets the same "automate the audit, automate the fix" model that Linux teams already expect: scan a host against a benchmark, produce a structured compliance report, and — where policy allows — automatically remediate the finding in place.

See also: AAP 2.7 EE Builder Step 1: Choosing a Base Image

What the Collection Covers

Based on its announced scope, infra.windows_ops is built around three pillars:

• Security baseline enforcement — applying and validating DISA STIG and CIS Benchmark controls (registry settings, local security policy, audit policy, service states, and account policies) across Windows Server and desktop targets.
• Drift detection — periodic or on-demand scans that compare live host state against the target baseline and flag deviations before they become audit findings.
• Remediation workflows — idempotent tasks that bring non-compliant settings back into line, with reporting suitable for feeding into governance dashboards or Event-Driven Ansible (EDA) pipelines for closed-loop response.

---
- name: Enforce CIS Level 1 baseline and remediate drift on Windows Server fleet
  hosts: windows_servers
  gather_facts: true
  vars:
    baseline_profile: cis_level1_server2022
    remediate_on_drift: true

  tasks:
    - name: Scan host against CIS Level 1 benchmark
      infra.windows_ops.baseline_scan:
        profile: "{{ baseline_profile }}"
      register: scan_result

    - name: Report detected drift findings
      ansible.builtin.debug:
        msg: "{{ scan_result.findings | length }} findings out of compliance"

    - name: Remediate non-compliant controls
      infra.windows_ops.baseline_remediate:
        profile: "{{ baseline_profile }}"
        findings: "{{ scan_result.findings }}"
      when:
        - remediate_on_drift | bool
        - scan_result.findings | length > 0
      register: remediation_result

    - name: Generate compliance report artifact
      infra.windows_ops.compliance_report:
        scan_data: "{{ scan_result }}"
        remediation_data: "{{ remediation_result | default(omit) }}"
        output_format: json
      register: compliance_report

    - name: Save compliance report for audit trail
      ansible.builtin.copy:
        content: "{{ compliance_report.report | to_nice_json }}"
        dest: "/var/log/ansible/compliance/{{ inventory_hostname }}-{{ baseline_profile }}.json"
      delegate_to: localhost

The key structural idea is the separation of scan → remediate → report into distinct, auditable steps. That separation matters for governance: security teams often want visibility into what would* change before automation is allowed to change it, especially on production Windows infrastructure.

See also: AAP 2.7 EE Builder Step 2: Adding Collections from Private Automation Hub

Comparing Baseline Options

Fitting Into the AAP 2.7 Governance Story

infra.windows_ops doesn't exist in isolation. It's one of 12 collections announced together at Red Hat Tech Day Netherlands 2026 under the themes of Efficiency, Resilience, Governance, and Scale — alongside collections like ansible.platform (configuration-as-code and RBAC refactoring for AAP itself) and hashicorp.vault (secrets and dynamic credentials). In practice, that means a mature compliance workflow can combine:

• ansible.platform to manage the job templates and RBAC controlling who can run remediation against which inventory.
• hashicorp.vault to supply dynamic, short-lived credentials for the Windows accounts executing baseline changes.
• infra.windows_ops to perform the actual scan-and-remediate work.

See also: AAP 2.7 EE Builder Step 3: Destination, Build, and Publish to Git

Key Takeaways

• infra.windows_ops is one of 12 new collections announced for AAP 2.7 at Red Hat Tech Day Netherlands 2026, focused specifically on Windows security baseline enforcement, DISA STIG alignment, CIS benchmark checks, and drift remediation.
• The collection follows a scan → remediate → report pattern, letting teams separate detection from automated fixing for better governance control.
• It complements infra.mecm_ops (patch orchestration) and pairs naturally with ansible.platform and hashicorp.vault for a fully governed, credentialed compliance pipeline.
• Organizations should pick a baseline (DISA STIG for regulated environments, CIS Level 1/2 for general hardening) and layer custom policy on top rather than building compliance content from zero.
• As infra.windows_ops matures beyond its announcement, expect the module and role surface to expand — treat early playbooks as a starting framework, not a finished implementation.