Compliance checks every managed device against your policies on every sync, and shows you the ones that fall out of line. You decide which device states count as a violation, which devices are exempt, and whether a violation opens a ticket. Nothing to scan, nothing to acknowledge.
Overview
Compliance answers three questions:
- Are the devices still in line with our policies? Is the disk encrypted, is the operating system current, is the antivirus running, is the device still enrolled and reachable?
- Which deviations actually matter? You choose. A state you do not flag is ignored.
- Who deals with it? You choose which issues open a ticket, and whether ONE works those tickets for you.
Every device sync re-runs the rules and refreshes the list. There is no scan to launch and no issue to tick off.
The two screens
It sits in two places, and knowing which is which saves a lot of clicking:
Go to |
For |
|---|---|
Compliance > Compliance issues |
The live list of devices currently violating your policies — your daily triage queue |
Compliance > Compliance issue settings |
Which states count as a violation, which devices are exempt, how long to wait |
A device only shows up in the list if its current state matches one you flagged and it is not covered by an exception. Change a setting and the list follows on the next sync.
The words you need
Term |
What it means |
|---|---|
Issue type |
A category that gets audited. Enrollment Status and Online Status apply to every device. Every other type (encryption, OS updates, password policy, firewall, Wi-Fi, antivirus, admin accounts and so on) is tied to a control, and stays read-only until you deploy that control. |
Status |
A value within a type: Encrypted, Not encrypted, Up to date, Offline 7+ days. |
Rule |
What each status does: nothing, raise an issue, or raise an issue and open a ticket. |
Exception |
A kind of device skipped entirely, such as unassigned devices or stock. |
Grace period |
How long a state has to last before it counts. It stops a device that is mid-encryption from raising an alarm. |
Issue |
A device currently reporting a state you flagged |
| Ticket | Opened for one issue. A device with five issues carries five tickets. |
| Auto remediation | ONE working those tickets under a policy you write. |
How an issue appears and disappears
- The device syncs. Every rule runs against it again.
- Each rule returns a state. Encrypted for the encryption rule, Offline 7+ days for the online rule.
- The state is compared to your rules. If you flagged it, the device gets an issue. If not, it counts as compliant.
- The issue clears itself. Encryption finishes, the operating system updates, the laptop comes back online — the issue disappears on the next sync.
There is no acknowledge, no snooze and no close. That is deliberate: the list always reflects the fleet as it is right now, not what somebody remembered to tick.
How to use
Work the list
Go to Compliance > Compliance issues. Newest first, refreshed on every sync.
| Column | What it tells you |
| Status | The state the device reported |
| Control name | The control or rule that raised it |
| Type | The category: encryption, OS update, antivirus… |
| Device name | The device affected |
| Date | When it was last evaluated |
Filter by device or type, hide columns you do not use, and save the view. Sorting and grouping are not available on this table.
Click any row to open the device panel: see how that device stands against every rule, jump to the control behind it, or act on the device directly — push the profile, lock it, wipe it. A needs attention marker follows the device everywhere it appears.
How to use — turn issues into tickets
Set a status to Create Issue and Ticket and a ticket opens for every device reporting it.
- The ticket arrives translated, tagged Compliance, with the device attached and its owner as requester, using your ticket defaults.
- Switching a status on backfills the devices already affected. Expect a batch the first time. Pick a quiet moment.
- You can also raise a ticket by hand from a single row, even for a status you never configured for ticketing.
- When the device reports compliant again, the issue goes and the ticket closes on its own.
- Tickets are reconciled on every computation, so an outage delays one by a sync cycle rather than losing it.
With auto remediation on, each new compliance ticket goes to ONE, which diagnoses it, pushes the fix when there is one, and hands back whatever only a person can decide. With it off, the tickets stay with your team.
Platform coverage and permissions
Compliance covers macOS, Windows, Linux, iOS, iPadOS and Android. Each rule only returns something meaningful where the underlying control runs: FileVault is macOS, BitLocker is Windows, the antivirus checks are desktop only.
Action |
Permission |
|---|---|
| View issues, settings and the remediation policy | MDM_READ |
| Edit settings, ticket defaults and the policy | MDM_WRITE |
Tips and best practices
- Start with everything set to raise an issue and nothing set to ticket. Watch the list for a week. You will learn what your fleet actually looks like before you commit anyone to working a queue.
- Turn ticketing on one status at a time. The backfill is the surprise: flip three statuses at once on a 500-device fleet and somebody's Monday disappears.
- Use the grace period instead of lowering your standards. Most false alarms are states that would have fixed themselves in an hour.
- Put stock and unassigned devices in exceptions on day one. A laptop in a cupboard is not a compliance problem, and it drowns the ones that are.
- Do not look for a close button. If an issue bothers you and the device is fine, the rule is wrong, not the device.
Troubleshooting and FAQ
Troubleshooting
- An issue type is greyed out. The control behind it is not deployed. Deploy the control and the type becomes configurable.
- A device you fixed still shows an issue. It has not synced yet. The list only moves when the device checks in.
- Hundreds of tickets appeared at once. A status was switched to ticketing and the existing devices were backfilled. Expected, and it only happens on the first change.
-
A device never appears even though you know it is non-compliant. Check the exceptions first: unassigned and in-stock devices are skipped entirely.
FAQ
-
Do we have to run a scan?
No. Evaluation happens on every device sync.
-
Can we close an issue we have decided to live with?
Not on the issue. Change the rule so that state no longer raises one.
-
How many tickets can one device generate?
One per issue. Five issues, five tickets.
-
What happens to the ticket when the device recovers?
It closes by itself on the next computation.