The controls suggested in Annex A of 27001 and the other ISO27k standards are typical, commonplace, conventional, good practice … whatever. Mature organizations often use them and find them useful. They have evolved into being over decades of experience with IT and millennia of experience with the use of information in a business context, and they are still evolving today. Cloud, BYOD and IoT, for examples, are all relatively new hence the associated risks are still emerging and the controls are a work in progress. Fraud, espionage and hacking are always going to remain challenging because of the ongoing arms-race between defenders and attackers: as fast as the controls are improved, the threats change.
The published ISO27k standards present a fraction of the accumulated knowledge of thousands of ISO/IEC JTC1/SC27 committee members and helpers around the world with experience in myriad organizations and situations. Most committee members accept the advice is valid, useful and worthwhile, on the whole. The standards development process reaches consensus among the committee, or as close as we can get with the occasional stalemate, truce, abstention or objection!
The standards are generic – deliberately so since they are meant to be applicable to any and all organizations. They need to be interpreted and applied sensibly according to the specific context of each organization. Key to doing that in the ISO27k way is first for the organization to figure out its information risks, consider and evaluate them, then use the advice in the standards (and/or elsewhere) as guidance on how those risks might be treated.
Sounds straightforward in theory, but in practice?
Any individual organization, manager, or information risk and security professional, may not have experienced all the issues that led to the controls being included in the standards - in other words, some of the information risks have not eventuated for them. Some may have occurred but not been recognized as such (e.g. the risk of losing valuable intellectual property when knowledge workers leave the organization may not be apparent, at least not for some time). Therefore, those risks may not feature at all on their risk landscape, or may be downplayed and perhaps lost among the weeds.
Hopefully, though, the exercise of reviewing the controls outlined in the standards leads to the corresponding risks being considered, although this is far from guaranteed, especially if those using the standards are inexperienced in the field. I would prefer the ISO27k standards themselves to be risk-driven in the same way as the ISO27k approach, explaining what information risks are addressed by the standards and, ideally, each of the controls within.
Failing that, we routinely document the information risks associated with each of the security awareness topics in our portfolio for the same reason: helping our customers' awareness audiences understand the purposes or objectives of the suggested controls in each area.
At the moment, the risks are integrated and discussed within various NoticeBored awareness materials - the presentations, briefings, newsletters etc. Maybe for 2019 we might produce a discrete deliverable for each module specifically on the risks. Hmmmm. That's a thought. I can already picture the format. Drafting the first 'Information risk profile' (or whatever we call it) will be the chance to generate a template to stabilize the format.
That's another thing for my lengthy to-do list. Talking of which, must dash ...