Compliance

The Compliance section measures your fleet against industry-standard security baselines. TridentStack Control supports multiple compliance frameworks and provides per-agent and per-control scoring.

Supported Frameworks

TridentStack Control includes built-in support for the following compliance frameworks:

DISA STIG

The Defense Information Systems Agency publishes Security Technical Implementation Guides. STIGs are mandatory for U.S. Department of Defense systems and widely used in government and defense contracting. TridentStack Control evaluates a platform-specific STIG on each agent automatically as it checks in:

Platform	Benchmark
Windows	DISA STIG for Windows 10, Windows 11, and Windows Server 2016 through 2025
macOS	DISA STIG for macOS
Ubuntu	DISA STIG for Ubuntu 20.04, 22.04, and 24.04 LTS
RHEL	DISA STIG for RHEL 8 and RHEL 9

Compliance scoring does not cover Debian or Rocky Linux. Those endpoints are still patched and still report vulnerabilities; they have no compliance framework to score against.

Microsoft Security Baselines

Microsoft's recommended security configurations for Windows operating systems. These baselines represent Microsoft's own guidance for hardening Windows, updated with each major OS release.

NIST SP 800-53 (control mapping)

TridentStack Control does not ship a NIST baseline you can scan against. Instead, DISA STIG controls carry CCI references, and TridentStack Control resolves those to NIST 800-53 controls when it builds a report, so a passing or failing STIG control can be traced back to the 800-53 control it supports. NIST 800-53 is the National Institute of Standards and Technology's catalog of security and privacy controls, referenced by FedRAMP, FISMA, and many private-sector compliance programs. Reports are labelled as STIG results mapped to NIST 800-53, because the scoring is done against the STIG, not against NIST directly.

Navigating the Compliance Page

The Compliance page is organized into five tabs, each providing a different angle on your compliance posture.

Overview

The fleet-wide compliance dashboard. This tab shows:

• Overall compliance score: An aggregate score across all active baselines and agents
• Framework-by-framework breakdown: How your fleet scores against each active baseline
• Trend charts: Compliance improvement (or regression) over time

Per-Agent

Each agent's compliance score across all active baselines. This tab answers the question: "How compliant is this specific machine?"

Click any agent to drill into its detailed results, showing which controls pass and which fail for each assigned baseline.

By Framework

Detailed compliance results organized by framework. Select a framework to see the pass/fail status for every control it contains.

This view is useful when preparing for an audit against a specific standard, as it shows your exact posture against every control in the framework.

By Category

Compliance results grouped by control category, such as:

• Account Policies
• Audit Policies
• Security Options
• User Rights Assignment
• Windows Firewall

This view is useful for identifying systemic gaps. For example, if most of your agents fail controls in the "Audit Policies" category, you know to focus your remediation efforts on audit configuration.

Baselines

Manage which compliance baselines are active and which agents they target. This is where you deploy new baselines and adjust targeting.

Deploying a Baseline

To start measuring compliance against a framework:

1. Navigate to Security > Compliance > Baselines.
2. Select the framework you want to deploy (for example, the DISA STIG for Windows 11 on your workstations, the DISA STIG for macOS on your Macs, or the DISA STIG for Ubuntu 22.04 LTS on your Linux servers).
3. Assign the baseline to one or more agent tags.
4. Choose the assessment scope for each assignment. Level 1 scores the framework's highest-severity controls only, Level 2 adds the medium-severity controls on top of Level 1, and Level 3 (the default) is the full benchmark. Each level includes the ones below it. For DISA STIG baselines the levels follow DISA's own severity categories: CAT I is Level 1, CAT II is Level 2, and CAT III is Level 3.
5. Click Save.

Compliance evaluation begins on the next agent check-in. Results will appear in the other tabs as agents report their configuration state.

info

Compliance evaluation runs automatically during agent check-ins. No manual scans are needed. If an endpoint stops checking in, its scores stop updating; the freshness indicators described below flag this.

Compliance Scoring

Each agent receives a compliance percentage per baseline. For example, an agent might show:

Baseline	Score	Passing	Failing	Not Applicable
DISA STIG Windows 11	87%	174	26	12
Microsoft Baseline	92%	138	12	5

The score is calculated as:

Compliance % = (Passing Controls / Total Applicable Controls) x 100

Controls that are not applicable to an agent (e.g., a BitLocker control on a machine without a TPM) are excluded from the calculation entirely. This prevents non-applicable controls from artificially lowering scores.

Data freshness and coverage

Compliance scores reflect the most recent data reported by each endpoint. When an endpoint is offline, its last known score remains visible rather than disappearing, and TridentStack Control discloses how current the underlying data is.

• The Overview tab shows how many endpoints have current data. The default freshness window is 7 days.
• The Per-Agent tab flags each endpoint whose data is stale, whose data basis is unknown, or that has not been fully evaluated for every assigned framework.
• Each endpoint's compliance tab shows "Data as of" (when the evaluated data was collected), "Last evaluated" (when scoring last ran), and how many controls were evaluated out of the total.
• PDF reports include the same coverage and freshness statements, so a report you hand to an auditor states the basis of every number it contains.

Controls that cannot be evaluated, for example when a check encounters an error, are excluded from the score and counted separately. A score is never silently computed from partial data without the coverage counts saying so.

Investigating Failures

When an agent fails a compliance control, you need to understand what is wrong and how to fix it. Click any failing control to see:

• Control description: What the control requires and why it matters
• Expected configuration: The value or state the control expects to find
• Actual configuration: What was found on the agent
• Remediation steps: How to bring the agent into compliance

For example, a failing "Minimum password length" control might show:

Field	Value
Expected	Minimum 14 characters
Actual	8 characters
Remediation	Set the "Minimum password length" policy to 14 or greater

Remediation with Configuration Policies

Many compliance failures can be remediated by deploying configuration policies. When a compliance control maps to an ADMX policy setting, the control detail page includes a direct link to the relevant setting.

The recommended workflow:

1. Identify failing controls in the By Category or Per-Agent view.
2. Click into a failing control to see the remediation guidance.
3. If the control links to an ADMX setting, navigate to Orchestration > Configuration Policies.
4. Create or update a policy to configure that setting with the expected value.
5. Assign the policy to the appropriate agent tags.
6. On the next check-in, the agent applies the setting and the compliance score updates.

tip

Start with the DISA STIG that matches your primary Windows build. Review the highest-severity findings first: they carry the largest risk reduction and are the ones an auditor asks about.

Best Practices

• Baseline before remediating. Deploy a baseline and measure your current posture before making changes. This gives you a clear before/after comparison.
• Prioritize by category. Use the By Category tab to find systemic issues that affect many agents, rather than fixing controls one agent at a time.
• Track trends. The Overview trend charts show whether your compliance posture is improving. Share these with stakeholders to demonstrate progress.
• Document exceptions. If a control cannot be met due to business requirements, document the reason and any compensating controls in place.
• Review after OS updates. Major OS updates can change default settings. Re-evaluate compliance after deploying feature or version updates to catch any regressions.