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

دو مفهوم کلیدی برای ساختن این مرزها Risk Appetite و Risk Tolerance هستند. Risk Appetite جهت کلی پذیرش ریسک را در ارتباط با اهداف سازمان تعیین می‌کند و Risk Tolerance این جهت را به حدودی تبدیل می‌کند که بتوان در عملیات روزانه سنجید، پایش کرد و برای عبور از آن اقدام مشخص داشت. NIST در مجموعه IR 8286 بر پیوند ریسک سایبری با Enterprise Risk Management و استفاده از Risk Register برای انتقال این تصمیم‌ها بین سطوح سازمان تأکید می‌کند.

سناریوی واقعی: سازمانی که هم سرعت می‌خواهد هم کنترل

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

اگر فقط گفته شود «برای نوآوری ریسک‌پذیر هستیم اما در امنیت محافظه‌کاریم»، تیم‌ها هنوز نمی‌دانند در عمل چه کنند. آیا دو ساعت Downtime قابل قبول است؟ آیا می‌توان Patch یک سامانه حیاتی را بدون Pilot منتشر کرد؟ آیا حساب ادمین موقت بدون MFA برای سه ساعت قابل پذیرش است؟ چه کسی اجازه دارد استثنا را بپذیرد؟ و این استثنا تا چه زمانی معتبر است؟

اینجاست که Appetite باید به Tolerance، Threshold، مالک و Trigger اجرایی تبدیل شود.

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

Capacity سقف تحمل واقعی سازمان است و Appetite معمولاً باید پایین‌تر از آن قرار بگیرد. Tolerance و Threshold نیز برای تبدیل سیاست به کنترل اجرایی به کار می‌آیند. اگر این لایه‌ها مخلوط شوند، سازمان ممکن است در سند ریسک «ریسک‌گریز» باشد اما در عملیات روزانه هیچ مرز قابل سنجشی نداشته باشد.

مرحله اول: Risk Appetite را از هدف کسب‌وکار شروع کنید

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

یک Appetite واحد برای همه چیز نسازید

سازمان می‌تواند در یک حوزه ریسک‌پذیر و در حوزه‌ای دیگر بسیار محافظه‌کار باشد. برای مثال:

• نوآوری: پذیرش متوسط برای آزمایش کنترل‌شده فناوری جدید در محیط غیرتولیدی؛
• امنیت اطلاعات: پذیرش بسیار پایین برای افشای داده حساس یا دسترسی ممتاز کنترل‌نشده؛
• تداوم خدمت: پذیرش پایین برای توقف سرویس‌های Tier-1؛
• تأمین‌کنندگان: پذیرش محدود برای وابستگی تک‌منبعی در سرویس بحرانی؛
• هزینه: پذیرش متوسط برای افزایش موقت هزینه در صورتی که ریسک عملیاتی را به‌طور قابل اندازه‌گیری کاهش دهد.

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

مرحله دوم: جمله مدیریتی را به Tolerance قابل سنجش تبدیل کنید

Appetite اگر قابل ترجمه به معیار نباشد، بیشتر یک بیانیه است تا ابزار تصمیم. مثلاً جمله «اشتهای ریسک ما برای اختلال سرویس پایین است» باید برای هر کلاس سرویس به عدد یا شرط قابل پایش تبدیل شود.

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

مرحله سوم: Appetite را وارد Risk Register کنید

Risk Register نباید فقط ستون «احتمال × اثر» داشته باشد. برای تصمیم‌گیری بهتر، هر ریسک باید نشان دهد در چه ارتباطی با Appetite قرار دارد و آیا Residual Risk پس از کنترل‌ها در محدوده Tolerance است یا نه.

حداقل اطلاعاتی که باید ثبت شود

• Risk Scenario روشن و قابل فهم؛
• هدف، سرویس یا دارایی تحت تأثیر؛
• Threat/Event و پیامد محتمل؛
• Inherent Risk پیش از کنترل؛
• کنترل‌های موجود و شواهد آن‌ها؛
• Residual Risk پس از کنترل؛
• مالک ریسک؛
• Appetite/Tolerance مرتبط؛
• وضعیت: داخل محدوده، نزدیک مرز یا خارج از محدوده؛
• Response و تاریخ بازبینی.

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

مرحله چهارم: قبل از عبور از Threshold، صاحب تصمیم را مشخص کنید

یکی از ضعف‌های متداول این است که سازمان Threshold دارد اما نمی‌داند وقتی از آن عبور شد چه کسی باید تصمیم بگیرد. مثلاً یک تیم SOC ممکن است Risk Score یا Severity را بالا تشخیص دهد، ولی اختیار پذیرش Business Risk را ندارد. یا تیم زیرساخت می‌تواند Downtime را اندازه بگیرد، اما مالک سرویس باید درباره پذیرش پیامد کسب‌وکار نظر بدهد.

برای هر Threshold حداقل این سه مورد را تعیین کنید: Owner، Escalation Path و زمان پاسخ. اگر ریسک خارج از Tolerance است، تصمیم باید یا به کاهش ریسک، اجتناب، انتقال یا پذیرش رسمی توسط سطح دارای اختیار منجر شود.

مرحله پنجم: Risk Appetite را به ابزارهای عملیاتی وصل کنید

ارزش Appetite زمانی دیده می‌شود که در کنسول‌های روزمره IT اثر بگذارد. نمونه‌های عملی عبارت‌اند از:

• Severity و Escalation در ITSM؛
• Approval Level برای Changeهای پرریسک؛
• RTO/RPO و Backup Schedule؛
• Threshold مانیتورینگ و Capacity؛
• Policyهای PAM و مدت دسترسی ممتاز؛
• Patch Ring، Pilot Group و Rollback Criteria؛
• Retention لاگ و الزام نگهداری شواهد؛
• SLA و OLA مرتبط با سرویس‌های بحرانی؛
• Vendor Risk و حد مجاز وابستگی.

در سازمان‌هایی که این ارتباط بین Risk Register، ISMS، ITSM و کنترل‌های PAM هنوز دستی و پراکنده است، مسئله معمولاً کمبود یک «فرم» نیست؛ مشکل طراحی مدل مالکیت و گردش تصمیم است. در چنین نقطه‌ای، یک جلسه ارزیابی و طراحی با مدانت می‌تواند روی همین اتصال بین Governance، کنترل و ابزار متمرکز شود، نه صرفاً خرید یک محصول.

مرحله ششم: Tolerance را با KRI و KPI اشتباه نگیرید

KPI می‌گوید عملکرد چگونه است؛ KRI نشانه افزایش یا کاهش Exposure را نشان می‌دهد؛ Tolerance می‌گوید چه میزان انحراف هنوز پذیرفته است. ممکن است یک KPI هنوز سبز باشد، اما یک KRI نشان دهد ریسک در حال نزدیک شدن به مرز تحمل است.

مثال عملی

فرض کنید Availability ماهانه هنوز بالاتر از SLA است، اما تعداد Failoverهای ناموفق در دو ماه اخیر افزایش یافته است. KPI ممکن است فعلاً خوب باشد، ولی KRI هشدار می‌دهد احتمال عبور از Tolerance در آینده نزدیک بالا رفته است. مدیریت ریسک بالغ فقط رخداد گذشته را نمی‌سنجد؛ نزدیک‌شدن به مرز را هم می‌بیند.

مرحله هفتم: استثناها را زمان‌دار کنید

هیچ Appetite Statement نباید راه را برای استثنای دائمی باز کند. اگر یک ریسک موقتاً پذیرفته می‌شود، باید دلیل، مالک، کنترل جبرانی، تاریخ انقضا و شرط بازبینی داشته باشد. نمونه روشن آن حساب Break-glass، تغییر اضطراری یا تمدید موقت استفاده از سیستم Legacy است.

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

مرحله هشتم: Appetite را با تغییر سازمان بازبینی کنید

Risk Appetite سندی برای یک بار تصویب نیست. رویدادهایی مانند ورود به بازار جدید، تغییر مقررات، ادغام شرکت‌ها، مهاجرت Cloud، تغییر معماری، رخداد امنیتی بزرگ یا تغییر مدل کسب‌وکار باید Trigger بازبینی باشند. علاوه بر آن، بازبینی دوره‌ای رسمی لازم است تا مدیریت ارشد تأیید کند مرزهای قبلی هنوز با واقعیت سازمان سازگارند.

چک‌لیست کنترل کیفیت Risk Appetite

نکات کلیدی

• Risk Appetite یک جهت مدیریتی است و Risk Tolerance مرز اجرایی آن.
• Appetite باید بر اساس هدف و نوع ریسک تفکیک شود؛ «ریسک‌گریز بودن» به‌تنهایی کافی نیست.
• Residual Risk باید با Tolerance مقایسه شود، نه فقط با ماتریس احتمال و اثر.
• Threshold بدون Owner و Escalation قابل اجرا نیست.
• KRI می‌تواند نزدیک‌شدن به مرز را قبل از نقض Tolerance نشان دهد.
• استثناهای ریسک باید کنترل جبرانی و تاریخ بازبینی داشته باشند.

سخن پایانی

اشتهای ریسک زمانی ارزشمند است که از یک جمله مدیریتی به زبان مشترک میان هیئت‌مدیره، مدیر فناوری، امنیت، عملیات و مالک سرویس تبدیل شود. سازمان بالغ فقط نمی‌پرسد «ریسک چقدر است؟»؛ می‌پرسد «این ریسک نسبت به مرزی که آگاهانه پذیرفته‌ایم کجاست، چه کسی صاحب تصمیم است و اگر از مرز عبور کرد دقیقاً چه اتفاقی باید بیفتد؟».

منابع

• NIST IR 8286A Rev. 1 — Identifying and Estimating Cybersecurity Risk for Enterprise Risk Management
• NIST SP 1303 — Cybersecurity Framework 2.0: Enterprise Risk Management Quick-Start Guide
• ISACA — Risk Appetite vs. Risk Tolerance