Standards, standards and more standards…

I was recently asked to advise a client on what information security standard they should adopt. They had looked at a number fo them, ranging from NIST to Cyber essentials, and had even made a small foray in obtaining and maintaining a couple with a very focussed scope. As part of my work there, they wanted to focus on one that would not only help them be more “compliant” (the normal starting point), but one that would also grow with them and allow them support and enable their clients. To be honest they had a very refreshing view as to the value of certification, and so we worked together well.

What they chose as a result of the workshops I had with them ultimately is neither here nor there, but one of the tasks was to create a simple comparison chart of the major players. “No problems!” I said… “I’ll Google it when I get back to the office” I thought to myself, “easy”. I was surprised to find it was neither easy or on Google.

The only document of use that I did find was from ISACA, entitled “Comparison of PCI DSS and ISO/IEC 27001 standard” written by Tolga Mataracioglu (the link may be behind a paywall, restricted to ISACA members). It is an excellent and in depth article looking at the two standards, mapping the requirements and generally doing a great job of helping the reader to understand the relevant strengths and weaknesses of both standards. However, it was only on the last page, Figure 8, that I saw something that was of value to the executive leadership folks I was presenting. It covered eight parameters and compared them in plain English. This approach is excellent for us “business” infosec people, and I applaud Tolga for this approach.

So I took what had been created already and decided to add to it, for instance other standards and a relative cost indicator, and asked a number of peers for their advice on filling various sections in; here is the finished result:

I like this approach as it breaks down into very terms what leadership need to be concerned with, and how it can be best applied to them.

So my question for this blog is what are your thought? Is this an accurate representation of the standards? Also, what other standards need to be included or other measures? Making this as robust as possible will benefit all of us (and I will be posting it for free download on my website shortly).

Looking forward to your responses and feedback.

Published by Thom Langford

An information security professional, award winning security blogger and industry commentator. Available as a speaking head and presenter on topics relating to information security, risk management and compliance.

Join the Conversation

5 Comments

  1. What’s the compliance level mean? 27001 I’d suggest is exists as you can loose your cert if there’s a major issue with your isms

    Like

    1. That’s a fair question Martin, especially as in the interests of brevity the description may not not be entirely clear. The principle is if you can have different levels of certification, so for instance with ISO27001 you either pass or fail, but with ISAE3402 you can be Type I or Type II certified. I hope that makes sense?

      Like

  2. PCI-DSS is also ‘volume’ based, the more card transactions processed, the stronger the rule set for compliance. Possibly consider adding a size related metric to the right hand side? Also, no mention of COBIT5. Tolga did an excellent job. (can you tell the ISACA member here?).

    Like

    1. Thanks for the response. Re the volume based aspect, that is referenced in the Compliance Level statement, albeit not explicitly. For instance, ISO is just pass or fail, no other levels, whereas PCI does have levels for, as you point out, volume.

      Of course the more you add to a slide like this, the more complicated and less useful (for certain people it becomes), but I will certainly take what you mentioned and see if it can be woven in.

      Like

      1. The rule set for compliance does not actually change dependent on your classification level with the card brands, but rather the onus of reporting and cost of compliance. Every merchant or service provider is given the same set of requirements and those only change based on architecture choices or outsourcing of responsibilities. But as you grow into a Level 2 or 1 merchant, you lose the ability to just self report via SAQ and add reporting responsibility to provide those ASV scans and (at Level 1) tohave an on-site assessment performed by a QSA…which, as it turns out, they do not like to do for free. 😀

        Like

Leave a comment

Leave a Reply to Martin Hepworth Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

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

%d bloggers like this: