Inspired by these pizza baking instructions, I thought I'd have a go at condensing an entire ISO/IEC 27001 implementation project to its absolute fundamentals.  So here goes ...

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...

Implementing and using an ISO/IEC 27001 I nformation S ecurity M anagement S ystem can be tricky, especially given limited resources or in complex or dynamic business and technology environments.   While largely-manual approaches may suffice for small, simple, stable organisations, dedicated ISMS support tools (computer applications and cloud services) are well worth considering.   With dozens of ISMS tools on the market, the obvious question is which to choose.   Here are some commonplace requirements or factors to consider: Support information risk identification, evaluation, treatment and monitoring, of course. Support compliance/conformity with applicable standards, regs, laws and contractual obligations. Interoperable with existing systems/processes for asset management, risk management, business continuity management, incident management, vulnerability scanning, anti-malware etc . Support the identification, investigation and resolution of security incidents. Supp...

Recovering from a ransomware incident is costlier, more complicated and much slower that people commonly assume. "Just restore the backups and you're good to go, right?". Spoiler alert: restoring networks and IT systems from backups is only a fraction of this.  Here's a reasonably complete set of ransomware recovery activities that would normally led by general business and IT managers : Wake up and smell the coffee! Deal with the unfolding crisis and a degree of confusion. Invoke the crisis management process. Settle things down. Assemble the business incident management team. Invoke the incident management process. Form the IT incident management team. Contact insurers, law enforcement and security experts for guidance.

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. That's not merely a pessimistic outlook: I'm an optimist by nature. In this c...

Truly effective deception isn't even recognised as such - it passes completely unnoticed.  There is no shortage of now-recognised examples that the deceived didn't spot at the time and maybe still haven't noticed. Here's a sample: A stick insect appears to a predator to be an inedible stick, not a tasty insect Spotted from an enemy's reconnaisance biplane, an inflatable tank or field gun may appear solid, a credible threat at least While an accomplice distracts a resident by knocking at the front door on a pretext, the cunning thief slips around the back Phishers emulate the look and feel of legitimate emails, senders and websites to dupe victims into visiting and disclosing their credentials, using spurious urgency to shortcut or bypass checks, specific timing and wording, and sheer volume to exploit the offguard vulnerables