बिना ज़रूरत से ज़्यादा प्रतिबद्धता के पहली SOC 2 रिपोर्ट का दायरा तय करना
दायरा तय करता है कि SOC 2 रिपोर्ट की लागत कितनी होगी, उसमें कितना समय लगेगा और ग्राहकों के लिए वह कितनी उपयोगी होगी। पहली बार की अधिकांश गलतियाँ दायरे की गलतियाँ होती हैं, और वे पहले ही हफ़्ते में हो जाती हैं।

एक SOC 2 रिपोर्ट सिस्टम को कवर करती है: वह सेवा जो ग्राहक खरीदते हैं और उसके पीछे की हर चीज़। यह सीमा बहुत चौड़ी खींचेंगे तो आप महीनों ऐसे controls का सबूत जुटाने में लगाएँगे जिनके बारे में किसी ने पूछा ही नहीं। बहुत संकरी खींचेंगे तो रिपोर्ट ग्राहक के सवाल का जवाब नहीं देगी। पहली बार की सबसे महंगी SOC 2 गलतियाँ दायरा तय करने वाले हफ़्ते में ही होती हैं।
निर्णय 1: कौन-सा सिस्टम
उस चीज़ से शुरू करें जिसे ग्राहक खरीदते और जिस पर निर्भर रहते हैं। अधिकांश सॉफ़्टवेयर कंपनियों के लिए यह production platform होता है: एप्लिकेशन, उसका infrastructure और data stores, उन्हें बनाने और चलाने वाले लोग, और वे प्रक्रियाएँ जिनका वे पालन करते हैं। आम तौर पर दायरे से बाहर होते हैं: आंतरिक कॉर्पोरेट IT जो ग्राहक डेटा को कभी छूता नहीं, अन्य product lines, और sales systems।
सीमा जल्दी लिख लें, क्योंकि यही रिपोर्ट में system description बनती है, और हर control उसके भीतर की हर चीज़ पर, पूरी observation period के हर दिन, काम करना चाहिए।
निर्णय 2: कौन-से criteria
Security, यानी common criteria CC1 से CC9, अनिवार्य है। अन्य तभी जोड़ें जब ग्राहकों को उनकी ज़रूरत हो:
- Availability, यदि ग्राहक uptime प्रतिबद्धताओं पर निर्भर हैं।
- Confidentiality, यदि आप ऐसा ग्राहक डेटा रखते हैं जिसे गोपनीय घोषित किया गया है (अधिकांश B2B सेवाएँ)।
- Processing Integrity, यदि ग्राहक आप पर अपना डेटा सही ढंग से प्रोसेस करने के लिए निर्भर हैं: payments, payroll, billing।
- Privacy, यदि आप अपने उद्देश्यों के लिए व्यक्तिगत जानकारी प्रोसेस करते हैं और ग्राहक इसकी माँग करते हैं। इसके अधिकांश criteria का security frameworks में कोई समकक्ष नहीं है, जैसा SOC 2 और ISO 27001 पर हमारा विश्लेषण दिखाता है।

निर्णय 3: subservice organisations
आपका cloud provider, payment processor या managed database provider ऐसे controls चलाता है जिन पर आप निर्भर हैं। आप इनमें से चुनते हैं:
- Carve-out (सबसे आम): उनके controls बाहर रखे जाते हैं; आप बताते हैं कि आप उन पर किस काम के लिए निर्भर हैं, और दिखाते हैं कि आप उनकी अपनी SOC 2 रिपोर्ट की समीक्षा करते हैं।
- Inclusive: उनके controls आपकी रिपोर्ट के भीतर परखे जाते हैं। इसके लिए उनका सहयोग चाहिए और बड़े providers के लिए यह दुर्लभ है।
निर्णय 4: complementary user entity controls
वे controls सूचीबद्ध करें जिन्हें ग्राहकों को आपके controls के काम करने के लिए चलाना होगा: अपने user accounts का प्रबंधन, अपनी API keys की सुरक्षा, अपने SSO का विन्यास। इन्हें यथार्थवादी और कम रखें, क्योंकि ग्राहक इन्हें पढ़ते हैं और उनकी security teams अनुचित सूची पर सवाल उठाएँगी।
निर्णय 5: Type I या Type II, और अवधि
Type I जल्दी हो जाती है; अधिकांश ग्राहक Type II चाहते हैं। पहली Type II के लिए तीन से छह महीने की अवधि आम है। अवधि तभी शुरू करें जब controls कुछ हफ़्तों से चल रहे हों, ताकि अवधि का शुरुआती हिस्सा exceptions से न भरा हो।
दायरा तय करने की checklist
अपनी CPA firm के साथ kickoff से पहले इन सवालों के जवाब तैयार रखें:
- यह रिपोर्ट किस product या service के बारे में है, और ग्राहक उस पर किस काम के लिए निर्भर हैं?
- कौन-से environments दायरे में हैं (केवल production, या staging भी)?
- कौन-से cloud accounts, regions और data stores?
- कौन-सी teams और roles इस सिस्टम को चलाते हैं?
- यह सिस्टम किन subservice organisations पर निर्भर है, और क्या आपके पास उनकी रिपोर्ट हैं?
- कौन-सी Trust Services Criteria श्रेणियाँ, और क्यों?
- ग्राहकों को चलाने होंगे वे कौन-से complementary user entity controls?
- पहले Type I, या सीधे Type II? कौन-सी अवधि?
- कौन-से मौजूदा frameworks या audits हैं जिनका evidence आप दोबारा उपयोग कर सकते हैं?
लिखित उत्तर आपकी system description का पहला मसौदा बन जाते हैं और हफ़्तों की आवाजाही बचाते हैं। यदि आपके पास पहले से ISO 27001 है, तो ISO 27001 → SOC 2 गैप रिपोर्ट अंतिम प्रश्न का उत्तर देती है।
वे दायरा-संबंधी गलतियाँ जो सबसे महंगी पड़ती हैं
- "सुरक्षा के लिए" कॉर्पोरेट IT को शामिल करना: इससे सबूत जुटाने वाले सिस्टमों की संख्या दोगुनी हो जाती है।
- Privacy या Processing Integrity इसलिए जोड़ना क्योंकि वे अच्छे लगते हैं: हर एक पूरी अवधि के लिए अतिरिक्त controls और evidence जोड़ता है।
- ऐसी system description जो वास्तविकता से मेल न खाए: auditors वही परखते हैं जो आपने लिखा है।
- controls चलने से पहले अवधि शुरू करना: पहले महीने के exceptions रिपोर्ट में बने रहते हैं।
हमारी SOC 2 गाइड पूरी प्रक्रिया कवर करती है; SOC 2 framework पेज हर criterion को उसकी मैपिंग के साथ सूचीबद्ध करता है; और यदि आपके पास पहले से कोई अन्य framework है, तो गैप विश्लेषण दिखाता है कि वह आपको कितनी दूर तक ले जाता है।
प्रश्न
SOC 2 रिपोर्ट के लिए न्यूनतम दायरा क्या है?
एक तय सिस्टम के लिए Security श्रेणी (common criteria, CC1 से CC9)। Availability, Confidentiality, Processing Integrity और Privacy वैकल्पिक हैं।
SOC 2 में carve-out क्या है?
किसी subservice organisation के controls (जैसे आपके cloud provider के data-centre controls) को अपनी रिपोर्ट से बाहर रखना, साथ ही यह बताना कि आप उस पर किस काम के लिए निर्भर हैं और उसकी निगरानी कैसे करते हैं।
2026-10-27 तक का डेटा: इस पोस्ट के आँकड़े वर्तमान क्रॉसवॉक से गणना किए गए हैं और उसके बदलने पर अपडेट होते हैं। क्रॉसवॉक प्रकाशित क्रॉसवॉक (NIST, ENISA, CIS, PCI SSC) यह संबंध बनाता है · संपादकीय जहाँ कोई क्रॉसवॉक मौजूद नहीं है वहाँ ControlMapping का निर्णय; कारण दिखाया गया है · केवल एक CSF 2.0 परिणाम साझा करता है: जाँचने योग्य है, मैपिंग नहीं · हमारे डेटा में कोई मैपिंग नहीं हमारे डेटा में कुछ भी मैप नहीं है; अक्सर यह नया काम होता है, पर कवरेज नोट्स जाँच लें. यह अनुपालन सलाह नहीं है।