No size fits all
This week I’ve been chatting with Aussie infosec blogger Endre about security policies. Although Endre elaborated very eloquently on the tradecraft of policy-writing, I don't think he had considered the variety of audiences/users of policies and their purposes. That diversity should be borne in mind when writing policies and supporting materials (guidelines, courses etc.), and when designing and documenting the associated processes/activities (awareness, training, oversight, compliance, metrics …) - an additional level of finesse to the tradecraft.
Today, a similar issue cropped up on the ISO27k Forum: Jose asked whether his organization might prepare, say, a single scoping document for multiple Management Systems sharing the same scope. Chris pointed out that there are several audiences for the MS documents, saying "You can structure the documents however you want as long as you are meeting the requirements of the standard but don’t forget that these documents need to be used by people."
Any Management System has several audiences/users and purposes. Its primary purpose (I would argue) is to allow the organization to manage stuff systematically and rationally, hence management is obviously the main audience/user, plus other stakeholders such as the organization’s owners, authorities, dependent business partners etc. with an interest in sound management. Certified compliance with, say, the ISO standards is a secondary purpose, along with assurance, demonstrable professionalism, adoption of good practices, continuous improvement and all that … with their respective audiences/users.
There's quite a bit of complexity there already, talking about individual Management Systems. It is hardly going to be simpler to implement multiple Management Systems in parallel - so why do it?
Commonality between Management Systems is not an objective but a means to an end: it should improve the net value (business benefits less costs) in various ways - simplifying and standardizing things, increasing familiarity, reducing duplication etc. … implying the need for deeper analysis to elaborate on and optimize the overall value, perhaps even a business case.
From there, it may or may not make sense to develop “Acme Corp’s Management Systems Unified Scope”, perhaps with a very bland and generic overall statement supported by more detailed appendices for each Management System … but at the end of the day, that’s just formal high-level documentation. In the same way, the supporting lower-level documents should also be designed to optimize the overall value and utility for diverse purposes and audiences. Are those to be designed and written in the same format? At what point (if any) in the hierarchy does it make more sense to separate the documents completely?
There will be both similarities and differences in the processes and activities being managed by the Management Systems. Any ‘risk management’ process, for instance, is clearly about ‘managing risks’ but the nature of the risks varies, hence the risk identification and analysis varies along with any subject matter experts who are involved, and the management, operational activities and controls arising.
From there, it may or may not make sense to develop “Acme Corp’s Management Systems Unified Scope”, perhaps with a very bland and generic overall statement supported by more detailed appendices for each Management System … but at the end of the day, that’s just formal high-level documentation. In the same way, the supporting lower-level documents should also be designed to optimize the overall value and utility for diverse purposes and audiences. Are those to be designed and written in the same format? At what point (if any) in the hierarchy does it make more sense to separate the documents completely?
There will be both similarities and differences in the processes and activities being managed by the Management Systems. Any ‘risk management’ process, for instance, is clearly about ‘managing risks’ but the nature of the risks varies, hence the risk identification and analysis varies along with any subject matter experts who are involved, and the management, operational activities and controls arising.
It is feasible to document the common elements of “Acme Corp’s Risk Management Process” at an overall level, perhaps supported by appendices elaborating on the differences for each kind of risk with the respective audiences in mind. Maybe. But that may not be helpful: there will be similarities between the approaches in practice even without a common overall document, and it may be more important to allow the individual approaches to vary according to the context (e.g. information, privacy and safety risks have some overlap but substantial differences too: trying to shoehorn them all through the exact same standard risk management process could be sub-optimal for each of them).