My talk at Secure 360 was on Process Not Outcomes, we've limited control over otucomes, but we can all improve our processes. One way to do this is with checklists. Checklists help us navigate complex domains and avoid mistakes around things that we know but don't apply.
One of the things that makes infosec an interesting field is the situation that I characterize as 50% gnarly, deep technical problems (think Kerberos) and 50% brain dead mistakes (think private keys in source code repository). You can fail by messing up either one, checklists are about avoiding the second class of mistakes.
The way that checklists are most effective is when you make them your checklists instead of blind adoption of industry top ten lists. Making it your checklist means mapping it to your development process, what must be done before promoting from dev, from test to prod and into operations.
Project Checklist has a great set of rules for writing effective checklists. Following the disciplines that they recommend forces hard choices on the infosec team to gather and prioritize items for the checklists that are actionable with clear, concise guidance. Importantly, it gets Infosec out of playing Dr. No and coming only with hugely time consuming and expensive solutions. Instead look to integrate the checklist into the development process, and make it simple enough for a developer to fill out in a short amount of time.