[ericalexander0]

I've built security programs from the ground up at two companies and have worked in compliance/security/cyber/etc for over 16 years. I'm also a maker and an engineer. I understand how security/compliance side sees the world, and how engineers see the world.

I hate to say it, but security/compliance tends to cargo cult. They implement what's accepted by whatever compliance framework they need to achieve. PCI, FedRAMP, SOX, SOC, CIS, etc, etc.

Engineers want to break things down to components and understand why each component is required. AKA thinking from first principles.

Mixing the two is like oil and water. Security and compliance don't have in-depth explanations for why they need to do something, they just need to check a box, and they know how it's most often checked. They know "nobody got fired for buying Sophos/Windows/AD/etc". They can't explain it from first principles, nor do they want to take the risk of going outside of known solutions.

So how do you negotiate? The box they're trying to check is likely well documented. Ask to see the documentation for the requirement(s). From there you can propose alternate solutions that meet those requirements. Try to find examples of your proposal being accepted, so you don't run into the "nobody got fired for buying x".