Technical and Organisational Measures

GDPR: Reporting Your “Technical and Organisational Security Measures”

You could almost be forgiven in thinking that words/phrases like; ‘pseudonymised’, ‘anonymised’, ‘access control’ or ‘encrypted’ are all that is required when reporting your technical and organisational security measures for Article 30 – Records of Processing Activities.


Continue reading
ISO 27001 Certification

ISO 27001 Certification, Is It Really Worth It?

For the last decade, ISO 27001 certification has been the de facto standard for security programs across the globe. The only problem is, few organisations can be bothered with it. In the years of its existence, I have been asked about implementing a total of twice.


The reasons are numerous, and vary from organisation to organisation. However, they most often fall within these categories. The client has:

  1. never actually heard of it;
  2. doesn’t care about cybersecurity;
  3. thinks it’s too difficult;
  4. thinks it’s too expensive; and
  5. cannot see a return on investment (ROI).

But the biggest reason I have not been involved in ISO that much?… The Payment Card Industry Data Security Standard (PCI DSS). Which coincidentally, began at almost the same time.

All by itself, PCI has sucked the security budgets out of enough organisations that there was little left for anything else. And if I’m honest, because of PCI, I haven’t had to go looking for any other work.

Think about that for just a minute…

A very basic, controls-only standard, related to a single form of data, that’s not even a law has driven enough business my way that I have not had to worry about diversifying.

And frankly, I still don’t, but with what’s going on here in the EU, we are all going to need something better. From the General Data Protection Regulation (GDPR) to the Payment Services Directive (PSD2), the regulatory landscape is finally making real security a necessity.

It follows therefore that organisations will begin looking to ISO for options.

And that’s really the point, can the ISO standards actually help, or is the 2700X series just a bunch of meaningless paperwork? At first glance, it certainly looks that way, and few organisations choose to go any further. And the ones that do, get so lost in the paperwork that they forget why they are doing it. It’s only when the framework is fully customised and implemented, that you see its true and significant benefits.

However, before you look to ISO, you absolutely MUST do your homework! You have to know exactly what an Information Security Management System (ISMS) is, why you’re doing it, and how you’re going to keep it going. If you can’t answer those questions, don’t start, because you will never cross the finish line.

The biggest killers of ISO certification projects, are, in this order:

  1. Grossly underestimating the level of effort;
  2. Doing it just to land a big contract (or for marketing purposes);
  3. Tying the certification to an overly aggressive deadline;
  4. Ignoring the expert help; and
  5. Having no business goals in mind.

These are usually exacerbated by not getting senior leadership support, and then failing to tailor ISO to your needs. So what organisations end up with 99 times out of 100 is a stalled project and an external consultant taking all the blame.

ISO 27001 certification is bloody difficult…

…just accept that from the beginning. It requires commitment from every aspect of your organisation, and will only be effective if you enable the culture shift necessary to embrace it properly.

Strangely enough though, it actually looks fairly simple, as the ISO 27001 standard itself is only 30-odd pages long and only 114 controls. However, for every 1 of those controls, there are an average of 4 additional aspect to consider from the NINETY-odd page ISO 27002. Then, if that’s not enough, you must show some kind of evidence that you actually doing what you say you are!

For example, the very first ISO 27001 control is “A.5.1.1 – Policies for information security – A set of policies for information security shall be defined and approved“. Sounds simple enough until you realise that there are a minimum of 19 suggested ‘Implementation Guidance’ factors behind it.

From requiring that Information Security Policies address; “business strategy” and “regulation, legislation and contract“, to the suggested ‘examples’ of “policy topics”, A.5.1.1 becomes a project all by itself. Then, assuming you get all this paperwork together, you have to ensure that the policies are; “communicated to employees and relevant external parties in a form that is relevant, accessible and understandable to the intended reader, e.g. in the context of an “information security awareness, education and training programme” (see 7.2.2).” Finally, you then need to provide some ‘record’ that this is all implemented , or that you have a risk treatment plan in place that shows you’re going to get it implemented …how …and when.

There are 114 of these, and even if you decide a few of them are not relevant to you, you must fully justify their EXclusion.

Not trying to put you off, the implementation of an appropriate ISMS is one of the best things you can do for your business as a whole. Just make sure you start out the project for the right reasons, with the right support, and the right goals in mind. And for GOD’S sake, get an expert in for a day FIRST to show all major stakeholders what to expect BEFORE you commit to the full project!

I see ISO 27001 certification becoming a must-have for almost any business, but only if it’s done properly.

[If you liked this article, please share! Want more like it, subscribe!]

ISO Standards

Question: When is a Standard Not a Standard?

Answer: When it’s an ISO Standard.

But before you get outraged, I believe the problem lies not with ISO, it’s that we don’t really know what a standard actually IS!:

  • Ask one person and they’ll say a standard is something that all ‘like things’ must be. i.e. they all must be the SAME.
  • Ask someone else and they’ll say that a standard is something you must reach   i.e. it’s a minimum bar.
  • Ask yet another person and they’ll say that a standard is an average of all things.

Even the OED backs this up!:

  • Something used as a measure, norm, or model in comparative evaluations;
  • A level of quality or attainment;
  • Something used or accepted as normal or average; and
  • A military or ceremonial flag carried on a pole or hoisted on a rope

OK, forget the last one, but you get the point, which is that the English language itself allows for multiple, often conflicting, interpretations of the SAME word! e.g. does the word ‘minute’ mean 60 seconds, or something very small? Right, this cannot be answered without context, but how about in this sentence; “The mouse was so minute that it fit into the tiniest of gaps.”?

So clearly the implementation of an ISO standard in any organisation depends entirely on the context to which they have chosen to adopt it, or are being forced to abide by it. An organisation looking for a marketing or competitive edge will adopt ISO as a quality attainment for example, and another will choose to use it for comparative purposes in their due diligence processes. Each will focus more heavily on different aspects of the ISO framework, and both can still meet the intent.

For things like information security this is no big deal, which I assume is why ISO 27001 uses the word ‘appropriate’ EIGHTEEN times! “…appropriate security…”, “…appropriate documentation…”, “…appropriate levels…” and so on. An organisation SHOULD choose which aspects of the standard are appropriate, and then go as deep into the framework controls as they deem …well, appropriate.

But what happens when the ISO standard (which is interchangeable with ‘framework’ in my opinion) is something like ‘Financial Transaction Card Originated Messages — Interchange Message Specifications’ (ISO 8583), or ‘Universal Financial Industry Message Scheme’ (ISO 20022) where you would think that everyone should not only interpret, but implement them in EXACTLY the same way to ensure global interoperability. Surely these things are not like an API bridge where you do whatever you want in the back end, surely they are more like a big puzzle where every single piece must meet SPECIFIC criteria to build the big picture?

Sure the message syntax might be defined, but the USE of fields and what actually goes IN the fields is optional. Why do you think the Card Brands, Issuers and Acquirers are going to have such a hard time implementing EMV tokenisation for example?

The mobile phone has changed everything; the way we communicate, the way we shop, and it won’t be long before it changes the way we think. If we are to embrace the enormous potential yet to come, globally, we must agree on a better definition of ‘standard’, or we might as well not bother. Information out of context has been the cause of innumerable wars, terror crimes, religious and lifestyle persecutions, and the continuation of nationalist behaviour to the detriment of the species.

Maybe we should standardise the word ‘standard’ …oh, wait?

[If you liked this article, please share! Want more like it, subscribe!]

Security Core Concepts

Security Core Concepts: Tying it All Together

With number 6, I completed my Security Core Concept series:

  1. Security Core Concept 1: Risk Assessment / Business Impact Analysis
    • Management buy-in
    • Examine your business processes 
    • Valuate and prioritise your data assets 
  2. Security Core Concept 2: Security Control Choice & Implementation
    • Perform gap analysis to determine control weaknesses
    • Mitigate control gaps based on priority
    • Think twice before throwing technology at a gap, perform robust vendor diligence if you do buy anything
  3. Security Core Concept 3: Security Management Systems
    • Make sure your controls are working
    • Begin control optimisation and measurement
    • Begin PDCA cycle 
  4. Security Core Concept 4: Governance & Change Control
    • Management buy-in
    • Interdepartmental co-operation and communication
    • Manage all business process and changes
  5. Security Core Concept 5: Incident Response (IR) & Disaster Recovery (DR)
    • Know what your baselines are
    • Standardise, centralise, and monitor
    • Test it, test it again, and keep testing it until everyone knows their part 
  6. Security Core Concept 6: Business Continuity Management (BCM) & Business As Usual (BAU)
    • Management buy-in (yes, that’s the THIRD time I’ve said that)
    • The goal is not security, it’s staying in business securely
    • BAU is where the true value of the core concepts is realised

…and have hopefully expressed in enough detail, the advantages of not only each of these steps, but of a security program ‘done right’.

What I have only alluded to, but will now examine in greater detail, is how the 6 Core Concepts make any regulation / standard / framework related to data security an afterthought.  Not that they aren’t useful, nor can they be ignored, but you’d already be ‘compliant’ with them.  The concepts themselves have been around for generations, and there are many treatises on each and every one.  There are even entire institutions dedicated to perfecting single concepts, but it’s only when you combine them all in a manner appropriate to YOUR business do they make sense.

I’m also talking about the fact that not one regulation the world-over goes deeper, and/or broader in their data security requirements, than you need to go for your business. They can’t, as the very names ‘standard’ and ‘framework’ automatically preclude, provide complete relevance to your organisation.  Nor can they possibly cover every nuance of every business type, sector, and culture.

What these regulations are trying to accomplish – but none state this outright – is a shift in culture away from function/profit only, to security enabled function/profit.  All 6 core concepts are basic fundamentals of security, yet are mostly ignored for reasons innumerable.  I hesitate to use the phrase business responsibility – I have enough issues with sounding like a lecturer – but that’s what it amounts to; you are responsible to protect the data in your possession.

But can you imagine going about your business, secure in the knowledge that no matter what security requirement or regulation gets thrown at you, you are already there!  Maybe not entirely, but the adjustments will be minimal, and will never require the level of effort that even PCI requires from you year after year.

In a nutshell;  If you do security properly, you will ALREADY be compliant with the security requirements of PCI / HIPAA / PoPI / SoX / SSAE-16 / GDPR / Swedish Personal Data Act / …and so on!

No more multiple annual audits / assessments (assuming you have some form of GRC tool), you will not only be compliant ALL the time, you can easily VALIDATE your compliance!

But none of this will be possible if your CEO doesn’t believe in it.  One again this phrase applies;

The CEO sets the tone for the entire company: its vision, its values, its direction, and its priorities.  If the organisation fails to achieve [enter business goal here], it’s the CEOs fault, and no-one else’s.

It does not matter what the goal, from PCI compliance, to great customer service, to an ethical salesforce, to a security culture that enables to business to grow responsibly, it’s the CEO who is responsible. And accountable.

I am pulling the following from where the sun doesn’t shine (no, not Scotland), but I would estimate that any time the CEO spends evangelising an appropriate security culture will be paid back 100-fold in terms of resource / capital / DR cost savings.

And it’s all so simple.  Not easy, but it is simple.

It may take years, even in smaller organisations, but the major costs are all front-loaded, and the long-term savings way in excess of the annual costs associated with constantly reacting.  Security is only effective if it’s mostly pro-active, and that’s exactly what the 6 Core Concepts are designed to do.

Don’t know where to start?


[If you liked this article, please share! Want more like it, subscribe!]

Plan > Do > Check > Act

Security Core Concept 3: Security Management Systems

If Governance (Core Concept 4) is the most ‘diversely interpreted’ of the 6 Core Concepts, Information Security Management Systems (ISMS) is the most widely MIS-interpreted and mis-understood.

As the de facto standard for ‘security frameworks’ , ISO 27001 is designed to; “…provide a model for establishing, implementing, operating, monitoring, reviewing, maintaining and improving an ISMS.”. Or more simply; It’s how you keep your security program in place, relevant, and appropriate to your business.

ISMS can be summarised by the old ‘Plan > Do > Check > Act (PDCA)’ cycle:


  • The Plan phase is about designing the ISMS, assessing information security risks and selecting appropriate controls;
  • The Do phase involves implementing and operating the controls;
  • The Check phase objective is to review and evaluate the performance (efficiency and effectiveness) of the ISMS;
  • In the Act phase, changes are made where necessary to bring the ISMS back to peak performance.

We already covered the Plan in Core Concept 1, and Do in Core Concept 2, so this; Core Concept 3, is a continuation of the security life cycle development.

With reference to a misquoted cliché; “You can’t manage what you can’t measure.”, the Check phase is designed to ensure that the controls you put in place to mitigate the risks detailed in the Risk Assessment (RA), are actually working. For example; your RA calls for segmentation between trusted and untrusted segments. Are the rules now in place to effect the segmentation? Is there any negative impact on performance? Are the firewall logs part of the established monitoring processes? Is the asset management system updated with all relevant detail? And so on…

If the answer to all of your success metrics above is positive, you must prepare to perform the cycle all over again at a time specified by your Governance Committee (usually annually at the very least). If the answer is no to ANY of the agreed metrics, you must go back and determine if the impact of the short-fall is sufficiently material to warrant major adjustment; e.g. fix it NOW, or no action at this time, or anything in between. This is the Act part of the ISMS.

As you can see, this is not actually that complicated. ‘ISO certification’ would be relatively easy if you were performing the first 3 Core Concepts correctly. However, because you can perform ISO certification of any aspect of your business, it is fairly meaningless unless you cover your entire infrastructure. Basically, unless you have a real business need to be ISO ‘certified’, don’t bother, just follow the Core Concepts.

While this Core Concept would SEEM to be the easiest (after all, it’s just determining if something is working or not), it’s the one that gets most ignored. It seems that most organisations lose interest after ‘fixing the problem’, so the additional expense of seeing if the controls actually worked gets put on hold. That ‘hold’ turns into forever, and continuous improvement is nothing more than a pipe-dream.

This is almost the same as doing nothing at all. Because not only do you not know if you are more secure than before, even if you WERE for while, you would soon fall back into your old ways. The entire investment is lost. In fact, it’s worse, because now you’ve wasted all that time and money as well.

Ensuring your ISMS is maintained is a critical function of the Governance Committee, along with Change Control, so we’ll tackle that in the next blog in the series; Security Core Concept 4: Governance & Change Control.

ISMS is where the rubber meets the road in terms of your corporate policies, standards, and procedures. These are the true baseline from which to measure the success of your security program. This is why they are one of The 4 Foundations of Security, and must receive the attention they deserve.

[If you liked this article, please share! Want more like it, subscribe!]