Getting control of IT security documentation

Does your IT department feel buried under mountains of paperwork? Expert Michael Cobb shows an easy way to organise your IT security documentation.

I recently helped a client pass the first annual audit of its ISO 27001 certification. I’m pleased to say my client passed with flying colours, but it was clearly struggling to keep the organisation's information security management system suite of IT security documentation and records up to date.

The workload involved in maintaining all these security logs was a strain on their resources and caused some resentment amongst administrators.

This was partly my fault, as when the organisation went for certified accreditation, I impressed the importance of having standard work instructions for common tasks and keeping records of events, incidents and changes to their IT infrastructure.

In the intervening period, it had spawned a multitude of Excel spreadsheets to log various changes, events and observations. It had comprehensibly captured all relevant information, but it was not easy to find or use. Some logs were barely used, while others carried entries duplicated elsewhere. On two occasions, we struggled to find and show the auditor the correct record for a specific event even though all the documentation was stored in one location on the file server.

The workload involved in maintaining all these security logs was a strain on the organisation's resources and caused some resentment amongst administrators, as it was seen as an overly onerous burden with little noticeable benefit.

It is never good when employees have this view of security. But ISO 27001 has several controls that cover the need for documentation and record keeping, and they need to be implemented and maintained to satisfy auditors, as well as to ensure information assets are correctly secured and maintained. In fact, the first control in ISO 27001 is A.5.1.1, which is an information security policy document.

The areas of ISO 27001 that seemed to be causing excessive amounts of work were A.13.1, “Reporting information security events and weaknesses”, and A.15.2, “Compliance with security policies and standards and technical compliance”. The control objectives here are to “ensure information security events and weaknesses associated with information systems are communicated in a manner allowing timely corrective action to be taken” and “ensure compliance of systems with organisational security policies and standards.”

In the case of my client, observations made during internal audits of suspected weaknesses or non-compliance were being recorded in an audit log and duplicated in a log of reported security weaknesses. On occasion, the reporting of a security weakness was also recorded as a security event. This meant that when an event or issue was closed out, all recorded instances had to be updated to document the outcome, and of course these sets of records quickly got out of sync. This led to people chasing problems that had already been resolved and confusion over system status at the regular information security forum meetings.

To remedy this situation, I combined the logs for information security events, weaknesses and non-conformities. As most of these logs were recorded in separate Excel spreadsheets, I moved them into one workbook. This put all issues relating to security problems, potential or real, in one place. The different types of records were colour-coded and rated according to severity, so a glance at the month’s entries gave a quick idea of the number and scale of any problems.

Having all problems recorded in one place makes it easier for administrators to ensure issues are dealt with and closed out in order of severity. It also helps improve the implementation of control A.6.1.2, which requires information security activities to be coordinated by representatives from different parts of the organization with relevant roles and job functions. Everyone is working from one status report based on one set of logs.

My next improvement was to bring the organisation's work instruction documentation under control. Control A.10.1.1 states operating procedures should be documented, maintained and made available to all users who need them, so I started by reviewing all policies and procedures and ensuring appropriate work instructions existed and were up to date. Work instructions are essential for tasks that are not performed on a regular basis to ensure they are completed correctly. However, familiarity with everyday tasks can lead to complacency and a work instruction that includes a checklist helps make sure no steps are missed from even routine tasks. This is why airline pilots run through a printed checklist prior to takeoff and landing.

Next, I went through each job description to ensure it included a definition of any security roles and responsibilities the job entailed - control A.8.1.1. I then supplemented this description with a reference to each work instruction relevant to that role. This helps management fulfil control A.8.2.1, which requires employees to apply security in accordance with the established policies and procedures of the organisation. Each employee can now easily check how to complete a specific task by following the appropriate work instructions listed in his or her job description. Of course, where a task involved recording information in a log, the instruction referenced the correct log file to ensure it was recorded in the right place.

My final change to the organisation's IT security documentation was to combine its information asset inventory with its asset ownership list, which involves controls A.7.1.1 and A.7.1.2. I also added each asset’s classification labelling requirements, as specified in control A.7.2.2, as an additional column.

While I've detailed them at length, what are in reality a few minor process changes have greatly reduced the time it takes my client’s network administrators to complete tasks and record information about the day-to-day management of IT systems. Although it is important to keep information security management system documentation compliant, it shouldn’t get in the way of security.

About the author:
Michael Cobb, CISSP-ISSAP, is a renowned security author with more than 15 years of experience in the IT industry. He is the founder and managing director of Cobweb Applications, a consultancy that provides data security services delivering ISO 27001 solutions. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. Cobb serves as’s contributing expert for application and platform security topics, and has been a featured guest instructor for several of’s Security School lessons.

Read more on IT risk management