Just got a call regarding PCI and Sarbanes Oxley (SOX) compliance. Whether it is SOX, the Health Insurance Portability and Accountability Act (HIPAA), Gramm Leach Bliley Act (GLBA) or some other regulation, organizations that also have to comply with the PCI standards want to maximize the work effort to avoid redundancy. After all, all of these assessments take a lot of effort to gather the documentation and other supporting materials as well as interviews and the like to go through the various assessments. It is not that this cannot be done, but it can get complicated to ensure efforts are coordinated properly and assessment work done by one party is acceptable to the QSA and vice versa. It has been my experience that properly planned, a lot of these other assessment programs can be aligned to minimize the amount of effort required to go through a PCI assessment. However, be advised that there may still be a significant amount of effort on your QSA’s part as well as your own organization because of the testing required by the PCI DSS.
For example, since the release of SOX there have been a lot of changes, particularly for section 404 where most public companies think they will gain leverage. What has happened is that with the changes to 404, the number of applications in-scope for SOX has been greatly reduced as has been the testing requirements. Therefore what is in-scope for SOX is usually a very small subset of what is in-scope for PCI or may not even be relevant to an organization’s PCI compliance. I know this will seem hard to believe, but we have publicly held clients where their point of sale (POS) is not in-scope for SOX. As a result, any leverage between SOX and PCI efforts is not always possible.
But that is not to say there are not areas where leverage can be obtained. One place where we typically get leverage is with the assessment of logical access controls, PCI DSS requirements 7 and 8. Since most companies have a central directory for managing users such as Microsoft Active Directory, logical access controls get fairly well covered under SOX, HIPAA or GLBA. As such, an organization’s internal audit function and/or external auditors have covered how users are added/changed/disabled/deleted, password aging, password strength, etc. There may still be areas that were not covered such as password resets, but there is no reason to go back over what has already been covered if that was already assessed and the parameters of their assessment meets or exceed the PCI DSS requirements. In most cases, we find that the assessment by the other party typically goes above and beyond what the PCI DSS requires.
Another area we find where leverage can be gained is with application development standards, PCI DSS requirement 6.3, and change control, PCI DSS requirement 6.4. Both of these areas get quite a bit of scrutiny under SOX, HIPAA and Federal Financial Institution Examination Council (FFIEC) regulations as well as most organizations’ internal audit work programs. Granted, these various assessment efforts will not cover every application or device in-scope for PCI. However most organizations have common policies, standards and procedures for application develop and change control and those will have been assessed and tested under other assessments. These assessments should be able to be leveraged and minimize a QSA’s testing to in-scope PCI items that were not tested as part of other assessment efforts. Again, in most cases, we find that the assessments of these areas go above and beyond what the PCI DSS requires.
Caveats
Now before everyone runs joyously off to limit their QSA’s review activities, there are some caveats that need to be considered in order for this to be effective.
First and foremost of all of these caveats is that it is up to the QSA to be willing to accept the other parties’ work efforts in assessing the requirement in question. The PCI SSC has made it clear that a QSA is under no obligation to accept any third party’s assessment efforts, even another QSA’s. As a result, just because you have these other assessments does not mean that you will gain anything in your PCI assessment. Which leads me to recommend that when you are assessing QSAs for your PCI compliance work, it is a good idea to ask them about whether or not they will accept other third parties’ assessment work? You cannot leverage the results of these other assessments if the QSA will not cooperate.
Another caveat is that the assessment efforts from any third party must have occurred within the PCI assessment period. No one should expect a QSA to rely on a work product that did not occur during the PCI assessment period. I have run into situations where, because of timing, the assessment of logical access occurred a few months prior to the PCI assessment time period and would not be re-assessed by the organizations until a month after the PCI assessment period. In those cases, we have had to conduct our own testing of logical access controls and could not leverage the other auditor’s work. I also have had run into instances where the assessment of a particular control occurred right at the start of the PCI assessment period. Because almost a year had passed, we opted to conduct some limited testing of the control to ensure that the control was still functioning as designed but did not conduct our full testing because of the results of the prior testing.
A third caveat is that the QSA needs to be careful in determining what was covered by the third party in their assessment. Not that we have had organizations trying to put one over on us, but as a QSA you really need to read the third party’s report and, if necessary, ask questions about the scope of the assessment. We have found in a number of instances that what was represented by our client and the work performed by the third party were not the same. The reason this occurs is that what we (QSA) asked for; what our client contact then asked for; what the person who has the report supplied; do not always jive with what we (QSA) were expecting or requested. As a result, it is not unusual to have to go a couple of iterations to get what we need. And even then we may find out that what we can get will not meet our needs.
The final caveat is that the third party must be qualified to conduct the testing you are going to rely upon. This is similar to the requirement that the PCI SSC tells QSAs about for internal vulnerability scanning and penetration testing. Per my earlier example, if an organization’s external auditor has done testing regarding how users are established and assigned access to the network and applications, there is little to be gained from a QSA going through the same exhaustive testing. As an employee of a public accounting firm, I can tell you that SOX testing is not a small effort in regards to logical access. So unless the logical access testing totally missed the cardholder data environment, I would typically have no trouble relying on the external auditor’s assessment.
So there are ways to leverage other compliance efforts to reduce the impact of PCI compliance work. In order to leverage all of these efforts, quite a bit of planning and coordination are required. And just because you can do this, does not automatically mean that the leverage gained outweighs the effort required to make it happen. So you need to keep in mind that such efforts may be for naught.
