Topic-specific policy 3/11: asset management
This piece is different to the others in this blog series. I'm seizing the opportunity to explain the thinking behind, and the steps involved in researching and drafting, an information security policy through a worked example. This is about the policy development process, more than the asset management policy per se.
One reason is that, despite having written numerous policies on other topics in the same general area, we hadn't appreciated the value of an asset management policy, as such, even allowing for the ambiguous title of the example given in the current draft of ISO/IEC 27002:2022. The standard formally but (in my opinion) misleadingly defines asset as 'anything that has value to the organization', with an unhelpful note distinguishing primary from supporting assets. By literal substitution, 'anything that has value to the organization management' is the third example information security policy topic in section 5.1 ... but what does that actually mean?
Hmmmm.
Isn't it tautologous? Does anything not of value even require management?
Is the final word in 'anything that has value to the organization management' a noun or verb i.e. does the policy concern the management of organizational assets, or is it about securing organizational assets that are valuable to its managers; or both, or something else entirely?
Well, OK then, perhaps the standard is suggesting a policy on the information security aspects involved in managing information assets, by which I mean both the intangible information content and (as applicable) the physical storage media and processing/communications systems such as hard drives and computer networks?
Seeking inspiration, Googling 'information security asset management policy' found me a policy by Sefton Council along those lines: with about 4 full pages of content, it covers security aspects of both the information content and IT systems, more specifically information ownership, valuation and acceptable use:
1.2. Policy Statement
The purpose of this policy is to achieve and maintain appropriate protection of organisational assets. It does this by ensuring that every information asset has an owner and that the nature and value of each asset is fully understood. It also ensures that the boundaries of acceptable use are clearly defined for anyone that has access to the information.
Interesting! I like the way they summarize the policy, condensing it down to just a couple of key sentences. From the busy and easily-distracted reader's perspective, this important chunk determines whether they should continue reading and taking notice of the remainder of the policy. From the policy developer and authorisers' perspectives, it focuses attention on the stated matters.
Aside: our policies all include policy axioms, generally just one or two of them. Crafting these is harder than it looks - balancing readability against formality and tone, while remaining on-topic. In practice, we find a separate policy summary in a less formal and stilted style is also worthwhile, as well as a set of supporting policy statements with details expanding pragmatically on the axioms, giving workers the guidance to know what they are expected to do in practice to comply with the policy and so satisfy management's stated objectives.
Re Sefton, we already have policies covering information ownership and classification which, arguably, is a form of [e]valuation, plus a pack of eight Acceptable Use Policies, albeit closer to guidelines than policies in style. But how does the council policy differ?
I notice the council's listing of "important" information assets:
- filing cabinets and stores containing paper records
- computer databases
- data files and folders
- software licenses
- physical assets (computer equipment and accessories, PDAs, cell phones)
- key services
- key people
- intangible assets such as reputation and brand
Ignoring the now dated technology references (in this ancient 2008 policy!), I'm impressed that it not only recognises the value of paper records as well as computer data, but calls out the final three bullet points: those are not commonly considered in this context (we the people are much neglected!), but they are undoubtedly highly valuable forms of information - cloud services for a modern day example, plus intellectual property and trade secrets. They are clearly all assets, however defined. I quite like the thought of the policy emphasizing particularly valuable information assets ... although I'd change the emphasis a little towards high-risk information assets, linking the policy to information risk management.
I'm angling towards developing an "Information [asset] protection policy" at this point, as opposed to an "Asset management policy". The title of a policy is quite important, being an obvious indication of its coverage and purpose. Don't be fixated on the particular policy examples given by '27002, especially the more ambiguous ones such as this and, yes, even "information security policy". Adopting the wrong (misleading, inappropriate, ambiguous ...) title markedly increases the risk that workers will blithely disregard it without even taking the trouble to read the content, and could cause managers to misunderstand it, mistakenly believing the organisation has a policy on a distinct topic. What a waste, an opportunity lost!
Sefton Council's policy goes on to mandate an [information] asset inventory, a control listed separately in Annex A of ISO/IEC 27001 and explained in '27002. The underlying principle is obvious: management needs to appreciate their [information] assets in order to both protect and exploit them appropriately, maximising their value. So that's something well worth considering ... but pragmatically. Based on experience, I'm keen to avoid the inventory taking on a life of its own, sucking in resources beyond the point that it adds net value. It has to be a useful tool for business purposes, not an objective in its own right. That means keeping it to the essentials, cataloguing just those high-risk information assets, perhaps ... which brings it closer to a risk register in style. Maybe they can be combined - something as simple as a column in the risk register listing the associated information assets?
What else?
Among other things, the information asset management policy from the Lamar Institute of Technology covers information disposal, prompting another consideration: information assets have cradle-to-grave lifecycles during which their value and the associated utility and risks vary. Should this be reflected, somehow, in the policy? I'm idly thinking of constructing a circular diagram to point out the key risk and security aspects visually - a picture to break up the turgid mass of words in almost all formal policies, increasing readability and engagement for at least some readers ...
... which leads me to another aspect: who is (or are) the audience for the policy? Who is it for? What is its intended purpose? What is it meant to achieve for the organisation? These rhetorical questions are worth addressing, briefly, in the policy preamble/introduction.
Also, how will the policy generate more value than it costs to design, develop, review, mandate, publish, implement, achieve compliance and maintain? These are not inconsiderable costs, although I have never (yet!) seen this overtly considered after someone sets the process rolling with 'We need a policy on X. Make it so!'.
There are things that can be done to minimise the costs and maximise the value of policies, like for instance:
- Engaging people with the right expertise for the policy development process, including a professional competent in effective business communications as well as the subject matter of information asset management, risk, security and all that - someone with the talent, expertise, knowledge and passion for both the process and the end product. A small, focused core team (perhaps just one or two people) is supplemented at the relevant point by interacting with representative implementers, trainers and auditors, plus reviewers and authorizers from management.
- Treating the development of a policy as a small project, applying conventional (hopefully highly efficient and effective!) project management techniques and appropriate (lightweight) governance arrangements. As with software development
- Investing thinking time and energy into the policy specification, research and design phase, rather than blundering directly into the writing. Remember: Steady > Aim > Fire is the preferred sequence. It's the same, by the way, if you are reviewing and maintaining existing policies: clarify the destination and plan the route before blundering into the forest of issues ahead.
- Using a corporate template to speed the process along while producing a policy in the organisation's preferred style and format that is consistent with the content of other policies (e.g. cross-referenced, using some sort of policy matrix or map). Naturally, someone first needs to design and develop such a template, possibly even mandate it through a policy management policy if that helps (cue spinning head!).
- Using a commercial policy template as a quick-start, a basis for the customisation inevitably needed by the organisation. Bear in mind, though, that after purchasing and using a single policy template, you will probably want more if it worked well for you, which is fine if the supplier offers a comprehensive, coherent, consistent suite of policies of the same quality at a reasonable price. Think ahead a little. Do you need a point solution covering a specific policy matter, or an integrated system of good practice policies and controls covering the entire gamut of information risk, security, privacy and so forth, in the context of corporate/business objectives, governance and compliance?
- Seeking honest feedback regarding the existing policies from those actively involved in their management, use, authorisation, assurance etc., refining the whole policy management process accordingly, rather than simply updating or withdrawing/replacing problematic policies individually. This is part of the maturation of an ISMS and the organisation's approach to information risk, security and related areas.
