ISO 27001 standard: Breaking the documentation myth
by Mirko Zorz - Friday, 22 June 2012.
Based on the feedback you get from your clients who begin writing the ISO 27001 documentation, what do they struggle with the most?

Most of them struggle with what I call the “documentation myth”. Before they start implementing the standard, they think it will be enough to write a couple of documents, show them to the certification auditor, and that's it – as simple as that, just a couple of days of work.

However, the reality is much different – first of all, they realize that writing the documentation is not that easy. For example, when you have to write the Risk Assessment methodology, not only must you know how to perform risk assessment, but you also need to know how to adapt it so that is suits your organization. After all, you don't want to spend the next 6 months wasting resources doing only risk assessment, and this process is determined mainly by your methodology. Therefore, writing it requires quite a lot of experience, and enough time to figure out what is best for the organization.

Secondly, once they have made quite an effort in writing a particular document, they realize that such a document doesn't make any sense if it is not implemented. But the problem is that changing habits is not easy – e.g. if a password policy requires that everyone changes passwords every 6 months, it is not something the employees are going to be very happy about. This is a point where training and awareness programs need to be performed, because without them such a change will fail.

What advice would you give to an organization preparing for an audit?

It really depends on the type of an audit – whether it is internal or external. Internal audits are often perceived as an overhead, as something that needs to be done “because the standard says so”. A very small number of companies use it for its real purpose, which is to help improve their security. The thing is – if an auditor is experienced and has the right approach, he will be in the best position to find out where the security problems are. So the main point of internal audit is to uncover all those nonconformities and initiate a structured approach to resolving them (also called “corrective actions”).

I consider external audits to be quite useful because they set a concrete deadline to finish all the implementation work, which urges companies to give priority to this kind of a project. The main difference when compared to an internal audit is that you need to be ready – and being ready means that you can’t write the documentation in the week prior to the audit. As I mentioned earlier, this step takes time and it has to be planned. Of course, this change in attitude is impossible without the understanding and direct support from the top management.

What advice would you give to an auditor set to examine an organization from the inside out?

Certification auditors also need to get away from the “documentation myth”. That is, they shouldn't issue the certificate only because the company has perfect documentation. They should check whether the appropriate security actions and processes are really in place, compliant with the documentation.

But not every auditor is capable of doing it. In my opinion, auditors must particularly focus on answering two questions:

1. Does the Information Security Management System (ISMS) really protect the confidentiality, integrity and availability of most critical information, throughout all the processes and all the organization? Auditors often get lost in some detail related to particular control and fail to see a big security issue on the other end of a process/organization.

2. Does the ISMS fit for this particular industry? The flow of information – and, therefore, the requirements for its security - is completely different in a bank as opposed to in a manufacturing company.

To be able to do this, auditors must gain experience in particular industries, and learn to think holistically as well as analytically.


Critical bug found in Cisco ASA products, attackers are scanning for affected devices

Several Cisco ASA products - appliances, firewalls, switches, routers, and security modules - have been found sporting a flaw that can ultimately lead to remote code execution by attackers.

Weekly newsletter

Reading our newsletter every Monday will keep you up-to-date with security news.

Daily digest

Receive a daily digest of the latest security news.

Fri, Feb 12th