Skip to main content
A control turns a technical expectation into a repeatable question. “MDM-enrolled devices report encryption enabled” is one question. “We can recover the encryption key” is another, usually requiring a manual review. Start with the outcome you need, then choose evidence that can actually establish it.

Choose a baseline

Browse the supplied controls and manual checks in eight topic categories.

Create your own

Build a focused control using the editor and a worked example.

Tune client expectations

Understand defaults, typed parameters and client overrides.

Add human judgement

Define review instructions, record evidence and keep assessments current.

​
The parts of a control

A predicate names the observation, such as device_encryption_enabled. The control adds the question: does that observation equal true? See predicates explained if this terminology is new. The control selects subjects and compares their observations with the effective settings. The result is an assessment; carrying out a change is a separate decision.

​
Keep each expectation small

Prefer separate controls for encryption, patching and EDR installation. A broad name such as “device is secure” hides what you have measured and makes failures difficult to explain. Automated controls need usable observations. A missing value is not false, a missing count is not zero, and no matching subjects is not a pass. Read control results before using a score to describe coverage.

​
Try a worked recipe

Control recipes connect editor settings to sample evidence, boundary cases and interpretation limits. Start with encryption or a configurable vulnerability threshold.

​
Choose your next step

Use the custom control walkthrough for a simple condition, advanced definitions for filtered populations, and testing and rollout before enabling a new expectation across clients.