Overview
Compliance responde a dos preguntas:
- Are my 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 online?
- Which deviations should raise an issue? You choose. Anything you do not flag is ignored.
Every time a device syncs it is re-evaluated and the issues list updates. There is no scan to launch and no issue to acknowledge by hand.
Where compliance lives
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 |
Choosing which statuses, per issue type, count as a violation |
A device appears in the issues list only if its status matches one you set to raise an issue and the device is not covered by an exception.
The six terms worth knowing
Term |
What it means |
|---|---|
Issue type |
A category that gets audited. Enrolment Status and Online Status are global. Every other type is tied to an MDM control and stays read-only until that control is deployed |
Status |
A value such as Encrypted, Not encrypted, Up to date, Offline 7+ days |
Issue rule |
What each status does: nothing, raise an issue, or raise an issue and open a ticket |
Exception |
A category of device compliance skips entirely — unassigned devices, or devices held in stock |
Grace period |
How long a status still being applied must persist before it raises an issue |
Compliance issue |
A device currently reporting a status you flagged |
How to use
How an issue appears and clears
- The device syncs. Every rule is re-run against it.
- A status is computed per rule — Encrypted for encryption, Offline 7+ days for online status.
- The status is compared to your rules. If it is flagged, the device gets an issue.
- The issue clears by itself when the status improves. There is no acknowledge or snooze.
Platform coverage
Every managed platform: macOS, Windows, Linux, iOS, iPadOS and Android. Each rule only returns meaningful results where the underlying control runs — FileVault on macOS, BitLocker on Windows, endpoint protection on desktops.
Permissions
Action |
Permission |
|---|---|
View issues and settings |
MDM_READ |
Change settings |
MDM_WRITE |
Tips and Best Practices
- Configure the settings before you judge the feature. Until you flag statuses the list stays empty — data is collected, nothing is raised.
- Start with the two global issue types. Enrolment Status and Online Status work on day one without any MDM control deployed.
- Turn on the exceptions early if you hold stock. Devices in a warehouse are supposed to be offline and unencrypted, and without an exception they fill your queue with noise.
- Do not flag every status you can. A list nobody triages is worse than no list.
Troubleshooting and FAQ
Troubleshooting
- The issues list is empty although devices are clearly non-compliant. No statuses are flagged yet. Data is collected regardless — configure them in Compliance issue settings.
- An issue type is visible but not editable. It is tied to an MDM control that has not been deployed. It stays read-only, deliberately, so you can see what compliance could watch before deciding to deploy it.
- A device you expected is missing from the list. Check the exceptions. An unassigned device, or one held in stock, is skipped entirely — no issue, no ticket, no remediation.
FAQ
-
Do we have to acknowledge or close issues?
No. They clear automatically when the device's status improves.
-
Why do some issue types apply to every device and others do not?
Enrolment Status and Online Status are global. Everything else needs its MDM control deployed first.
-
Does an exempt device stop being monitored?
No. Its real state is still computed and shown on the device page. Only the issues list, the counts and the tickets ignore it.