Automated evidence collection sounds great. And it is. It can save you time and help you repair relationships with control owners. But have you ever considered where the evidence that is automatically collected goes? If all the evidence is just placed in a “folder” waiting for you to sort through, the automation might not feel so great after all.
Most automated evidence collection vendors agree. That is why they also automatically map the evidence to where it is needed. When done right, cross-mapping should save you additional time when validating a control. Since one piece of evidence is used in several controls, the actions you take on the evidence in one place will automatically be applied everywhere the evidence appears.
So, cross-mapping can save you valuable time by reducing duplicate work. Great. End of story, right? Not quite. There is still one important issue to resolve: How does the platform know where to map the evidence? Or, put differently—what is the mapping based on? As we will explain below, the answer to this question is the key to understanding how much duplicate work you can actually eliminate and how much time you will truly save.
Control-Based Cross-Mapping
Most automation tools have adopted a method of mapping based on a common control language. In other words, identical controls, and, this is key, similar controls, in whatever framework they appear, will have the exact same evidence mapped to them. In theory, it sounds like the obvious and best solution. In reality, this approach presents a few challenges.
While controls may be similar or even identical, this doesn’t mean that what's required to satisfy them in every context is the same. For example, what you need to satisfy the user authentication control in ISO 27001:2022 differs from what you need to meet the same control in CIS. ISO and CIS have different objectives and approaches, with CIS adopting a more granular control scope. Therefore, it makes sense that these controls will require different evidence to satisfy them.
Vendor solutions where cross-mapping is based on controls set a single standard for what evidence will be mapped. The vendor decides what evidence needs to be included based on what is relevant in most cases. This means that, in some cases, users have a surplus of evidence—running the risk of sharing unnecessary information with the auditor. Or to avoid that, forcing them to decide manually what is or isn’t relevant. In other cases, they are missing evidence to meet the specific requirements of a control, again forcing them to do the work manually, diminishing much of the tool’s value.
Requirement-Based Cross-Mapping
The other approach to cross-mapping goes one level deeper. Rather than looking at a control as a single unit, the vendor solution takes controls and breaks them down based on what evidence is required to satisfy the control in the context of the framework. In other words, it explains the requirements that must be met to satisfy the control (hence the name “requirement-based mapping”). The mapping of the evidence is then done to each of the requirements within a control, not the control itself.
If we go back to our earlier example, to satisfy user authentication controls in ISO, you need to meet the requirements of one control (A8.5 Secure Authentication), for which you need both your password policy configurations and MFA enforcement configurations. There are two user authentication-related controls in CIS: one that addresses password requirements and one that focuses on MFA.
With a common controls approach, the same evidence would appear in a single control in both frameworks. That means you would need to manually adjust the evidence for each control (in this case, adding or removing evidence). With a requirement-based approach, the relevant evidence would appear in each control since it would be mapped based on the specific requirements of each control.
The requirement-based approach takes the extra work away from you and shifts it to the vendor side. They need to create these requirements and map them to each control, which saves you a lot of time and tedium. And, by tailoring what is needed for each control in its given context and not going with the “average” as the control-based approach does, you get what you need, where you need it. Nothing more, nothing less.
Accuracy Through Granularity
At the end of the day, the difference in the approaches comes down to granularity. Both the control and requirement approaches will save you time and duplicate work. The added benefit of the requirement approach is that it offers you greater accuracy as well. It saves you from having to do the extra work of checking every control for missing or surplus evidence and having to do more work on your own. What kind of mapping does your solution have?
About the author
