Risk management trumps checklist security

While arguably better than nothing at all, an unstructured approach to the management of information security results in organisations adopting a jumble, a mixed bag of controls with no clear focus or priorities and – often – glaring holes in the arrangements. The lack of structure indicates the absence of genuine management understanding, commitment and support that is necessary to give information risk and security due attention - and sufficient resourcing - throughout the business. 
 
It's hard to imagine anyone considering such a crude, messy approach adequate, even those who coyly admit to using it!  I'm not even sure it qualifies as 'an approach'.
 
Anyway, the next rung up the ladder sees the adoption of a checklist approach: essentially, someone says 'Just adopt these N controls and you'll be secure'! It may be true that some information security controls are more-or-less universal, so any organisation that does not have them all might be missing out. Maybe it is a step up from the previous approach, and yet there are significant issues with checklists that tend to be:
  • Basic, severely over-simplifying a complex and dynamic problem, ignoring numerous aspects while focusing attention on the N (meaning a handful);
  • Generic but not necessarily as universal as implied, given the wide diversity of organisations out there in terms of size, maturity, industry, culture, history, business objectives, resources and so on;
  • The 'lowest common denominator', setting a (very) low bar;
  • Sequenced linearly in a way that implies priorities for implementation and generally disregards dependencies and linkages between items on the list, yet another over-simplification; 
  • Just someone's arbitrary selection, generally without any sound basis for selecting the listed controls and not others, other than the originator's alleged expertise;
  • Tricky to interpret and apply in a given situation, given the immaturity of the organisations attracted to checklist approaches;
  • Not sufficient in most cases, and often biased towards particular types of control e.g. 'cyber' or 'compliance';
  • Unrealistic in the presumption that simply because someone recommends the N controls, managers will therefore naively accept that they are both required and valuable;
  • Belittling, clearly implying that they are deliberately dumbed-down because the intended audience is, well, dumb.
If N controls are inadequate or even barely sufficient, it is tempting to expand the list. N-plus control checklists suffer similar problems, plus:
  • The more controls that are added to the list, the less likely they are to be truly universal;
  • The controls tend to be grouped and structured in some fashion ... which is another ill-defined process involving arbitrary criteria and of dubious value;
  • The longer the list, the less attractive it becomes to those seeking easy solutions. Simply reading longer lists takes time and becomes tedious, while implementing all the controls appears increasingly arduous - especially if the recommended controls are not explained and justified properly (which would make the list even longer anyway!);
  • Ultimately, a long list is no better than a bit of Googling, consideration and discussion;
  • There is a risk that the very readers who would benefit to some extent from the approach are overwhelmed by it all and put off entirely.
At face value, ISO/IEC 27001 is an N-plus checklist, after all Annex A is an arbitrarily structured list of about 100 information security controls recommended by a committee of experts. There's more to it than that, however.

For one thing, Annex A is merely a succinct summary of the information security controls in ISO/IEC 27002. It's a simple list, yes, but one backed by roughly a page of detailed explanation behind each control, particularly in the latest, fully updated edition published a few months back.

Furthermore, the main body of ISO/IEC 27001 avoids the checklist mentality by defining the governance arrangements for managing an organisation’s information risks. It is a systematic, iterative, risk-driven approach, simple and easy to grasp. In a nutshell, there are just 4 phases:


An ISO27k ISMS enables and supports the analysis, prioritisation and changes required for any organisation to design and implement a sound, systematic approach to information risk and security management that is tailored and appropriate to its specific situation - a substantial enhancement over any crude checklist. The selection and implementation of information security controls is context-dependent in ISO27k, particularly as the standard allows organisations to choose controls from any source - including those crude checklists, and Google, and ... whatever. Any list of controls is less important than the process for identifying, evaluating and treating risks. 
 
The risk management process at the heart of ISO/IEC 27001 is universally applicable. It's not even limited to information risks, information security, privacy and so forth.
 
Organisations may wish to go beyond the fairly basic risk and security management arrangements mandated in the main body of ISO/IEC 27001 … but that is not necessarily a good idea, especially at the start of their journey to maturity. ‘Keep it simple’ makes more sense as a strategy, especially in a start-up situation i.e. set out to implement just the basics, get them working properly and plan to build gradually from there, over time, making incremental improvements where justified or necessary. The ISMS itself embodies the mechanisms to capture requirements and push through improvements, systematically (see the K in the RISK mnemonic).

A reasonably mature organisation is likely to have a suite of reasonably mature management and governance arrangements already operating. A new ISO27k ISMS will be slotting in to and making use of them, requiring changes in various aspects to accommodate the structured, systematic, risk-driven ISO27k approach. The ISMS itself is likely to involve consolidating existing practices around information and cyber security management, albeit often mostly within IT but hopefully with strong lateral links to related functions such as Risk, Compliance, Procurement, HR, Operations and Facilities, perhaps even upwards to senior/Executive Management and the Board. Even here, the keep-it-simple ISMS strategy has value in terms of focusing on the essential/core processes and activities around information risk management. Anything above and beyond the core should probably be a lesser priority during the initial ISMS implementation phase, unless there are good business reasons to press ahead more urgently in other areas (e.g. compliance obligations) – in which case those pressures can help drive through the ISMS implementation.