NBlog Nov 18 - enough is enough

Keeping ISO27k Information Security Management Systems tight, constrained within narrow scopes, avoiding unnecessary elaboration, seems an admirable objective. The advantages of ISMS simplicity include having less to design, implement, monitor, manage, maintain, review and audit. There's less to go wrong. The ISMS is more focused, a valuable business tool with a specific purpose rather than a costly overhead. 

All good. However, that doesn't necessarily mean that it is better to have fewer ISMS documents. In practice, simplifying ISMS documentation generally means combining docs or dispensing with any that are deemed irrelevant. That may not be the best approach for every organization, especially if it goes a step too far.

Take information security policies for example. Separate, smaller policy docs are easier to generate and maintain, {re}authorize and {re}circulate individually than a thick monolithic “policy manual”. It’s easier for authors, authorisers and recipients to focus on the specific issue/s at hand. That's important from the governance, awareness and compliance perspective. At a basic level, what are the chances of people actually bothering to read the change management/version control/document history info then check out all the individual changes (many of which are relatively insignificant) when yet another updated policy manual update drops into their inbox? In practice, it aint gonna happen, much to the chagrin of QA experts!

On the other hand, individual policies are necessarily interlinked, forming a governance mesh: substantial changes in one part can have a ripple effect across the rest, which means someone has the unenviable task of updating and maintaining the entire suite, keeping everything reasonably consistent. Having all the policies in one big document makes maintenance easier for the author/maintainer, but harder for change managers, authorisers and the intended audiences/users.

As if that’s not challenging enough already, bear in mind that information risk and security is itself just part of corporate management, with obvious links to IT, risk management, HR, compliance and many other areas, some of which are more obscure or tenuous (e.g. health & safety is an information security issue in the sense that people are information assets worth protecting). The ripples go all the way, and flow both ways: changes in, say, IT or HR policies can have an effect on information risk and security, requiring policy updates there too.

Even within the ISMS, extending your policy management approach to take in the associated procedures plus awareness and training materials multiplies the problems. Extending it to include myriad other ISMS-related documentation makes it worse again. 

Alternative approaches include using a ‘document management system’ or ‘policy management system’ – essentially a database system used to manage and control the materials as a coherent set – and hybrid approaches such as Word’s “compound document” facility – with one master doc linking to all the subsidiary docs, one for each policy. Here again there are pros and cons, not least the costs involved plus the rigidity and red-tape they inevitably introduce.

Rationalising and simplifying the ISMS documentation to reduce the practical problems and costs clearly makes a lot of sense, but be careful: information risk and security is an inherently complex, far-reaching concept. There’s a lot to it. If for instance you drop a given policy from the ISMS suite on the basis that it is only marginally relevant, too narrow, too obscure or whatever, that leaves you without a stated policy in that area, which may have implications elsewhere, implications that may not be immediately obvious. Damn those ripples!

Bottom line: governing, structuring, managing and maintaining ISMS documentation is tougher than you may think. The trick is to find the best balance point for your organization, specifically, and the generic standards can only offer so much guidance on that.