CIS compliance check for Windows: measure before enforcing

Objective: check CIS compliance without stopping users

CIS Benchmarks are a clear set of recommendations for configuring Windows: which policies, services and security options should be enabled to reduce the risk of breaches and mistakes. This is not a "magic button" but a list of concrete settings you can measure and compare against a baseline.

Problems usually start when CIS is attempted to be "enabled everywhere at once." Abruptly tightening policies breaks usual processes: applications stop launching for users, administrators lose RDP access, services fail to start after reboot, and support receives a flood of tickets. Even a logically correct setting may be unsuitable for you if you have legacy applications, special accounts or nonstandard login scenarios.

Failures most often happen in several areas:

• passwords and lockouts (complexity, expiration, login attempts, account lockout);
• UAC and privileges (elevation, driver and software installation, local admin restrictions);
• firewall (closing needed ports, blocking internal services, remote management);
• encryption (BitLocker, TPM requirements, recovery key handling, maintenance compatibility);
• RDP and remote access (NLA, prohibitions, protocol and cipher restrictions).

A more reasonable goal is to see the facts first, not to change rules. The “measure-only” strategy means you collect the current state, compare it to CIS, note deviations and their possible impact on users. Only then — with agreed exceptions and a pilot — do you move to enforcement. This order is almost always cheaper: fewer outages, fewer emergency rollbacks and fewer conflicts between IT and security.

Before you start: scope and basic agreement

To prevent a CIS check from turning into meeting disputes and sudden workstation failures, agree first on boundaries and rules. This takes one to two hours but saves weeks of follow-ups.

Start with inventory: which Windows versions you will actually check (Windows 10, Windows 11, Windows Server), and what server roles exist (domain controller, file server, RDS, SQL, etc.). CIS recommendations depend on role, so a “one checklist for all” almost always gives wrong conclusions.

Next, choose the CIS profile. Level 1 is usually suitable as a basic secure minimum with moderate user impact. Level 2 more often requires strict restrictions and is better introduced after a pilot. Record a simple justification for the choice so it won't be changed later by a new process owner.

Also define exactly what you will measure. In practice some settings live in GPOs, some in local policies, some in the registry, services and security parameters. If you don't define this up front, the report becomes "unusable": it will be unclear where a setting originates and who can change it.

A short kickoff checklist is useful:

• Which OS versions and server roles are included and which are excluded (with reasons).
• Which CIS profile is chosen (Level 1 or Level 2) and why.
• Which sources of settings are checked: GPO, local policies, registry, services.
• Which critical applications, departments and user groups must not be broken (cash desks, call center, accounting, healthcare, classrooms).
• How often to take measurements and in what window (once for baseline, then weekly or monthly for trend).

One last point to state aloud: at this stage you only measure and document deviations. No changes, not even "small tweaks," until business owners and IT confirm the risk and an implementation plan.

The “measure-only” strategy: how to run a safe audit

The idea is simple: log reality first, then decide what to change. In measure-only mode all actions should be read-only: collect parameters, export settings, compare with the benchmark. No new GPOs, MDM profiles, registry-changing scripts, or quick fixes during the audit.

It helps to break the measurement into layers so you don't confuse setting sources and draw false conclusions:

• local machine (local policies, local rights, services);
• domain (GPOs and application order);
• MDM/Intune (profiles, configurations, compliance policies);
• scripts and agents (logon scripts, EDR, hardening agents);
• manual exceptions (changes admins made outside centralized policies).

For each requirement use statuses so the report is honest: compliant, non-compliant, not applicable, unknown. The "unknown" status is important: it usually means lack of access to data, missing telemetry or conflicting sources.

Next, take a baseline snapshot: date, CIS Benchmarks version for your Windows editions, list of checked hosts, data source (GPO, local, MDM), who ran the check and with which privileges. This is the basis for repeat checks and for disputes like "it was always like that."

Agree up front on thresholds: which findings during measurement are red flags and require action even without enforcement. For example: disabled login auditing, no lock-screen on shared PCs, weak admin account parameters. This keeps the audit meaningful without turning it into a formality.

Example: in a branch where accounting uses shared terminals, first record current lock timeouts and local admin rights, note risks, and plan a pilot with agreed exceptions.

Tools: what to use to measure CIS on Windows in practice

You usually need a set of sources to assess CIS compliance. One tool rarely sees everything: some settings live in local policies, some come from the domain, and some depend on Windows version and server role.

What to check on the Windows hosts

On hosts measure what is actually applied, not what "should have been" applied. Start with local policies and security options, service states, User Rights Assignment, audit and logging settings. Also record OS version, installed roles and parameters like UAC, RDP, SMB — many CIS recommendations depend on context.

Domain layer: GPO, inheritance and conflicts

Many corporate deviations are explained by GPOs. Measure not only the effective value on the PC but also the source: which policy set it, whether inheritance is blocked, WMI filters, security filtering, and conflicting higher-priority GPOs. Otherwise the report will be "correct" but won't help remove the root cause.

A practical toolset usually includes:

• Microsoft Security Compliance Toolkit — helpful for templates, baseline values and comparisons.
• RSOP and gpresult — to see what actually applied and where it came from.
• Local policy and security checks (including audit policy and event logs) — to catch divergences on specific machines.
• PowerShell scripts — quickly cover dozens of hosts but need validation: different OS editions, localization, GPO overrides and nuances like "Not Configured" vs "Disabled" often cause false positives.
• Commercial scanners and SIEMs — good at collecting facts (events, configurations, vulnerabilities) but not always accurate in interpreting GPO nuances and CIS; validate results with spot checks.

A simple example: a scanner reports "non-compliant" for auditing, but in reality a GPO sets the required values while a terminal server group has an exception for an old application. Without source mapping you'll create needless incidents and user frustration.

Step by step: run the check without making changes

The rule of measure-only is simple: collect facts, change nothing. Even "harmless" edits in a GPO or local policy can unexpectedly affect logons, mapped drives or legacy applications.

First, document what you will check. It's convenient to prepare a device list and group them so results are comparable: pilot (a few typical workstations), main office, remote sites, and a separate server group.

Then proceed:

1. Take an inventory snapshot: Windows versions, server roles, presence of important apps (accounting, medical systems, bank clients), and owner for each group.

2. Run the read-only check: collect security parameters and configurations without making changes.

3. Consolidate results into a single format for filtering and group comparisons (table, CSV or JSON). Each row should contain: computer, parameter, current value, expected value, source.

4. Verify setting sources: what is local, what came from GPO, and what is overridden. A common trap: a policy looks correct in one GPO but a lower-priority exception or misapplied OU causes the wrong value.

5. Mark “risky for users” items with a flag. These are settings that often affect compatibility: password and lockout rules, SMB and network access, Office macros and zones, PowerShell restrictions, update policies, firewall rules.

After the first pass, schedule a repeat. Preferably two: one on a normal workday and another after planned updates or reboots. If values "jump," an unstable source (logon script, MDM, different GPOs for laptops and desktops) exists. At this stage agree what can go to pilot testing and what needs application owner discussion first.

Report format: readable by IT, security and the business

A good CIS compliance report should answer three questions: how close are we to requirements, where are deviations, and what to do next without risking work stoppage.

Structure that people will actually read

Start with a one-page summary for executives and process owners. It helps quickly align priorities and not drown in detail.

• Overall picture: compliance percentage by chosen profile (by role or device groups).
• Top 5 critical deviations with a short risk explanation.
• What is affected: number of devices, departments or workstation types.
• Trend: comparison with the previous check (if repeated measurement).
• Decision required: what goes to work now, what moves to testing.

After the summary provide a deviation map: a matrix with settings as rows and device groups (office PCs, laptops, terminals, servers) as columns. This shows at a glance which issues are isolated and which are systemic.

Setting card: the minimum required

The detailed part is convenient as repeating cards for each setting so IT can reproduce the measurement and security can defend priorities.

• Current state: the current value and where it occurs.
• Target state: the CIS target value (exact wording).
• Source: local, via GPO, via MDM or mixed.
• Risk and impact: security, user convenience, application compatibility.
• Recommendation: keep, fix, postpone, needs testing.

To avoid arguments, add a short “why” note. For example, enabling SMB signing improves protection but may break old file services or some scanner models. Record it as "fix after pilot" with a clear owner and deadline.

Finally, maintain a separate exceptions table. Don’t hide exceptions in text — show who approved them, for how long and how they are compensated (segmentation, enhanced monitoring).

How to interpret results: prioritize without panic

Don’t try to “fix all red” at once. CIS highlights not only risks but differences from your operational model. The goal now is to understand what matters, what can be safely fixed quickly, and what needs business-level decisions.

Group deviations by themes to see recurring problems and where one action fixes many items: accounts and passwords, rights and UAC, network and remote access, logging and audit, cryptography and TLS, updates and protection.

Quick wins and cautious items

Quick wins usually have noticeable effect and minimal user impact: enable needed audit categories, increase log sizes, disable obsolete protocols on servers where they’re not used, tidy local admin groups.

Mark items that almost always require caveats. Typical examples: strict lock-screen timeouts on shared stations, restrictions affecting accounting and digital signatures, disabling old ciphers on servers that have legacy integrations. These aren’t bad settings, but without testing and agreement they can stop business processes.

Who decides and what the backlog looks like

Each deviation needs a decision owner: security sets acceptable risk, IT implements and supports, service owner confirms compatibility, department manager approves workflow changes.

Create a change backlog with simple fields:

• what to change (setting and where applied);
• expected effect and user risk;
• dependencies (app update, protocol migration);
• priority (P1-P3) and deadline;
• owner and verification criteria after deployment.

Example: weak logging on terminal servers and outdated TLS on an internal web service. The first can be P1 and enabled quickly. The second is P2 with a dependency: confirm clients and plan tests, otherwise you risk cutting off access for some users.

Common mistakes that most often break user workflows

The most frequent cause of failures is not a strict CIS, but speed and lack of boundaries. When a team measures and immediately enforces, problems appear as blocked logons, app errors and update failures.

Mistake 1: enabling Level 2 without a pilot and exceptions

Level 2 often brings tighter restrictions. Without a pilot you won’t know which groups suffer: accounting, call center, dev, terminal users. You need an exceptions list beforehand, otherwise “same for everyone” turns into downtime.

Mistake 2: mixing workstation and server profiles

Server and workstation policies may look similar but live in different scenarios. What’s fine for a rack in a datacenter can break remote work, printing or legacy clients on PCs.

Check areas that often break: login and lockout parameters, macro and script restrictions (including PowerShell), SMB/NTLM and signing requirements, firewall rules for corporate apps, RDP and network-level authentication.

Mistake 3: confusing “not applicable” with “non-compliant”

If a setting doesn’t apply to a role or Windows version, it can’t be counted as a failure. Otherwise the report balloons and real risks drown in noise. This is especially visible in environments with mixed images and roles.

Mistake 4: ignoring GPO conflicts

Conflicts and application order produce unpredictable effects: you enabled one thing but another setting is effective. Before drawing conclusions record which policy actually won and where it came from.

Mistake 5: enabling auditing without capacity planning

Extended auditing can quickly fill disks or overload log collection. Example: a public sector organization enabled detailed login auditing on hundreds of PCs and a few servers, and after a week logs and collectors were overwhelmed.

A minimal safeguard before expanding logs:

• estimate event volume on a pilot group;
• set log size limits and overwrite policy;
• check disk space and log delivery speed.

Preflight checks before switching to enforcement

Before enabling enforcement run a short preflight checklist. It takes hours and saves days of troubleshooting after someone’s VPN or printing stops working.

First, record which CIS profile you will use for each device group. Servers, workstations, terminal hosts and kiosks usually have different requirements. Without an approved profile you’ll argue about interpretations instead of facts.

Then ensure you have a baseline and know the source of each setting: local policy, GPO, MDM or script. Otherwise you may “fix” a parameter in one place only for it to return from another source an hour later.

Check five things before the first change:

• Approved CIS profile for each group (and benchmark version recorded).
• Baseline collected on representative PCs and servers, with source for each setting noted (local, GPO, MDM).
• Top-10 critical deviations listed and an owner assigned to each (security, AD team, app owner).
• A pilot group (10–30 users or 1–2 departments) and a clear rollback plan for each change.
• Impact metrics defined: support request increase, login failures, app errors, printing issues, performance drops.

Also ground the report: for each critical deviation provide not only status (pass/fail) but a decision — accept risk, mitigate, or fix — plus deadline and responsible person.

Example: before strengthening lock-screen and macro restrictions for accounting, collect a week of data: support tickets about logons, 1C/Office errors, how often users were locked out. If metrics spike after change, roll back the specific setting per the prepared plan rather than "rolling everything back."

Example scenario: going from measurement to pilot

Imagine an organization with 300 workstations and 40 servers. Some employees work remotely, and there are several critical systems (accounting, healthcare, terminal farms). The goal is to pass a CIS check without abrupt changes and outages.

Plan for 4 weeks

Week 1: measure-only and baseline collection. Choose the CIS Benchmarks version matching your OS editions and define the object set: workstations, servers, domain controllers, RDP hosts. Run in audit mode: no enforcement GPOs, just facts. Typically you get 15–25 deviations that materially affect risk. In our example — 20 key items.

Record for the pilot use:

• date and coverage (how many PCs/servers checked);
• top deviations by frequency;
• where the setting is defined (local or GPO);
• which departments/systems are affected;
• preliminary user impact assessment.

Week 2: pilot. Choose 20 PCs from different roles (office, accounting, remote, engineering) and 2 non-critical but similar servers. Security and IT pre-agree exceptions (e.g., for accounting and medical systems where stricter authentication or macro blocking may break functionality).

Weeks 3–4: expansion. Increase coverage in waves with short observation windows after each wave. Monitor not only compliance percentages but real effects: support ticket volume, login failures, printing issues, app outages. A good sign is reduced risk without incident spikes.

Finally enable settings that noticeably change user or app behavior:

• macro and script blocking rules;
• SMB/NTLM restrictions and stricter Kerberos policies;
• AppLocker/WDAC and execution control;
• UAC changes, blocking password saving and autofill;
• RDP parameters (NLA, encryption, denying legacy clients).

This keeps changes manageable: measure and agree first, then enable selectively and scale.

Next steps: gently move from audit to enforcement

When the audit is complete don’t enable everything at once. Move to enforcement as a controlled change with clear stages, owners and quick rollback options.

Roadmap for transition

Document a plan understandable to IT, security and process owners. Four stages usually suffice:

• Measurement: capture deviations and collect real user incidents.
• Pilot: apply policies to a small, diverse group (20–50 users).
• Phased rollout: deploy by department, starting with the most resilient groups.
• Control: compare pre/post reports and monitor for rollbacks after Windows updates or GPO edits.

Add readiness criteria for each stage. For example, to move from pilot to rollout require no critical login, printing or network failures; support runbooks in place; and an approved exceptions list.

Operational necessities that prevent failures

Prepare policy templates and an exception process in advance. Otherwise every special role (cashier, nurse, call operator) will need an ad-hoc edit.

Assign owners and define how users get help on change day:

• who receives requests and who can temporarily remove a policy;
• how to request an exception (reason, duration, system owner, risk);
• where the exception list is stored and how often it’s reviewed;
• who publishes a monthly report: what improved, what worsened, what rolled back.

A practical report shows dynamics, not only "compliance percentages." For example: in a month we closed 12 medium deviations, but after an update three firewall settings reverted on some laptops.

If you need external help to move without overloading the team, the system integrator GSE.kz (GSE.kz) can assist with audit, pilot and follow-up support, including 24/7 support and tailoring compatible infrastructure to your organization’s requirements.