Should all applicable controls be mentioned in documenting an ISMS?

In my very first job we were told, repeatedly told, to document everything and keep our personal journals up to date. Not just with what we did but the reasoning behind those decisions. This was so that if anything happened to use kn knowledge about the work, the project, what had been tried and thought about was lost, if, perhaps, we were ‘hit by a bus on the way to work‘.

At that point whoever was saying this looked toward a certain office or certain place in the parking lot. One of the Project managers drove a VW bus and was most definitely not a good driver!

So the phrase ‘document everything in case you’re hit by a bus’ entered into the work culture, even after that individual had left.

And for the rest of us it entered into our person culture and practices.

Oh, and the WHY is very important. How often have you looked at something that seems strange and worried about changing it in case there was some special reason for it being like that which you did no know of?
Unless things get documented …. Heck a well meaning ‘kid’ might ‘clean it out’ ignorant of the special reason it was like that!

So here we have what appear to be undocumented controls.
Perhaps they are just controls that were added and someone forgot to mention; perhaps the paperwork for these ‘exceptions’ is filed somewhere else[1] or is referred to by the easily overlooked footnote or mentioned in the missing appendix.

It has been pointed out to me that having to document everything, including the reasons for taking one decision rather than another, “slows down work”. Well that’s been said of security, too, hasn’t it? I’ve had this requirement referred to in various unsavoury terms and had those terms associated with me personally for insisting on them. I’ve had people ‘caught out’, doing one thing and saying another.
But I’ve also had the documentation saving mistakes and rework.

These days with electronic tools, smartphones, tablets, networking, and things like wikis as shared searchable resources, its a lot easier.[2]

Sadly I still find places where key documents such as the Policy Manuals and more are really still “3-ring binder” state of the art, PDF files in some obscure[1] location that don’t have any mechanism for commenting or feedback or ways they can be updated.

Up to date and accurate documentation is always a good practice!

[2] And what surpises me is that when I’ve implemented those I get a ‘deer in the headlight’ reaction from staff an managers much younger than myself. Don’t believe what you read about ‘millennials’ being better able to deal with e-tools than us Greybeards.

About the author

Security Evangelist


  1. I do a lot of writing of tooling, mostly for my own personal use. I’ll use the tool for years, and it slowly develops new appendages as needs evolve.

    > Heck a well meaning ‘kid’ might ‘clean it out’ ignorant of the special reason it was like that!

    What I find is that well meaning ‘kid’ is myself six months or a year later — why the heck did I write it like that? Oh, well, it was probably just something awkward… and then several days later (and hooray for RCS) I figure out that it *had* to be that way. So yeah, TiddlyWiki for ongoing microcontent aggregation, and extensive code documentation is the only way to keep from wasting a lot of time.

  2. Documents are of course a good way to record, store and replay information. They’re also good for sharing stuff with colleagues or other interested parties. They constitute evidence, provide guidance and instruction, and so forth.

    As if that’s not enough, the *process* of documenting something can itself be a valuable activity. Authors are forced to think through what they are trying to say, get their thoughts in order, structure the content, and generally make the effort to express themselves. They often need to research, reading and building upon other works.

    These days, collaborative approaches bring authors, researchers, critics and creatives together, pooling and feeding off each others’ knowledge, expertise and creative energies. It’s great fun when the team gels.

Leave a Reply