Recently I’d been helping a customer negotiate their cyber security insurance – which turned out to be trickier than I expected. This got me thinking about the role that insurance played in cyber security. Then – coincidentally – I was reading a book on security (Paul Martin’s great “The Rules of Security”) and came across this sentence: “Insurance is sometimes described as a means of transferring risk, but it is really more of a mechanism for softening the financial impact of a loss.” (p 73). It got me wondering – at Axenic have we been thinking about insurance all wrong?
Category: Risk
March 2021 Newsletter – Axenic Cybersecurity Commentary
Hot off the “virtual” press is our March newsletter. This month we discuss cyber news such as Accellion vulnerability and consider a use for blockchain and of course the associated risk that comes with this. We also highlight some useful resources such as the OPC’s Principle 12 tools and our very own flexible virtual roles to help you add some extra security muscle to your organisation. Click here to get the full picture.
From Chaos to Conformance: 4 Context of the organisation
Information security is all about context!
In my previous two articles in this series focused on developing an Information Security Management System (ISMS) based on ISO 27001:2013, I presented the common myths associated with the standard. In this article, I am going to provide an overview of the standard and section 4 Context of the organisation.
From Chaos to Conformance: More ISO 27001 myths
Dispelling more common myths
Okay, I know I promised to delve into and discuss the requirements defined in 4 Context of the organisation. However, I realised that they are other common myths that I should dispel for those of you that are interested in implementing an Information Security Management System (ISMS) that conforms with ISO/IEC 27001:2013 (ISO 27001).
From Chaos to Conformance: A series on implementing an ISMS
Dispelling some common myths.
Rapid Reaction: Detecting or Reporting Information Security Incidents
This is the fourth article in a series that aim to help organisations build and maintain their information security incident management and response capability.
In the previous article I provided a bird’s eye view of the standard incident handling process. As noted previously, the incident handling process is triggered either by detecting or reporting security events. A number of security professionals believe that detecting an incident means looking for failure logs such as failed login, failed resource access etc.