برنامه‌ریزی اقتضایی کسب‌وکار؛ از BIA تا تمرین بحران

برنامه‌ریزی اقتضایی یعنی پیش از اختلال، حداقل خدمت قابل‌قبول، نقطه فعال‌سازی، صاحب تصمیم، راه جایگزین و معیار بازگشت را روشن کنید. برنامه خوب فهرست بلند خطرها یا جمله «سرور پشتیبان را روشن کنید» نیست؛ باید نشان دهد وقتی افراد، محل، فناوری، داده، تأمین‌کننده یا ارتباطات در دسترس نیستند، کدام خدمت اول حفظ می‌شود و با چه کنترل ایمنی و امنیتی. جان و ایمنی همیشه بر تداوم فروش یا سرعت بازیابی مقدم‌اند.

پاسخ کوتاه: برنامه اقتضایی چیست؟

برنامه اقتضایی یک مجموعه اقدام از پیش‌طراحی‌شده برای یک اختلال یا از‌دست‌رفتن منبع است. این برنامه trigger، سطح فعال‌سازی، فرمانده/مالک، نقش‌های اصلی و جانشین، ارتباطات، منابع جایگزین، حداقل خروجی، محدودیت و پایان وضعیت را مشخص می‌کند. هدف، تضمین «بدون توقف» یا حذف عدم‌قطعیت نیست؛ هدف کاهش زمان سردرگمی و حفظ خدمت حیاتی در سطحی از پیش‌توافق‌شده است.

برای کسب‌وکار کوچک، یک برنامه یک‌صفحه‌ایِ آزموده برای دو خدمت حیاتی از سند ۵۰صفحه‌ای بدون شماره تماس و اختیار مفیدتر است. اما برنامه یک‌صفحه‌ای هم جای طرح تخلیه، واکنش سایبری، الزامات صنعت، بیمه یا قانون محلی را نمی‌گیرد.

برنامه اقتضایی را با پنج برنامه دیگر یکی نگیرید

حوزه	پرسش اصلی	زمان	خروجی نمونه
مدیریت ریسک	چه چیزی ممکن است رخ دهد و چگونه احتمال/اثر را کم کنیم؟	پیش از اختلال	risk register و کنترل پیشگیرانه
طرح اقدام اضطراری	چگونه جان و ایمنی افراد را حفظ کنیم؟	دقایق نخست	هشدار، تخلیه، شمارش افراد، تماس اضطراری
مدیریت حادثه/بحران	چه کسی وضعیت را کنترل و تصمیم‌ها را هماهنگ می‌کند؟	حین حادثه	ساختار فرماندهی و decision log
تداوم کسب‌وکار	کدام محصول/خدمت در چه سطحی ادامه یابد؟	حین اختلال تا تثبیت	حداقل خدمت و راه جایگزین
بازیابی فناوری/داده	سامانه و داده چگونه با کنترل مناسب برگردند؟	پس از اختلال فنی	مراحل restore، اعتبارسنجی و بازگشت
برنامه اقتضایی	اگر منبع/سناریوی مشخص رخ داد چه اقدام جایگزینی فعال شود؟	پیش و حین اختلال	trigger، action card و fallback

این حوزه‌ها هم‌پوشانی دارند و لازم نیست حتماً شش سند جدا باشند، اما مسئولیت و ترتیب باید روشن باشد. راهنمای تداوم کسب‌وکار دولت بریتانیا incident plan را برای اثر اولیه و business continuity plan را برای حفظ/بازیابی محصولات و خدمات کلیدی تفکیک می‌کند. این راهنما قانون ایران نیست. راهنمای Business Continuity دولت بریتانیا همچنین بر BIA، تمرین و نگهداری تأکید دارد.

راهنمای رسمی کسب‌وکار استرالیا نیز طرح را به continuity پیش از اختلال، emergency action هنگام رخداد و recovery پس از آن تقسیم می‌کند و ایمنی افراد را مقدم می‌داند. این منبع برای کسب‌وکارهای استرالیاست، نه مقررات ایران. راهنمای Emergency Management دولت استرالیا یک نمونه روشن از اتصال این سه فاز است.

گام صفر: مرز جان، ایمنی و اختیار

هیچ برنامه کسب‌وکار نباید کارمند آموزش‌ندیده را به اطفای حریق، نجات، کمک پزشکی، کار با برق، ورود به محل ناامن یا پاسخ فنی خارج از صلاحیت وادار کند. دستور مقام‌های مسئول، خدمات اضطراری و طرح ایمنی محل بر هدف عملیاتی مقدم است. شماره‌ها، مسیرها و وظایف باید برای محل و حوزه قضایی واقعی تأیید شوند.

الزامات OSHA برای Emergency Action Plan در ایالات متحده، گزارش وضعیت اضطراری، تخلیه، وظیفه عملیات حیاتی پیش از خروج، شمارش افراد، وظایف نجات/پزشکی و مسئول تماس را پوشش می‌دهد. این متن استاندارد حقوقی آمریکا است و نباید قانون ایران تلقی شود. حداقل‌های EAP در راهنمای OSHA نمونه‌ای برای دیدن عناصر ایمنی است؛ طرح نهایی باید با متخصص و مقررات محلی تطبیق یابد.

از خدمت حیاتی شروع کنید، نه فهرست بلایای ممکن

تیم‌ها اغلب با طوفان فکری «زلزله، جنگ، استعفا، هک، قطعی برق…» شروع می‌کنند و سندی عظیم می‌سازند. روش مقاوم‌تر، impact-first است: کدام خدمت اگر متوقف شود به جان/ایمنی، تعهد قانونی، داده، مشتری، نقدینگی یا اعتبار آسیب جدی می‌زند؟ سپس منابع لازم برای همان خدمت را مشخص کنید.

برای دیدن مسیر واقعی و وابستگی‌های انتظار/تحویل، داده فرایند می‌تواند مکمل مصاحبه باشد؛ راهنمای ردیابی زمان برای بهبود فرایند نشان می‌دهد case، مرحله و handoff چگونه ثبت می‌شوند. لاگ زمان به‌تنهایی BIA نیست و اثرهای ایمنی، قانونی و کیفی را کامل نمی‌سنجد.

کاربرگ تحلیل اثر کسب‌وکار (BIA) ساده

فیلد	سؤال	مثال آموزشی
خدمت/محصول	چه خروجی برای چه ذی‌نفعی؟	پاسخ تیکت بحرانی مشتری
اثر توقف	در ۲، ۸، ۲۴ و ۷۲ ساعت چه پیامدی دارد؟	خطر از دست‌رفتن سفارش فعال
حداقل سطح	کمترین ظرفیت قابل‌قبول و ایمن چیست؟	فقط تیکت‌های severity ۱
حد تحمل	پس از چه زمانی اثر غیرقابل‌قبول می‌شود؟	نیازمند تأیید مالک کسب‌وکار
وابستگی	افراد، محل، فناوری، داده و طرف سوم؟	CRM، اینترنت، on-call، تأمین‌کننده
راه جایگزین	در نبود هر وابستگی چه می‌کنیم؟	شماره پشتیبان و فرم آفلاین مجاز
مالک و جانشین	چه کسی تصمیم و چه کسی جای او؟	مدیر پشتیبانی / جانشین شیفت
شاهد بازیابی	از کجا می‌فهمیم خدمت واقعاً برگشته؟	تست ثبت و پاسخ یک تیکت کنترل‌شده

اثر را در چند افق زمانی بسنجید؛ خدمتی که توقف دو‌ساعته‌اش قابل‌تحمل است ممکن است پس از ۲۴ ساعت بحرانی شود. درآمد تنها معیار نیست. تعهد قانونی، سلامت، داده، آسیب به گروه آسیب‌پذیر و برگشت‌پذیری را جدا ثبت کنید.

RTO و RPO را فقط در جای درست استفاده کنید

RTO هدف زمانی بازیابی یک سامانه/خدمت است؛ RPO نقطه بازیابی داده و مقدار از‌دست‌رفتن داده قابل‌تحمل را بیان می‌کند. این‌ها وعده قطعی، زمان واقعی حادثه یا عددی برای حدس مدیر نیستند. باید از اثر کسب‌وکار، معماری، backup، هزینه، امنیت و آزمون بازیابی بیایند.

NIST SP ۸۰۰-۳۴ Rev.۱ برای سامانه‌های اطلاعاتی فدرال آمریکا نوشته شده و BIA، کنترل‌های پیشگیرانه، راهبرد بازیابی، برنامه، آزمون/آموزش/تمرین و نگهداری را در چرخه contingency planning قرار می‌دهد. انتشار ۲۰۱۰ است و scope آن عمومیِ همه بحران‌ها نیست. راهنمای NIST برای Federal Information Systems برای اصطلاحات و ساختار IT مفید است؛ معماری و مقررات محلی باید جدا بررسی شوند.

وابستگی‌ها را در شش سبد ببینید

1. افراد: دانش کلیدی، شیفت، جانشین، دسترسی و سلامت.
2. محل و تجهیزات: ساختمان، ایستگاه، ماشین، ابزار و دسترس‌پذیری.
3. فناوری: هویت، شبکه، سامانه، دستگاه و پشتیبانی.
4. داده: منبع معتبر، نسخه، محرمانگی، تمامیت و backup.
5. طرف سوم: تأمین‌کننده، حمل، پرداخت، ابر و پیمانکار.
6. زیرساخت و ارتباط: برق، اینترنت، تلفن، آب، سوخت و کانال اطلاع‌رسانی.

برای هر وابستگی سه سؤال بپرسید: single point of failure چیست؟ راه جایگزین چقدر ظرفیت دارد؟ آخرین بار چه زمانی واقعاً آزموده شد؟ وجود نام یک vendor دوم به معنای آمادگی نیست؛ قرارداد، دسترسی، داده، زمان راه‌اندازی و ظرفیت باید قابل‌اثبات باشند.

سناریو را بر «از دست رفتن منبع» طراحی کنید

به‌جای نوشتن صد برنامه برای علت‌های مختلف، هسته مشترک بسازید: محل برای ۴۸ ساعت در دسترس نیست؛ ۴۰٪ نیرو حاضر نیست؛ سامانه سفارش نامطمئن است؛ تأمین‌کننده اصلی هفت روز تحویل ندارد؛ اینترنت منطقه قطع است. سپس افزونه‌های خطر خاص مانند آتش، حمله سایبری یا آلودگی را به متخصص همان حوزه بسپارید.

سناریو باید فرض‌های قابل‌آزمون داشته باشد: زمان شروع، مدت نامعلوم، منابع از‌دست‌رفته، اطلاعات ناقص و ذی‌نفعان. «همه‌چیز خراب است» تمرین مفیدی نمی‌سازد و «قطعی دقیقاً ۱۵ دقیقه» ممکن است false precision ایجاد کند.

Trigger، سطح فعال‌سازی و اختیار تصمیم

سطح	نمونه trigger	تصمیم	اختیار
پایش	هشدار معتبر یا degradation محدود	تأیید، ثبت، آماده‌سازی جانشین	مالک شیفت
جزئی	خدمت زیر حد تعریف‌شده و workaround موجود	فعال‌سازی راه جایگزین محدود	incident lead
کامل	ایمنی/خدمت حیاتی/چند واحد درگیر	ساختار فرماندهی و continuity mode	نقش ارشد تعیین‌شده
بازگشت	کنترل، تست و ظرفیت پایدار تأیید شده	بازگشت مرحله‌ای و پایش	مالک خدمت + فنی/ایمنی

trigger نباید فقط «احساس مدیر» یا یک عدد بدون منبع باشد. معیار، منبع هشدار، روش تأیید، شخص مجاز و مسیر escalation را بنویسید. جانشین برای زمانی لازم است که صاحب اصلی در دسترس نیست. برای تفکیک واگذاری کار از اختیار تصمیم و تعریف سطح escalation، راهنمای تفویض اختیار کمک می‌کند.

کارت اقدام یک‌صفحه‌ای برای هر خدمت حیاتی

• هشدار ایمنی: اقدام ممنوع، مرجع اضطراری و اولویت جان.
• دامنه: خدمت، محل، نوع اختلال و حداقل ظرفیت.
• فعال‌سازی: trigger، منبع تأیید و صاحب تصمیم/جانشین.
• ۱۵ دقیقه نخست: ایمنی، تأیید وضعیت، log و اطلاع نقش‌های لازم.
• ۶۰ دقیقه نخست: fallback، اولویت queue، پیام اولیه و منابع.
• تداوم: شیفت، حد توقف، ثبت دستی مجاز و کنترل کیفیت.
• ارتباطات: مخاطب، کانال اصلی/جایگزین و تأیید پیام.
• بازگشت: تست، تأیید داده، بازگشت مرحله‌ای و deactivation.
• نسخه: مالک سند، تاریخ آزمون و تغییر بعدی.

نام افراد سریع منقضی می‌شود؛ نقش را محور کنید و فهرست تماس جدا و قابل‌به‌روزرسانی نگه دارید. نسخه آفلاین امن و قابل‌دسترسی لازم است اگر مخزن اصلی ممکن است در حادثه از دسترس خارج شود. اطلاعات حساس، رمزها یا کلیدها را داخل کارت عمومی نگذارید.

اولویت‌بندی هنگام فعال‌سازی

در بحران، همه واحدها ممکن است کار خود را «حیاتی» بخوانند. ابتدا گیت جان/ایمنی، الزام و آسیب برگشت‌ناپذیر را بررسی کنید؛ سپس اثر تأخیر، وابستگی و حداقل برش خدمت را مقایسه کنید. صاحب اولویت باید پیش از بحران تعیین شده باشد.

اگر چند خروجی با ظرفیت محدود رقابت می‌کنند، پروتکل حل تساوی اولویت‌ها برای گیت خطر، هزینه تأخیر، وابستگی، cut line و change control مناسب است. ماتریس احتمال/اثر به‌تنهایی ترتیب عملیات زنده را تعیین نمی‌کند.

راه جایگزین باید حداقل خدمت را واقعاً تحویل دهد

هر fallback هزینه و خطر تازه دارد. فرم کاغذی ممکن است خطای ورود و نشت داده بسازد؛ کار از خانه به برق، اینترنت، دستگاه و حریم وابسته است؛ تأمین‌کننده دوم ممکن است کیفیت یا مجوز لازم نداشته باشد؛ backup ممکن است آلوده یا ناسازگار باشد. برای هر جایگزین، ظرفیت، مدت قابل‌استفاده، کنترل و خروج ایمن را بنویسید.

راه جایگزین را در شرایط واقعی اما کنترل‌شده امتحان کنید. فقط «فایل باز شد» کافی نیست؛ آیا فرد جانشین دسترسی دارد؟ آیا سفارش کامل می‌شود؟ آیا داده بعداً بدون duplication برمی‌گردد؟ آیا مشتری می‌فهمد چه انتظاری داشته باشد؟

برای حادثه سایبری نسخه عمومی نسازید

در رخداد مشکوک امنیتی، خاموش‌کردن، پاک‌کردن یا restore عجولانه می‌تواند شواهد را از بین ببرد، آلودگی را گسترش دهد یا بازیابی را نامعتبر کند. برنامه تداوم باید نقطه اتصال به incident response سایبری، نقش مجاز، کانال خارج از سامانه آسیب‌دیده و معیار integrity را مشخص کند؛ دستور فنی را تیم امنیت و برنامه معتبر سازمان می‌دهد.

backup صرفاً وجود فایل نیست. جداسازی، کنترل دسترسی، تاریخ/نسخه، آزمون restore و اعتبارسنجی داده اهمیت دارد. NIST ۸۰۰-۳۴ برای سیستم‌های فدرال ساختاری می‌دهد، اما پاسخ رخداد سایبری و الزامات گزارش‌دهی به راهنمای جاری و حوزه قضایی نیاز دارد.

ارتباطات: سریع، تأییدشده و حداقلی

پیام اولیه لازم نیست همه علت را بداند. چهار جزء کافی است: چه چیزی تأیید شده، چه اثری بر مخاطب دارد، اکنون چه اقدامی لازم است و به‌روزرسانی بعدی چه زمانی/از کدام کانال می‌آید. حدس، مقصرسازی و وعده زمان بازیابی بدون تأیید را حذف کنید.

کانال اصلی ممکن است همان چیزی باشد که از کار افتاده است؛ جایگزین و روش احراز پیام را از پیش تعیین کنید. برای طراحی request/urgency/response/escalation و جلوگیری از آشفتگی کانال‌ها، قرارداد مدیریت وقفه و پیام فوری می‌تواند بخش عملیاتی ارتباط تیمی را پشتیبانی کند.

جلسه حادثه و Decision Log

جلسه وضعیت باید کوتاه و خروجی‌محور باشد: واقعیت تأییدشده، تصمیم‌های لازم، صاحب اقدام، موعد بررسی و ریسک باز. هر تصمیم با زمان، اطلاعات موجود و شرایط بازبینی ثبت شود. این log برای handoff، پسارویداد و جلوگیری از دستور متعارض ضروری است.

برای دستورجلسه پرسش‌محور، نقش صاحب تصمیم و صورت‌جلسه action/owner/due، چک‌لیست جلسه مؤثر را متناسب با incident cadence کوتاه کنید. جلسه بیشتر به معنای کنترل بیشتر نیست؛ اگر تصمیم یا هماهنگی لازم ندارد، update غیرهم‌زمان ممکن است بهتر باشد.

برنامه ظرفیت انسانی هنگام اختلال

continuity mode نباید به اضافه‌کاری نامحدود تبدیل شود. حداقل خدمت، شیفت، جانشین، استراحت، handoff و شرط توقف را تعریف کنید. یک نفر کلیدی که هم فرمانده، هم فنی و هم ارتباطات است single point of failure است. افراد دارای معلولیت، شیفت شب، دورکاران، پیمانکاران و بازدیدکنندگان را در هشدار و دسترسی فراموش نکنید.

وقتی موج کار از ظرفیت عبور می‌کند، تریاژ فوری غرق شدن در کار برای محاسبه شکاف، WIP و مذاکره کاهش دامنه مفید است. تمرین تنفس یا پیام انگیزشی جای نیروی کافی، استراحت، ایمنی و حمایت نیست.

تمرین tabletop را چگونه طراحی کنیم؟

1. هدف: یک قابلیت را انتخاب کنید؛ مثلاً activation یا ارتباط جایگزین.
2. دامنه: خدمت، نقش‌ها و مدت تمرین را محدود کنید.
3. سناریو: از‌دست‌رفتن یک منبع با اطلاعات تدریجی بسازید.
4. قواعد ایمنی: هیچ اقدام زنده پرخطر، ارسال عمومی یا تغییر production بدون مجوز.
5. تسهیل: injectها را در زمان مناسب بدهید و تصمیم‌ها را ثبت کنید.
6. مشاهده: زمان تأیید، activation، تماس، تصمیم، gap و workaround را ببینید.
7. debrief: چه چیزی کار کرد، چه چیزی مبهم بود و چه کسی اصلاح می‌کند؟
8. بستن اقدام: مالک، موعد، شاهد تکمیل و retest تعیین کنید.

راهنمای تمرین تداوم دولت بریتانیا برای local responders نوشته شده و بر اعتبارسنجی، تمرین نقش، آزمون سیستم و یادگیری پس از exercise تأکید دارد. نتایج قدیمی survey داخل آن را به همه شرکت‌ها تعمیم نمی‌دهیم. راهنمای رسمی exercising و testing tabletop را جای آزمون فنی یا live exercise کامل نمی‌داند.

چه چیزی را در تمرین بسنجیم؟

سنجه	تعریف	guardrail
زمان تشخیص/تأیید	از نخستین signal تا تأیید معتبر	هشدار کاذب و مسیر verify
زمان activation	از تأیید تا اعلام سطح و فرمانده	فعال‌سازی عجولانه
دستیابی به حداقل خدمت	زمان و درصد ظرفیت قابل‌قبول	کیفیت، ایمنی و قانون
موفقیت تماس	نقش‌های لازم که پیام را دریافت/تأیید کردند	حریم فهرست تماس
تصمیم بی‌مالک	تصمیم/اقدام بدون owner یا due	بار بیش‌ازحد یک نقش
بستن اصلاحات	اقدام‌های after-action با شاهد و retest	تغییر سند بدون تغییر قابلیت

«همه شرکت کردند» یا «تمرین خوب بود» سنجه آمادگی نیست. از طرف دیگر، رسیدن به RTO در tabletop اثبات نمی‌کند سامانه واقعاً در همان زمان restore می‌شود. آزمون فنی جدا و کنترل‌شده لازم است.

سه سناریوی نمونه برای کسب‌وکار کوچک

اینترنت محل برای یک روز قطع است

خدمت حیاتی، کانال جایگزین مجاز، دستگاه/داده آفلاین، سقف ثبت دستی، sync بعدی و پیام مشتری را مشخص کنید. به hotspot شخصی، پیام‌رسان نامجاز یا انتقال فایل حساس خودکار پناه نبرید. فرض‌ها درباره پوشش موبایل و برق باید آزموده شوند.

فرد کلیدی ناگهان در دسترس نیست

نقش و تصمیم‌ها را مستند کنید، deputy دارای دسترسی و سطح اختیار بسازید و یک handoff آزمایشی انجام دهید. برنامه نباید به درخواست password شخصی یا تماس مزاحم هنگام بیماری وابسته باشد. کاهش دامنه ممکن است امن‌تر از تقلید کامل ظرفیت فرد باشد.

تأمین‌کننده اصلی تحویل نمی‌دهد

موجودی/زمان تحمل، سفارش‌های متأثر، کیفیت و مجوز جایگزین، زمان onboarding، قیمت، ارتباط مشتری و شرط بازگشت را ثبت کنید. vendor دوم روی کاغذ بدون قرارداد و آزمون نمونه fallback قابل‌اتکا نیست. این سه سناریو ساختگی‌اند و توصیه قراردادی یا فنی اختصاصی نیستند.

برنامه را چه زمانی به‌روزرسانی کنیم؟

بازبینی سالانه می‌تواند کف اداری باشد، اما کافی نیست. تغییر فرد/جانشین، سامانه، محل، تأمین‌کننده، محصول، قانون، قرارداد، معماری، کانال تماس، نتیجه تمرین یا حادثه باید trigger بازبینی باشد. هر نسخه مالک، تأییدکننده، تاریخ، دامنه و تاریخ آزمون دارد.

برنامه منقضی را بی‌صدا جایگزین نکنید؛ نقش‌ها باید بدانند چه چیزی تغییر کرده است. شماره تماس و دسترسی را بیشتر از متن راهبردی بررسی کنید، چون سریع‌تر منقضی می‌شوند. پس از اصلاح مهم، بخشی که تغییر کرده دوباره آزموده شود.

پسارویداد: از سرزنش به اصلاح قابلیت

پس از تثبیت، timeline مبتنی بر log بسازید: signal، تأیید، activation، تصمیم، fallback، بازیابی و بازگشت. میان plan gap، execution gap، information gap، resource gap و فرض نادرست فرق بگذارید. اقدام اصلاحی باید مالک، موعد، شاهد و retest داشته باشد.

اگر برنامه فعال شد اما نتیجه نداد، چارچوب ادامه، اصلاح یا توقف برنامه برای stabilization، واقعیت پایه، گزینه قابل‌برگشت، sunk cost و after-action log مفید است. پسارویداد بدون ایمنی روانی و عدالت می‌تواند گزارش‌دادن خطا را تضعیف کند.

فشار روانی و تصمیم زیر بحران

برنامه از پیش‌نوشته‌شده ممکن است بار تصمیم را کم کند، اما آرامش، تصمیم درست یا جلوگیری از آسیب روانی را تضمین نمی‌کند. وظایف کوتاه، role clarity، شیفت، buddy، handoff و دسترسی به حمایت مهم‌اند. نشانه‌های پزشکی یا خطر خودآسیبی باید از مسیر سلامت و فوریت مناسب پیگیری شوند.

برای فشار ناشی از موعد و فوریت، راهنمای استرس زمانی تریاژ و مرز کمک را توضیح می‌دهد. آن صفحه و این برنامه جای خدمات اضطراری، درمان یا برنامه سلامت شغلی نیستند.

خطاهای رایج برنامه‌ریزی اقتضایی

• شروع با ۵۰ خطر: خدمت حیاتی و dependency گم می‌شود.
• trigger مبهم: همه منتظر دیگری می‌مانند یا زود فعال می‌کنند.
• مالک بدون جانشین: برنامه با غیبت همان فرد می‌شکند.
• fallback بدون ظرفیت/کنترل: خطر تازه یا کیفیت پایین می‌سازد.
• backup آزمون‌نشده: وجود فایل برابر restore معتبر نیست.
• پیام بدون تأیید: شایعه و وعده نادرست ایجاد می‌کند.
• اضافه‌کاری نامحدود: خطا و فرسایش ظرفیت را زیاد می‌کند.
• tabletop بدون action owner: گفت‌وگو رخ می‌دهد، قابلیت تغییر نمی‌کند.
• به‌روزرسانی فقط سالانه: تماس و dependency منقضی می‌مانند.
• یک سند برای همه خطرهای تخصصی: ایمنی، سایبر و قانون سطحی می‌شوند.

چک‌لیست نسخه یک‌صفحه‌ای

• خدمت حیاتی و حداقل سطح قابل‌قبول
• اثر توقف در چند افق زمانی
• وابستگی افراد/محل/فناوری/داده/طرف سوم/زیرساخت
• trigger، روش تأیید و سطح activation
• incident lead، ownerها و deputyها با اختیار
• اقدام ۱۵ و ۶۰ دقیقه نخست
• fallback با ظرفیت، کنترل و شرط توقف
• کانال ارتباط اصلی/جایگزین و پیام اولیه
• معیار restore، validation و deactivation
• نسخه، دسترسی آفلاین امن، تاریخ تمرین و action log

جمع‌بندی: آمادگی را با قابلیت آزموده بسنجید

برنامه اقتضایی مزیت رقابتی تضمینی، سپر کامل یا پیش‌بینی آینده نیست. یک قرارداد عملیاتی است برای اینکه بدانیم چه خدمتی، در چه سطحی، با چه trigger و اختیاری ادامه می‌یابد. از BIA سبک و dependency map شروع کنید، نه فهرست ترس‌ها.

کارت اقدام را با ایمنی، جانشین، ارتباط جایگزین، fallback و معیار بازگشت بسازید؛ سپس tabletop محدود و آزمون فنی کنترل‌شده اجرا کنید. شکاف‌ها را به اقدام مالک‌دار و retest تبدیل کنید. اگر برنامه با تغییر سازمان منقضی شد، آن را اصلاح کنید. آمادگی واقعی در تعداد صفحات نیست؛ در این است که افراد، دسترسی‌ها، منابع و تصمیم‌ها زیر اختلالِ شبیه‌سازی‌شده واقعاً کار کنند.

سؤالات متداول

تفاوت برنامه اقتضایی و تداوم کسب‌وکار چیست؟

تداوم کسب‌وکار چارچوب حفظ و بازیابی محصولات و خدمات حیاتی است. برنامه اقتضایی می‌تواند برای نبود یک منبع یا سناریوی مشخص، اقدام جایگزین تعریف کند و بخشی از همان چارچوب باشد. مرز اسناد به ساختار سازمان بستگی دارد.

آیا کسب‌وکار کوچک به برنامه مفصل نیاز دارد؟

نه لزوماً. یک BIA سبک، دو خدمت حیاتی و کارت‌های کوتاه آزموده می‌توانند شروع مناسبی باشند. اما الزامات ایمنی، صنعت، داده، بیمه و قانون با کوچک‌بودن حذف نمی‌شوند و ممکن است سند تخصصی لازم باشد.

هر چند وقت یک‌بار برنامه را تمرین کنیم؟

عدد ثابت برای همه وجود ندارد. ریسک، تغییر سازمان، اهمیت خدمت، نتیجه تمرین قبلی و الزام صنعت ریتم را تعیین می‌کنند. پس از تغییر مهم یا اصلاح یک شکاف، همان بخش زودتر retest شود؛ بازبینی تقویمی تنها محرک نباشد.

آیا RTO همان زمان واقعی بازیابی است؟

خیر. RTO یک هدف مبتنی بر نیاز کسب‌وکار و قابلیت طراحی‌شده است. زمان واقعی حادثه ممکن است متفاوت باشد. رسیدن به RTO باید با آزمون فنی و شرایط مختلف بررسی شود؛ tabletop به‌تنهایی restore را اثبات نمی‌کند.

اولین قدم امروز چیست؟

یک خدمت حیاتی را انتخاب کنید و بنویسید: حداقل سطح قابل‌قبول، اثر توقف پس از چند ساعت، شش دسته وابستگی، صاحب تصمیم و یک fallback. سپس یک tabletop ۴۵دقیقه‌ای کم‌خطر با action log برنامه‌ریزی کنید.