128+ terms covering PCI DSS, payment security, compliance frameworks, and industry terminology. Your complete reference for understanding payment card security.
The set of policies, procedures, and technical controls that restrict access to systems, data, and resources to only authorised individuals. PCI DSS Requirement 7 requires that access to cardholder data be limited to personnel whose job function requires it (need-to-know). Access must be granted based on the least privilege principle and reviewed at least every six months.
A financial institution or entity that contracts with merchants to process payment card transactions. The acquirer is responsible for ensuring its merchants comply with PCI DSS and may impose fines or terminate the merchant agreement for non-compliance. Acquirers submit transaction data to the card networks for clearing and settlement, and bear financial risk for merchant fraud and chargebacks.
When a customer pays with a Visa card at a retailer, the retailer's acquirer routes the authorisation request through VisaNet to the issuing bank.
A global payment card network that uniquely serves as both card issuer and network operator (closed-loop model). American Express is a founding member of the PCI SSC. Unlike Visa and Mastercard, Amex has a direct relationship with many merchants. Amex enforces PCI DSS compliance through its Data Security Operating Policy (DSOP) with merchant levels based on Amex-specific transaction volumes.
The yearly PCI DSS compliance validation required for all entities that store, process, or transmit cardholder data. For Level 1 entities, this is a formal on-site assessment by a QSA. For other levels, it is a self-assessment using the appropriate SAQ. The annual assessment cycle is fundamental to PCI DSS — compliance is not a one-time achievement but an ongoing obligation.
Software designed to detect, prevent, and remove malicious software (malware) from systems. PCI DSS Requirement 5 requires that anti-malware solutions be deployed on all systems commonly affected by malware within the CDE. Solutions must be kept current, perform periodic scans, generate audit logs, and cannot be disabled by users without authorisation.
The practices and controls that protect application programming interfaces from misuse, unauthorised access, and data leakage. In PCI DSS environments, APIs that transmit or process cardholder data must use strong authentication, TLS encryption, input validation, rate limiting, and logging. PCI DSS v4.0 places increased emphasis on securing custom application interfaces.
An organisation certified by the PCI SSC to perform external vulnerability scans of internet-facing systems. PCI DSS Requirement 11.3.2 requires quarterly ASV scans for all entities with internet-facing system components. ASV scans check for known vulnerabilities and produce a pass/fail report. Passing scans are required for compliance validation.
A merchant receives a "fail" result from their quarterly ASV scan due to an outdated TLS configuration. They must remediate and rescan until a passing result is achieved.
A formal declaration or certification of compliance status. In PCI DSS, attestation takes the form of the AOC (Attestation of Compliance), which is signed by an authorised officer of the assessed entity and the QSA (for on-site assessments). The attestation confirms that the assessment was conducted according to PCI DSS procedures and represents the entity's compliance status.
A formal document signed by the merchant or service provider and the QSA (if applicable) attesting to the entity's PCI DSS compliance status. The AOC summarises the assessment scope, methodology, and results without the detailed evidence contained in the ROC. Acquirers and payment brands typically require the AOC as evidence of compliance.
The process by which a payment card transaction is approved or declined by the issuing bank. When a cardholder presents their card, the merchant sends an authorisation request through the acquirer and payment network to the issuer, which checks the account status, available credit, and fraud indicators before returning an approval or decline code. Authorisation data includes the PAN and is in scope for PCI DSS.
The first 6–8 digits of a payment card number (PAN) that identify the issuing bank, card brand, card type, and country of issuance. BINs are also called Issuer Identification Numbers (IINs). BIN data is used for transaction routing, fraud detection, and card scheme identification. While BINs alone are not considered cardholder data under PCI DSS, they are sometimes treated as sensitive by organisations.
A BIN of 411111 identifies the card as a Visa card issued by a specific bank, allowing the payment processor to route the transaction correctly.
An attack method that systematically tries every possible combination of credentials until the correct one is found. PCI DSS Requirement 8.3.4 mandates account lockout after no more than 10 invalid login attempts, and lockout duration of at least 30 minutes (or until an administrator unlocks the account). Rate limiting and CAPTCHA provide additional protection.
The organisation and network infrastructure that facilitates payment card transactions between issuers, acquirers, and merchants. Card schemes (also called card networks or payment brands) set the rules for transaction processing, interchange fees, and security standards. The major global card schemes are Visa, Mastercard, American Express, Discover/Diners Club, JCB, and UnionPay.
A transaction where the physical card is not presented to the merchant, such as e-commerce, mail-order, or telephone-order payments. CNP transactions carry higher fraud risk and different PCI DSS scope considerations. Merchants processing CNP transactions typically use SAQ A, SAQ A-EP, or SAQ D depending on their payment page integration method.
An online bookshop where customers enter their card details on a checkout page is conducting CNP transactions.
A transaction where the physical payment card is presented at the point of interaction, typically via chip insertion, magnetic stripe swipe, or contactless tap. Card-present transactions are generally considered lower fraud risk than CNP transactions. Merchants processing only CP transactions via P2PE may qualify for SAQ P2PE.
Information printed on, or stored within, a payment card that must be protected under PCI DSS. At minimum CHD includes the PAN, and may also include cardholder name, expiration date, and service code when stored alongside the PAN. CHD differs from SAD in that CHD may be retained post-authorisation if properly protected.
The people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data. The CDE also includes any component that directly connects to or supports this environment. Accurately defining CDE scope is the foundation of every PCI DSS assessment.
A payment application server, the database storing encrypted PANs, and the network switch connecting them are all part of the CDE.
The name of the individual to whom the payment card is issued, as printed on the card and encoded in Track 1 data. Cardholder name is considered CHD only when stored in conjunction with the PAN. On its own, it does not trigger PCI DSS requirements.
A trusted entity that issues digital certificates used to verify the identity of servers, devices, or individuals in cryptographic communications. In a PCI DSS context, CAs underpin TLS/SSL connections that protect cardholder data in transit. Organisations must manage their certificate inventory and ensure timely renewal to avoid service disruptions.
A formal process for requesting, reviewing, approving, testing, and documenting changes to system components in the CDE. PCI DSS Requirement 6.5 requires change control processes for all changes to system components. Changes must be documented, include a back-out plan, assess security impact, and be approved by authorised parties before deployment.
A reversal of a payment card transaction initiated by the cardholder's issuing bank, typically due to a dispute over the transaction (e.g., unauthorised use, goods not received, or merchant error). Chargebacks result in the transaction amount being returned to the cardholder and debited from the merchant's account, plus a chargeback fee. High chargeback rates can lead to PCI DSS compliance scrutiny, increased processing fees, or account termination.
An alternative security control that can be considered when an entity cannot meet a PCI DSS requirement due to legitimate technical or business constraints. Compensating controls must meet the intent and rigour of the original requirement, provide a similar level of defence, and be "above and beyond" other PCI DSS requirements. They must be documented in a Compensating Control Worksheet and validated by the assessor.
A legacy system that cannot support TLS 1.2 may use a compensating control of network segmentation, IP whitelisting, and enhanced monitoring to protect the connection.
A document or digital badge issued upon successful completion of PCI DSS compliance validation. While the AOC is the official attestation, some QSAs and compliance management platforms issue certificates that summarise the entity's compliance status, scope, and validity period. Compliance certificates are often shared with business partners and customers as evidence of data security commitment.
The process by which an entity demonstrates its compliance with PCI DSS to its acquirer and the payment brands. Validation methods include on-site assessments (ROC/AOC by a QSA), self-assessments (SAQ/AOC), and quarterly ASV scans. The required validation level depends on the entity's merchant level and the payment brand's specific programme rules.
A payment method using near-field communication (NFC) technology that allows a cardholder to tap or wave their card or mobile device near a POI terminal. Contactless transactions use EMV chip technology and generate dynamic cryptograms. The same PCI DSS requirements apply to contactless payment data as to any other card-present transaction.
An attack that forces an authenticated user's browser to send forged requests to a web application, performing unwanted actions such as changing account settings or initiating transactions. CSRF tokens and SameSite cookie attributes are common defences. PCI DSS Requirement 6.2 includes CSRF among the common software vulnerabilities that must be addressed in secure development practices.
An application-layer vulnerability where an attacker injects malicious scripts into web pages viewed by other users. In payment environments, XSS on a merchant's site could be used to steal cardholder data from payment forms or redirect users to phishing pages. PCI DSS Requirement 6.2 requires secure coding practices that address XSS, and Requirement 6.4.3 mandates script integrity controls on payment pages.
A new validation option introduced in PCI DSS v4.0 that allows organisations to meet a requirement's stated objective using controls that differ from the defined approach. The customised approach requires a targeted risk analysis, documented controls matrix, and independent testing by the assessor. It is intended for mature organisations with robust security programmes.
Card verification values are security codes used to validate card-not-present transactions. CVV2 (Visa), CVC2 (Mastercard), CAV2 (JCB), and CID (Amex/Discover) are the three- or four-digit numbers printed on the card. These values are classified as SAD and must never be stored after authorisation under any circumstances.
An e-commerce checkout page collects the CVV to send in the authorisation request, but the merchant must never write the CVV to a database or log file.
Technologies and processes designed to detect and prevent the unauthorised transmission of sensitive data outside the organisation. DLP solutions can monitor email, web traffic, removable media, and cloud storage for patterns matching cardholder data (e.g., PAN formats). While not explicitly required by PCI DSS, DLP supports multiple requirements related to protecting stored data and monitoring access.
The traditional PCI DSS validation method where an organisation meets each requirement exactly as stated in the standard, following the prescribed testing procedures. The defined approach is the most straightforward compliance path and is suitable for all organisations. Under PCI DSS v4.0, entities choose between the defined approach and the customised approach for each requirement.
An electronic document issued by a certificate authority that binds a public key to an entity's identity. Digital certificates enable encrypted communications (TLS/SSL) and authenticate the identity of web servers to clients. PCI DSS requires the use of trusted certificates from recognised CAs for all public-facing connections transmitting cardholder data.
A payment card network and founding member of the PCI SSC, also operating the Diners Club International network. Discover enforces PCI DSS compliance through its Discover Information Security Compliance (DISC) programme. Discover's merchant level thresholds generally align with those of Visa and Mastercard.
A network segment that sits between the public internet and the internal network, providing an additional layer of security. Public-facing systems (e.g., web servers) are placed in the DMZ while backend systems (e.g., databases) reside on the internal network. PCI DSS requires that systems storing cardholder data are never placed directly in the DMZ.
A key-management scheme in which a unique encryption key is derived for each transaction from an initial key loaded into the payment terminal. DUKPT ensures that compromise of a single transaction key does not expose keys from other transactions. It is widely used in P2PE and PCI PTS environments for PIN and data encryption.
An integrated circuit embedded in payment cards conforming to the EMV (Europay, Mastercard, Visa) standard. EMV chip transactions generate a unique cryptogram for each transaction, making counterfeit fraud significantly harder than magnetic stripe. Chip data equivalent to track data is classified as SAD and must not be stored after authorisation.
The use of cryptographic algorithms to protect stored cardholder data so that it is unreadable without the correct decryption keys. PCI DSS Requirement 3 mandates that stored PAN be rendered unreadable using methods such as strong one-way hashing, truncation, index tokens, or strong cryptography with associated key-management processes.
The use of strong cryptography to protect cardholder data while it is being transmitted over open, public networks. PCI DSS Requirement 4 requires that PAN be encrypted during transmission using protocols such as TLS 1.2+ or IPsec. Internal network transmission should also use encryption where feasible.
A security solution that continuously monitors endpoints (servers, workstations, mobile devices) for suspicious behaviour, provides real-time visibility, and enables rapid response to threats. EDR goes beyond traditional antivirus by using behavioural analysis and machine learning to detect advanced threats. It supports PCI DSS Requirements 5 and 10.
The date after which a payment card is no longer valid, printed on the card front and encoded in track data. The expiration date is classified as CHD when stored alongside the PAN. It may be retained post-authorisation if business needs justify it and it is adequately protected.
An evolution of EDR that integrates security data across endpoints, networks, cloud workloads, and email to provide unified threat detection and response. XDR correlates alerts from multiple security layers to reduce noise and improve investigation efficiency. While not explicitly required by PCI DSS, XDR supports multiple requirements across logging, monitoring, and incident response.
A security control that detects unauthorised changes to critical system files, configuration files, and content files. PCI DSS Requirement 11.5 requires FIM to be deployed on systems within the CDE to alert personnel to unauthorised modification of critical files. FIM comparisons must be performed at least weekly.
FIM software detects that a payment application's executable file has been modified outside of the change control window and generates an alert for the security team.
A network security device or software that monitors and controls incoming and outgoing network traffic based on predetermined security rules. PCI DSS Requirement 1 mandates the installation and maintenance of network security controls (firewalls and/or equivalent technology) to protect the CDE. Firewall rules must be reviewed at least every six months.
A stateful inspection firewall is configured to deny all inbound traffic to the CDE except from explicitly approved source IP addresses and ports.
A detailed examination of systems and data following a suspected or confirmed security breach to determine the nature, scope, and source of the compromise. Payment card forensic investigations must be conducted by a PCI Forensic Investigator (PFI) certified by the PCI SSC. The PFI provides findings to the acquirer and payment brands.
The financial responsibility for fraudulent transactions, allocated between the issuer and the acquirer/merchant based on the circumstances. Under the EMV liability shift, if a chip card is used at a non-chip terminal, fraud liability shifts to the merchant/acquirer. For CNP transactions, liability rules vary by card network. PCI DSS non-compliance can result in increased fraud liability and fines following a data breach.
A preliminary assessment that compares an organisation's current security controls against PCI DSS requirements to identify areas of non-compliance (gaps). A gap analysis is typically the first step in a PCI DSS compliance programme and is used to create a prioritised remediation plan. It is not a formal assessment and does not result in a compliance certification.
A QSA conducts a gap analysis for a new e-commerce merchant and identifies 47 gaps across Requirements 2, 6, 8, and 10, producing a remediation roadmap.
A physical computing device that safeguards and manages cryptographic keys, performs encryption/decryption operations, and provides tamper-resistant key storage. HSMs are used in payment processing to protect PIN blocks, generate keys, and perform cryptographic operations in a certified secure boundary. They are typically FIPS 140-2 Level 3 or higher certified.
A one-way cryptographic function that converts input data into a fixed-length output (hash value) from which the original data cannot be recovered. PCI DSS accepts keyed cryptographic hashing (e.g., HMAC-SHA256) as a method to render stored PAN unreadable. Simple, unkeyed hashes are not considered sufficient as lookup tables can reverse them.
A merchant stores HMAC-SHA256 hashes of PANs for transaction lookups, making it computationally infeasible to reverse-engineer the original card number.
Security systems that monitor network traffic for suspicious activity. An IDS detects and alerts on potential threats, while an IPS actively blocks them. PCI DSS Requirement 11.4 requires intrusion-detection or intrusion-prevention techniques at the perimeter and critical points of the CDE to detect and/or prevent intrusions.
A payment page implementation where the payment form is embedded within an inline frame (iframe) served from the payment provider's domain. Since cardholder data is entered into the provider's iframe and never touches the merchant's server, this approach can qualify the merchant for SAQ A. However, the parent page must still be secured against script injection.
The organised approach to addressing and managing the aftermath of a security breach or cyberattack. PCI DSS Requirement 12.10 mandates a documented incident response plan that covers roles and responsibilities, communication procedures, containment and recovery steps, and root-cause analysis. The plan must be tested at least annually.
Upon detecting unauthorised access to the CDE, the incident response team follows the documented plan: contain the breach, notify the acquirer and forensic investigator, preserve evidence, and begin remediation.
A fee paid by the acquirer to the issuer for each payment card transaction, designed to compensate the issuer for the cost and risk of extending credit. Interchange fees are set by the card networks and vary based on factors such as transaction type (CP vs. CNP), merchant category, and card type. They represent the largest component of the merchant discount rate.
An individual employed by the organisation who has been trained and certified by the PCI SSC to perform internal PCI DSS assessments. ISAs can conduct assessments on behalf of their own organisation, but for Level 1 entities, the assessment must still be validated by a QSA. ISAs help maintain continuous compliance between annual QSA assessments.
A financial institution that issues payment cards to consumers on behalf of the card networks (Visa, Mastercard, etc.). The issuer is responsible for authenticating the cardholder during transactions, approving or declining authorisation requests, and billing the cardholder. Issuers bear the fraud liability for card-present transactions (post-EMV liability shift) and set cardholder credit limits and terms.
Chase Bank issues a Visa credit card to a consumer. When the consumer makes a purchase, Chase (the issuer) receives the authorisation request and approves or declines it based on the account status.
A payment page implementation that uses JavaScript loaded from the payment provider to collect cardholder data directly on the merchant's page. While the data is sent directly to the provider, the merchant's page controls the script execution context. This typically qualifies the merchant for SAQ A-EP, which has more requirements than SAQ A due to the increased risk of script compromise.
A merchant uses Stripe.js to render card input fields on their checkout page. The fields are controlled by Stripe's JavaScript, but the merchant's page must be secured against XSS attacks.
A major international payment card brand headquartered in Japan and a founding member of the PCI SSC. JCB enforces PCI DSS compliance through its JCB Data Security Programme. JCB has a significant presence in the Asia-Pacific region and is accepted globally. Its merchant level definitions and compliance validation requirements align closely with those of other payment brands.
The set of policies and procedures governing the lifecycle of cryptographic keys, including generation, distribution, storage, rotation, and destruction. PCI DSS Requirement 3.6 and 3.7 mandate documented key-management processes. Weak key management undermines even the strongest encryption algorithms.
An organisation rotates its data-encrypting keys annually, uses split-knowledge and dual-control procedures, and stores key-encrypting keys in an HSM.
A security principle that grants users and processes only the minimum level of access necessary to perform their required functions. PCI DSS Requirement 7.1 mandates that access to system components and cardholder data is limited to only those individuals whose job requires such access. Default access should be "deny all" unless specifically allowed.
The practice of collecting, reviewing, and analysing audit logs from systems, applications, and network devices to detect anomalies and security incidents. PCI DSS Requirement 10 requires logging of all access to cardholder data and all actions by individuals with administrative privileges. Logs must be reviewed at least daily, and retained for at least 12 months with 3 months immediately available.
Data encoded on a payment card's magnetic stripe, encompassing Tracks 1, 2, and (rarely) 3. This data includes the PAN, cardholder name, expiration date, and service code. Full magnetic stripe data is classified as SAD. While magnetic stripe technology is legacy, it remains in use globally and is a target for skimming attacks.
Malicious software designed to damage, disrupt, or gain unauthorised access to computer systems. In the payment card context, malware types include RAM scrapers (memory-scraping malware targeting POS systems), keyloggers, banking trojans, and web skimmers (e.g., Magecart). PCI DSS Requirement 5 mandates anti-malware protections on all systems commonly affected by malware.
Magecart is a type of malware that injects malicious JavaScript into e-commerce payment pages to capture cardholder data as it is entered by customers.
A global payment card network and founding member of the PCI SSC. Mastercard enforces PCI DSS compliance through its Site Data Protection (SDP) programme. Mastercard's merchant levels are: Level 1 (over 6 million transactions/year), Level 2 (1–6 million), Level 3 (20,000–1 million e-commerce), Level 4 (under 20,000 e-commerce). Mastercard requires Level 1 and Level 2 merchants to validate compliance annually.
Any entity that accepts payment cards for goods or services. Merchants are assigned a level (1–4) based on annual transaction volume, which determines their PCI DSS compliance validation requirements. All merchants that store, process, or transmit cardholder data must comply with PCI DSS, regardless of size. The acquirer is responsible for ensuring merchant compliance.
A classification assigned to merchants based on their annual payment card transaction volume, determining the required PCI DSS compliance validation method. Level 1: over 6 million transactions (requires QSA on-site assessment). Level 2: 1–6 million transactions. Level 3: 20,000–1 million e-commerce transactions. Level 4: fewer than 20,000 e-commerce or up to 1 million other transactions. Thresholds vary slightly by payment brand.
A retailer processing 8 million Visa transactions annually is classified as Level 1 and must undergo an annual on-site QSA assessment.
An authentication method requiring two or more independent factors: something you know (password), something you have (token/device), or something you are (biometric). PCI DSS Requirement 8.4 mandates MFA for all non-console administrative access to the CDE and for all remote network access. PCI DSS v4.0 extended MFA requirements to all access into the CDE, not just remote.
An administrator logs into the payment server using a password (factor 1) and a time-based one-time password from an authenticator app (factor 2).
The practice of dividing a network into isolated segments to limit the scope of the CDE and reduce the number of systems subject to PCI DSS requirements. While not a PCI DSS requirement itself, network segmentation is strongly recommended as it reduces assessment scope, cost, and risk. Segmentation controls must be validated during penetration testing.
A retailer isolates its payment processing VLAN from its corporate network using firewalls, reducing PCI DSS scope to only the payment segment.
A formal PCI DSS compliance evaluation conducted by a QSA at the assessed entity's location(s). On-site assessments are mandatory for Level 1 merchants and Level 1 service providers. The QSA examines documentation, interviews personnel, observes processes, and tests technical controls. The deliverables are a ROC and AOC.
A former PCI standard for payment application vendors, ensuring their products do not store prohibited data and support merchant PCI DSS compliance. PA-DSS has been replaced by the PCI Software Security Framework (SSF), which includes the Secure Software Standard and the Secure Software Lifecycle Standard. Existing PA-DSS validations remain valid until their expiration date.
The process of identifying, evaluating, testing, and deploying software patches and updates to address security vulnerabilities. PCI DSS Requirement 6.3 requires that critical security patches be installed within one month of release. A documented patch management process must cover all system components in the CDE, including operating systems, applications, and firmware.
An organisation that operates a payment card network and sets the rules for card acceptance, including PCI DSS compliance requirements. The five major payment brands — Visa, Mastercard, American Express, Discover, and JCB — founded the PCI SSC. Each brand has its own compliance programme with specific merchant level thresholds, deadlines, and penalty structures.
A service provider that enables sub-merchants to accept card payments under the PayFac's merchant account with an acquirer. The PayFac assumes responsibility for sub-merchant onboarding, risk management, and PCI DSS compliance oversight. PayFacs must be PCI DSS Level 1 compliant and are accountable for their sub-merchants' compliance.
Square and Stripe act as PayFacs, allowing small businesses to accept card payments without establishing their own merchant accounts.
A technology service that transmits payment transaction data from the merchant to the acquirer or payment processor. Payment gateways are service providers under PCI DSS and must be PCI DSS compliant. Merchants should verify their gateway's compliance status and understand which party is responsible for each PCI DSS requirement.
Stripe, Braintree, and Adyen are examples of payment gateways that offer PCI-compliant hosted payment pages to reduce merchant scope.
The infrastructure and rules that connect issuers, acquirers, and merchants to facilitate payment card transactions. Payment networks (e.g., VisaNet, Mastercard Network) route authorisation requests, clearing data, and settlement funds between parties. They also set the operating regulations that govern dispute resolution, interchange fees, and security requirements including PCI DSS compliance.
A web page where cardholder data is collected during an e-commerce transaction. The security of the payment page directly affects PCI DSS scope and SAQ eligibility. Options include fully hosted pages (redirect), iframe-embedded pages, or JavaScript integrations. PCI DSS v4.0 introduced new requirements (6.4.3, 11.6.1) for monitoring scripts on payment pages.
A merchant embeds their payment provider's iframe on their checkout page, so cardholder data is collected by the provider's domain, not the merchant's.
An entity that handles the technical processing of payment card transactions on behalf of acquirers or merchants. Payment processors route authorisation requests to the card networks and issuers, and handle clearing and settlement. As service providers, they must maintain their own PCI DSS compliance and provide evidence of compliance to their clients.
A device used at the point of sale to capture payment card data via magnetic stripe, EMV chip, or contactless interface. Terminals must be PCI PTS-approved and regularly inspected for tampering. PCI DSS Requirement 9 mandates physical security controls for terminals, including tamper-evidence checks and personnel training.
A PCI standard that provides security requirements for environments performing 3DS functions — the authentication protocol that adds an additional verification layer for card-not-present transactions. 3DS (e.g., Visa Secure, Mastercard Identity Check) reduces fraud by verifying the cardholder's identity with the issuing bank during online transactions.
The global security standard for all entities that store, process, or transmit cardholder data and/or sensitive authentication data. PCI DSS provides a framework of 12 high-level requirements organised into 6 control domains. Version 4.0.1 is the current version, with full enforcement from March 2025. Compliance is mandated by the payment brands (Visa, Mastercard, etc.) and enforced through acquirers.
A PCI standard that specifies requirements for the secure management, processing, and transmission of PIN data during online and offline payment card transactions. PCI PIN covers key management, cryptographic operations, and the physical and logical security of devices that handle PIN data. Acquirers and processors managing PIN transactions must comply with PCI PIN.
A PCI SSC standard that defines security requirements for PIN acceptance and processing devices. PCI PTS covers device hardware and firmware security, cryptographic key management, and device lifecycle management. Only PTS-approved devices should be used for PIN entry in PCI DSS environments.
Before deploying a new payment terminal, a merchant verifies it appears on the PCI SSC list of PTS-approved devices.
The global forum founded in 2006 by Visa, Mastercard, American Express, Discover, and JCB to develop, manage, and promote PCI security standards. The PCI SSC maintains PCI DSS, PA-DSS (now SSF), PCI PTS, PCI P2PE, PCI 3DS, and PCI PIN standards. It also qualifies QSAs, ASVs, PFIs, and other security professionals. The PCI SSC does not enforce compliance — that responsibility lies with the payment brands and acquirers.
A PCI standard that governs entities providing payment tokenisation services, ensuring tokens are generated, managed, and de-tokenised securely. TSPs replace PANs with tokens for use in payment transactions, reducing the risk of data exposure. TSPs must maintain the security of the token vault and ensure tokens cannot be reverse-engineered to reveal the original PAN.
A controlled, simulated attack against systems and networks to identify exploitable security vulnerabilities. PCI DSS Requirement 11.4 mandates annual penetration testing (or after significant changes) of the CDE perimeter and critical systems, covering both network-layer and application-layer tests. The methodology must be based on an industry-accepted approach such as NIST SP 800-115 or OWASP.
A qualified penetration tester attempts to exploit vulnerabilities in the merchant's e-commerce application to demonstrate whether an attacker could access cardholder data.
A qualified forensic investigator certified by the PCI SSC to conduct forensic examinations following a suspected or confirmed payment card data breach. PFIs determine the scope of the compromise, identify the attack vector, assess what data was exposed, and provide recommendations for remediation. Acquirers and payment brands may mandate a PFI investigation after a breach.
A social engineering attack that uses deceptive emails, messages, or websites to trick individuals into revealing sensitive information or installing malware. PCI DSS Requirement 12.6 requires security awareness training that covers phishing threats. Spear phishing targets specific individuals, while whaling targets senior executives.
An attacker sends an email impersonating the CFO, asking the finance team to "verify" payment card data on a spoofed website.
A Personal Identification Number used to verify the cardholder at a point-of-interaction device. A PIN block is the encrypted representation of the PIN combined with the PAN using a standard format (e.g., ISO 9564). PIN and PIN block data are classified as SAD and must be encrypted in transit and never stored after authorisation.
When a cardholder enters their PIN at an ATM, the terminal encrypts it into a PIN block before transmitting it to the issuer for verification.
The initial point where payment card data is captured — typically a payment terminal, card reader, or e-commerce payment page. POI devices must be secured against physical tampering and logical attacks. In a P2PE solution, the POI is where encryption first occurs.
A PCI-validated solution that encrypts cardholder data at the point of interaction (POI) using validated encryption hardware, and the data cannot be decrypted until it reaches the secure decryption environment. P2PE-validated solutions significantly reduce the merchant's PCI DSS scope because the merchant never has access to cleartext cardholder data.
A retail merchant using a PCI-listed P2PE solution can qualify for SAQ P2PE, which has significantly fewer requirements than SAQ D.
The unique payment card number (typically 14–19 digits) that identifies the issuer and the cardholder account. The PAN is the defining element of cardholder data — if PAN is not present, PCI DSS requirements do not apply. It must be rendered unreadable anywhere it is stored using truncation, tokenisation, hashing, or strong cryptography.
A Visa card number such as 4111 1111 1111 1111 is a PAN. Storing it in plaintext violates PCI DSS Requirement 3.
An individual certified by the PCI SSC to perform on-site PCI DSS assessments and validate an organisation's compliance. QSAs are employed by QSA Companies (QSACs) that have been qualified by the PCI SSC. They are required to assess Level 1 merchants and Level 1 service providers, and produce the ROC and AOC as assessment deliverables.
A Level 1 retailer engages a QSA to conduct an annual on-site PCI DSS assessment, resulting in a Report on Compliance submitted to their acquirer.
An external vulnerability scan performed every 90 days by an ASV on all internet-facing system components. PCI DSS Requirement 11.3.2 mandates quarterly ASV scans. A passing scan must show no vulnerabilities with a CVSS score of 4.0 or higher. Failed scans require remediation and rescanning until a passing result is achieved within the quarter.
A type of malware that encrypts a victim's data and demands a ransom payment for the decryption key. Ransomware attacks on organisations in the CDE can disrupt payment processing and may lead to data breaches. Defence requires a multi-layered approach including network segmentation, regular backups, endpoint protection, user awareness training, and a tested incident response plan.
A payment integration method where the customer is redirected from the merchant's website to the payment provider's hosted payment page to enter cardholder data. After the transaction is completed, the customer is redirected back to the merchant. This is the simplest method for achieving SAQ A eligibility as no cardholder data touches the merchant's systems.
The process of correcting identified security deficiencies or gaps to achieve compliance with PCI DSS requirements. Remediation may include implementing new controls, updating configurations, deploying patches, or redesigning architecture. A remediation plan should prioritise high-risk items and include timelines, responsible parties, and validation procedures.
The detailed compliance report produced by a QSA (or ISA under QSA oversight) following an on-site PCI DSS assessment. The ROC documents the assessor's findings for each PCI DSS requirement, including testing procedures performed, evidence examined, and the compliance status of each requirement. It is the primary deliverable for Level 1 merchants and service providers.
An access control model where permissions are assigned to roles, and users are assigned to roles based on their job function. RBAC simplifies access management and supports the PCI DSS requirement for need-to-know access control. Each role should have the minimum privileges necessary to perform its duties.
A "Payment Operations" role grants read access to transaction records but not to stored cardholder data, while a "Database Admin" role has no access to production cardholder data.
The simplest SAQ type, applicable to e-commerce or mail/telephone-order merchants that have fully outsourced all cardholder data processing to PCI DSS-compliant third parties. The merchant's website must not directly receive cardholder data — payment pages must be entirely from the third-party provider (via redirect or iframe). SAQ A contains approximately 22 requirements.
An SAQ type for e-commerce merchants whose website does not receive cardholder data but does affect the security of the payment transaction. This typically applies when the merchant uses JavaScript-based payment integrations where the merchant's page controls how the payment form is rendered. SAQ A-EP has approximately 139 requirements — significantly more than SAQ A.
An SAQ type for merchants that process cardholder data only through imprint machines or standalone, dial-out payment terminals with no electronic cardholder data storage. These merchants have no internet-connected payment processing and no electronic storage of CHD. SAQ B contains approximately 41 requirements.
An SAQ type for merchants using only standalone, PTS-approved payment terminals with an IP connection to the payment processor. The terminals must not be connected to any other systems in the merchant environment, and the merchant must not store electronic cardholder data. SAQ B-IP contains approximately 82 requirements.
An SAQ type for merchants whose payment application systems are connected to the internet but who do not store electronic cardholder data. SAQ C applies to merchants with payment application systems (e.g., POS systems) that are segmented from other network systems. It contains approximately 160 requirements.
An SAQ type for merchants that process cardholder data only through a virtual terminal on an isolated computing device connected to the internet. The virtual terminal is provided by a PCI DSS-compliant third-party service provider, and no electronic cardholder data is stored. SAQ C-VT contains approximately 79 requirements.
The most comprehensive SAQ type, applicable to merchants and service providers that do not qualify for any other SAQ type. SAQ D covers all PCI DSS requirements and is effectively the same scope as a full on-site assessment. There are two versions: SAQ D for Merchants and SAQ D for Service Providers, each with approximately 300+ requirements.
An SAQ type for merchants using only PCI-listed P2PE hardware payment terminals with no electronic cardholder data storage. Because the P2PE solution encrypts data at the POI and the merchant never has access to cleartext cardholder data, this SAQ has significantly reduced scope — approximately 33 requirements. The P2PE solution must be listed on the PCI SSC website.
Strategies and technologies used to minimise the number of systems, processes, and people subject to PCI DSS requirements. Common scope-reduction techniques include network segmentation, tokenisation, P2PE, and outsourcing payment processing to compliant third parties. Reducing scope lowers compliance costs, simplifies assessments, and reduces risk.
By implementing tokenisation and P2PE, a merchant reduces their CDE from 200 servers to 3, qualifying for SAQ P2PE instead of SAQ D.
A PCI DSS compliance validation method where eligible merchants or service providers evaluate their own compliance using the appropriate SAQ, without requiring an on-site QSA assessment. Self-assessment is available to Level 2, 3, and 4 merchants (thresholds vary by payment brand). The entity must honestly evaluate their compliance with each applicable requirement and sign the AOC.
A PCI DSS compliance validation tool for eligible merchants and service providers who are not required to undergo a full on-site assessment. SAQs come in several types (A, A-EP, B, B-IP, C, C-VT, D, P2PE) based on how the entity processes, stores, or transmits cardholder data. Each SAQ type has a specific set of applicable requirements.
A small e-commerce merchant using a fully hosted payment page from their provider completes SAQ A annually, covering only 22 requirements.
Security-related information used to authenticate cardholders and authorise payment transactions. SAD includes full track data, CVV/CVC/CAV2 codes, and PIN/PIN blocks. SAD must never be stored after authorisation, even if encrypted, as its compromise enables counterfeit card fraud.
After a payment is authorised, the merchant system must purge CVV values and full track data from all storage, including logs and temporary files.
A control that divides critical functions among different individuals to prevent a single person from having the ability to both commit and conceal fraud or errors. In PCI DSS environments, this means ensuring that those who develop code do not deploy to production, and those who manage cryptographic keys do not have access to encrypted data in the same capacity.
A three- or four-digit value encoded in the magnetic stripe or chip that specifies card acceptance attributes such as international usage restrictions, PIN requirements, and authorisation processing rules. Service code is classified as CHD when stored with the PAN.
A business entity (not a payment brand) that is directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. Service providers include payment gateways, hosting providers, managed security services, and any third party with access to CHD. They must maintain their own PCI DSS compliance and provide evidence of compliance (AOC) to their customers.
A cloud hosting provider that hosts a merchant's payment application is classified as a service provider and must be PCI DSS compliant.
The process by which funds from payment card transactions are transferred from the issuer to the acquirer and ultimately to the merchant. Settlement typically occurs within 1–3 business days after the transaction. The acquirer deducts the merchant discount rate (which includes the interchange fee and processing fees) before depositing funds into the merchant's account.
A platform that aggregates and analyses log data from multiple sources across the IT environment to detect security events, correlate threats, and support incident investigation. PCI DSS Requirement 10 requires centralised log collection and review. A SIEM automates the continuous monitoring and alerting required by PCI DSS for timely detection of anomalies.
A SIEM platform such as Splunk or Microsoft Sentinel collects logs from firewalls, servers, and applications in the CDE, triggering alerts for suspicious login attempts or configuration changes.
A centralised facility or team responsible for monitoring, detecting, analysing, and responding to security incidents across the organisation. A SOC typically operates 24/7 and leverages tools such as SIEM, EDR, and threat intelligence feeds. For PCI DSS compliance, a SOC supports Requirements 10 (logging and monitoring), 11 (security testing), and 12 (incident response).
Psychological manipulation techniques used to deceive individuals into divulging confidential information or performing actions that compromise security. Common forms include phishing, pretexting, tailgating, and baiting. PCI DSS Requirement 12.6 mandates security awareness training that includes recognition of social engineering attacks.
An application-layer attack where malicious SQL statements are inserted into input fields to manipulate or extract data from a database. SQL injection is one of the most common and dangerous web application vulnerabilities in payment environments. PCI DSS Requirement 6.2 requires secure coding practices that address injection flaws, and a WAF can provide an additional layer of defence.
An attacker enters ' OR 1=1 -- into a login form, bypassing authentication and potentially accessing the cardholder data database.
A focused risk assessment methodology introduced in PCI DSS v4.0 that allows organisations to determine the frequency of certain periodic activities (e.g., log reviews, password changes) based on their specific risk profile. TRA replaces the one-size-fits-all approach with entity-specific frequencies. It must be documented, include threat and vulnerability analysis, and be reviewed at least annually.
Information about current and emerging cyber threats that is collected, analysed, and used to inform security decisions and improve defences. Threat intelligence feeds can include indicators of compromise (IoCs), attack techniques (MITRE ATT&CK), and vulnerability disclosures. PCI DSS v4.0 encourages the use of threat intelligence to prioritise security efforts and enhance detection capabilities.
Transport Layer Security is a cryptographic protocol that provides secure communication over a network. PCI DSS requires a minimum of TLS 1.2 for all connections transmitting cardholder data. TLS 1.3 is recommended as it removes support for weaker cipher suites and improves handshake performance. Earlier versions (SSL, TLS 1.0, TLS 1.1) are explicitly prohibited.
A merchant's e-commerce site must serve all pages over HTTPS using TLS 1.2 or higher, verified by regular vulnerability scans.
The process of replacing a PAN with a surrogate value (token) that has no exploitable meaning outside the tokenisation system. Tokens cannot be reversed without access to the token vault. Tokenisation is one of the most effective scope-reduction techniques because systems that only store tokens are removed from the CDE.
A merchant replaces stored PANs with tokens like "tok_4f8a2b". The token vault is operated by a PCI-compliant service provider, reducing the merchant's CDE scope.
Data encoded on Tracks 1 and 2 of a payment card's magnetic stripe. Track 1 contains the PAN, cardholder name, expiration date, service code, and discretionary data. Track 2 contains PAN, expiration date, service code, and discretionary data. Full track data is classified as SAD and must never be stored after authorisation.
A POS terminal reads track data during a magnetic-stripe swipe to build the authorisation request. The data must be purged from memory immediately after the transaction completes.
One of the world's largest payment card networks and a founding member of the PCI SSC. Visa operates the VisaNet transaction processing network and enforces PCI DSS compliance through its Visa Global Compliance Programme. Visa's merchant levels are: Level 1 (over 6 million transactions/year), Level 2 (1–6 million), Level 3 (20,000–1 million e-commerce), Level 4 (under 20,000 e-commerce or up to 1 million other).
A logical network segmentation technique that groups devices on one or more LANs to communicate as if they were on the same physical network segment, regardless of their physical location. VLANs are commonly used for PCI DSS network segmentation, but VLAN alone is not sufficient — access control lists and firewall rules must enforce segmentation between VLANs.
A technology that creates an encrypted tunnel over a public network to provide secure remote access. PCI DSS requires that all remote access to the CDE uses encrypted VPN connections with multi-factor authentication. VPN solutions must use strong cryptography and should be configured to prevent split tunnelling when accessing the CDE.
An automated tool that scans systems, networks, and applications for known security vulnerabilities such as missing patches, misconfigurations, and weak credentials. PCI DSS Requirement 11.3 requires quarterly internal vulnerability scans and quarterly external scans by an ASV. High-risk and critical vulnerabilities must be remediated and rescanned.
An ASV scan of a merchant's external-facing IP addresses reveals an outdated TLS configuration, which must be remediated and rescanned before the merchant can pass.
A security solution that filters, monitors, and blocks HTTP/HTTPS traffic to and from a web application. A WAF protects against attacks such as SQL injection, XSS, and CSRF. PCI DSS Requirement 6.4 requires either a WAF or an equivalent automated solution to detect and prevent web-based attacks against public-facing web applications.
An HTTP callback mechanism where a payment provider sends real-time event notifications (e.g., payment completed, refund issued) to a merchant's server endpoint. Webhooks that include cardholder data or payment details must be received over TLS and validated using signatures or shared secrets to prevent spoofing. Webhook endpoints are part of PCI DSS scope if they process or transmit CHD.
A security model based on the principle of "never trust, always verify" — no user, device, or network is inherently trusted regardless of location. Zero trust architectures enforce continuous authentication, micro-segmentation, and least-privilege access. While PCI DSS does not mandate zero trust, its principles closely align with PCI DSS v4.0's emphasis on continuous validation and targeted risk analysis.