ऑडिट में टिकने वाला प्रयोज्यता विवरण कैसे लिखें

ISO/IEC 27001 की धारा 6.1.3(d) के लिए एक प्रयोज्यता विवरण (SoA) चाहिए: एक ऐसा दस्तावेज़ जो बताता है कि आपको कौन से नियंत्रण चाहिए, आपने उन्हें क्यों शामिल किया, वे लागू हैं या नहीं, और Annex A के 93 नियंत्रणों में से किसी को क्यों बाहर रखा। यह सुनने में प्रशासनिक लगता है। व्यवहार में यह आपके जोखिम आकलन और आपके नियंत्रणों के बीच का सेतु है, और प्रमाणन ऑडिटर इसे ध्यान से पढ़ते हैं, क्योंकि कमज़ोर SoA का अक्सर अर्थ होता है कि उसके पीछे की जोखिम प्रक्रिया भी कमज़ोर है।

इसमें क्या होना चाहिए

Annex A के हर नियंत्रण के लिए, और आपके अपने किसी भी नियंत्रण के लिए:

1. लागू है या नहीं।
2. शामिल करने का औचित्य: आमतौर पर वे जोखिम जिनका वह नियंत्रण उपचार करता है, कोई कानूनी या संविदात्मक आवश्यकता, या कोई व्यावसायिक निर्णय।
3. कार्यान्वयन की स्थिति: लागू, आंशिक रूप से लागू, या योजनाबद्ध।
4. बाहर रखने का औचित्य, यदि उसे बाहर रखा गया है।

अधिकतर SoA में हर नियंत्रण के कार्यान्वयन का एक छोटा विवरण और नीति या प्रक्रिया का संदर्भ भी जोड़ा जाता है। यह सख़्ती से आवश्यक नहीं है, लेकिन इससे ऑडिट कहीं तेज़ हो जाते हैं।

शामिल करने का औचित्य

हर नियंत्रण को किसी ठोस चीज़ से जोड़ें: आपके जोखिम रजिस्टर में कोई जोखिम, कोई कानूनी आवश्यकता (GDPR अनुच्छेद 32, NIS2, क्षेत्र-विशेष का विनियमन), कोई अनुबंध या ग्राहक की आवश्यकता। “सर्वोत्तम प्रथा” एक कमज़ोर औचित्य है; “यह जोखिम R-12 और R-17 का उपचार करता है और हमारी NIS2 बाध्यताओं के लिए आवश्यक है” एक मज़बूत औचित्य है। नियंत्रणों को कानूनी आवश्यकताओं से जोड़ना उस समय भी मदद करता है जब आप कई फ़्रेमवर्क के प्रति जवाबदेह हों: हमारे आवश्यकता पृष्ठ दिखाते हैं कि हर Annex A नियंत्रण किन अन्य फ़्रेमवर्कों से मैप होता है, जैसे A.8.24 क्रिप्टोग्राफ़ी का उपयोग।

बाहर रखने का औचित्य

बहिष्करण की अनुमति है, लेकिन हर बहिष्करण के लिए ऐसा कारण चाहिए जिसे ऑडिटर जाँच सकें। अच्छे कारण:

• गतिविधि दायरे में होती ही नहीं। कोई आउटसोर्स्ड डेवलपमेंट नहीं: A.8.30 बाहर रखा गया।
• जोखिम दायरे में मौजूद ही नहीं है। पूरी तरह रिमोट संगठन, जिसका कोई कार्यालय नहीं, कुछ A.7 भौतिक नियंत्रणों को बाहर रख सकता है, लेकिन उन्हें नहीं जो उपकरण और मीडिया से संबंधित हैं, चाहे वे कहीं भी हों।

कमज़ोर कारण: “प्रासंगिक नहीं”, “IT देखती है”, “क्लाउड प्रदाता यह करता है”। यदि कोई आपूर्तिकर्ता कोई नियंत्रण लागू करता है, तो वह फिर भी लागू है; आप उसे आपूर्तिकर्ता नियंत्रणों के माध्यम से प्रबंधित करते हैं।

ऑडिट में आने वाली आम कमियाँ

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

एक व्यावहारिक ढाँचा

हर नियंत्रण के लिए एक पंक्ति: ID और शीर्षक, लागू है (हाँ/नहीं), कारण (जोखिम, कानूनी और संविदात्मक आवश्यकताएँ), स्थिति, यह कैसे किया जाता है इसका एक-पंक्ति विवरण, स्वामी, और साक्ष्य का संदर्भ। इसे स्प्रेडशीट में या दस्तावेज़ नियंत्रण के अधीन अपने GRC टूल में रखें, और हर जोखिम आकलन के साथ इसकी समीक्षा करें।

SoA को जीवित रखना

पहले प्रमाणन के लिए लिखा गया और फिर कभी न छुआ गया SoA अगले ऑडिट में एक कमी बन जाता है। इसे चालू रखने के लिए इसे हर बार अपडेट करें जब:

• जोखिम आकलन चुने गए नियंत्रण बदल दे;
• दायरा बदले (नया उत्पाद, कार्यालय या क्लाउड प्रदाता);
• किसी नियंत्रण की कार्यान्वयन स्थिति बदले;
• कोई नई कानूनी या संविदात्मक आवश्यकता लागू हो (उदाहरण के लिए NIS2 या किसी ग्राहक का अनुबंध)।

हर बार संस्करण, तिथि और अनुमोदक दर्ज करें।

मुख्य बातें

• हर Annex A नियंत्रण पर एक निर्णय और एक कारण चाहिए, बहिष्करण सहित।
• शामिल करने को विशिष्ट जोखिमों और कानूनी या संविदात्मक आवश्यकताओं से जोड़ें।
• SoA को जोखिम उपचार योजना के साथ सुसंगत और अद्यतन रखें।

एक साथ कई फ़्रेमवर्क

यदि आप SOC 2, NIS2 या PCI DSS के प्रति भी जवाबदेह हैं, तो हर एक के लिए मिलती-जुलती आवश्यकताओं का कॉलम जोड़ें। तब SoA एक साझा नियंत्रण समूह की रीढ़ बन जाता है; हमारी पोस्ट SOC 2 और ISO 27001 के लिए एक नियंत्रण समूह इस दृष्टिकोण को दिखाती है, और गैप विश्लेषण हर Annex A नियंत्रण को किसी भी अन्य फ़्रेमवर्क के सामने सूचीबद्ध करता है। ISO 27001 गाइड प्रमाणन के बाक़ी पहलू कवर करती है।

प्रश्न

क्या ISO 27001 में Annex A के नियंत्रणों को बाहर रखा जा सकता है?

हाँ, यदि बहिष्करण का औचित्य सिद्ध हो, आमतौर पर तब जब जोखिम आपके दायरे में मौजूद ही न हो (उदाहरण के लिए, आउटसोर्स्ड डेवलपमेंट, जब आप डेवलपमेंट आउटसोर्स नहीं करते)। बहिष्करणों का औचित्य प्रयोज्यता विवरण में दर्ज करना अनिवार्य है।

प्रयोज्यता विवरण में क्या होना चाहिए?

ISO 27001 की धारा 6.1.3(d) के अनुसार आवश्यक नियंत्रण, उन्हें शामिल करने का औचित्य, यह कि वे लागू हैं या नहीं, और किसी भी Annex A नियंत्रण को बाहर रखने का औचित्य आवश्यक है।

क्या प्रयोज्यता विवरण ग्राहकों के साथ साझा किया जाता है?

आमतौर पर पूरा नहीं; यह एक आंतरिक दस्तावेज़ है जिसकी समीक्षा प्रमाणन निकाय करता है। कुछ संगठन NDA के तहत ग्राहकों के साथ सारांश साझा करते हैं ताकि दिखाया जा सके कि कौन से नियंत्रण लागू होते हैं।