PRAGMATIC policy metrics

PRAGMATIC information security policy metrics

First, to set the context for this piece, let me be explicit about four important presumptions:

1. "Policy" means a clear statement of management intent or direction or control - a written set of high-level requirements or constraints over what employees should and should not do under certain circumstances, considered and laid out by management, and formally mandated on everyone in the organization.
2. Management is more than merely 'concerned' to achieve compliance with the corporate policies: they have implemented a suite of compliance-related processes and activities with the goal of achieving a high level of - though not necessarily total - compliance (e.g. there is a formalized way of identifying and handling policy exceptions and, where appropriate, granting exemptions).
3. Employees are aware of their obligations under various policies.  They have ready access to the policies, and they are actively encouraged to read them and comply.  The policies are written straightforwardly enough to be readily understood, and there are suitable support mechanisms for anyone who needs help to understand and implement the policies.  Policies are generally considered sensible, appropriate and necessary - not draconian or frivolous.  There are change-management activities supporting their introduction, as well as subsequent reviews and updates.
4. Enforcement is treated as a last resort, but management is willing to apply suitable penalties firmly and fairly if that is what it takes to achieve compliance.  More than that, policies are actually enforced, contravenors are penalized, and everyone understands that there probably will be adverse consequences for them (at least) if they break the rules.

If those presumptions hold true, I would argue that there is value in using metrics to support the policies.  Compliance-related metrics are obvious candidates but there will usually be others that relate to the subjects, purposes or objectives of the policies.  

For example, suppose there is a corporate policy about the use of cryptography concerning its use for encryption, authentication and integrity purposes.  Suitable metrics in each of these areas should support the need for the policy in the first place, such as by identifying what proportion of systems are still using deprecated algorithms or weak keys.  Once the policy is approved, tracking and reporting the same metrics ought to show how effectively the policy is proving in practice at dealing with the issues.

That in turn suggests the possibility of proactively stating and using metrics in policies, perhaps a discrete metrics section specifying compliance and subject-matter metrics in the same way as policies usually state 'responsibilities' and 'compliance'.   Metrics may also be used in the preamble or introduction or background (within the policies and/or in the accompanying emails, awareness and training materials to accompany their implementation), helping to explain and justify the need for the policies, putting meat on the bones rather than the usual vague assertions about risks.

Naturally, I'm talking about PRAGMATIC metrics, implying that thought should be applied to the specific choice of metrics, which in turn implies that someone is thinking quite deeply about the specific requirements and purposes of the policies - no bad thing in its own right.  

If those presumptions do not hold true, policy metrics are probably not at the very top of your to-do list, but bear them in mind.  Now may be a good time to seed the idea with your more enlightened colleagues.