Compliance policy

How it works

A policy is a list of checks plus a list of consequences. The checks are read from the device at each check-in: OS version and patch level, passcode strength, storage encryption, jailbreak or root state, presence of a required app, last contact date. Some MDMs also accept external signals, like a risk score from a Mobile Threat Defense agent.

Each check has a threshold you set. iOS 17 or later, for instance, or a six-digit passcode. When every check passes, the device is compliant. When one fails, the device is marked non-compliant and the consequences kick in, usually in stages: a notification to the user first, then a block on managed apps after a grace period of a few days, then a selective wipe if nothing changes.

The grace period is what makes policies livable. Without it, a user who hasn't installed last night's iOS update loses access to their email at 8 a.m. With it, they get three days and a reminder.

Why it matters for a fleet

Compliance policies turn a security standard into something you can measure. A written rule that says "all devices must be encrypted" is an intention. A policy that reports 412 of 420 devices encrypted, and lists the eight that aren't, is evidence. That distinction is what auditors ask for, and it's what NIS2 (directive 2022/2555, article 21) expects you to be able to produce.

They also scale in a way manual checks can't. At 50 devices you can walk around the office. At 500, spread over three countries and two operating systems, you can't. The policy runs the check for you every few hours.

One trade-off to keep in mind: strict policies generate friction. If you require the latest OS within 24 hours of release, you'll block half the fleet every time Apple ships an update. Most teams set the OS threshold one version behind current and tighten it only for a known critical vulnerability.

How Appaloosa handles it

In Appaloosa, you define compliance rules per device group, so field tablets and executive phones don't share the same thresholds. Each rule combines conditions (OS version, passcode, encryption, jailbreak state, required apps, last check-in) with an action: notify, restrict access to managed apps, or wipe the work data. The console shows the compliance state of every device and the reason it fails, which is usually what you need to fix it in one call to the user.

Because compliance is evaluated inside the same mobile device management platform that pushes configurations, a failing device can be corrected directly: push the missing app, force the passcode setting, or trigger the OS update from the same screen.