रिसोर्स · 07
थर्ड-पार्टी डिजिटल रिस्क: एक क्रिटिकल सप्लायर का असेसमेंट करें
किसी सेंसिटिव सर्विस या डेटासेट को सौंपने से पहले एविडेंस, डिपेंडेंसी, सबकॉन्ट्रैक्टर, कंटिन्यूटी और रिवर्सिबिलिटी को कनेक्ट करें।
अपडेटेड · 6 min
यह गाइड क्या पाने में मदद करती है
- काम के सप्लायर को सच में क्रिटिकल थर्ड पार्टी से अलग करें
- सेल्फ-असेसमेंट से आगे वेरिफाई करें
- डिपेंडेंसी चेन देखें
- एक वर्केबल एग्जिट तैयार करें
जल्दी से चेक करें
- अगर यह सप्लायर फेल हो जाता है तो कौन सी सर्विस बंद हो जाएगी?
- यह कौन सा डेटा पढ़ सकता है, ट्रांसफॉर्म कर सकता है या एक्सपोर्ट कर सकता है?
- कौन से सबकॉन्ट्रैक्टर ज़रूरी हैं?
- क्या रेस्टोरेशन दिखाया गया है?
- क्या डेटा को इस्तेमाल करने लायक फ़ॉर्मेट में रिकवर किया जा सकता है?
स्टेप-बाय-स्टेप तरीका
- 1
क्रिटिकैलिटी को क्लासिफ़ाई करें
हर सप्लायर को प्रोसेस, डेटा, यूज़र, ज़िम्मेदारियों और रिकवरी की डेडलाइन से कनेक्ट करें। ज़्यादा खर्च हमेशा ज़रूरी नहीं होता; एक छोटा API ज़रूरी हो सकता है।
डिलीवरेबल: सर्विस, असर और ओनर प्रोफ़ाइल।
- 2
सही सबूत मांगें
आर्किटेक्चर, एक्सेस, इंसिडेंट, बैकअप, टेस्ट, ज़रूरी सर्टिफ़िकेशन और एक्सेप्शन को टारगेट करें। अटेस्टेशन इसके स्कोप को समझने की जगह नहीं ले सकता।
डिलीवरेबल: सबूत फ़ाइल और क्लैरिफ़िकेशन पॉइंट।
- 3
चेन को मैप करें
होस्टिंग, डेटा प्रोसेसर, SaaS कंपोनेंट और ज्योग्राफ़िक डिपेंडेंसी की पहचान करें। कई सप्लायर में कॉमन कंसंट्रेशन देखें।
डिलीवरेबल: डिपेंडेंसी और कंसंट्रेशन मैप।
- 4
टेस्ट सिनेरियो
आउटेज, कॉम्प्रोमाइज़, डेटा लॉस, ओनरशिप चेंज और कॉन्ट्रैक्ट टर्मिनेशन का असेसमेंट करें। हर सिनेरियो को एक सिग्नल, डिसीजन और फ़ॉलबैक दें।
डिलीवरेबल: फेलियर सिनेरियो और कम्पेनसेटिंग उपाय।
- 5
कॉन्ट्रैक्ट और ऑपरेशन को अलाइन करें
चेक करें कि नोटिफिकेशन डेडलाइन, एविडेंस एक्सेस, सबकॉन्ट्रैक्टिंग, रिटर्न, डिलीशन और एग्जिट सपोर्ट असल में काम कर रहे हैं या नहीं।
डिलीवरेबल: कॉन्ट्रैक्ट और ऑपरेशनल कंट्रोल।
- 6
डिसाइड करें और मॉनिटर करें
ओनर के साथ एक्सेप्टेंस, रेमेडिएशन या रिजेक्शन, डेडलाइन और क्लोजर एविडेंस बताएं। बड़े बदलाव या इंसिडेंट के बाद रीअसेस करें।
डिलीवरेबल: कंडीशनल डिसीजन और मॉनिटरिंग प्लान।
काल्पनिक काम का उदाहरण
उदाहरण वाली स्थिति
एक सर्विस ऑर्डर कन्फर्म करने के लिए एक ईमेल प्रोवाइडर पर निर्भर करती है। टीम एक्सेस, ट्रांसफर किया गया डेटा, मिले अलर्ट और रुकावट का सही समय रिकॉर्ड करती है।
फैसला और उम्मीद का सबूत
प्लान में सिर्फ़ कॉन्ट्रैक्ट क्लॉज़ पर निर्भर रहने के बजाय एक एस्केलेशन कॉन्टैक्ट, एक रेस्टोरेशन चेक और एक टेस्ट करने लायक कंटिन्यूटी ऑप्शन शामिल है।
मैनेजमेंट इंडिकेटर
| इंडिकेटर | यह क्या मापता है | पहला एक्शन |
|---|---|---|
| कवरेज | मालिक और मौजूदा फ़ाइल वाले ज़रूरी सप्लायर | बिना फ़ॉलबैक वाली सर्विस को एड्रेस करना |
| सही सबूत | हाल के सबूत से सपोर्टेड ज़रूरी कंट्रोल | ऐसे आइटम रिक्वेस्ट करें जो फ़ैसला बदल सकें |
| कंसंट्रेशन | एक ही एक्टर या रीजन पर निर्भर सर्विस | एक असली विकल्प तैयार करें |
| रिवर्सिबिलिटी | सर्विस और डेटा रिकवर करने के लिए मापा गया समय और क्वालिटी | एक्सपोर्ट की तुरंत ज़रूरत होने से पहले उसे टेस्ट करना |
आम गलतियाँ
- हर सप्लायर को एक ही क्वेश्चनेयर भेजना
- सर्टिफ़िकेशन को रिस्क की कमी मानना
- सप्लायर सबकॉन्ट्रैक्टर को नज़रअंदाज़ करना
- बिना टेस्ट किए बाहर निकलने के लिए बातचीत करना
अक्सर पूछे जाने वाले सवाल
क्या हर सप्लायर का ऑडिट होना चाहिए?
नहीं। उनसे शुरू करें जिनकी नाकामी किसी ज़रूरी सर्विस, सेंसिटिव डेटा, किसी ज़िम्मेदारी या मौजूदा कंसंट्रेशन पर असर डालती है।
क्या सर्टिफ़िकेशन काफ़ी है?
नहीं। यह काम का सबूत हो सकता है, लेकिन इसका स्कोप, तारीख, एक्सक्लूज़न और आपके इस्तेमाल से इसका रिश्ता ज़रूर चेक करना चाहिए।
एक सप्लायर का कितनी बार रिव्यू किया जाना चाहिए?
बदलाव की गंभीरता और रफ़्तार के हिसाब से, और किसी घटना, एक्विजिशन, बड़े सर्विस बदलाव या मटीरियल सबकॉन्ट्रैक्टिंग बदलाव के बाद।
ऑफ़िशियल रेफ़रेंस
रेफ़रेंस इस तरीके को सपोर्ट करते हैं। अपने कॉन्टेक्स्ट के हिसाब से चेक को एडजस्ट करें; वे सर्टिफ़िकेशन नहीं हैं। ओरिजिनल रेफ़रेंस टाइटल और सोर्स डॉक्यूमेंट दूसरी भाषा में हो सकते हैं।
