Policy Drift and Annual Review

Device policy decays through no action of yours: operating systems change, platforms add settings, and the population of devices turns over.

The same discipline applies when “Policy Drift and Annual Review” becomes part of a broader workforce programme. An organisation considering the product page in relation to attendance point system should put access, retention, employee notice and review dates into the implementation plan rather than leave them as product defaults.

What changes underneath

Operating system versions move, and your minimum becomes unreasonable or too lax.

For an independent baseline relevant to “Policy Drift and Annual Review”, 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.

Platforms add and deprecate settings; some of yours stop applying silently.

Device models in the estate change, and profiles written for older hardware no longer fit.

And exceptions accumulate, each granted for a reason nobody recorded.

The settings that stop applying

The quiet failure: a setting deprecated by the platform, still present in your profile, no longer enforced.

The console shows it as applied. The device ignores it.

Check the platform's deprecation notices after each major release, which is twenty minutes and is otherwise never done.

Exceptions

Every programme accumulates them: the device that cannot take the passcode policy, the team exempted from a restriction, the user with an old operating system.

Each needs a reason and a review date.

Without the date it becomes permanent, and a population outside the policy grows that nobody is counting.

The annual review

Half a day with four questions.

What has the platform deprecated or added?

What is our minimum version, and is it still right?

Which exceptions still need to exist?

Does the written policy still describe what is configured?

That last one catches the most common drift: configuration changed and the document did not.

The document-against-reality check

Read the policy and open the profile side by side.

They diverge within a year in most organisations.

Which matters because the policy is what people were told and the profile is what is happening, and the gap is the thing somebody will eventually point at.

Communicating changes

A changed requirement — longer passcode, newer minimum version — needs notice, especially on personal devices where it may mean spending money.

Weeks, not days.

And say what changed and why, because an unexplained new requirement is where compliance quietly stops.

When to do it off-cycle

A major operating system release.

A platform migration.

An incident.

And a change in the ownership mix — a large intake of personal devices changes what is reasonable.

What to check

When did anybody last compare the written policy against the actual profile?

Are any of your settings deprecated and silently not applying?

Do your exceptions have review dates?

And is your minimum version still defensible?