The idea behind what some people calls “mappings” is that, for example:
I’m compliant with PCI-DSS req 2.3.5 because we have an Internal Control (AD Security Standards). Now because that 2.3.5 req is “the same” as 2.36, HIPAA 5.4 and NIST 800-53 1.4.b, I “should” be compliant with those requirements as well.
In eramba mappings can be defined (much against our recommendation) and they looks as shown on the image below. As you can see, you will define “Source” and “Destination” requirements as mappings. You can import them (ChatGPT can build any mapping today in seconds using what is already available on the internet).
In a hierarchy illustration this looks as shown below. On the left we see ISO as the “Source” and 800-53 and NIST CSF as “Destinations”. You might have mappings in between 800-53 and CSF so as long as they don’t create a loop (eramba won’t allow you to get there). As you can see, you have a single point of “failure” on ISO.
On the right side is the method eramba uses and recommends implementing the most basic GRC concept of eramba (problems & solutions). Where there is no single point of reliance or failure and you trully reflect the reality of your organisation in respect to different frameworks or regulations.
If you want to know how to use compliance mappings, simply complete the compliance course or simply go to the episode where this type of mappings are explained.
In general, we do not recommend using these mappings because of the following well proven issues:
- You are adding “Subjectivity” to your compliance framework, nothing is the same no matter how much they seem. In the eyes of an ISO auditor, PCI is totally different. This means that the “destination” might need “more” (Solutions: controls, policies, etc) than the “source”.
- Auditors have different audit guidelines for different frameworks, they won’t audit ISO and PCI the same way as each framework has its own methods.
- The requirements might look “similar”, but their testing requirements (type of evidence and frequency in particular) might be different.
- If the scope of your “Source” is different from the scope of your “Destination”, no matter if they “subjectively” the requirement is the same, the scope of applicability is different.
- You rely on a single (most times) “authoritative” framework to “comply” with other frameworks. A mapping requires a “source” and a “destination”. For example, if the source is ISO and the destination is NIST, HIPAA, Etc you will always depend on ISO. This has multiple issues:
- ISO (following the example above) might be updated far less frequently than your destination packages. You will then have to identify solutions for those destination requirements “Skipping” the source.
- Changing the “Source” is a plain nightmare. Just think how many mappings you need to delete and create again.
- Today your organisation might find ISO relevant and use it as a source, that might change next year. Then what you do? You think that is not common? Ask COBIT, 800-53, etc practitioners when their “Authoritative” standards last got fully updated. In fact, ISO since 2005 got 3 updates (in 20 years).
- ISO might be far less descriptive than your destination, so while you might seem to comply the source, you might far from the destination.
In general, is much more practical to simply apply the “problem & solution” principle to all your frameworks in that way you will always have guarantees that you are actually compliant (or not).