Whereas ISO/IEC 27001 indicates that only fourteen (14) types of ISMS documentation are strictly required  (mandatory), they are barely a start, even for a barebones ISMS.  In practice,  both mandatory and  discretionary documents are valuable . ISO/IEC 27001 c lause 4.4   states: “The organization shall establish, implement, maintain and continually improve an information security management system, including the processes needed and their interactions, in accordance with the requirements of this document.” Documentation (termed 'documented information' in the standard - see clause 7.5) is generally the best way for management to inform workers about their information security responsibilities  e.g. through written policies, procedures/work instructions and job/role descriptions, accompanied by awareness and training materials such as guidelines and briefings. In addition, many security-related processes generate 'records' such as completed forms, ...

Denis Yakimov ​shared this on LinkeDin: " Imagine your ISMS as a battlefield: Context : The battlefield terrain—topography, weather, and conditions. Issues : Your main enemies. ​Controls and SoA : Troops, tools, and fortifications. Each control is a soldier with a specific purpose. ​Leadership : The chain of command, setting the battle’s tone and ensuring everyone understands their role. ​ Planning : The war strategy how to deploy soldiers (controls) to address issues under current conditions. ​Operation : Execution of the battle plan where soldiers confront issues directly. ​ Internal Audit : A field hospital that identifies wounded soldiers and offers opportunities to remediate them. Improvement : Lessons learned applied to strengthen future engagements.” ​Google Gemini made a reasonable if naive attempt to draw a military analogy for me too: ​ " Imagine a military base: ​ The Base : Represents the organization and its information assets. ​ The General : Top management, se...

Last year in the course of collaboratively developing the Adaptive SME Security method , a friendly group of experts from the ISO27k Forum came up with the 'iterative risk assessment' approach. It is a pragmatic way to start a regular security improvement cycle - one that is realistic even for the tiniest of micro-businesses (sole proprietors). The process is a simplified version of conventional information risk management, tackling just one piece of the puzzle at a time. The bite-sized chunks can be picked up and chewed over as-and-when, and parked temporarily if (when!) something more urgent comes up. Each run through the cycle uses a single incident to exemplify and explore the associated risks in a way that any SME can manage - in fact, even larger organisations might benefit from this if their information risks aren't being managed effectively, to re-energise the process, or to share the work throughout the business. Time-boxing the cycle at (say) a month should avo...

I'm not a fan of new year's resolutions that tend (in my experience) to have limited impact and are often soon forgotten. My cynical self says the same thing applies to pledges, vows and other stated commitments, even agreements and contracts to some extent. They are more symbolic than actual control mechanisms (although I'm sure the lawyers would argue otherwise - on the clock, naturally). The focus is often on avoiding, preventing or stopping bad things, a negative emphasis although the actual language may be positive as in "I will lose weight" and "I will get fit". They can be a last resort, a sharp retrospective reminder of where we thought we were going when we are already heading off-course.

In a discussion thread on the ISO27k Forum about selecting appropriate information security controls, a member told us: "As far as software development is concerned, we really need the controls A8.25 and following". I queried that determination, guessing  their thought process may have been along these lines:  We do software development. Controls A8.25+ concern software development. Therefore, for conformity with ISO/IEC 27001, controls A8.25+ are applicable and cannot be excluded. #3 is patently a false conclusion, a logical error. The Annex A controls are  not  formally required for conformity with the standard. They are not mandatory - none of them, not one. If you believe otherwise, kindly explain which specific clause from ISO/IEC 27001 contains that explicit requirement because, despite hunting high and low over many years, and despite numerous claims from so-called experts in the field, I simply can't find it. There  is , however, a formal req...

In the past few days, I have been triggered yet again by someone fearing that ISO/IEC 27001 certification auditors may insist that various Annex A controls are applicable and must therefore be implemented for conformity. Apocryphal nightmares about auditors doing exactly that tend to stoke the fear and prolong the myth. Myth, yes, myth. I've said it before and no doubt I'll say it again: the Annex A information security controls are not formally required for conformity with the standard - none of them, not even one. If you or your auditors believe otherwise, kindly tell us which clause of the standard applies. What are the exact words leading to that conclusion? Spoiler alert: there are none. There is no such requirement. IT DOES NOT EXIST. There is , however, a conformity requirement to check through Annex A for any controls that might reduce otherwise untreated information risks, but even then there is no (repeat, no ) obligation to implement the controls as stated in A...

There is a growing appreciation, perhaps even consensus in the field that information risk management - or indeed risk management in general - is not simply a matter of predicting or controlling the future, at least not in a rational and deterministic manner. Given that the future is inherently complex and uncertain (= risky!), the best we can reasonably hope for is to reduce somewhat the number and negative impacts of disruptive events and incidents, while simultaneously hopefully increasing the chances and value of positive, beneficial outcomes. Both objectives are asymptotic: the effort and investment required to progress increase exponentially as we get ever closer to those two goals, ultimately putting them both beyond our means given finite resources (oh and one or two other things to pour our money into!). In other words, despite our best intentions, we know we are doomed to fail at some point.  Doomed I tell you. That's not merely a pessimistic outlook: I'm an optimist ...

Recently I enjoyed a lecture by a bank's economist to local business leaders concerning the NZ economy. Observing the blizzard of graphs, I was struck by his short timeline , stretching to about a couple of years ahead. Now I'm sure the economist is earning his crust at the bank. Of course they need to keep on top of day-to-day and month-to-month fluctuations in the economic parameters, playing the markets. Equally, I'm sure the bank has other experts with a longer-term outlook, diligently modelling the implications of national and global issues including political, social, environmental and technological, for many years or decades ahead - for at least as long as the bank's mortgages and business loan periods anyway. Nevertheless, that prompted me to think about planning horizons in information risk and security management, within the broader context of budgeting and investment management in any commercial organisation - a pertinent topic as we plummet towards the new c...

Objectives are king. If strategy is the organisational or personal journey ahead, we must truly understand our objectives to move ahead confidently in the right direction, systematically measuring progress towards those objectives.  If the objectives are uncertain, well, any path will do, and our measures are largely pointless: we may know how far we've come and how much fuel we've consumed so far but we're not sure how much further we need to go, nor in what direction and at what speed. That's sub-optimal. So far so good. But what if the objectives are hidden, in conflict, or not what they seem? There are clearly potential problems with objective-led approaches - a little seething cluster of problems in fact.  So, then, it seems objectives have objectives. 

For decades, I have appreciated  Peter Sandman 's approach to outrage - the social phenomenon in which groups of people react strongly to some perceived threat, issue, concern or whatever, drawing-in other like-minded individuals via social media. The echo chamber (positive feedback loop) can rapidly escalate emotions to an unreasonable degree with a lack of reasoned, critical thinking - according to those allegedly responsible for the issue anyway.    In the case of, say, the placing of 5G cell towers in/near schools, the outraged can become furious that the risk (as they see it) is being 'callously ignored' by the equipment suppliers, site developers, authorities and scientists, and enraged that they are 'not being taken seriously'. From their perspective,  thanks to group think (social endorsement),  the  perceived   risks are portrayed and understood to be deadly serious .  Leaders within the outraged community gain notoriety, influence and p...

The last of a dozen learning points I made in a post-incident review of the Crowdstrike incident was: "Unless changes are actually made as a result of an incident, the uncertainties (risks) remain. We have missed out on a valid learning and improvement opportunity." Although I accept that nobody is obliged to learn from incidents, make changes or improve, the Crowdstrike incident was Big News when it occurred back in July, and here we are in October. So it's fair to ask what - if anything - are we doing differently now? [I'm using Crowdstrike here simply as a well-known example. Even if the Crowdstrike incident had no material impacts on your organisation, you have undoubtedly suffered various incidents, possibly something serious or critical. As you read on, by all means substitute some other significant recent incident in place of "Crowdstrike" if that helps you relate to this piece.]  A cyberattack can be a devastating event for any organization. It'...

I am delighted to announce the release of   Adaptive SME Security : The guide describes a pragmatic, five-phased approach for  S mall to  M edium-sized  E nterprises to manage their information risk and security arrangements:

I blogged about the Crowdstrike incident on July 21st  while it was still playing out. Now, having  d rained the swamp and let the d ust settle, I'm  d ue to d raw out, d econstruct and d ecide what to d o about the Crowdstrike d isaster, so here goes: Design, build and test systems for resilience, where 'systems' means not just IT systems but the totality of interdependent technologies, organisations, people, information flows and other resources necessary to deliver and support critical business activities. Hinson tip : "be prepared" is not just for  boy scouts ! Those dependencies are p otential p inch p lus  p ain p oints. Test software before release. Sounds easy, right? It isn't. There is an infinite amount of testing that could be performed, only a fraction of which realistically should be, while the amount and quality of testing actually performed is resource-constrained and time-boxed for business and uncertainty (risk!) reasons (delaying secu...

My beady eye has been caught by another excellent thought-provoking Protiviti article by Jim DeLoach with Randy Armknecht concerning board-level blind spots. I highly recommend reading and contemplating Are There Blind Spots in Your Boardroom ? Jim and Randy offered ten practical suggestions for boards to address the issue. Here they are with my thoughts and ideas on how to apply them in other contexts, besides the boardroom, such as within the information risk and security management team for example: Assess whether current board culture, composition and agendas are fit for purpose in the current disruptive business environment. Assess the current team culture, composition, priorities, skills & competences, expertise, relationships, interests etc. with a view towards the future. How should the team evolve or adapt to changing circumstances, building on past successes and learning from failures?

KPMG's Soft Controls model caught my beady eye this week: KPMG are evidently using these 8 factors to analyse, measure and help clients manage their corporate cultures, claiming that "Our model gives organisations a valid tool for getting a clear picture of the current organisational situation, confront it, and break through the silence and passivity." Hmmm, 'silence and passivity', really KPMG? Well OK, whatever. It appears to be a viable approach.

"Mitigation and adaptation are required together to reduce the risks and impacts of climate change, including extreme weather events. Mitigation refers to actions taken to limit the amount of greenhouse gas emissions, reducing the amount of future climate change. Adaptation refers to actions taken to limit the impacts of a changing climate. Mitigation and adaptation together provide co-benefits for other environmental and social goals." That paragraph by Lizzie Fuller, Climate Science Communicator for the UK's Met Office, plucked from another excellent digest of lessons learned from various UK resilience exercises and initiatives , obviously con cerns climate change ... but it occurs to me that 'mitigate and adapt' might be a novel approach to information risks and impacts as well.

Early this morning ( very  early!) I remotely attended an ISO/IEC JTC 1/SC 27/WG 1 editing meeting in London discussing the planned revision of ISO/IEC 27003:2017 . Overall, the meeting was very productive in that we got through a  long  list of expert comments on the preliminary draft standard, debated the objectives of the project and the standard and reached consensus on most points. In summary: 27003 is to be revised to align with the current 2022 releases of ISO/IEC 27001 , 27002 and 27005 : These changes are  mostly  minor aside from the new section 6.3 on ISMS changes.

This checklist is appended to a SecAware guideline on implementing an ISMS , elaborating clause-by-clause on ISO/IEC 27001 - essentially, our version of ISO/IEC 27003 .   It offers  pragmatic guidance for information security managers and CISOs - nothing too obscure or complex. ---oooOOOooo--- Project definition, justification, scoping and planning ⬚   Study the standards, in depth: complete lead implementer training if possible. ⬚   Study the business, in depth, to understand its objectives, strategies, culture, governance arrangements, existing information risk and security management etc . ⬚   If the organisation has a defined, structured approach for this phase, use it! ⬚   Build a business case that identifies and promotes the business benefits of the ISMS. ⬚   Look beyond ‘security’ and ‘compliance’ e.g . helping management to manage business risks, supporting/enabling other business initiatives and strategies.

Like other ISO management systems standards, ISO/IEC 27001:2022 has just been amended to incorporate two small wording changes : “The organization shall determine whether climate change is a relevant issue” (clause 4.1); “NOTE: Relevant interested parties can have requirements related to climate change.” (clause 4.2). So, it is fair to ask what has climate change got to do with information risk and security? Is it even relevant? Having been been mulling that over for quite some while now, I've come up with a dozen points of relevance: For more on those twelve, read " Secure the Planet " - a FREE white paper. The clock in that image is a reminder that time is pressing, so here are half-a-dozen things information risk and security professionals can do to help.

This week I've read an interesting, inspiring piece by Robin Long exploring the costs, benefits, approaches and strategic options for implementing ISO27k.   I like Robin's idea of trying things out and banking some 'security wins' before committing to a full implementation. A full-scope ISMS is a major commitment requiring strong understanding and support from management, requiring a high degree of trust in the team and CISO/ISM/project leader as well as the [planned] ISMS. Demonstrating and celebrating security wins is a good way to build trust and sustain it, once the ISMS is running. I'm also intrigued by the possibilities of unconventional, creative, less boring approaches to implementation project planning - for example, instead of plodding sequentially through ISO/IEC 27001, clause-by-clause, think about: