SMotW #76: Policy quality

Security Metric of the Week #76: quality of information security policies

Poor-quality, badly-written policies:

Are less likely to be understood by the people they are meant to guide/direct/control;
May neglect, under-play or mis-state certain obligations or requirements;
Are probably not being actively maintained and so are probably outdated;
May conflict with other policies, plus strategies, standards, procedures, guidelines, laws, regulations etc.;
May create legal liabilities or open up opportunities for people or organizations to claim they don't apply, are unworkable, are unreadable etc.;
May create excessive, unnecessary or inappropriate requirements and costs (red-tape);
Give the appearance of expressing management's intent but in fact probably do not (fully) address the information security issues/risks they are supposed or intended to address;
Don't work - compliance is likely to be low, they are more likely to be flaunted or openly ignored;
Reflect badly on the professionalism of their authors, and on the value and importance of the information security program as a whole;
Indicate a lack of concern and support for information security by management, bordering on carelessness, neglect or disrespect, most likely reflecting a serious underlying governance issue.

Those are pretty severe consequences if you think about it. Policies, along with the associated policy lifecycle management/maintenance processes, authorization, awareness/training, compliance activities etc. are therefore an important element of the organization's information security. No wonder they are explicitly required in clause 5.2 of ISO/IEC 27001:2013 and section 5 of ISO/IEC 27002:2013, as well as most other information security standards and frameworks and even some laws.

As a consultant, I can tell a lot about an organization's information security status simply by reviewing its policy-related materials. The quality and style of the writing says as much as the literal content. An hour or three spent in a quiet corner reading and contemplating the policy stuff will answer questions such as:

Do the policies read well? Are they straightforward, easy to understand, well-structured, sensibly laid out? Is the grammar and spelling OK? Is there a standard, recognizable structure and layout for all of them?
Are they relevant, interesting even? Do they bother to explain why they exist, the context, background and purpose of the controls laid out? Do they make a case for compliance, or simply insist?
Is there evidence of a grand design - a coherence and fit between related policies? No significant overlaps or gaps? No bald conflicts or nonsense? Do they follow a recognized structure or framework (such as ISO27k, COBIT, SP800, BMIS ...) or does it look like someone has been busy reinventing the wheel?
Are they pragmatic, workable, usable ... or are they theoretical, unduly formalized, stilted and essentially unworkable? [Hint: legalese, pseduo-legal jargon and archaic terms such as "including but not limited to" and "heretofore" are big flappy red flags as far as I am concerned. Such language usually indicates that someone who is NOT legally-trained has been in charge or involved in the writing, and has tried to appear clever. If your corporate lawyers or other professionals actually insist on incorporating that kind of tripe in your policies, you have my deepest sympathies for the constraint.]
Does it appear that they are being actively maintained? Are they up-to-date with current risks and controls? Is there a nominal owner, someone with sufficient seniority and gravitas to make people at all levels (including senior management!) aware that they are obliged to comply? Is there evidence of a timely review and (re-)authorization process? Is there version control and a history of changes?
Is there evidence that they are taken seriously e.g. formal authorization or mandate, stated applicability and scope?

The icing on the cake for me includes things such as stating compliance obligations plus related roles and responsibilities, associated metrics, and explicit cross-references to related policies, procedures, standards, laws, regulations etc., including those that fall outside the remit of the Information Security Management function (e.g. HR policies, legal/regulatory compliance policies, risk management and audit policies) ... but, at the same time, I give bonus marks for conciseness and clarity!

Anyway, the green pie chart demonstrates the kind of metric that ACME Enterprises had in mind when their managers were assessing and scoring this as a potential information security metric. The idea is for someone appropriate to review and classify the policies (and perhaps related materials) using criteria derived along the lines of the notes above. ACME's PRAGMATIC ratings for this metric were as follows:

P	R	A	G	M	A	T	I	C	Score
80	85	40	66	72	75	80	80	80	73%

With most ratings hitting the 70s and 80s, the only real fly in the ointment was Actionability at 40% since the pie chart does not indicate why certain policies were deemed of low quality, nor which policies were in the lower quality categories, hence it is not readily apparent what needs to be done to improve the metric. It's obvious how that issue could be addressed (asking the assessor/s for more information) for an even higher score, making this security metric a strong candidate for ACME ... and, we suggest, for almost every organization, given the aforementioned importance of security policies.

And yes, 'aforementioned' is one of those archaic words I despise!