That being said, it made me way better at my job. No matter how many technical justifications I have for why we should implement X, the second I brought up a small to medium legal thing everyone would fix it immediately.
In almost every work environment, I've seen the policies working directly against security: if not by contradicting it, ignoring the details where the real security decisions live, or by striking the wrong balances between prescriptiveness and generality - then by out-prioritizing security decision making. (I've worked at mostly 100,000+ person companies).
It's much better to have technical security controls >80-90% of the actual security. It's just expensive and harder to teach/learn/implement.
That said, there's some real security gained by policy. It comes from: - Ability to communicate expectations ("adopt technical solution X") - Ability to exercise legitimized (instanciated/codified) authority
Most of the rest of the value of policy comes in as business enablement value (policies are easier to communicate to auditors than security control implementations are).
Policy can also be a useful placeholder for real security in the sense it will satisfy many external parties who might otherwise reprioritize/randomize security investments.
As an example, I’m glad that browser vendors require CAs to document their policies for issuing certificates. Let’s Encrypt does a great job of making much of this process automatic, but there’s still pieces that must be done by humans, and there’s still written policies in place for all of their operations.
At some point in any security process, human judgment comes into play. Striking the wrong balance between technical controls and allowing for human judgment can also lead to absurd outcomes, like this recent article/discussion[0].
If your system is doing "all the right security stuff" and then nobody knows about it - sure, you're secure - but nobody knows that or how you are secure. And that's a very significant problem both to a bureaucracy and to its customers. It's also an issue in terms of maintaining those controls over time between changes to staff and business direction.
There's a whole "secondary market" (within an organization) for security assurance, and it tends to be much more measurable than security posture.
Policies and summaries of those policies go a long way toward feeding that "assurance feeling" secondary market without draining resources from ongoing investments actual posture.
Essentially the way it works is that you develop security controls toward an ideal end state/direction and describe your direction as your policy. Any gaps auditors or your company find then become fuel for making actual changes to the underlying security posture at a technical level.
The danger of not having your policy really be disguised summaries of your actual implementation is that the various security staff become free to debate over fictional security and can convince themselves that if they mandate some changes on paper to the policy (with there being nothing technical associated whatsoever) that this has or should have some kind of real affect.
It's more dangerous still if the internal security assurance program uses its own policies or some measure of "adherence to the policies" to then measure security. What happens is that the compliance operation becomes authoritarian about adherence to policies that don't exist outside of (otherwise non-discoverable) mandate, and the company and its auditors are able to "measure" their posture by their policies and convince themselves they are secure.
The worst version of this is where its done on purpose for fraud.
EG: Adding something as simple as a privilege expiration (generic example) and propagating it through the org and various teams itself will take time.
Anyone who's worked at a large company can tell you how incredibly complex and expensive this can get if your systems aren't designed for this.
It would be difficult to incur a 50% increase in expenses without massive policy shift.