PCI Secure SLC 2.0: पेमेंट सॉफ़्टवेयर को ट्रांज़िशन प्लान चाहिए

28 सितंबर 2026 को PCI SSC ने Secure Software Lifecycle Standard का वर्ज़न 2.0, यानी PCI Secure SLC 2.0, जारी किया। यह अपडेट AI समेत डिजिटल टूल्स को ध्यान में रखता है। असेसर्स की ट्रेनिंग चौथी तिमाही में होनी है; वर्ज़न 1.1 से बारह महीने का ट्रांज़िशन ट्रेनिंग उपलब्ध होने के बाद शुरू होगा, न कि स्टैंडर्ड के प्रकाशन वाले दिन अपने आप।

असल में किसका आकलन होता है

Secure SLC सॉफ़्टवेयर डेवलपमेंट के जीवन-चक्र से जुड़ा है। पेमेंट सॉफ़्टवेयर ख़रीदने वाले के लिए यह अहम फ़र्क़ है: तैयार प्रोडक्ट और उसे बनाने की प्रक्रिया जाँच के अलग-अलग विषय हैं। PCI SSC अलग से स्पष्ट करता है कि Secure SLC का आकलन और Secure Software का आकलन एक-दूसरे पर निर्भर नहीं हैं। इसलिए स्टैंडर्ड का नाम और आकलन का दायरा बताए बिना वेंडर का PCI अनुपालन का सामान्य दावा पर्याप्त जानकारी नहीं देता।

पेमेंट इंटीग्रेशन के एक अर्जेंट फ़िक्स पर विचार करें। कोड छोटा हो सकता है, लेकिन उसे सुरक्षित रूप से रिलीज़ करने के लिए लेखक की एक्सेस, बदलाव की समीक्षा, बिल्ड, रिलीज़ की अनुमति और रोलबैक की संभावना — सब अहम हैं। अगर कोई एक क़दम सिर्फ़ चैट में अनौपचारिक सहमति के रूप में मौजूद है, तो किसी घटना के बाद इतिहास दोबारा जोड़ना मुश्किल होता है। यह संपादकीय उदाहरण दिखाता है कि डेवलपमेंट प्रक्रिया का अपना स्वतंत्र महत्व क्यों है।

AI टूल्स इस कहानी में एक और हिस्सा जोड़ते हैं। टीम को समझना होगा कि टूल को कौन-सी सामग्री दी जाती है और उसका आउटपुट प्रोडक्शन प्रोडक्ट तक कैसे पहुँचता है। रिलीज़ बटन दबाने वाले व्यक्ति की मौजूदगी अपने आप बदलाव के स्रोत और उसकी समीक्षा को नहीं समझाती। यहीं से टूल्स की अद्यतन सूची और कोड के दस्तावेज़ित रास्ते का व्यावहारिक मूल्य निकलता है।

वेंडर के लिए तात्कालिक काम है मौजूदा प्रक्रिया की नए वर्ज़न से तुलना करना और असेसर से प्रोग्राम का कैलेंडर स्पष्ट करना। मर्चेंट के लिए — यह समझना कि डेवलपर के पास कौन-सी पुष्टि है और वह उसे अद्यतन कैसे रखता है। इसका मतलब हर स्टोर के लिए तुरंत नई जाँच नहीं है।

इस ख़बर में ट्रांज़िशन अवधि की शर्त को सही रूप में रखना ख़ास तौर पर ज़रूरी है। अगर ट्रेनिंग अभी उपलब्ध नहीं है, तो गिनती की शुरुआत को प्रेस रिलीज़ की सुविधाजनक तारीख़ से नहीं बदला जा सकता। सही कैलेंडर और लागू होने का दायरा नाम में 2.0 आने से ज़्यादा व्यावहारिक महत्व रखते हैं।

वेंडर्स और PSP क्या जाँचें

पेमेंट सॉल्यूशंस के डेवलपर्स और उन PSP के लिए जो ख़ुद पेमेंट पेज, SDK या इंटीग्रेशन लिखते हैं, यह ख़बर ट्रांज़िशन अवधि शुरू होने से पहले प्रक्रिया की छोटी समीक्षा का मौक़ा है।

• क्या AI असिस्टेंट समेत डेवलपमेंट टूल्स की सूची अद्यतन है और क्या नियम हैं कि उनमें कौन-सा डेटा डाला जा सकता है।
• क्या हर बदलाव, अर्जेंट फ़िक्स समेत, कोड रिव्यू और रिलीज़ की अनुमति से गुज़रता है।
• क्या बिल्ड, डिपेंडेंसीज़ का स्रोत और रिलीज़ हुए कोड का वर्ज़न इस तरह दर्ज होते हैं कि इतिहास दोबारा जोड़ा जा सके।
• क्या प्रोडक्शन एनवायरनमेंट और कार्डधारकों के डेटा तक डेवलपर्स की एक्सेस अलग-अलग है।
• क्या कोई ज़िम्मेदार व्यक्ति तय है जो ट्रांज़िशन का कैलेंडर और असेसर्स की ट्रेनिंग की समय-सीमा पर नज़र रखता है।

मर्चेंट्स के लिए इसका क्या मतलब है

मर्चेंट के लिए पेमेंट सॉफ़्टवेयर वेंडर्स से यह स्पष्ट करना उपयोगी है कि उनकी पुष्टि में कौन-सा स्टैंडर्ड और कौन-सा दायरा शामिल है, मौजूदा वैलिडेशन कब ख़त्म होता है और वेंडर ट्रांज़िशन की योजना कैसे बना रहा है। ये सवाल वेंडर्स की सालाना जाँच और अनुबंध में शामिल करने लायक़ हैं, ख़ासकर अगर इंटीग्रेशन मर्चेंट की अपनी PCI DSS आवश्यकताओं के दायरे को प्रभावित करता है। स्टैंडर्ड और दायरे के नाम के बिना "हम PCI के अनुरूप हैं" वाला जवाब अधूरा मानना और पुष्टि करने वाला दस्तावेज़ माँगना बेहतर है।

आंतरिक डेवलपमेंट टीमों के लिए पहले से सबूतों का पैकेज तैयार करना उपयोगी है: रिलीज़ प्रक्रिया का विवरण, बदलावों का लॉग और टूल्स की सूची। इसे असेसर के लिए भी इस्तेमाल किया जा सकता है और उन बड़े क्लाइंट्स को जवाब देने के लिए भी, जो सुरक्षित डेवलपमेंट की पुष्टि माँगते हैं।

स्रोत: PCI SSC Secure SLC 2.0 release; PCI Secure SLC programme overview