मुख्य सामग्री पर जाएँ

भारत में SaaS data residency: localization और cloud region चुनना

Cloud region चुनने से पहले SaaS data, backup और access locations map करें; DPDP transfer नियमों और sector-specific localization दायित्वों की जाँच करें।

इस मार्गदर्शिका में

भारत में SaaS के लिए data residency का क्या अर्थ है?

Data residency बताती है कि data कहाँ store या process होता है; data sovereignty बताती है कि उस पर कौन-से कानून या authority लागू हो सकते हैं। केवल cloud region चुनना पूरा उत्तर नहीं है। Production database, object storage, replica, backup, logs, telemetry, support access और subprocessors map करें, फिर वास्तविक service और customer पर लागू नियम तय करें।

Personal, payment और operational data अलग-अलग map करें

Data class, purpose, व्यक्ति, service component, subprocessor, location और retention दर्ज करें। Primary record के साथ search index, cache, log, analytics, support ticket, crash report, backup और disaster recovery copy भी जोड़ें। Pseudonymized या encrypted field भी data-location commitment में आ सकती है—यह data और contract की परिभाषा पर निर्भर है।

Storage, processing, access और replication को अलग रास्ते मानें

हर cloud service के लिए primary copy, replica, backup, support staff access और operational metadata की location लिखें। Region में processing, दूसरे देश से remote access और वहाँ रखी replica अलग बातें हैं; पता करें कि law, contract या customer promise इनमें किसे सीमित करता है।

Cloud region label से अकेले कानूनी अनुपालन न मानें

Services की regional availability, control plane, support path और replication अलग हो सकते हैं। Service-specific location documentation पढ़ें, configuration देखें और contract से मिलाएँ। Encryption confidentiality में मदद करता है, लेकिन अपने-आप data location की शर्त पूरी होने का प्रमाण नहीं है।

Data location और transfer map
Data class और purposeStorage तथा processing servicesPrimary, replica और backup locationsRemote access और subprocessorsRule/contract तथा evidence owner
Account और profile data
Payment या transaction data
Logs, analytics और support data

भारत के data नियमों के तहत SaaS team क्या जाँचे?

DPDP Act की धारा 16 को पूरा कानूनी संदर्भ देकर पढ़ें

धारा 16 केंद्र सरकार को किसी Data Fiduciary द्वारा processing के लिए personal data के transfer को सरकार द्वारा अधिसूचित देश या क्षेत्र तक सीमित करने की शक्ति देती है। यह अन्य भारतीय कानूनों को भी बनाए रखती है जिनमें अधिक सुरक्षा या transfer restriction हो। केवल इस धारा को हर भारतीय user का data भारत में ही रखने की blanket शर्त न बताएं।

अधिक सीमित localization वाले sector नियम जाँचें

RBI का payment-system data निर्देश संबंधित authorized या approved payment-system providers और payment-system data पर लागू होता है; सेवा प्रदाताओं की लागू व्यवस्थाएँ भी दायरे में आ सकती हैं। इसे हर SaaS product या सभी personal data पर लागू न मानें। कंपनी या customer की regulated भूमिका और वास्तविक activity पहचानें, फिर सलाह लें।

Commencement, rules, notifications और contract promises की पुष्टि करें

DPDP Act और 2025 Rules में commencement के लिए अधिसूचित चरणबद्ध समयरेखा है। Compliance दावा करने से पहले संबंधित तारीख पर प्रभावी प्रावधान, बाद की notifications, sector directions और customer contracts जाँचें। India-only storage का sales promise लागू सामान्य कानून से अधिक कठोर हो सकता है।

Data location strategy कैसे बनाएँ और verify करें?

Resilience और transfer सीमा दोनों ध्यान में रखकर location चुनें

Allowed primary और recovery regions map करें; backups, replicas, queue payloads और logs भी उसी सीमा में हैं या नहीं जाँचें। Single region location control सरल कर सकता है पर recovery लक्ष्य प्रभावित हो सकते हैं। Multi-region resilience बढ़ाता है पर transfer path बनाता है जिसकी समीक्षा जरूरी है। Trade-off लिखें और legal, security तथा service owners से अनुमोदन लें।

निर्णय को configuration और contract controls में बदलें

जहाँ उपलब्ध हों, provider location policy, account separation, backup rules और infrastructure tests इस्तेमाल करें। Service-region inventory, subprocessor list, data-processing terms, retention नियम और नया transfer approve करने की प्रक्रिया रखें। Vendor से product-specific evidence लें; provider के पास Indian region होना हर service artifact की location साबित नहीं करता।

Architecture या vendor बदलने पर location दोबारा जाँचें

Production data नए analytics, AI, support, observability, backup या security service में भेजने से पहले समीक्षा करें। Region और replication की configuration का evidence test करें। Provider feature, subprocessor, customer commitment या law बदलने पर map अपडेट करें और हर assumption का owner व review date रखें।

भारत में SaaS data residency के सवाल

क्या DPDP Act हर SaaS company को सभी personal data भारत में रखने को कहता है?

धारा 16 स्वयं सरकार द्वारा अधिसूचित देशों में transfer पर रोक लगाने की व्यवस्था देती है और अधिक कठोर अन्य कानूनों को बनाए रखती है। यह अकेले हर SaaS के लिए universal India-only storage नियम नहीं बताती। वर्तमान notifications, commencement, sector law, contract और service की भूमिका जाँचें।

क्या Indian cloud region चुनना data residency साबित करता है?

नहीं। हर service की storage, backup, replication, support, telemetry और subprocessors देखें। Product के अनुसार locations और control paths अलग हो सकते हैं; वास्तविक configuration तथा data class का evidence रखें।

इस बिंदु के स्रोत: Data Residency and Hybrid Cloud Lens

क्या payment-system localization और DPDP transfer नियम एक ही हैं?

नहीं। RBI का payment-system data निर्देश अलग और sector-specific है। इसे असंबंधित SaaS records तक फैलाने के बजाय जाँचें कि वह entity और payment activity पर लागू होता है या नहीं।

क्या encryption cross-border transfer की चिंता समाप्त कर देता है?

अपने-आप नहीं। Encryption exposure घटा सकता है, लेकिन लागू नियम के तहत transfer, storage location, remote access या contract promise फिर भी मायने रख सकते हैं। Counsel से data, keys, access और सटीक कानूनी दायित्व की समीक्षा कराएँ।