If you are an organization in the business of payment collections, your company may not be set up to accept credit cards as a form of payment. Thus, the inquiry from a current or potential client may be whether you are “PCI” compliant. The quick answer might be “No. We don’t need to be, because we do not accept credit cards, therefore those requirements do not apply to us”. Fair enough. However, processing branded Visa or Master Card debit card transactions also require PCI DSS compliance. Additionally, there is a move by the National Automated Clearing House Association (NACHA) to apply PCI DSS–type controls on large organizations that process very large volumes of ACH transactions annually. “So what?” – You might say. “That’s for organizations processing six million or more transactions a year. We will never be that size.” But the trend in the information security industry is that these kinds of frameworks will eventually become a requirement to smaller organizations as well. While, statistically, compromises of payment processing information and PII for ACH related data is very small by comparison to the Head-Liner breaches of major merchants the past 10 years or so, Banking institutions clearly are striving to mitigate all risk of fraud and data breaches related to payment transactions of all kinds, including ACH transactions. Anyone who knows anything about PCI DSS understands that the prescriptive and rigid controls of this framework standard which are required to achieve compliance is a daunting task for most small IT organizations. This is generally because such businesses grow organically from very small problem-solving solutions into larger more mature service providers. We have observed that in many such organizations, information security was often an after-thought which came about when someone realized that the service being provided which required the collection and storage of sensitive information is now a liability with external regulatory institutions and clients suddenly demanding assurances that such information is secured and that justification for collection and retention be provided. If you are processing ACH transactions, you are likely collecting information that may be classified as PII, such as bank account numbers along with a routing numbers associated with the bank account owners name. These components are referred to as the payment processing information (PPI). This data could be viewed analogously to cardholder data (CHD) in the Payment Card Industry and may eventually require the same level of protection as prescribed by the PCI DSS. There is precedent for other large organizations adopting PCI DSS framework and modifying it for application to sensitive data other than CHD. A few years ago, Experian, one of the three major credit bureaus, adopted the core of PCI DSS version 2.0 as a tool to require third parties who collect, store and/or transmit sensitive PII to protect that data in a similar fashion as CHD. Experian did modify the language of many of the controls to apply to Experian sensitive data, but the core of the security prescriptions remained the same. Additionally, Experian did NOT adopt the more tedious testing and reporting format of the PCI DSS version 3.x Report on Compliance (RoC). Will NACHA eventually push to have smaller organizations also comply with a security framework and provide annual attestation of compliance? We are not entirely certain. However, we do believe that any organization that adopts a strong framework of securing sensitive information will be better prepared to manage future compliance mandates – and the PCI DSS framework has clearly gained respect as a valuable tool for building and maintaining a secure IT infrastructure. We strongly encourage any organization that stores, processes or transmits any data that should be classified as PII (or any sensitive information for that matter) to use a strong security-focused network architecture and data handling policies and procedures. A Qualified Security Assessor (QSA) working for a QSA Company (QSAC) can be a very valuable resource for evaluating your organization’s information security (IS) environment. The reason for this is primarily because a QSA is most concerned with SCOPE and validating SCOPE Reduction – the determination that a more rigid security control can be applied to a very specific and often very small portion of an organization’s IT infrastructure as opposed to the entire footprint of the company. Because PCI DSS is so prescriptive, few organizations of ANY size want their ‘entire’ organization to be in-scope for PCI as opposed to a subset where all the sensitive data is stored. This is why building your IT architecture from the ground up with security in mind makes complying with PCI DSS easier than trying to apply security measures after the fact in order to meet a new compliance mandate. This mind-set is valuable for ANY IT environment. But, alas, as we stated, this is often not addressed until the horse is already out the gate and in full gallop. If your organization does in fact, handle PII as outlined above, consider hiring an experienced QSA to perform a GAP Assessment using the PCI DSS framework as a guideline to determine how well you are (or are not) protecting sensitive information. This can also be valuable as a part of your organizations RISK assessment or be the foundation of a risk assessment if you do not currently conduct such an exercise at least annually.