Departments that have an ISO 9000-type approach to quality assurance, or any other mature ‘management system’, typically have standard ways of managing documents involving things such as: Document lifecycles from cradle-to-grave: how does the need for a new document arise?   How does that happen, in practice?   Who determines and specifies the requirements or objectives etc. ? Document ownership, accountabilities and responsibilities: who is in charge?   Who has the final say?   Classification of documents, even if only by name [policies, procedures, guidelines etc. ], with implications on authorization, use, assurance, disclosure etc .; Structured document review, update, authorization and release processes; Standard, consistent document formats and styles – preferably emphasizing readability and utility – perhaps using templates with mandatory and optional elements; Maintained and managed inventory of [important] documents, ...

A deceptively simple question this morning from a client about where the information security function should sit in the organization structure set me thinking as the first coffee of the day did its magic. My first thought is that it all depends on the organization, the existing structure and power bases, the specific interests of the individual executive managers, the strategic directions, the corporate culture, other stakeholders and most of all ‘the business’.  So for, say, a financial services, defense, health or intellectual property company, information is such a critically important, valuable yet vulnerable corporate resource that risk and security deserves direct representation in the C-suite i.e. a C hief I nformation S ecurity O fficer or possibly C hief S ecurity O fficer.   For other industries, it’s not so clear-cut. I strongly favour the core term “information risk” since risk to and involving information (not just computer data!) is what drives our field. ...

Another interesting morning on the ISO27k Forum when a new member asked for help to address an ISMS internal audit finding relating to  ISO/IEC 27001:2013 section 4.1:  “The organization shall determine external and internal issues that are relevant to its purpose and that affect its ability to achieve the intended outcome(s) of its information security management system.” To my beady eye , that succinct sentence (plus the rest of clause 4 and more besides) leads-in to a fairly diverse and creative set of activities relating to ‘establishing the context for the Information Security Management System’: Who are the stakeholders with an interest in the organization’s information and hence the associated risks and opportunities?   What are their 'issues' - their interests, in fact? What matters to them? What are their priorities and concerns? What business is it of theirs? [Clause 4.2] Consider the organization’s purposes (business objectives/goals, strategies and...

At the peak of the typical policy pyramid sits a  ‘corporate information security policy’. In clause 5.2, ISO/IEC 27001 explicitly requires  an information security policy specifying aspects such as demonstrable top management commitment and objectives . The corporate information security policy template has: The usual boilerplate for any formal policy e.g. summary, applicability, version and date up front, plus responsibilities and references at the back; A short introduction, using the pyramid diagram to outline the entire information security policy structure; A set of seven  principles (objectives) driving information risk and security  e.g.  “Information is a valuable business asset that must be protected against inappropriate activities or harm, yet exploited appropriately for the benefit of the organization.   This includes our own information and that made available to us or placed in our care by third par...

According to the BBC , British Airways has been fined £183m for last year's breach of the G eneral D ata P rotection R egulation, dwarfing the previous record fines of £½m under the previous Data Protection Act.   Ouch. Privacy compliance is now A Thing - A Very Big Scary Thing with Sharp Teeth, Claws and a Bad Attitude. The prosecution and fine broadcasts a clear message that organizations are going to be held to account under GDPR for failing to prevent privacy breaches. I guess privacy officers, information risk and security managers, CISOs, CROs, CCOs and execs generally are now scrambling to gain assurance that their organizations are not going to end up in the same mess. And management at organizations which have suffered privacy breaches since GDPR came into effect, especially if they are currently under investigation or being prosecuted, must be quaking in their hand-made Italian leather boots.  At 366 times the previous record, the BA fine is deliberately shocki...

A thread on the ISO27k Forum about how to go about auditing an organization's P ublic K ey I nfrastructure set me thinking this morning. The thread started with a question from PS: "Could you please share some tips for auditing TLS/SSL arrangements within organisation?  Nessus will help us to identify weakness around configuration of crypto but if  I want to audit how sysadmins are creating self-signed certs and applying key management principles, how would I do that?" In response, Ahmed provided some background information about PKI, followed by a  fairly detailed and specific list of 15 auditable items, describing them as 'essential points': Audit for Root Certificate: how its managed, should be stored over secure hardware module (HSM) FIPS 140-2, if not how its secured. Assess CA Signing certificate (CA Private key) : How it is managed, secured, validity and key length. Audit System documentation to audit: (mentioned above) specially key management policy and p...