Also See: PCI Data Security Compliance Program

PCI Data Security Overview

What are the various PCI Security Standards?

There are three PCI security standards that agencies functioning as merchants must adhere to: 1) PCI Data Security Standard (PCI DSS), which applies to the agency’s entire merchant card process; 2) Payment Application Data Security Standard (PA-DSS), which applies to the capture software that the agency may be using; and 3) PCI Pin Transaction Security (PCI PTS), which applies to terminals and devices that provide for the keying of PIN Debit cards (also referred to as PCI PIN Entry Device – PCI PED).

What is the PCI Data Security Standard (PCI DSS)?

The PCI DSS is a multifaceted security standard that includes requirements for security management, policies, procedures, network architecture, software design and other critical protective measures associated with credit card account data. This comprehensive standard is intended to help organizations proactively protect customer credit card account data that is either stored, processed, or transmitted. All merchants, regardless of the annual transaction volume (merchant level assigned), are required by the various card brands (i.e., Visa, MasterCard, American Express, Discover, and JCB) to follow the standard. Merchants not adhering to the standard are subject to substantial fines levied by the card associations.

What is the Payment Application Data Security Standard (PA-DSS)?

PA-DSS is a standard (separate from the PCI DSS) which stands for Payment Application Data Security Standard. Released in April 2008, it is in the process of replacing Visa's Payment Application Best Practices (PABP), on a phase-in basis. The goal of PA-DSS is to help software vendors and others develop secure payment applications that do not store prohibited data, such as full magnetic stripe, other sensitive authentication data or PIN data, and ensure their payment applications support compliance with the PCI DSS. PA-DSS requirements apply to payment applications that are sold, distributed or licensed to third parties (merchants). It does not apply to an application that was developed by a vendor for just one particular customer of the vendor. However, such customized applications are subject to the PCI DSS review.

Effective October 1, 2008, acquirers (e.g., STMS) cannot accept the enrollment of any new application that is not compliant with the PA-DSS. If the application is currently being processed on one of STMS's platforms, it may continue to be utilized until the PA-DSS fully becomes effective. All vulnerable applications will be decertified October 1, 2009, and no non-compliant application can continue to be utilized after July 1, 2010.

There are currently two lists of validated payment applications, one published by Visa (PABP List), and one published by the PCI Security Council (PA-DSS List). Participants should check with their vendor to ascertain if the application they are currently using is, or will be, included on the Council’s List of Validated Applications. It has been reported that some payment applications have already been identified by vendors that will not likely be validated under the new PA-DSS. If assurance cannot be obtained from the vendor that the payment application will be PA-DSS compliant, the participant should begin the process of acquiring an alternate application that is PA-DSS compliant.

What is the PCI Pin Transaction Standard (PCI PTS)?

PCI PTS is a standard (separate from the PCI DSS) which stands for Payment Card Industry PIN Transaction Security. The standard is sometimes referred to as the PCI Pin Entry Device Standard (PCI PED). It incorporates several documents issued by the PCI Security Council, including “Encrypting PIN Pad Devices.” While the standard has been in place for a number of years, previously it only applied to manufacturers of PIN Entry devices, and the card brands had a grandfather provision for existing POS terminals. However, effective July 1, 2010, the standard will have an effect on merchants, as merchants utilizing devices not compliant with the standard will be subject to fines. The standard requires all POS terminals processing PIN debit cards to have Triple DED (TDES) encryption pin pads. A list of Approved PIN Transaction Devices can be viewed on the PCI Security Council’s website.

What are CISP and SDP?

Compliance with the PCI DSS is in addition to the requirements specified by each card association's "validation" program (i.e., Visa's CISP and MasterCard's SDP). CISP stands for "Cardholder Information Security Program," and SDP stands for "Site Data Protection." Therefore, PCI DSS refers to "compliance," while CISP and SDP refer to "validation" of that compliance. The validation of compliance requirements are those of CISP and SDP, which are incorporated into the card associations' rules. Merchants are required contractually to adhere to all card association rules.

What are Merchant Levels?

In accordance with Visa's CISP and MasterCard's SDP, each merchant is assigned a "merchant level," to help an acquirer determine what procedures are to be taken by the merchant to demonstrate "validation" of the merchant's compliance with the PCI DSS. The level assigned to a merchant is based primarily upon the merchant's annual transaction volume, taking into account e-commerce transactions only, and all transactions regardless of acceptance channel.

What is a merchant level 1?

Level 1 is the most stringent level and is assigned to a merchant with all Visa transactions exceeding 6 million annually, or with all MasterCard transactions exceeding 6 million annually, or any merchant that has experienced a security breach that resulted in an account compromise. A level 1 merchant is required to have an annual on-site PCI security audit performed annually, while the other three levels do not require such on-site annual audit. Currently, there are not any government agencies in North Carolina having volume high enough to be considered a level 1 merchant.

What is a level 2 merchant?

A level 2 merchant is one, regardless of acceptance channel, processing 1,000,000 to 6,000,000 Visa or MasterCard transactions per year. If multiple card processors are used by a merchant to accommodate multiple acceptance channels, then an aggregate of the total between all processors determines the level. Level 2 merchants are required to complete an annual self-assessment questionnaire (SAQ), and to perform a vulnerability network scan at least quarterly (for external-facing IP addresses). Effective June 30, 2011, MasterCard will require the annual SAQ to be completed by either: internal audit staff trained via PCI DSS Internal Security Assessor (ISA) Program; or alternatively, to have an onsite security assessment conducted by an Qualified Security Assessor (QSA). (MasterCard’s on-site assessment requirement was announced in June 2009 and revised in December 2009.) Each level 2 merchant must provide an annual attestation of its compliance to both Visa and MasterCard, when directed by STMS. The NC DMV is the currently the only government agency in North Carolina considered a level 2 merchant, by virtue of it exceeding one million Visa transactions annually. However, several universities are approaching the level 2 threshold.

What is a level 3 merchant?

A level 3 merchant is one processing 20,000 to 1,000,000 Visa or MasterCard e-commerce transactions per year. Level 3 merchants are required to complete an annual self-assessment questionnaire, and to perform a vulnerability network scan at least quarterly (for external-facing IP addresses). No date has yet been established for a level 3 merchant to provide an attestation to Visa of its compliance.

What is a level 4 merchant?

A level 4 merchant is a merchant that has either - fewer than 20,000 Visa or MasterCard e-commerce transactions annually; or one, regardless of acceptance channel, fewer than one million Visa or Mastercard transactions. Completion of the annual Self-Assessment questionnaire and conducting of a quarterly vulnerability network scan (same as required of a level 2 and 3 merchant) are recommended by Visa and MasterCard, but may be required by the merchant's acquirer (STMS or other processor). In the case of participants in the State Controller's Master Services Agreement with STMS, both STMS and the State Controller have mandated that level 4 merchants complete the annual self-assessment questionnaire, and, if external facing IP addresses are involved, to conduct the required vulnerability network scans. No date has yet been established for a level 4 merchant to provide an attestation to Visa of its compliance.

What are the six security elements that PCI DSS focuses on?

Build and maintain a secure network
Protect cardholder data
Maintain a vulnerability management program
Implement strong access control measures
Regularly monitor and test networks
Maintain an information security policy

What version of the PCI DSS applies?

PCI DSS Version 2.0 replaced Version 2.2 effective January 1, 2011. The new version does not have material changes, but does provide many clarifications. The PCI Security Council’s website should be referred to for a summary of the changes.

Where can the standard be found?

The standard is posted on the Website hosted by the PCI Security Council. There are links from the card associations' Websites, as well as from the State Controller's SECP Website.

Where can information on Visa's CISP and MasterCard's SDP be found?

Complete descriptions of the programs are found on each respective card association website. There are links from the State Controller's SECP website.

What is the State Controller's position on the PCI DSS?

The State Controller issued a memorandum dated July 14, 2005 providing agencies guidance regarding their obligations to be in compliance with the standard. Additionally, the E-Commerce Policy entitled "Security and Privacy Data" was amended effective October 1, 2005, which includes reference to the standard, stating in part that all agencies must:

Adhere to all applicable merchant card associations' operating rules (e.g., Visa, MasterCard)
Participate in any security assessments and security scans required by the associations and/or OSC, in order to be and to remain compliant with Payment Card Industry (PCI) Security Standards, and be responsible for any fines levied as the result of not being compliant.

Has the State Controller issued a policy regarding PCI Compliance?

Yes. A policy was issued October 1, 2008. The policy requires all participants in the MSA with STMS to be enrolled in TrustKeeper for the purpose of being validated. The policy also specifies the monitoring process and the involvement of central oversight agencies.

Must participants in OSC's Master Services Agreement be compliant with the PCI DSS?

Yes. As a prerequisite for participating under the MSA, an entity is required to comply with all card association rules. This includes the rules pertaining to the PCI Data Security Standard. Compliance has actually been required by the card associations since July 01, 2005. All merchants not compliant since that date have been at risk, and continue to be at risk of being fined for non-compliance. Neither OSC nor STMS has the authority to grant an exemption from being compliant with the PCI DSS, nor from adhering to the validation requirements of CISP and SDP.

Does a merchant have to experience a security breach before being subject to a fine?

No. A merchant can be fined by a card association even if a security breach has not occurred. It is uncertain as to how aggressive the card associations will be in levying fines for such non-compliant merchants that might be detected. Visa has announced its fine structure. Effective September 30, 2007, Visa will levy a monthly fine of $25,000 to any level 1 merchant detected as non-compliant. Effective December 31, 2007, Visa will levy a monthly fine of $5,000 to any level 2 merchant detected as non-compliant. No fine structure has yet been announced for level 3 and 4 merchants.

How does a participant enrolled (or enrolling) in the MSA validate its compliance with the standards?

Effective July 1, 2008, each participant in the MSA must also enroll in the "Compliance Validation Services" available from Trustwave, a Qualified Security Assessor (QSA). Enrollment in the online TrustKeeper portal provided by Trustwave allows for two component services to be obtained:

Vulnerability Scanning Service - Capture applications involving external-facing IP addresses (URLs and POS software applications connected to the Internet) must be validated as compliant by passing a quarterly vulnerability scan. Upon enrolling in TrustKeeper, each IP address required to be scanned is registered. This service component does not apply to capture applications that do not involve web-facing IP addresses, such as stand-alone POS terminals using analog telephone lines. (While the Standard requires scanning to be performed quarterly, Trustwave performs the scans on a monthly basis, providing the participant the ability to correct any problems timely.)
Self-Assessment Questionnaire and Attestation Service - All capture applications (whether vulnerability scanning is required or not) must be validated annually as being compliant by completing a Self-Assessment Questionnaire (SAQ). Upon enrolling in TrustKeeper, each participant is able to: 1) select the appropriate SAQ to be completed (A,B,C, or D); and 2) complete the SAQ online. This service component of TrustKeeper also serves as the participant's "attestation" of validation of compliance with the PCI DSS.

What is the role of the Office of the State controller (OSC) in PCI DSS Compliance?

OSC has elected to obtain a statewide "Compliance Validation Service" for the participants in the MSA to subscribe to, using the TrustKeeper Portal Tool. OSC has the capability to view the validation of compliance status of all chain numbers enrolled in TrustKeeper. Accordingly, OSC has the capability to generate management reports regarding the validation status of the various chain numbers: 1) Compliant; 2) Non-Compliant; or 3) Incomplete. The role of OSC will not be to ensure that validation of compliance has been performed, but to facilitate the reporting (attestation) of the validation of compliance status to STMS. Periodic reports will be provided to STMS. Such reports may be on a scheduled basis (likely monthly), or on an "as requested" basis as may be requested by one of the card associations. OSC may share the status reports with the appropriate central oversight agencies (i.e., UNC General Administration, NC Community College System, Local Government Commission).

What is the difference between compliance, validation and attestation?

Merchants (agencies) are compliant when they are abiding by the PCI Data Security Standard (PCI DSS), which is required of all merchants, regardless of the capture method used. Compliance relates to both infrastructure security and to business procedures. Validation is the process performed by a Qualified Security Assessor (QSA) confirming that a merchant is compliant. Validation has two components: 1) Vulnerability Scanning for capture methods involving external facing IP addresses - on a quarterly basis; and 2) Self-Assessment Questionnaire for all capture methods - on an annual basis. Attestation of validation is to be made by the merchant to the acquirer (STMS) as may be requested from time to time. For participants in the State's Master Services Agreement (MSA), both the validation process and the attestation process is performed through TrustKeeper. In addition to the online attestation done through TrustKeeper, STMS may require a written attestation by the merchant if deemed necessary to fulfill any requirements of the card associations. (The card associations have different requirements for each of the four levels of merchants - Levels 1, 2, 3, and 4).

What is a Safe Harbor?

Safe harbor is an element of Visa's CISP that provides member banks a potential protection from Visa fines and compliance exposure in the event their merchant experiences a data compromise. MasterCard's SDP has a similar program called SDP Program Registration. Since a merchant must maintain full compliance at all times, including at the time of breach as demonstrated during a forensic investigation, the safe harbor provision offers little protection.

If an agency only utilizes POS Terminals, is it subject to the standard?

Yes, the standard applies to all "payment channels" (i.e., POS terminals, Mail Order/Telephone Order, Web applications, etc). Therefore, an agency is subject to the standard even if it does not have any Web applications. Vulnerability scanning is not applicable to a POS terminal utilizing an analog telephone line, but is for a POS terminal connected via the Internet. In either case, the agency must enroll in TrustKeeper in order to complete the online Self-Assessment Questionnaire (SAQ) annually. The agency should be aware of the anniversary date that the SAQ is to be completed, to ensure it is done timely.

When does the vulnerability scanning requirement apply?

Any application that stores, transmits, or processes cardholder data and involves an external facing (web-facing) IP address must be scanned. This is normally associated with a web application and with any POS software maintained on a public network that is connected to the Internet. A web application that only has a link to a third-party service provider does not have to be scanned. For those participants enrolled in Trustwave's TrustKeeper portal, the vulnerability scanning is not performed quarterly, but monthly. For a participant's array of IP address enrolled in TrustKeeper, participants are entitled to 12 scans per year (one monthly), as well as 10 self-directed scans during the year if needed. A self-directed scan may be needed after fixing a problem detected during a scheduled monthly scan, or if a scan is needed for an application not yet put into production. Vulnerability scanning is pursuant to requirement 11.2 of the Standard, and is different than the "penetration testing" that is required by 11.3 of the Standard.

When does the Penetration Test requirement apply?

Pursuant to Requirement 11.3 of the PCI DSS, penetration testing (both external and internal) is required of certain merchants. Merchants that utilize a card capture solution that involves both of the following are subject to the requirement: 1) utilizes external-facing IP addresses; and 2) stores cardholder data electronically. Penetration testing is different than “vulnerability scanning” required under Requirement 11.2. If a merchant qualifies to complete SAQ-C instead of SAQ-D (by virtue of not storing cardholder data electronically), penetration testing is not required. The PCI Council’s Supplement addressing Requirement 11.3 should be referenced.

Which questionnaire should an agency complete?

Effective May 1, 2008, there are four different questionnaires an agency must choose from (A,B, C, or D). The one to be completed depends upon two factors: 1) the agency's capture method(s); and 2) if cardholder data is being stored or not. A chart is available to assist in making the determination as to which questionnaire to use. If an agency has multiple capture methods, and more than one questionnaire applies, the questionnaire that is the most stringent should be completed.

Is the online reporting system to be considered when answering the Self-Assessment Questionnaire?

Yes. All participants are provided an online reporting system (e.g., MyMerchantView, ClientLine, Amex Online Merchant Services, etc.) by the merchant card processor, which normally displays bulk cardholder data. These systems are not under the scope of PCI DSS if they are only used to view cardholder data (even if the full account number is displayed), as the cardholder data is not considered being "stored" by the merchant. If these systems are used to download cardholder data, two situations could apply: 1) If the downloaded primary account number (PAN) is masked, the systems are not in scope; 2) If the downloaded PAN is not masked, the systems are within scope. Consequently, regardless of the capture method, if "unmasked primary accounts numbers" are being "stored," questionnaire D must be completed. Internal procedures could be developed to prohibit employees from downloading unmasked PANs is so desired (in order to avoid being in scope due to "storing").

What does "screening employees" mean?

The standard requires potential employees having access to bulk account data to be screened. The standard does not define screening. The old questionnaire, which was stricter than the actual standard, referred to "background checks." The new questionnaire does not use the term background checks. Merchants are to perform a risk analysis and make its own determination regarding what constitutes "screening." Factors such as the volume of account data must be taken into consideration. For example, employees having access to small volumes of account data may be subject to a less stringent screening process than an employee having access to large volumes of account data (e.g. electronic databases). The level of screening is normally a judgment made by the participant's Human Resources Department.

Are shadow databases covered by the PCI DSS?

Yes. Shadow databases are those databases frequently kept by employees, such as Excel worksheets, that are not always known about by an agency's IT staff.

Does the PCI DSS requirement pertaining to employee screening apply to all employees?

The requirement only applies to employees that have access to bulk account data that is "stored." Employees that perform reconciliation functions using the processor's online reporting system normally have access to bulk account data. Consideration must be given regarding their viewing and downloading capabilities. If the employee can "download" unmasked primary account numbers (PANs), the screening requirement applies, since the PAN is stored. Employees that only process POS terminal transactions generally do not have access to bulk account data, and the screening requirement would not apply.

What credit card data must never be stored?

It is never acceptable to retain or store magnetic stripe data subsequent to transaction authorization. It is never acceptable to retain or store the security code numbers (CVV2 or CVC2) subsequent to transaction authorization. Substantial fines can be levied by the card associations for such violation. Cardholder name, account number, and expiration date may be retained subsequent to transaction authorization; however, the data must be encrypted in accordance with the PCI DSS. The "customer name" field is to be considered separate from the "cardholder name," although they may sometimes be identical. The customer name in itself is not subject to PCI DSS.

As a service provider, is the CPS considered to be PCI DSS compliant?

Yes, CPS is enrolled with TrustWave, which has validated CPS as being compliant.

Do participants utilizing a Virtual Terminal application provided by a gateway service have to undergo external vulnerability scanning by Trustwave?

The PCI Security Council has not given definitive guidance on the issue of “virtualization.” While there are some vendors claiming that virtual terminal applications do not require the merchant to undergo external vulnerability scanning, most Qualified Security Assessors (including Trustwave) now advise that they do.

In 2009, Trustwave revised its previous position regarding virtualization applications and gave the following guidance: Virtual terminals—web applications that a merchant enters credit card data into—still leave the merchant with PCI compliance burdens. A merchant in this case is involved with the transmission of cardholder data since they take the card number and enter it into the web application. Although storage is not involved, if cardholder data is being transmitted over public (external facing) IP addresses in an agency’s control then those IP addresses are in scope for PCI vulnerability scanning. To validate compliance, virtual terminal applications require at least SAQ C (if the PC terminal is a stand-alone terminal not connected to any other system), and often SAQ D (if the PC terminal is connected to other systems).

Therefore, agencies utilizing the Virtual Credit Card Terminal (VCCT) offered by the Common Payment Service (CPS) should enroll in the vulnerability scanning service provided by Trustwave. Agencies utilizing the virtual terminal feature offered by a third-party vendor, including PayPoint, where the merchant enters the cardholder data through the agency’s IP address, should also undergo vulnerability scanning. The utilization of PayPoint where the virtual terminal feature is not used (web entry by cardholders using their own PCs) does not require vulnerability scanning. All vendors offering virtual terminal applications must be certified as PCI compliant as a “service provider.”

If an agency accepts merchants cards, but is not a participant in OSC's MSA, is it still required to be compliant with the PCI DSS and required to be validated in accordance with CISP and SDP?

Yes. The association rules apply to all merchants, which incorporate both the PCI DSS and the validation requirements. Validation compliance and attestation of validation should be made in accordance with the requirements of the acquirer (vendor) that the agency has contracted with to processes its merchant card payments.

Can an agency that is not a participant in OSC's MSA obtain the services of TrustWave, under OSC's contract with the vendor?

Yes. State agencies that have obtained an exemption from using OSC's MSA with STMS and are using a different card processor may subscribe to the services of Trustwave on an optional basis. Subscribing to the service is very beneficial if the agency utilizes a card capture solution involving external facing IP addresses that require vulnerability scanning. Otherwise, the agency must secure vulnerability scanning services on its own. If vulnerability scanning services are not needed, the agency may still elect to enroll in TrustKeeper in order to facilitate the completion of the annual Self-Assessment Questionnaire (which is to be provided by the agency to its contracted acquirer, not to STMS). Non-State agencies that do not participate in OSC's MSA cannot obtain the services of TrustWave.

Can community colleges obtain PCI Compliance Validation Services from TrustWave?

Community colleges that are participants in the State Controller's (OSC) MSA with SunTrust Merchant Services (STMS) are required to enroll in TrustKeeper through OSC, with OSC being the parent sponsor and administrator. Community colleges that utilize a card processor other than STMS must enroll in Trust Keeper through the NC Community College System (NCCCS) with NCCCS being the parent sponsor and administrator. Refer to the Division of Business and Finance at NCCCS for enrollment instructions.

Is there a cost for enrolling in TrustWave's TrustKeeper portal?

No, not for entities that are participants in OSC's MSA, as OSC secures funding for the services provided by TrustWave on a statewide enterprise approach. For State agencies that are not participants in OSC's MSA, services obtained from TrustWave under OSC's contract with TrustWave may be required to incur some of the costs of services obtained (services beyond the basic scanning).

In the event a participant incurs a security breach and a forensic investigation is required by the card associations, the participant will be responsible for the cost of the forensic investigation. Additionally, if the participant is elevated to a "merchant level one" as the result of a security breach, the participant will be responsible for the cost of an annual security audit that would then be required. These costs would be in addition any fines that the card associations might levy.

How does the requirement of demonstrating PCI compliance apply to an entity applying for the first time to participate in the State's MSA?

For new participants, enrollment in TrustKeeper is required at the "chain" level. If vulnerability scanning of any IP addresses is required, the IP addresses should be listed during the online enrollment process. Scheduling of vulnerability scans should be made, with successful scans being performed before the application is placed into production. For any additional IP addresses that may be added in the future, the IP addresses should be registered in TrustKeeper (added to the existing chain number), with a successful scan being made before being placed into production. In all cases (scanning required or not), the Self-Assessment Questionnaire (SAQ) should be completed online before the application is placed into production.

Do third-party service providers used by a participant have to be PCI compliant?

Yes. A service provider could be either a gateway service, a web hosting company, or a backup storage service. PCI DSS requirement 12.8 applies, which requires the merchant to “manage” the service provider by: 1) maintaining a “written agreement” specifying the service provider’s responsibility for compliance; 2) performing due diligence to ensure PCI compliance prior to engagement; and 3) monitoring the service provider’s compliance status. Additionally, OSC's Data Privacy Security Policy specifies that only PCI compliant service providers can be utilized. A list of compliant service providers can be viewed on Visa and MasterCard websites, along with the date of their validation. A service provider may be compliant but may not have registered to be included on Visa’s list. Non-registered service providers should provide you with evidence of the obtaining of a “Report on Compliance” (ROC) if they are a Level 1 service provider, or provide you evidence of their validation by a qualified scanning vendor (QSV) if they are a Level 2 service provider. The Common Payment Service (CPS) is a Level 1 service provider and has been validated by TrustWave as being compliant, with evidence of a ROC being provided on OSC’s website. You cannot truthfully answer the Self-Assessment Questionnaire with a “yes” answer if you have not adhered to these requirements.

Is there a sample "written agreement" available for agencies to execute with a service provider to fulfill Requirement 12.8?

Yes, there is a “Sample Addendum for Requirement 12.8” available on OSC’s website. An addendum should be executed if the existing contact with the service provider is not sufficient to specify the responsibilities of the provider regarding PCI Data Security. If you are negotiating a new contract, Requirement 12.8 must be addressed in the new contract. If applicable, approvable of the Division of Purchase and Contract or the ITS Procurement Office must be obtained.

If the agency's application only involves a link on its website to a service provider, is the agency's site subject to the quarterly vulnerability scan requirement?

The State's contracted Qualified Security Assessor (Trustwave) has reversed its previous position regarding this matter. The procedures required by Qualified Scanning Vendors to follow allow for certain "segmentation methods" to be used to "reduce the scope of the PCI Security Scan" (i.e., providing physical segmentation between the segment handling cardholder data and other segments; and employing appropriate logical segmentation where traffic is prohibited between the segment or network handling cardholder data and other networks or segments). The focus of the standard is to encourage separation of system components that "store, transmit, or process" cardholder data from those that do not, and to focus compliance efforts on those system components that do. A website that only has a link to a third-party service provider constitutes an appropriate separation from the cardholder environment referred to in the standard, as the two system components are not considered "connected." Therefore, from the perspective of the PCI DSS requirements, such website does not have to be scanned to obtain compliance. However, agencies may elect to have such websites scanned anyway, as a precaution against the potential of a "pharming" incident.

Is compliance with the PCI DSS a requirement of both American Express and Discover?

Yes. Additionally, each company has its own security policy that must be adhered to.

What types of fines are possible for non-compliance with the DSS?

Any fines levied would be the result of the respective card association rules, not those of the PCI Security Council. Each card association would determine the fines that would be levied, based upon the non-compliance condition, or upon the circumstances and extent of a security incident. A security incident could be either an actual security breach or a suspected security breach. Fines could include, but not be limited to, up to $500,000 per occurrence, per card association. Other fines could be levied to reimburse the issuer of the card numbers that were compromised to cover the costs involved in replacing the cards.

Are there costs other than fines associated with a security incident?

Yes. In most cases, the card associations will require a forensic investigation to be conducted once an incident is reported. This forensic investigation must be performed by a Qualified Security Assessor (QSA), and be paid for by the merchant. There could also be costs associated with the notification of cardholders whose accounts were compromised. Another consequence of a security incident is that the merchant would then be elevated to the status of a Level 1 merchant. This would require the merchant to have to pay for an annual on-site review.

How would a fine be levied?

The card association rules, including the CISP and the SDP, specify that the acquirer (merchant bank) is responsible for ensuring that each merchant is compliant with the PCI DSS. The merchant agreement between the acquirer and the merchant (either directly or indirectly through a master services agreement), requires the merchant to be compliant with the PCI DSS. Should a fine be levied, the card association would fine the acquirer (merchant bank), which would then invoice the merchant, in accordance with the merchant card agreement.

Why are government entities not exempt from the PCI DSS and the fines that the card associations may levy?

Any fines levied by the card associations are the result of non-compliance with the associations' "operating rules," not pursuant to any statutory authority or prohibition. Governments voluntarily elect to subscribe to the services provided by the card associations, and the services are provided indirectly under agreements with member merchant banks. Governments not willing to accept the terms of the agreements, which require compliance with all association operating rules, are denied service. All agreements entered into by the governments are done so on a voluntary basis.

Does the merchant agreement specify that fees can be levied against a merchant?

Most standard merchant agreements do not specifically state that fees can be levied. Instead the agreements state that the merchant shall adhere to all of the terms of the merchant bank's "operating guide." All such "operating guides" indicate that the merchant agrees to adhere to all card association rules. The card association rules is the authority that allows for fines to be levied, and to require each merchant to abide by the rules. The merchant banks pass this liability on to the merchants by way of terms contained in their standard merchant agreement.

Who would be responsible for paying any fines or costs?

The merchant (agency) is responsible for all fines and costs. In the case of participants of the State Controller's Master Services Agreement with STMS, paragraph 9 of the Agency Participant Agreement (Schedule E) specifically indicates that the Participant accepts all obligations and responsibilities required by the terms of the master agreement.

Are there any terms in the OSC Master Services Agreement with STMS that relate to fines?

Yes. The pertinent terms include paragraphs 7, 16.10, 19, 21.8, and 21.9. These terms address cure periods and dispute resolution.

Is there a policy regarding a security incident plan?

Yes, the PCI DSS requires the development of such a plan by each merchant. In addition, the Office of the State Controller has issued a policy that addresses the development of such plan. In the case of participants under the purview of the State Chief Information Officer, the OSC policy requires adherence with the Security Incident Reporting Policy issued by the Office of Information Technology. The plan should require the reporting of a known or suspected security incident with 24 hours to the OSC. The OSC is to be involved in all assessments of security incidents and coordinate any notification to the card associations that may be appropriate.

Why should a merchant desire to ensure it is PCI DSS compliant?

To be in adherence with policies of the OSC
To avoid substantial fines
To avoid costs associated with a security breach
To avoid being designated a level one merchant, which would require the cost of an annual on-site audit, in order to continue to be able to process merchant cards
To avoid the merchant card application from being shut down
To avoid adverse publicity
To avoid a possible class action lawsuit
To be a good steward in preventing citizens' identity theft