Mapping client processes, regulatory requirements, risks and commonly adopted standards or frameworks needs to serve a business purpose.  While many seek the Holy Grail spreadsheet providing one clean map of the audit universe, they must ultimately face reality. Mapping is an exercise that includes the client, business context, and a collaborative decision-making process.  Just as business demands change, the purpose of mapping would require similar levels of adjustment.

For example, an organization might have already identified their IT General Computing Controls and determined to include the CobiT control PO7.4 "Personnel training".  Current, free and available guidance tells us this is mapped to ISO 27001 8.2.2 "Information security awareness, education, and training".

This mapping serves to reinforce that a policy for Personnel training exists, and a program is or should be, implemented.  Reliance upon generic mapping, however, is problematic and might even serve to move a compliance project off course.

(At the time of this paper, mapping scope had not yet included ISO 27002:2013, NIST CSF, SOC 2 2017, PCI DSS 3.2.1, CIS CSC 8.1, NIST 800-53r5, HIPPA/ HITRUST, and a number of smaller mapping standards. Please review the images at the base of this document for more information about current mapping capabilities.)

The question of any mapping exercise needs to be, "based on the risk that is managed or mitigated by this control, which areas of policy are most necessary to achieving its success?"  The answer to this question is only valid in the context of a company's current risk apatite and posture.  A small business, as for example, a corner grocery chain, might not have concern for intellectual property rights.  There might only be one antiquated computer and one register at each of less than twenty locations.  Is it reasonable to suggest they deploy a full-scale internal control framework to include cryptographic controls?  Does it matter that they lack a policy for teleworking?  What if they decide to manage risk using third-party expertise?  Perhaps all of their security requirements will be covered in an upcoming PCI/Visa compliance review.  That being the case, the organization model is directly tied to both what they control and how they control it.

Having established that no single map of controls, regulations, and policies can apply across multiple business contexts, there is an even greater need to enable a Dynamic Mapping Process.  In order to rapidly and effectively evaluate an organization's risk of Noncompliance with any Law or framework, certain tools and project components need to be in place.
  • Method to gather, record and report the client Risk Profile
  • Means for mapping Risks to Controls
  • Source of Regulatory information and means for keeping it up to date
  • Interface to Develop, Map and Report Processes, Programs or Services with respectively aligned Controls
  • This toolset must enable a capacity to engage across Risks, Controls, Processes, Regulation and Policy, capturing and compiling client information and allowing for consistent billable, actionable output.
  • Risk Assessment creates a profile of an entity's most significant Regulatory and Enterprise Concerns
  • Controls Assessment establishes the "in scope" Control objectives that are used to highlight compliance points within any process. Policy Mapping ties actual and required client policy documentation to the established Control framework.  Process Profiling creates the step-by-step activities and their associated controls that are represented as mapped process flow diagram.  This area of documentation may serve as compliance demonstration, future state planning or even sales material.
Main Menu