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.
No comments:
Post a comment