The application control lifecycle, stage by stage

Application control gets scoped as a policy exercise, which is why it gets underestimated. The policy file is the smallest part of it.

What actually has to happen is four stages, and only the first three have an end. Here is what each involves, and what each looks like with native tooling alone against a control plane on top of it.

Stage one, discovery #

You cannot decide what belongs until you know what is there.

The difficulty nobody expects. Autopilot and modern provisioning mean there is no single gold image to inspect. Devices are built from a configuration rather than cloned from a master, so the estate has to be discovered from the devices themselves, and what procurement bought is not what runs.

What you need out of it. An inventory of every signer, publisher and unsigned binary present, with owners against them. Unsigned and hash only applications flagged early, because those are the ones that will cost maintenance later. Shadow IT surfaced now rather than at enforcement.

On software already installed. This is worth stating because it catches people. Managed installer works by tagging files as they are written to disk, so it does nothing for anything already present when the policy arrives. That software needs explicit signer, publisher or hash rules built from what discovery found. There is no shortcut.

Stage two, governance #

Every extension of trust is a decision. The question is whether it is recorded as one.

Authoring and review. A raw XML diff tells an approver almost nothing. What an approver needs is what changed in readable terms, at which rule level, and why that level was chosen. Choosing App Control rule levels covers why the level is the decision that matters most.

Managed installer, with a gate in front of it. Designating a deployment tool as a managed installer means everything it installs inherits trust. That is sound for one or two vetted paths such as Intune or Configuration Manager. It stops being sound when each application's own updater gets designated, because the trusted set then grows without anyone approving what is in it. So the useful arrangement is every acting installer in one visible list, with an approval in front of anything joining it.

Separation of duties. Without it, whoever writes a rule is whoever approves it. The workable split is IT operations preparing the change and the evidence behind it, the security team authorising the extension of trust, and both recorded against the policy version.

Stage three, enforcement #

Enforcement is not a switch. It is a sequence, and the sequence is the safety.

Move outward by group or ring, each one gated on the previous one going quiet, with readiness evidence before the next expansion. That evidence is the point: the question before every ring is whether the last one produced surprises, and the answer has to come from data rather than from confidence.

Audit mode to enforcement covers where audit mode is silent, which matters because audit mode is not a complete dress rehearsal and the gaps are documented.

Stage four, operation, which does not end #

This is the stage that gets left out of business cases and then consumes the programme.

Drift. The policy on a device stops matching the policy you approved. Somebody needs to know, and know which device.

Exceptions. Requests arrive, get granted, and then need to expire. An exception without an expiry is permanent from the moment it is issued, and that is how a narrow policy becomes a wide one over a year.

Policy history. Which version is where, who approved it, what changed, and how to get back. That record is the thing that makes a reversal a decision rather than a panic.

Software that will not sit still. Auto-updating applications ship new binaries on the vendor's schedule. Vendors change signing certificates. Applications generate helper files at runtime. The allowlist has to track how software behaves rather than how it was packaged on day one.

Why this is a lifecycle rather than a project #

Three of those four stages have a completion point. The fourth does not, and it is the one that decides whether the first three were worth doing.

A policy that reached enforcement and then drifted, accumulated permanent exceptions and lost its version history is not a control any more. It is a configuration nobody will touch.

That is the whole argument for treating this as an operating model with tooling behind it, rather than an implementation with a closing date. Who application control actually involves covers the functions that end up inside that operating model, and the platform sets out the sequence for a first pass.

Stage four is also where PoliEze earns its place, because it is the stage nobody budgets for. Drift you are told about rather than discover, exceptions that expire without anybody remembering them, and a version history that makes a reversal a decision rather than a panic. Those are the things that decide whether the first three stages were worth doing.