سامانه قدیمی انبار به یک نسخه پشتیبانینشده وابسته است. تیم فنی ارتقا را پیشنهاد میکند، اما واحد کسبوکار میگوید تا پایان دوره عملیاتی امکان توقف ندارد. در صورتجلسه نوشته میشود «ریسک پذیرفته شد». سه ماه بعد، کسی نمیداند این تصمیم را چه فردی، برای چه مدتی و با اتکا به کدام کنترلها گرفته است.
پذیرش ریسک فناوری اطلاعات باید یک تصمیم آگاهانه و قابل پیگیری باشد، نه راهی برای بستن کارهای عقبافتاده. این مقاله، با استفاده از منابع ISACA و NIST، الگویی اجرایی برای ثبت مسئول، دامنه، شواهد و بازبینی تصمیم ارائه میکند. فرمها و دورههای پیشنهادی، طراحی عملیاتی هستند؛ نه نقل یک الزام یکسان برای همه سازمانها.
پذیرش ریسک با نادیده گرفتن مشکل فرق دارد
در توضیح ISACA درباره پاسخ به ریسک، پذیرش، کاهش، انتقال یا اشتراک و اجتناب، گزینههای متفاوت پاسخ هستند. پذیرش یعنی سازمان آگاهانه با سطحی از ریسک ادامه دهد؛ کاهش یعنی اقدامی برای کم کردن احتمال یا پیامد آن انجام شود. ممکن است بخشی از ریسک کاهش یابد و ریسک باقیمانده پذیرفته شود.
عبارت «فعلاً بودجه نداریم» ارزیابی ریسک نیست. باید روشن شود چه رویدادی ممکن است رخ دهد، کدام خدمت متأثر میشود و چرا ادامه وضعیت فعلی نسبت به گزینههای دیگر انتخاب شده است. وجود مشکل فنی و داشتن سناریوی ریسک دو چیز متفاوتاند؛ سناریو باید پیامد برای سازمان را هم توضیح دهد.
مالک ریسک چه کسی است؟
واژهنامه ISACA مالک ریسک را فردی با اختیار و پاسخگویی برای تصمیمهای مبتنی بر ریسک معرفی میکند. بنابراین کسی که یک آسیبپذیری را کشف کرده، الزاماً صاحب اختیار پذیرش پیامد آن نیست. کارشناس میتواند شواهد فنی را آماده کند؛ تصمیم باید در دامنه اختیار تعیینشده سازمان گرفته شود.
در الگوی پیشنهادی زیر، نقشها از هم تفکیک شدهاند. یک سازمان کوچک ممکن است چند نقش را به یک فرد بسپارد، اما این تجمیع باید روشن و با سیاست تعارض منافع سازگار باشد. نام یک واحد کلی، جای فرد یا نقش پاسخگوی مشخص را نمیگیرد.
| نقش | مسئولیت پیشنهادی | چه چیزی را نباید مفروض گرفت؟ |
|---|---|---|
| تحلیلگر ریسک | جمعآوری شواهد و توضیح احتمال و پیامد | اختیار پذیرش هر ریسک |
| مالک ریسک | پاسخگویی درباره سناریو و تصمیم در دامنه اختیار | انتقال مسئولیت به ابزار یا پیمانکار |
| مسئول کنترل | اجرای اقدام و ارائه شاهد اثربخشی | کافی بودن نصب ابزار بدون آزمون |
| مرجع تأیید | تصمیم درباره موارد خارج از اختیار مالک | تأیید نامحدود و بدون دامنه |
| مسئول بازبینی | پیگیری تغییر شرایط و اعتبار تصمیم | تمدید خودکار استثنا |
ریسک را به زبان خدمت بنویسید
به جای «سرور قدیمی است» بنویسید: «در صورت سوءاستفاده از ضعف شناختهشده در سامانه انبار، ثبت یا دسترسی به اطلاعات موجودی میتواند مختل شود و فرایند تحویل کالا تحت تأثیر قرار گیرد». سپس دارایی، وابستگی، کنترل موجود و محدوده عدم قطعیت را مشخص کنید. اگر اثر دقیق معلوم نیست، آن را تخمین قطعی معرفی نکنید.
راهنمای بازنگریشده NIST درباره شناسایی و برآورد ریسک، ثبت سناریوهای تهدید، آسیبپذیری، دارایی و پیامد را برای ارتباط با مدیریت ریسک سازمانی توضیح میدهد. نتیجه عملی این نگاه آن است که یک فهرست خطاهای فنی، بدون ارتباط با اهداف و خدمات، برای تصمیم مدیریتی کافی نیست.
پیش از پذیرش، گزینهها را مقایسه کنید
گزینهها فقط «ارتقای فوری» و «هیچ کاری نکنیم» نیستند. ممکن است محدود کردن دسترسی، جداسازی یک جزء یا اصلاح فرایند، بخشی از ریسک را کاهش دهد. هر گزینه باید از نظر امکان اجرا، هزینه، اثر بر خدمت و ریسک باقیمانده بررسی شود. وجود یک کنترل پیشنهادی تا زمانی که اجرا و آزمون نشده، دلیل کافی برای پایین آوردن امتیاز ریسک نیست.
NIST در راهنمای اولویتبندی ریسک، ارتباط انتخاب پاسخ و هزینه پیشبینیشده آن با اهداف سازمان و دفتر ثبت ریسک را مطرح میکند. این مقایسه کمک میکند تصمیم از یک مخالفت کلی با هزینه، به انتخاب میان گزینههای مشخص تبدیل شود.
کنترل جبرانی باید قابل اثبات باشد
برای مثال، عبارت «لاگها بررسی میشوند» زمانی معتبر است که جریان داده، مسئول بررسی و روش اعلان معلوم باشند. اگر دریافت لاگ قطع شده باشد، فرض نظارت فعال قابل اتکا نیست. راهنمای تشخیص قطع دریافت لاگهای امنیتی نمونهای از کنترل کیفیت شواهد است.
همین منطق درباره محدودسازی دسترسی صدق میکند. نوشتن شماره تیکت در فرم، الزاماً دسترسی را مجاز نمیکند؛ دسترسی مدیریتی با تیکت معتبر نشان میدهد چگونه باید شرط کنترل با آزمون واقعی تطبیق داده شود.
حداقل اطلاعات یک تصمیم قابل دفاع
| فیلد پیشنهادی | چه چیزی ثبت شود؟ |
|---|---|
| سناریو و دامنه | رویداد محتمل، خدمت متأثر و داراییهای مشمول |
| شواهد ارزیابی | منبع، تاریخ، روش برآورد و عدم قطعیت |
| کنترلهای موجود | کنترل اجراشده همراه نتیجه آزمون، نه صرفاً برنامه آینده |
| گزینههای بررسیشده | دلیل انتخاب یا کنار گذاشتن هر پاسخ |
| تصمیم و اختیار | مالک، مرجع تأیید و محدوده اختیار |
| شرایط اعتبار | تاریخ بازبینی، رویدادهای بازگشایی و محدودیتها |
| برنامه بعدی | اقدام کاهش، مسئول اجرا و وابستگی زمانی یا بودجهای |
برای استثنای موقت، پیشنهاد میشود تاریخ پایان یا بازبینی اجباری مشخص باشد. این پیشنهاد به معنای وجود یک مهلت استاندارد جهانی نیست؛ دوره مناسب باید با سرعت تغییر تهدید، اهمیت خدمت و سیاست سازمان تعیین شود. تصمیم بدون شرط اعتبار بهآسانی از یک استثنا به وضعیت دائمی تبدیل میشود.
چه زمانی باید تصمیم دوباره باز شود؟
افزایش دامنه استفاده از سامانه، تغییر نوع داده، شکست کنترل جبرانی، وقوع رخداد مرتبط یا عقب افتادن برنامه اصلاح، میتواند فرضهای تصمیم قبلی را تغییر دهد. در مدل اجرایی ما، هر کدام باید موجب بازبینی شود؛ حتی اگر تاریخ بازبینی دورهای هنوز نرسیده باشد.
تغییر مالک نیز مهم است. وقتی مدیر یا پیمانکار عوض میشود، پذیرش قدیمی نباید بدون انتقال مسئولیت معتبر فرض شود. فرد جدید باید دامنه، تعهدات و شواهد را دریافت کند و وضعیت تصمیم مطابق سازوکار سازمان بازبینی شود.
ارتباط این تصمیم با حاکمیت فناوری چیست؟
در مدل COBIT، هدفهای مرتبط با بهینهسازی ریسک و مدیریت ریسک، به ترتیب با شناسههای EDM03 و APO12 شناخته میشوند؛ این نامها در منبع رسمی ISACA درباره هدفهای چارچوب نیز آمدهاند. برداشت اجرایی برای این موضوع آن است که هم جهتگیری و حدود اختیار روشن باشد و هم فرایند روزمره ارزیابی و پیگیری کار کند.
لازم نیست برای هر ریسک کوچک جلسه هیئتمدیره برگزار شود. بهتر است ماتریس اختیار متناسب با اثر و دامنه تصمیم طراحی شود. موارد خارج از حدود تعیینشده باید به مرجع بالاتر ارجاع شوند. راهنمای طراحی حاکمیت متناسب با سازمان، مکمل این نگاه است.
پذیرش یک ریسک، پذیرش همه ریسکهای مشابه نیست
اگر یک استثنا برای یک سرور و یک دوره مشخص تصویب شده، نمیتوان آن را خودکار به همه شعب تعمیم داد. همچنین چند ریسک کوچک با وابستگی مشترک ممکن است در کنار هم پیامد بزرگی ایجاد کنند. گزارش باید این تجمع را نشان دهد؛ نه اینکه فقط هر ردیف را جداگانه سبز کند.
بازنگری اول NIST IR 8286 بر اتصال اطلاعات ریسک امنیت سایبری به فرایند مدیریت ریسک سازمانی و اهداف کسبوکار تأکید دارد. تصمیم محلی باید در این تصویر بزرگتر دیده شود. پذیرش داخلی نیز بهتنهایی اثبات رعایت تعهدات قراردادی یا الزامات بیرونی نیست؛ این موارد باید در مسیر بررسی تخصصی خود ارزیابی شوند.
ثبت دیجیتال تصمیم چه ویژگیهایی داشته باشد؟
فرم دیجیتال باید هویت تأییدکننده، نسخه ارزیابی، دامنه و تاریخ تصمیم را حفظ کند. تغییر متن ریسک بعد از تأیید نباید طوری انجام شود که تأیید قدیمی به ارزیابی جدید نسبت داده شود. دسترسی ویرایش، سوابق تغییر و اعلان بازبینی را متناسب با حساسیت اطلاعات طراحی کنید.
در سامانه میز خدمت یا ابزار سفارشی، بستن کار اجرایی را با حذف ریسک از دفتر ثبت یکی نکنید. نصب کنترل میتواند یک کار را تمام کند؛ کاهش واقعی ریسک پس از آزمون مشخص میشود. همچنین شمار تصمیمهای پذیرفتهشده، بهتنهایی شاخص موفقیت نیست؛ تصمیمهای بدون مسئول، منقضی و فاقد شاهد باید جدا گزارش شوند.
نکات کلیدی
- پذیرش ریسک، تصمیم آگاهانه با اختیار مشخص است؛ نه بستن یک تیکت.
- کنترل پیشنهادی را تا قبل از اجرا و آزمون، کنترل مؤثر گزارش نکنید.
- برای استثناهای موقت، شرایط اعتبار و محرکهای بازبینی تعیین کنید.
- ریسکهای وابسته را در سطح سازمان ببینید، نه فقط در ردیفهای جداگانه.
سخن پایانی
پذیرش ریسک، زمانی قابل دفاع است که سازمان بتواند توضیح دهد چه چیزی را، با کدام شواهد، تا چه زمانی و با مسئولیت چه کسی پذیرفته است. امضا بدون دامنه و بازبینی، ریسک را مدیریت نمیکند؛ فقط ابهام را به آینده منتقل میکند.
مدانت در حوزه حاکمیت فناوری و چارچوب COBIT، آموزش، مشاوره و طراحی فرایندهای مرتبط خدمات ارائه میدهد. برای تدوین ماتریس اختیار، دفتر ثبت ریسک و اتصال تصمیمها به اقدامات اصلاحی، از جلسه مشاوره مدانت استفاده کنید؛ شروع مناسب، یک سناریوی واقعی و مسئول پاسخگوی روشن است.
منابع
- واژهنامه ISACA
- توضیح پاسخ به ریسک
- شناسایی و برآورد ریسک در NIST IR 8286A بازنگری اول
- اولویتبندی و انتخاب پاسخ
- اتصال ریسک سایبری به ریسک سازمانی
