MedaGRC
در بحران، همه سرویس‌ها نمی‌توانند هم‌زمان اولویت اول باشند. اگر هر واحد بگوید سامانه خودش حیاتی است، تیم فناوری و مدیریت بحران نمی‌دانند منابع محدود بازیابی را کجا مصرف کنند. BIA یا Business Impact Analysis برای حل همین مسئله است.
BIA بررسی می‌کند توقف یک فرایند، سرویس یا فعالیت در گذر زمان چه اثری بر سازمان دارد و از چه نقطه‌ای این اثر غیرقابل قبول می‌شود.
BIA با Risk Assessment فرق دارد
Risk Assessment می‌پرسد «چه چیزی ممکن است اتفاق بیفتد و احتمال و اثر آن چیست؟» اما BIA بیشتر می‌پرسد «اگر این فعالیت متوقف شود، بعد از یک ساعت، چهار ساعت یا دو روز چه اتفاقی برای کسب‌وکار می‌افتد؟»
| موضوع | BIA | Risk Assessment |
|---|---|---|
| تمرکز | اثر توقف فعالیت | سناریوهای ریسک |
| خروجی | اولویت و اهداف بازیابی | سطح ریسک و Treatment |
| پرسش | تا چه زمانی می‌توانیم تحمل کنیم؟ | چه چیزی ممکن است رخ دهد؟ |
مرحله ۱: فرایند و سرویس را دقیق تعریف کنید
«واحد مالی» برای BIA بیش از حد کلی است. بهتر است فعالیت‌هایی مثل پرداخت حقوق، صدور فاکتور یا تسویه مشتریان جدا بررسی شوند. هر فعالیت می‌تواند وابستگی و تحمل توقف متفاوتی داشته باشد.
مرحله ۲: اثر توقف را در چند بُعد بسنجید
- مالی
- عملیاتی
- حقوقی و قراردادی
- اعتباری
- ایمنی و انسانی
- اثر بر مشتری
اثر معمولاً با گذشت زمان بیشتر می‌شود. توقف یک ساعت شاید قابل تحمل باشد اما توقف یک روز ممکن است بحران ایجاد کند.
مرحله ۳: وابستگی‌ها را پیدا کنید
فرایند حیاتی بدون وابستگی وجود ندارد. افراد، سامانه، Database، شبکه، محل کار، Vendor و حتی یک فایل مشترک می‌توانند Dependency باشند. BIA خوب این زنجیره را روشن می‌کند.
مرحله ۴: اهداف بازیابی را تعیین کنید
دو اصطلاح پرکاربرد RTO و RPO هستند. RTO زمان هدف برای بازیابی سرویس است و RPO میزان قابل تحمل از دست‌رفتن داده را نشان می‌دهد. این اعداد باید از نیاز کسب‌وکار بیایند، نه صرفاً از توان فعلی زیرساخت.
مرحله ۵: نتیجه را با واقعیت فنی مقایسه کنید
اگر کسب‌وکار RTO دو ساعت می‌خواهد اما تیم IT می‌گوید بازیابی Database حداقل شش ساعت زمان می‌برد، این اختلاف یک Gap واقعی است. باید Strategy، Control یا سرمایه‌گذاری تغییر کند.
سناریو: سامانه حقوق و دستمزد
فرض کنید توقف سامانه حقوق در روزهای عادی اثر متوسطی دارد، اما دو روز قبل از پرداخت حقوق اثر آن بسیار بیشتر می‌شود. BIA باید این حساسیت زمانی را ثبت کند. همچنین وابستگی به بانک، سیستم حضور و غیاب و فایل‌های منابع انسانی مشخص شود.
BIA باید Evidence داشته باشد
منبع اعداد، افراد تأییدکننده و تاریخ بازبینی باید ثبت شوند. اگر RTO فقط بر اساس حدس یک نفر نوشته شده باشد، در زمان بحران قابل دفاع نیست.
ارتباط BIA با GRC
خروجی BIA می‌تواند به Asset، Risk، Control و برنامه تداوم متصل شود. مقاله ISO 22301 و GRC توضیح می‌دهد چگونه نتیجه BIA وارد چرخه BCM می‌شود.
در MedaGRC هدف این است که اولویت کسب‌وکار، ریسک، کنترل و نتیجه آزمون بازیابی در یک مدل قابل ردیابی بمانند.
سخن پایانی
BIA قرار نیست یک جدول طولانی از همه فرایندهای سازمان تولید کند. هدف آن این است که در روز بحران، تصمیم سخت «اول چه چیزی را بازیابی کنیم؟» از قبل بر اساس اثر واقعی کسب‌وکار پاسخ داده شده باشد.
