Are you responsible for your organisation's information security or cybersecurity budget? Are you busily putting the finishing touches to your 2021 budget request, still working on it, just thinking about it, or planning to do it, honestly, when you next come up for breath? Budgeting is generally a dreaded, stressful management task. Not only do we have to figure out the figures but we typically anticipate a tough battle ahead leading (probably) to a disappointing outcome and yet more problems. On top of that, 2020 has been an exceptional year thanks to COVID. The business and information security implications of knowledge workers suddenly working from home, en masse, are still playing out now, while the economic impacts of COVID do not bode well for any of next year's budgets except perhaps for the manufacture of vaccines, masks, gloves, sanitiser and respirators. A substantial part of information security expenditure is (whatever we may believe as professionals) discretionary...

One of the recurrent (zombie) threads on the ISO27k Forum concerns the status of ISO/IEC 27001:2013 Annex A. Typically the zombie is prodded from its slumber by a relatively inexperienced member naively suggesting that certain security controls from Annex A are essential or mandatory for certification. In the course of debating and attempting to bury the zombie, some members trot out their own curious interpretations of the standard, pointing out actual and apparent discrepancies in the wording which, to them, indicate that Annex A is at least partly mandatory. I'm too polite to say they are wrong, but I believe they are misguided or mistaken - partly, it must be admitted, because the standard is ambiguously worded in some areas, hence it has to be interpreted care fully in practice. To be clear, based on my three decades' professional experience and membership of ISO/IEC JTC 1/SC 27, my position is that  none  of the controls outlined in Annex A are mandatory.  None at...

We've been chatting on the ISO27k Forum  lately about using various IT systems to support ISO27k ISMSs. This morning, in response to someone saying that a particular tool which had been recommended did not work for them, Simon Day made the point that " Each organisation trying to implement an ISMS will find it’s own way based on their requirements. " Having surveyed the market for ISMS products recently, I followed-up with my usual blurb about organisations having different information risks and business situations, hence their requirements in this area are bound to differ, and in fact vary dynamically (in part because organisations mature as they gain experience with their ISMS: their needs change). The need for flexibility is why the ISO27k standards are so vague (essentially: figure out your own requirements by identifying and evaluating your information risks using the defined governance structure - the ISMS itself), rather than explicitly demanding particular securit...