Cross Audit Evidence Sharing: Compliance Language

Managing multiple InfoSec frameworks, controls, and evidence for those controls all at the same time is a pretty tall order.

The average modern company has 13 frameworks between security and privacy in place. While they all have their own flavor, these frameworks all share a common goal—ensuring that organizations adhere to external standards, with the intention of protecting and securing company and user data.

The goal is a noble one to be sure, but as we know all too well, managing it all is pretty complex. Each framework is its own ecosystem, with its own intricacies and specificities. PCI-DSS, ISO 27K, SOC 2, HIPAA, and their counterparts each have their own language and their own requirements, even when referring to overlapping elements.

For example, when it comes to password management, ISO 27001:2013 A.9.4.3 states, “Password management systems shall be interactive and shall ensure quality passwords.” Meanwhile, over in PCI-DSS, 8.2.3 outlines the specific requirements needed for passwords. They “require a minimum length of at least seven characters,” they must “contain both numeric and alphabetic characters,” etcetera, etcetera, etcetera.

This makes managing various frameworks especially tricky for you, the compliance leader. You're the one tasked with repeatedly turning to the same people—the IT team, the security architects, HR personnel, whoever—to get the evidence needed to prove your controls are in place. You have to nudge, cajole, and sometimes even beg those same people for the same pieces of evidence, when you may already have what you need, hiding behind a different name.

{{banner-image}}

What Happens When You’re Missing a Unifying Language

This lack of unified language creates a bunch of unnecessary problems:

• Audit fatigue and dependencies - By continuously asking people for the same evidence, you place additional burden on them. To illustrate, imagine this (not-too-hard-to-imagine) scenario: To get you the evidence you need, the network admin has to repeatedly generate reports of firewalls rules, logs, etc. Then there’s the Identity Access Management (IAM) team, who must continuously provide you with access control requests and lists of users and permissions, sometimes to multiple systems, based on the scope of each audit. And last, consider the burden this places on the R&D manager; He or she must repeatedly explain their SDLC process and how change management is performed. And every time they have to go through it with you, it must be explained in varying levels of detail, based on factors like the wording you use, the scope of each audit, and their spare time to work with you. This creates more work for both you and them and gives compliance a reputation as a hindrance, an inhibitor of productivity and progress.
  

• Inconsistent data - Without a common language, you may get different answers to the same questions. Based on the above scenario, it's easy to see how you could wind up with different pieces of evidence to support essentially the same controls; For example, though penetration testing, vulnerability scanning in code, and security code review all fall under the general umbrella of Security Testing, each one is its own process. The auditor or the framework may not dictate specifically what's expected, so you may get different answers when asking your colleagues, as developers often use different names for them.  
  

• Increased and inefficient spending - Lacking a unifying language may cause you to miss what’s overlapping and end up double spending on quick-fixes. For example, let's say you find an issue in a process as part of PCI-DSS and remediate it, such as access to sensitive data. Later on, someone else finds an issue with this same process as part of ISO 27001. You both have different expectations and/or recommendations of how to resolve it. Your organization will end up paying for two separate solutions, when the ideal resolution would have been to solve the issue for both frameworks, while adding real value to the organization, instead of merely covering the audit findings.

To illustrate, take a look at what happened to one of our customers; When preparing for PCI-DSS in January, they found an issue in their control of encrypting data at rest. Instead of re-assessing the process, finding an optimal cost-effective solution for the organization, and thereby fixing the issue, they simply found a workaround tailored for the immediate need. When ISO 27001 rolled around in March, they deployed another temporary fix. By the time they started to think about preparing for SOC 2, there was no budget left for a proper solution for this same control.

Creating a Common Language with a Centralized Single Source of Truth

To solve these challenges, organizations need one common language of compliance. When everyone is speaking the same language, issues can be solved in a broader way and a methodology can be implemented and maintained over time. Cross-audit evidence sharing is the optimal way to prevent issues from becoming siloed, saving organizations time, money, and efforts.

With cross-audit evidence sharing, you can easily maintain one unified list of controls, based on (or referring to) their policies and procedures, which has already been approved by management. Moreover, that unified list of controls is already mapped to each of the frameworks that are relevant to the organization, for now and in the future. This includes assignment of requirements and evidence, to collect and fulfill that unified list of controls.

We all know that achieving and maintaining compliance can be a headache, to say the least. I can’t promise you that using one unified framework will remove all your compliance challenges.

That would take a miracle.

But what I can say with a great degree of confidence is that with one common language, you can simplify (at least some of) the complexities to make this part of your job a whole lot less stressful.

‍