It’s no surprise the ultimate decision in getting that stamp of approval AKA the Report on Compliance (ROC) is in the hands of your QSA (Qualified Security Assessor). And while they are your primary voice or point of contact into VISA, you can hold direct conversations with the PCI committee/representatives (specifically to discuss DSS compliance…yet they’ll just assert the QSA and his/her organization are liable for acceptance & interpretation leading to a ROC). While Visa and PCI can set guidelines and requirements, etc. your QSA is the gatekeeper towards getting your company’s name on the approved list.
So why is it then that the interpretation of the requirements left up to the QSAs—given the sheer number of “security boutiques” with QSAs opinions and practices that vary (i.e. how conservative is yours)? Moreover, why is the PCI requirements left to one’s “qualified” interpretation? Is it any different than SOx as it pertains to financially significant systems/controls; or how different is it from SAS70 based scope for assurance? Though there is one difference in these compliance reports in that I don’t recall any BIG4 or other CPA firms still conducting ROC attestation (i.e. just the side business of PCI compliance not certification).
Of course, everyone should be PCI compliant for credit card numbers [I don’t need any more mysteriously green fees popping up] but what about all the other PII data contained within your 4 walls or consultants cubes; as well as the business partners you share them with…
So, let’s visit some variations in the implementation of these requirements. Oh, by the way, (in getting an edge) try getting your competitor’s scope for their ROC…good luck.
Requirement 3.3 by definition requires the masking of the first 6 AND the last 4 of the PAN(payment account number), leaving only the middle portions displayed. Then, real world and reality chimes in. As a function of your “business” and requirements of your customers, displaying the first half of the PAN is actually necessary for absolute comparison in cases of disputes, for example. Provide this compelling argument to your QSA and yes, they’ll agree the existing practice (provided consistent and justifiable) will be accepted. Your alternative is complete overhaul of your existing application and processing models (not to mention the technical reconfiguration and programming that’s involved). Is this meeting the underlying objective PCI set forth; you tell me?
When you need time to stand still for a little while—particularly if you are not the Merchant or Service Provider Visa or acquiring bank directly being hold accountable, push back on being fined by the upstream providers by leveraging existing contracts/agreements. Have the acquiring bank or provider share the burden of compliance/implementation cost…so in turn they can quickly meeting the vendor requirement section. Basically, as a downstream vendor of card numbers, you’re slid under the VISA radar so Merchants/Providers, in fulfilling their own certification, have to put reliance on existing contract/SOW/agreement (signed perhaps prior to the heightened PCI awareness days). Sure you may have to pay “credits” which is most often less expensive (in the short term) than complete remediation. Just keep in mind the risky business and repercussions of an actual security breach down-/up-steam or sideways use of PAN (should it occur prior to compliance).
Do share your interpretation of specific requirements and the spin on its implementation.
Of course, everyone should be PCI compliant for credit card numbers [I don’t need any more mysteriously green fees popping up] but what about all the other PII data contained within your 4 walls or consultants cubes; as well as the business partners you share them with…
So, let’s visit some variations in the implementation of these requirements. Oh, by the way, (in getting an edge) try getting your competitor’s scope for their ROC…good luck.
Requirement 3.3 by definition requires the masking of the first 6 AND the last 4 of the PAN(payment account number), leaving only the middle portions displayed. Then, real world and reality chimes in. As a function of your “business” and requirements of your customers, displaying the first half of the PAN is actually necessary for absolute comparison in cases of disputes, for example. Provide this compelling argument to your QSA and yes, they’ll agree the existing practice (provided consistent and justifiable) will be accepted. Your alternative is complete overhaul of your existing application and processing models (not to mention the technical reconfiguration and programming that’s involved). Is this meeting the underlying objective PCI set forth; you tell me?
When you need time to stand still for a little while—particularly if you are not the Merchant or Service Provider Visa or acquiring bank directly being hold accountable, push back on being fined by the upstream providers by leveraging existing contracts/agreements. Have the acquiring bank or provider share the burden of compliance/implementation cost…so in turn they can quickly meeting the vendor requirement section. Basically, as a downstream vendor of card numbers, you’re slid under the VISA radar so Merchants/Providers, in fulfilling their own certification, have to put reliance on existing contract/SOW/agreement (signed perhaps prior to the heightened PCI awareness days). Sure you may have to pay “credits” which is most often less expensive (in the short term) than complete remediation. Just keep in mind the risky business and repercussions of an actual security breach down-/up-steam or sideways use of PAN (should it occur prior to compliance).
Do share your interpretation of specific requirements and the spin on its implementation.
No comments:
Post a Comment