PCI DSS (Payment Card Industry Data Security Standard) is an actionable framework for developing a robust payment account data security process, including prevention, detection, and appropriate reaction to security incidents. It was developed to encourage and enhance payment account data security and facilitate the broad adoption of consistent data security measures globally.
1. Build and Maintain a Secure Network and Systems
- Req 1: Install and maintain network security controls
- Req 2: Apply secure configurations to all system components
2. Protect Account Data
- Req 3: Protect stored account data
- Req 4: Protect cardholder data with strong cryptography during transmission over open, public networks
3. Maintain a Vulnerability Management Program
- Req 5: Protect all systems and networks from malicious software
- Req 6: Develop and maintain secure systems and software
4. Implement Strong Access Control Measures
- Req 7: Restrict access to system components and cardholder data by business need to know
- Req 8: Identify users and authenticate access to system components
- Req 9: Restrict physical access to cardholder data
5. Regularly Monitor and Test Networks
- Req 10: Log and monitor all access to system components and cardholder data
- Req 11: Test security of systems and networks regularly
6. Maintain an Information Security Policy
- Req 12: Support information security with organizational policies and programs
Defined Approach
TraditionalThe traditional method. Entity implements controls that meet stated requirements; assessor follows defined testing procedures. Best for those wanting clear direction or who already have controls in place. Compensating Controls are an option here when legitimate technical or business constraints prevent meeting a requirement as written.
Customized Approach
FlexibleAllows entities to implement innovative controls that meet the Customized Approach Objective without strictly following the defined requirement. Intended for risk-mature entities. The assessor develops unique testing procedures. Compensating Controls are NOT an option with this approach.
| Category | Data Element | Can Store? | Must Render Unreadable? |
|---|---|---|---|
| Cardholder Data (CHD) | |||
| CHD | Primary Account Number (PAN) | Yes — minimized per Req 3.2 | Yes — per Req 3.5 |
| CHD | Cardholder Name | Yes — minimized per Req 3.2 | No |
| CHD | Service Code | Yes — minimized per Req 3.2 | No |
| CHD | Expiration Date | Yes — minimized per Req 3.2 | No |
| Sensitive Authentication Data (SAD) — CANNOT be stored post-authorization | |||
| SAD | Full Track Data (magnetic stripe / chip equivalent) | NEVER post-auth | Yes — if stored pre-auth |
| SAD | Card Verification Code (CVV/CVC/CAV2/CID) | NEVER post-auth | Yes — if stored pre-auth |
| SAD | PIN / PIN Block | NEVER post-auth | Yes — if stored pre-auth |
- PAN — Embossed on front, stored on magnetic stripe (tracks 1 & 2) and chip
- Cardholder Name — Embossed on front
- Expiration Date — Embossed on front
- Service Code — On magnetic stripe (3-digit code defining card usage rules)
- Magnetic Stripe — Full track data on back (tracks 1 & 2) — SAD, NEVER store post-auth
- Chip — Equivalent of magnetic stripe data in chip form — SAD, NEVER store post-auth
- CVV2/CVC2/CAV2/CID — Security code on back (or front for Amex CID) — SAD, NEVER store post-auth
When displaying PAN, only the first six digits and last four digits may be displayed. The middle digits must be masked (e.g., 4111 11xx xxxx 1111). This applies to all displays — screen, paper, receipts, logs.
- Encryption — Changes plaintext into ciphertext using a cryptographic key
- Decryption — Changes ciphertext back into plaintext using the key
- Key Management — Req 3.6 and 3.7 require secure key management covering the entire key lifecycle: generation, distribution, storage, retirement, and destruction
- Strong Cryptography — Required for PAN storage (Req 3.5) and transmission (Req 4.2). Legacy protocols are not acceptable.
- The Cardholder Data Environment (CDE) — all system components, people, and processes that store, process, or transmit CHD/SAD
- System components that do not store CHD/SAD but have unrestricted connectivity to CDE components
- System components, people, and processes that could impact the security of CHD/SAD (e.g., authentication servers, remote access servers, logging servers)
Entities must annually confirm PCI DSS scope by identifying all account data locations and flows, and all connected/potentially-impacting systems. This includes backup/recovery sites and failover systems. Documentation must be retained for assessor review and the next scope confirmation. This is separate from the assessor's scoping confirmation performed during the assessment.
What Is a TPSP?
Know ThisAny entity that stores, processes, or transmits cardholder data on behalf of a customer, or manages in-scope system components on their behalf. Using a compliant TPSP does NOT make the customer PCI DSS compliant, and does NOT remove the customer's responsibility for their own compliance.
Requirement 12.8 — Managing TPSP Relationships
Annual- Perform due diligence before and during the TPSP relationship
- Have appropriate agreements in place with all TPSPs
- Identify which PCI DSS requirements apply to the customer vs. which apply to the TPSP
- Monitor TPSP compliance status at least annually
- Important: Req 12.8 only requires monitoring status — the TPSP does NOT need to be PCI DSS compliant for the customer to meet Req 12.8
TPSP Compliance Evidence (Req 12.9)
Provide on Request- If a TPSP has an AOC — they are expected to provide it to customers upon request
- If a TPSP does NOT have an AOC — they must provide specific evidence related to applicable PCI DSS requirements so customers/assessors can confirm compliance
- Customers and TPSPs must clearly define which requirements each party is responsible for and which are shared
Security controls must be maintained on an ongoing basis — not just during assessments. Key BAU practices include:
- Monitor security controls for effectiveness on an ongoing basis
- Detect and respond to security control failures in a timely manner
- Review environment changes (new systems, config changes) for PCI DSS scope impact before completion
- Review scope impact after organizational structure changes (mergers, acquisitions)
- Periodic reviews to confirm requirements remain in place and personnel follow secure processes
- Annual review of hardware and software technologies to confirm continued vendor support and compliance with PCI DSS
SAQ — Self-Assessment Questionnaire
Eligible MerchantsAlternate validation tool for merchants eligible to conduct self-assessments. Different SAQ types apply based on environment: SAQ-A (fully outsourced e-commerce), SAQ-B (imprint/standalone), SAQ-P2PE (validated P2PE), SAQ-D (catch-all, 300+ questions). Contact your acquiring bank or payment brands to determine eligibility.
ROC — Report on Compliance
Large MerchantsDetailed report documenting PCI DSS assessment results. More detailed than SAQs — includes entity environment info, assessor samples, and how each requirement was assessed. Mandatory for QSAs to use for any PCI DSS assessment documented in a ROC. Produced by the QSA.
AOC — Attestation of Compliance
All EntitiesDeclaration of PCI DSS assessment results, completed and signed by the entity and the QSA (if involved). Reflects results documented in an associated ROC or SAQ. Service providers with an AOC are expected to provide it to customers upon request.
QSA — Qualified Security Assessor
PCI SSC QualifiedIndependent security organizations qualified by PCI SSC to assess and validate PCI DSS adherence. Their role: verify technical information, use independent judgment, provide support during compliance, adhere to testing procedures, validate scope, evaluate compensating controls, and produce the final report.
ISA — Internal Security Assessor
InternalEmployees of PCI-qualified ISA sponsor companies trained to improve PCI DSS understanding, facilitate QSA interactions, and enhance quality/consistency of self-assessments.
ASV — Approved Scanning Vendor
Quarterly ScansQualified by PCI SSC to perform external vulnerability scanning. Required quarterly for applicable merchants. To pass: no CVSS score ≥4.0 and no PCI DSS violations in scan results. CVSS 7.0–10.0 = High Severity Fail; 4.0–6.9 = Medium Severity Fail; 0.0–3.9 = Low Severity Pass.
PCIP — Payment Card Industry Professional
Your CertFoundational PCI SSC credential demonstrating professional knowledge of PCI SSC standards and supporting materials. Required for Arrow Payments TSMs and CSMs within Year One.
QIR — Qualified Integrator & Reseller
Your CertPCI SSC trained integrators and resellers who address critical security controls while installing merchant payment systems. Reduces merchant risk by focusing on the most common causes of payment data breaches. Required for Arrow Payments TSMs within Year One.
Tap any card to flip it.
PCI DSS v4.x Knowledge Test
50 questions covering the 12 requirements, account data types, scope, assessment process, TPSPs, validation approaches, and key PCI concepts. Questions randomized each attempt.