In many information security, privacy, and financial auditing approaches, the audited customer needs to produce one piece/set of evidence per requirement. Each requirement needs distinct artifacts. This allows for simple data management - my list of requirements is X long and therefore my list of evidence artifacts/sets should be the same length. I can then track progress as an audited customer by measuring how much evidence I have produced, and how much is left to go. I can even set up workflows within project management tools and GRC tools easily to accommodate this. Put in data terms - my requirement to evidence relationship is one to one, or one to many.

In contrast, in an efficient HITRUST project with the current rubric and version, I will encounter many scenarios where my requirement statement has more than 1 idea contained within it. This has increased with the new rubric's adoption of Policy Elements. I then gather a larger set of evidence for the requirement. But in order to be efficient, and to not burden the assessor or the audited firm teams with duplicative evidence requests, I have to take the returned artifacts and consider which of many requirements the evidence may meet. For example, a HIPAA risk assessment may be appropriately used as an artifact for multiple controls spanning Domain 1, 6, 17 and 19. However, some of those controls are not fully satisfied by this artifact alone. In effect I must maintain 2 maps for bi-directional association of Requirements to Evidence and Evidence to Requirements. This is a many-to-many relationship.

This can cause friction and difficulty in a few places. First, many audited firm compliance teams are geared to operationalize and measure progress against the production of evidence more so than by completing HITRUST Requirements. This is due to the fact that many organizations must meet multiple frameworks worth of audit requests and only a common evidence approach scales up. Second, this causes duplicative efforts for audited firm teams and assessor teams where a topic has been addressed in earlier requirements but the same tests of the same artifacts must be duplicated in later tests to achieve full coverage. Going back to the earlier example, when I review the HIPAA risk assessment I know I will have to duplicate that testing as a portion of coverage in a number of controls. Ideally, I would test the HIPAA risk assessment once and therefore spare duplicated testing, and duplicated evidence production and upload by the audited firm team.