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

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 please 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.