जब आपके बिज़नेस का कोई मुख्य सिस्टम डाउन हो जाता है, तो सबसे मुश्किल हिस्से हैं: पहले क्या रीस्टोर करें, इसके लिए किसके पास एक्सेस है, कौन सा बैकअप विश्वसनीय है, और उस सिस्टम के बिना आपका बिज़नेस कितनी देर तक काम कर सकता है।
यहीं पे कई छोटे और मध्यम आकार के बिज़नेस (SMBs) को बैकअप रखने और असली रिकवरी प्लैन रखने के बीच का गैप दिखता है। बैकअप में वो डाटा हो सकता है जिसकी आपको ज़रूरत है, लेकिन वो रिकवरी का क्रम तय नहीं करता, ज़िम्मेदारियां असाइन नहीं करता, ये सत्यापित नहीं करता कि रीस्टोर काम करता है या नहीं, और आउटेज के दौरान एडमिन प्रमाण के गायब होने की समस्या हल नहीं करता।
IT डिज़ास्टर रिकवरी प्लैन, रुकावट आने से पहले इस प्रक्रिया को ढांचा देता है। ये तय करता है कि कौन से सिस्टम सबसे ज़्यादा ज़रूरी हैं, उन्हें कितनी जल्दी रीस्टोर करना है, बिज़नेस कितना डाटा लॉस सह सकता है, कौन सी data loss prevention स्ट्रैटेजी अपनानी है, हर रिकवरी स्टेप की ज़िम्मेदारी किसकी है, और ज़रूरी प्रमाण कैसे सुरक्षित रखे जाते हैं। ये स्पष्टता किसी IT घटना को लंबे डाउनटाइम, राजस्व के नुकसान, या बड़े ऑपरेशनल संकट में बदलने से रोक सकती है।
IT डिज़ास्टर रिकवरी प्लैन क्या है?
बिज़नेस कंटिन्यूटी बनाम IT डिज़ास्टर रिकवरी
आपके IT डिज़ास्टर रिकवरी प्लैन में क्या शामिल होना चाहिए
आपके IT डिज़ास्टर रिकवरी प्लैन को क्या तय करना होगा
प्रमाण रिकवरी: नज़रअंदाज़ किया गया डिज़ास्टर रिकवरी सिनेरियो
डिज़ास्टर रिकवरी प्लैन टेम्पलेट
अपना IT डिज़ास्टर रिकवरी प्लैन कैसे टेस्ट करें
रिकवरी को सिस्टम, डाटा, और एक्सेस के इर्द-गिर्द बनाएं
IT डिज़ास्टर रिकवरी प्लैन क्या है?
IT डिज़ास्टर रिकवरी प्लैन, रुकावट के बाद टेक्नोलॉजी सिस्टम रीस्टोर करने की एक दस्तावेज़ी प्रक्रिया है। ये बिज़नेस की IT लेयर पे फोकस करता है: डाटा, एप्लीकेशन, डिवाइस, इंफ्रास्ट्रक्चर, क्लाउड सर्विसेज़, एडमिन एक्सेस, बैकअप, और रिकवरी के लिए ज़िम्मेदार लोग।
एक व्यावहारिक IT रिकवरी प्लैन को ऐसे सवालों के जवाब देने चाहिए:
- कौन से सिस्टम पहले वापस आने चाहिए?
- बिज़नेस कितना डाउनटाइम सह सकता है?
- कितना डाटा लॉस स्वीकार्य है?
- बैकअप कहां स्टोर किया जाता है?
- सिस्टम कौन रीस्टोर कर सकता है?
- कौन से एडमिन प्रमाण ज़रूरी हैं?
- टीम कैसे पुष्टि करेगी कि रीस्टोर किए गए सिस्टम सुरक्षित और इस्तेमाल करने लायक हैं?
- अगर मुख्य चैनल डाउन हों तो बिज़नेस स्टाफ और ग्राहकों से कैसे संवाद करेगा?
डिज़ास्टर रिकवरी प्लैन सिर्फ साइबरअटैक से निपटने तक सीमित नहीं होना चाहिए: इसमें रोज़मर्रा की समस्याएं शामिल होनी चाहिए जैसे हार्डवेयर फेल्योर, खोए हुए प्रमाण, और गलती से डिलीट होना। इसमें बाहरी सर्विस रुकावटें भी शामिल होनी चाहिए जैसे क्लाउड प्लैटफॉर्म या SaaS टूल में रुकावट, गलत कॉन्फिगरेशन, और ज़रूरी कर्मचारियों का ज़रूरी एक्सेस ट्रांसफर किए बिना नौकरी छोड़ना।
रिकवरी कुछ ऐसा नहीं है जिसे आउटेज के दौरान डिज़ाइन किया जाए। इसे प्लैन किया जाना, इसकी ज़िम्मेदारी तय होना, संवादित होना, और टेस्ट होना ज़रूरी है, इससे पहले कि आपका बिज़नेस इस पे निर्भर होना शुरू करे।
बिज़नेस कंटिन्यूटी बनाम IT डिज़ास्टर रिकवरी
बिज़नेस कंटिन्यूटी और IT डिज़ास्टर रिकवरी को अक्सर एक ही चीज़ समझा जाता है, लेकिन ये अलग-अलग समस्याएं हल करते हैं।
बिज़नेस कंटिन्यूटी का मतलब है रुकावट के दौरान कंपनी को चालू रखना। इसमें क्लाइंट संवाद, अस्थायी वर्कफ्लो, स्टाफ की ज़िम्मेदारियां, सप्लायर कोर्डिनेशन, और ये फैसले शामिल हैं कि अगर सामान्य सिस्टम उपलब्ध ना हों तो भी कौन सी सर्विसेज़ चलती रहनी चाहिए।
IT डिज़ास्टर रिकवरी उस काम के पीछे की टेक्नोलॉजी पे फोकस करती है। ये तय करती है कि सिस्टम, डाटा, एप्लीकेशन, बैकअप, और एडमिन एक्सेस कैसे रीस्टोर किए जाएंगे, ताकि बिज़नेस सुरक्षित रूप से सामान्य ऑपरेशन पे वापस आ सके।
उदाहरण के लिए, CRM आउटेज को देखें। बिज़नेस कंटिन्यूटी प्लैन ये बता सकता है कि CRM डाउन होने के दौरान सेल्स या सहायता टीमें ग्राहकों की सेवा कैसे करती रहें। IT रिकवरी प्लैन ये बताता है कि वेंडर से कौन संपर्क करेगा, कौन सा डाटा रीस्टोर करना है, कौन सा बैकअप या निर्यात उपलब्ध है, कौन से प्रमाण ज़रूरी हैं, और टीम कैसे पुष्टि करेगी कि सिस्टम दोबारा इस्तेमाल के लिए सुरक्षित है।
कई SMBs के लिए, ये गैप सिर्फ किसी घटना के दौरान सामने आता है। लोग जानते हैं कि क्लाइंट्स से कौन संपर्क करेगा, लेकिन ये नहीं कि बिलिंग सिस्टम कौन रीस्टोर कर सकता है। उन्हें पता है कि बैकअप मौजूद हैं, लेकिन ये नहीं कि रीस्टोर कभी टेस्ट हुआ है या नहीं। उन्हें पता है कि IT आमतौर पर एक कर्मचारी हैंडल करता है, लेकिन ये नहीं कि वो व्यक्ति उपलब्ध ना हो तो क्या होगा, या उसके संपर्क से बाहर होने पे एडमिन पासवर्ड कहां स्टोर किया गया है।
आपके IT डिज़ास्टर रिकवरी प्लैन में क्या शामिल होना चाहिए
एक मज़बूत IT डिज़ास्टर रिकवरी प्लैन का बहुत लंबा होना ज़रूरी नहीं है, लेकिन उसे किसी तनाव वाली स्थिति के दौरान चलाने लायक स्पष्ट होना चाहिए।
रिकवरी टाइम ऑब्जेक्टिव
रिकवरी टाइम ऑब्जेक्टिव, यानी RTO, तय करता है कि किसी सिस्टम को कितनी जल्दी रीस्टोर करना है। पेमेंट सिस्टम को कुछ घंटों में वापस आना पड़ सकता है, जबकि इंटरनल रिपोर्टिंग डैशबोर्ड लंबा आउटेज सह सकता है।
RTO बिज़नेस इम्पैक्ट के हिसाब से तय करें, टेक्निकल पसंद के हिसाब से नहीं, क्योंकि डाउनटाइम की कीमत बिज़नेस और टेक्निकल, दोनों तरह की समस्या है। देखें कि कौन से सिस्टम राजस्व, ग्राहकों से किए वादों, कानूनी दायित्वों, सुरक्षा, और कर्मचारियों की प्रोडक्टिविटी को प्रभावित करते हैं।
रिकवरी पॉइंट ऑब्जेक्टिव
रिकवरी पॉइंट ऑब्जेक्टिव, यानी RPO, तय करता है कि कितना डाटा लॉस स्वीकार्य है, जिससे फिर सही data loss prevention (DLP) स्ट्रैटेजी सेट करने में मदद मिलती है। अगर किसी सिस्टम का RPO एक घंटा है, तो बैकअप या रेप्लिकेशन को लगभग उसी पॉइंट तक रिकवरी में सहायता करनी चाहिए।
अगर RPO एक दिन है, तो बिज़नेस एक बड़ा गैप स्वीकार कर रहा है। RPO बैकअप की फ्रीक्वेंसी तय करने में भी मदद करता है, क्योंकि जितना छोटा आपका RPO, उतनी ज़्यादा बार बैकअप लेना होगा। इसलिए ज़रूरी सिस्टम को कम प्रायोरिटी वाले सिस्टम की तुलना में ज़्यादा बार बैकअप की ज़रूरत होती है।
सिस्टम प्रायोरिटी टियर
हर सिस्टम को एक ही समय पे रीस्टोर नहीं किया जाना चाहिए। छोटे बिज़नेस का डिज़ास्टर रिकवरी प्लैन सिस्टम को प्रायोरिटी टियर में बांटे।
- टियर 1: कोर ऑपरेशन, सुरक्षा, संवाद, या राजस्व के लिए ज़रूरी सिस्टम।
- टियर 2: ज़रूरी सिस्टम जो छोटा डाउनटाइम सह सकते हैं।
- टियर 3: कम प्रायोरिटी वाले सिस्टम जिन्हें बिज़नेस के स्थिर होने के बाद रीस्टोर किया जा सकता है।
आम टियर 1 सिस्टम में ईमेल, पहचान प्रोवाइडर, पासवर्ड मैनेजर, फाइनेंस सिस्टम, ग्राहक डेटाबेस, क्लाउड स्टोरेज, और संवाद प्लैटफॉर्म शामिल हो सकते हैं।
बैकअप स्ट्रैटेजी
आपकी बैकअप स्ट्रैटेजी को ये तय करना चाहिए:
- किस चीज़ का बैकअप लिया जाता है और कितनी बार
- बैकअप कहां स्टोर किया जाता है
- उन्हें कौन एक्सेस कर सकता है
- रिस्टोरेशन कैसे टेस्ट किया जाता है
NCSC ने भी प्रकाशित किया है(नई विंडो) क्लाउड और ऑन-प्रिमाइसेज़ बैकअप सॉल्यूशन के लिए रैंसमवेयर-प्रतिरोधी बैकअप सिद्धांत, और बताया है कि बैकअप किया डाटा डिफॉल्ट रूप से रैंसमवेयर के प्रतिरोधी नहीं होता और रैंसमवेयर खतरे के मुकाबले उसका आकलन होना चाहिए।
एक मज़बूत बैकअप स्ट्रैटेजी में आमतौर पर ज़रूरी डाटा के लिए ऑफलाइन या इम्यूटेबल बैकअप, नियमित टेस्टिंग, दस्तावेज़ी रीस्टोर स्टेप्स, और बैकअप एडमिनिस्ट्रेशन के लिए अलग प्रमाण शामिल होते हैं।
भूमिकाएं और ज़िम्मेदारियां
डिज़ास्टर रिकवरी प्लैन में सिर्फ काम नहीं, बल्कि ज़िम्मेदार लोगों के नाम होने चाहिए। अगर रिकवरी की सारी जानकारी एक व्यक्ति के पास है, तो बिज़नेस के पास IT रिस्क के साथ-साथ लोगों का रिस्क भी है। तय करें कि कौन:
- रिकवरी का नेतृत्व करे
- सिस्टम रीस्टोर करे
- वेंडर से संपर्क करे
- इमरजेंसी एक्सेस को मंज़ूरी दे
- इंटरनल संवाद करे
- फैसलों को डॉक्यूमेंट करे
आपके IT डिज़ास्टर रिकवरी प्लैन को क्या तय करना होगा
| कंपोनेंट | ये क्या बताता है |
| RTO | हर सिस्टम को कितनी जल्दी रीस्टोर करना होता है? |
| RPO | बिज़नेस कितना डाटा खोने का जोखिम ले सकता है? |
| प्रायोरिटी टियर | कौन से सिस्टम पहले वापस आते हैं, और कौन से रुक सकते हैं? |
| बैकअप स्ट्रैटेजी | किस चीज़ का बैकअप लिया जाता है, वो कहां स्टोर किया जाता है, और क्या रिस्टोरेशन टेस्ट हुआ है? |
| भूमिकाएं और ज़िम्मेदारियां | रिकवरी का नेतृत्व कौन करता है, सिस्टम कौन रीस्टोर करता है, वेंडर से कौन संपर्क करता है, और इमरजेंसी बदलावों को कौन मंज़ूरी देता है? |
प्रमाण रिकवरी: नज़रअंदाज़ किया गया डिज़ास्टर रिकवरी सिनेरियो
डिज़ास्टर रिकवरी अक्सर डाटा, सर्वर, और बैकअप पे फोकस करती है। लेकिन असल में, रिकवरी असफल हो सकती है क्योंकि टीम उन सिस्टम को एक्सेस नहीं कर पाती जो ऑपरेशन रीस्टोर करने के लिए ज़रूरी हैं।
प्रमाण रिकवरी ये सवाल पूछती है:
- एडमिन खातों तक एक्सेस किसके पास है?
- बैकअप प्रमाण कहां स्टोर किए जाते हैं?
- कौन से खाते ज़रूरी सिस्टम रीस्टोर कर सकते हैं?
- अगर पासवर्ड खो जाए, उसकी छेड़छाड़ हो जाए, या वो किसी उपलब्ध ना होने वाले व्यक्ति के पास हो तो क्या होगा?
- क्या इमरजेंसी प्रमाण सुरक्षित हैं और उनका रिव्यू होता है?
- क्या एक्सेस जल्दी वापस लेकर दोबारा असाइन किया जा सकता है?
अगर बैकअप प्रमाण किसी कर्मचारी के ब्राउज़र में स्टोर किए हैं, रिकवर कोड किसी निजी नोट में रखे हैं, या शेयर किए गए एडमिन पासवर्ड चैट के ज़रिए घूम रहे हैं, तो किसी घटना के दौरान बिज़नेस साफ तौर पे रिकवर नहीं कर पा सकता।
एक बिज़नेस पासवर्ड मैनेजर ज़रूरी प्रमाण को एन्क्रिप्ट की गई तिजोरियों में केंद्रीकृत करके, भूमिका के हिसाब से एक्सेस असाइन करके, और किसी के जाने या ज़िम्मेदारियों के बदलने पे एक्सेस वापस लेना या दोबारा असाइन करना आसान बनाकर उस रिस्क को कम करने में मदद करता है। Proton Pass for Business टीमों को मज़बूत पासवर्ड जनरेट करने, प्रमाण सुरक्षित रूप से स्टोर करने, सुरक्षित शेयरिंग इस्तेमाल करने, और संवेदनशील एक्सेस को चैट और स्प्रेडशीट से दूर रखने में मदद करता है।
IT टीमों के लिए पासवर्ड मैनेजर के रूप में, Proton Pass केंद्रीकृत प्रमाण मैनेजमेंट, पासवर्ड नीतियां, सुरक्षित शेयरिंग, रिपोर्टिंग और लॉग, SCIM प्रोविजनिंग, और SSO इंटीग्रेशन के लिए सहायता करता है। इससे प्रमाण रिकवरी ज़्यादा मैनेज करने लायक हो जाती है, क्योंकि ज़रूरी सिस्टम तक एक्सेस एक व्यक्ति, एक ब्राउज़र प्रोफाइल, या एक बिना डॉक्यूमेंट किए पासवर्ड पे निर्भर नहीं रहता।
डिज़ास्टर रिकवरी प्लैन टेम्पलेट
डिज़ास्टर रिकवरी प्लैन सबसे अच्छा तब काम करता है जब वो आउटेज के दौरान कार्रवाई के लिए गाइड करने लायक स्पष्ट हो, लेकिन दबाव में टीम के इस्तेमाल के लिए आसान भी हो। SMBs के लिए, टेम्पलेट को ज़रूरी चीज़ों पे फोकस करना चाहिए: क्या रीस्टोर करना है, कितनी जल्दी, किस बैकअप से, किसके द्वारा, और किन प्रमाणों के साथ।
1. स्कोप
तय करें कि प्लैन कौन से सिस्टम, सर्विसेज़, स्थान, डिवाइस, और डाटा कवर करता है।
टेम्पलेट टेक्स्ट: ये IT डिज़ास्टर रिकवरी प्लैन, [Company Name] के ज़रूरी ऑपरेशन को टेक्नोलॉजी रुकावट के बाद रीस्टोर करने के लिए ज़रूरी सिस्टम, डाटा, सर्विसेज़, प्रमाण, और वेंडर को कवर करता है।
2. ज़रूरी सिस्टम की सूची
उन सिस्टम की लिस्ट बनाएं जिन पे आपका बिज़नेस निर्भर है, और प्रायोरिटी टियर असाइन करें।
टेम्पलेट टेक्स्ट: ज़रूरी सिस्टम को बिज़नेस इम्पैक्ट, रिकवरी टाइम ऑब्जेक्टिव, रिकवरी पॉइंट ऑब्जेक्टिव, और दूसरे सिस्टम पे निर्भरता के आधार पे टियर 1, टियर 2, और टियर 3 के ग्रुप में बांटा जाएगा।
3. रिकवरी ऑब्जेक्टिव
हर प्रायोरिटी सिस्टम के लिए RTO और RPO तय करें।
टेम्पलेट टेक्स्ट: हर सिस्टम के पास दस्तावेज़ी रिकवरी टाइम ऑब्जेक्टिव और रिकवरी पॉइंट ऑब्जेक्टिव होने चाहिए। इन टारगेट का रिव्यू साल में कम से कम एक बार और किसी बड़े सिस्टम बदलाव के बाद होना चाहिए।
4. बैकअप और रीस्टोर प्रोसेस
डॉक्यूमेंट करें कि बैकअप कहां स्टोर किए जाते हैं, वो कितनी बार चलते हैं, उन्हें कौन एक्सेस कर सकता है, और रीस्टोर टेस्टिंग कैसे काम करती है।
टेम्पलेट टेक्स्ट: बैकअप को बिना अनुमति वाले एक्सेस से सुरक्षित रखा जाना चाहिए, जहां ठीक हो वहां मुख्य सिस्टम से अलग स्टोर किया जाना चाहिए, और नियमित शेड्यूल पे टेस्ट किया जाना चाहिए। टियर 1 सिस्टम के लिए रीस्टोर प्रोसीजर डॉक्यूमेंट किए जाने चाहिए।
5. प्रमाण और एक्सेस रिकवरी
तय करें कि ज़रूरी प्रमाण कहां स्टोर किए जाते हैं और रिकवरी के दौरान उन्हें कौन एक्सेस कर सकता है।
टेम्पलेट टेक्स्ट: डिज़ास्टर रिकवरी के लिए ज़रूरी एडमिन प्रमाण, बैकअप प्रमाण, रिकवर कोड, और वेंडर एक्सेस को मंज़ूर एन्क्रिप्ट की गई तिजोरी में स्टोर किया जाना चाहिए। एक्सेस सिर्फ अधिकृत भूमिकाओं तक सीमित होना चाहिए, और भूमिका बदलने, ऑफबोर्डिंग, और रिकवरी एक्सरसाइज़ के बाद उसका रिव्यू होना चाहिए।
6. भूमिकाएं और एस्कलेशन
रिकवरी के ज़िम्मेदार, विकल्प, और एस्कलेशन रास्ते तय करें।
टेम्पलेट टेक्स्ट: हर रिकवरी भूमिका का एक मुख्य ज़िम्मेदार और एक बैकअप ज़िम्मेदार होना चाहिए। प्लैन में ये साफ होना चाहिए कि रिकवरी का नेतृत्व कौन करेगा, सिस्टम कौन रीस्टोर करेगा, वेंडर से कौन संपर्क करेगा, अपडेट कौन शेयर करेगा, और इमरजेंसी बदलावों को कौन मंज़ूरी देगा।
7. संवाद प्लैन
तय करें कि IT आउटेज के दौरान बिज़नेस अंदरूनी और बाहरी तौर पे कैसे संवाद करता है।
टेम्पलेट टेक्स्ट: रिकवरी कार्यक्रम के दौरान, इंटरनल अपडेट [मंज़ूर चैनल] के ज़रिए शेयर किए जाएंगे। ग्राहकों, वेंडर, इंश्योरर, या रेगुलेटर को बाहरी संवाद [भूमिका/टीम] की मंज़ूरी से होने चाहिए।
8. टेस्टिंग और रिव्यू कैडेंस
तय करें कि प्लैन कितनी बार टेस्ट और अपडेट किया जाता है।
टेम्पलेट टेक्स्ट: ये डिज़ास्टर रिकवरी प्लैन कम से कम [साल में एक बार/साल में दो बार] टेस्ट किया जाएगा और बड़ी घटनाओं, सिस्टम बदलावों, वेंडर बदलावों, या असफल रिकवरी एक्सरसाइज़ के बाद रिव्यू किया जाएगा।
अपना IT डिज़ास्टर रिकवरी प्लैन कैसे टेस्ट करें
डिज़ास्टर रिकवरी प्लैन तभी काम का बनता है जब उसे असली रुकावट जैसी स्थितियों में टेस्ट किया गया हो। मौजूद लेकिन कभी रीस्टोर ना किया गया बैकअप अब भी सिर्फ एक अंदाज़ा है। जिस रिकवरी भूमिका को सिर्फ एक व्यक्ति समझता है, वो अब भी एक निर्भरता है। जिस एडमिन प्रमाण को कोई आउटेज के दौरान ना ढूंढ पाए, वो अब भी एक रुकावट है।
शुरू में टेस्टिंग का जटिल होना ज़रूरी नहीं है। ज़्यादातर SMBs के लिए, मकसद ये साबित करना है कि बिज़नेस सही सिस्टम, सही लोगों के साथ, सही प्रमाण इस्तेमाल करके, व्यावहारिक समय-सीमा के भीतर रीस्टोर कर सकता है।
1. टेबलटॉप एक्सरसाइज़
कोई संभावित सिनेरियो चुनें, जैसे शेयर की गई फ़ाइलों को प्रभावित करता रैंसमवेयर, क्लाउड स्टोरेज आउटेज, ग्राहक डाटा की गलती से डिलीट होना, या अचानक एडमिन खाते का एक्सेस खोना। देखें कि पहले घंटे में टीम क्या करेगी, नेतृत्व कौन करेगा, किन वेंडर से संपर्क किया जाएगा, कौन से सिस्टम को प्रायोरिटी दी जाएगी, और कौन सी जानकारी गायब होगी।
2. रिस्टोरेशन टेस्ट करें
कोई ज़रूरी फ़ाइल, डेटाबेस, मेलबॉक्स या सिस्टम निर्यात चुनें और पुष्टि करें कि उसे इस्तेमाल लायक स्थिति में रीस्टोर किया जा सकता है। देखें कि रीस्टोर किया डाटा काफी नया है या नहीं, परमिशन अब भी काम करती हैं या नहीं, और टीम जानती है या नहीं कि बैकअप कहां है।
3. नियमित रूप से टेस्ट करें
व्यावहारिक बेसलाइन के तौर पे, SMBs को NIST की Special Publication 800-34 Revision 1(नई विंडो) गाइडेंस के मुताबिक प्लैन का टेस्ट साल में कम से कम एक बार करना चाहिए, और किसी बड़े सिस्टम या वेंडर बदलाव के बाद और ज़्यादा बार।
4. प्रमाण रिकवरी टेस्ट करें
पुष्टि करें कि अधिकृत लोग बैकअप एडमिन खातों, क्लाउड एडमिन खातों, वेंडर पोर्टल, रिकवर कोड, और इमरजेंसी प्रमाण तक बिना किसी कर्मचारी के ब्राउज़र, निजी नोट्स, या याददाश्त पे निर्भर हुए एक्सेस कर सकते हैं। मकसद संवेदनशील पासवर्ड को बिना ज़रूरत उजागर करना नहीं है। मकसद ये पुष्टि करना है कि दबाव में होने पे एक्सेस मॉडल अब भी काम करता है।
हर टेस्ट के बाद, डॉक्यूमेंट करें कि क्या असफल हुआ, किसमें बहुत समय लगा, और हर फिक्स के लिए एक खास व्यक्ति और डेडलाइन तय करें। अच्छा टेस्ट वो नहीं है जिसमें सब कुछ परफेक्ट चलता है। अच्छा टेस्ट वो है जो तब गैप दिखाता है जब बिज़नेस के पास उन्हें ठीक करने का समय अब भी होता है।
रिकवरी को सिस्टम, डाटा, और एक्सेस के इर्द-गिर्द बनाएं
एक काम का IT डिज़ास्टर रिकवरी प्लैन बिज़नेस को रिकवरी का क्रम, ज़िम्मेदार लोगों का एक सेट, स्वीकार्य डाउनटाइम का व्यावहारिक अंदाज़ा, और बिज़नेस कंटिन्यूटी बनाए रखने तथा उन सिस्टम तक दोबारा एक्सेस पाने का तरीका देता है जो काम चालू रखते हैं।
SMBs के लिए, यही फर्क तय कर सकता है कि रुकावट छोटी रहेगी या लंबा आउटेज बनेगी। अगर ईमेल, फाइनेंस सॉफ्टवेयर, क्लाउड स्टोरेज, ग्राहक सिस्टम, या एडमिन खाते उपलब्ध ना हों, तो टीम को जानना होगा कि पहले क्या आता है, कौन कार्रवाई कर सकता है, और एक्सेस को सुरक्षित तरीके से रीस्टोर करने के लिए कौन से प्रमाण ज़रूरी हैं।
इसीलिए रिकवरी प्लानिंग में सिस्टम, डाटा, और एक्सेस को साथ में कवर करना चाहिए। बैकअप फ़ाइलें रीस्टोर कर सकता है, लेकिन प्रमाण ही वो चीज़ हैं जो टीम को रिकवर के लिए ज़रूरी सिस्टम पे दोबारा कंट्रोल दिलाते हैं। एडमिन लॉगइन, वेंडर पोर्टल, बैकअप खाते, रिकवर कोड, और शेयर किए गए ऑपरेशनल प्रमाण — सबको सुरक्षित रखना, व्यवस्थित रखना, और कुछ गड़बड़ होने पे सही लोगों के लिए उपलब्ध रखना ज़रूरी है।
एक बिज़नेस पासवर्ड मैनेजर प्लैन के उस हिस्से को मज़बूत बनाने में मदद करता है। ज़रूरी प्रमाण एन्क्रिप्ट की गई पासवर्ड तिजोरियों में स्टोर किए जाते हैं और सिर्फ अधिकृत लोगों के साथ शेयर किए जाते हैं, जिससे रिकवरी कार्यक्रम के दौरान बिज़नेस किसी एक कर्मचारी के ब्राउज़र, निजी नोट्स, या याददाश्त पे कम निर्भर रहता है।
