The very highest level, the process is easy enough: specify policy goals.  https://fedoraproject.org/wiki/Privilege_escalation_policy does something of that kind in the "Scope" section (focused on physical users, but applies basically equally to service accounts); perhaps we need to add more requirements.

The lowest level is also, mostly, easy enough: When any security-related configuration option is introduced (immediately as a part of some process, or as a batch process once per year), notice it, determine values that are acceptable, and change the configuration or set up a Server-specific configuration deviation (as Stephen says, treating it like any other configuration deviation), and perhaps write tests to ensure we don't regress.   Noticing the new option is easy enough when it is a new polkit control, but it does require a potentially laborious manual process in application-specific mechanisms.

It's the middle level that is problematic: How to ensure that the code implements, or allows implementing, the policy goals.  I don't have any better answer than "eternal vigilance" I'm afraid; as mentioned above, we can notice when a new option is introduced and documented, but we can't always notice when a new patch violating the high-level policy lands upstream without prominent user-facing documentation of that behavior or impact.

(No, we don't have the "lowest level" solved in the way I have described above, with a process and automation; and we could.  But with the huge difficulty with dealing with the "middle level", it seems to me that improving the "middle level" would be more beneficial than automating the "low level".)

I suppose this is just a very long-winded way of saying "I don't really know", but perhaps it has introduced a structure that allows thinking about the different aspects of the problem.

    Mirek