Topic-specific policy 6/11: information security incident management

I'm intrigued by the title of this topic-specific policy from the [draft] 3rd edition of ISO/IEC 27002, being the only one of eleven example titles in the standard that explicitly states "information security".  

I ask myself why? Is there something special about the management of events classed as 'information security incidents', as opposed to other kinds? 

Hmmmm, yes there are some specifics but I'm not entirely convinced of a need for a distinct, unique policy. I feel there is more in common with the management of all kinds of incident than there are differences in respect of infosec incidents, hence "Incident management policy" makes more sense to me.

Here's one I prepared earlier.

Organisations deal with events and incidents all the time. Aside from the humdrum routines of business, things don't always go to plan and unexpected situations crop up. Mature organisations typically have incident management policies already, plus the accompanying procedures and indeed people primed and ready to respond to 'stuff' at the drop of a hat. Wouldn't it make sense, therefore, to ensure that "information security incidents" are handled in much the same way as others?

That's fine for mature organisations. For the rest, the SecAware information security policy template on incident management concentrates on the specifics of infosec incidents and outlines incident management in general. A workable infosec policy can prompt the development and maturity of incident management by:

• Documenting and formalising things - particularly the process, expressing management's expectations and requirements in clear terms (e.g. striking the right balance between investigating and resolving incidents, especially where business continuity is a factor).
• Stabilising the working practices, de-cluttering things, making them more consistent and hence amenable to management control.
• Enabling reviews and audits, leading to systematic process improvement where appropriate.
• Discouraging inappropriate shortcuts (e.g. ineptly investigating serious issues, compromising important forensic evidence) while facilitating escalation and management decisions where appropriate (e.g. determining whether forensic investigation is justified). 
• Making people aware of their responsibilities, helping them understand their roles in relation to the process and each other (e.g. IT and legal professionals collaborating to investigate and resolve cyber incidents, while others keep out of their way unless asked to participate).

By the way, we also offer a distinct incident reporting policy. Why call that out separately? Our reasoning is that the policies address different audiences: incident management is primarily relevant to the incident management team and managers, whereas incident reporting involves everyone - staff, managers, contractors and other workers, even total outsiders who spot and wish to notify the organisation of incidents such as privacy breaches and physical or staff vulnerabilities ... and on those lines, I'll simply mention whistleblowing and fraud, leaving you to contemplate.

Looking back at this and previous blog pieces in the series, the topic-specific policy examples simply, briefly and ambiguously named in the standard have led us into exploring related areas and stimulated creative thinking ... just as examples are intended to do. I'll circle back to discuss the policy mesh at the end of this series in just a few days.