Compliance Rules and What Happens When They Fail

Compliance here means a device meets stated conditions. What follows when it does not is the part that determines whether the mechanism helps or just generates tickets.

The same discipline applies when “Compliance Rules and What Happens When They Fail” becomes part of a broader workforce programme. An organisation considering workforce analytics software in relation to workforce analytics software should put access, retention, employee notice and review dates into the implementation plan rather than leave them as product defaults.

What is worth checking

Encryption on.

For an independent baseline relevant to “Compliance Rules and What Happens When They Fail”, the NIST Cybersecurity Framework is a useful companion: compare its principles with the proposed configuration, ownership model and real support process before approving a rollout.

Passcode set, meeting the policy.

Operating system at or above the minimum.

Not jailbroken or rooted.

Management profile present and current.

Five conditions. Longer lists produce failures that nobody acts on.

What is not worth checking

Anything the user cannot fix themselves.

Anything whose failure you would not act on.

Conditions that fluctuate — a device temporarily out of contact is not non-compliant, it is off.

Each of those generates noise and teaches people to ignore the status.

The consequence

Access to work data blocked until resolved is the standard answer, and it works because it is proportionate and self-resolving.

Not: a wipe.

Not: a message to their manager.

The device stops being able to reach work data, and starts again when fixed.

The grace period

Immediate blocking on first failure produces a help desk queue and resentment, because many failures are transient or trivially fixable.

A grace period — a day or three, depending on the condition — with clear messaging, resolves most without any contact.

Jailbreak detection is the exception: no grace, because the condition is not accidental.

The message

It should say what is wrong, what to do, and what happens if it is not done.

"Your device is non-compliant" is not a message; it is a status.

People fix things they understand, and most compliance failures are a passcode setting or a pending update.

Watching the aggregate

Compliance rate across the estate, by condition.

A single condition failing widely usually means the policy is wrong rather than everybody is careless — an unreasonable passcode requirement, a minimum version nobody can reach.

Which is a finding about your policy, and it is visible only if you look at the breakdown.

The devices that never comply

Every estate has them: an old device, an exception, somebody who disabled something.

They sit permanently red and everybody stops noticing the colour.

Resolve or except them explicitly, because a permanently failing check devalues every other one.

What to check

How many compliance conditions do you check, and would you act on each?

Is there a grace period, and how long?

Does your non-compliance message say what to do?

And how many devices have been non-compliant for more than a month?