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 primarily of Policies, Procedures and Guidelines, you have nothing 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 must ensure your message, whatever that might be, endures over time and is easily understood and referenceable throughout its lifetime.
You may think 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 only sometimes produces 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.
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
The policy is a high-level document that, after its 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 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 that gives the IT team the choice of a method of securing email that makes the most sense for them. 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.
The Procedure
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. For example, the definition of TLS 1.3 is precisely the information described in the procedure from the above example. Therefore a procedure has a more frequent update cycle, i.e. whenever technology or working practices change.
It’s important to note that “Policy” and “Procedure” are often used interchangeably, 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.
The Guideline
A guideline is a document where the security function can get involved in the technology! It describes a best practice for implementing email. 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 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 interchangeably, while the intent and adherence to them are different.
Good Practise
As you might expect, there are some good practices when managing this kind of documentation that should be adhered to:
Review Schedule
Fix a schedule and adhere to it. Every document should be reviewed at least once a year or whenever a significant change in technology, process or even culture occurs. Out-of-date documentation can slow a business down, inhibit innovation and mark the security team out as gatekeepers.
Version control
Always have version control, formal sign-off procedures and clear ownership and accountability of every document. It is an overhead that ensures any audit or review is passed with ease and warrants that the documentation is up to date and, more importantly, relevant.
Distribution
Policies should be made available to everyone. Liaise with the HR department, include them in the staff handbook, post them on the intranet and reference them accordingly. Procedures and guidelines will have a more limited audience, but make sure that the audience knows where they are.
Approvals
These documents should be approved at the appropriate levels, depending on 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 ownership hierarchy, and the documents create a support structure building upwards.
This sounds like a lot of work…
It is, especially in the early days of setting the work programme up, but its importance cannot be emphasised enough. Without these foundational documents, there is no linchpin to define and guide current and future activities and no frame of reference describing how individuals and the company should behave and work. Finally, there is no way of 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.
Thom Langford 