PCI DSS v4 क्या है, और कार्ड से भुगतान लेने वाले बिज़नेस के लिए इसका क्या मतलब है?
लेखक Kumar Shanu · प्रकाशित · 7 मिनट में पढ़ें
कानूनी, टैक्स या निवेश सलाह नहीं।
PCI DSS कार्ड इंडस्ट्री का सुरक्षा मानक है, जो हर उस संस्था पर लागू है जो कार्डहोल्डर डेटा को स्टोर, प्रोसेस या ट्रांसमिट करती है, या उसकी सुरक्षा पर असर डाल सकती है। Version 4.0 मार्च 2022 में प्रकाशित हुआ और जून 2024 में सीमित संशोधन 4.0.1 ने उसकी जगह ली, जो 1 जनवरी 2025 से एकमात्र समर्थित संस्करण है। Version 4 ने 64 नई ज़रूरतें जोड़ीं; इनमें से 51, 31 मार्च 2025 तक सिर्फ़ बेस्ट प्रैक्टिस थीं और अब अनिवार्य हैं। ज़्यादातर छोटे मर्चेंट कार्ड डेटा को अपने सिस्टम से दूर रखकर और एक सेल्फ़-असेसमेंट प्रश्नावली भरकर नियमों का पालन करते हैं।
भारतीय निर्यातक या फ्रीलांसर हैं? Payzoplus आपको विदेश से भुगतान रुपये में दिलाता है।मुफ़्त अकाउंट खोलें →
इस पेज पर
PCI DSS क्या है?
Payment Card Industry Data Security Standard को PCI Security Standards Council (PCI SSC) तय करती है। काउंसिल इसे पेमेंट अकाउंट डेटा की सुरक्षा के लिए बनाई गई तकनीकी और ऑपरेशनल ज़रूरतों का एक बुनियादी स्तर बताती है। यह हर उस संस्था पर लागू है जो कार्डहोल्डर डेटा या संवेदनशील ऑथेंटिकेशन डेटा को स्टोर, प्रोसेस या ट्रांसमिट करती है, या जो उस माहौल की सुरक्षा पर असर डाल सकती है जहाँ यह डेटा रहता है। इसमें मर्चेंट, प्रोसेसर, एक्वायरर, इश्यूअर और सर्विस प्रोवाइडर शामिल हैं।
PCI DSS कोई क़ानून नहीं है। इसे कॉन्ट्रैक्ट के ज़रिए लागू किया जाता है: कार्ड नेटवर्क एक्वायरर से इसकी माँग करते हैं, और एक्वायरर उन मर्चेंट से जिन्हें वे जोड़ते हैं। किसी बिज़नेस को कौन-सा वैलिडेशन और कितनी बार करना है, यह उसका एक्वायरर और कार्ड ब्रांड तय करते हैं, काउंसिल नहीं।
Version 4 में क्या बदला?
PCI DSS v3.2.1 से v4.0.1 तक
31 मार्च 2022
PCI DSS v4.0 प्रकाशित
31 मार्च 2024
v3.2.1 सेवानिवृत्त
नए असेसमेंट के लिए v4.0 एकमात्र संस्करण
11 जून 2024
v4.0.1 प्रकाशित
सीमित संशोधन: स्पष्टीकरण, कोई नई या हटाई गई ज़रूरत नहीं
31 दिसंबर 2024
v4.0 सेवानिवृत्त
v4.0.1 एकमात्र समर्थित संस्करण
31 मार्च 2025
आगे की तारीख वाली ज़रूरतें लागू
51 ज़रूरतें बेस्ट प्रैक्टिस से अनिवार्य बनीं
v3.2.1 से v4.0 तक के बदलावों के काउंसिल के सारांश में 64 नई ज़रूरतें गिनी गई हैं। इनमें से 13 तुरंत लागू हुईं और 51 "आगे की तारीख वाली" थीं: 31 मार्च 2025 तक बेस्ट प्रैक्टिस, फिर अनिवार्य। अक्टूबर 2026 तक वह छूट की अवधि कब की ख़त्म हो चुकी है, इसलिए अब हर v4 ज़रूरत असेसमेंट में गिनी जाती है।
नए नियमों के अलावा v4 ने मानक लिखने का तरीका भी बदला। ज़रूरतें उद्देश्यों के रूप में लिखी गई हैं, और कोई संस्था इनमें से कई को customized approach से पूरा कर सकती है, यानी तय तरीके (defined approach) की जगह बताए गए उद्देश्य को पूरा करने के लिए बनाया गया अपना कंट्रोल, जिसके पीछे एक टार्गेटेड रिस्क एनालिसिस हो। कई ज़रूरतों में अब संस्था किसी काम की आवृत्ति अपने टार्गेटेड रिस्क एनालिसिस से तय कर सकती है, जहाँ v3.2.1 इसे तय कर देता था। शब्दावली भी नई की गई: "firewalls and routers" अब network security controls हैं, "anti-virus" अब anti-malware है, और जहाँ ठीक हो वहाँ "cardholder data" अब account data है।
12 ज़रूरतें क्या हैं?
ढाँचा पहले के संस्करणों जैसा ही है: छह लक्ष्य और बारह मुख्य ज़रूरतें। आसान शब्दों में:
| लक्ष्य | ज़रूरत | संक्षेप में क्या माँगती है |
|---|---|---|
| सुरक्षित नेटवर्क और सिस्टम बनाना और बनाए रखना | 1 | नेटवर्क सिक्योरिटी कंट्रोल लगाएँ और बनाए रखें |
| 2 | सभी सिस्टम हिस्सों पर सुरक्षित कॉन्फ़िगरेशन लागू करें | |
| अकाउंट डेटा की सुरक्षा | 3 | स्टोर किए गए अकाउंट डेटा की सुरक्षा करें |
| 4 | खुले, सार्वजनिक नेटवर्क से गुज़रते समय कार्डहोल्डर डेटा को मज़बूत क्रिप्टोग्राफ़ी से सुरक्षित रखें | |
| कमज़ोरियों के प्रबंधन का कार्यक्रम बनाए रखना | 5 | सभी सिस्टम और नेटवर्क को मैलिशियस सॉफ़्टवेयर से बचाएँ |
| 6 | सुरक्षित सिस्टम और सॉफ़्टवेयर बनाएँ और बनाए रखें | |
| मज़बूत एक्सेस कंट्रोल लागू करना | 7 | सिस्टम हिस्सों और कार्डहोल्डर डेटा तक पहुँच सिर्फ़ ज़रूरत वालों तक सीमित रखें |
| 8 | यूज़र की पहचान करें और सिस्टम हिस्सों तक पहुँच को ऑथेंटिकेट करें | |
| 9 | कार्डहोल्डर डेटा तक भौतिक पहुँच सीमित रखें | |
| नेटवर्क की नियमित निगरानी और टेस्टिंग | 10 | सिस्टम हिस्सों और कार्डहोल्डर डेटा तक हर पहुँच को लॉग करें और उस पर नज़र रखें |
| 11 | सिस्टम और नेटवर्क की सुरक्षा को नियमित रूप से टेस्ट करें | |
| सूचना सुरक्षा नीति बनाए रखना | 12 | संगठन की नीतियों और कार्यक्रमों से सूचना सुरक्षा को सहारा दें |
कौन-सी नई ज़रूरतें सबसे ज़्यादा मायने रखती हैं?
51 आगे की तारीख वाली ज़रूरतों में से कुछ ही ज़्यादातर बिज़नेस का रोज़ का काम बदलती हैं:
- 8.4.2 — कार्डहोल्डर डेटा एनवायरनमेंट में हर पहुँच के लिए मल्टी-फ़ैक्टर ऑथेंटिकेशन, सिर्फ़ रिमोट या एडमिनिस्ट्रेटर पहुँच के लिए नहीं। v4.0.1 ने एक नोट जोड़ा कि जब सिर्फ़ फ़िशिंग-रोधी फ़ैक्टर, जैसे FIDO पासकी या सिक्योरिटी की, इस्तेमाल हों तो एनवायरनमेंट में नॉन-एडमिनिस्ट्रेटिव पहुँच के लिए MFA ज़रूरी नहीं है।
- 5.4.1 — एंटी-फ़िशिंग। स्टाफ़ को फ़िशिंग हमलों से पहचानने और बचाने की प्रक्रियाएँ और स्वचालित व्यवस्थाएँ।
- 6.4.3 — पेमेंट पेज की स्क्रिप्ट। ग्राहक के ब्राउज़र में लोड और चलने वाली पेमेंट पेज की सभी स्क्रिप्ट का प्रबंधन करें।
- 11.6.1 — पेमेंट पेज पर बदलाव और छेड़छाड़ की पहचान। ब्राउज़र को मिलते समय पेमेंट पेज के HTTP हेडर और कंटेंट में अनधिकृत बदलाव पर अलर्ट दें।
- 3.4.2 — रिमोट एक्सेस। रिमोट-एक्सेस टेक्नोलॉजी इस्तेमाल करते समय स्टाफ़ को कार्ड नंबर कॉपी करने या कहीं और ले जाने से रोकने के तकनीकी कंट्रोल।
- 12.3.1 — टार्गेटेड रिस्क एनालिसिस उन ज़रूरतों के लिए जो संस्था को अपनी आवृत्ति ख़ुद तय करने देती हैं।
पेमेंट पेज वाले दोनों नियम, 6.4.3 और 11.6.1, ई-स्किमिंग को निशाना बनाते हैं: चेकआउट पेज में डाली गई मैलिशियस स्क्रिप्ट जो ग्राहक के टाइप करते समय कार्ड का ब्योरा कॉपी कर लेती हैं। हमारी पोस्ट पासकी और FIDO बताती है कि कोई ऑथेंटिकेशन फ़ैक्टर फ़िशिंग-रोधी कैसे बनता है।
कौन-सी सेल्फ़-असेसमेंट प्रश्नावली लागू होती है?
छोटे मर्चेंट आमतौर पर Qualified Security Assessor के ऑन-साइट असेसमेंट के बजाय एक Self-Assessment Questionnaire (SAQ) से वैलिडेट करते हैं। हर SAQ में सिर्फ़ वे ज़रूरतें होती हैं जो कार्ड लेने के किसी ख़ास तरीके से जुड़ी हैं। सबसे हल्की, SAQ A, कार्ड-नॉट-प्रेज़ेंट मर्चेंट (ई-कॉमर्स, मेल या टेलीफ़ोन ऑर्डर) के लिए है जिन्होंने अकाउंट डेटा से जुड़े सभी काम PCI DSS वैलिडेटेड थर्ड पार्टी को पूरी तरह आउटसोर्स कर दिए हैं, और जो अपने सिस्टम या परिसर में कोई भी अकाउंट डेटा इलेक्ट्रॉनिक रूप से स्टोर, प्रोसेस या ट्रांसमिट नहीं करते।
30 जनवरी 2025 को काउंसिल ने SAQ A में बदलावों की घोषणा की जो 31 मार्च 2025 से लागू हुए। इसने SAQ A से ज़रूरतें 6.4.3, 11.6.1 और 12.3.1 हटा दीं, और एक पात्रता शर्त जोड़ी: मर्चेंट को पुष्टि करनी होगी कि उसकी साइट उन स्क्रिप्ट हमलों के प्रति कमज़ोर नहीं है जो उसके ई-कॉमर्स सिस्टम पर असर डाल सकते हैं। मूल ज़रूरतें PCI DSS में बनी हुई हैं; उन्हें सिर्फ़ उस प्रश्नावली से हटाया गया। SAQ A के तहत भी, मर्चेंट के अपने वेब सर्वर की सुरक्षा वाली ज़रूरतें, जैसे ज़रूरत 2, 6 और 8 के हिस्से, तब भी लागू होती हैं जब वह ग्राहकों को किसी थर्ड पार्टी पर रीडायरेक्ट करता है या थर्ड पार्टी का पेमेंट फ़ॉर्म एम्बेड करता है।
कार्ड लेने का तरीका आपका PCI दायरा कैसे बदलता है
| कार्ड डेटा आपके सिस्टम को छूता है | कार्ड डेटा पूरी तरह आउटसोर्स | |
|---|---|---|
| उदाहरण | आपके फ़ॉर्म से कार्ड नंबर आपके सर्वर पर आते हैं | होस्टेड पेमेंट पेज या एम्बेड किया गया प्रोवाइडर फ़ॉर्म |
| संभावित वैलिडेशन | बड़ा SAQ या पूरा असेसमेंट | SAQ A, अगर पात्र हों |
| पेमेंट पेज की स्क्रिप्ट | 6.4.3 और 11.6.1 पूरी तरह लागू | पुष्टि करें कि पेज स्क्रिप्ट हमलों से सुरक्षित है |
| स्टोर किए गए कार्ड नंबर | ज़रूरत 3 पूरी तरह | कोई स्टोर नहीं |
| मेहनत | ज़्यादा और लगातार | कम, लेकिन शून्य नहीं |
PCI दायरा छोटा कैसे रखें?
सबसे सस्ती ज़रूरत वह है जो लागू ही न हो। दायरा कार्ड डेटा के पीछे चलता है, इसलिए मुख्य उपाय है कार्ड नंबर को अपने सिस्टम से दूर रखना:
- होस्टेड या एम्बेड किया गया पेमेंट पेज इस्तेमाल करें जो किसी PCI DSS वैलिडेटेड प्रोवाइडर का हो, ताकि कार्ड का ब्योरा ग्राहक के ब्राउज़र से सीधे प्रोवाइडर तक जाए।
- कार्ड नंबर नहीं, टोकन स्टोर करें। बार-बार बिलिंग के लिए प्रोवाइडर का टोकन या नेटवर्क टोकन रखें। भारत में RBI के card-on-file टोकनाइज़ेशन नियम पहले से ही मर्चेंट को कार्ड नंबर स्टोर करने से रोकते हैं।
- कार्ड का ब्योरा कभी ईमेल, चैट या स्प्रेडशीट से न लें। एक भटकी हुई फ़ाइल पूरे लैपटॉप या मेलबॉक्स को दायरे में ले आती है।
- अपने चेकआउट पेज पर नज़र रखें। जिन पेज पर पेमेंट फ़ॉर्म होस्ट या एम्बेड है, वहाँ थर्ड-पार्टी स्क्रिप्ट सीमित रखें, और पता रखें कि उन्हें कौन बदल सकता है।
- पेमेंट से जुड़ी हर जगह MFA चालू करें: प्रोवाइडर डैशबोर्ड, आपकी होस्टिंग और आपकी कोड रिपॉज़िटरी।
- सबूत संभालकर रखें। आपके प्रोवाइडर का Attestation of Compliance और आपका अपना SAQ ही वह है जो एक्वायरर माँगेगा।
नेटवर्क टोकन और प्रोवाइडर वॉल्ट की तुलना नेटवर्क टोकन बनाम PCI वॉल्टिंग में है। जिन एक्सपोर्टर को कार्ड के बजाय बैंक ट्रांसफ़र से भुगतान मिलता है, उनके लिए PCI DSS का सवाल ही नहीं उठता; यह कार्ड-डेटा का मानक है।
Payzoplus आपकी कैसे मदद करता है
भुगतान की तकनीक, बिना उसे बनाए
- Payzoplus एक डैशबोर्ड और ऐप में रिसीविंग अकाउंट, इनवॉइस मिलान और आपके बैंक में सेटलमेंट देता है — शुरू करने के लिए किसी इंटीग्रेशन की ज़रूरत नहीं।
- हर भुगतान उसे भेजने वाले ग्राहक से पहले से मिला हुआ आता है, इसलिए मिलान एक कदम है, खोजबीन नहीं।
- मिलान (रिकंसाइल) करने के बाद T+1 पर रुपये आपके अपने बैंक अकाउंट में पहुँचते हैं।
कोई सेटअप फ़ीस नहीं · कोई मासिक फ़ीस नहीं · वेरिफ़िकेशन आमतौर पर एक कामकाजी दिन में
अक्सर पूछे जाने वाले सवाल
क्या भारत में PCI DSS अनिवार्य है?
PCI DSS एक इंडस्ट्री मानक है, भारतीय क़ानून नहीं। कार्ड नेटवर्क और एक्वायरर, भारत में भी और बाक़ी जगह भी, कार्ड डेटा संभालने वाले मर्चेंट और सर्विस प्रोवाइडर से कॉन्ट्रैक्ट के ज़रिए इसकी माँग करते हैं। RBI के अलग नियम, जैसे कार्ड टोकनाइज़ेशन, क़ानून के तहत लागू होते हैं।
PCI DSS का मौजूदा संस्करण कौन-सा है?
PCI DSS v4.0.1, जो जून 2024 में प्रकाशित हुआ। Version 4.0 को 31 दिसंबर 2024 को और version 3.2.1 को 31 मार्च 2024 को सेवानिवृत्त किया गया। आगे की तारीख वाली ज़रूरतें 31 मार्च 2025 को अनिवार्य हुईं।
अगर मैं पेमेंट गेटवे इस्तेमाल करता हूँ, तो क्या मुझे फिर भी PCI DSS चाहिए?
आमतौर पर हाँ, लेकिन बहुत छोटे रूप में। जो मर्चेंट कार्ड संभालने का काम पूरी तरह आउटसोर्स करता है, वह SAQ A के लिए पात्र हो सकता है, जिसमें फिर भी पेमेंट पेज पर रीडायरेक्ट करने या उसे एम्बेड करने वाली वेबसाइट की सुरक्षा जैसी बातें आती हैं। आपको क्या फ़ाइल करना है, यह आपका एक्वायरर पुष्टि करता है।
PCI DSS की ज़रूरतें 6.4.3 और 11.6.1 क्या हैं?
ई-स्किमिंग के ख़िलाफ़ v4 की दो ज़रूरतें। 6.4.3 पेमेंट पेज की हर स्क्रिप्ट के प्रबंधन की माँग करती है; 11.6.1 ब्राउज़र को मिलते समय पेमेंट पेज में अनधिकृत बदलाव पकड़ने की। दोनों 31 मार्च 2025 को लागू हुईं।
स्रोत
इस लेख को 30 अक्टूबर 2026 को इन मूल स्रोतों से जाँचा गया।
- PCI SSC — PCI DSS standard overview
- PCI SSC — PCI DSS v4.0 resource hub (published 31 March 2022)
- PCI SSC — Just Published: PCI DSS v4.0.1, 11 June 2024
- PCI SSC — Summary of Changes from PCI DSS v3.2.1 to v4.0 (May 2022)
- PCI SSC — Important updates for merchants validating to SAQ A, 30 January 2025
- PCI SSC — PCI DSS v4.0 Self-Assessment Questionnaire A
यह सामान्य जानकारी है, टैक्स, कानूनी या निवेश सलाह नहीं। नियम और प्रोडक्ट बदलते रहते हैं: अपने व्यवसाय के लिए विवरण अपने CA, बैंक या नियामक से पक्का करें।
यह लेख कितना काम का लगा?
सबसे पहले रेटिंग दें।
टिप्पणियाँ
विनम्र रहें और विषय पर बात करें। लिंक या संपर्क जानकारी वाली टिप्पणियाँ दिखने से पहले जाँची जाती हैं।