Call Us
The PCI DSS requirements are 12 security controls set by the PCI Security Standards Council (PCI SSC) for any organisation that stores, processes, or transmits payment card data. They sit under six goals: secure networks, protected account data, vulnerability management, access control, monitoring and testing, and security policy. The current version is PCI DSS v4.0.1, and every one of its requirements has been mandatory since 31 March 2025.
The 12 PCI DSS requirements, in the Council's order, are:
- Install and Maintain Network Security Controls
- Apply Secure Configurations to All System Components
- Protect Stored Account Data
- Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks
- Protect All Systems and Networks from Malicious Software
- Develop and Maintain Secure Systems and Software
- Restrict Access to System Components and Cardholder Data by Business Need to Know
- Identify Users and Authenticate Access to System Components
- Restrict Physical Access to Cardholder Data
- Log and Monitor All Access to System Components and Cardholder Data
- Test Security of Systems and Networks Regularly
- Support Information Security with Organizational Policies and Programs
PCI DSS compliance means meeting every requirement that applies to your environment and proving it through the validation method your acquirer or payment brand expects.
Key Highlights
- Twelve requirements, six goals: The structure has stayed stable across versions, but the detail inside each requirement has grown.
- v4.0.1 is the current standard: The Council published it on 11 June 2024 as a limited revision of v4.0. v4.0 itself retired on 31 December 2024.
- Future-dated items are now live: The PCI DSS 4.0.1 requirements that were once "best practice until 31 March 2025", such as MFA for all access into the cardholder data environment, are now mandatory.
- Validation depends on your situation: Your PCI DSS compliance levels, set by payment brands and acquirers, decide whether you complete a Self-Assessment Questionnaire (SAQ) or a Report on Compliance (ROC).
- PCI DSS is not an Indian law: However, RBI directions make it mandatory for payment aggregators and sit alongside separate card-data storage rules.
- Gateways and tokenisation reduce exposure, not responsibility: Your scope shrinks only if your payment architecture genuinely keeps card data away from your systems.
Introduction
Most teams meet PCI DSS the same way. An acquirer, an enterprise customer, or an auditor asks for an Attestation of Compliance, and nobody is sure where to begin.
The standard looks intimidating because it is long. Underneath, though, it asks a simple question: if someone attacked the systems that touch your customers' card data, which controls would stop them, and could you prove those controls work?
This guide answers that question requirement by requirement. You will see what each of the 12 PCI DSS requirements demands, what changed between v4.0 and v4.0.1, and how SAQs and ROCs differ. You will also see how PCI DSS and RBI rules fit together for Indian businesses, why organisations fail assessments, and what gateways and tokenisation really change. A practical PCI DSS compliance checklist sits in the middle, ready to use with your own team.
Whether you are a security manager, an IT lead, or preparing for your first assessment, could this be the exact resource that transforms your team’s compliance chaos into complete alignment? Read on to find out!
What Are the 12 PCI DSS Requirements?
PCI DSS, short for Payment Card Industry Data Security Standard, is a technical and operational standard that protects payment account data. The PCI SSC maintains it. American Express, Discover, JCB, Mastercard, and Visa founded the Council in 2006. The standard applies to any entity that stores, processes, or transmits cardholder data, and to any system that could affect the security of that data.
The PCI DSS requirements list above gives the official titles. Each requirement then breaks into numbered sub-requirements, such as 3.5.1, that assessors test one at a time. The sections below explain what the 12 PCI DSS requirements mean in practice.
First, a few terms will make everything else easier.
- Cardholder data (CHD) is the primary account number (PAN), plus the cardholder name, expiry date, and service code when they appear with the PAN.
- Sensitive authentication data (SAD) is the data used to authenticate a cardholder: full track data, card verification codes such as CVV2, and PINs or PIN blocks.
- Account data covers both CHD and SAD.
- The cardholder data environment (CDE) is every system, person and process that stores, processes or transmits account data, plus systems that connect to or could affect them.
The next table shows what the standard allows you to store once a payment is authorised. It explains why so many requirements focus on the PAN and why SAD gets the strictest treatment.
| Data element | Storage after authorisation | Condition |
| PAN | Permitted | Must be rendered unreadable wherever stored |
| Cardholder name, expiry date, service code | Permitted | Must be protected in line with the standard |
| Full track data, card verification code, PIN or PIN block | Not permitted | Applies even if encrypted |
Build and Maintain a Secure Network and Systems
The first goal covers the foundations. If the network is open and the servers run on default settings, nothing built on top of them can be trusted.
Requirement 1: Install and Maintain Network Security Controls
Network security controls (NSCs) decide which traffic can reach your payment systems. They include firewalls, cloud security groups, virtual network rules, and similar tools. Version 4.0 replaced the older "firewall" wording so that cloud and software-defined networks clearly fall under this requirement.
You must define and document NSC rules, deny any traffic that has no business purpose, and review rulesets at least every six months. You also need accurate network diagrams and data-flow diagrams that show where account data travels. Without them, you cannot define scope, and every later requirement suffers.
A common failure looks like this. A team opens a cloud security group to "any" during troubleshooting and never closes it. Six months later, an assessor finds it.
Requirement 2: Apply Secure Configurations to All System Components
Attackers routinely try vendor default accounts and passwords first. Requirement 2 therefore asks you to change or disable defaults before a system goes live, including on network devices, databases, payment terminals, and wireless access points.
You also need documented configuration standards for each system type, based on industry-accepted hardening guidance such as CIS Benchmarks. Disable services you do not need. Keep one primary function per system, or isolate functions through virtualisation. In addition, encrypt all non-console administrative access.
The practical test is simple: could a new server join the environment with default settings? If yes, your build process needs work.
Protect Account Data
This goal contains the requirements most people picture when they think of card security. It controls what you keep and how you protect it, both at rest and in transit.
Requirement 3: Protect Stored Account Data
The safest card number is one you never store. Requirement 3 starts there. You need a data retention policy that keeps account data only as long as a business, legal, or regulatory need exists, plus a process that securely deletes it afterwards.
SAD cannot be stored after authorisation, even in encrypted form. Wherever you do store a PAN, you must render it unreadable using strong cryptography with proper key management, truncation, tokens or keyed hashes. When you display a PAN, show only what staff genuinely need. The standard allows at most the first six and last four digits.
Version 4.0 tightened several details:
- Plain hashes no longer qualify for protecting a PAN. They must be keyed cryptographic hashes (3.5.1.1).
- Disk-level or partition-level encryption alone is no longer enough for most storage situations (3.5.1.2).
- Technical controls must block copying or relocating PAN when staff use remote-access tools, unless a business need is documented (3.4.2).
Key management matters as much as encryption. You must generate, store, rotate, and retire keys securely, and limit who can access them.
Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks
When card data crosses the internet, public Wi-Fi, cellular networks, or satellite links, anyone in the path can try to read it. Requirement 4 asks you to protect that data with strong cryptography and secure protocols; in practice, current versions of TLS.
Version 4.0 added two points that catch teams out. You must keep an inventory of the trusted keys and certificates that protect transmissions, and you must confirm each certificate is valid and has not expired. In addition, you must never send an unprotected PAN through end-user messaging such as email, chat, or SMS.
For example, support agents sometimes ask customers to email a card number. That single habit can bring an entire mailbox system into scope.
Maintain a Vulnerability Management Program
Security weaknesses appear constantly. This goal makes sure you find and fix them before an attacker does. A consistent risk assessment method helps here, because teams must rank vulnerabilities by severity and decide what to fix first.
Requirement 5: Protect All Systems and Networks from Malicious Software
Requirement 5 expects anti-malware controls on all systems commonly affected by malware. They must stay current, run periodic scans or continuous behavioural monitoring, and resist tampering by ordinary users. Teams also need to scan removable media when someone connects it.
The most notable v4.0 change is anti-phishing. Since 31 March 2025, organisations must deploy mechanisms that detect and protect personnel against phishing attacks (5.4.1). Where you decide a system is "not at risk" from malware, you must document that conclusion through a targeted risk analysis and re-evaluate it periodically.
Requirement 6: Develop and Maintain Secure Systems and Software
This requirement covers patching, secure development, and web-facing protections. Critical security patches must be applied within one month of release. You must also identify new vulnerabilities from reputable sources and rank them by risk.
For in-house or custom software, you need a secure development lifecycle, code review before release, change control, and separate environments for development, testing, and production. Live PANs must not appear in pre-production systems. Version 4.0 also added an inventory of bespoke and third-party software components (6.3.2).
Two newer controls deserve attention for any business with an online checkout:
- Public-facing web applications need an automated technical solution that detects and prevents web-based attacks, such as a web application firewall (6.4.2).
- Payment page scripts must be inventoried, authorised, and checked for integrity (6.4.3). This responds to skimming attacks that inject malicious JavaScript into checkout pages.
Implement Strong Access Control Measures
Once the technical foundations exist, the next question is who can reach card data and how you verify them.
Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know
People should access only what their job requires. Requirement 7 asks you to define roles, assign access by role, and apply least privilege, with a default of "deny all" for access not explicitly granted.
Version 4.0 added a six-monthly review of all user accounts and their privileges (7.2.4). It also extended control to application and system accounts (7.2.5), which often hold broad permissions and go unreviewed for years.
Requirement 8: Identify Users and Authenticate Access to System Components
Every user needs a unique ID, so every action traces back to one person. Shared accounts break that link and rarely survive an assessment.
Version 4.0 raised authentication standards considerably:
- Passwords: a minimum of 12 characters where the system supports it (8.3.6).
- Password-only authentication: change passwords at least every 90 days, unless you use continuous risk-based analysis (8.3.9).
- MFA: required for all access into the CDE, not only for administrators (8.4.2), and for remote access to the network (8.4.3).
- System and application accounts: interactive login must be prevented, and credentials must not be hard-coded in scripts or configuration files without protection (8.6).
Multi-factor authentication systems must also resist replay attacks, which is often handled with a nonce or one-time value, and misconfiguration (8.5.1). A poorly set up MFA tool can fail an assessment as easily as having none.
Requirement 9: Restrict Physical Access to Cardholder Data
Physical access to servers, paper records, and payment terminals can expose card data as surely as a network attack. Requirement 9 asks for facility entry controls, visitor management, secure media handling, and controlled destruction of media you no longer need.
Point-of-interaction (POI) devices need special care. You must keep an up-to-date list of devices, inspect them periodically for tampering or substitution, and train staff to spot suspicious behaviour. Retailers and restaurants with many terminals feel this one most.
Cloud-hosted businesses can usually rely on their provider's Attestation of Compliance for data-centre controls. They still need to document which party is responsible for what.
Regularly Monitor and Test Networks
Controls decay. Monitoring and testing show you when they have.
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data
Audit logs let you reconstruct what happened during an incident. You must log all access to system components and cardholder data, link each event to an individual user, synchronise system clocks and protect logs from alteration.
Retain audit log history for at least 12 months, with the most recent three months immediately available for analysis (10.5.1). Review logs and security events regularly. Version 4.0 requires automated mechanisms to support that review (10.4.1.1).
Since 31 March 2025, every entity must also detect, alert on, and respond to failures of critical security controls, including firewalls, anti-malware, access controls, and logging itself (10.7.2). A silent logging failure is a gift to an attacker, and this requirement closes that gap.
Requirement 11: Test Security of Systems and Networks Regularly
Requirement 11 covers the testing routine:
- Wireless: detect and identify authorised and unauthorised wireless access points at least quarterly (11.2.1).
- Vulnerability scans: run internal and external scans at least once every three months. An Approved Scanning Vendor (ASV) must perform external scans. Authenticated internal scanning is now required (11.3.1.2).
- Penetration testing: test internally and externally at least annually and after significant changes. Include segmentation testing if you use segmentation to reduce scope (11.4).
- Intrusion detection and prevention: monitor traffic at the perimeter and at critical points inside the CDE.
- Change and tamper detection: alert on unauthorised changes to critical files and to HTTP headers and scripts on payment pages (11.5.2 and 11.6.1).
In practice, this requirement produces the most evidence, so schedule it early and keep every report.
Maintain an Information Security Policy
Requirement 12: Support Information Security with Organizational Policies and Programs
The last requirement ties everything together. It asks for a security policy that you review at least once a year, and that staff acknowledges. It also asks for defined roles, a formal risk assessment, and targeted risk analyses wherever the standard lets you choose how often to perform an activity (12.3.1).
Several parts of Requirement 12 demand specific, repeatable work:
- Scope: document and confirm PCI DSS scope at least every 12 months and after significant changes (12.5.2).
- Awareness: Train staff at hire and at least annually ,Structured PCI awareness training can cover this for non-technical teams. including training on phishing and social engineering (12.6.3.1).
- Third-party service providers (TPSPs): keep a list, hold written agreements, It became popular through Intercom as an alternative to the classic user story.monitor their compliance status annually, and document which requirements each party manages (12.8). Service providers must acknowledge their responsibility in writing (12.9).
- Incident response: maintain a plan, test it annually, train responders, and cover alerts from payment page tamper detection (12.10).
Governance work like this overlaps with broader security frameworks. Professionals who want a wider foundation often build it through CISSP certification, which covers security governance and risk management in depth.
Teams that want a structured way to turn these 12 requirements into daily practice often start with PCI DSS certification training, which walks through the standard, scoping, and assessment preparation.
PCI DSS Requirements Checklist
A PCI DSS compliance checklist works best as a review tool before an assessment, not as a replacement for the standard. Use it to find gaps early, assign owners, and decide what evidence to collect. Each row maps back to the PCI DSS requirements explained above.
| Area | What to verify | Evidence to keep | Req. |
| Scope | You know every system and process that touches account data, and scope was confirmed in the last 12 months | Scope document, data-flow diagrams, asset inventory | 1, 12 |
| Network controls | Rulesets deny unneeded traffic and were reviewed within six months | Ruleset exports, review sign-offs | 1 |
| Configuration | Vendor defaults are removed, and hardening standards exist for each system type | Build standards, scan results | 2 |
| Stored data | You keep account data only as long as needed, and SAD is never stored after authorisation | Retention policy, data discovery results | 3 |
| PAN protection | Stored PANs are unreadable, and keys are managed under documented procedures | Encryption settings, key custodian records | 3 |
| Transmission | TLS protects PAN in transit, and a certificate inventory exists | Protocol scans, certificate list | 4 |
| Malware and phishing | Anti-malware is active and anti-phishing controls are deployed | Console reports, email security settings | 5 |
| Patching and code | Critical patches are applied within one month, and web applications have automated protection | Patch reports, WAF configuration | 6 |
| Payment pages | Scripts are inventoried and authorised, and tamper detection runs | Script inventory, alert logs | 6, 11 |
| Access | Roles follow least privilege and accounts were reviewed in the last six months | Access review records | 7 |
| Authentication | Unique IDs and MFA protect all access into the CDE | MFA configuration, user lists | 8 |
| Physical security | Entry controls work, and POI devices are inventoried and inspected | Visitor logs, device inspection records | 9 |
| Logging | Logs are retained for 12 months, and failures of security controls raise alerts | Log retention settings, alert samples | 10 |
| Testing | Quarterly scans, annual penetration tests, and segmentation tests are complete | ASV reports, penetration test reports | 11 |
| Policy and vendors | Policies are current, staff are trained, and TPSP responsibilities are documented | Policy versions, training records, responsibility matrix | 12 |
Two habits make this PCI DSS requirements checklist more useful. First, assign a named owner to every row. Second, collect evidence continuously rather than the week before the assessor arrives.
What Changed in PCI DSS v4.0 and v4.0.1?
Teams often mix up the two versions, so it helps to separate them. Version 4.0 introduced the major changes. Version 4.0.1 then clarified and corrected that text without adding or removing requirements.
| Date | Event |
| 31 March 2022 | PCI SSC publishes PCI DSS v4.0 |
| 31 March 2024 | v3.2.1 retires |
| 11 June 2024 | PCI SSC publishes v4.0.1 as a limited revision |
| 31 December 2024 | v4.0 retires |
| 31 March 2025 | Future-dated requirements become mandatory |
| June to July 2026 | PCI SSC runs a request-for-comments period on v4.0.1 |
As of mid-2026, no newer version has replaced v4.0.1. Because the Council has opened feedback on the next iteration, check the PCI SSC document library before you plan a long project around today's text.
What v4.0 Introduced
Version 4.0 changed how the standard works, not just what it lists. It added more than 60 new requirements, and most carried a deadline of 31 March 2025. The biggest shifts were:
- A customised approach: Organisations can meet a requirement's stated objective through their own controls instead of the defined method. This route demands a documented targeted risk analysis and extra assessor testing. It also does not apply to entities completing an SAQ.
- Targeted risk analysis: Many requirements now let you set your own frequency for an activity, provided you justify it through analysis.
- Wider MFA: Authentication moved from administrator and remote access to every access into the CDE.
- Stronger passwords: The minimum length rose to 12 characters.
- Client-side protection: New requirements address scripts on payment pages.
- Business-as-usual emphasis: The standard pushes organisations to treat security as continuous work, not an annual push.
What v4.0.1 Clarified
The PCI DSS 4.0.1 requirements keep the same structure and numbering as v4.0. The revision fixed typographical errors, improved wording, and clarified applicability notes where assessors and merchants had read the text differently. It did not create a new control, so a team that complied with v4.0 faced no new work purely because of v4.0.1.
The Council also revised guidance around payment page scripts and how merchants using SAQ A should treat them. If you validate through SAQ A, read the current questionnaire carefully rather than relying on an older summary.
The practical takeaway is straightforward. Assess against v4.0.1, and treat every PCI DSS 4.0.1 requirement, including the former future-dated ones, as in force today.
PCI DSS Compliance Levels and Validation: SAQ vs ROC
PCI DSS compliance levels do not come from the standard itself. Payment brands and acquirers define them, usually by annual transaction volume. The level then determines how you must prove compliance.
Visa's merchant levels illustrate the pattern. Other brands use similar but not identical thresholds, so confirm yours with your acquirer.
| Merchant level | Typical criteria (Visa) | Typical validation |
| Level 1 | More than 6 million Visa transactions a year, or designated by a brand | Annual ROC, quarterly ASV scans, Attestation of Compliance |
| Level 2 | 1 million to 6 million Visa transactions a year | Annual SAQ, quarterly ASV scans where applicable, Attestation of Compliance |
| Level 3 | 20,000 to 1 million Visa e-commerce transactions a year | Annual SAQ, quarterly ASV scans where applicable, Attestation of Compliance |
| Level 4 | Fewer than 20,000 e-commerce transactions, or up to 1 million transactions through other channels | SAQ or as directed by your acquirer |
Service providers have their own levels, and the highest tier usually requires an annual ROC. Because these rules vary, the right validation path depends on your circumstances and on the requirements of your payment brands and acquirer. Two organisations of similar size can follow different paths.
What Is an SAQ?
A Self-Assessment Questionnaire (SAQ) is a validation tool that lets eligible organisations assess their own compliance and record the results. You complete the questionnaire, sign an Attestation of Compliance (AOC), and submit both to your acquirer or payment brand on request.
The questionnaire you use depends on how you accept payments:
| SAQ | Typical fit |
| A | Card-not-present merchants that fully outsource payment processing to a validated third party |
| A-EP | E-commerce merchants whose website affects payment security but who outsource processing |
| B and B-IP | Merchants using imprint machines or standalone terminals (dial-out or IP-connected) |
| C-VT | Merchants entering transactions manually into a virtual terminal on an isolated computer |
| C | Merchants with payment applications connected to the internet |
| P2PE | Merchants using a validated point-to-point encryption solution |
| SPoC | Merchants using commercial off-the-shelf devices with a validated PCI SPoC solution |
| D (merchant and service provider) | Everyone who does not qualify for another SAQ |
Eligibility rules are strict. If you answer "yes" to one SAQ's criteria but your setup also stores PAN somewhere, you may need SAQ D instead. Check each questionnaire's eligibility criteria on the PCI SSC site.
What Is a ROC?
A Report on Compliance (ROC) is a detailed assessment report written by a Qualified Security Assessor (QSA), or by a qualified Internal Security Assessor (ISA) where the payment brands allow it. The assessor tests each applicable requirement, interviews staff, reviews configurations, and documents the evidence. A ROC runs far deeper than an SAQ, and it ends with an AOC signed by an authorised officer.
Expect a ROC if you are a Level 1 merchant, a large service provider, or an organisation your acquirer specifically requires to undergo an assessment. A ROC also tends to suit businesses that want independent assurance for enterprise customers.
Who Determines the Required Validation Method?
The PCI SSC writes the standard and runs the assessor programmes, but it does not enforce compliance or decide who validates how. Simpliaxis offers the SAFe POPM Certification Training for Product Owners and Product Managers. They set the level, the SAQ or ROC requirement, and any deadlines.
In practice, ask your acquirer or payment service provider three questions: which level you fall under, whether they accept an SAQ, and which version of the standard they expect you to use. Then document the answers. That record settles most disputes later.
PCI DSS and RBI Requirements: What Indian Businesses Should Know
Indian businesses face two separate sets of rules. PCI DSS is a global industry standard, while the Reserve Bank of India (RBI) regulates payment entities under Indian law. The two overlap, but neither automatically replaces the other.
| Aspect | PCI DSS | RBI requirements |
| Issuing body | PCI Security Standards Council | Reserve Bank of India |
| Legal nature | Industry standard enforced through contracts with acquirers and card brands | Binding directions under the Payment and Settlement Systems Act, 2007, for regulated entities |
| Primary scope | Security of cardholder data across any organisation that handles it | Authorisation, governance, data storage limits, tokenisation and security for payment system participants |
| Compliance mechanism | SAQ or ROC, scans, Attestation of Compliance | Authorisation, audits, reporting and supervisory review |
| Relationship | Often named by RBI as a required control for specific entities | Adds obligations that PCI DSS does not cover |
Three RBI developments matter most.
Payment aggregator rules: RBI issued the Regulation of Payment Aggregators Directions, 2025 on 15 September 2025. They apply to bank and non-bank payment aggregators, and they expect compliance with cybersecurity standards that include PCI DSS, along with regular audits and vulnerability assessments. Entities that hold or plan to hold an RBI authorisation should read the directions themselves, not a summary.
Limits on storing card data: RBI barred entities in the payment chain, other than card issuers and card networks, from storing actual card data, and it required them to purge data stored earlier. After several extensions, the deadline reached 30 September 2022. Merchants therefore cannot keep full card numbers on their own systems for convenience, even if they are fully PCI DSS compliant. RBI's tokenisation guidance does permit limited data, such as the last four digits and the card issuer's name, for tracking transactions.
Card-on-file tokenisation: RBI allows tokenisation services from card networks and card issuers acting as token service providers. Customers must consent, and merchants use tokens in place of stored card numbers.
For an Indian merchant, the sensible approach is to treat the two as complementary. PCI DSS compliance shows that your environment protects card data. RBI rules decide what you may store and which entities may perform which roles. Separately, the Digital Personal Data Protection Act, 2023 may apply to other personal data you collect, so involve legal counsel.
Common Reasons Organisations Fail PCI DSS Assessments
The Council does not publish a ranked list of failures, and assessor reports differ by industry. Still, the same causes appear repeatedly across practitioner write-ups and assessor experience. Most of them are process problems, not missing technology.
An inaccurate scope: If data-flow diagrams miss a system that stores a PAN, every control around it is untested. Assessors often find the gap through a call-recording tool, a log file, or an old export folder.
Weak evidence: Teams may do the work but fail to document it. A quarterly firewall review with no sign-off, or a training session with no attendance record, counts as not done.
Point-in-time compliance: An organisation passes in March, drifts through the year and struggles in October when the next assessment starts. Version 4.0's business-as-usual emphasis targets exactly this pattern.
Access-control weaknesses: Shared accounts, stale user accounts, over-broad application accounts, and MFA gaps appear again and again. Since MFA now covers all access into the CDE, a missing second factor on one jump server can fail a requirement.
Missed vulnerability and testing deadlines: Failed external ASV scans, penetration tests that skip segmentation testing, and critical patches that miss the one-month window all cause findings.
Inadequate monitoring: Teams collect logs but never review them, or they do not notice when a security tool stops working. Requirement 10 asks for both.
Unclear third-party responsibility: Many organisations assume a vendor covers a requirement and never confirm it. Requirement 12 asks you to document who manages each control.
Unmanaged payment pages: Third-party scripts on checkout pages go unlisted, unauthorised, and unmonitored. Requirements 6.4.3 and 11.6.1 now target this.
The fix for most of these is the same. Assign owners, calendar recurring tasks, store evidence as you create it, and run an internal mock assessment about three months before the real one.
PCI DSS, Payment Gateways and Tokenisation: What Changes?
Payment gateways and tokenisation can shrink your PCI DSS scope. They do not remove your obligations. How much they help depends on your payment architecture and on who handles card data at each step.
How Your Integration Model Affects Scope
| Integration model | What reaches your systems | Typical SAQ | What stays with you |
| Full redirect to a hosted payment page | No card data | SAQ A, if eligible | Vendor management, protecting your redirect and site |
| Hosted fields or iframe from the provider | No card data, but your page loads the provider's script | SAQ A or A-EP, depending on design and eligibility | Page security, script control, vendor management |
| Your own form posting to the gateway | Card data passes through your page or server | SAQ A-EP or D | Most technical requirements for those systems |
| Direct API with your servers handling the PAN | Full card data | SAQ D | Almost the full standard |
The SAQ column describes typical outcomes only. Your acquirer and the questionnaire's eligibility criteria make the final call.
Here is a simple, hypothetical example. A small online retailer moves from its own checkout form to the gateway's hosted fields. Card numbers no longer touch the retailer's servers, so its assessment shrinks considerably. However, the retailer must still secure its website, manage the gateway as a third-party service provider, collect the gateway's AOC and respond to an incident if the checkout page is compromised.
Tokenisation and Encryption Are Not the Same
Tokenisation replaces a PAN with a surrogate value, called a token, that has no usable meaning outside the system that issued it. Encryption, in contrast, transforms the PAN in a way that anyone with the key can reverse.
The difference matters for scope. Systems that hold only tokens and that cannot retrieve the PAN may fall outside the scope of Requirement 3. The token vault itself remains fully in scope for whoever operates it. Encrypted PANs stay in scope wherever the keys are accessible.
In India, card-network tokens add another layer. Under RBI's framework, merchants store tokens issued through the card networks instead of card numbers. That serves RBI's storage restrictions, but it does not by itself complete your PCI DSS validation.
What Does Not Change
Using a gateway or tokens does not remove these responsibilities:
- Validating compliance as your acquirer requires, usually through an SAQ.
- Managing the provider under Requirements 12.8 and 12.9, including a written responsibility matrix.
- Securing any system that could affect payment security, including your website and the scripts it loads.
- Controlling any place card data can still appear, such as support emails, call recordings, and logs.
Treat the provider's own AOC as an input, not a conclusion. It tells you what the provider covers, and it should also show what remains your job.
Conclusion
The 12 PCI DSS requirements form a logical sequence. You secure the network and systems, protect account data, manage vulnerabilities, control access, monitor and test, and run it all under clear policy. Version 4.0.1 keeps that structure, and every requirement, including the former future-dated ones, now applies.
Three practical points are worth carrying forward. First, define your scope accurately, because every other decision depends on it. Second, confirm your validation path with your acquirer instead of assuming it. Third, remember that gateways and tokenisation reduce exposure but never replace documented responsibility.
For Indian organisations, keep RBI rules and PCI DSS side by side. Return to the PCI DSS compliance checklist earlier in this guide as a recurring review, not a one-time exercise. Professionals who want structured preparation can also explore Simpliaxis's PCI DSS training alongside broader security study.
Lowest-Price Challenge
Personalized Path
.webp){kind=small}
USA 
Canada 
India 
UK 
Australia 
Singapore 
