It's unlikely that you will read a more dull and despairing title for a practical blog series than "Document & Review", and there is a high chance that you will even consider skipping this one. If you do, however, you will be missing the most foundational aspect of your entire information security programme. Without documentation in the form primarily of Policies, Procedures and Guidelines, you have nothing with which to build your grand information security plan upon. Nothing to reference, fall back on, or even educate people with.
Neil Postman, American author, educator, media theorist and cultural critic, summed it up:
"The written word endures, the spoken word disappears."
If you want to build for the future, you need to ensure your message, whatever that might be, endures over time, is easily understood and referenceable throughout its lifetime.
You may think that this is obvious and everybody knows there has to be documentation, as who hasn't heard the refrain "it's in the policy, go read it!"? That said, subsequently pointing towards a meaningful policy document, procedure or guideline doesn't always produce the results intended. Policies are overly long and descriptive, Procedures either repeat the policy or don't exist, and the story is similar for Guidelines as well.
So, dear reader here is the low down on what each of those terms means and their relationship to each other, laid bare and thoroughly before you:
The policy is a high-level document, that after it's first 6-12 months of existence won't change very often, perhaps every 3-5 years.
It defines the requirements of people, departments and the organisation as a whole, but without specifying the technology or specifics needed to make it happen. For example, here is a statement from a poorly written policy about email security:
"All email transmissions must be protected using the TLS 1.3 protocol to avoid unauthorised interception."
A better policy statement would be:
"All email transmissions must be protected to avoid unauthorised interception."
It is a simple change, but one that is not overly specific and gives the IT team the choice of method of securing email that makes the most sense for them. As such policies (and to a greater extent, the security team as a whole) are technology agnostic, focussing the policy on outcomes and not delivery methods.
Finally, for policies, focus on clear, understandable language that does not use TLAs* or other jargon; policies are designed for as broad a readership as possible and help support educational activities.
A procedure should follow naturally from the policies it supports in that it takes the required outcomes as laid out in the policy and then defines how it is to be achieved. The definition of TLS 1.3 is precisely the kind of information that is described in the procedure from the above example. Therefore a procedure has a more frequent update cycle, i.e. whenever technology or working practises change.
It's important to note that the terms "Policy" and "procedure" are often used interchangeably, and yet nothing could be further from the truth. A policy does not state how something is to be achieved, merely that it needs to be achieved. Additionally, a policy may be supported by multiple procedures.
A guideline is a document where the security function can get involved in the technology! It could describe a best practise for implementing email, for instance. It may well define what version of TLS should be used along with other information about hardening the email server, and will inform the reader accordingly. It does not have to be adhered to, and it is not mandatory to follow the guidance in there. Dependent upon the culture of the company and the relationship between the security function and the rest of the company, it may also be defined as a Standard. In contrast to a guideline, the standard is a mandatory requirement and establishes minimum expected requirements for the activity/services it supports. A guideline and a standard may be used somewhat interchangeably, while the intent and adherence to them are different.
As you might expect, there are some good practises when managing this kind of documentation that should be adhered to:
Fix a schedule and adhere to it. Every document should be reviewed at least once a year, or whenever there is a significant change in technology, process or even culture. Out of date documentation can slow a business down, inhibit innovation and mark the security team out as gatekeepers.
Always have version control, formal sign off procedures and clear ownership and accountability of every single document. It is an overhead, but one that ensures any audit or review is passed with ease, and also warrants the documentation is up to date, and more importantly, relevant.
Policies should be made available to everyone. Liaise with the HR department, include them in the staff handbook, have them posted on the intranet and reference them accordingly. Procedures and guidelines by their nature will have a more limited audience, but make sure that the audience knows where they are.
These documents should be approved at the appropriate levels, and that is dependent upon the work environment. However, as a rule of thumb policies should be approved by company leadership, procedures by department heads and guidelines/standards by the senior technical lead. In this way, there is a clear hierarchy of ownership, and the documents create a support structure building upwards.
This sounds like a lot of work...
It potentially is, especially in the early days of setting the programme of work up, but its importance cannot be emphasised enough. Without these foundational documents in place, there is no linchpin to define and guide current and future activities, no frame of reference describing how individuals and the company should behave and work. Finally, there is also no way of actually proving that the security function is meeting its goals and objectives as approved by the company leadership.
Define what you do and ensure your message will endure.