One policy estate, a profile per business unit

At a few hundred devices, application control is a technical problem. At a hundred thousand across several business units it is a scoping problem, and the scoping decision is made before anybody writes a rule.

The failure it prevents is specific. One policy for the whole fleet has to be the union of every requirement in the organisation, because anything it does not allow is something that stops working for somebody. Developers need compilers, debuggers and package managers. Finance needs macro enabled workbooks. A retail kiosk needs one task application and a printer driver. A single policy that satisfies all three has the attack surface of the widest member and gives it to the narrowest, so the kiosk ends up carrying the debugger.

The shape that works #

Three parts, and the order matters.

A shared foundation, allowed once. The software genuinely present on every device, allowed centrally by signer or publisher rather than by version, so a vendor update does not arrive as a policy change.

A supplemental per profile. The line of business applications that one group needs and the others do not, scoped to that group.

A deny set in the base. Held centrally, because of a constraint covered below, and because what you refuse is an estate wide decision rather than a local one.

What goes in the foundation #

This list is shorter than teams expect, and keeping it short is the point. Everything here is allowed for everybody, so anything that does not belong to everybody belongs in a profile instead.

• The operating system and Windows components
• The productivity suite
• The managed browser and its approved extensions
• Endpoint security and detection agents
• The VPN or network access client
• Collaboration and meeting clients
• The management agent itself
• Whatever the vetted deployment tool installs, and only those paths

The last one carries a caveat worth stating. Designating a deployment tool as a managed installer means everything it installs inherits trust, which is sound for one or two vetted paths and stops being sound the moment each application's own updater gets the same designation. The application control lifecycle covers why that list needs an approval gate in front of it.

Five profiles, and what actually separates them #

The profiles below are a starting shape rather than a template. What matters is the reasoning, which is that each group is defined by the tooling it needs that others must not have.

Corporate #

Knowledge workers, and the default every new device lands in. Departmental SaaS clients, reporting and business intelligence tools, printer and meeting room utilities.

Script hosts and interpreters denied. This is the largest group on most fleets, so it carries the tightest workable policy, and a rule that is safe here is safe almost everywhere.

Engineering #

Developers and platform teams. Compilers and software development kits, package managers, container and cloud tooling, debuggers.

This is the awkward one, because the group needs build and debug tooling that is on the block list for everybody else. A debugger can execute arbitrary code, which is exactly why it is blocked elsewhere and exactly why this group cannot work without it. The carve out is named rather than general, covering the build tooling, the debuggers and the interpreters the toolchain calls.

Finance #

Finance and treasury. Ledger and enterprise resource planning clients, treasury and payments tools, macro enabled workbooks.

Macros here are a business requirement rather than a bad habit, so the answer is not to refuse them. It is to govern them by signer, so what runs is the workbook somebody signed rather than any workbook that arrives.

Frontline #

Field, retail and kiosk devices. One or two task applications and the drivers for the hardware attached to them.

The smallest allowlist on the fleet, and usually the easiest group to enforce first, which makes it a good candidate for an early ring.

IT administration #

Endpoint, server and support teams. Management consoles, remote support tooling, diagnostic utilities.

The instinct is to give this group the most latitude because they are the most technical. The opposite is correct. This is the highest privilege group on the fleet and the most valuable to an intruder, so its carve outs are named individually, scoped by signer and reviewed on a list somebody owns.

Why the deny set cannot be delegated #

The technical constraint is documented and still catches people. A deny rule placed in a supplemental policy is ignored. Not rejected, not warned about, ignored. Supplementals can only widen what a base policy allows, so a business unit cannot narrow its own posture by adding a supplemental, and a deny that appears to have been applied may never have been in effect.

That has a governance consequence beyond the technical one. Because denies live in the base, the deny set is a single estate wide statement, which is the right place for it. What you refuse to run is not a local preference.

The set worth holding there is the dual purpose tooling that is legitimate somewhere and has no business being everywhere.

• Files that run script from an HTML or help wrapper
• Hosts that execute VBScript and JScript directly
• Build tooling that compiles and runs code at runtime
• Debuggers, which can execute arbitrary code by design
• Remote execution and persistence utilities
• The Linux subsystem, which sidesteps the Windows execution path

None of that is malware and banning it outright annoys the people who need it, which is how permanent exceptions start. Stop asking what is dangerous covers why the answer is usually a location rather than a yes or no, and base and supplemental policies covers the combination rules in detail.

What is delegated is scope, not authority #

This is the sentence that keeps the structure from becoming a set of local policies with a shared name.

A profile describes what a group needs. It does not give the group the ability to decide what is trusted. The working split is that operations prepare the rules and the evidence behind them, the security function authorises the extension of trust, and both are recorded against the policy version.

Without that split, whoever writes a rule is whoever approves it, and the profile becomes a way of routing around review rather than a way of scoping it. Who application control actually involves sets out the functions that end up inside this.

Decide the profile before the policy exists #

The expensive version of this is discovering it late.

Retrofitting profiles onto a single policy that already reached enforcement means every group gets re-tested against rules written for a different set of assumptions, and the groups that were quiet become the ones generating events. Deciding the shape first costs a workshop. Deciding it after enforcement costs a quarter.

The question to answer before anything is authored is which groups exist, what each one needs that the others must not have, and who owns the answer for each. The platform sets out where that sits in the sequence.

Holding this shape by hand across several business units is where the structure usually comes apart. PoliEze keeps one estate visible as one estate: every supplemental in a single list, what each profile adds, who approved it, and where the effective policy lands for any given group. Delegating scope stays safe because nothing is delegated invisibly.