I was hired in part to write my employer's IT security policies and standards, and to guide the various IT groups in building their procedure documentation. Most of it has gone reasonably well since I started mostly with established methods and tightening things here and there. There have been some areas of contention, but the things that have received the most pushback are around development. For example, the idea that developers for enterprise systems with deployment tiers (dev, test, UAT, prod) should not have direct, full-time access to prod sparked heated debate. In addition, a couple of groups seem to be about to start a political fight over the idea that they should document some basic practices like allowed programming languages, minimum versions of those languages, security features like ASLR, and compiler settings. I've been accused of trying to dictate their development environment, but I'm just trying to get them to write down what they're already doing and agree to set some minimums on their own. The only thing that I've "imposed" is that any library or platform they use for new projects should be officially supported so that they're not writing new Python 2 or .NET 3 code.
> You got virus checkers and software solutions to handle the technical stuff, the hard part is to convince the damn receptionist to stop buying from spam mails, because THATS where most of the damage comes from.
It's not the receptionists that we have to worry about so much as middle management. We get more compromises at that level than at the lower tiers.