[repelsteeltje]

I'm basing this mostly off first hand and anecdotal evidence - but through the years I've found that the major contribution of audits lies in having to think about the checkboxes every now and then. And what they mean in the context of my organization or project.

Rarely have I found that compliance to the goals was an issue in themselves. Or that making changes to tick a checkbox correlated to material improvements.

That is to say that if this leads to more efficiency and makes it easier for compliance audits and such, I fear is stream lining the least impactful part of its goals.

[hiatus]

> Rarely have I found that compliance to the goals was an issue in themselves. Or that making changes to tick a checkbox correlated to material improvements.

I am confused when I hear people say stuff like this. I guess if you turn on a tool and never look at it again, it won't result in material improvements. But complying with regulations or a particular compliance regime should _absolutely_ result in at least _some_ material improvement to your security posture. Like you can implement segregation of duties just as a checkbox, or use the requirement to revisit the way you gate changes to production, as just one example.

[repelsteeltje]

It depends on where you're coming from. Your code base, that is.

If it's already outstanding, you spend a lot of time revalidating what you already know and it's often a noisy process with many false positives.

If it's in a horrible state, however, the regulation often leaves a lot of wiggle room where you do some work to achieve, say, PCI compliance and then spend a lot of time arguing why this and that don't apply in your specific case.

So admitted, the is probably some improvement in the latter case but it's hardly proportional.

So IMHO, it doesn't help those of good will & expertise and does too little for the negligent. It adds noise and in the end quality still depends on factors other than compliance and certification.