SOC 2 रिपोर्ट कैसे प्राप्त करें

Paul Gillet के अनुसार · अपडेट किया गया 2026-10-17

यदि कोई ग्राहक पूछता है कि "क्या आप SOC 2 compliant हैं?", तो वह असल में SOC 2 रिपोर्ट माँग रहा होता है: AICPA के attestation standards के तहत जारी, आपके controls पर एक स्वतंत्र CPA फ़र्म की राय। SOC 2 का कोई प्रमाणपत्र नहीं होता और न ही कोई पासिंग अंक होता है। रिपोर्ट आपके सिस्टम, आपके controls और ऑडिटर के परीक्षणों का वर्णन करती है, और ग्राहक की सुरक्षा टीम इसे पढ़कर तय करती है कि अपना डेटा आप पर भरोसा करके सौंपा जाए या नहीं।

रिपोर्ट में क्या शामिल है

SOC 2 आपके controls को AICPA के Trust Services Criteria (2017, जिनके points of focus 2022 में संशोधित हुए) के आधार पर जाँचता है। इसकी पाँच श्रेणियाँ हैं:

• Security (सामान्य criteria, CC1–CC9): हमेशा शामिल। इसमें governance, जोखिम मूल्यांकन, निगरानी, logical और physical access, संचालन, change management और vendor जोखिम आते हैं।
• Availability (A1): क्षमता, backups और recovery। यदि ग्राहक आपकी uptime पर निर्भर हैं तो इसे जोड़ें।
• Confidentiality (C1): गोपनीय जानकारी की पहचान और उसका निपटान। ग्राहक डेटा रखने वाले B2B उत्पादों में आम।
• Processing Integrity (PI1): प्रसंस्करण का पूर्ण, सटीक और समय पर होना। भुगतान, payroll और data-processing सेवाओं के लिए प्रासंगिक।
• Privacy (P1–P8): व्यक्तिगत जानकारी की सूचना, सहमति, प्रतिधारण और प्रकटीकरण। कुछ ही security frameworks इसे कवर करते हैं; GDPR इसके सबसे निकट है।

अधिकांश पहली रिपोर्टों में केवल Security, या Security के साथ Availability और Confidentiality शामिल होते हैं। श्रेणियाँ डिफ़ॉल्ट रूप से नहीं, बल्कि तभी जोड़ें जब ग्राहक माँगें, क्योंकि हर श्रेणी के साथ चलाने के लिए नए controls और जुटाने के लिए नए साक्ष्य जुड़ते हैं।

Type I या Type II?

• Type I रिपोर्ट बताती है कि आपके controls एक तय तारीख पर उचित रूप से डिज़ाइन किए गए थे और लागू थे। यह जल्दी मिल जाती है, और जब डील इंतज़ार नहीं कर सकती तो पहले कदम के रूप में उपयोगी है।
• Type II रिपोर्ट बताती है कि आपके controls एक अवधि भर डिज़ाइन और प्रभावी रूप से संचालित हुए, आमतौर पर 3 से 12 महीने। अधिकांश ग्राहकों की vendor-risk टीमें वास्तव में यही चाहती हैं, क्योंकि इससे दिखता है कि controls व्यवहार में काम करते हैं।

एक सामान्य रास्ता यह है: तैयार होते ही एक Type I, फिर 3 से 6 महीने की अवधि वाली पहली Type II, और उसके बाद 12 महीने की अवधि वाली वार्षिक Type II रिपोर्टें।

चरण

1. दायरे में सिस्टम परिभाषित करें: वह उत्पाद या सेवा जो ग्राहक खरीदते हैं, साथ में उसके पीछे का infrastructure, लोग, प्रक्रियाएँ और डेटा। इसे उतना ही रखें जितना ग्राहक भरोसा करते हैं; सीमित दायरा चलाने में सस्ता और समझाने में आसान होता है।
2. Criteria चुनें: Security के साथ वे श्रेणियाँ जो आपके ग्राहक माँगते हैं।
3. Criteria के आधार पर तैयारी मूल्यांकन चलाएँ। यदि आप पहले से कोई अन्य फ़्रेमवर्क अपनाते हैं तो गैप विश्लेषण का उपयोग करें, फिर CPA फ़र्म या किसी सलाहकार से पुष्टि करें।
4. गैप बंद करें और सब कुछ लिखित में रखें: नीतियाँ, जोखिम मूल्यांकन, access reviews, change management, vendor reviews, incident response, onboarding और offboarding, backups। ऑडिटर आप जो कहते हैं उसके मुकाबले आप जो करते हैं उसे परखते हैं, इसलिए दस्तावेज़ वास्तविकता से मेल खाने चाहिए।
5. CPA फ़र्म चुनें। केवल लाइसेंस प्राप्त CPA फ़र्में SOC 2 रिपोर्ट जारी कर सकती हैं। आपके जैसी कंपनियों के साथ अनुभव, ऑडिटरों की तकनीकी गहराई, और साक्ष्य कैसे जुटाए जाएँगे, इनकी तुलना करें।
6. वैकल्पिक Type I: ऑडिटर किसी एक समय बिंदु पर डिज़ाइन और कार्यान्वयन की जाँच करता है।
7. Type II के लिए अवलोकन अवधि चलाएँ: हर control संचालित करें और चलते-चलते साक्ष्य सुरक्षित रखें।
8. Fieldwork और रिपोर्ट: ऑडिटर अवधि से साक्ष्य का नमूना लेता है, किसी भी अपवाद पर आपसे चर्चा करता है, और रिपोर्ट जारी करता है, आमतौर पर अवधि समाप्त होने के कुछ सप्ताह बाद।
9. इसे चालू रखें: SOC 2 रिपोर्ट अतीत को कवर करती है, इसलिए ग्राहक हर साल नई रिपोर्ट की अपेक्षा करते हैं, और अवधियों के बीच कोई अंतर नहीं होना चाहिए।

विशिष्ट समयसीमा

उचित security hygiene वाली एक छोटी सॉफ़्टवेयर कंपनी के लिए तैयारी और सुधार आमतौर पर एक से तीन महीने लेते हैं, उसके तुरंत बाद Type I हो सकता है, और पहली Type II उसके तीन से छह महीने बाद आती है। बड़े दायरे, अधिक श्रेणियाँ या अपरिपक्व प्रक्रियाएँ हर चरण को लंबा करती हैं। किसी vendor के "SOC 2 कुछ हफ़्तों में" वाले वादे को Type I के बारे में वादा समझें।

ऑडिटर जिन साक्ष्यों की माँग करते हैं

Type II परीक्षण मुख्यतः नमूनाकरण पर आधारित होता है। अवलोकन अवधि से ऐसी माँगों की अपेक्षा करें:

• नए जुड़े और छोड़ने वाले कर्मचारी, इस प्रमाण के साथ कि access स्वीकृति पर दिया गया और समय पर हटाया गया;
• मुख्य सिस्टमों के लिए आवधिक user access reviews;
• change tickets, जो उत्पादन से पहले समीक्षा, परीक्षण और स्वीकृति दिखाएँ;
• vulnerability scans और penetration test परिणाम, सुधार के साथ;
• जोखिम मूल्यांकन और प्रबंधन द्वारा उसकी समीक्षा;
• महत्वपूर्ण आपूर्तिकर्ताओं के लिए vendor due-diligence रिकॉर्ड;
• incident tickets, और incident response परीक्षण का साक्ष्य;
• backup और restore परीक्षण, तथा monitoring alerts के साथ फ़ॉलो-अप;
• security awareness प्रशिक्षण रिकॉर्ड और हस्ताक्षरित नीतियाँ।

जिन बातों में लोग चूक जाते हैं

• Subservice organisations: आपके cloud provider के controls आपके नहीं हैं। अधिकांश रिपोर्टें carve-out पद्धति अपनाती हैं: आप provider को सूचीबद्ध करते हैं, उसकी अपनी SOC 2 रिपोर्ट पर निर्भर रहते हैं, और दिखाते हैं कि आप उसकी समीक्षा करते हैं।
• Complementary user entity controls: रिपोर्ट उन controls को सूचीबद्ध करती है जिन्हें ग्राहकों को स्वयं संचालित करना होता है, जैसे अपने users का प्रबंधन। इन्हें व्यावहारिक बनाएँ।
• अपवाद: Type II में अपवाद (विफल नमूने) हो सकते हैं और फिर भी रिपोर्ट उपयोगी रहती है। उन्हें छिपाने के बजाय अपनी management response में स्पष्ट रूप से समझाएँ।
• Scope creep: दायरे में हर सिस्टम को अवधि के हर दिन हर control पूरा करना होता है।

यह साइट कैसे मदद करती है

ControlMapping हर SOC 2 criterion को उन अन्य फ़्रेमवर्कों से जोड़ता है जिन्हें वह कवर करता है, ताकि आप देख सकें कि मौजूदा काम कितना आगे ले जाया जा सकता है। Criterion का पाठ AICPA का कॉपीराइट है, इसलिए हम अपने एक-पंक्ति के सारांश दिखाते हैं, और हर SOC 2 लिंक ControlMapping का संपादकीय निर्णय है, जिसका कारण भी दिया गया है: AICPA के अपने मैपिंग खुले तौर पर लाइसेंस प्राप्त नहीं हैं। इसका उपयोग योजना बनाने के लिए करें, ऑडिट साक्ष्य के रूप में नहीं।

क्या आपके पास पहले से कोई और फ़्रेमवर्क है?

SOC 2 की कितनी आवश्यकताएँ उन फ़्रेमवर्क से मैप होती हैं जिन्हें आप पहले से मानते हो सकते हैं। आवश्यकता-दर-आवश्यकता सूची के लिए गैप रिपोर्ट खोलें।

क्रॉसवॉक प्रकाशित क्रॉसवॉक (NIST, ENISA, CIS, PCI SSC) यह संबंध बनाता है · संपादकीय जहाँ कोई क्रॉसवॉक मौजूद नहीं है वहाँ ControlMapping का निर्णय; कारण दिखाया गया है · ढीले तौर पर संबंधित केवल एक CSF 2.0 परिणाम साझा करता है: जाँचने योग्य है, मैपिंग नहीं · हमारे डेटा में कोई मैपिंग नहीं हमारे डेटा में कुछ भी मैप नहीं है; अक्सर यह नया काम होता है, पर कवरेज नोट्स जाँच लें. गिनती उसी डेटा से आती है जिससे गैप विश्लेषण बनता है; मैपिंग का अर्थ है संबंधित आवश्यकताएँ, इस बात का प्रमाण नहीं कि एक दूसरे को संतुष्ट करती है।

प्रश्न

क्या SOC 2 एक प्रमाणन है?

नहीं। SOC 2 रिपोर्ट एक attestation है: आपके controls पर CPA फ़र्म की राय। कोई भी व्यक्ति "SOC 2 certified" नहीं होता, हालाँकि यह वाक्यांश आम है।

क्या मुझे SOC 2 Type I या Type II चाहिए?

अधिकांश ग्राहक Type II माँगते हैं, क्योंकि यह परखता है कि controls एक अवधि भर संचालित हुए या नहीं। यदि कोई ग्राहक Type II अवधि चलने के दौरान इसे स्वीकार करे, तो Type I एक उचित पहला कदम है।

क्या SOC 2 कानूनन अनिवार्य है?

नहीं। यह एक बाज़ार की अपेक्षा है, मुख्यतः अमेरिकी ग्राहकों की vendor-risk प्रक्रियाओं से। अनुबंध इसे आपके लिए अनिवार्य बना सकते हैं।

यह कानूनी या अनुपालन सलाह नहीं है। इस पर भरोसा करने से पहले आधिकारिक पाठ और अपने ऑडिटर, मूल्यांकनकर्ता या नियामक से जाँच लें।