What are the various PCI Security Standards?
The PCI Security Standards are developed and maintained by the PCI Security Standards Council to protect payment data throughout the payment lifecycle. The different PCI Standards Support different stakeholders and functions within the payments industry. These standards are constantly evolving. Visit the PCI Security Standards Council website (external link) for current standards.
The PCI security standards that agencies functioning as merchants must adhere to are the 12 mandated security requirements of the PCI Data Security Standard (PCI-DSS) that are designed to protect cardholder data during processing, storage, and transmission.
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 was retired in October 2022 and has been superseded by the PCI Software Security Framework (PCI-SSF) which is a set of security standards by the PCI Security Standards Council designed to help software vendors secure payment applications. It focuses on two key areas: the Secure Software Standard for product security and the Secure Software Lifecycle Standard for development processes.
PA-DSS was a standard (separate from the PCI DSS) which stands for Payment Application Data Security Standard. Released in April 2008, it replaced Visa's Payment Application Best Practices (PABP), on a phase-in basis. The goal of PA-DSS was 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). PA-DSS was retired in October 2022.
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 PIN Transaction Security (PTS) Point of Interaction (POI) Standard. This standard offers security requirements for the characteristics and management of devices used to protect cardholder PINs, account data, and other sensitive payment card data at the point of interaction. POI devices are used by merchants, financial institutions, and other payment industry participants at the point of interaction to capture payment card data during payment card transactions. The latest version of the standard is 7.0 (May 2025) and is valid until April 2023. Always check the PCI Security Standards Council website (external link) for the most recent version.
What are Merchant Levels?
Merchant levels (or PCI compliance levels) are four distinct categories defined by the card brands (Visa, Mastercard, AMEX, etc.). 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 transactions exceeding 6 million annually through any acceptance channel, or any merchant that has experienced a security breach that resulted in an account compromise, or any merchant identified by any card association as Level 1. A Level 1 merchant is required to file an annual Report on Compliance (ROC) completed by a Qualified Security Assessor and must pass quarterly vulnerability scans by a PCI-SSC approve vendor and the Attestation of Compliance.
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). Each Level 2 merchant must provide an annual attestation of its compliance to both Visa and MasterCard, if directed by the processor Fiserv/First Data Merchant Services.
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).
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, 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 may be required.
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
These 6 elements can be further expanded to cover the 12 mandated security requirements.
What version of the PCI DSS applies?
On March 31, 2022, the PCI Security Standards Council published version 4.0 of the PCI Data Security Standard (PCI DSS). It introduced significant updates, with a two-year transition period that made it fully mandatory on March 31, 2024, replacing version 3.2.1 Always consult the PCI Security Standards Council website (external link) for the latest version of the standards.
Where can the standard be found?
The standard is posted on the website hosted by the PCI Security Council (external link).
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 Fiserv/First Data Merchant Services to remain compliant with PCI-DSS.
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 Fiserv/First Data Merchant Services has the authority to grant an exemption from being compliant with the PCI DSS.
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.
How does a participant enrolled (or enrolling) in the MSA validate its compliance with the standards?
Effective February 1, 2015, each participant in the MSA may enroll in the optional compliance validation services previously available through Coalfire and currently available from MegaPlanIt and VigiTrust. Enrollment 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 MegaPlanIt, 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.
- Self-Assessment Questionnaire - 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 VigiTrust, each participant is able to select the appropriate SAQ to be completed and complete the SAQ online via the VigiOne portal.
Participants can also seek to procure PCI compliance validation services on their own and not use the optional services provided by MegaPlanIt and VigiTrust.
What is the role of the Office of the State Controller (OSC) in PCI DSS Compliance?
OSC has elected to obtain optional statewide compliance validation services for the participants in the MSA through MegaPlanIt for vulnerability scans and the VigiOne portal for SAQs. 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 Fiserv/First Data Merchant Services.
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 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 (SAQ) for all capture methods - on an annual basis. Attestation of validation is included in the SAQ and is to be provided by the merchant to the acquirer (Fiserv/First Data Merchant Services). For participants in the State's Master Services Agreement (MSA), vulnerability scanning and SAQ services are available as an optional service through MegaPlanIt and VigiTrust respectively. In addition, Fiserv/First Data Merchant Services may require a written attestation by the merchant if deemed necessary to fulfill any requirements of the card associations.
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 complete an annual Self-Assessment Questionnaire (SAQ). 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?
PCI DSS Requirement 11 (version 4.0) mandates that organizations regularly test security systems and processes to ensure the protection of cardholder data. Key actions include quarterly wireless access point scans, internal/external vulnerability scans at least every three months, annual penetration testing, and implementing change-detection mechanisms to protect web pages from unauthorized script. Key aspects of Requirement 11:
- Wireless Security (11.1): Detect authorized and unauthorized wireless access points at least quarterly.
- Vulnerability Scans (11.2): Conduct internal and external network scans at least quarterly and after any significant changes, using an Approved Scanning Vendor (ASV) for external scans.
- Penetration Testing (11.3): Perform comprehensive network and application layer penetration tests at least annually, and after significant changes.
- Detection Mechanisms (11.6): Implement change- and tamper-detection mechanisms (e.g., file integrity monitoring) to alert on unauthorized modifications to payment pages, which must run at least every seven days.
Incident Response: Vulnerabilities must be remediated, and scans re-tested.
Historically vulnerability scanning was only required of any application that stores, transmits, or processes cardholder data and involves an external facing (web-facing) IP address. However, after the release of PCI DSS 4.0 that is no longer the case. Always check the PDI-DSS standards for current requirements for vulnerability scans as these can change.
When does the Penetration Test requirement apply?
PCI DSS Requirement 11.3 mandates that organizations conduct internal and external penetration testing at least annually and after any significant infrastructure or application upgrade or change.
Which questionnaire should an agency complete?
The types of self-assessment questionnaires are regularly updated by the PCI Security Standards Council. Please visit the PCI website (external link) to review the current SAQs and each of the requirements. Additionally, the VigiOne SAQ tool provided by VigiTrust has a questionnaire that can be walked through that will identify the applicable SAQ.
Is the online reporting system to be considered when answering the Self-Assessment Questionnaire?
Yes. All participants are provided with an online reporting system (e.g.,Commerce Control Center/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. Internal procedures could be developed to prohibit employees from downloading unmasked PANs is 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?
PCI-DSS strictly prohibits storing Sensitive Authentication Data after authorization, even if encrypted. It is never acceptable to retain or store the security code numbers (CVV2 or CVC2), full magnetic stripe/chip track data, or personal identification numbers subsequent to transaction authorization. Substantial fines can be levied by the card associations for such violations.
Do participants utilizing a Virtual Terminal application provided by a gateway service have to undergo external vulnerability scanning?
Merchants using virtual terminals (typically SAQ C-VT) must conduct external vulnerability scans at least once every three months, performed by a PCI Approved Scanning Vendor (ASV) to confirm no cardholder data is stored and security is maintained. While SAQ C-VT merchants don't store data, they must ensure the browser-based system is secure. Virtual terminals are web applications that a merchant enters credit card data into. Virtual terminals 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 address are in scope for PCI vulnerability scanning.
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 undergo vulnerability scanning.
If an agency accepts merchant cards, but is not a participant in OSC's MSA, is it still required to be compliant with the PCI DSS?
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 PCI compliance services under OSC's contract with the PCI compliance vendors?
Yes. State agencies that have obtained an exemption from using OSC's MSA with Fiserv/First Data Merchant Services and are using a different card processor may subscribe to the services 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 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 Fiserv/First Data Merchant Services). Non-State agencies that do not participate in OSC's MSA cannot obtain PCI compliance services through OSC.
Can community colleges obtain PCI Compliance Validation Services through OSC?
Community colleges that are participants in the State Controller's (OSC) MSA with Fiserv/First Data Merchant Services may enroll in contracted compliance validation services through OSC, with OSC being the parent sponsor and administrator. Community colleges that utilize a card processor other than Fiserv/First Data Merchant Services can enroll in contracted compliance validation services through OSC and must refer to the Division of Business and Finance at NCCCS for enrollment instructions.
Is there a cost for enrolling in OSC’s contracted Compliance Validation Services?
No, not for entities that are participants in OSC's MSA, as OSC secures funding for these services on a statewide enterprise approach. For State agencies that are not participants in OSC's MSA, services obtained may be required to incur some of the costs of services obtained.
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 a compliance validation service is required. If vulnerability scanning of any IP addresses is required, scheduling of vulnerability scans should be made, with successful scans being performed before being placed into production. For any additional IP addresses that may be added in the future, the IP addresses should be registered with MegaPlanIt, with a successful scan being made before being placed into production. In all cases (scanning required or not), a Self-Assessment Questionnaire (SAQ) should be completed 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.
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?
Yes, a website that links to a third-party processor (such as a hosted payment page or redirect) generally requires quarterly external vulnerability scans by an Approved Scanning Vendor (ASV) to maintain PCI DSS compliance. Even if the processor handles all data, the agency's site remains in scope, requiring compliance validation. Agencies using redirects or linked third-party payment forms typically complete SAQ A, which necessitates quarterly external vulnerability scans. If the agency has external facing IP addresses (which a website does), a quarterly scan by an ASV is mandatory to identify vulnerabilities. Using a compliant third-party processor reduces scope but does not eliminate the need for regular vulnerability scanning. Always consult the PCI Security Standards Council website (external link) for the must current standards.
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 (Card Information Security Program) and the SDP (Mastercard Site Data Protection), 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 are 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 Fiserv, paragraph 8 of the Agency Participation Agreement 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 Fiserv that relate to fines?
Yes. The pertinent terms include paragraphs 2.11.5 and 11.5.3.
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 Department of Information Technology. The plan should require the reporting of a known or suspected security incident within 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 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 in adherence with policies of OSC
- To be a good steward in preventing citizens' identity theft