Part of the problem with regulations is that regulators often don't have the tools they need, resulting in wasteful and needless compliance work that leaves sys

Part of the problem with regulations is that regulators often don't have the tools they need, resulting in wasteful and needless compliance work that leaves systems less secure than they were before. Regulations are generally OK where they dictate personnel or procedural requirements but often extremely problematic where they intersect with technical matters. An example would be cryptography in the HIPAA security rule. The only crypto standard regulators had in their toolbox was FIPS 140-2 (I believe it's a recommendation, not a requirement). Sadly, FIPS is a total footgun. Many organisations however (sometimes under misleading advice from compliance paper pushers who do not know anything about security) then interpret FIPS 140-2 compliance or certification as a requirement for vendors. Well, what's the problem? FIPS-140-2 is absolutely toxic to software. Trying to run systems in FIPS mode weakens them and breaks a lot of compatibility. Also, technically, you're not allowed to patch the crypto routines after certification! See: e.g. https://blogs.oracle.com/darren/entry/fips_140_2_actively_harmful https://blogs.oracle.com/darren/entry/fips_140_2_actively_ha... for a discussion of some of the problems.