The 12 Requirements of PCI DSS
The Payment Card Industry Data Security Standard includes more than 250 requirements under 12 major standards. The 12 standards are:
- Install and maintain a firewall configuration to protect cardholder data
- Do not use vendor-supplied defaults for system passwords and other security parameters
- Protect stored cardholder data
- Encrypt transmission of cardholder data across open, public networks
- Protect all systems against malware and regularly update anti-virus software or programs
- Develop and maintain secure systems and applications
- Restrict access to cardholder data by business need-to-know
- Identify and authenticate access to system components
- Restrict physical access to cardholder data
- Track and monitor all access to network resources and cardholder data
- Regularly test security systems and processes
- Maintain a policy that addresses information security for all personnel
A central consideration of security requirements cited by Requests for Proposal is the protection of sensitive data.
Personally Identifiable Information (PII) is not just information that reveals the identity of an individual but any information that may potentially reveal the identity of an individual when combined with other information. This effectively makes all consumer information PII and mandates a comprehensive approach to data security.
A particularly sensitive type of PII, meanwhile, is cardholder data. Payment card data not only poses the risk of identifying an individual, but also sensitive financial, transactional, and bank information that can be directly leveraged for fraud.
As a result, the security of payment processing becomes a central consideration in RFPs. Any RFP that seeks a digital commerce partnership inherently includes considerations for payment processing, including who’s responsible for payment processing (virtually always the vendor), how payment processing is secured, and to what standard.
The latest installment in our RFPs & Rising Technology Demands series examines the particular sensitivities of payment processing and the requirements and standards for payment processing often cited as conditions for a bidder to win the business.
PCI DSS: A Primary Payment Processing Requirement in RFPs and Elsewhere
A digital commerce arrangement naturally includes some form of payment with one of the parties responsible for processing payments, specifically payments with a credit, debit, or other payment card, whether at a point-of-sale terminal but increasingly likely online.
The primary responsibility for payment processing almost always rests with the vendor, the bidder in the RFP. The vendor is making the sales and collecting the payment and it’s a natural expectation that the vendor will be responsible for the processing of the payment, and its security, as well.
Every organization likes to get paid, of course, but it comes at the cost of scope: processing payments comes with an extensive set of security requirements, namely the Payment Card Industry Security Standard (PCI DSS, which includes 12 individual standards each with many requirements of its own. PCI DSS in its entirety includes more than 250 requirements for payment processing.
While PCI DSS isn’t a law, it often serves as a de facto law. PCI Compliance is cited as a contractual condition between the vendor and the payment card company. Therefore, non-compliance can become a legal liability in the form of a contractual breach. Specific to the RFPs, the companies issuing RFPs often cite PCI DSS as the contractual payment processing security standard, as well.
Managing PCI DSS to Win RFPs
The scope of PCI DSS can become burdensome for small and medium, even large, companies.
Complying with 12 standards – "encrypt transmission of cardholder data across open, public networks,” to name one particularly involved requirement – is often a greater standard than companies have the resources to meet.
The standards, like the encryption standard,” often require technological infrastructure that companies may not have or, more accurately, may not have reason to invest in fully. There are logistical requirements as well, such as extensive periodic self-assessments and requirements for regular testing and policy creation and maintenance.
Because the scope of PCI DSS and payment card data security is so expansive, it’s common for vendors to trust payment processing to third-parties such as USAePay, PayPal, and others who specialize in payment processing. This largely transfers the scope of compliance from the vendor to the third-party processor, as well as quickening implementation and overall simplifying payment card processing.
The matter for satisfying the requirements of the RFP, then, becomes reliant on using systems that support third-party payment processing.
As a practical matter, in order to meet the transactional efficiency expected by RFP issuers, the vendor also needs ecommerce and back-office systems that integrate with third-party payment processors so that payments can be automatically applied and communicated with minimal manual effort.
Payment Card Tokenization: A Complement to PCI DSS Compliance
While PCI DSS is the overarching requirement for the security of payment card processing, RFPs often cite additional standards for data security, both generally and specifically for payment cards.
One practice that may be cited for an RFP specific to payment cards is Tokenization, where payment card data is removed from a vendor’s system and replaced with a random string of representative numbers, called a token. The token stored by the vendor represents the customer payment card data and continues to work for payment processing purposes.
But the actual cardholder data is remove from the vendor’s systems, servers, databases, and environments and stored elsewhere, typically with a third-party payment processor who specializes in managing the sensitive data. This way, even if a breach were to occur with the vendor, there is no sensitive payment card data to be had, only the effectively worthless token, further reducing PCI scope and potential liability.
Tokenization removes payment card data from a company’s systems, servers, databases, and environments and replaces it with an essentially worthless token -- a string of random representative numbers.
Beyond Payment Card Data: Other Data Security Standards Found in RFPs
RFPs often cite additional standards that don’t address payment card data directly but address data security generally, which inherently includes payment card data.
Among these are the National Institute of Security Standards Technology Cybersecurity Framework (NIST CSF), which is a set of security policies and best practices that the NIST developed to detect and manage cybersecurity risks; and the Department of Defense (DoD) Cybersecurity Certification, cybersecurity standards that the U.S Department of Defense developed for its contractors.
Others the International Organization for Standardization (ISO 2700) standards, developed by ISO to help organizations manage the security of financial information, intellectual property, and PII; and SOX compliance, which refers to the Sarbanes-Oxley Act that the U.S. Congress passed to protect investors and the general public from accounting errors and fraud.
Understanding and Implementing Cardholder Data Security to Win RFPs
A particularly sensitive type of information is Personally Identifiable Information and a particularly sensitive type of PII is cardholder data.
As a result, RFPs generally require the security of payment card processing, which almost exclusively is the responsibility of the vendor. The most prominent standard for the security of cardholder data and payment processing is the Payment Card Industry Security Standard (PCI DSS), a standard often cited by RFPs.
The scope of PCI compliance generally leads vendors to outsource payment processing to a third party. While outsourcing is common, vendors are advantaged by using ecommerce and back-office systems that integrate third-party processing so that manual efforts are limited and the transactional efficiency that RFP issuers expect is met.
RFPs often cite other security standards in addition to PCI DSS, both specifically for payment card data and generally for data security. Tokenization, where cardholder data is removed from vendor systems and replaced with a randomized token for processing purposes, is one complement to payment card data security. Others include standards created by industry groups and government.
Any RFP for digital commerce almost necessarily includes requirements for payment processing as the vendor’s responsibility and, alongside it, the security of payment processing. In order to become the winning bidder for the RFP, vendors must demonstrate capability to understand and implement payment card data security standards.
Previous: Understanding Enterprise RFP Requirements: Security – Sensitive Data and Consumer Privacy
Next: When it Comes to RFPs, Find a Technology Partner: Lose the Dread and Win the Opportunity