Machine compliance

Compliance checks the security configuration of every machine running the TechWatchAlert agent: accounts and passwords, SSH, firewall, logging, disk encryption, unneeded services, system protections… Each machine gets a score out of 100 and a grade from A to E, and for every point that is not right, the screen tells you what was found, why it matters and how to fix it.

Note

The agent only reads the configuration: it changes nothing on the machine. Fixes are suggested, never applied.

What is checked

Covered systems

Family	Versions
Red Hat Enterprise Linux and derivatives (Rocky Linux, AlmaLinux, Oracle Linux, CentOS Stream)	8, 9, 10
Debian	11, 12
Ubuntu	20.04, 22.04, 24.04
Windows	10, 11
Windows Server	2016, 2019, 2022, 2025
macOS	13, 14, 15, 26

On a system that is not in this list, the machine’s Compliance tab says so; nothing is graded.

Rules

Each system has its own set of rules, grouped into sections: accounts and passwords, authentication (lockout, sudo), SSH, network, firewall, logging, system auditing, file systems (partitions, mount options, permissions), services, kernel, boot (boot loader, Secure Boot), updates, encryption, remote access (RDP, sharing), session and desktop (screen lock), system protection (antivirus, SELinux, AppArmor, SIP, Gatekeeper) and time synchronisation.

A rule has a severity (critical, high, medium, low), a level (1 or 2) and targets a profile:

• server or workstation: the profile comes from the environment set in the machine’s business context (Workstation → workstation; production, pre-production, test, development → server), otherwise from the system edition (Windows Server → server; Windows client and macOS → workstation). A Linux machine with no indication takes the default profile from the settings.
• Level 1 — baseline: the essential settings, with no noticeable effect on use. It is the default level, recommended for every machine.
• Level 2 — hardened: adds stricter checks (defence in depth) that may get in the way of some uses. For sensitive machines.

A rule may not apply to a machine (a service that is not installed, a feature missing from that version): it is then not applicable and does not count.

When

• Automatically: the first audit starts at the first check-in of an agent running version 1.2 or later, then every 24 hours, and again as soon as the rules or the settings change.
• On demand: Run the audit again on the machine’s page (Analyst role or above). The agent picks it up at its next check-in, usually within a minute; an audit takes a few seconds.

An agent older than 1.2 is not audited: update it (see Agent updates).

Reading the score and grade

Each evaluated rule is compliant or non-compliant. The score is the share of compliant rules, weighted by severity:

Severity	Weight
Critical	10
High	5
Medium	3
Low	1

Score = 100 × weight of compliant rules ÷ weight of compliant and non-compliant rules, rounded to the nearest integer. A non-compliant critical rule therefore weighs ten times as much as a low one. Not counted: not applicable rules, rules in error (the check could not be performed, for example a tool missing from the machine) and rules set as exceptions.

Grade	Score
A	90 and above
B	80 to 89
C	70 to 79
D	50 to 69
E	below 50

Each section also has its own score, computed the same way: it shows where to focus the effort.

A drop of 10 points or more from one audit to the next is recorded in the machine’s History.

The machine’s Compliance tab

On a machine’s page, the Compliance tab shows:

• the score and grade, the date of the latest audit, the system, the profile and the level;
• the counters: non-compliant, compliant, not applicable, errors, exceptions (a click filters the list);
• Run the audit again; when it is not possible, the reason is written next to it (no agent, agent too old, system not covered, audit already in progress, insufficient role);
• the score by section: a click on a section filters the list;
• the list of rules, one line per rule: severity, title, section, CIS reference, status. Non-compliant rules come first, from the most to the least severe, then errors, compliant, not applicable and exceptions. Filters: status, severity, section, and search (title, finding, reference).

A click on a rule opens its details:

• What was found: what the agent observed on the machine (for example PermitRootLogin yes), with no secret at all (never a password nor a password hash);
• Why it matters;
• How to fix it: the steps, the commands to copy one by one or all at once, and for Windows the Group Policy path;
• the possible impact of the fix, when there is one;
• the references: CIS recommendation numbers per system version, DISA STIG identifiers, NIST SP 800-53, CIS Controls v8.

After a fix, Run the audit again updates the score without waiting for the next run.

Exceptions

A rule may not suit a machine: an internal router has to forward packets, a legacy protocol is still needed during a migration. Set as exception (in the rule details) leaves it out of the score, without erasing the measured result, which stays visible.

1. Open the rule and choose Set as exception.
2. Enter the reason (required): the compensating control, the business need or the accepted risk.
3. Choose the scope: this machine, or the whole organisation (every machine in all of its projects).
4. Optionally, an expiry date: from that date, the rule counts in the score again.

The author and date of each exception are kept. Remove the exception puts the rule back into the score, with its latest result. The list of all exceptions, in force or expired, is in Fleet › Compliance › Exceptions.

The Fleet › Compliance view

Fleet › Compliance brings the whole fleet together:

• the key figures: average score, grade distribution from A to E, audited machines, machines not audited (including those whose agent needs updating);
• the most failed rules: the rules that fail on the most machines, what to fix first;
• By rule: for each rule, the number of failing, in error, compliant and excepted machines, filterable by section, severity and system. A click opens the rule with the list of failing machines and their finding; an exception for the whole organisation can be set from there;
• By machine: score, grade, non-compliant rules, date of the latest audit and agent version; a click opens the machine’s Compliance tab;
• Exceptions: every exception, its scope, reason and expiry;
• Settings: level 1 or 2, default profile for Linux machines.

The Fleet list also has a sortable Compliance column (score and grade): least compliant machines first.

Export (CSV) downloads one line per machine and per rule of the latest audit: machine, platform, score, grade, audit date, rule, title, section, severity, status, finding, CIS reference.

Permissions

Action	Role
View compliance, export	Any project member
Run the audit again	Analyst or above
Exception on one machine	Project admin
Exception for the whole organisation, settings (level, profile)	Project admin and organisation administrator

Settings and organisation-wide exceptions apply to every project in the organisation (for a personal project: to that project).

Security and privacy

• The agent reads configuration files, system settings and the output of a few read-only commands known in advance; it runs no free-form command and changes no setting.
• The list of rules to check reaches it in a task signed by TechWatchAlert, like all of its orders.
• What is sent back is the status of each rule and a short finding, with no secret.

CIS and STIG references

The rules are written by TechWatchAlert from open sources: DISA STIG guides, the ComplianceAsCode and macOS Security Compliance Project projects, Microsoft security baselines. When these sources give it, a rule quotes the matching CIS recommendation number (for example “CIS reference 5.1.20” for RHEL 9), to link it with a CIS Benchmark your organisation may already use. These references are given for information only: TechWatchAlert is not affiliated with the Center for Internet Security, and compliance is not a certification.