The Journey to ISO27001 and ISO9001 : part 1

Over a series of posts, I’ll attempt to document how I managed to get our development workflow independently audited to ISO27001 (Information Security) and ISO9001 (Quality).

To appreciate the scale of the task, I have to cast my mind back to 2011. I was looking for a new job and saw a role as PHP developer advertised. At the time I was nothing more than a bedroom PHP coder, I’d written a few simple web applications using PHP but these were just for fun and certainly nothing to be proud of. In my previous role, I done a bit of web programming using Visual Basic, but I was certainly no expert.

Anyway, I was invited for interview and a coding test. I felt rather out of my depth, seeing professional PHP developers working on applications that a multi-million pound business depended on.

The coding test made me shudder – not because I couldn’t do it, but because of what I was asked to do. I was given a page of tasks to perform and a laptop. I was told to write the code and then to FTP the code to the company’s one and only production server, where I could examine its outputs. So, here I was, someone with no professional PHP experience been asked to write code on the hoof and then upload it to a production server to see if it worked. One of the tests also involved running MySQL queries against a production database.

Anyway, I got the job and started on the long journey to getting the web development processes up to the standards required by ISO9001 and ISO27001.

It became apparent early on that the workflow adopted by the team was to edit code on the production server and see what happened. There was no local development environments on the developers’ PCs, and no test environment. I lost count of the number of times someone tried running an experimental query and we had to then call Rackspace and ask them to stop it running as it was killing the database server.

The first task was to have a dedicated and isolated test environment set up. An old PC was found in the server room and was quickly turned into a basic Centos LAMP stack. Unfortunately, all of the production code had been written so that it only could run on the production server – just copying the production code onto the test server did not work. We had to spend ages setting up reverse proxies as well as changing code so that it was not coupled to the environment where it would run.

We also installed XAMPP on all the developers’ PCs so they could at least run code locally before it reached production.

In summary – production servers are sacred, and cannot be used for testing anything. Get a test environment!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.