What have policies ever done for us?

Why do we have policies, procedures and all that jazz? What are they and what are they for?  What do they actually achieve?  What would happen if we didn't bother at all?  What else could we do instead - are there better ways?  

Those rhetorical questions were prompted by a disarmingly simple and naive-sounding question on the ISO27k Forum this morning, viz "I am looking at implementing iso27001. How do I know if I need a policy or procedure in place?" 

Good question!

In relation to ISO27k and to information risk and security in general, policies and/or procedures are needed in order to:

• Address information risks that are of concern to the organization, or more specifically to management and other stakeholders;
• State or express management's intentions formally in various areas;
• Communicate and clarify things to the intended readers, giving them clear guidance (e.g. work instructions, awareness and training materials);
• Satisfy requirements stated explicitly in ISO/IEC 27001(assuming the organization intends to be certified compliant);
• Satisfy other relevant and applicable requirements (e.g. under privacy laws and regulations, or for contractual reasons);
• Promote good practices through a stable, mature, considered, structured and systematic approach, allowing continuous review, updates and improvement where needed;
• Integrate various approaches in a coherent manner (e.g.information risk and security, plus privacy, plus business continuity, plus compliance, plus physical security, plus .... plus ...);
• Demonstrate to all concerned (insiders and outsiders) that various issues have been considered and desired approaches have been determined, while generally implying that other possible approaches have been discounted and are not required, perhaps even not approved or authorized;
• Enable assurance checks and formal compliance enforcement purposes, in which case they need to be unambiguous: clearly written, clearly applicable, clearly mandated ...;
• Ensure consistency of operations and response; *
• Allow for reporting and metrication of results; *
• Stop people guessing or making stuff up on a whim, or at least reduce this in certain areas while giving them more latitude in other areas;
• Emphasize and focus attention on Stuff That Matters.

* Additional objectives contributed by Anton Aylward - thanks Anton!

As to 'policy' and 'procedure', individuals and organizations quite often interpret those and related terms differently. Dictionary definitions are generally   definitive.

ISO/IEC 27000 defines some terms explicitly in the context of the ISO27k standards including:

• “Documented information” means information required to be controlled and maintained by an organization and the medium on which it is contained [i.e. ‘documentation’ in common parlance];
• “Policy” means intentions and direction of an organization, as formally expressed by its top management [where organization and top management are also explicitly-defined terms];
• “Process” means set of interrelated or interacting activities which transforms inputs into outputs [where none of those terms are explicitly defined!].

By the way, "insurance policy" neatly demonstrates a key difficulty in defining words individually, in isolation from the context. An insurance policy is not the "intentions and direction of an organization, as formally expressed by its top management" - it is a legally binding agreement, a contract between the parties concerning the insurance arrangement. "Foreign policy" is different again, and so on. Dictionaries tackle this situation by providing multiple, distinct or related definitions and examples, illustrating the defined terms being used in typical statements. ISO/IEC 27000 backs into a corner by giving just one definition and no context.

To make it worse, several key words and terms (including "key", for one!), are undefined. “Procedure” is not explicitly defined … but is used throughout ISO27k including 27000 itself where “processes and procedures” suggests they are distinct, and “policies, procedures and practices” implies further [also undefined] distinctions.

“Procedure” to me means the description of a “process” which is generally a sequence of “activities” which may be “tasks” or “decisions” or something else (e.g. “Wait patiently for authorization”). The manner of their description may be step-by-step instructions, flow diagrams, demonstrations, notes or some other format, usually captured in some form so that it can be more easily and consistently specified, stored, standardized, reviewed and authorized, communicated/used, and improved.

I have my own personal documentation preferences and styles. Given the choice, I prefer clear at-a-glance diagrams over tedious paragraphs of text for procedures, although both and more may be needed. For corporate policies, I much prefer readable plain English over the curious pseudo-legal mumbo-jumbo that is depressingly common in practice. But then IANAL: I'm a technical author writing information risk and security policies, procedures, training guides and awareness materials for ordinary people.

If a client uses different terms or interpretations, has particular requirements such as specific documentation formats and styles, needs their mumbo to be jumbo or whatever, that’s fine by me. He who pays the piper calls the tune!  

So, apart from all that, what have security policies ever done for us?