The most expensive project is the one that stalled
A project that never started has an honest risk register. The line item is open, everyone knows it, and the cost of the work is still in the future.
A stalled application control project is worse. The budget is already spent. The pilot group is in enforcement, the rest of the fleet is sitting in audit mode, the exception list has grown a tail nobody owns, and the policies have not been reviewed in months. The money has left the building — and the posture has not moved.
That is the trap specific to application control. A half-finished rollout gives you all of the cost and almost none of the protection. You are still not at ML3. You are still exposed to exactly the class of thing audit mode was never going to stop. And the audit finding that started the whole project is still open.
What you are really comparing
When a team weighs up an application control project, the honest comparison is not "the cost of the tool" against "free, we will do it ourselves." It is two full paths, end to end.
Path one is the unaided build. Six months or more of calendar time for a single fleet, most of it specialist effort, with a real probability of stalling, a fleet that will not enforce, or a removal that breaks something nobody knew was load-bearing. At the end of it, if it lands, the knowledge lives in one person's head and the next change starts the cycle again.
Path two is someone who has already walked path one — more than once — arriving with the lifecycle already built. Generation, testing, enforcement, exception handling, patch re-validation: not a thing the team assembles under deadline pressure, but a product that does it. The calendar shrinks because the wasted motion is gone, not because anyone is cutting corners. And when the engagement ends, the team is not left with a folder of scripts and a diagram. They are left with the tool, running, in a form they can actually operate.
The second path is a fraction of the time and a fraction of the risk. The cost of the engagement is set against the first path — against the six-month slog and everything that can go wrong inside it — not against an idealised version where the DIY build goes perfectly. It rarely goes perfectly. That gap, between the project people imagine and the one they actually get, is the real number, and it is almost always larger than they expect.
What WDACManager changes
WDACManager exists to take the slow path off the table. The lifecycle that used to be most of a year of internal effort — build, test, enforce, handle exceptions, keep up with patches — is the product, not something the team hand-assembles while the clock runs.
It was built by people who have already taken real environments all the way to full enforcement, not just to audit mode. The mistakes that cost the slow path its months — the audit events that mislead, the noise that should never enter a policy, the removal that bricks a machine — are the ones already designed out, because they were paid for once already, the hard way.
The result is a delivery that looks more like a focused engagement than an open-ended program, and a team that is left with a capability they can run themselves rather than a dependency on the person who built it.
If your application control project has been "nearly there" for longer than you would like to admit, the most useful thing is usually not more internal effort. It is a conversation about what the rest of the path actually costs — and how much shorter it can be.