پارامترهای ارزیابی ریسک موثر برای ISO 27001

اگر دنبال این هستی که ارزیابی ریسک در ISO 27001 فقط «فرم پر کردن» نباشد و واقعاً در ممیزی Stage 1 و Stage 2 قابل دفاع باشد، باید از یک نکته ساده شروع کنیم: استاندارد از شما نمی‌خواهد صرفاً چند ریسک را لیست کنی؛ می‌خواهد یک روش ارزیابی ریسک داشته باشی که خروجی‌اش سازگار، قابل تکرار و قابل مقایسه باشد. یعنی اگر همین ارزیابی را یک ماه دیگر با همان ورودی‌ها انجام بدهی، نتیجه‌ات بی‌دلیل بالا و پایین نشود، و اگر ممیز پرسید «چرا این ریسک High شد؟» بتوانی با معیار مشخص جواب بدهی، نه با حس و تجربه شخصی.

در ISO 27001، ارزیابی ریسک (Risk Assessment) دقیقاً جایی است که مشخص می‌کنی «کدام تهدیدها واقعاً برای سازمان من مهم‌اند و چرا». اینجا دو خروجی کلیدی داری: اول اینکه معیارهای ارزیابی را تعریف می‌کنی (مثلاً احتمال و پیامد را چطور می‌سنجی، چه مقیاسی داری، و از چه سطحی به بعد ریسک برای تو غیرقابل قبول است). دوم اینکه نتیجه ارزیابی را مستند می‌کنی (سطح ریسک برای هر سناریو، مالک ریسک، کنترل‌های موجود و ریسک باقیمانده). اگر این دو خروجی شفاف نباشند، معمولاً کل سیستم ISMS در ممیزی به مشکل می‌خورد؛ چون ممیز در نهایت دنبال این است که ببیند تصمیم‌های امنیتی شما (انتخاب کنترل‌ها، اولویت‌ها، بودجه و برنامه‌ها) واقعاً از دل ریسک آمده یا نه.

پس قبل از اینکه برویم سراغ ماتریس ریسک یا عددگذاری، یک تعریف کوتاه داشته باشیم: پارامترهای ارزیابی ریسک یعنی همان متغیرهایی که باعث می‌شوند تصمیم‌گیری تو استاندارد و قابل دفاع شود؛ مثل تعریف مقیاس احتمال و اثر، معیار پذیرش ریسک، در نظر گرفتن کنترل‌های موجود، تعیین مالک ریسک، و ثبت ریسک ذاتی و ریسک باقیمانده. در ادامه مقاله، دقیقاً همین‌ها را طوری می‌چینیم که هم برای ساخت یک Risk Register واقعی به کارت بیاید، هم اگر فردا ممیز ازت Evidence خواست، بدانی باید چه چیزی نشان بدهی.

آپدیت مهم (۲۰۲۶): دوره گذار ISO/IEC 27001:2022 تمام شده است
اگر هدف شما «اخذ گواهینامه» یا «تمدید» است، یک نکته تاریخ‌دار را باید خیلی شفاف بدانید: استاندارد ISO/IEC 27001:2022 در اکتبر ۲۰۲۲ منتشر شد و طبق الزامات International Accreditation Forum (IAF)، دوره گذار آن تا 31 اکتبر 2025 بوده است. یعنی بعد از این تاریخ، گواهی‌های مبتنی بر نسخه 2013 عملاً باید به نسخه 2022 منتقل شده باشند.

دو تاریخ کلیدی که روی پروژه شما اثر مستقیم دارد

• تا 30 آوریل 2024: ممیزی‌های صدور اولیه/تمدید (Recertification) باید وارد مسیر نسخه 2022 می‌شدند.
• تا 31 اکتبر 2025: انتقال (Transition) سازمان‌هایی که قبلاً 2013 داشتند باید کامل می‌شد.

این یعنی چه برای شما؟ (خیلی عملی و بدون تعارف)

1. اگر تازه می‌خواهید گواهی بگیرید، مبنا ISO 27001:2022 است؛ پس خروجی‌های شما مثل Risk Register / Risk Treatment Plan / SoA باید با منطق 2022 قابل دفاع باشند (به‌خصوص SoA که باید با Annex A نسخه جدید هم‌خوان باشد).
2. اگر قبلاً گواهی 2013 داشته‌اید و هنوز Transition انجام نشده، ریسک «تعلیق/ابطال» یا حداقل «عدم پذیرش در مراقبتی/تمدید» بالا می‌رود؛ چون ضرب‌الاجل رسمی گذار گذشته است.

پیشنهاد سریع برای اینکه در ممیزی گیر نکنید
قبل از هر چیز، یک Gap Analysis کوتاه انجام دهید و بعد سه خروجی را همزمان اصلاح کنید:

• معیارهای ریسک (Risk Criteria) و روش امتیازدهی‌تان،
• برنامه درمان ریسک (RTP) با مالک/مهلت/شاخص اثربخشی،
• SoA با توجیه انتخاب/عدم انتخاب کنترل‌ها و شواهد اجرایی (Evidence).

چارچوب ارزیابی ریسک

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

شناسایی ریسک ها

رویکرد مبتنی بر دارایی در مقابل رویکرد مبتنی بر ریسک برای ارزیابی ریسک

پارامترهای حداقلی ریسک‌رجیستر (فیلدهای ممیزی‌پسند) + یک نمونه ردیف واقعی

اگر قرار باشد ممیز به ریسک‌رجیستر شما نگاه کند و در همان ۳–۵ دقیقه اول بفهمد «این ارزیابی ریسک واقعی است»، معمولاً دنبال یک چیز مشخص می‌گردد: آیا شما معیار دارید یا نه، و آیا برای هر ریسک، ردّ تصمیم (Decision trail) قابل پیگیری است یا نه. این یعنی ریسک‌رجیستر نباید فقط یک جدول “Threat/Impact” باشد؛ باید نشان بدهد ریسک از کجا آمده، چه کسی صاحبش است، کنترل‌های فعلی چه اثری دارند، ریسک باقیمانده چیست و تصمیم نهایی چه بوده.

در عمل، شما با 12–16 فیلدِ درست می‌توانی یک ریسک‌رجیستر کاملاً ممیزی‌پسند بسازی. کم‌تر از این هم می‌شود، ولی معمولاً یا تصمیم‌ها مبهم می‌شوند، یا ممیز مجبور می‌شود پشت هر ردیف چند سؤال باز کند (و آن وقت ریسکِ Nonconformity بالا می‌رود).

پارامترهای حداقلی که پیشنهاد می‌کنم (به زبان ساده و اجرایی) این‌هاست:

1) شناسه ریسک (Risk ID)
برای اینکه بتوانی در جلسات، اکشن پلن و شواهد، دقیقاً به همان ریسک ارجاع بدهی.

2) دارایی/فرآیند مرتبط (Asset / Process)
به جای اینکه همه چیز را کلی بنویسی، مشخص کن این ریسک روی چه دارایی یا فرآیند اثر دارد (مثلاً “CRM”، “پایگاه داده مشتریان”، “فرآیند صدور فاکتور”).

3) سناریوی ریسک (Threat + Vulnerability + Event)
این یکی خیلی مهم است: یک جمله‌ی سناریو محور بنویس، نه فقط “نشت اطلاعات”. مثال: «دسترسی غیرمجاز به CRM به‌علت رمزهای ضعیف و نبود MFA».

مطالعه پیشنهادی: سناریوهای ریسک / رویکرد سناریومحور

4) پیامد (Consequence)
اگر این اتفاق بیفتد، چه ضربه‌ای می‌خوری؟ بهتر است پیامد را در چند بعد ببینی (محرمانگی/تمامیت/دسترس‌پذیری + مالی/قانونی/اعتباری).

5) مالک ریسک (Risk Owner)
اسم نقش/سمت را بنویس (نه اسم شخص). مثلاً “مدیر فناوری اطلاعات”، “مدیر فروش”، “مدیر منابع انسانی”. ممیزی‌پسند یعنی مشخص باشد چه کسی تصمیم‌گیر و پاسخگو است.

6) کنترل‌های موجود (Existing Controls)
الان چه چیزی جلوی این ریسک را گرفته؟ مثال: “Password policy”، “Firewall”، “Access log”، “Role-based access”. اگر این ستون نباشد، ارزیابی شما ناقص دیده می‌شود.

7) اثربخشی کنترل‌های موجود (Control Effectiveness)
حداقل در ۳ سطح ساده (قوی/متوسط/ضعیف) یا عددی (1 تا 5). این ستون باعث می‌شود ممیز بفهمد شما کنترل‌ها را واقعاً سنجیده‌اید، نه اینکه صرفاً اسم‌شان را نوشته باشید.

8) احتمال (Likelihood) – قبل از درمان
بر اساس مقیاس تعریف‌شده‌ی خودتان (مثلاً 1 تا 5). مهم این است که “تعریف” احتمال را جای دیگر مقاله گفته باشید تا قابل دفاع شود.

9) پیامد/اثر (Impact) – قبل از درمان
باز هم طبق مقیاس خودتان. بهتر است معیار اثر را به زبان کسب‌وکار ببندی (پول/زمان توقف/جریمه/شکایت/از دست‌رفتن مشتری).

10) سطح ریسک ذاتی (Inherent Risk)
خروجی ضرب/ترکیب احتمال و اثر قبل از اینکه درمان جدیدی اضافه کنی.

11) معیار پذیرش (Risk Acceptance Criteria / Threshold)
لازم نیست این ستون برای هر ردیف جدا باشد؛ اما اگر داشته باشی عالی است. حداقل باید معلوم باشد کدام سطح‌ها “قابل قبول” و کدام “نیازمند درمان” هستند.

12) تصمیم درمان (Risk Treatment Decision)
یکی از این‌ها را شفاف انتخاب کن:

• کاهش/درمان (Mitigate/Treat)
• اجتناب (Avoid)
• انتقال/اشتراک (Transfer/Share)
• پذیرش (Accept)

13) کنترل‌های پیشنهادی/اقدامات درمان (Treatment Actions / Proposed Controls)
اینجا دقیقاً می‌گویی چه می‌خواهی اضافه/اصلاح کنی (مثلاً “فعال‌سازی MFA”، “سخت‌سازی دسترسی‌ها”، “بازنگری نقش‌ها”).

14) برنامه/زمان‌بندی و وضعیت (Due Date / Status)
تاریخ، وضعیت (Open/In progress/Done) و اگر خواستی اولویت.

15) ریسک باقیمانده (Residual Risk)
بعد از اجرای اقدامات درمان، دوباره احتمال/اثر را می‌سنجی و سطح ریسک را می‌نویسی.

16) شواهد/لینک به مدارک (Evidence / Reference)
یک اشاره کوتاه به اینکه شواهد کجاست: سیاست، لاگ، اسکرین‌شات تنظیمات، گزارش تست، تیکت، صورتجلسه.

نکته مهم: اگر همین 16 فیلد را داشته باشی، ریسک‌رجیستر تو هم برای عملیات داخلی قابل استفاده است، هم در ممیزی قابل دفاع. چیزی که معمولاً باعث رد شدن یا ایراد ممیز می‌شود، نبودِ “مالک ریسک”، نبودِ “ریسک باقیمانده”، و نبودِ “اثربخشی کنترل‌ها/شواهد” است.

نمونه ردیف واقعی (قابل کپی در اکسل)

• Risk ID: ISMS-R-012
• Asset/Process: CRM و پایگاه داده مشتریان
• Risk Scenario: دسترسی غیرمجاز به حساب‌های CRM به‌علت نبود MFA و استفاده از رمزهای ضعیف/تکراری
• Consequence: افشای داده مشتریان (Confidentiality)، شکایت/ریسک قانونی، آسیب اعتباری و از دست‌رفتن مشتری
• Risk Owner: مدیر فناوری اطلاعات
• Existing Controls: سیاست رمز عبور، محدودیت IP برای پنل ادمین، لاگ ورود، سطح‌بندی دسترسی‌ها
• Control Effectiveness: متوسط (به‌علت نبود MFA و ضعف در اجرای سیاست رمز)
• Likelihood (Before): 4 از 5
• Impact (Before): 5 از 5
• Inherent Risk: 20 (خیلی بالا)
• Acceptance Threshold: بالاتر از 9 = غیرقابل قبول و نیازمند درمان
• Treatment Decision: کاهش/درمان (Mitigate)
• Treatment Actions / Proposed Controls: فعال‌سازی MFA برای همه کاربران CRM، الزام رمز قوی و جلوگیری از reuse، قفل شدن حساب پس از تلاش ناموفق، آموزش کوتاه کاربران فروش، بازبینی نقش‌ها و حداقل‌سازی دسترسی‌ها
• Due Date / Status: 30 روز / In progress
• Residual Likelihood: 2 از 5
• Residual Impact: 5 از 5
• Residual Risk: 10 (متوسط رو به بالا) – نیازمند پایش و اقدامات تکمیلی
• Evidence: اسکرین‌شات تنظیمات MFA، خروجی Policy، گزارش لاگ‌ها، صورتجلسه آموزش، تیکت تغییرات

تجزیه و تحلیل ریسک (Risk Analysis) — از «حس کلی» به «عدد قابل دفاع»

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

بهترین روش این است که برای هر سناریو، دو چیز را روشن و قابل تکرار بسنجید: احتمال وقوع و اثر. احتمال یعنی «چقدر منطقی است این سناریو در بازه مشخص رخ بدهد؟» و اثر یعنی «اگر رخ بدهد، چه خسارتی به محرمانگی/یکپارچگی/دسترس‌پذیری و در نهایت به پول، اعتبار، عملیات یا انطباق قانونی وارد می‌کند؟». اگر سیستم شما چندسایته است یا داده حساس (مالی/سلامت/هویتی) دارد، اثر را بهتر است فقط با یک جمله کلی نبندید؛ حداقل یک معیار ساده و ثابت داشته باشید تا دو نفر مختلف به نتیجه نزدیک برسند.

یک مدل ممیزی‌پسند و ساده (که هم برای سازمان‌های کوچک جواب می‌دهد، هم برای متوسط‌ها) این است که مقیاس را ۵ سطحی بگیرید و سطح ریسک را با ضرب محاسبه کنید:

• Risk = Likelihood × Impact (هر دو از 1 تا 5)

برای اینکه این مدل «واقعاً قابل دفاع» شود، تعریف‌های کوتاه ولی دقیق به آن اضافه کنید.

نمونه مقیاس ممیزی‌پسند برای احتمال و اثر (۵ سطحی)

سطح	احتمال (Likelihood)	اثر (Impact)
1	نادر: یک‌بار در > ۳ سال / شواهد وقوع بسیار کم	جزئی: اختلال کوتاه، بدون نقض جدی، هزینه ناچیز
2	کم: یک‌بار در ۱–۳ سال / رخدادهای مشابه محدود	کم: اثر محدود بر یک واحد/یک سرویس، قابل جبران سریع
3	متوسط: سالانه محتمل / سابقه داخلی یا صنعت وجود دارد	متوسط: توقف چندساعته/چندروزه، شکایت مشتری، هزینه محسوس
4	زیاد: چندبار در سال / کنترل‌های فعلی ضعیف یا ناقص	زیاد: اختلال گسترده، ریسک قانونی/قراردادی، آسیب اعتباری
5	خیلی زیاد: نزدیک و فوری / شواهد فعال (هشدارها، رخدادها)	فاجعه‌آمیز: توقف حیاتی، نقض داده حساس، پیامد حقوقی سنگین

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

اول اینکه هر سناریو بهتر است دو بار سنجیده شود: یک‌بار ریسک ذاتی (Inherent) یعنی قبل از کنترل‌ها، و یک‌بار ریسک باقیمانده (Residual) یعنی با در نظر گرفتن کنترل‌های موجود. این کار باعث می‌شود ممیز دقیقاً بفهمد کنترل‌های فعلی چه تغییری ایجاد کرده‌اند، و شما هم بتوانید تصمیم درمان/پذیرش را منطقی کنید.

دوم اینکه اگر ریسک را فقط «عدد» کنید ولی در ردیف ریسک ننویسید «این عدد از کجا آمده»، باز هم دفاع سخت می‌شود. برای هر سناریو یک جمله کوتاه کنار احتمال/اثر بگذارید: مثلاً «احتمال ۴ چون دسترسی ادمین مشترک است و MFA نداریم» یا «اثر ۴ چون سرویس فروش متوقف می‌شود و SLA داریم». همین توضیح کوتاه، ریسک‌ریجستر را از فایل صوری به سند تصمیم‌گیری تبدیل می‌کند.

ارزیابی ریسک (Risk Evaluation) — تصمیم‌گیری قابل دفاع (پذیرش/درمان) با معیار روشن

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

برای اینکه ارزیابی شما ممیزی‌پسند باشد، فقط یک چیز لازم دارید: Risk Acceptance Criteria (معیار پذیرش). یعنی به‌طور شفاف بگویید از چه سطحی به بعد، ریسک باید درمان شود؛ و چه کسی اختیار پذیرش دارد. یک چارچوب ساده و قابل اجرا (با همان مقیاس ۱ تا ۲۵) این است:

• ۱ تا ۵: قابل پذیرش (Accept) — با پایش دوره‌ای
• ۶ تا ۹: قابل پذیرش مشروط — پذیرش با اقدام سبک/بهبود کوچک یا کنترل جبرانی
• ۱۰ تا ۱۵: نیازمند درمان برنامه‌ریزی‌شده (Treat) — در RTP زمان‌بندی و مالک مشخص شود
• ۱۶ تا ۲۵: بحرانی — اقدام فوری، گزارش به مدیریت، و تصمیم رسمی

این تقسیم‌بندی یک قانون خشک نیست؛ ما معمولاً آن را با واقعیت سازمان تنظیم می‌کنیم. مثلاً اگر شما تعهد قراردادی (SLA)، داده حساس، یا الزام قانونی جدی دارید، آستانه درمان پایین‌تر می‌آید. مهم این است که «آستانه‌ها» در سند شما ثابت، شفاف و قابل دفاع باشند.

بعد از تعیین معیار پذیرش، خروجی ارزیابی باید کاملاً روشن باشد: برای هر ریسک، تصمیم شما یکی از این‌هاست: درمان (کاهش)، انتقال (مثلاً بیمه/برون‌سپاری با SLA)، اجتناب (حذف فعالیت/تغییر فرآیند)، یا پذیرش. اما پذیرش هم باید حرفه‌ای انجام شود: اگر ریسک را می‌پذیرید، کنار آن بنویسید «چرا قابل پذیرش است» و «چه کسی تایید کرده» و «چه زمانی بازبینی می‌شود». همین سه مورد ساده، جلوی خیلی از سوال‌های ممیز را می‌گیرد.

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

۱) RTP (برنامه درمان ریسک): ریسک‌های درمان‌شونده با اقدام، مالک، موعد، و روش سنجش اثربخشی.
۲) SoA: کنترل‌هایی که انتخاب کرده‌اید (یا انتخاب نکرده‌اید) با توجیه روشن و وضعیت اجرا.
اگر این اتصال برقرار باشد، ریسک‌ریجستر شما «مدرک زنده» می‌شود؛ یعنی ممیز می‌بیند عددها صرفاً پر نشده‌اند و واقعاً به تصمیم و کنترل و شواهد اجرایی رسیده‌اند.

مدیریت ریسک در ISO 27001 یعنی «تصمیم قابل دفاع» (نه صرفاً کاهش ریسک)

بعد از اینکه احتمال و اثر را سنجیدی و سطح ریسک به‌دست آمد، تازه می‌رسی به قسمت مهم‌تر: با این ریسک چه می‌کنی؟ استاندارد از شما انتظار دارد برای هر ریسکِ «غیرقابل‌قبول طبق معیار پذیرش»، یک تصمیم روشن بگیری و بتوانی نشان بدهی این تصمیم چگونه به کنترل‌ها و اقدامات عملی تبدیل شده است. اینجا همان جایی است که خیلی از ISMSها صوری می‌شوند: ریسک‌ها نوشته می‌شوند، اما درمان ریسک تبدیل به یک سری جمله کلی یا لیست کنترل‌های کپی‌شده می‌شود—بدون اینکه معلوم باشد چرا این کنترل‌ها انتخاب شده‌اند، چه کسی مسئول اجراست، چه زمانی تمام می‌شود، و ریسک باقیمانده چقدر است.

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

1. تصمیم درمان برای هر ریسک
2. برنامه درمان ریسک (Risk Treatment Plan)
3. بیانیه کاربردپذیری کنترل‌ها (SoA – Statement of Applicability)
   به زبان ساده: ریسک را می‌سنجی، تصمیم می‌گیری، برنامه اجرا می‌چینی، و بعد با SoA نشان می‌دهی کدام کنترل‌ها را انتخاب کرده‌ای و چرا.

۱) گزینه‌های تصمیم درمان ریسک (چهار مسیر استاندارد)

برای هر ریسک، یکی از این چهار تصمیم باید شفاف ثبت شود؛ نه به‌صورت کلی، بلکه برای همان سناریوی ریسک:

پذیرش (Accept):
یعنی ریسک طبق معیار پذیرش شما قابل قبول است، یا هزینه/پیچیدگی درمانش فعلاً منطقی نیست و با آگاهی مدیریت پذیرفته می‌شود. نکته ممیزی‌پسند این است که پذیرش باید صاحب داشته باشد (Risk Owner) و معمولاً با تأیید سطح مناسب مدیریت ثبت شود.

کاهش/درمان (Treat / Mitigate):
یعنی با اجرای کنترل‌ها یا اقدامات مشخص، احتمال یا اثر را پایین می‌آورید. این رایج‌ترین حالت است و دقیقاً همینجاست که باید «برنامه درمان ریسک» واقعی داشته باشید.

اجتناب (Avoid):
یعنی کاری می‌کنید که آن فعالیت/فرآیند/روش انجام نشود یا تغییر بنیادین کند تا ریسک حذف شود (مثلاً قطع یک سرویس پرریسک یا تغییر روش تبادل داده).

انتقال/اشتراک (Transfer / Share):
یعنی بخشی از پیامد یا مسئولیت را با قرارداد، بیمه، برون‌سپاری، SLA و… منتقل می‌کنید. دقت کن: انتقال معمولاً ریسک را صفر نمی‌کند؛ فقط شکل و محلش را عوض می‌کند، پس باز هم ریسک باقیمانده باید سنجیده شود.

۲) برنامه درمان ریسک (Risk Treatment Plan) باید «قابل اجرا و قابل پیگیری» باشد

برنامه درمان ریسک اگر فقط یک جمله باشد (مثلاً “فعال‌سازی کنترل‌ها”) برای ممیزی و برای اجرا ارزش ندارد. یک RTP خوب نشان می‌دهد دقیقاً چه کارهایی انجام می‌دهی و چگونه نتیجه‌اش را می‌سنجی. حداقل چیزی که بهتر است در برنامه درمان برای هر ریسک داشته باشی این‌هاست:

• اقدام(ها) یا کنترل(های) درمانی دقیق (مثلاً “فعال‌سازی MFA برای همه کاربران سیستم X” نه “افزایش امنیت”)
• مسئول اجرا (Owner) و نقش تأییدکننده (Approver)
• زمان‌بندی و وضعیت (Due date / Status)
• منابع یا پیش‌نیازها (اگر لازم است خرید/پیکربندی/آموزش انجام شود)
• معیار موفقیت و شواهد (Evidence)؛ یعنی بعداً چه چیزی نشان می‌دهی که واقعاً اجرا شده است (اسکرین‌شات تنظیمات، گزارش لاگ، صورتجلسه آموزش، خروجی ابزار، تیکت تغییرات، گزارش تست و…)

نکته مهم: درمان ریسک بدون “Evidence” عملاً قابل دفاع نیست. ممیز معمولاً دنبال این است که ببیند تصمیم درمان فقط روی کاغذ نمانده و شواهد اجرای آن موجود است.

۳) SoA (Statement of Applicability) قلب دفاع شما در ممیزی است

SoA جایی است که نشان می‌دهید از بین کنترل‌های Annex A، کدام‌ها را انتخاب کرده‌اید و کدام‌ها را انتخاب نکرده‌اید—و مهم‌تر از همه، چرا. این سند باید به ارزیابی ریسک شما وصل باشد، نه اینکه یک فایل آماده و عمومی باشد.

مطالعه پیشنهادی: SoA / Statement of Applicability

یک SoA ممیزی‌پسند معمولاً برای هر کنترل این منطق را شفاف می‌کند:

• کنترل “Applicable” است یا “Not applicable”
• دلیل کاربردپذیری/عدم‌کاربردپذیری چیست (بر اساس Scope، فناوری، فرآیندها، یا نتایج ریسک)
• وضعیت اجرا (Implemented / Planned / Not implemented)
• ارجاع به شواهد یا اسناد مرتبط (Policy/Procedure/Config/Logs)

اگر SoA شما دقیق و قابل ردیابی باشد، بخش زیادی از سخت‌گیری ممیز عملاً خنثی می‌شود؛ چون می‌بیند انتخاب کنترل‌ها از دل ریسک و Scope بیرون آمده، نه از کپی‌کاری.

مطالعه پیشنهادی: چک‌لیست ممیزی ریسک‌محور ISO 27001 (Risk→SoA→Evidence)

۴) ریسک باقیمانده و تأیید مالک ریسک را جدی بگیر

بعد از اجرای درمان (یا حتی در حین برنامه‌ریزی)، باید دوباره سطح ریسک را بسنجید و Residual Risk را ثبت کنید. این نقطه‌ای است که استاندارد انتظار دارد نشان بدهید «پس از کنترل‌ها، ریسک به سطح قابل قبول رسیده یا نه».

اگر ریسک باقیمانده هنوز بالاتر از معیار پذیرش است، شما یا باید:

• درمان را تقویت کنید (کنترل/اقدام اضافه)،
• تصمیم را تغییر دهید (اجتناب/انتقال)،
• یا اگر واقعاً می‌خواهید بپذیرید، پذیرش رسمی و قابل دفاع داشته باشید.

و نکته‌ای که خیلی‌ها جا می‌اندازند: پذیرش ریسک باید توسط مالک ریسک تأیید شود (و در ریسک‌های بزرگ، معمولاً سطح بالاتری از مدیریت). این دقیقاً همان چیزی است که در ممیزی به‌عنوان «کنترل مدیریتی» دیده می‌شود.

یک معیار ساده برای اینکه بفهمی این بخش “واقعی” نوشته شده یا صوری

اگر کسی از بیرون (ممیز یا مدیر) فقط با نگاه به سه چیز بتواند مسیر تصمیم را دنبال کند، یعنی کار درست است:
Risk Register → Risk Treatment Plan → SoA (و Evidence)
اگر این زنجیره قطع باشد، معمولاً ایرادها از همینجا شروع می‌شود.

یعنی شما باید بتوانید نشان بدهید ریسک‌ها را در Risk Register با پارامترهای روشن (احتمال/اثر/سطح/مالک/مهلت) ثبت کرده‌اید، بعد برای هر ریسکِ مهم تصمیم گرفته‌اید «قبول می‌کنیم یا درمان می‌کنیم» و این تصمیم را در Risk Treatment Plan (RTP) به اقدام‌های واقعی تبدیل کرده‌اید.

مرحله بعد این است که کنترل‌ها را صرفاً انتخاب نکنید؛ در SoA دقیقاً مشخص کنید کدام کنترل‌های Annex A را چرا انتخاب کرده‌اید/چرا انتخاب نکرده‌اید و برای هر کنترل، وضعیت اجرا و توجیه‌اش چیست. نهایتاً همان چیزی که در ممیزی تعیین‌کننده است Evidence است: اگر برای هر کنترل و هر اقدام درمان ریسک، شواهد اجرایی (سیاست‌ها، لاگ‌ها، گزارش‌ها، تیکت‌ها، خروجی ابزارها، آموزش‌ها، نتایج تست‌ها و بازبینی‌ها) داشته باشید، ارزیابی ریسک از یک فایل «صوری» به یک سیستم تصمیم‌گیری واقعی تبدیل می‌شود و هم اخذ گواهی ساده‌تر می‌شود، هم در ممیزی‌های مراقبتی دردسر کمتری دارید.

سوالات متداول درباره پارامترهای ارزیابی ریسک در ISO 27001

منابع معتبر برای مطالعه و استناد

• ISO/IEC 27001:2022
  متن اصلی الزامات ISMS؛ مبنای اینکه “ارزیابی ریسک” دقیقاً باید چه ویژگی‌هایی داشته باشد و چه خروجی‌هایی از شما انتظار می‌رود.
• ISO/IEC 27005:2022
  راهنمای تخصصی مدیریت ریسک امنیت اطلاعات؛ برای تعریف سناریوهای ریسک، معیارها، روش‌های ارزیابی و ارتباط با کنترل‌ها بسیار کاربردی است.
• ISO/IEC 27002:2022
  راهنمای کنترل‌های امنیتی (Annex A) با توضیحات اجرایی؛ برای اینکه انتخاب کنترل‌ها در SoA و درمان ریسک واقعی و قابل دفاع شود.
• ISO 31000:2018
  راهنمای عمومی مدیریت ریسک؛ کمک می‌کند منطق معیار پذیرش، پایش و یکپارچه‌سازی ریسک با مدیریت سازمانی را اصولی بچینی.
• National Institute of Standards and Technology – NIST SP 800-30 (Risk Assessments)
  چارچوب عملیاتی و شناخته‌شده برای ارزیابی ریسک، به‌خصوص برای سناریونویسی و تحلیل احتمال/اثر (بسیار محبوب در تیم‌های فنی).
• National Institute of Standards and Technology – NIST SP 800-37 (Risk Management Framework)
  برای نگاه فرآیندمحور به مدیریت ریسک و اتصال تصمیم‌ها به اجرای کنترل‌ها و پایش اثربخشی.
• European Union Agency for Cybersecurity (ENISA) – راهنماهای Risk Management
  برای مثال‌های کاربردی در حوزه تهدیدات رایج، سناریوها، و رویکردهای ریسک‌محور در امنیت سایبری.
• UK National Cyber Security Centre (NCSC) – Guidance on Risk Management
  برای بیان ساده و مدیریتیِ ریسک، و اینکه چطور تصمیم‌ها را برای مدیران قابل فهم و قابل دفاع ارائه کنی.