Policy options that mean the opposite of what they read
An App Control policy option is true because it is present. Several are written as double negatives, so the secure setting is often the one nobody set.
Most of the attention in an App Control programme goes to the rules, because the rules are the part that decides what runs. The options get set once, early, usually by copying a base policy, and then nobody looks at them again.
They deserve more than that. The options decide how the whole policy behaves, and they are written in a way that works against the person reviewing them.
The option is the setting
In an App Control policy there is no field with a value. There is a list, and an option is true because it appears in it.
That means the name has to carry the state, so every option is written as its own switched on position. Enabled:Audit Mode in the policy means the policy is in audit. Take it out and the policy enforces. You did not remove audit and land somewhere neutral, because there is nowhere neutral to land.
This is perfectly logical to the engine and consistently surprising to people. An engineer removing something expects less to happen. Here, removing the audit option is how you turn enforcement on.
Several of them are double negatives
The awkward part is that not every option describes a thing being switched on. Some describe a protection being switched off, and those read backwards.
Disabled:Script Enforcement. Script enforcement is on by default in every App Control policy. This option turns it off. So the secure position is not to set it, and the decision in front of you is never "enable script enforcement", it is "do not disable it".
Disabled:Runtime FilePath Rule Protection. By default App Control checks at runtime that a path rule only covers a location administrators can write to. That check is the thing that makes path rules defensible at all. This option removes it. Choosing App Control rule levels covers why that check matters and the custom administrator SID case that makes people reach for the option in the first place.
Enabled:Unsigned System Integrity Policy. This one reads insecure and is the normal starting position. It allows the policy itself to remain unsigned. Removing it is what commits you to signed policies and the certificate handling that comes with them, which signed and unsigned policies covers properly.
Put those together and you get a review problem. In a list where presence means true, a protection that is still in place shows up as nothing at all. There is no line to read, no green tick, no entry confirming that script enforcement is on. The safe state is an absence, and an absence is the one thing a reader cannot see.
Where this actually bites
Three of the misreadings are common enough to name.
Turning enforcement on by accident. Somebody removes the audit option intending to make the policy quieter. It does the opposite, everywhere the policy is deployed.
Switching off a protection while fixing a compatibility problem. Disabled:Runtime FilePath Rule Protection makes a stubborn path rule work. It also removes the check that made path rules acceptable, and the change ticket usually records the symptom that was fixed rather than the guarantee that was given up.
Assuming audit mode covers everything. It does not, and that has its own post: audit mode to enforcement sets out the four things that are enforced or altered even while the policy says audit, including one that has no audit mode at all.
Not every option is valid everywhere
Two more constraints sit underneath the names.
Some options only apply to a base policy. Add one to a supplemental and it is simply not doing the job somebody assumed it was doing. Base and supplemental policies covers how the two combine.
Some options depend on the Windows version. An estate with mixed builds can have the same policy behaving differently across it, which surfaces as a fleet where a change worked for most people.
Neither of these announces itself. There is no error, no warning and no event. The option sits there looking correct.
Reviewing an option list properly
Three things make the difference, and none of them is technical.
Translate before you approve. Every option should reach an approver as what it does, not as what it is called. "Script enforcement will be turned off" is a decision somebody can make. "Disabled:Script Enforcement" is a string somebody will nod at.
State the security impact separately from the compatibility impact. Most of these options get added to fix compatibility, and the security cost is the part that goes unrecorded. Both belong in the approval, because in six months the only question anyone will ask is why.
Change options and rules separately. A release that adds allow rules and adjusts options at the same time gives you no way to attribute what happened next. Options change how the policy behaves everywhere it is deployed, so they earn their own ring and their own window.
Where PoliEze fits
An option list is a security configuration that reads like an engine setting, and that gap is where the mistakes live.
PoliEze closes it. Options are presented as what they do to security and to compatibility, in plain language, so an approver reads a decision rather than a string. Choices that switch a protection off are treated as exactly that, with a reason and an owner attached. Options that are not valid for the policy or the platform they are being applied to are caught before deployment rather than discovered as a change that quietly did nothing.
The result is a policy whose behaviour somebody can explain, which is the part that matters when an assessor or an incident asks. The platform sets out where policy governance sits in the sequence.
Sources
Questions about this
What are policy options in App Control for Business?
Why is removing an option different from turning it off?
Which policy options are the easiest to misread?
Can I review a policy by reading its option list?
Are all options valid in every policy?
Related reading
The missing control plane for App Control for Business
Windows already enforces. What no vendor ships is the layer that decides what to trust, records who approved it, and takes it away again when it is no longer needed.
Every application control product identifies files the same way
The file identity model is common to all of them. What separates one product from another is the operating model around it, which is what evaluations skip.
Managed installer is not a convenience flag. It is a trust channel
Designating one trusts everything it writes, and everything its child processes write. That makes the choice a security decision rather than an operational one.