The Matrix, policy edition

Inspired by an insightful comment on LinkeDin from an SC 27 colleague on the other side of the world (thanks Lars!), I spent most of last week updating the SecAware security policy templates and ISO27k ISMS materials.

The main change was to distinguish conformity from compliance - two similar terms that I admit I had been using loosely and often incorrectly for far too long. As I now understand them:

• Compliance refers to fulfilling binding (mandatory) legal, regulatory and contractual obligations;
  
• Conformity concerns fulfilling optional (discretionary) requirements in standards, agreements, codes of ethics etc. 

It's a fine distinction with implications for the associated information risks, given differing impacts:

• Noncompliance may lead to legal enforcement action (fines/penalties), other costly sanctions (such as more intrusive monitoring by the authorities and perhaps revocation of operating licenses) and business issues (such as reputational damage and brand devaluation, plus the costs of defending legal action). 
• The consequences of nonconformity may be trivial or nothing at all if nobody even cares, but can also involve business issues such as inefficiencies, excess costs and so on, particularly if customers, business partners, the authorities or other stakeholders are seriously concerned at management's apparent disregard for good security practices.

Certification of an organisation's ISMS, then, demonstrates its conformity with, not compliance to, ISO/IEC 27001 - well in most cases anyway, where management voluntarily chooses to adopt and conform to the standard. If they are obliged by some mandatory, legally-binding requirement (an applicable law or regulation, or perhaps terms in a formal contract with a supplier or customer, perhaps due to a law or regulation that pplies to them), I guess they must comply.

 

Putting that another way, nonconformity is an option. Noncompliance isn't.

Anyway, having adjusted the terminology and tweaked the SecAware materials, I took the opportunity to prepare two new 'bulk deal' packages - a comprehensive suite of information security policy templates, and a full set of ISO27k ISMS materials. I'm hoping to persuade customers to spend invest a little more for greater returns. 

The SecAware policies, for instance, are explicitly designed to work best as a whole, an integrated and coherent suite as opposed to an eclectic collection of policies on various discrete topics. In recent years, I have developed a spreadsheet to track the mesh of relationships between policies:

Yellow blobs on the matrix indicate touch-points between policies, issues of common concern. For example, blobs in the access control policy column mean the policy is related in some way to policies on business relationships, clear desk and screen, cryptography, database security and so on. 

If, say, a organisation has an access control policy but currently lacks a policy on the information risk and security aspects of business relationships (e.g. with its Internet and cloud service providers), that may represent a gap in its policy framework unless the access control policy happens to cover business relationship security as well. Likewise with all the other related aspects. While technically it would be possible for the access control policy to cover the lot, in practice that would be 'suboptimal', resulting in an unfocused, unweildy, convoluted and confusing policy, especially if each policy went into detail on related topics.

[Trust me, I know. BTDT. Years back I developed an 'Information security policy manual' as a single document. It was a headache to maintain and having grown to about 150 pages, a nightmare to read and understand. The 'policy suite' approach with a collection of topic-specific policies works better for me and our clients.]

The relationships are bidirectional, by the way: access control is relevant to business relationship security, and vice versa. That markedly simplifies the matrix since blobs to the right of the black diagonal would be a mirror image of those to the left.

The matrix is a surprisingly useful policy management tool, a simple, visual way to maintain the complex relationships between policies in the suite. A few days ago, for instance, I added entries for three new policies on responsible disclosure, threat intelligence and data masking/redaction. Updating the matrix involves determining, for each policy, which related areas are significant enough to merit blobs. It's worth checking that the linked policies don't both cover the same issues, at least not in any detail and especially not in conflicting terms - although, having personally written and regularly maintained these policies for decades, I already have a pretty good idea about what the related policies do and don't say. It's getting harder, though, as the suite approaches 80 topic-specific policies (!) plus 8 Acceptable Use Policies and an overarching Corporate Information Security Policy and, frankly, I'm getting on a bit.

The security architectural objective is to ensure that all relevant policy matters are covered clearly and unambiguously, leaving no significant gaps or overlaps. The policies need to interlock, supporting each other and strengthening the entire control construct. That's important from a governance perspective since policies are a primary mechanism for exerting management direction and control over the organisation.

So, there you have it, a Hinson tip for managing a complex mesh of information security or indeed other policies, something worth contemplating at least. I commend it to the house.