سیستم مدیریت تداوم کسب‌وکار (BCMS) چیست؟

سیستم مدیریت تداوم کسب‌وکار (BCMS) چیست؟ بررسی کامل با رویکرد امنیت سایبری

چرا تداوم کسب‌وکار به یکی از اولویت‌های سازمان‌ها تبدیل شده است؟

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

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

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

بنابراین، پرسش اساسی این نیست که آیا سازمان با اختلال مواجه خواهد شد یا خیر؛ بلکه این است که:

اگر یک اختلال جدی رخ دهد، سازمان تا چه اندازه برای مدیریت پیامدهای آن، ادامه فعالیت‌های حیاتی و بازیابی خدمات آماده است؟

سیستم مدیریت تداوم کسب‌وکار یا Business Continuity Management System که به اختصار BCMS نامیده می‌شود، رویکردی ساختاریافته برای پاسخ به این پرسش است. این سیستم به سازمان کمک می‌کند فعالیت‌های حیاتی خود را شناسایی کند، اثرات اختلال را ارزیابی کند، راهبردهای تداوم و بازیابی را تدوین کند و آمادگی خود را از طریق تمرین، ارزیابی و بهبود مستمر افزایش دهد.

استاندارد بین‌المللی ISO 22301 چارچوب الزامات سیستم مدیریت تداوم کسب‌وکار را مشخص می‌کند و یکی از مهم‌ترین مراجع برای طراحی، پیاده‌سازی، نگهداری و بهبود BCMS به شمار می‌رود.

در ادامه این مطلب از سایت امین رای، ابتدا مفهوم تداوم کسب‌وکار و ضرورت آن را بررسی می‌کنیم؛ سپس اجزای BCMS، کاربرد آن در امنیت سایبری، مراحل پیاده‌سازی و تفاوت‌های دقیق آن با BCP و DRP را توضیح می‌دهیم.

1. تداوم کسب‌وکار (Business Continuity) چیست؟

تداوم کسب‌وکار به توانایی سازمان برای ادامه ارائه محصولات و خدمات در سطوح از پیش تعیین‌شده و قابل‌قبول، پس از وقوع یک اختلال یا بحران، اشاره دارد.

این تعریف دو نکته مهم دارد.

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

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

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

ازاین‌رو، برنامه‌ریزی تداوم کسب‌وکار باید فرایندهای سازمان، کارکنان، مکان‌های عملیاتی، فناوری، اطلاعات، تأمین‌کنندگان و وابستگی‌های میان آن‌ها را در نظر بگیرد.

2. سیستم مدیریت تداوم کسب‌وکار (BCMS) چیست؟

سیستم مدیریت تداوم کسب‌وکار یا Business Continuity Management System مجموعه‌ای یکپارچه از سیاست‌ها، مسئولیت‌ها، فرایندها، روش‌های ارزیابی، برنامه‌ها، منابع و سازوکارهای نظارتی است که برای ایجاد، حفظ و بهبود توانایی سازمان در مدیریت اختلال‌ها و تداوم فعالیت‌های حیاتی طراحی می‌شود.

بر اساس چارچوب ISO 22301، یک BCMS سیستم مدیریتی مستند و قابل ارزیابی است که سازمان را قادر می‌سازد برای اختلال‌های مخرب آماده شود، به آن‌ها پاسخ دهد و فعالیت‌های خود را در سطح مورد نیاز بازیابی کند.

درک یک تمایز اساسی در این تعریف ضروری است: BCMS صرفاً مجموعه‌ای از اسناد اضطراری نیست. وجود یک فایل شامل شماره تماس افراد کلیدی یا سندی با عنوان «برنامه تداوم کسب‌وکار» به‌تنهایی به معنای استقرار یک سیستم مدیریت تداوم کسب‌وکار نیست.

BCMS باید به‌صورت یک فرایند مدیریتی مستمر عمل کند؛ فرایندی که در آن اهداف تعیین می‌شوند، ریسک‌ها و پیامدها تحلیل می‌شوند، برنامه‌ها توسعه می‌یابند، منابع اختصاص داده می‌شوند، آمادگی سازمان آزمایش می‌شود و یافته‌ها برای اصلاح و بهبود به کار می‌روند.

2.1. اجزای اصلی BCMS

یک سیستم مدیریت تداوم کسب‌وکار اثربخش معمولاً شامل اجزای زیر است:

• سیاست و راهبری: تعیین تعهد مدیریت ارشد، اهداف، دامنه سیستم و مسئولیت‌ها.
• تحلیل اثرات کسب‌وکار (BIA): شناسایی فعالیت‌های حیاتی و تعیین پیامدهای توقف آن‌ها در طول زمان.
• ارزیابی ریسک: شناسایی رویدادهایی که می‌توانند فعالیت‌های سازمان را مختل کنند و ارزیابی احتمال و پیامدهای آن‌ها.
• راهبردهای تداوم و بازیابی: تعیین روش‌های ادامه فعالیت، کاهش اثر اختلال و بازگرداندن خدمات.
• برنامه‌ها و رویه‌های اجرایی: مستندسازی اقداماتی که کارکنان در شرایط اختلال باید انجام دهند.
• آموزش و آگاهی‌رسانی: اطمینان از اینکه افراد نقش خود را در شرایط اضطراری می‌شناسند.
• آزمون و تمرین: بررسی عملی قابلیت اجرای برنامه‌ها و شناسایی نقاط ضعف.
• ارزیابی عملکرد و بهبود مستمر: بازبینی نتایج، اصلاح کاستی‌ها و به‌روزرسانی سیستم.

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

2.2. استاندارد ISO 22301 چه نقشی دارد؟

استاندارد ISO 22301 با عنوان Security and resilience — Business continuity management systems — Requirements مرجع اصلی تعیین الزامات BCMS است.

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

ساختار استاندارد به چرخه‌ای مدیریتی شباهت دارد که در آن برنامه‌ریزی، اجرا، ارزیابی و بهبود به‌صورت مستمر تکرار می‌شوند. بنابراین، انطباق با ISO 22301 نباید به تهیه چند سند یا برگزاری یک مانور محدود شود.

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

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

۳. چرا سازمان‌ها به BCMS نیاز دارند؟

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

3.1. کاهش اثرات اختلال بر عملیات

هدف BCMS این نیست که از وقوع همه حوادث پیشگیری کند؛ بلکه کمک می‌کند سازمان پیامدهای اختلال را بهتر مدیریت کند.

برای مثال، اگر سامانه سفارش‌گیری یک شرکت از دسترس خارج شود، وجود یک راهکار از پیش تعیین‌شده برای ثبت سفارش‌ها، اطلاع‌رسانی به مشتریان و ادامه موقت فعالیت‌ها می‌تواند از گسترش خسارت جلوگیری کند.

3.2. محافظت از درآمد و کاهش زیان مالی

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

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

البته میزان کاهش زیان مالی به نوع حادثه و اثربخشی راهکارهای اجراشده بستگی دارد و نباید آن را نتیجه‌ای تضمین‌شده دانست.

3.3. افزایش آمادگی برای بحران‌های غیرقابل‌پیش‌بینی

اختلال ممکن است ناشی از عوامل مختلفی باشد؛ از جمله:

• حملات سایبری و باج‌افزارها
• خرابی سخت‌افزار، نرم‌افزار یا زیرساخت شبکه
• قطع برق یا اختلال در ارتباطات
• بلایای طبیعی مانند سیل، زلزله و آتش‌سوزی
• از دست رفتن دسترسی به محل کار
• بیماری گسترده یا کمبود نیروی انسانی کلیدی
• اختلال در زنجیره تأمین یا خدمات ابری
• خطاهای انسانی و تغییرات فنی ناموفق

یک BCMS مناسب، سازمان را برای سناریوهای مرتبط با شرایط واقعی خودش آماده می‌کند؛ نه صرفاً برای یک حادثه از پیش انتخاب‌شده.

3.4. حفظ اعتماد مشتریان و ذی‌نفعان

مشتریان و شرکای تجاری انتظار دارند خدمات مهم در زمان اختلال نیز تا حد امکان در دسترس باقی بمانند یا در چارچوب زمانی مشخصی بازیابی شوند.

وجود برنامه‌های قابل‌اجرا، مسئولیت‌های مشخص و سازوکار ارتباطات بحران به سازمان کمک می‌کند در زمان حادثه، اطلاع‌رسانی دقیق‌تری داشته باشد و تصمیم‌های خود را با انسجام بیشتری اجرا کند.

3.5. پشتیبانی از الزامات قانونی و قراردادی

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

BCMS می‌تواند به شناسایی و مدیریت این الزامات کمک کند. بااین‌حال، نباید فرض کرد که صرف پیاده‌سازی ISO 22301 تمام الزامات قانونی یا مقرراتی سازمان را برآورده می‌کند؛ این موضوع به قوانین مربوط، دامنه سیستم و شواهد انطباق بستگی دارد.

3.6. تصمیم‌گیری بهتر در شرایط بحران

هنگامی که اختلال رخ می‌دهد، سازمان باید درباره اولویت‌ها، تخصیص منابع، توقف یا ادامه خدمات، اطلاع‌رسانی و زمان بازیابی تصمیم بگیرد.

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

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

3.7. شناسایی وابستگی‌های پنهان

گاهی یک فعالیت ظاهراً ساده به مجموعه‌ای از سامانه‌ها و خدمات وابسته است. برای مثال، فرایند صدور فاکتور ممکن است به سامانه هویت، پایگاه داده مشتریان، سرویس پرداخت، ارتباط شبکه و ارائه‌دهنده ابری وابسته باشد.

تحلیل این وابستگی‌ها می‌تواند نقاط شکست مشترک و گلوگاه‌هایی را آشکار کند که در بررسی جداگانه هر سامانه دیده نمی‌شوند.

4. ارتباط BCMS با امنیت سایبری

در سازمان‌های دیجیتال، تداوم کسب‌وکار و امنیت سایبری ارتباط مستقیمی دارند؛ اما یکسان نیستند.

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

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

از سوی دیگر، وجود برنامه تداوم کسب‌وکار نیز جایگزین کنترل‌های امنیتی، مدیریت آسیب‌پذیری، نظارت امنیتی یا پاسخ‌گویی به رخدادها نیست.

BCMS از منظر امنیت سایبری، پیوند میان آمادگی سازمانی، مدیریت اختلال، پاسخ‌گویی هماهنگ و بازیابی امن خدمات را تقویت می‌کند.

4.1. تهدیدهای سایبری چگونه تداوم کسب‌وکار را مختل می‌کنند؟

حملات باج‌افزاری

در حمله باج‌افزاری، مهاجم ممکن است فایل‌ها یا سامانه‌ها را رمزگذاری کند، نسخه‌های پشتیبان در دسترس را از بین ببرد یا پیش از رمزگذاری، اطلاعات حساس را خارج کند.

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

راهنمای مشترک CISA و MS-ISAC درباره باج‌افزار بر اهمیت پشتیبان‌گیری آفلاین و رمزگذاری‌شده، آزمون منظم نسخه‌های پشتیبان، برنامه پاسخ به رخداد و بازیابی اولویت‌بندی‌شده تأکید می‌کند.

حملات منع سرویس توزیع‌شده (DDoS)

در حملات DDoS، حجم بالای ترافیک مخرب می‌تواند دسترسی کاربران به خدمات را مختل کند.

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

نفوذ به حساب‌های مدیریتی و زیرساخت هویت

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

به همین دلیل، دسترس‌پذیری و امنیت زیرساخت هویت، حساب‌های اضطراری، کلیدهای رمزنگاری و مسیرهای مدیریتی باید در برنامه‌ریزی بازیابی لحاظ شوند.

تخریب یا دست‌کاری اطلاعات

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

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

اختلال در خدمات ابری و تأمین‌کنندگان

سازمان‌ها ممکن است برای ذخیره‌سازی اطلاعات، احراز هویت، ارتباطات، پردازش یا ارائه خدمات به تأمین‌کنندگان بیرونی وابسته باشند.

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

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

4.2. BCMS چگونه با پاسخ به رخدادهای امنیتی ارتباط پیدا می‌کند؟

مدیریت رخداد امنیتی، تداوم کسب‌وکار و بازیابی از فاجعه، فعالیت‌های مرتبط اما دارای اهداف متفاوت هستند.

پاسخ به رخداد امنیتی (Incident Response) بر شناسایی، تحلیل، مهار، ریشه‌کنی و مدیریت پیامدهای رخداد امنیتی تمرکز دارد. تداوم کسب‌وکار تعیین می‌کند که فعالیت‌های حیاتی در زمان اختلال چگونه ادامه یابند یا با چه اولویتی از سر گرفته شوند. بازیابی فناوری نیز بر بازگرداندن سامانه‌ها و خدمات فنی تمرکز دارد.

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

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

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

4.3. نقش ISO/IEC 27031 در آمادگی فناوری اطلاعات برای تداوم کسب‌وکار

استاندارد ISO/IEC 27031:2025 با عنوان Cybersecurity — Information and communication technology readiness for business continuity به آمادگی فناوری اطلاعات و ارتباطات برای پشتیبانی از تداوم کسب‌وکار می‌پردازد.

این استاندارد در مقایسه با ISO 22301 تمرکز تخصصی‌تری بر آمادگی ICT دارد و می‌تواند در هماهنگ‌کردن نیازهای کسب‌وکار با قابلیت‌های فنی بازیابی مفید باشد.

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

این استاندارد در کنار ISO 22301 و استانداردهای مدیریت امنیت اطلاعات، می‌تواند به ایجاد رویکردی یکپارچه برای تداوم خدمات دیجیتال کمک کند.

4.4. ارتباط BCMS با چارچوب امنیت سایبری NIST

چارچوب امنیت سایبری NIST نسخه 2.0، امنیت سایبری را در شش کارکرد اصلی سازمان‌دهی می‌کند: حاکمیت (Govern)، شناسایی (Identify)، حفاظت (Protect)، تشخیص (Detect)، پاسخ (Respond) و بازیابی (Recover).

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

BCMS می‌تواند با این کارکردها هم‌راستا شود؛ به‌ویژه در زمینه تعیین اولویت خدمات، تعریف مسئولیت‌ها، آماده‌سازی منابع بازیابی و آزمودن توانایی سازمان برای بازگشت به عملیات.

بااین‌حال، NIST CSF و ISO 22301 جایگزین یکدیگر نیستند. چارچوب NIST راهنمایی برای مدیریت ریسک امنیت سایبری فراهم می‌کند، درحالی‌که ISO 22301 الزامات سیستم مدیریت تداوم کسب‌وکار را مشخص می‌سازد.

5. تفاوت BCMS، BCP و DRP چیست؟

یکی از مهم‌ترین نکات در حوزه تداوم کسب‌وکار، تفکیک درست سه اصطلاح BCMS، BCP و DRP است. استفاده نادرست از این اصطلاحات می‌تواند باعث شود سازمان تصور کند با داشتن یک برنامه بازیابی فناوری اطلاعات، تمام الزامات تداوم کسب‌وکار را پوشش داده است.

5.1. BCMS؛ سیستم مدیریت تداوم کسب‌وکار

BCMS مخفف Business Continuity Management System است و به کل سیستم مدیریتی تداوم کسب‌وکار اشاره دارد.

این سیستم شامل سیاست‌ها، مسئولیت‌ها، تحلیل اثرات کسب‌وکار، ارزیابی ریسک، راهبردها، برنامه‌ها، آموزش، تمرین، پایش و بهبود مستمر است.

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

5.2. BCP؛ طرح تداوم کسب‌وکار

BCP مخفف Business Continuity Plan است و سند یا مجموعه‌ای از رویه‌های اجرایی است که اقدامات موردنیاز برای ادامه یا بازیابی فعالیت‌های کسب‌وکار در زمان اختلال را مشخص می‌کند.

یک BCP می‌تواند شامل موارد زیر باشد:

• مسئولیت‌ها و اختیارات افراد در شرایط اختلال؛
• معیارهای فعال‌سازی برنامه؛
• اولویت فعالیت‌ها و خدمات حیاتی؛
• روش‌های ادامه موقت عملیات؛
• منابع و محل‌های جایگزین؛
• روش‌های ارتباط با کارکنان، مشتریان و تأمین‌کنندگان؛
• معیارهای بازگشت به عملیات عادی.

BCP یکی از خروجی‌ها و اجزای عملیاتی BCMS است؛ اما به‌تنهایی معادل کل سیستم مدیریتی نیست.

بیشتر بخوانید: طرح تداوم کسب‌وکار (BCP) چیست؟

5.3. DRP؛ طرح بازیابی از فاجعه

DRP مخفف Disaster Recovery Plan است و معمولاً به برنامه‌ای برای بازیابی زیرساخت‌ها، سامانه‌ها، داده‌ها و خدمات پس از یک اختلال شدید اشاره دارد.

در سازمان‌های مبتنی بر فناوری، DRP اغلب بر بازیابی مراکز داده، ماشین‌های مجازی، پایگاه‌های داده، شبکه، ذخیره‌سازی، سرویس‌های ابری و سایر اجزای فنی تمرکز می‌کند.

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

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

بیشتر بخوانید: طرح بازیابی از فاجعه (DRP) چیست؟

5.4. یک مثال عملی برای درک تفاوت‌ها

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

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

نقش BCP: برنامه تداوم مشخص می‌کند که در زمان اختلال، چگونه سفارش‌های ضروری مدیریت شوند، چه روش جایگزینی برای ارتباط با مشتریان وجود داشته باشد، چه افرادی مسئول هماهنگی باشند و چه اطلاعاتی به ذی‌نفعان اطلاع داده شود.

نقش DRP: برنامه بازیابی از فاجعه مشخص می‌کند که چگونه زیرساخت آسیب‌دیده ایمن‌سازی و بازسازی شود، نسخه پشتیبان معتبر انتخاب شود، پایگاه داده بازیابی شود و سرویس سفارش‌گیری پس از بررسی‌های امنیتی دوباره راه‌اندازی شود.

این سه نقش مکمل یکدیگرند.

1. اگر فقط DRP وجود داشته باشد، ممکن است تیم فناوری بتواند سامانه‌ها را بازیابی کند، اما سازمان برای ادامه عملیات در فاصله زمانی بازیابی برنامه‌ای نداشته باشد.
2. اگر فقط BCP وجود داشته باشد، روش‌های ادامه موقت فعالیت ممکن است مشخص باشند، اما جزئیات فنی بازسازی زیرساخت ناقص بمانند.
3. اگر هیچ‌یک در یک سیستم مدیریتی مستمر نگهداری و آزموده نشوند، احتمال کهنه‌شدن برنامه‌ها و ناکارآمدی آن‌ها افزایش می‌یابد.

5.5. آیا DRP همیشه زیرمجموعه BCP است؟

از نظر مفهومی، BCP بر تداوم فعالیت‌های کسب‌وکار و DRP بر بازیابی از فاجعه تمرکز دارد. در بسیاری از سازمان‌ها، برنامه بازیابی فناوری اطلاعات در چارچوب برنامه‌ریزی تداوم کسب‌وکار توسعه داده می‌شود.

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

بنابراین، گزاره دقیق این است که DRP باید با اهداف تداوم کسب‌وکار هم‌راستا باشد و در ساختار کلی BCMS تعریف شود؛ نه اینکه در همه سازمان‌ها الزاماً یک سند مستقل یا بخشی با عنوان ثابت داشته باشد.

راهنمای NIST SP 800-34 Rev. 1 درباره برنامه‌ریزی اقتضایی سامانه‌های اطلاعاتی، ارتباط برنامه‌های فناوری اطلاعات با سایر برنامه‌های اضطراری، امنیتی و تداوم سازمان را بررسی می‌کند و برای درک این تفکیک منبع مفیدی است.

6. مفاهیم کلیدی در طراحی BCMS برای محیط‌های سایبری

برای طراحی یک BCMS قابل‌دفاع، لازم است چند مفهوم فنی به‌درستی تعریف شوند. این مفاهیم به تعیین اولویت‌ها و سنجش قابلیت واقعی بازیابی کمک می‌کنند.

6.1. تحلیل اثرات کسب‌وکار (BIA)

تحلیل اثرات کسب‌وکار یا Business Impact Analysis فرایندی برای شناسایی فعالیت‌های سازمان و ارزیابی پیامدهای اختلال در آن‌ها در طول زمان است.

BIA به این پرسش پاسخ می‌دهد که توقف هر فعالیت چه اثری بر سازمان می‌گذارد و این اثر در چه زمانی به سطح غیرقابل‌قبول می‌رسد.

در یک BIA مناسب، صرفاً فهرست‌کردن سامانه‌های فناوری اطلاعات کافی نیست. باید خدمات و فرایندهای کسب‌وکار، وابستگی‌های آن‌ها به نیروی انسانی، اطلاعات، زیرساخت، مکان و تأمین‌کنندگان و نیز پیامدهای توقف آن‌ها بررسی شود.

برای مثال، ممکن است سامانه گزارش‌گیری مدیریتی برای چند ساعت قابل‌جایگزینی باشد، اما سامانه پردازش تراکنش‌ها تنها برای مدت بسیار کوتاهی امکان توقف داشته باشد.

BIA به تعیین اولویت‌های بازیابی و اهداف زمانی کمک می‌کند؛ درحالی‌که ارزیابی ریسک بیشتر بر شناسایی و تحلیل سناریوهای تهدیدکننده تمرکز دارد. این دو فرایند مکمل یکدیگرند، اما یکسان نیستند.

6.2. هدف زمانی بازیابی (RTO)

RTO مخفف Recovery Time Objective است و هدف زمانی تعیین‌شده برای بازیابی یک فعالیت، سامانه یا خدمت پس از اختلال را بیان می‌کند.

برای مثال، اگر برای یک خدمت RTO برابر با چهار ساعت تعیین شود، هدف برنامه‌ریزی این است که آن خدمت در چارچوب زمانی توافق‌شده، حداکثر ظرف چهار ساعت به سطح عملیاتی موردنظر بازگردد.

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

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

6.3. نقطه هدف بازیابی (RPO)

RPO مخفف Recovery Point Objective است و حداکثر میزان از دست رفتن داده را برحسب زمان بیان می‌کند که سازمان در سناریوی بازیابی برای یک سامانه یا خدمت در نظر گرفته است.

برای مثال، RPO برابر با ۱۵ دقیقه به این معناست که راهکار بازیابی باید با هدف محدودکردن از دست رفتن داده به بازه‌ای در حدود ۱۵ دقیقه طراحی شود؛ البته دستیابی واقعی به این هدف به معماری ثبت و تکثیر داده، سازوکار پشتیبان‌گیری و شرایط حادثه وابسته است.

RPO با RTO تفاوت دارد:

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

6.4. حداکثر مدت قابل‌تحمل اختلال (MTPD)

MTPD مخفف Maximum Tolerable Period of Disruption است و به حداکثر مدتی اشاره دارد که سازمان می‌تواند اختلال در یک فعالیت را تحمل کند، پیش از آنکه پیامدهای آن غیرقابل‌قبول شوند.

در تحلیل اثرات کسب‌وکار، این مفهوم به تعیین فوریت بازیابی کمک می‌کند.

RTO و MTPD نباید به‌جای یکدیگر استفاده شوند. MTPD حد تحمل اختلال از دیدگاه کسب‌وکار را بیان می‌کند، درحالی‌که RTO هدف زمانی بازیابی است. در طراحی مناسب، RTO باید با در نظر گرفتن MTPD و نیاز به زمان لازم برای اعتبارسنجی، تثبیت و بازگشت به عملیات عادی تعیین شود.

6.5. ارتباط RTO و RPO با پشتیبان‌گیری و بازیابی سایبری

فرض کنید سازمانی هر ۲۴ ساعت از پایگاه داده خود نسخه پشتیبان تهیه می‌کند، درحالی‌که هدف RPO آن ۱۵ دقیقه است.

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

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

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

7. مراحل پیاده‌سازی سیستم مدیریت تداوم کسب‌وکار

پیاده‌سازی BCMS باید بر اساس دامنه مشخص، اولویت‌های کسب‌وکار و الزامات قابل‌اعمال سازمان انجام شود. مراحل زیر یک مسیر عملی برای اجرای این سیستم ارائه می‌کند.

مرحله اول: تعیین دامنه و شناخت سازمان

در آغاز باید مشخص شود که BCMS کدام واحدها، خدمات، فرایندها، سامانه‌ها و مکان‌ها را پوشش می‌دهد.

شناخت ذی‌نفعان، الزامات قانونی و قراردادی، وابستگی‌های بیرونی و محدودیت‌های عملیاتی نیز در این مرحله اهمیت دارد.

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

مرحله دوم: تعهد مدیریت ارشد و تعیین مسئولیت‌ها

تداوم کسب‌وکار فقط مسئولیت تیم فناوری اطلاعات یا واحد امنیت نیست. مدیریت ارشد باید اهداف و اولویت‌ها را تأیید کند و مسئولیت‌ها و اختیارات لازم را در اختیار افراد مرتبط قرار دهد.

در این مرحله باید نقش مالکان فرایندهای حیاتی، مسئول تداوم کسب‌وکار، تیم پاسخ به رخداد، تیم فناوری، منابع انسانی، روابط عمومی و مسئولان ارتباط با تأمین‌کنندگان مشخص شود.

در رخدادهای بزرگ، ابهام درباره اختیار تصمیم‌گیری می‌تواند به‌اندازه کمبود منابع فنی مشکل‌ساز باشد.

مرحله سوم: اجرای تحلیل اثرات کسب‌وکار

در این مرحله، فعالیت‌های سازمان، پیامدهای توقف، وابستگی‌ها و اهداف بازیابی تحلیل می‌شوند.

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

مرحله چهارم: ارزیابی ریسک و سناریوهای اختلال

پس از شناخت اثرات، سازمان باید سناریوهای مهم اختلال را ارزیابی کند.

این سناریوها می‌توانند شامل حملات سایبری، از دست رفتن دسترسی مدیریتی، خرابی زیرساخت، قطع برق، اختلال ارائه‌دهنده ابری یا از دست رفتن محل عملیاتی باشند.

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

ارزیابی ریسک باید با توجه به تهدیدهای مرتبط، آسیب‌پذیری‌ها، کنترل‌های موجود و پیامدهای احتمالی انجام شود. نتیجه آن به انتخاب راهبردهای متناسب کمک می‌کند.

مرحله پنجم: انتخاب راهبردهای تداوم و بازیابی

در این مرحله، سازمان راهکارهایی را انتخاب می‌کند که بتوانند نیازهای شناسایی‌شده را پوشش دهند.

راهکارها ممکن است شامل موارد زیر باشند:

• استفاده از محل یا زیرساخت جایگزین
• ادامه موقت برخی فرایندها به‌صورت دستی
• افزونگی در زیرساخت و ارتباطات
• پشتیبان‌گیری و تکثیر داده؛
• ایجاد محیط بازیابی جداگانه
• استفاده از ظرفیت جایگزین برای ارائه خدمات
• توافق‌های پشتیبانی با تأمین‌کنندگان
• حفظ دانش و دسترسی‌های ضروری برای بازیابی.

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

مرحله ششم: تدوین BCP و DRP

پس از تعیین راهبردها، برنامه‌های اجرایی تدوین می‌شوند.

BCP باید نحوه مدیریت تداوم فعالیت‌های کسب‌وکار را مشخص کند. DRP نیز باید روش بازیابی زیرساخت‌ها و خدمات فنی را با جزئیات کافی شرح دهد.

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

در سناریوهای سایبری، لازم است بازیابی با پاسخ به رخداد هماهنگ باشد تا سامانه‌های آلوده یا اعتبارنامه‌های به‌خطر‌افتاده دوباره وارد محیط عملیاتی نشوند.

مرحله هفتم: آموزش و آزمون برنامه‌ها

برنامه‌ای که فقط نوشته شده باشد، لزوماً قابل‌اجرا نیست. کارکنان باید بدانند در زمان اختلال چه مسئولیتی دارند و تصمیم‌ها چگونه اتخاذ می‌شوند.

آزمون‌ها می‌توانند از مرور مستندات و تمرین‌های رومیزی آغاز شوند و تا شبیه‌سازی‌های فنی و آزمون‌های بازیابی واقعی ادامه پیدا کنند.

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

مرحله هشتم: ارزیابی عملکرد و بهبود مستمر

پس از تمرین یا رخداد واقعی، نتایج باید بررسی شوند.

آیا اهداف RTO و RPO محقق شدند؟ آیا مسئولیت‌ها روشن بودند؟ آیا نسخه‌های پشتیبان قابل‌استفاده بودند؟ آیا وابستگی‌های بیرونی درست شناسایی شده بودند؟ آیا ارتباطات در زمان بحران به‌موقع انجام شدند؟

پاسخ به این پرسش‌ها باید به اقدامات اصلاحی مشخص، مسئولیت تعیین‌شده و زمان‌بندی اجرا منجر شود.

BCMS زمانی ارزش عملیاتی دارد که از نتایج آزمون‌ها و رخدادهای واقعی برای بهبود آمادگی استفاده کند.

8. الزامات مهم BCMS در محیط‌های امنیت سایبری

در محیط‌های دیجیتال، چند ملاحظه فنی باید به‌طور ویژه در برنامه‌ریزی تداوم و بازیابی لحاظ شوند.

8.1. طراحی پشتیبان‌گیری مقاوم در برابر باج‌افزار

پشتیبان‌گیری یکی از اجزای مهم بازیابی است، اما وجود نسخه پشتیبان به‌تنهایی برای اثبات آمادگی کافی نیست.

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

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

8.2. جداسازی محیط بازیابی

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

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

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

8.3. بازیابی امن، نه صرفاً بازیابی سریع

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

بنابراین، برنامه بازیابی باید تعادلی روشن میان سرعت و اطمینان امنیتی برقرار کند. بررسی دامنه نفوذ، مهار تهدید، اعتبارسنجی داده‌ها و کنترل دسترسی‌ها ممکن است پیش‌شرط اتصال مجدد سامانه‌ها باشد.

8.4. مدیریت هویت و دسترسی اضطراری

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

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

این دسترسی‌ها باید کنترل‌شده، قابل‌ردیابی و به‌صورت دوره‌ای آزموده شوند.

8.5. مدیریت وابستگی به تأمین‌کنندگان

بازیابی ممکن است به سرویس‌هایی خارج از کنترل مستقیم سازمان وابسته باشد؛ مانند ارائه‌دهنده ابری، اپراتور ارتباطی، شرکت پرداخت یا تأمین‌کننده نرم‌افزار.

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

وجود قرارداد یا توافق سطح خدمت به‌تنهایی تضمین نمی‌کند که تأمین‌کننده در تمام سناریوها قادر به برآورده‌کردن نیازهای سازمان باشد. این وابستگی‌ها باید ارزیابی و در صورت امکان آزموده شوند.

8.6. حفظ شواهد و هماهنگی با الزامات قانونی

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

برنامه‌های پاسخ و بازیابی باید به‌گونه‌ای هماهنگ شوند که اقدامات اضطراری، تا حد امکان، باعث از بین رفتن شواهد مهم نشوند.

روش دقیق نگهداری شواهد، گزارش‌دهی و اطلاع‌رسانی باید با توجه به نوع حادثه، الزامات قانونی، قراردادها و سیاست‌های سازمان تعیین شود.

9. چگونه اثربخشی BCMS را اندازه‌گیری کنیم؟

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

شاخص‌های قابل استفاده، بسته به دامنه و ماهیت سازمان، می‌توانند شامل موارد زیر باشند:

• درصد خدمات حیاتی دارای BIA به‌روز
• درصد خدمات حیاتی دارای اهداف بازیابی مصوب
• درصد برنامه‌هایی که در بازه زمانی تعیین‌شده آزموده شده‌اند
• میزان تحقق RTO و RPO در آزمون‌های معتبر
• درصد نسخه‌های پشتیبانی که بازیابی موفق آن‌ها تأیید شده است
• مدت زمان رفع یافته‌های مهم آزمون‌ها
• میزان پوشش وابستگی‌های حیاتی به تأمین‌کنندگان
• میزان آگاهی کارکنان از نقش‌های اضطراری
• تعداد نقاط ضعف تکرارشونده شناسایی‌شده در تمرین‌ها.

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

10. اشتباهات رایج در پیاده‌سازی BCMS

اشتباه اول: برابر دانستن BCMS با برنامه تداوم کسب‌وکار

تهیه یک BCP بدون ایجاد سازوکار راهبری، ارزیابی، آموزش، آزمون و بهبود، به معنای استقرار کامل BCMS نیست.

اشتباه دوم: محدود کردن تداوم کسب‌وکار به فناوری اطلاعات

فناوری اطلاعات اهمیت زیادی دارد، اما نیروی انسانی، فرایندهای عملیاتی، مکان‌ها، ارتباطات و تأمین‌کنندگان نیز باید در دامنه تحلیل قرار گیرند.

اشتباه سوم: فرض اینکه نسخه پشتیبان برای بازیابی کافی است

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

اشتباه چهارم: تعیین RTO و RPO بدون تحلیل

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

اشتباه پنجم: آزمون نکردن برنامه‌ها

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

اشتباه ششم: نادیده گرفتن امنیت در زمان بازیابی

اگر بازیابی بدون بررسی سلامت محیط و کنترل دسترسی انجام شود، احتمال بازگشت مهاجم یا آلودگی مجدد وجود دارد.

اشتباه هفتم: تصور اینکه انطباق با استاندارد، تضمین تداوم است

استاندارد چارچوبی برای مدیریت و ارزیابی فراهم می‌کند؛ اما موفقیت در هر حادثه به عوامل واقعی مانند منابع، سناریوی اختلال، کیفیت راهکارها و عملکرد تیم‌ها وابسته است.

11. چک‌لیست اولیه ارزیابی آمادگی BCMS

برای ارزیابی مقدماتی آمادگی سازمان، می‌توان پرسش‌های زیر را بررسی کرد:

• آیا دامنه سیستم مدیریت تداوم کسب‌وکار مشخص و تأیید شده است؟
• آیا فعالیت‌های حیاتی و وابستگی‌های آن‌ها شناسایی شده‌اند؟
• آیا تحلیل اثرات کسب‌وکار و ارزیابی ریسک مستند و به‌روز هستند؟
• آیا RTO و RPO خدمات مهم بر اساس نیازهای واقعی تعیین شده‌اند؟
• آیا برنامه‌های تداوم کسب‌وکار و بازیابی فناوری با یکدیگر هماهنگ هستند؟
• آیا مسئولیت‌ها و اختیارات تصمیم‌گیری در زمان بحران مشخص‌اند؟
• آیا نسخه‌های پشتیبان حیاتی در برابر حذف یا دست‌کاری غیرمجاز محافظت می‌شوند؟
• آیا بازیابی نسخه‌های پشتیبان در عمل آزموده شده است؟
• آیا سناریوهای باج‌افزار، از دست رفتن دسترسی مدیریتی و اختلال تأمین‌کنندگان بررسی شده‌اند؟
• آیا کارکنان آموزش دیده‌اند و برنامه‌ها در تمرین‌های متناسب آزموده شده‌اند؟
• آیا یافته‌های آزمون‌ها ثبت و تا زمان رفع پیگیری می‌شوند؟
• آیا تغییرات مهم در زیرساخت، خدمات، تأمین‌کنندگان و تهدیدها موجب بازبینی برنامه‌ها می‌شوند؟

12. جمع‌بندی: BCMS چه ارزشی برای سازمان ایجاد می‌کند؟

سیستم مدیریت تداوم کسب‌وکار چارچوبی برای تبدیل آمادگی در برابر اختلال از یک اقدام مقطعی به یک قابلیت سازمانی مستمر است.

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

در محیط‌های وابسته به فناوری، این سیستم باید با امنیت سایبری، پاسخ به رخدادها، مدیریت زیرساخت و برنامه‌های بازیابی فنی ارتباط داشته باشد. بازیابی سریع بدون اطمینان کافی از سلامت محیط می‌تواند خطرناک باشد؛ همان‌طور که کنترل‌های امنیتی بدون برنامه تداوم، لزوماً مانع توقف خدمات نمی‌شوند.

تمایز میان سه مفهوم اصلی نیز ضروری است:

BCMS سیستم مدیریتی جامع است، BCP برنامه ادامه یا بازیابی فعالیت‌های کسب‌وکار است و DRP برنامه بازیابی از فاجعه با تمرکز رایج بر سامانه‌ها و زیرساخت‌های فنی است.

این سه مفهوم در کنار یکدیگر معنا پیدا می‌کنند و باید متناسب با نیازهای سازمان طراحی، هماهنگ و آزموده شوند.

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