On Checklists
On one of my recent trips back from New York City to my office, I had to spend some time on Penn Station to wait for my train to arrive. Invariably, whenever that happens, I end up in a book store. Although, I usually do not end up buying anything, this time I picked up a copy of Atul Gawande's The Checklist Manifesto. In the book, Gawande presents example after example to explain why just about any procedure can be improved by using checklists.
Checklists provide the minimal steps required to execute a procedure successfully. They do not have to always be written in full, and should not go into extreme details describing every step to take, but they should focus on certain key steps that should always be followed. Arguably, the most well-known form of checklists are the ones used by pilots. These checklists cover routine circumstances, but specific exception checklists also exist. The checklists typically do not focus on how to do things, they do provide a form of reflection to whomever uses them to ensure that the what has been done.
Information security practices may also benefit from checklists. Keep in mind the lesson from the book: checklists should be simple to understand, focus on critical steps, describe what needs to be done and not how to do it, and most importantly, be used consistently.
In my security practice, I often use very simple checklists. Common items include:
☐ Notify CIO
☐ Inform Helpdesk
☐ Create tracking ticket
☐ Activate CSIRT
These checklist items are simple to understand, do not assign specific responsibility for who should execute the steps, and do not provide any guidance about how they should be executed. Yet, they are unambiguous, and when steps are omitted from them, it may come back to haunt you.
Some of the common objections against using checklists raised by critics are:
- "I do not need a checklist to tell me how to do my job." Maybe, but remember that the checklist does not specify how to do a job. They provide reminders of all the steps that need to be gone through, and they will provide whoever is using them with the assurance that all steps were followed. Especially with highly repetitive jobs that are executed dozens of times a day, it is easy to miss a step or to cut a corner. Conversely, procedures that are invoked very rarely run the risk of being executed incorrectly. Checklists will ensure that defined processes are executed completely and consistency, rather as shot from the hip. I find that incident response work typically benefits from checklists.
- "Checklists slow me down." That is part of the whole idea. Checklists will stop people from going on autopilot and force them to actually think about what they are doing and how they do them.
- "I do not see the value of checklists". Completing checklists will provide job metrics, especially if exceptions are noted. In addition, they may provide a documentation trail about the work that is done. Finally, the first time that a checklist actually catches an omission before it turns into an incident in its own right, their value will be made obvious.