Payment Card Industry Compliance

No, the PCI Security Standards Council does not replace the individual brands' compliance programs. The individual participating payment brands (Visa, MasterCard, etc) will separately determine what entities must be compliant, including any brand-specific enforcement programs.

In order to log into the site you must have been previously added. If you are a new customer to Sage Payment Solutions, use of the Portal to validate/certify is not required for 90 days. If it has been 90 days, or you are a long-standing Sage Payment Solutions customer, please contact 1-800-261-0240 and ask to speak to a Compliance representative, or you may contact a Compliance representative via email at pcicompliance@sagepayments.com.

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. For questions regarding compliance validation requirements and deadlines as well as compliance reporting requirements, it is recommended that you contact your Merchant Acquirer (credit card processor).

For more information regarding the PCI security standards and supporting documentation, including the “Navigating the PCI DSS” as well as targeted Self Assessment Questionnaires to assist small and medium merchants, please visit the PCI SSC website at: www.pcisecuritystandards.org.

PCI DSS is the standard for merchants and service providers to protect cardholder data. The PA-DSS and PTS (formerly PED) device security requirements support the overall implementation of PCI DSS by allowing merchants to choose from Council certified payment applications and PTS devices to further cardholder data security. PA-DSS and PTS are not merchant initiatives. Rather, they are geared toward the application providers and PTS device manufacturers who must submit their applications and devices for testing against the standards. That said, merchants that utilize these applications and PTS devices must validate that they are using certified applications/approved devices when asked to do so by their Merchant Acquirer (credit card processor).

A list of certified QSA’s are located at the following link:

https://www.pcisecuritystandards.org/pdfs/pci_qsa_list.pdf

Scans can take 30 minutes to 1 ½ hours and depends on where you are in the queue when you request the scan.

Log into Trustwave (https://login.trustwave.com/portal-core/home) and click on your dashboard. If you have any questions related to what you need to do, please contact Trustwave at (1-800-239-2468) or you may email them at spssupport@trustwave.com.

During your self assessment Trustwave will give you the ability to download samples to use for your company. The exception is SAQd merchants where infrastructures are more complex and for which customized policies and procedures to deal with the complexity are required. For these the merchant can customize their own or hire Trustwave or another QSA to create the policies and procedures for them.

During your self assessment Trustwave will give you the ability to download samples to use for your company.

Anyone that stores, processes or transmits credit cards is subject to some sort of certification with respect to PCI. Your customers credit card information is being entered into an external website (whether by you or your customers) and as such you as the merchant are ultimately responsible for ensuring the data is being handled safely. Fortunately PCI has regulations in place that also extend to the companies that run these external websites (Service Providers) and they too must receive certification. As you complete your PCI-DSS, the Self Assessment Questionnaire (SAQ) should ask you whether you have validated that the Service Provider you chose is PCI Compliant. With an entirely hosted (Saas-based) application, that would mean that they would have achieved their PCI-DSS Service Provider Level 1 or Level 2 certification. Level 1 certifications can be verified online with Visa or MasterCard. Level 2 Service Providers must submit their application through a Level 1 Service Provider to Visa and MasterCard, but should have some confirmation from either the Service Provider or Visa/MasterCard of their Service Level 2 certification and when it expires. As a merchant, your decision to enlist the services of an 3rd party to store, process or transmit your customers credit card data does not relieve you of the need to ensure that data is being handled pursuant to the PCI-DSS. The SAQ is the means by which the card brands ensure you remain engaged and are actively involved in ensuring the Service Provider receives/maintains their PCI certification.

It is actually commonplace for a merchant to have multiple MID’s for different terminals in their business. If the MID’s are all in the same industry (Mail Order Telephone Order-MOTO; Retail; e-Commerce) and are all at the same location, then yes, we can “chain” the MID’s together so that your PCI-DSS Self Assessment Questionnaire covers all of the MID’s. If however the MID’s are for separate industries and/or are for multiple locations, “chaining” of the MID’s cannot be done, and separate PCI-DSS SAQ’s must be completed that relate to the different industry and/or locations. If you have multiple MID’s that meet the above criteria for chaining, please contact pcicompliance@sagepayments.com and provide the list as well as your contact information. A compliance representative will respond to you and confirm the chaining has taken place. You may also contact us at 1-800-261-0240 and ask to speak to a Compliance Representative.

The PCI DSS analysis is $50.00, billed on an annual basis. It will be debited to the merchant’s end of the month processing fees. The PCI DSS Certificate fee will be billed annually beginning in the applicable month required for recertification.

If the multiple MID’s are in the same location and the same industry (Retail, MOTO, eCommerce), we can “chain” the MID’s to a master MID and will only be required to pay one $50.00 fee and complete the PCI DSS once. If the MID’s are for different locations and/or different industries, the $50.00 fee must be paid for each and the PCI-DSS certification must be completed for each.

Yes, the merchant will have to upload their PCI DSS certificate on theTrustwave/Trustkeeper site (https://sagepayments.pci.trustwave.com) Sage will manually validate the PCI DSS certificate and credit $40 of the $50 PCI DSS fee charged to the merchant account to offset the administrative costs of validating the certificate.

Yes. If you have 10 or more locations, a break will be applied based on the total volume. To qualify for the break though, you must notify pcicompliance@sagepayments.com and provide the MID’s and request the credit.

Yes, Sage has partnered with Trustwave to provide a bundled rate for this program. This Fee is extremely competitive with what other processors are billing for this service. Our competitive analysis revealed annual rates from $139.00 - $250.00.

Yes, the requirement is for merchants to have their businesses reviewed annually to ensure compliance.

As a Visa mandate, the Merchant Acquirer (credit card processor) has been directed to ensure merchants are using a PA-DSS certified compliant software (if they are storing, processing or transmitting credit card transactions via software). If you are breached after July 1, 2010 and it is discovered you were not using a PA-DSS compliant software Visa can and likely will impose fines/penalties which will be passed through to you as the merchant.

Merchant Acquirer’s are mandated by Visa to validate your use of PA-DSS certified compliant software. If you are asked to validate, and are found to be using a non-compliant software, your Merchant Acquirer can require you to begin using PA-DSS compliant software to process credit cards, or terminate your credit card processing account if you refuse.

Yes. PA-DSS applies to any application that stores, processes or transmits credit card information.

PA-DSS does NOT apply to a payment application developed for and sold to only one customer since this application will be covered as part of the customer’s normal PCI DSS compliance review. Note that such an application (which may be referred to as a “bespoke” application) is sold to only one customer (usually a large merchant or service provider), and it is designed and developed according to customer-provided specifications. PA-DSS also does NOT apply to payment applications developed by merchants and service providers if used only in-house (not sold to a third party), since this in-house developed payment application would be covered as part of the merchant’s or service provider’s normal PCI DSS compliance.

However, using the PA-DSS as a guide to development will help to ensure that the application does not hinder the entity’s PCI DSS compliance and therefore can be utilized as a best practice for bespoke and in-house payment applications. The entity may choose to have their application assessed by a PA-QSA to satisfy their internal security requirements, however, this application, if certified to be PA-DSS compliant, would not be listed by the PCI SSC.

The requirements for Payment Application Data Security Standard (PA-DSS) are derived from the Payment Card Industry Data Security Standard (PCI DSS). This document details what is required for a merchant to be PCI DSS compliant (and therefore what a payment application must support to facilitate a merchant's PCI DSS compliance). Traditional PCI DSS compliance may not apply to payment application vendors since most vendors do not store, process, or transmit cardholder data. However, because these payment applications are used by merchants to store, process, and transmit cardholder data, and merchants are required to be PCI DSS compliant, payment applications should facilitate, and not prevent, merchants' PCI DSS compliance.

Just a few of the ways payment applications can prevent a merchant's compliance are: 1) storage of magnetic stripe data in the merchant's network after authorization; 2) applications that require merchants to disable other features required by PCI DSS, such as anti-virus software or firewalls, and; 3) vendors that use unsecured methods to connect to the application to provide support to the merchant.

The PA-DSS applies to all payment application providers. Whether it is mandatory or not will be determined by the payment brands.

You may view all currently listed PA-DSS certified payment applications at the following link:

https://www.pcisecuritystandards.org/security_standards/vpa/vpa_approval_list.html

Not necessarily. There is actually a lag between the time an application is considered compliant by the PA-QSA, when it is reviewed by Visa, and when it is posted to the PCI-SSC website. If an application isn’t listed yet and you want to verify if it is “in the queue” for listing, you may visit the following link and submit a question to the council regarding the payment application’s status:

http://selfservice.talisma.com/display/2/_index1.aspx?tab=atr&r=0.5234722

Payment Card Industry – PIN Entry Device was specifically designed to protect consumer PIN (Personal Identification Number) data from theft. It is also intended to enforce hardware security of devices that accept consumer PINs and house secret encryption keys of the acquirer, including how the PIN Entry Device (PED) is produced, controlled, transported, stored and used throughout its life cycle.

The new name reflects an expanding standards program that will continue to incorporate other parts of the PIN (Personal Identification Number) based payment chain beyond PED and other physical devices. The new name more accurately reflects the greater variety of device and non device types that play a role in PIN transaction security. For the sake of continuity this site will continue to refer to PED until the new PTS term has been properly socialized.

Both the PIN (Personal Identification Number) and PED Security Requirements have the common overall objective of protecting the cardholder’s PIN during a financial transaction. PED Security Requirements (managed by the PCI-SSC) are primarily concerned with device characteristics impacting the security of the PIN Entry Device used by the cardholder during a financial transaction. The requirements also include device management up to the point of initial key loading, but the evaluation process only addresses device characteristics.

The PIN Security Requirements (managed by MasterCard and Visa) consist of 32 security requirements divided into seven logically related groups, which are referred to as Control Objectives. The PIN requirements are about process management-primarily dealing with the secure management of cryptographic keys throughout their lifecycle (key creation, conveyance, loading, usage, and administration). This results in a complete set of requirements for the secure management, processing, and transmission of Personal Identification Number (PIN) data during online and offline payment card transaction processing at attended and unattended point-of-sale (POS) terminals and for PIN processing at ATM’s.

In cryptography Triple DES (3DES) is the common name for the Triple Data Encryption Algorithm (TDEA) block cipher, which applies the Data Encryption Standard (DES) cipher algorithm three times to each data block. Because the key size of the original DES cipher was becoming problematically short, Triple DES was designed to provide a relatively simple method of increasing the key size of DES to protect against brute force attacks without designing a completely new block cipher algorithm.

Consult with your Merchant Acquirer (credit card processor) on whether you can upgrade your terminal(s) to PCI PED compliant devices that support TDES encryption. Merchants that upgrade can do so by purchasing a PCI-PTS pin pad. If an internal pin pad is currently being used that is not compliant, a new external pin-pad may need to be purchased.

PCI-PTS-approved terminals are designed with physical security features including special tamper detection measures, which can render a terminal inoperative by erasing encryption keys. Tamper-resistant features should also make it unworkable for hackers to obtain personal cardholder information or financial data by attempting to access important electronic components of PIN pads or terminals.

You may access the standards via the PCI SSC site located at the following link:

https://www.pcisecuritystandards.org/pdfs/PCI_PED_General_FAQs.pdf

The flat fee to utilize the QSA services of Trustwave for your PCI-DSS is $50.00 and will appear on your merchant statement as an annual fee. If you already have your PCI-DSS certificate or obtain it through an alternate QSA, Sage Payment Solutions will credit the fee upon validation of the certificate.

There is no fee for validating to PA-DSS and PCI-PTS. Sage Payment Solutions includes the validation with the base cost of the PCI-DSS.

No. There is an element to SAQd that requires (like a, b and c) policies and procedures, which (depending on the infrastructure) could be complex. Services to provide customized policies and procedures are offered by Trustwave and other QSA’s, but are not a merchant requirement. Because these services are customized, other merchants already have the policies and procedures, and are entirely voluntary, they are not included in the base SAQd PCI-DSS. The base PCI-DSS cost still remains $50.

Sage Payments is a certified Level 1 Service Provider and the screens you are seeing in the Virtual Terminal are subject to PCI SLP-1 requirements. We have recently been re-certified as a Service Provider 1 which includes a thorough review of our infrastructure (including the Virtual Terminal) and are found to be fully compliant. That said, we have scheduled masking the credit card numbers as part of the next Virtual Terminal enhancement at a to be determined date. Because the pop-up windows we provide are subject to the PCI 15 minute window, and because we are SLP-1 certified, your use of the Virtual Terminal is acceptable within the PCI-DSS regulations and does not increase or otherwise impair your PCI certification from a merchant standpoint. For more information on Virtual Terminals and PCI, please reference the following: http://image.communications.trustwave.com/lib/fef91375756307/m/1/Trustwave+Virtual+Terminal+Guidance+4-29-10.pdf

The suggestion (that’s what it is) is that by segmenting access to the Virtual Terminal to one PC (away from your network), you are reducing the scope of PCI. That means that (if all you use is the Virtual Terminal to process credit card payments), having access to the Virtual Terminal on a separate PC will mean PCI only relates to that PC (for scanning and other PCI requirement purposes). Otherwise PCI will need to expand to your entire network as the entire network is potentially at risk of a breach and therefore must be assessed from a card data security standpoint. The expansion of PCI-DSS efforts towards your entire network could result in your being placed in a different Self Assessment Questionnaire type (a, b, c or d) which could carry additional costs/efforts, and ultimately it will be up to you to determine whether segmentation is in your company’s best interests.

TrustKeeper Agent is an additional tool that is part of the PCI-DSS with Trustwave. If your business is subject to an external scan, only your ports are scanned. The TrustKeeper Agent (once downloaded and initiated) scans your PC/systems (if connected) for sensitive information (like credit card numbers) and a host of other items—and does so monthly to help alert you to any changes in your infrastructure that you should be concerned with. Items from the scan also can help pre-populate your SAQ during the PCI-DSS certification process to make it easier for you to complete. For more information on the TrustKeeper Agent, please visit the following link:

https://www.trustwave.com/downloads/Trustwave-TrustKeeper-Agent.pdf

If you have also validated to PA-DSS and PCI-PTS, and have notified your Merchant Acquirer (credit card processor) of the results (if not done automatically by Trustwave), then yes you are done.

For the purposes of the PCI-DSS, a merchant is defined 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.

It is a violation of PCI DSS requirement 3.2 to store any sensitive authentication data, including card validation codes and values, after authorization even if encrypted. It is therefore prohibited to use any form of digital audio recording (using formats such as wav, mp3 etc) for storing CAV2, CVC2, CVV2 or CID codes after authorization if that data can be queried; recognizing that multiple tools exist that potentially could query a variety of digital recordings.

Where technology exists to prevent recording of these data elements, such technology should be enabled.

If these recordings cannot be data mined, storage of CAV2, CVC2, CVV2 or CID codes after authorization may be permissible as long as appropriate validation has been performed. This includes the physical and logical protections defined in PCI DSS that must still be applied to these call recording formats.

This requirement does not supersede local or regional laws that may govern the retention of audio recordings.

The intent of requirements for unique user IDs and complex passwords is to ensure each user is uniquely identified—instead of using one ID and password for several employees—so that an organization can maintain individual accountability for actions and an effective audit trail per employee. This will help speed issue resolution and containment when misuse or malicious use occurs. The answer to this question then is no, passwords sharing is not permissible.

It is required that any cardholder data that any entity stores, processes, or transmits must be protected in accordance with PCI DSS. If faxes or emails are sent or received via modem, these are not considered to be traversing a public network. On the other hand, if a fax or email is sent or received via high-speed connections over the internet, they are traversing a public network and these transmissions must be encrypted per PCI DSS requirements 4.1 and 4.2. 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 (or be protected by applicable compensating controls).

Any entity should also protect paper documents that contain cardholder data in accordance with PCI DSS requirements 9.6 through 9.10. For example, requirement 9.6 states “Physically secure all paper and electronic media (including computers, electronic media, networking and communications hardware, telecommunication lines, paper receipts, paper reports, and faxes) that contain cardholder data.”

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)." See also the note under PCI DSS requirement 3.3 - "This requirement does not apply to employees and other parties with a legitimate business need to see the full PAN. This requirement does not supersede stricter requirements in place for displays of cardholder data (for example, for point-of-sale (POS) receipts)."

Since this requirement covers all displays of PAN, including those on paper reports, computer screens, and receipts, the maximum digits allowed may be more than are specified in existing regulations (see FACTA below). Please note, however, 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). Also note that any paper receipts stored by merchants for legitimate business reasons and which contain the full PAN must adhere to the PCI DSS, especially requirement 9 regarding physical security.

PCI DSS requirement 4.2 prohibits the sending of primary account numbers (PANs) via unencrypted email, whether sent internally or over public networks. Instant messaging and chat should be considered an alternative mechanism of email and thus required to meet PCI DSS requirement 4.2 Per PCI DSS requirement 4.1, strong cryptography and security protocols should be used when cardholder data is sent over open, public networks. As a reminder, under no circumstances should sensitive authentication data such as the card validation codes and values (CAV2, CID, CVC2, CVV2) be stored after obtaining authorization.

For PCI DSS requirement 3.4 and protection of specific cardholder data elements the table on page 2 illustrates that, if the cardholder name, expiration date, or other cardholder data is recorded in conjunction with the PAN, even if the PAN is rendered unreadable, these additional cardholder data elements are still required to be “protected”. This means that all other requirements in the PCI DSS must be adhered to for protection of those cardholder data elements stored in conjunction with the PAN, such as firewall, patches, anti-virus, access controls, policies and procedures, etc., but only the PAN must be rendered unreadable. Please note that if the PAN is not stored, processed, or transmitted, even if other non-sensitive cardholder data is stored, PCI DSS does not apply.

A truncated PAN, consisting of the maximum of the first 6 and the last 4 digits, is not considered cardholder data per PCI DSS. If the merchant only stores truncated PAN, and does not store, process, or transmit the full PAN, then PCI DSS would not apply to this merchant (except for requirement 12.8, which is between the merchant and their service providers). Keep in mind that if a merchant stores any paper receipts, reports, etc., with full PAN, this is also considered storage of PAN per PCI DSS. PCI DSS does not apply to a merchant that does not electronically store, process, or transmit full PAN data OR store such data on paper receipts, reports, etc. However, PCI DSS (and SAQ A) does apply to a merchant who stores full PAN on paper, even though they’ve outsourced all electronic storage, processing, and transmission of cardholder data to a third party and only electronically store truncated PANs.

Any payment card (credit, debit, prepaid, stored value, gift or chip) bearing the logo of one of the PCI Security Standards Council’s five founding payment brands is required to be protected as prescribed by the PCI DSS.

PCI DSS requirements are applicable if a Primary Account Number (PAN) is stored, processed, or transmitted. If PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply. However, under PCI DSS requirement 12.8, if the merchant shares cardholder data with a third party processor or service provider, the merchant must ensure that there is an agreement with that third party processor/service provider that includes their acknowledgement that the third party processor/service provider is responsible for the security of the cardholder data it possesses. In lieu of a direct agreement, the merchant must obtain evidence of the third-party processor/service provider's compliance with PCI DSS via other means, such as via a letter of attestation.

All system components in the network are considered part of the cardholder data environment unless adequate network segmentation is in place that isolates 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 Data Security Standard, and all PCI Data Security Standard requirements apply. QSAs can advise their clients on how to implement network segmentation to reduce PCI DSS scope. 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 for all PCs that need access, and should prohibit access for all other PCs. With such segmentation in place, PCI DSS requirements are relevant to, and should be applied to, only that smaller PC population. Regarding the applicability of each PCI DSS requirement to an individual PC, the QSA should also consider features that are part of the PC’s basic functionality (for example, logging or file integrity monitoring) or are part of existing network controls, and determine whether these features meet the intent of PCI DSS requirements to protect cardholder data stored, processed, or transmitted by these PCs.

PCI DSS requirement 12.7 states, “Screen potential employees to minimize the risk of attacks from internal sources.” It further states, “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.

The PCI DSS is a global standard and is applicable to all entities that process, transmit or store cardholder data regardless of geographic location. Each payment brand manages their PCI DSS compliance and enforcement programs independently of the PCI Security Standards Council. With regard to levels, time lines, and other specific questions about compliance and enforcement, please contact each payment brand to understand programs in the regions in which the company operates. 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.

If the cardholder data is stored in non-persistent memory (e.g. RAM), encryption of cardholder data is not required. However, proper controls must be in place to ensure that memory maintains a non-persistent state. For example, if the memory is being written to a file, then appropriate PCI DSS requirements are applicable to that file. Where appropriate, this data should be securely purged as soon as possible - for example, from swap files and temporary folders. PCI SSC recommends engaging a Qualified Security Assessor (QSA) for guidance as to whether a specific implementation will satisfy this requirement. Please see the list of QSAs at www.pcisecuritystandards.org/pdfs/pci_qsa_list.pdf

The PCI DSS requirement 4.1 states “use strong cryptography and security protocols such as SSL / TLS/ IPSEC to safeguard sensitive cardholder data during transmission over open, public networks.” While the PCI DSS does not specifically mention Bluetooth technology as an open, public network, it is a technology that can present security risk if not implemented properly. Appropriate measures in the implementation of the Bluetooth technology must be taken such as having the security features enabled and using long PIN codes or pairing the devices only in private. PCI SSC recommends that you consult a Qualified Security Assessor for proper implementation of the Bluetooth technology. Our list of Qualified Security Assessors can be found at: https://www.pcisecuritystandards.org/resources/qualified_security_assessors.htm Please note: If a vendor is providing an application that is facilitating the transmission of the cardholder transaction using Bluetooth technology, that vendor is responsible for meeting the PCI DSS requirements, not the consumer.

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. In the case of a script running, such a script could be executed by an administrator/user and not require activity or the necessity of a login while in process. Additionally, idle time by an administrator should not halt the execution of a script or program. As a reminder, this requirement can be met by an automatic PC screensaver with a password.

Systems that use operating systems that are no longer supported with new security patches by the vendor, OEM, or developer are not necessarily out of compliance. Compensating controls could address risks posed by using older operating systems. Exploit of legacy code is the main risk posed by an older operating system.e. Since well-known exploits are typically included as signatures to anti-virus, IDS/IPS and firewall filtering, a compensating control to consider is performing an exhaustive search to ensure that all known exploits for that operating system are identified, and that anti-virus, IDS/IPS and firewall rules are all updated to address those exploits.

Other compensating controls could include monitoring IDS/IPS and firewall logs more frequently than required (for example, the requirement is for daily log reviews, so more frequently may be continuously and automated), or isolating and segmenting their POS systems via firewalls from the Internet and other systems in the cardholder data environment. The eventual solution is to upgrade to a new and supported operating system, and the entity should have an active plan for doing so. For more help with compensating controls, and for questions about whether a specific implementation is consistent with the standard or is 'compliant', please contact a Qualified Security Assessor.

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, or obtaining other relevant information, including potential consequences should a compromise have occurred.

You may visit the following website for the latest list:

http://usa.visa.com/download/merchants/cisp-list-of-pcidss-compliant-service-providers.pdf

An ADCR is an Account Data Compromise Recovery fine. The ADCR process is followed in the event of a magnetic stripe data compromise and fraud violations. If fined by the ADCR committee, the penalty could result in a merchant paying 2-5% of their annual Visa sales volume.

Please visit the following link: http://usa.visa.com/download/merchants/cisp-list-of-pcidss-compliant-service-providers.pdf

Up to 3 computers are included in the base cost of the PCI-DSS, beyond that please submit a request to pcicompliance@sagepayments.com along with the particulars and allow up to 24 hours for a response.

If you want to contact the council directly plase contact 781-876-8855.

An ISA is a new program available from the PCI Security Standards Council and stands for Internal Security Assessor. The ISA Program provides an opportunity for eligible internal security audit professionals of qualifying organizations to receive PCI DSS training and certification to improve the organization’s understanding of the PCI DSS, facilitate the organization’s interactions with QSA’s, enhance the quality, reliability, and consistency of the organizations internal PCI DSS self assessments, and support the consistent and proper application of PCI DSS measures and controls. Information on becoming an ISA can be found on the PCI SSC website at the following URL:
https://www.pcisecuritystandards.org/qsa_asv/become_isa.shtml

All merchants (Level 1, 2, 3 and 4) must certify annually to the PCI DSS.

The different Card Brands classify the level of merchants by sales transaction count. Generally, if you are classified by one Card Brand as a higher level, you must certify to that level for all Card Brands. Your Acquirer (credit card processor) should be able to help you accurately determine your merchant level.

Level 1: Visa, MasterCard and Discover classify merchants as level one if their transactions exceed 6 million (per Brand – not cumulative). American Express classifies merchants as level one if their transactions exceed 2.5 million.

Level 2: Visa, MasterCard and Discover classify merchants as level two if their transactions fall between 1 and 6 million (per Brand – not cumulative). American Express classifies merchants as level two if their transactions fall between 50,000 and 2.5 million.

Level 3: Visa, MasterCard and Discover classify merchants as level three if their transactions fall between 20,000 and 1 million (per Brand – not cumulative). American Express classifies merchants as level three if their transactions are less than 50,000.

Level 4: Visa, MasterCard and Discover classify merchants as level four if their transactions are less than 20,000. American Express does not have a merchant level below level three.

Contact Trustwave at 800-239-2468, 24/7/365.

Contact the customer support number for the software product.

Contact Sage Payment Solutions at 1-800-261-0240 x3056 between the hours of 9:30 – 5:30 EST.

You may also email us with your question at pcicompliance@sagepayments.com.

Contact Sage Payment Solutions Merchant Financial Services at 1-877-841-7014 between the hours of 8a.m. to 8 p.m. EST.

Yes. Trustwave has a service (as do most QSA’s) that will provide a dedicated person to walk you through the PCI-DSS. The service is called Compliance Validation Service (CVS) . To set a scoping call with a Compliance Expert at Trustwave, please send your request including the type of system you are running and a date and time when you are available for an appointment.

Prior to doing so however, you may wish to view an end-to-end recording of a merchant experience. It is located at the following link:

https://trustwave.webex.com/trustwave/lsr.php?AT=pb&SP=EC&rID=52248252&rKey=f9e078c1f4b85a76.

Merchants or service providers are encouraged to submit feedback about their QSA/ASV through the feedback form available on our website at https://www.pcisecuritystandards.org/tech/supporting_documents.htm QSAs and ASVs are contractually obligated to provide feedback forms to all of their clients upon completion of services. These completed forms should be submitted directly to the Council at qsa@pcisecuritystandards.org or asv@pcisecuritystandards.org. The PCI Security Standards Council will consider all feedback regarding QSAs/ASVs and will address issues as needed on an individual basis.