If you do not see your question answered under one of the subcategories, please use the form below to submit your question.
The PCI Security Standards Council’s Role and Authority
What is the PCI Security Standards Council?
The Payment Card Industry Security Standards Council was created by American Express, Discover Financial Services, JCB, MasterCard Worldwide and Visa International with to improve payment account security standards and practices. The PCI Security Standards Council maintains the PCI Data Security Standard (PCI DSS) which must be adopted and implemented by all businesses that store, process and/or transmit credit/debit card data.
How does the PCI Security Standards Council make payment card data more secure?
Security of payment card data is the responsibility of every business that participates in payment processing.
Single industry-level security standards supported by the members of the PCI Security Standards Council eliminate confusing, competing, and overlapping brand-specific requirements to simplify compliance for businesses that store payment card data.
If I am deemed compliant with the PCI DSS today by one of the payment card brands, will the other brands in the PCI Security Standards Council recognize this designation of compliance and if so, what information must be put forth to achieve such recognition?
Since the individual payment brands are responsible for their own PCI DSS compliance programs, organizations should follow each brand’s specific compliance processes and procedures. Satisfying the requirements of one member of the PCI SSC should not be construed as compliance that will satisfy all other member payment card brands.
How frequently will the PCI Security Standards Council update the PCI DSS and PA-DSS?
To minimize changes to the standards, the PCI Security Standards Council (PCI SSC) has established a lifecycle approach for PCI DSS and PA-DSS, where version changes to the standards will occur every 3 years. The 3-year standards lifecycle also allows for changes “out-of-cycle” as needed to address critical issues. To ensure that organizations have time to achieve compliance with new versions of the standards, certain new requirements may be phased in with future effective dates.
Are there any plans for PCI SSC to be a single point of contact for a merchant, financial institute or processor to send a PCI DSS compliance report to in the future?”
Because PCI SSC does not have a contractual relationship with merchants, financial institutes, processors, etc., PCI SSC cannot be the central repository for this information. The Council’s focus is to define effective payment-related security standards, as well as to educate and provide resources to the marketplace to drive awareness and adoption of these standards. The payment brands define and manage the compliance programs for these security standards, and entities will continue to send their compliance validation documentation to the payment brands, financial institutions (such as acquirers or merchant banks), or other agents as applicable for each payment card brand compliance program.
Do QSAs and ASVs need to send reports of compliance (ROCs) or scanning results to the PCI Security Standards Council directly?
No. QSAs and ASVs do not send reports of compliance or scanning results to the PCI Security Standards Council. They should continue to follow the payment brand specific procedures.
In case of a suspected breach, should the PCI Security Standards Council be contacted directly?
No. In the event of a suspected account security breach, the business entity should follow existing, brand-specific processes and procedures for notifying the affected payment brand(s) and law enforcement officials.
Will the PCI Security Standards Council provide information on breaches, the status of investigations, or PCI DSS compliance status?
The PCI Security Standards Council does not provide information on the status of breach investigations or PCI DSS compliance efforts. The PCI Security Standards Council receives guidance from the payment brands, the PFI community, and advisory groups regarding emerging threats and forensics trends. However, the PCI Security Standards Council does not a participate in forensics investigations or compliance reporting and does not receive information on specific forensic investigation cases or a specific organizations’ PCI DSS compliance status.
Will the PCI Security Standards Council be involved in performing forensics investigations as a result of an account data compromise event?
The PCI Security Standards Council will not conduct forensics investigations either directly or through a third party in the event of an account compromise.
Will the PCI Security Standards Council approve my organization’s implementation of compensating controls in my effort to comply with the PCI DSS?
The PCI Security Standards Council (PCI SSC) is not able to approve specific configurations or compensating controls since they are not onsite doing the assessment and are therefore not able to understand and review the total security environment.
Each individual approved as a Qualified Security Assessor (QSA) is trained by the PCI SSC regarding the underlying intent of PCI DSS requirements and the evaluation of compensating controls. QSAs are responsible for determining whether a compensating control is sufficient to meet the intent of a requirement during their review of all other controls in place to satisfy PCI DSS requirements. We recommend that you contact a QSA to review your environment and assist in evaluating any compensating controls you may have in place for meeting the intent of PCI DSS requirements.
The Purpose of the PCI Data Security Standard
What is PCI DSS?
PCI DSS stands for Payment Card Industry Data Security Standard. This standard (also referred to simply as “PCI”) outlines a set of security practices that help ensure the safe handling of payment card data. Created by the five major card companies (American Express, Discover JCB, MasterCard and Visa) that make up the Payment Card Industry Security Council, this standard includes 12 distinct requirements that are designed to:
- Build and maintain a secure network
- Protect (cardholder) data in transit or at rest
- Maintain a vulnerability management program
- Implement strong access control measures
- Regularly monitor and test your IT infrastructure
- Maintain an information security policy.
Who must comply with the PCI DSS?
Any entity (merchant or service provider) that stores, processes, and/or transmits cardholder data must be PCI DSS compliant – regardless the size of the entity and volume of transactions made. However, PCI DSS requirements do not only apply to electronic data. Businesses are expected to dispose of printed material which contains payment card details and credit cardholder data in an appropriate way. In large environments where waste management is outsourced to subcontractors such as paper-shred companies, the entities that request such services must make sure that their “service providers” are PCI DSS compliant as well.
Definitions Important to Understanding PCI DSS
What are payment cards?
The PCI DSS defines “payment cards” as all credit/debit/cash cards that are issued with any American Express, Discover, JCB, MasterCard or Visa branding.
What is payment card data?” style=”fancy” icon=”chevron”]Payment card data is information pertaining to credit/debit cards and their owner. This data is classified in 2 categories “Cardholder Data” and “Sensitive Authentication Data.” PCI DSS imposes some storage restrictions on data elements making part of these categories.
What is cardholder data?
Cardholder data refers to all information from a credit card or debit card that is used in a transaction. Cardholder data can include the Primary Account Number (PAN), Cardholder Name and Expiration Date displayed on the front of the card, etc. Cardholder data is digitally stored on the magnetic stripe at the back of the card.
What is sensitive authentication data?
Sensitive Authentication Data is security related information used to authenticate the cardholder’s identity and authorize card transactions. Sensitive Authentication Data elements include Magnetic Stripe data and the Card Validation Code – the three or four digit number security code found either on the front or on the back of a card (a.k.a. CVV, CVV2).
What is the definition of merchant?
PCI DSS defines a “merchant” as any entity that accepts payment cards bearing the logos of any of the five members of PCI SSC (American Express, Discover,
JCB, MasterCard or Visa) as payment for goods and/or services. Note that a merchant that accepts payment cards as payment for goods and/or services can also be a service provider if the services sold result in storing, processing, or transmitting cardholder data on behalf of other merchants or service providers. For example, an ISP is a merchant that accepts payment cards for monthly billing, but also is a service provider if it hosts merchants as customers.
What is a self-assessment questionnaire?” style=”fancy” icon=”chevron”]A self-assessment questionnaire (SAQ) is a reporting requirement of PCI DSS compliance for merchants and service providers. It can be completed in-
house without contracting with a 3rd party. Businesses must complete this security-related questionnaire that examines the current and past state of network security.
What is the definition of “remote access
PCI DSS requirement 8.3 is intended to apply to users that have remote access to the network, where that remote access could lead to access to the
cardholder data environment. In this context, remote access refers to network-level access originating from outside the company’s own network, either from the Internet or from an “untrusted” network or system such as an employee accessing the corporate network using his/her mobile computer. Internal company LAN-to-LAN access (e.g. between two offices via VPN) is not considered remote access for the purposes of this environment.
If the corporate network has appropriate segmentation such that remote users cannot access the cardholder data environment, two-factor authentication during remote access to the corporate network is not required by PCI DSS. However, two-factor authentication is required for any remote access to the cardholder data environment, and is recommended for remote access to the corporate network.
What is a payment gateway?
Payment Gateways connect a merchant to the bank or processor that is acting as the front-end connection to the Card Brands. They are called gateways because they take many inputs from a variety of different applications and route those inputs to the appropriate bank or processor. Gateways communicate with the bank or processor using dial-up connections, Web-based connections or privately held leased lines.
How is IP-based POS environment defined?
The point of sale (POS) environment refers to a transaction that takes place at a merchant location (i.e. retail store, restaurant, hotel, gas station, convenience store, etc.). An Internet protocol (IP)-based POS is when transactions are stored, processed, or transmitted on IP-based systems or systems communicating via TCP/IP.
Benefits of Compliance/Consequences of Non-Compliance with PCI DSS
[_spoiler title=”What happens if I am not compliant?” style=”fancy” icon=”chevron”]Non-compliant businesses may face fines up to $500,000 plus expensive litigation costs. From an operational point of view, level 2, 3 or 4 merchants and
service providers that experience a network security breach can have their level escalated to level 1. Scrutiny, requirements, and compliance costs are higher at level 1. Non-compliance also impacts brand reputation and exposes
corporations to negative publicity that undermines consumer confidence.[_/spoiler]
[_spoiler title=”What are the benefits of implementing PCI DSS?” style=”fancy” icon=”chevron”]PCI DSS is a binding collection of rules designed to promote sound IT security processes. The goal of PCI DSS is to reduce financial fraud
through heightened network security capabilities. There are many benefits of PCI DSS compliance. The most fundamental benefits include:
- Protection of customers’ personal data
- Increased customer confidence through a higher level of data security
- Increased protection against financial losses and remediation costs that arise from security breaches
- Maintain customer trust, and safeguard reputation
- Benchmark and assess the security mechanisms of systems that store, process and/or transmit payment cardholder data
[_spoiler title=”What are the fines and penalties assessed to companies for non-compliance with the PCI DSS?” style=”fancy” icon=”chevron”]Any fines and/or penalties associated with non-compliance with the PCI DSS and/or confirmed
security breaches are defined by each of the payment card brands. For more specific information, please contact the individual payment card brands.[_/spoiler]
[_spoiler title=”If my business was deemed compliant but my system was still breached and payment account data compromised, what liability would my business incur?” style=”fancy” icon=”chevron”]The PCI Security Standards Council is not
responsible for levying any financial or operational consequences on businesses that have either been breached or are suspected of an account data compromise. These businesses should contact the individual payment brands regarding next
steps such as contacting law enforcement, obtaining forensic or other relevant information, and potential consequences should a breach be found to have occurred.[_/spoiler]
[_spoiler title=”What are the consequences to my business if I do not comply with the PCI DSS?” style=”fancy” icon=”chevron”]The PCI Security Standards Council encourages all businesses that store payment account data to comply with the
PCI DSS to help minimize risk to their brand and potential financial consequences associated with account payment data compromises. The PCI Security Standards Council does not manage compliance programs and does not impose any fines or
penalties for non-compliance. Individual payment brands, however, may have their own compliance initiatives including financial or operational consequences to certain businesses that are not compliant.[_/spoiler]
[_spoiler title=”What if a merchant refuses to cooperate?” style=”fancy” icon=”chevron”]PCI is not, in itself, a law. The standard was created by the major card brands such as Visa, MasterCard, Discover, AMEX, and JCB. At their acquirers
discretion, merchants that do not comply with PCI DSS may be subject to fines, card replacement costs, costly forensic audits, brand damage, etc., should a breach event occur. [_/spoiler][/spoiler]
[spoiler title=”Data Storage Provisions of the PCI DSS” style=”fancy” icon=”plus-circle” anchor=”Data Storage in PCI DSS”]
[_spoiler title=”What cardholder data can be stored?” style=”fancy” icon=”chevron”]The PCI DSS specifies which data elements can be stored and how they should be protected. Companies can store the PAN, Cardholder Name and Expiration Date
as long as they are adequately protected. Protection should include encryption using a strong technique such as AES; alternatively the PAN must be hashed or truncated. This protection is important since the PAN together with one of the
other elements is the minimum data required in certain instances for effecting a payment.[_/spoiler]
[_spoiler title=”What sensitive authentication data can be stored?” style=”fancy” icon=”chevron”]None. Companies cannot store Sensitive Authentication Data elements at all, even if encrypted.[_/spoiler]
[_spoiler title=”Can the full credit card number be printed on the consumer’s copy of the receipt?Question 3″ style=”fancy” icon=”chevron”]PCI DSS requirement 3.3 states “Mask PAN when displayed (the first six and last four digits are
the maximum number of digits to be displayed).” While the requirement does not prohibit printing of the full card number or expiry date on receipts (either the merchant copy or the consumer copy), please note that PCI DSS does not
override any other laws that legislate what can be printed on receipts (such as the U.S. Fair and Accurate Credit Transactions Act (FACTA) or any other applicable laws).
Note: This requirement does not apply to employees and other parties with a specific need to see the full PAN, nor does the requirement supersede stricter requirements in place for displays of cardholder data (for example, for point of
sale (POS) receipts). Any paper receipts stored by merchants must adhere to the PCI DSS, especially requirement 9 regarding physical security.[_/spoiler][/spoiler]
[spoiler title=”Scope of PCI DSS (Who and What is Covered)” style=”fancy” icon=”plus-circle” anchor=”Scope of PCI DSS”]
[_spoiler title=”If I only accept credit cards over the phone, does PCI still apply to me?” style=”fancy” icon=”chevron”]Yes. All business that store, process or transmit payment cardholder data must be PCI Compliant.[_/spoiler]
[_spoiler title=”Do organizations using third-party processors have to be PCI compliant?” style=”fancy” icon=”chevron”]Yes. Merely using a third-party company does not exclude a company from PCI compliance. Working through a third party
may cut down on risk exposure and consequently reduce the effort required to validate compliance. However, it does not mean they can ignore PCI.[_/spoiler]
[_spoiler title=”My business has multiple locations. Is each location required to validate PCI Compliance?” style=”fancy” icon=”chevron”]This is determined by your acquiring bank. However, if your business locations process under the
same Tax ID, then typically you are only required to validate once annually for all locations and submit quarterly passing network scans by an PCI SSC Approved Scanning Vendor (ASV), if applicable.[_/spoiler]
[_spoiler title=”Are debit card transactions subject to PCI requirements?” style=”fancy” icon=”chevron”]PCI standards include any debit, credit, and pre-paid cards branded with one of the five card association/brand logos that
participate in the PCI SSC – American Express, Discover, JCB, MasterCard, and Visa International. [_/spoiler]
[_spoiler title=”I’m a small merchant who has limited payment card transaction volume. Do I need to be compliant with PCI DSS?” style=”fancy” icon=”chevron”]All merchants, whether small or large, need to be PCI compliant. The payment
brands have collectively adopted PCI DSS as the requirement for organizations that process, store or transmit payment cardholder data. PCI SSC is responsible for managing the security standards while each individual payment brand is
responsible for managing and enforcing compliance to these standards.[_/spoiler]
[_spoiler title=”Is encrypted cardholder data in scope for PCI DSS?” style=”fancy” icon=”chevron”]Encryption of cardholder data with strong cryptography is an acceptable method of rendering the data unreadable in order to meet PCI DSS
Requirement 3.4. Because encrypted data can be decrypted with the right cryptographic key, however, encrypted cardholder data remains in scope for PCI DSS.
Generally, the encrypted data is the responsibility of the entity (the corporation, organization or business being reviewed) that controls and/or has access to the encrypted data and the decryption keys. It is possible that encrypted
data may potentially be out of scope for a particular entity if, and only if, it is validated that the entity in possession of the encrypted data does not have access to the cleartext cardholder data or the encryption process, nor do
they have the ability to decrypt the encrypted data. This means the entity does not have cryptographic keys anywhere in their environment, and that none of the entity’s systems, processes or personnel have access to the environment where
cryptographic keys are located, nor do they have the ability to retrieve them.
If an entity outsources encryption or key management operations to a third party, the entity is responsible, as part of their due diligence processes, for ensuring that all applicable PCI requirements (for example PTS, PIN, PCI DSS, PA-
DSS, and P2PE) for protection of the account data are being met. This includes responsibility for the security of any cryptographic operations used to protect the data.
Systems performing encryption and/or decryption of cardholder data, and any systems performing key management functions, are always in scope for PCI DSS. Scope reduction for encrypted data may only be considered when that data is
isolated from these processes.
Ultimately, all applicable PCI DSS requirements apply if:
Encrypted cardholder data is stored on a system or media that also contains the decryption key,
Encrypted data is stored in the same environment as the decryption key,
Encrypted data is accessible to an entity that also has access to the decryption key.[_/spoiler]
[_spoiler title=”How does PCI DSS apply to individual PCs or workstations?” style=”fancy” icon=”chevron”]All system components in the network are considered part of the cardholder data environment unless adequate network segmentation is
in place to isolate systems that store, process, or transmit cardholder data from those that do not. Without proper network segmentation, the entire network is in scope for the PCI DSS. Where there are many PCs or workstations in an
environment and all PCs do not need access to the cardholder data environment (CDE), the network segmentation should provide access to the CDE only for the PCs that need access, and should prohibit access for all other PCs.
Where segmentation is used to reduce PCI DSS scope, the assessor must verify that the segmentation controls are effective and working as intended. The assessor would need to determine whether the connected systems provide a path for
other systems into the CDE. If there are other systems on the network which are not adequately segmented (isolated) from the CDE, they could also be brought into scope. Once it has been validated that adequate segmentation is in place,
PCI DSS requirements become relevant and should be applied to the PC population which is in scope. While all connected systems should be considered in scope for a PCI DSS review, the particular PCI DSS requirements applicable to each
system may vary depending on the function of the system and the presence of any additional controls that are implemented. (For example, controls could be in place to prevent the system from accessing cardholder data or from influencing
the security of the CDE in any way). All such controls would need to be verified as part of PCI DSS scope verification.[_/spoiler]
[_spoiler title=”Does PCI DSS apply to merchants who outsource all payment processing operations and never store, process or transmit cardholder data?” style=”fancy” icon=”chevron”]PCI DSS applies to any entity that stores, processes or
transmits cardholder data.
If a merchant outsources all their payment operations, the applicable PCI DSS requirements for the protection of account data would apply to the environment(s) where the data is actually stored, processed and transmitted – such as third
party service providers, payment gateways, etc. However, it is the responsibility of the merchant to ensure that the data they share with third parties is properly handled and protected. Just because a merchant outsources all payment
processing does not mean that the merchant won’t be held responsible by their acquirer or payment brand in the event of an account data compromise.
Additionally, the merchant’s acquirer or payment brand may still require the merchant to validate their PCI DSS compliance status. For example, the merchant may be required to complete SAQ A in which the merchant attests that they have
outsourced all payment processing services, do not store account data, and that they are compliant with PCI DSS Requirement 12.8. PCI DSS Requirement 12.8 states that merchants must have written agreements with their service providers
that include the service provider’s acknowledgement of their responsibility for securing the data in their possession, and also requires that merchants monitor their service provider’s compliance at least annually.
Merchants should check with their acquirer or payment brand to determine their compliance obligations when all payment processing is outsourced.[_/spoiler]
[_spoiler title=”Does PCI DSS apply to paper with cardholder data (receipts, reports, etc.)?” style=”fancy” icon=”chevron”]PCI DSS requirements are applicable if a Primary Account Number (PAN) is stored, processed, or transmitted by any
media – this includes paper records. PCI DSS requirements 9.6 through 9.10 specifically address the safeguarding of paper records containing cardholder data.[_/spoiler]
[_spoiler title=”Are digital images containing cardholder data and/or sensitive authentication data included in the scope of the PCI DSS?” style=”fancy” icon=”chevron”]Forms and images containing cardholder data are subject to the PCI
DSS. PCI DSS requirement 3.4 requires that all cardholder data be rendered unreadable. It does not differentiate between how the data is stored or managed. To comply with PCI DSS, the image and/or paper form will need to be stored in a
compliant manner which would include rendering it unreadable (or protecting that data with appropriate compensating controls). In addition, PCI DSS requirement 3.2 prohibits storage of sensitive authentication data (magnetic stripe, card
validation codes and values (CID, CAV2, CVC2, CVV2), and PIN block data) after authorization. If the entity collects any sensitive authentication data, they must remove or obfuscate such data before they image it, thereby not storing
prohibited data before (and after) the image is scanned.[_/spoiler]
[_spoiler title=”Is pre-authorization account data in scope for PCI DSS?” style=”fancy” icon=”chevron”]Yes, PCI DSS applies wherever cardholder data (CHD) and/or sensitive authentication data (SAD) is stored, processed or transmitted,
regardless of whether it is pre-authorization or post-authorization. There are no specific rules in PCI DSS regarding how long CHD or SAD can be stored prior to authorization, but the data would need to be protected according to PCI DSS.
Use of PTS-validated payment devices and PA-DSS validated payment applications can support PCI DSS compliance for the protection of data prior to authorization.
With respect to SAD, PCI DSS Requirement 3.2 prohibits storage of SAD AFTER authorization, even if encrypted. Whether SAD is permitted to be stored prior to authorization is determined by the individual payment brands, including any
related usage and protection requirements. Additionally, several payment brands have very specific rules that prohibit any storage of SAD and do not make any exceptions. To determine payment brand requirements, please contact the
individual payment brands directly.[_/spoiler]
[_spoiler title=”Are hashed Primary Account Numbers (PAN) considered cardholder data that must be protected in accordance with PCI DSS?” style=”fancy” icon=”chevron”]One-way hashing meets the intent of rendering the PAN unreadable in
storage; however the hashing process and results, as well as the system(s) that perform the hashing, would still be in scope to assure that the PAN cannot be recovered. If the hashing result is transferred and stored within a separate
environment, the hashed data in that separate environment would no longer be considered cardholder data and the system(s) storing the hashed data would be out of scope of PCI DSS. If however, the system hashes and stores the data on the
same system, that system is considered to be storing cardholder data and is within PCI DSS scope. The difference lies in where the data is hashed and then stored.
A hash is intended to be irreversible by taking a variable-length input and producing a fixed-length string of cipher text. As the PAN has been ‘replaced’, it should most often be considered out of scope in the same manner receipt of
truncated PANs are out of scope. However, PCI DSS Requirement 3.4 also states that the hash must be strong and one-way. This implies that the algorithm must use strong cryptography (e.g. collisions would not occur frequently) and the
hash cannot be recovered or easily determined during an attack.
It is also a recommended practice, but not specified requirement, that a salt be included. Since the intent of hashing is that the merchant or service provider will never need to recover the PAN again, a recommended practice is to simply
remove the PAN rather than allowing the possibility of a compromise cracking the hash and revealing the original PAN. If the merchant or service provider intends to recover and use the PAN, then hashing is not an option and they should
evaluate a strong encryption method.[_/spoiler]
[_spoiler title=”Can I fax payment card numbers and still be PCI DSS Compliant?” style=”fancy” icon=”chevron”]Body Any cardholder data that is stored, processed, or transmitted must be protected in accordance with PCI DSS. If faxes or
emails are sent or received via modem over a traditional analogue phone line, these are not considered to be traversing a public network. On the other hand, if a fax or email is sent or received via the internet, they are traversing a
public network and these transmissions must be encrypted per PCI DSS requirements 4.1 and 4.2. Any systems (such as fax or email servers) that the cardholder data passes through must be secured according to PCI DSS. Also, any cardholder
data on the fax or email that is electronically stored must comply with PCI DSS requirement 3.4 to render the cardholder data unreadable.
In addition, requirement 3.2 prohibits storage after authorization of sensitive authentication data (magnetic stripe, CAV2, CVC2, CVV2, CID and PIN block data). To ensure that prohibited data is not stored if received on a fax (for faxes
and emails, this would only be the CAV2, CVC2, CVV2, or CID values printed on the front or back of payment cards), the data should be blacked-out or removed prior to retaining the fax in paper form, and the original fax transmission (via
email, etc.) should be securely deleted from the system in a manner which ensures the data is non-recoverable.
Entities should also protect paper documents that contain cardholder data in accordance with PCI DSS Requirements 9.6 through 9.10.[_/spoiler]
[_spoiler title=”Are truncated Primary Account Numbers (PAN) required to be protected in accordance with PCI DSS?” style=”fancy” icon=”chevron”]Systems that store only truncated PANs (where a segment of PAN data has been permanently
removed) may be considered out of scope for PCI DSS if that system is adequately segmented from the cardholder data environment, and does not otherwise store, process or transmit cardholder data or sensitive authentication data.
However, the system performing the truncation of the PANs, as well as any connected systems and networks, would be in scope for PCI DSS. Note: Access to different truncation formats of the same PAN greatly increases the ability to
reconstruct full PAN, and the security value provided by an individual truncated PAN is significantly reduced. If the same PAN is truncated using more than one truncation format (for example, different truncation formats are used on
different systems), additional controls should be in place to ensure that the truncated versions cannot be correlated to reconstruct additional digits of the original PAN.[_/spoiler]
[_spoiler title=”Does PCI DSS apply to ‘hot cards,’ fraudulent or invalid card numbers, or cancelled cards?” style=”fancy” icon=”chevron”]If the issuer confirms the cards are inactive or disabled, the PANs (Primary Account Numbers) no
longer pose fraud risk to the payment system. The PCI DSS would not apply in these cases. If however, the PAN is later reactivated, PCI DSS will again apply.[_/spoiler]
[_spoiler title=”Do internet service providers need to comply with the PCI DSS?” style=”fancy” icon=”chevron”]If the ISP only provides a “pipe” for internet access, then it is not considered a service provider and is not subject to PCI
DSS compliance. However, if the ISP is providing additional services such as firewalls or hosting functions, it is considered a service provider and would need to comply with the PCI DSS.[_/spoiler]
[_spoiler title=”Is it required that all of a company’s sites, even those located in other countries, must be included in the company’s PCI DSS review?” style=”fancy” icon=”chevron”]Yes. The PCI DSS is a global standard and is applicable
to all entities that process, transmit or store cardholder data regardless of geographic location.
The sites in other countries can only be eliminated from the scope of the primary assessment if those sites are properly segmented from the primary assessed environment. If not, a hacker compromising the sites in other countries could
gain access to the primary assessed environment. If it is desirable to only include certain sites/locations in a PCI DSS review, then that should be clearly noted in the report of compliance as well as noting that specific other
sites/locations were excluded from the assessment. However, a separate PCI DSS review may be required if the other sites store, process or transmit cardholder data. Alternatively, one review can include all sites and system components
for all international locations.
Each payment brand manages their PCI DSS compliance and enforcement programs independently of the PCI Security Standards Council. For answers to specific questions about compliance and enforcement, you should contact each payment brand
to understand programs in the regions in which the company operates.[_/spoiler]
[_spoiler title=”Is VoIP in scope for PCI DSS?” style=”fancy” icon=”chevron”]PCI DSS requirements apply wherever account data is stored, processed, or transmitted. While PCI DSS does not explicitly reference the use of VoIP, VoIP traffic
that contains cardholder data is in scope for applicable PCI DSS controls, in the same way that other IP network traffic containing cardholder data would be.
Note that VoIP transmissions originating from an external source and sent to an entity’s environment are not considered in scope for the entity’s PCI DSS compliance, as an entity cannot control the method of inbound phone calls that
their customers and other parties may make, including whether any account data sent over that transmission is being adequately protected by the caller. However, the entity does have control over transmissions, storage and processing of
VoIP traffic within their own network, and any outbound transmissions that they instigate. Therefore, VoIP traffic containing account data that is stored, processed or transmitted internally over an entity’s network, or transmitted
externally by the entity, is in scope for applicable PCI DSS controls.
The PCI SSC also published an Information Supplement titled “Protecting Telephone Based Payment Card Data”
which provides additional guidance for protecting cardholder data that is received via voice communications. [_/spoiler]
[_spoiler title=”How extensive must background checks be on employees who have access to cardholder data?” style=”fancy” icon=”chevron”]PCI DSS requirement 12.7 requires employers to “screen potential employees to minimize the risk of
attacks from internal sources…For those employees such as store cashiers who only have access to one card number at a time when facilitating a transaction, this requirement is a recommendation only.”
In general, it is expected that a company would have a policy and process for background checks, including their own decision process for which background check results would have an impact on their hiring decisions (and what that impact
would be). The check should be exhaustive enough (within the constraints of local law) to reduce the risk of fraud from internal resources. Examples of criteria, if permissible by law; that could be checked include employment history,
criminal records, credit history, and reference checks.[_/spoiler]
[_spoiler title=”Is two-factor authentication required between two different segments of an internal network?” style=”fancy” icon=”chevron”]PCI DSS requirement 8.3 is intended to apply to users that have remote access to the network,
where that remote access could lead to access to the cardholder data environment. In this context, remote access refers to network-level access originating from outside the company’s own network, either from the Internet or from an
“untrusted” network or system such as an employee accessing the corporate network using his/her mobile computer. Internal company LAN-to-LAN access (e.g. between two offices via VPN) is not considered remote access for purposes of this
requirement. If the corporate network has appropriate segmentation such that remote users cannot access the cardholder data environment, two-factor authentication during remote access to the corporate network is not required by PCI DSS.
However, two-factor authentication is required for any remote access to the cardholder data environment, and is recommended for remote access to the corporate network.[_/spoiler]
[_spoiler title=”Can VLANS be used for network segmentation?” style=”fancy” icon=”chevron”]In general, implementing adequate network segmentation can reduce the scope of the PCI DSS assessment if it isolates systems that store, process,
or transmit cardholder data from other systems. While this segmentation can be implemented with, for example, properly-configured internal firewalls, routers with strong access control lists, VLANs, or other technologies that restrict
access to a particular network segment, the PCI Security Standards Council is not able to offer an opinion about how your organization can achieve adequate network segmentation since it requires an understanding of security features and
controls implemented in your environment.[_/spoiler]
[_spoiler title=”How do I reduce the scope of a PCI DSS assessment?” style=”fancy” icon=”chevron”]Network segmentation or isolating (segmenting) the cardholder data environment from the remainder of an entity’s network is strongly
recommended as a method that may reduce the scope of a PCI DSS assessment. At a high level, adequate network segmentation isolates systems that store, process, or transmit cardholder data from those that do not.
Network segmentation can be achieved through a number of physical or logical means, such as properly configured internal network firewalls, routers with strong access control lists, or other technologies that restrict access to a
particular segment of a network.
To reduce the scope of the cardholder data environment requires a clear understanding of business needs and processes related to the storage, processing or transmission of cardholder data. Restricting cardholder data to as few locations
as possible by elimination of unnecessary data, and consolidation of necessary data, may require reengineering of long-standing business practices. Documenting cardholder data flows via a dataflow diagram helps fully understand all
cardholder data flows and ensures that any network segmentation is effective at isolating the cardholder data environment. The adequacy of a specific implementation of network segmentation is highly variable and dependent upon a number
of factors, such as a given network’s configuration, the technologies deployed, and other controls that may be implemented. You should be validating the scope of your cardholder data environment as part of your annual PCI DSS assessment
process, including validation of any network segmentation.[_/spoiler]
[_spoiler title=”What is the scope of a PCI DSS assessment for a network that is not segmented?” style=”fancy” icon=”chevron”]Without proper network segmentation to isolate the systems that store, process or transmit cardholder data from
those that do not, all system components in that network are considered part of the cardholder data environment, the entire network is in scope for PCI DSS, and all PCI DSS requirements apply.[_/spoiler]
[_spoiler title=”How should a hosting provider demonstrate PCI DSS compliance (as part of their client’s assessment or in their own separate assessment)?” style=”fancy” icon=”chevron”]Per the Scope of Assessment section of the PCI DSS
Requirements and Security Assessment Procedures, there are two options for hosting providers and other third party providers to validate compliance:
- They can undergo a PCI DSS assessment on their own and provide evidence to their customers to demonstrate their compliance, or
- If they do not undergo their own PCI DSS assessment, they can have their services reviewed during the course of each of their customer’s PCI DSS assessments.
[_spoiler title=”Why does PCI DSS requirement 8.5.14 require account lockout?” style=”fancy” icon=”chevron”]The intent of PCI DSS requirement 8.5.14 is to lock out accounts due to suspicious activity, to prevent a malicious user from
gaining access to users’ accounts, by continually trying to guess a user’s password over and over. The lockout occurs after six consecutive failed login attempts, and remains in place for at least 30 minutes or until reset by the
[_spoiler title=”Why does PCI DSS requirement 8.5.15 require consoles/PCs to become “locked” after 15 minutes of idle time?” style=”fancy” icon=”chevron”]The intent of this requirement is to prevent someone from using an unattended
console/PC to gain unauthorized access to the user’s computer and accounts, and/or the company’s network. This does not prevent legitimate activities from being performed while the console/PC is unattended. For example, if a user needs
to run a program from an unattended computer, they can login to the computer to initiate the program, and then either logout or “lock” the computer so that no one else can use their login while the computer is unattended. An example of
how to meet this requirement includes configuring an automated screensaver to launch whenever the console has been idle for 15 minutes, and requires the logged-in user to enter their password in order to unlock the screen.
Note: For critical systems (for example, systems that perform security functions or have access to sensitive data), it may be appropriate to reduce the time that the system is idle before the console is locked.[_/spoiler][/spoiler]
[spoiler title=”Categories/Levels of PCI Merchants and Providers” style=”fancy” icon=”plus-circle” anchor=”Levels for PCI DSS”]
[_spoiler title=”Is there a distinction between merchant types for purposes of PCI DSS?” style=”fancy” icon=”chevron”]All merchants that acquire payment card transactions are categorized in 4 distinct levels, as determined by their
number of annual transactions:
- Level 1: Merchants with more than six million card transactions and merchants which cardholder data has been compromised.
- Level 2: Merchants with card transactions between one million and six million
- Level 3: Merchants with card transaction between 20,000 and one million
- Level 4: All other merchants
These levels determine the validation processes that a merchant must undertake in order to achieve and maintain compliance.[_/spoiler]
[_spoiler title=”Is there a distinction between the different types of service providers?” style=”fancy” icon=”chevron”]
All service providers that process credit card transactions are categorized in the following 3 levels:
- Level 1: All payment processors and payment gateways
- Level 2: All service providers not in level 1 but with more that 1 million credit card accounts or transactions.
- Level 3: Service providers not in Level 1, with fewer than one million annual credit card accounts or transactions.
These levels determine the validation processes that a service provider must undertake in order to achieve and maintain compliance.[_/spoiler][/spoiler]
[spoiler title=”Steps to PCI DSS Compliance” style=”fancy” icon=”plus-circle” anchor=”Steps to PCI Compliance”]
[_spoiler title=”What are the PCI DSS requirements?” style=”fancy” icon=”chevron”]PCI DSS includes 12 requirements, often referred to as the “digital dozen.”
- Install and maintain a firewall configuration to protect cardholder data.
- Do not use vendor supplied defaults of system passwords and other security parameters
- Protect stored cardholder data
- Encrypt transmission of cardholder data across open, public networks.
- Use and regularly update antivirus software or programs
- Develop and maintain secure systems and applications
- Restrict access to cardholder data by business need-to-know
- Assign a unique ID to each person with computer access
- 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 employees and contractors.
[_spoiler title=”I am a merchant. How do I become PCI DSS compliant?” style=”fancy” icon=”chevron”]
Becoming PCI DSS compliant requires your business to fulfill and demonstrate all twelve requirements of PCI DSS. This includes:
- Level 1 merchants: Annual on-site security audit and quarterly network scan. On-site security audits are performed by a Qualified Security Assessor (QSA).
- Level 2, 3, 4 merchants: Annual self-assessment questionnaire and quarterly network scan. Self-assessment questionnaires are compiled in-house by the merchant. Network scans are performed by an approved scan vendor (ASV).
[_spoiler title=”I am a service provider. How do I become PCI DSS compliant?” style=”fancy” icon=”chevron”]
Becoming PCI DSS compliant requires businesses to fulfill and demonstrate all the twelve requirements of PCI DSS. This includes:
- Level 1 & 2 service providers: Annual on-site security audit and quarterly network scan. On–site security audits are performed by a Qualified Security Assessor (QSA).
- Level 3 service providers: Annual self-assessment questionnaire and quarterly network scan. Self-assessment questionnaires are compiled in-house by the service provider. Network scans are performed by an approved scan vendor(ASV).
[_spoiler title=”What does a small-to-medium sized business (Level 4 merchant) have to do in order to satisfy the PCI requirements?” style=”fancy” icon=”chevron”]To satisfy the requirements of PCI, a merchant must:
- Identify your Validation Type as defined by PCI DSS – see below. This is used to determine which Self-Assessment Questionnaire (SAQ) is appropriate for your business.
- SAQ A – Card-not-present (ecommerce or mail/telephone-order) merchants, all cardholder data functions outsourced. This would never apply to face-to-face merchants.
- SAQ B – Imprint-only merchants with no electronic cardholder data storage or stand alone, dial-out terminal merchants with no electronic cardholder data storage.
- SAQ C – Merchants with payment application systems connected to the internet, no electronic data storage.
- SAQ C-VT – Merchants using only web-based virtual terminals, no electronic cardholder data storage.
- SAQ D – All other merchants not included in descriptions for SAQ types A through C above, and all service providers defined by a payment card brand as eligible to complete an SAQ.
- Complete the Self-Assessment Questionnaire according to the instructions in the Self- Assessment Questionnaire Instructions and Guidelines. You can find the SAQ documents and other resources here.
- Complete and obtain evidence of a passing vulnerability scan with a PCI SSC Approved Scanning Vendor (ASV). Note scanning does not apply to all merchants. It is required for SAQ C and D – those merchants with external facing IPaddresses. Basically if you electronically store cardholder information or if your processing systems have any internet connectivity, a quarterly scan by an approved scanning vendor is required.
- Complete the relevant Attestation of Compliance in its entirety (located in the SAQ tool).
- Submit the SAQ, evidence of a passing scan (if applicable), and the Attestation of Compliance, along with any other requested documentation, to your acquirer.
All merchants, small or large, need to be PCI compliant. The payment brands have collectively adopted PCI DSS as the requirement for organizations that process, store or transmit payment cardholder data.[_/spoiler]
[_spoiler title=”Am I PCI compliant if I have an SSL certificate?” style=”fancy” icon=”chevron”]No. SSL certificates do not secure a Web server from malicious attacks or intrusions. High assurance SSL certificates provide the first tier
of customer security and reassurance such as the below, but there are other steps necessary to achieve PCI Compliance.
• A secure connection between the customer’s browser and the Web server
• Validation that the Website operators are a legitimate, legally accountable organization[_/spoiler]
[_spoiler title=”How long does it take to move back to my original level after a breach that moved me to level 1?” style=”fancy” icon=”chevron”]Moving back to you original level takes two years after a breach penalty caused your company
to be designated level 1. The first year is dedicated to fixing any procedural errors that may have led to the security breach. The second year is a buffering period to ensure that no new security breaches have occurred.[_/spoiler]
[_spoiler title=”What are the requirements that have to be satisfied to be in compliance with the PCI Data Security Standard” style=”fancy” icon=”chevron”]The PCI Data Security Standard is a multifaceted security standard that includes
requirements for security management, policies, procedures, network architecture, software design and other critical protective measures. The PCI Data Security Standard is comprised of 12 general requirements designed to:
- Build and maintain a secure network,
- Protect cardholder data,
- Ensure the maintenance of vulnerability management programs,
- Implement strong access control measures,
- Monitor and test networks, and
- Ensure the maintenance of information security policies.
[_spoiler title=”Can an entity be PCI DSS compliant if they have performed quarterly scans, but do not have four “passing” scans?” style=”fancy” icon=”chevron”]PCI DSS requires entities to perform internal and external quarterly
vulnerability scans, identify and address vulnerabilities in a timely manner, and verify through rescans that vulnerabilities have been addressed. In order to achieve these objectives, an entity would need to show “clean” or “passing”
quarterly scans for the previous four quarters for both their external and internal environments. A “clean” or “passing” scan generally means:
- No configuration or software was detected that results in an automatic failure (such as the presence of default accounts and passwords, etc.)
- For external scans, no vulnerabilities with a score of 4.0 or higher on the Common Vulnerability Scoring System (CVSS)
- For internal scans, no “High” vulnerabilities as defined in PCI DSS Requirement 6.2
With new vulnerabilities continuously identified, regular scanning becomes an integral part of an organization’s vulnerability management process leading to a cycle of scanning, patching and rescanning until a “clean” scan is obtained.
However, due to the frequency of new vulnerabilities being identified, it may not always be possible to produce a single, clean scan for every quarter.
For example, following a quarterly scan which identifies a number of vulnerabilities, the entity would then need to fix all the identified vulnerabilities and performs a rescan to verify. The rescan may show that the vulnerabilities
identified in the first scan have been addressed, but new vulnerabilities that were not present in the original scan have since appeared.
In this case, instead of having a single, environment-wide scan report, an entity may verify they have met the scanning requirements through a collection of scan results which together show that all required scans are being performed,
and that all applicable vulnerabilities are being identified and addressed on an ongoing, quarterly basis.
To verify that the quarterly scan requirement has been met, the following should be documented:
- Scans of all in-scope systems were performed for each quarterly period, and all in-scope systems are covered by the entity’s scan-remediate-rescan processes
- Rescans were performed as necessary, and show that vulnerabilities identified in the initial quarterly scans have been remediated, for all affected systems, as part of the quarterly process
- The entity has processes in place to remediate currently identified vulnerabilities
- Repeated failing scans are not the result of poor remediation practices resulting in previously identified vulnerabilities not being properly addressed
If, however, an entity does not have four passing quarterly scans because they didn’t schedule the scans properly, the scans are incomplete, or the identified vulnerabilities haven’t been addressed from one quarter to the next, then the
entity has not met the requirement.
Note: results from quarterly external vulnerability scans may also be required by acquirers and payment card brands as part of an entity’s annual compliance validation. Entities should contact their acquirer (merchant bank) and/or the
payment brands directly to understand their reporting requirements for external scans.[_/spoiler]
[_spoiler title=”What are the steps are necessary to validate compliance with PCI DSS?” style=”fancy” icon=”chevron”]In accordance with payment brands’ compliance programs, those merchants and service providers who are permitted by the
payment brands to validate their compliance with the PCI DSS using a Self-assessment Questionnaire (SAQ) may need to complete the following steps:
- Complete the SAQ according to the Self- Assessment Questionnaire Instructions and Guidelines document.
- Complete a clean vulnerability scan with a PCI SSC Approved Scanning Vendor (ASV), and obtain evidence of a passing scan from the ASV.
- Complete the relevant Attestation of Compliance in its entirety (located in the SAQ).
- Submit the SAQ, evidence of a passing scan, and the Attestation of Compliance, along with any other requested documentation, to your acquirer or payment brand.
Merchants should consult with their acquirer (merchant bank) or the payment brands directly to determine if they are eligible or required to submit an SAQ, and if so, which SAQ is appropriate for their environment.[_/spoiler]
[_spoiler title=”How does an organization maintain compliance when a standard changes?” style=”fancy” icon=”chevron”]To minimize changes to the standards, the PCI Security Standards Council (PCI SSC) has established a lifecycle approach
for PCI DSS and PA-DSS, where major version changes to the standards will occur every 3 years (for example, an update from version 2.0 to version 3.0). To ensure organizations have enough time to transition to a new standard without
falling out of compliance, the previous version will remain active for 14 months after a major version of the standard is published. This ensures a gradual, phased introduction of any updated requirements, and helps to prevent
organizations from becoming noncompliant when changes are published. The 3-year standards lifecycle also allows for changes “out-of-cycle” as needed to address critical issues or errata. To ensure that organizations can maintain
compliance with updated versions of the standards, new requirements may be phased in with future effective dates.[_/spoiler]
[_spoiler title=”What is a network security scan and how often do I have to scan? ” style=”fancy” icon=”chevron”]A network security scan involves an automated tool that checks a merchant or service provider’s systems for
vulnerabilities. The tool will conduct a non-intrusive scan to remotely review networks and Web applications based on the external-facing Internet protocol (IP) addresses provided by the merchant or service provider. The scan will
identify vulnerabilities in operating systems, services, and devices that could be used by hackers to target the company’s private network. Note, typically only merchants with external facing IP address are required to have passing
quarterly scans to validate PCI compliance. This is usually merchants completing the SAQ C or D version.
You are required to submit a passing scan every 90 days/once per quarter. Merchants and service providers should submit compliance documentation (successful scan reports) according to the timetable determined by their acquirer.
[spoiler title=”The PCI Self Assessment Questionnaire” style=”fancy” icon=”plus-circle” anchor=”SAQs in PCI”]
[_spoiler title=”How do I determine whether my business is required to conduct an independent assessment or a self-assessment?” style=”fancy” icon=”chevron”]Merchants should contact the acquiring financial institutions with whom they
have merchant agreements (for example, their merchant bank) to determine whether they must validate compliance and the specific requirements for performing and reporting their compliance validation. Service providers should contact the
individual payment brands for further information.[_/spoiler]
[_spoiler title=”Why are there multiple PCI DSS Self-assessment Questionnaires (SAQs)?” style=”fancy” icon=”chevron”]The PCI Data Security Standard Self-assessment Questionnaire (SAQ) is a validation tool to assist merchants and service
providers in demonstrating their compliance with the PCI Data Security Standard (PCI DSS) through a self- assessment, as permitted by the payment brands. There are multiple versions of the SAQ to meet various scenarios depending on how
your organization stores, processes, or transmits cardholder data. For more information on how to complete the SAQ, please refer to the “Self-Assessment Questionnaire Instructions and Guidelines,” available in the document library on the Council website. Another document to help you better understand the PCI DSS and complete the SAQ is “Navigating PCI
DSS: Understanding the Intent of the Requirements.” Merchants should also consult with their acquirer (merchant bank) or the payment brands directly to determine if they are eligible or required to submit an SAQ, and if so, which SAQ is
appropriate for their environment.[_/spoiler]
[_spoiler title=”Is a “P2PE Assessor” required for a merchant’s PCI DSS assessment if the merchant uses a Council-listed P2PE solution?” style=”fancy” icon=”chevron”]No, merchants using P2PE solutions are not required to engage a P2PE
assessor [that is, a QSA (P2PE) or PA-QSA (P2PE)] for their PCI DSS assessments. Merchants using Council-listed P2PE solutions will continue to validate their PCI DSS compliance as determined by the payment brand compliance programs. For
example, a merchant may need to engage a QSA to perform an onsite assessment or they may be eligible to complete a self-assessment questionnaire (SAQ). [_/spoiler]
[_spoiler title=”If a merchant has multiple processing environments, should the merchant complete multiple SAQ forms to validate their PCI DSS compliance?” style=”fancy” icon=”chevron”]If a merchant has multiple processing environments,
whereby one environment qualifies it to complete SAQ form A and another qualifies it to complete SAQ form B, then it is advisable that the merchant default to the more stringent of the two SAQ forms (in this case, SAQ form B). However,
we recommend that the merchant consult with its acquirer to determine which SAQ form would be appropriate to validate the merchant’s PCI DSS compliance.[_/spoiler][/spoiler]
[spoiler title=”Payment Application Provisions of the PCI DSS” style=”fancy” icon=”plus-circle” anchor=”Payment Apps in PCI DSS”]
[_spoiler title=”What is PA-DSS and PABP?” style=”fancy” icon=”chevron”]PA-DSS refers to Payment Application Data Security Standard maintained by the PCI Security Standards Council. PABP is Visa’s Payment Application Best Practices,
which is now referred to as PA-DSS. Visa started the program, and it has been transitioned to the PCI Security Standards Council (PCI SSC).
In 2005, to address the critical issue of payment application security, Visa created the Payment Application Best Practices (PABP) requirements to ensure vendors provide products which support merchants’ efforts to maintain PCI DSS
compliance and eliminate the storage of sensitive cardholder data. See www.visa.com/pabp for more information.
The Payment Card Industry Security Standards Council (PCI SSC) will maintain the PA-DSS and administer a program to validate the compliance of payment applications with this standard. The PCI SSC now publishes and maintains a list of
PA-DSS validated applications. Click here for more information.[_/spoiler]
[_spoiler title=”Can a payment application that uses cryptographic keys hard-coded by the vendor be PA-DSS compliant if they cannot be changed by the customer?” style=”fancy” icon=”chevron”]No. In order to meet PA-DSS and PCI DSS
requirements, the payment application must facilitate the customers’ ability to perform key changes periodically and as required by the customer in case of suspected compromise. This functionality must be included within the application
along with instructions on how to perform key changes. If this requirement can only be met by reinstalling the application, the customer must be able to perform this process to change cryptographic keys without requiring a new software
release or code update from the vendor. Additionally, the vendor must include instructions on key management processes, including performing key changes, as part of the PA-DSS Implementation Guide.[_/spoiler]
[_spoiler title=”What is a payment application? ” style=”fancy” icon=”chevron”] The Attestation of Compliance for Self Assessment Questionnaires B, C, and D asks what Payment Application is in use, and the Payment Application. A payment
application is a commercial application that stores, processes, or transmits cardholder data as part of authorization or settlement. A common example of a payment application is the software running on a point of sale (POS) terminal. To
obtain details about a payment application on a POS, please contact the point of sale terminal provider or your acquiring bank (merchant bank).
Note: When a PA-DSS validated payment application has expired, it is listed as “acceptable” only for pre-existing deployments, or in other words, for customers that have already purchased and deployed the product. The PCI SSC encourages
entities wishing to purchase a payment application to check the application’s expiration date as part of their purchasing due diligence process. Whether, and for how long, an entity is permitted to continue using an expired application
that is only “Acceptable only for Pre-Existing Deployments” is determined by the individual payment brands and/or acquirers, and should be discussed with them.[_/spoiler]
[_spoiler title=”For the list of Validated PA-DSS Applications, what is the difference between Revalidation Date and Expiry Date?” style=”fancy” icon=”chevron”]Revalidation Date: Annually, the software vendor is required to
revalidate by completing Part 3b of the Attestation of Validation form, confirming that no changes have been made to the application version listed as a Validated Payment Application. The vendor submits the Attestation form and
revalidation fees to the PCI Security Standards Council (PCI SSC) prior to the listed Revalidation Date. If there is a new or changed version of the application that the vendor wants listed, the vendor goes through the process for either
a Major Update (new PA-DSS assessment) or Minor Update (Change Analysis).
Expiry Date: Each application is given an expiration date, after which an assessment against the current version of PA-DSS is required in order to renew the application listing.
When a PA-DSS validated payment application has reached its expiry date, it is listed as acceptable only for pre-existing deployments, or in other words, for customers that have already purchased and deployed the product. Note that if
the software vendor wishes to continue selling the application, the application must undergo a new PA-DSS assessment in order for the listing to be renewed. The PCI SSC encourages entities wishing to purchase a payment application to
check the application’s expiry date as part of their purchasing due diligence process. Whether, and for how long, an entity is permitted to continue using an expired application that is only “acceptable for pre-existing deployments” is
up to the individual payment brands and/or acquirers, and should be discussed with them.
Please refer to the PA-DSS Program Guide for more details on the Revalidation Date and Expiry Date. [_/spoiler]
[_spoiler title=”How can I know if a payment application is PA-DSS validated?” style=”fancy” icon=”chevron”]The List of Validated Payment
Applications on the PCI SSC website is the authoritative list of applications which have been accepted by PCI SSC as PA-DSS validated. If an application is not included in the list, it is not PA-DSS validated. Each application on
the list has a version number which represents the specific version of the application that was reviewed in the PA-DSS assessment. The format of the version number is determined by the application vendor and is updated by the vendor
according to their defined versioning methodology. Note that an application may have multiple versions listed as PA-DSS validated, but only those specific versions listed on the PCI SSC website are considered PA-DSS validated. Also
note that compliance mandates for use of PA-DSS validated payment applications are managed by the individual payment brands, not by the PCI Security Standards Council. For queries about how usage of a particular payment application
affects PCI DSS compliance, please contact your acquirer (merchant bank) or the payment brands directly.[_/spoiler]
[_spoiler title=”What happens if I am using a PA-DSS validated payment application that is breached?” style=”fancy” icon=”chevron”]The Council requires that approved PA-QSAs carry appropriate liability insurance. The appropriate response
and procedures to be followed in the event of a breach should be accounted for in any service contract you sign with a software vendor.[_/spoiler]
[_spoiler title=”Is it acceptable to make minor changes to a PA-DSS validated application and retain the existing version number?” style=”fancy” icon=”chevron”]Even if there is no impact on PA-DSS requirements, all changes to the
software of a validated PA-DSS application must result in a new version number. This ensures that all parties involved can clearly determine whether a particular version of an application is PA-DSS validated. Note that an application may
have multiple versions listed as PA-DSS validated, but only those specific versions listed on the PCI SSC website are considered PA-DSS validated. If an Administrative Change (as defined in the PA-DSS Program Guide) is made to an
application such that there is no change to the software itself (for example, corporate entity name change), then the version number of the application may remain unchanged at the application vendor’s discretion. The application vendor
should follow the process set out in the PA-DSS Program Guide in order for the List of Validated Payment Applications to be updated.[_/spoiler]
[_spoiler title=”If a merchant is using a payment application listed as “acceptable only for pre-existing deployments,” is the merchant allowed to install more copies of the application?” style=”fancy” icon=”chevron”]Compliance
validation programs are managed by the individual payment brands, not by the PCI Security Standards Council. Payment brand validation programs may include whether certain applications must be PA-DSS validated, under what conditions non-
PA-DSS applications may be used, timeframes for mandatory use of PA-DSS applications, reporting requirements, due dates, fines and penalties, etc. For information about individual payment brand compliance programs, please contact your
acquirer (merchant bank) or the payment brands directly. Questions related to new installations of a payment application listed as “acceptable only for pre-existing deployments”, including how onboarding or transferring of merchant
accounts may affect use of these applications, should be addressed to the acquirer and/or applicable payment brand.[_/spoiler][/spoiler]
[spoiler title=”Acquiring Banks Information and Provisions of the PCI DSS” style=”fancy” icon=”plus-circle” anchor=”Acquiring Banks in PCI DSS”]
[_spoiler title=”What are the responsibilities of acquiring banks?” style=”fancy” icon=”chevron”]Acquirers are not currently mandated to carry out any specific PCI DSS validation or certification process.
Nevertheless, these organizations are still required to be PCI DSS compliant, therefore acquiring banks must ensure PCI DSS compliance either by conducting internal audits themselves (following the criteria provided on the self
assessment questionnaire) or by outsourcing the process to Qualified Security Assessors (QSAs).
In addition, acquiring banks are responsible for ensuring:
- PCI DSS compliance of their merchants
- PCI DSS compliance of all service providers through which they or their merchants store, transmit or process payment card data.
All Acquiring Banks (merchant banks) must ensure that the merchants and service providers validate at the appropriate level, and then obtain the compliance validation documentation from merchants with more than 20,000 transactions per
year. Following receipt of compliance reports, acquirers must compile and submit a monthly status reports on compliance to the major card associations. All compliance validation documentation must be kept, and made available to the card
associations upon request. Ideally acquiring banks should verify that service providers send compliance validation documentation to card associations.[_/spoiler][/spoiler]
Share your question below and Loricca’s IT Security and Compliance experts will be happy to answer it. You can also email email@example.com your question. We will do our best to have the answer for you within one business day.[column size=”1/2″ center=”yes”][xyz-ihs snippet=”Zoho-form—FAQ”][/column]