Getting the documentation right

One of the stated objectives of this blog is to describe some of the operational challenges that I encounter on a day-to-day basis. My role is certainly challenging with a good deal of variety: one day I might be conducting a risk assessment on behalf of any one of more than two hundred business units, and the next being of assistance to a development group requiring guidance on how to achieve regulatory compliance. A lot of my job is writing reports and updating various internal guidelines and standards. It sounds mundane but our documentation is a part of corporate governance and so it’s important that it’s suitable for the audience to which it’s aimed.

I think that over the years I’ve become quite accomplished in creating documentation in “business speak” with just the right amount of technical detail and just the right amount of executive blurb. But it’s not all plain sailing and certainly not without its pitfalls: much of the target audience for what I write is American: and as we all know, they may speak a language that sounds like English but it isn’t – it’s American! I’m still not fluent – just ask my American boss – if I had a dollar for every red line he put into my document submissions I’d have enough to have lessons – and my blunt British statements frequently have to be replaced with their Americanese equivalents.

Anyway, onto the point of todays blog: some of my recent work on documentation has been criticised for being too technical in it’s language for the target audience. The target audience is senior non-technical management and the objective of the work in question is to ensure that they follow set procedures within our risk management plan.

The feedback has come at just the right time: it’s crucial that the right people know the right processes to follow. Fortunately I don’t work alone: I have some fantastic colleagues and we work as a team in resolving these types of problems – we also have various “virtual teams” that also provide feedback. So todays operational challenge is to get my revised guidance documentation written and out to the right people to review and hope not to have to go through too many more iterations before it’s considered acceptable.

I read David Lacey’s blog entry today with interest – particularly about the solution offered by Secerno. A colleague of mine, suitably impressed, recently recommended I take at look at the solution offered by this company. I’ve not had the opportunity to do so yet in any detail however, on paper it appears to be a very interesting product. One problem I would have is in trying to justify a very specialist point solution to place into a server room already brimming with point solutions. Who’s going to manage it, configure it, upgrade it…you get my point. And how much risk mitigation do we buy? And please don’t talk to me about potential ROI: I’ll make the rather contentious statement that you wont get any and that you don’t get any with most of what count as information security solutions. And if that doesn’t provoke some comments onto this blog then I don’t know what will!

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

Stuart, The same-old whitelist security solutions will always swallow management resource and simplistic ROI calculations never fully account for this (or such solutions' frequent ineffectiveness!) David Lacey spotted something different in Secerno - a low maintenance approach that is actually effective. He also wrote a white paper on how to make a full business case, taking all factors into account. I recommend it to anyone sceptical of the usual simplistic ROI approaches. It's downloadable from