ISO 27001, SOC 2 और HIPAA के लिए एक जोखिम मूल्यांकन
ISO 27001, SOC 2 और HIPAA, तीनों एक जोखिम मूल्यांकन से शुरू होते हैं। अगर इसे तीनों ऑडिटरों के सवालों का जवाब देने के लिए डिज़ाइन किया गया हो, तो आपको सिर्फ़ एक की ज़रूरत है।
यह पोस्ट उन 11 फ़्रेमवर्कों को कवर करती है जिन्हें इसके लिखे जाने के समय ControlMapping ने मानचित्रित किया था। तब से DORA, CPS 234, Cyber Essentials को 2026-10-27 पर जोड़ा गया है; उनके पृष्ठ और कवरेज मैट्रिक्स में वे शामिल हैं।

जोखिम मूल्यांकन वह जगह है जहाँ तीन सबसे आम फ़्रेमवर्क शुरू होते हैं। ISO 27001 हर चीज़ इसी पर आधारित करता है (खंड 6.1.2)। SOC 2 अपने कॉमन क्राइटेरिया का एक खंड इसी के लिए समर्पित करता है (CC3.1 से CC3.4)। HIPAA सिक्योरिटी रूल जोखिम विश्लेषण को अपना पहला अनिवार्य कार्यान्वयन विनिर्देश बनाता है (§164.308(a)(1)(ii)(A)), और HHS के जाँचकर्ता जिस पहले दस्तावेज़ का अनुरोध करते हैं, वह यही है। कई संगठन तीन अलग मूल्यांकन चलाते हैं। एक ही काफ़ी है।
हर फ़्रेमवर्क क्या जाँचता है
- ISO 27001 को एक परिभाषित, दोहराने योग्य पद्धति चाहिए जिसमें स्वीकृति के मानदंड हों; गोपनीयता, अखंडता और उपलब्धता के लिए पहचाने गए जोखिम; मालिक; संभावना और परिणाम का विश्लेषण; और जोखिम उपचार तथा Statement of Applicability से जुड़ाव।
- SOC 2 को उद्देश्य इतने स्पष्ट रूप से निर्दिष्ट चाहिए कि जोखिम पहचाने जा सकें (CC3.1), पूरी इकाई में जोखिम पहचाने और विश्लेषित किए गए हों (CC3.2), धोखाधड़ी के जोखिम पर विचार हुआ हो (CC3.3), और बदलावों का मूल्यांकन हुआ हो (CC3.4)।
- HIPAA को ePHI के लिए जोखिमों और कमज़ोरियों का सटीक और व्यापक मूल्यांकन चाहिए, चाहे ePHI कहीं भी बनाया, प्राप्त, संग्रहित या प्रेषित होता हो; यह अद्यतन रहना चाहिए और उसके बाद जोखिम प्रबंधन होना चाहिए (§164.308(a)(1)(ii)(B))।
हमारे डेटा में ये आवश्यकताएँ सीधे जुड़ी हैं:
| फ़्रेमवर्क | जोखिम मूल्यांकन | लिंक |
|---|---|---|
| NIST CSF 2.0 | ID.RA-03ID.RA-04ID.RA-05ID.RA-06 | विषय परिभाषा |
| ISO 27001 | Clause 6.1.2Clause 6.1.3 | क्रॉसवॉक |
| CIS v8.1 | — | हमारे डेटा में कोई मैपिंग नहीं |
| SOC 2 | CC3.2CC3.4CC3.3 | संपादकीय |
| PCI DSS | 12.3.1 | क्रॉसवॉक |
| CMMC | RA.L2-3.11.1 | क्रॉसवॉक |
| 800-53 | RA-3RA-7 | क्रॉसवॉक |
| HIPAA | §164.308(a)(1)(ii)(A) | क्रॉसवॉक |
| GDPR | Art.35(1)Art.35(7) | संपादकीय |
| NIS2 | 2.1 | क्रॉसवॉक |
| Essential Eight | — | हमारे डेटा में कोई मैपिंग नहीं |
पूर्ण विवरण और हर संबंध का कारण: फ़्रेमवर्क में जोखिम मूल्यांकन →
तीनों के लिए एक मूल्यांकन की रूपरेखा
- सब कुछ कवर करने के लिए दायरा तय करें: ISMS का दायरा, SOC 2 सिस्टम और ePHI का हर स्थान। दर्ज करें कि कौन-सी संपत्तियाँ किस फ़्रेमवर्क के अंतर्गत आती हैं।
- एक पद्धति अपनाएँ: संपत्ति या परिदृश्य आधारित, संभावना और प्रभाव के पैमाने, स्वीकृति मानदंड और मालिकों के साथ। ISO की दस्तावेज़ित, दोहराने योग्य पद्धति की आवश्यकताएँ सबसे सख़्त हैं, इसलिए उन्हें पूरा करें।
- फ़्रेमवर्क-विशिष्ट संकेत जोड़ें: धोखाधड़ी का जोखिम (SOC 2 CC3.3), ePHI-विशिष्ट खतरे और कमज़ोरियाँ (HIPAA), और कानूनी व संविदात्मक जोखिम।
- हर जोखिम को उपचार से जोड़ें: चुने गए नियंत्रण, अवशिष्ट जोखिम, मालिक की स्वीकृति। यही एक तालिका ISO Statement of Applicability, SOC 2 की नियंत्रण गतिविधियों और HIPAA के जोखिम प्रबंधन को पोषित करती है।

ऐसे परिणाम जो तीनों जाँचकर्ताओं को संतुष्ट करें
- पद्धति, स्वीकृत।
- मालिकों, स्कोर और उपचार निर्णयों वाला एक जोखिम रजिस्टर।
- तारीखों वाली एक जोखिम उपचार योजना।
- अवशिष्ट जोखिम की मालिकों द्वारा स्वीकृति।
- कम से कम वार्षिक और किसी महत्वपूर्ण बदलाव के बाद समीक्षा का प्रमाण।
एक सरल जोखिम रजिस्टर प्रारूप
हर जोखिम के लिए एक पंक्ति तीनों फ़्रेमवर्क के लिए काम करती है:
| फ़ील्ड | उदाहरण |
|---|---|
| जोखिम | रैनसमवेयर उत्पादन डेटाबेस को एन्क्रिप्ट कर देता है |
| संपत्तियाँ | उत्पादन डेटाबेस, बैकअप, ePHI स्टोर |
| फ़्रेमवर्क | ISO 27001, SOC 2, HIPAA |
| संभावना और प्रभाव | संभव, गंभीर |
| मौजूदा नियंत्रण | MFA, EDR, रात्रिकालीन बैकअप |
| उपचार | बैकअप को अलग करें; रिस्टोर का परीक्षण हर तिमाही करें |
| मालिक | इंफ्रास्ट्रक्चर प्रमुख |
| अवशिष्ट जोखिम और स्वीकृति | मध्यम, CTO द्वारा स्वीकृत |
| समीक्षा तिथि | अगली तिमाही |
फ़्रेमवर्क वाला कॉलम ही असली चाल है: इससे एक रजिस्टर बिना तीन स्प्रेडशीट के तीन जाँचकर्ताओं के सवालों का जवाब दे सकता है।
मुख्य बातें
- एक पद्धति और एक रजिस्टर ISO 27001, SOC 2 और HIPAA को पूरा कर सकते हैं।
- फ़्रेमवर्क-विशिष्ट संकेत जोड़ें: धोखाधड़ी का जोखिम और ePHI के स्थान।
- कम से कम वार्षिक और किसी महत्वपूर्ण बदलाव के बाद समीक्षा करें।
सामान्य निष्कर्ष
- सामान्य जोखिम ("हैकर", "डेटा उल्लंघन") जिनका किसी विशिष्ट संपत्ति या नियंत्रण से संबंध नहीं।
- कोई मालिक नहीं, या सुरक्षा टीम हर जोखिम की मालिक।
- ePHI के स्थान छूटे हुए: एक्सपोर्ट, बैकअप, ईमेल, परीक्षण सिस्टम।
- पुराना रिकॉर्ड: पहले ऑडिट के लिए एक बार मूल्यांकन, फिर कभी नहीं।
ये फ़्रेमवर्क आपस में कैसे संबंधित हैं, इस पर अधिक जानकारी के लिए ISO 27001 बनाम HIPAA तुलना और जोखिम मूल्यांकन विषय देखें। गैप विश्लेषण किन्हीं भी दो के बीच हर मैपिंग दिखाता है।
प्रश्न
क्या HIPAA जोखिम विश्लेषण ISO 27001 जोखिम मूल्यांकन के समान है?
इनमें काफ़ी ओवरलैप है। HIPAA के लिए ePHI की गोपनीयता, अखंडता और उपलब्धता के जोखिमों का सटीक और व्यापक मूल्यांकन ज़रूरी है; एक ISO 27001 जोखिम मूल्यांकन, जिसके दायरे में ePHI शामिल हो और जो HIPAA-विशिष्ट तत्व दर्ज करता हो, दोनों की जगह काम आ सकता है।
जोखिम मूल्यांकन कितनी बार करना ज़रूरी है?
ISO 27001 के लिए नियोजित अंतराल पर और किसी महत्वपूर्ण बदलाव के बाद जोखिम मूल्यांकन ज़रूरी है। SOC 2 ऑडिटर आम तौर पर कम से कम वार्षिक जोखिम मूल्यांकन की अपेक्षा करते हैं। HIPAA के लिए जोखिम विश्लेषण का अद्यतन रहना ज़रूरी है।
क्या जोखिम मूल्यांकन गुणात्मक होना चाहिए या मात्रात्मक?
तीनों फ़्रेमवर्क के लिए दोनों में से कोई भी तरीका काम करता है, बशर्ते पद्धति परिभाषित हो, एक समान रूप से लागू हो और तुलनीय परिणाम दे। अधिकांश संगठन गुणात्मक तरीके से शुरू करते हैं और जहाँ निर्णयों के लिए ज़रूरत हो वहाँ संख्यात्मक आँकड़े जोड़ते हैं।
2026-10-27 तक का डेटा: इस पोस्ट के आँकड़े वर्तमान क्रॉसवॉक से गणना किए गए हैं और उसके बदलने पर अपडेट होते हैं। क्रॉसवॉक प्रकाशित क्रॉसवॉक (NIST, ENISA, CIS, PCI SSC) यह संबंध बनाता है · संपादकीय जहाँ कोई क्रॉसवॉक मौजूद नहीं है वहाँ ControlMapping का निर्णय; कारण दिखाया गया है · केवल एक CSF 2.0 परिणाम साझा करता है: जाँचने योग्य है, मैपिंग नहीं · हमारे डेटा में कोई मैपिंग नहीं हमारे डेटा में कुछ भी मैप नहीं है; अक्सर यह नया काम होता है, पर कवरेज नोट्स जाँच लें. यह अनुपालन सलाह नहीं है।