Checklists have featured quite a bit in my work lately. Both the development of new and the tweaking of an existing one. This came at the same time as reading The Checklist Manifesto. This melds in my head with the increasing push for throughput over thought and to take this to its logical conclusion – a race to the bottom.

I found myself in a disagreement with someone senior to me who was insistent that a checklist review of a particular system’s security architecture was all that was required to assess its posture. Now there is one variable to this discussion that I should declare. The checklist involved could be described as comprehensive but not exhaustive. That’s by design. There is no way to think of every possible facet of any and every system in a large company and codify it succinctly without misinterpretation by a fungible resource pool. My argument was that while the checklist review will likely get through 80+% of most company’s concerns – there is still ~20% that needs some actual thought.

To get to the point, the checklist is useful, but its just a reminder. Airline pilots use a checklist when they are conducting major aspects of a flight, pre-takeoff, after takeoff, pre-landing etc. But this is the key point – following a checklist will not fly the plane – it’s a reminder, a memory jogger, an aide memoire. You still need to have skill and apply it to the situation.

There is, perhaps, a clue in the word I used above: fungible. Is it acceptable to distil a skill-base into a checklist, with the quid pro quo of reducing staff costs?

Thinking more about the checklist – I suppose its similar to the oft quoted point – that you can be “compliant, but not secure”.