What is an ISO 27001 gap analysis?

In the context of ISO/IEC 27001, I've often heard people planning to commission or conduct a ‘gap analysis’ or 'readiness assessment' or 'pre-certification audit' or 'ISMS project review', but what do they mean? What exactly is going to take place?

Good question! There is no formal definition. It is essentially just a consultancy assignment specified by the client and agreed with the consultant/s doing the work. Given the context, its main purpose is generally to review the organization's state of readiness, addressing the question "Is the organization ready to be certified compliant with the ISO standard?" Another way of putting that is to ask "If the certification auditors turned up next week, would they: 

1. Turn around and walk away during the very first morning, shaking their heads in sheer disbelief at the near total clue deficiency and leaving site with another war-story;
   
   
2. Get stuck in to the audit fieldwork, quickly digging up plenty of issues including some major ones to discuss with management, perhaps serious enough that they would refuse to issue a certificate unless they were resolved;
    
3. Get stuck in to the fieldwork, finding only a few trivial issues and a lot of good practices, hence having every reason to issue the certificate; or
   
   
4. Struggle to find anything of real concern, perhaps leaving site with enough material for a case study in how to do it?

Determining the organization's certification readiness status is (usually) the obvious focal point of the job, its core objective ... but there's more to it in practice. In addition to the obvious gap-gazing element, an 'ISO27k gap analysis' or whatever the assignment is called will typically also:

• Review the scope of the ISMS and hence the likely scale and nature of the implementation project, including the timescales and resources needed;
  
  
• Review the information risks and security controls against those required or recommended by ISO/IEC 27001 [this is a surprisingly small element, since the standard and the certification auditors pay far more attention to the Management System than to Information Security];
  
  
• Review the ISMS implementation project or programme - the plans and resources (particularly key players such as the project manager, steering committee and senior management advocate), and various project risks;
  
  
• Introduce various people in the organization to the idea that managing information risk and security really is a bigger, broader, deeper concern than they probably appreciated (e.g. it concerns physical security for smartphones and servers, corporate papers, tablets, laptops and people while they are traveling on business or working from home or whatever - areas that traditional IT security, even in the modern guise of ‘cybersecurity’, may have barely even considered: there's more to ISO27k than IT/technical security!);
  
  
• Inform and hopefully engage management and other stakeholders more fully with the ISMS and the ISMS implementation project, giving them the chance to think about, raise and discuss information risks that are of concern to them and the business, not just of theoretical concern to those paranoid infosec pro's;
  
  
• Pump-prime a productive business dialog between stakeholders and specialists that will continue indefinitely, concerning information risks, opportunities, controls, governance, compliance, privacy And All That, emphasizing their value to the organization (the business context);
  
  
• Provide information and guidance for planning and completing the ISMS implementation, such as prioritizing areas which need some serious effort to bring them up to the required standards. The advice may extend to working out roughly how long it will take and how much more it is likely to cost; identifying the ‘friends' of information security vice those who are more likely to be blockers or enemies, needing some guidance and persuasion to bring them into line;
  
  
• Give management an independent perspective on the ISMS and the project team, from a competent, experienced professional who knows the standards inside-out and has been hands-on using them for a considerable period (hopefully, that is: anyone can claim to be a consultant, so caveat emptor - check their qualifications, background and expertise. An ISO/IEC 27001 Lead Auditor or Lead Implementer certificate may seem impressive but does not, in itself, indicate much beyond confirming somebody's attendance on a short course, especially if it is a fake or was issued under dubious circumstances. Remember that the consultant is likely to gain sensitive inside knowledge about the client's information security arrangements, hence they must be trustworthy);
  
  
• Give the Chief Information Security Officer, Information Security Manager, Information Security team, Cybersecurity guy/gal or ISMS Implementation Project Manager a chance to see how the consultant works, and vice versa. If the assignment goes well for both parties and the working relationship flourishes, there may be opportunities for ongoing contact and support, perhaps further consulting assignments during the journey ahead. If not, well fair enough, maybe it's better to part ways at this point;
  
  
• Support and encourage all concerned in a general sense. As well as gently pointing towards the end goal, boosting team morale, (re)motivating people and reassuring nervous managers are classic side-benefits of a productive project audit or review.

As with the ISO27k standards themselves, factors such as the size or type of organization, its structure, ownership etc. are of limited relevance to the assignment. A gap analysis is likely to be quite quick (perhaps a couple of days on the ground) for a relatively small, simple organization at a single location that doesn’t have a lot of valuable or vulnerable information to protect, doesn’t have many people or business relationships, is already strong on information security, and isn’t subject to stringent compliance obligations (laws, regulations, contracts including PCI-DSS, and more). Conversely a bank, even a small/specialist one, is bound to take longer to assess. Likewise a multinational or a government body.

The timing of the gap analysis is also pertinent. If the job is done very early on in the ISMS implementation project (perhaps even in advance of project approval), there probably won't be much in the way of hard evidence to review, making the assignment very fluid and somewhat perplexing for client employees not already engaged with the project. Conversely if it is done just a few weeks before the formal certification audit, most of the hard work should have been done: a competent consultant should still find a few things to comment on, providing a measure of assurance to management that the audit is likely to go smoothly once the final few pieces slip into place.  

Things can get interesting if the gap analysis falls in the middle period. The basics of an ISMS should all be in place with some parts of it operational already. This is normally such a fraught period for the implementation project team, however, that they may not have the high-level oversight, hence management may well be concerned to find out whether the project is on track and going to plan, teetering on the brink or running off the rails. A gap analysis in this period can be more involved and take longer, if only for the simple reason that everyone is extremely busy. On the up-side, there is still time left to make substantial changes if that is necessary. This is a good point to pencil-in the certification audit, and start lining up the certification body (the details to be confirmed nearer the time, perhaps after a final readiness assessment).

Strong governance of information risk and security, including management engagement with the ISMS is, I venture, crucial to its long term success, one of the if not the biggest Critical Success Factors. To put that another way, limited management understanding and support is, in my experience, the number one reason for problems on ISMS projects and the most likely reason for lack of funds, lack of priority, disinterest, unplanned changes, limited scope, lack of opportunity for improvements, aggravation, stress and, ultimately, marginal value to the organization. A well-timed, well-specified, well-resourced gap analysis can be the turning point.

PS  I am planning to add that updated version of the process diagram to the free ISO27k Toolkit at ISO27001security.com in due course.

PPS Get in touch if you think you might want a gap analysis. I know several gap analysts around the world, even some down here in the South Pacific.