May 7, 2021

Last Updated on June 13, 2024

Over the last 20+ years, one of the most frequent questions I’ve answered for clients that need to move to a (more) “provably secure” state (e.g., ISO 27001 certification, CMMC compliance, SOC 2 attestation) is “Why don’t you just start with a gap assessment like ‘Competitor X’ is proposing?”

From now on I will be tempted to point them to this blog post. It illustrates critical factors that a thorough scoping exercise will identify that a gap assessment won’t.

Simply put, a gap assessment is a measure of your gap from the requirements outlined in a standard. The challenge is that all standards are impacted by context. Context is defined as “the circumstances that form the setting for an event, statement, or idea, and in terms of which it can be fully understood and assessed.” Updated to reflect our use case, the definition becomes “the circumstances that form the basis for the proper implementation of a standard, in terms of which it can be fully understood and assessed.”

So literally by definition, you can’t gap assess until you understand context and risk.

If you fail to heed my warning, here are 3 of the most significant problems that can occur:

  1. The standard may not be the only prescriptive guidance that you should be assessing against. For example, perhaps your business processes Controlled Unclassified Information (CUI). So you ask the vendor to gap assess against CMMC Level 3. On that basis, they recommend you migrate to Microsoft 365 GCC to achieve CMMC compliance. But the CUI you process is also covered by ITAR. So, you end up abandoning your $50,000/6-month migration to Microsoft 365 GCC, as only Microsoft GCC High meets ITAR requirements. (Or even worse, you don’t recognize the ITAR requirement, and I end up including a link about your settlement with the State Department in a future blog post.)
  2. You may not know the full scope to apply the standard to. Say you process healthcare claims for insurance companies and are being asked for HIPAA attestation from your clients. So, you ask the vendor to gap assess against HIPAA. The vendor finds that your IT controls fully meet the requirements. But because they focused on the IT controls rather than context, they fail to identify that a small portion of the data input processes are performed by a secondary office that has not implemented the Technical, Physical, and Administrative Safeguards required by HIPAA (and yes, this is a real example).
  3. The standard is not prescriptive and can’t be applied without context. Perhaps you provide background screening services from a dozen offices worldwide, and your clients want you to become ISO 27001 certified. So, you ask the vendor to gap assess against ISO 27001. The vendor thus gap assesses your Access Control Policies. ISO 27002 states that the objective for Access Control is “To limit access to information and information processing facilities.” But without through scoping, the auditor would not know which types of information are in the scope of the ISMS and therefore necessary to review. Are client contracts, marketing materials, internal HR, financial, etc. in scope? From the background check data, which elements are considered sensitive/high-risk (e.g., driver’s license, credit check, SSN) and will require higher degrees of access control? And which data types are considered less sensitive (e.g., criminal, educational and/or job history) and don’t?

ISO 27002 also states that “An access control policy should be established, documented and reviewed based on … business and information security requirements.” Further, “Asset owners should determine appropriate access control rules, access rights and restrictions for specific user roles towards their assets, with the amount of detail and the strictness of the controls reflecting the associated information security risks.”

To bring the above reasoning full circle, ISO 27001 clearly states that in order to determine the correct implementation of a control you need to understand the information you are protecting, the business context, and the risks to the data. Which makes complete sense, because a control is a mechanism to reduce risk. Without understanding how big the risk is, you can’t understand how robust the control is. Without understanding the business context, you can’t understand the risk.

Context tends to be a vague term, so I find it helpful to illustrate typical contexts that help to shape scope, risk, and the optimized implementation of controls. For the data you are trying to protect, you need to comprehensively understand:

  • Physical locations where the data resides
  • Cloud services that store, process or transit the data
  • Systems that store, process or transit the data
  • Employees with access to the data
  • Vendors with access to the data
  • Critical applications that process the data
  • Legal regulations governing the data
  • Client contractual obligations relating to the data
  • Other stakeholders (governing bodies, business partners)
  • Risks to the data
  • The value of the information and the consequences to risks being realized
  • Business structure/strategy that influences risk appetite
  • Etc., etc., etc. …

Hopefully, I have made a compelling argument on the importance of scope—caveat emptor.

If you want to quickly check out 13 million more reasons why you need to scope before you do a gap assessment, click here.