Wellmo recently received its ISO 27001 certificate, the primary standard for an information security management system (ISMS).  I was closely involved in defining the processes and policies to obtain the certificate, and will share some of my experiences in this post.

ISO is not your enemy.  I presumed that certifications meant bureaucracy and lots of red tape.  In that aspect I was positively surprised by ISO 27001:2013 – which I hear is a lot lighter and less bureaucratic than previous versions, though still one of the tougher standards.

Most of the items required by the standard were things that we were already doing or things we should be doing.  Most of the work involved was documenting our existing practices and then filling in the gaps.  At the end of the day, there were few documents that served no other purpose than to obtain the certification.

Get help.  Don’t try to become compliant just by reading the standards, but instead hire an expert to assist you.

Make it your own.  While you should have an expert to assist, you should write your own processes and policies.  Don’t try to use ready made policies as a basis.

If you’re seeking ISO 27001 certification, you’re probably doing a lot of the right things already.  It’s much better to document existing practices and fill in the gaps, rather than trying to take totally new processes into use.

Remember, the standard defines what needs to be done, not how it needs to be done or documented.

Minimize the scope.  The scope defines what parts / processes you are certifying.  By excluding irrelevant portions, you can lighten the burden considerably.  What is it you’re actually trying to gain from using the ISMS?  For example, mandate rigorous data handling procedures only for the relevant sensitive information, and only recommend it for other, out-of-scope information.

Be actionable.  Many ready-made policies are very generic and high-level.  Such documents are burdensome to read, are not very useful in themselves, and need additional support documents.  I took a different route, and tried to make all documents direct and to the point for the person reading them.

For example, our Information Security Policy contains direct requirements applicable to all employees.  It is accompanied with a separate document with practical instructions.  Both contain cross-links to assist in reading.  As little high-level chit-chat as possible.

Minimize the number of documents.  The more documents you have, the more documents you need to maintain.  In many cases, instead of having separate documents for all control items, it is sufficient to have a brief description in the Statement of Applicability or some other related document.

At the same time, minimize the amount of documentation that any person needs to read.  For example, we have a separate Secure DevOps Policy for developers and operations personnel, which other employees don’t need to worry about.

Create a recurring tasks document.  In the ISMS, many things need to be done on a regular basis. It helps a lot to create a single document (in our case a shared Google Sheets) which can track all these actions, their next due date and when they have been performed.  In many cases, marking a task done and adding a comment to a cell is sufficient for evidence required by the ISMS (possibly adding a link to further documentation).

Here is a recurring tasks document template.

Don’t start with certification.  There are certain things – such as internationalization – that should be built into a product from day one, or they will cost more to implement later.  In my opinion, certification isn’t one of them (unless it’s really a regulatory requirement even for an MVP).

You should instead start off light, develop best practices and processes that work for you, and then start to formalize those and fill in the gaps.

I hope these notes have been useful.  Please leave any additional tips in the comments below!