EndpointOps

Compliance Assessment

Learn how to author compliance rules with audit and remediation logic, test them live, bundle them into a framework mapped to a standard like CIS or GDPR, deploy it to endpoints, and read per-rule results - including what an INVALID result means versus a genuine failure.

2 min
June 25, 2026

What You'll Learn

How to author a compliance rule with separate audit and remediation logic
Use the built-in AI command generator to draft a rule's script
Live-test a rule against a real endpoint before it ships
Build a framework from your own rules or the built-in benchmark library
Deploy a framework to endpoints and read per-rule, per-endpoint results
Tell an INVALID result apart from a genuine FAILED result

Frequently Asked Questions

What's the difference between Invalid and Failed?

Failed means the audit script ran and the check simply didn't meet the expected condition. Invalid means the audit script couldn't produce a determinate result at all, often due to an OS mismatch, a missing dependency, or a binding error. Invalid is a rule or deployment problem to fix, not a posture finding. The [how to build and run compliance assessments](/learn/compliance/how-to-build-and-run-compliance-assessments) guide covers how to isolate the cause.

Should I trust the AI-generated command as-is?

No. Treat it as a first draft. Review the generated script fully and live-test it against a real endpoint before it becomes part of a framework used in production deployments.

Can I build a framework entirely from the built-in library?

Yes. CIS, GDPR, and other standard mappings ship pre-built for common Windows and Linux versions, ready to deploy as-is or combined with your own custom rules in a single framework.

Does a low pass rate always mean the endpoint is non-compliant?

Not necessarily. If most of the failing count is Invalid rather than Failed, the low percentage is more likely pointing to a rule or binding mismatch than the endpoint's actual security posture.

Does remediation run automatically on a failed rule?

Only if the rule has a remediation script attached and the deployment policy is configured to apply it. A rule without remediation logic just reports the failure, and someone still has to act on it manually.

How do I know if my remediation actually worked?

Re-run the deployment against the same scope and framework and compare the new evaluation to the previous one, rule by rule. A single snapshot never confirms a fix on its own.