The problem is that the security checklists are often flawed in the other direction - they're poorly targeted towards the system under review, technically out-of-date, and wielded by rigid and inflexible thinkers who won't take anything but "No" for an answer.
A few years I filled out a checklist for a customer (for my entirely cloud-based business) that had the question "The company's file server is secured against physical intrusion: Yes or No?"
then...
"All physical access keys to the file server are under control of company management: Yes or No?"
Blech - what am I supposed to answer here?
In another example, a checklist asked us to verify that our codebase did not contain any instances of libraries implementing the MD5 algorithm. Of course, it was used in a number of places for innocuous, non-cryptographic purposes, which were hard to change due to backward compatibility. This one we couldn't squirm out of - and it took us three months to overcome the fact that we "failed" the security checklist because of that one question.
So, nearly every engineer who is forced to go through one of these stupid checklists learns they have to first transform the question into the mental space of their system, and then transform the technically correct answer into the mental space of the checklist author before determining exactly what to write down.
I think your MD5 scenario is a good example. Just answer the question honestly. The fact that the auditor doesn't understand it not being a security concern is a different problem that needs to be addressed. Yes, its painful, but working these issues IMHO is the best long term solution.
A few years I filled out a checklist for a customer (for my entirely cloud-based business) that had the question "The company's file server is secured against physical intrusion: Yes or No?"
then...
"All physical access keys to the file server are under control of company management: Yes or No?"
Blech - what am I supposed to answer here?
In another example, a checklist asked us to verify that our codebase did not contain any instances of libraries implementing the MD5 algorithm. Of course, it was used in a number of places for innocuous, non-cryptographic purposes, which were hard to change due to backward compatibility. This one we couldn't squirm out of - and it took us three months to overcome the fact that we "failed" the security checklist because of that one question.
So, nearly every engineer who is forced to go through one of these stupid checklists learns they have to first transform the question into the mental space of their system, and then transform the technically correct answer into the mental space of the checklist author before determining exactly what to write down.