Also See: PCI Data Security Compliance Program

PCI Data Security Overview

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 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. Level 2 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). Level 2 merchants were required to provide an attestation to Visa of its compliance by September 30, 2007. The NC DMV is the only government agency in North Carolina considered a level 2 merchant, by virtue of it exceeding one million transactions annually.

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 1 was replaced with Version 1.1 effective September 7, 2006. There was a phase out period for Version 1, which became obsolete effective January 1, 2007. However, the Self-Assessment Questionnaire (SAQ) that correlates to Version 1.1 was not published until February 6, 2008. Version 1.2 of the PCI DSS is anticipated to be released in October 2008.

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.

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. While vulnerability scanning is not applicable, the agency must still 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.

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 VCCT provided by CPS have to enroll the associated merchant number with TrustWave?

Yes. While the vulnerability scanning of Virtual Credit Card Terminals (VCCTs) provided by CPS is not the responsibility of the participant but that of the Office of Information Technology Services (ITS), the agency must still enroll in TrustKeeper in order to complete the online Self-Assessment Questionnaire (SAQ). The SAQ is to be completed annually. If the VCCT is provided by a third party gateway instead of CPS, the third party must be a compliant 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 gateway service providers used by a participant have to be PCI compliant?

Yes, 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. These service providers should be able to provide you evidence of their validation. The Common Payment Service (CPS) has been certified by TrustWave as being compliant.

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.

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.

Participants under the State's contract with STMS should be aware that STMS will not accept the enrollment of any new application that is not compliant with either PABP or 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. This effective date will vary according to the application, anywhere from 12 to 24 months after the vendor received PABP certification for the application.

The list of validated applications is targeted to be published by the PCI Security Standard Council toward the end of September 2008. Grandfathered PABP applications, PABP applications that go through the PA-DSS Transition Procedures, and newly validated PA-DSS applications will be on this list. Visa will continue to publish their list of PABP applications until publication of PCI SSC's list. Participants should check with their vendor to ascertain if the application they are currently using will be considered PA-DSS compliant, by virtue of a new certification or by virtue of being grandfathered. If assurance cannot be obtained from the vendor, the participant should begin considering acquiring an alternate application that is considered PA-DSS compliant.

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