اگر دنبال این هستی که «ریسکهای امنیت اطلاعات» در سازمانت واقعاً قابلمدیریت شوند (نه فقط یک فایل صوری برای ممیزی)، ISO/IEC 27005 دقیقاً همان نقشهراهی است که کنار ISO 27001 به کارت میآید. این استاندارد به تو کمک میکند ریسکها را از مرحله شناسایی تا تحلیل، ارزیابی و انتخاب راهکار درمان ریسک جلو ببری، معیارهای تصمیمگیری را شفاف کنی، و خروجیهای عملی مثل Risk Register و Risk Treatment Plan بسازی؛ خروجیهایی که هم برای تصمیمگیری مدیریت قابل دفاعاند و هم در ممیزی Stage 1 و Stage 2 واقعاً جواب میدهند.
در این صفحه، ISO 27005 را با نگاه کاربردی و نسخههای جدیدتر توضیح میدهیم تا دقیق بدانی چه زمانی به آن نیاز داری، چه مستنداتی باید تولید شود، و چطور مدیریت ریسک را به شکل درست به ISMS وصل کنی.
- ایزو ۲۷۰۰۵ چگونه تعریف میشود؟
- نسخهها و تفاوتهای ISO/IEC 27005 (۲۰۰۸ تا ۲۰۲۲)
- چه افرادی از این استاندارد استفاده میکنند؟
- چگونه ISO/IEC 27005 کار میکند؟
- ارتباط مستقیم ISO/IEC 27005 با بندهای ISO/IEC 27001:2022
- خروجیها و مستندات کلیدی ISO/IEC 27005 در عمل
- پذیرش ریسک باقیمانده پس از درمان (Residual Risk Acceptance)
- مزایای ISO/IEC 27005 برای سازمان شما
- چرا سازمانها باید از ISO/IEC 27005 استفاده کنند؟
- جمعبندی
- منابع معتبر و استانداردهای مرجع
پادکست خلاصه ایزو ۲۷۰۰۵
ایزو ۲۷۰۰۵ چگونه تعریف میشود؟
ISO/IEC 27005 یک راهنمای تخصصی برای مدیریت ریسک امنیت اطلاعات است که به تو کمک میکند ریسکها را به شکل منظم و قابلدفاع شناسایی، تحلیل، ارزیابی و برایشان تصمیم درمان ریسک بگیری—طوری که خروجیاش مستقیماً به نیازهای ISMS و الزامات ISO/IEC 27001 وصل شود.
نکته مهم این است که 27005 معمولاً «استاندارد قابل صدور گواهی» نیست؛ یعنی شما با اجرای آن گواهی جداگانه نمیگیرید، اما با استفاده از آن میتوانی مدیریت ریسک را از حالت کلی و سلیقهای خارج کنی و مستندات عملی مثل Risk Register، معیارهای پذیرش ریسک، و Risk Treatment Plan بسازی که هم برای تصمیمگیری مدیریت شفاف است و هم در ممیزیها قابل ارائه و پیگیری.
آخرین نسخه کدام است و چرا برای شما مهم است؟
ISO/IEC 27005 یک «راهنما» برای مدیریت ریسک امنیت اطلاعات است؛ یعنی خودش استانداردِ «الزامی برای صدور گواهی» نیست، اما دقیقاً برای این نوشته شده که مدیریت ریسک را بهصورت قابلدفاع در کنار ISMS اجرا کنید و نیازهای ریسکمحور ISO/IEC 27001 را درست پوشش بدهید. بنابراین وقتی نسخهها تغییر میکنند، موضوع فقط تاریخ نیست؛ واژهها، ساختار بندها و حتی خروجیهایی که ممیز از شما انتظار دارد، همراستا با نسخههای جدیدتر دقیقتر میشود.
تاریخچه نسخهها (برای اینکه مبنا را اشتباه انتخاب نکنید)
این استاندارد در چهار نسخه اصلی منتشر شده است: ISO/IEC 27005:2008، سپس 2011، بعد 2018 و در نهایت ISO/IEC 27005:2022 (ویرایش چهارم) که نسخه جاری و مرجع محسوب میشود. اگر امروز سازمان شما روی ISO/IEC 27001:2022 حرکت میکند (یا قصد ممیزی/گواهی دارد)، منطقیترین مبنا برای مدیریت ریسک، همین 27005:2022 است.
مطالعه پیشنهادی: فرآیند اخذ گواهینامه
نسخهها و تفاوتهای ISO/IEC 27005 (۲۰۰۸ تا ۲۰۲۲)
مهمترین تفاوتهای 27005:2022 نسبت به 27005:2018
در نسخه ۲۰۲۲، تغییرات «هستهای» اینهاست: متن راهنما بهطور کامل با ISO/IEC 27001:2022 و همچنین با رویکرد و واژگان استاندارد مدیریت ریسک ISO 31000:2018 همراستا شده؛ یعنی هم زبان مشترکتر شده و هم ساختار بندها به چیدمان 27001:2022 نزدیکتر شده است. این همراستاسازی باعث میشود وقتی دارید ریسک را مستندسازی میکنید، خروجیها طبیعیتر به زبان ممیزی و الزامات ISMS ترجمه شوند.
از نظر واژگان، برخی اصطلاحات برای هماهنگی با ISO 31000 بهروزرسانی شدهاند (مثلاً در منابع آموزشیِ مبتنی بر متن استاندارد اشاره میشود که «impact» در بسیاری موارد با «consequence» جایگزین شده تا اصطلاحات با ISO 31000 یکدست باشد). این تغییر شاید کوچک بهنظر برسد، اما در عمل روی فرمها، معیارها و حتی ادبیات Risk Register اثر میگذارد و جلوی دوگانگی اصطلاحات در سازمان را میگیرد.
تفاوت مهم دیگر این است که در 27005:2022 مفهوم «سناریوی ریسک» پررنگتر شده؛ یعنی بهجای اینکه ریسکها صرفاً لیست تهدید/آسیبپذیری باشند، بهتر و شفافتر به شکل سناریوهای قابلتصور و قابلتحلیل نوشته میشوند (چه اتفاقی، برای چه دارایی/فرآیند، با چه پیامد و در چه شرایطی). این نگاه، کیفیت تحلیل و قابلدفاع بودن درمان ریسک را بالا میبرد.
همچنین نسخه ۲۰۲۲ بهصورت روشنتر «رویکرد رویدادمحور (event-based)» را در کنار «رویکرد داراییمحور (asset-based)» در شناسایی ریسک مطرح و مقایسه میکند. نتیجه عملی برای شما این است که اگر تا امروز فقط داراییمحور جلو میرفتید، حالا میتوانید (و بهتر است) در کنار آن سناریو/رویدادها را هم وارد مدل شناسایی کنید تا ریسکهای واقعی عملیاتی و سایبری از قلم نیفتند.
و یک نکته خیلی کاربردی: محتوای ضمائم (Annexes) در 2022 بازنگری و بازساختاردهی شده و به سمت یک پیوست یکپارچه رفته است. یعنی اگر شما در 27005:2018 به پیوستها و مثالهای آن بهعنوان «قالب آماده» تکیه کرده بودید، در 27005:2022 باید انتظار ساختار جدیدتر و فشردهتر ضمائم را داشته باشید و الگوها را مطابق نسخه جدید بازچینش کنید.
اگر هدف تو ممیزی Stage 1/Stage 2 است، بهترین نقطه شروع یک تحلیل شکاف سریع است تا دقیقاً معلوم شود کدام خروجیهای ریسک و شواهد هنوز کم داری و چه چیزهایی باید قبل از ممیزی تکمیل شود.
این تفاوتها در عمل چه اثری روی مستندات و ممیزی دارد؟
اگر بخواهیم خیلی اجرایی جمعبندی کنیم: با 27005:2022 بهتر است خروجیهای مدیریت ریسک را طوری بنویسید که به زبان 27001:2022 نزدیک باشد؛ یعنی «زمینه و معیارها» روشن باشد، سناریوهای ریسک قابلردگیری باشند، و ارتباط بین ریسک → تصمیم درمان → کنترل/اقدام → ریسک باقیمانده شفاف ثبت شود. این کار هم برای تصمیمگیری مدیریت قابل دفاعتر است و هم در ممیزیهای ISMS کمتر وارد بحثهای فرسایشیِ اصطلاحات و ساختار میشوید.
چه افرادی از این استاندارد استفاده میکنند؟
این استاندارد را معمولاً سازمانهایی استفاده میکنند که «ریسک امنیت اطلاعات» برایشان واقعی و اثرگذار است و میخواهند مدیریت ریسک را در کنار ISO/IEC 27001 به شکل قابلدفاع جلو ببرند؛ از شرکتهای فناوری و نرمافزار، استارتاپهای SaaS، مراکز داده و ارائهدهندگان خدمات ابری و میزبانی گرفته تا بانکها و مؤسسات مالی، بیمه، پرداخت، سلامت و بیمارستانها، آموزش، صنایع نفتوگاز و انرژی، تولید و زنجیره تأمین، اپراتورها و سازمانهای دولتی.
در سطح نقشها هم معمولاً مدیر امنیت اطلاعات (CISO)، مدیر یا کارشناس ISMS، تیم GRC/ریسک و انطباق، مدیران IT و شبکه، مسئولان حریم خصوصی و حفاظت داده، مدیران فرآیند/مالک داراییهای اطلاعاتی، و حتی واحد حقوقی و مدیریت ارشد از ISO/IEC 27005 استفاده میکنند؛ چون خروجیهای آن کمک میکند تصمیمهای امنیتی و هزینهکردها بر مبنای ریسک و اولویت، شفاف و قابل دفاع شود.
چگونه ISO/IEC 27005 کار میکند؟
ISO/IEC 27005 را میتوانی مثل «موتور تصمیمگیری امنیت اطلاعات» ببینی که کمک میکند امنیت از حالت شعار و چکلیست خارج شود و تبدیل به تصمیمهای قابلدفاع بر اساس ریسک شود. منطقش ساده است: ما اول زمینه و قواعد بازی را مشخص میکنیم (چه چیزی مهم است، چه چیزی قابلقبول نیست)، بعد ریسکها را به شکل سناریوهای واقعی شناسایی و اندازهگیری میکنیم، سپس تصمیم میگیریم هر ریسک را درمان کنیم، منتقل کنیم، اجتناب کنیم یا آگاهانه بپذیریم—و در نهایت این چرخه را با پایش و بازنگری زنده نگه میداریم.
۱) از «زمینه» شروع میکند، نه از فرم
اول از همه باید معلوم شود دقیقاً درباره چه چیزی صحبت میکنیم: دامنه (Scope)، داراییهای اطلاعاتی، فرآیندها، سیستمها، ذینفعان و الزامات قانونی/قراردادی. همزمان معیارها را تعیین میکنیم: مثلاً «چه سطحی از پیامد برای ما غیرقابلقبول است؟»، «ریسک را با چه مقیاسی میسنجیم؟»، و «چه زمانی باید ریسک را به مدیریت ارشد Escalate کنیم؟». اگر این قسمت شفاف نباشد، بقیه کار ظاهراً پرحجم میشود ولی خروجی قابل دفاع به دست نمیآید.
۲) ریسک را «سناریومحور» شناسایی میکند
در 27005 ریسک فقط یک عنوان کلی مثل “Phishing” نیست. ما ریسک را به شکل سناریو مینویسیم: چه اتفاقی میافتد، برای کدام دارایی/فرآیند، از چه مسیری، و چه پیامدی ایجاد میکند؟
مثلاً به جای «ریسک حمله فیشینگ»، سناریو میشود: «ایمیل فیشینگ باعث افشای نام کاربری/رمز سیستم مالی میشود و احتمال پرداخت غیرمجاز/افشای داده مالی ایجاد میکند». این مدل نوشتن، هم تحلیل را دقیق میکند و هم درمان ریسک را هدفمند.
۳) ریسک را تحلیل و ارزیابی میکند (تا اولویتها واقعی شوند)
بعد از شناسایی، دو چیز را میسنجیم: احتمال (Likelihood) و پیامد (Consequence/Impact). بسته به سازمان میتوانیم مدل کیفی (کم/متوسط/زیاد) یا نیمهکمی/کمی داشته باشیم، اما نکته کلیدی این است که «روش» ثابت و قابل تکرار باشد. سپس ریسکها را با معیارهای مرحله ۱ مقایسه میکنیم تا مشخص شود کدامها باید درمان شوند، کدامها قابل قبولاند، و کدامها باید به سطح مدیریت بالاتر بروند.
۴) تصمیم درمان ریسک میسازد، نه فقط “کنترلهای Annex A”
اینجا نقطهای است که 27005 واقعاً ارزش ایجاد میکند: برای هر ریسک تصمیم میگیریم چه کار کنیم:
- Modify/Reduce (کاهش): با کنترلها، فرآیندها، آموزش، سختسازی، مانیتورینگ…
- Avoid (اجتناب): حذف فعالیت/تغییر معماری که ریسک را ایجاد میکند
- Share/Transfer (انتقال): بیمه، برونسپاری با SLA/تعهدات، قرارداد
- Retain/Accept (پذیرش): وقتی ریسک در محدوده قابلقبول است یا هزینه کاهش آن منطقی نیست
نتیجه این مرحله معمولاً یک Risk Treatment Plan است که دقیقاً میگوید چه اقدامی، توسط چه کسی، تا چه تاریخی، با چه شواهدی انجام میشود و بعد از اجرا «ریسک باقیمانده» چقدر میماند. این دقیقاً همان نقطهای است که به ISO 27001 وصل میشود و در ممیزی به شکل Evidence قابل ارائه است.
مطالعه پیشنهادی: جدول Annex A استاندارد ایزو 27001 / ایزو 27002 چگونه بر ایزو 27001 تاثیر می گذارد؟
۵) ثبت و گزارشدهی را جدی میگیرد (چون ممیزی و مدیریت به آن نیاز دارند)
در 27005 هر چیزی باید قابل ردیابی باشد: از معیارها تا سناریوهای ریسک، امتیازدهی، تصمیم درمان، مالک ریسک، و وضعیت اجرا. خروجیهایی مثل Risk Register و گزارشهای دورهای باعث میشود مدیریت ارشد بتواند تصمیم بگیرد و ممیز هم بتواند دنبال کند که «ریسکها واقعاً مدیریت شدهاند یا فقط نوشته شدهاند».
۶) چرخهاش با «ارتباط + پایش و بازنگری» زنده میماند
ریسک امنیت اطلاعات ثابت نیست؛ سیستمها، تهدیدها، تامینکنندگان و حتی کسبوکار تغییر میکنند. 27005 تاکید میکند که مدیریت ریسک باید با Communication/Consultation (گفتوگوی ساختارمند با ذینفعان و مالکین دارایی) و Monitoring & Review (بازنگری دورهای، رویدادمحور و بعد از تغییرات مهم) دائماً بهروز شود. اگر این دو جزء را جدی نگیریم، Risk Register ظرف چند ماه تبدیل به یک فایل قدیمی میشود.
جمعبندی اجرایی
ISO/IEC 27005 در عمل یک مسیر قابل دفاع میدهد تا تو بتوانی بگویی: «اینها ریسکهای واقعی ما هستند، این معیارها را داریم، اینها اولویتهای ما هستند، این برنامه درمان است، این هم شواهد اجرای آن و سطح ریسک باقیمانده.» اگر هدف تو این است که ISMS واقعاً کار کند و ممیزی هم بدون بحثهای فرسایشی پیش برود، این استاندارد دقیقاً نقش همان چارچوب اجرایی را بازی میکند.
اگر دنبال یک مسیر اجرایی هستی، ما میتوانیم مدیریت ریسک را مرحلهبهمرحله جلو ببریم: تعریف معیارها → ساخت Risk Register سناریومحور → تدوین Risk Treatment Plan → آمادهسازی شواهد → برنامه پایش و بازنگری.
ارتباط مستقیم ISO/IEC 27005 با بندهای ISO/IEC 27001:2022
اگر ISO/IEC 27001 را «چه چیزهایی باید انجام شود» در نظر بگیریم، ISO/IEC 27005 دقیقاً میگوید «این کار را چگونه انجام بدهیم که هم منطقی باشد، هم قابل دفاع و هم قابل ممیزی». یعنی 27005 روش، زبان مشترک، و خروجیهای عملی مدیریت ریسک را استاندارد میکند تا شما بتوانی الزامات ریسکمحور 27001 را با کمترین ابهام اجرا کنی و همان چیزی را تولید کنی که ممیز انتظار دارد: یک خط قابل ردیابی از ریسک تا تصمیم درمان و شواهد اجرا.
در بخش برنامهریزی 27001 (بندهای 6.1.2 و 6.1.3)، سازمان باید فرآیند ارزیابی ریسک را تعریف کند (از جمله معیارهای پذیرش و معیارهای ارزیابی) و سپس برای ریسکها تصمیم درمان و انتخاب کنترلها را انجام دهد. 27005 در همین نقطه به کار میآید: کمک میکند معیارها و روش امتیازدهی را درست تعریف کنی، ریسکها را سناریومحور بنویسی، و درمان ریسک را از حالت «انتخاب کنترلهای پراکنده» به یک تصمیم مهندسیشده تبدیل کنی.
در بخش عملیات 27001 هم (بندهای 8.2 و 8.3)، استاندارد از شما انتظار دارد ارزیابی ریسک را در فواصل برنامهریزیشده و هنگام تغییرات مهم انجام بدهی و درمان ریسک را به شکل عملی اجرا کنی—نه اینکه صرفاً یک فایل تئوریک داشته باشی. 27005 این را اجرایی میکند: مشخص میکند ارزیابیها چگونه تکرارپذیر بمانند، چه دادههایی ثبت شوند، چطور خروجیها (مثل Risk Register و Risk Treatment Plan) همیشه بهروز و قابل پیگیری باشند، و چطور «تصمیم درمان» به اقدام و شواهد واقعی وصل شود.
یک نکته خیلی کاربردی برای ممیزی این است که این ارتباط را «قابل نشان دادن» کنی: یعنی وقتی ممیز درباره 8.2 و 8.3 سؤال میپرسد، شما بتوانی با یک مسیر روشن جواب بدهی: معیارها و روش ارزیابی (6.1.2) → نتایج ارزیابی و اولویتها (8.2) → تصمیم درمان و انتخاب/توجیه کنترلها (6.1.3) → اجرای درمان و Evidenceها (8.3). اگر این زنجیره را شفاف بسازی، ممیزی از حالت بحثهای سلیقهای خارج میشود و سریعتر و کمحاشیهتر جلو میرود.
خروجیها و مستندات کلیدی ISO/IEC 27005 در عمل
اگر بخواهیم ISO/IEC 27005 واقعاً برای سازمان «کار کند»، باید نتیجه هر مرحله به خروجیهای مشخص و قابلپیگیری تبدیل شود؛ چون ارزش این استاندارد فقط در توضیح فرآیند نیست، در این است که مدیریت ریسک شما مستندسازیپذیر، قابل دفاع و قابل ممیزی شود. در نسخههای جدیدتر هم روی «اطلاعات مستند درباره فرآیندها و نتایج» تأکید بیشتری دیده میشود، یعنی باید هم روش را ثبت کنید و هم خروجیهایش را.
۱) روش مدیریت ریسک و معیارها (Methodology + Criteria)
اولین خروجیِ واقعی، «قواعد بازی» است: اینکه ریسک را با چه روشی میسنجید، مقیاس احتمال و پیامدتان چیست، چه سطحی از ریسک برای سازمان قابلقبول است، و چه ریسکهایی باید به مدیریت ارشد ارجاع شوند. وقتی این بخش روشن و ثابت باشد، ارزیابی ریسک در واحدهای مختلف سازمان یکدست میشود و بعداً هم میتوانید نشان دهید تصمیمها بر اساس معیار بوده، نه سلیقه.
۲) ثبت ریسکها بهصورت سناریومحور (Risk Register)
خروجی مرکزی 27005 معمولاً «Risk Register» است؛ جایی که ریسکها را به شکل سناریو ثبت میکنید (چه اتفاقی، برای کدام دارایی/فرآیند، از چه مسیر، با چه پیامد) و کنار آن مالک ریسک، سطح ریسک، وضعیت کنترلهای موجود و اولویت اقدام را میآورید. این سند، مرجع مشترک بین IT، امنیت، مالکین فرآیند و مدیریت میشود و جلوی پراکندگی تصمیمها را میگیرد—بهخصوص وقتی بعداً تغییرات سیستم/تأمینکننده/فرآیند رخ میدهد و باید ریسکها را سریع بازنگری کنید.
۳) برنامه درمان ریسک و اتصال به کنترلها (Risk Treatment Plan)
خروجی بعدی «Risk Treatment Plan» است: برای هر ریسک تصمیم میگیرید کاهش بدهید، اجتناب کنید، منتقل کنید یا نگه دارید؛ اما مهمتر از نام تصمیم، این است که اقدام/کنترل دقیق، مسئول، زمانبندی و شواهد اجرا روشن باشد. اینجاست که مدیریت ریسک از حالت “فهرست تهدیدها” خارج میشود و تبدیل به برنامه اجرایی میگردد—و در مسیر ISO 27001 هم دقیقاً همین برنامه است که بخش بزرگی از Evidence ممیزی را میسازد.
۴) ریسک باقیمانده و پذیرش آن (Residual Risk + Acceptance)
بعد از تعریف اقدامات درمان، باید «ریسک باقیمانده» را دوباره بسنجید و مشخص کنید آیا با معیارهای پذیرش ریسک سازمان همخوان است یا نه. این تصمیم باید ثبتشده، قابل ردیابی و دارای سطح تأیید مناسب باشد (بهخصوص برای ریسکهای بالا). در رویکرد نسخههای جدیدتر هم پذیرش، عملاً به یک نقطه تصمیم پس از درمان تبدیل میشود.
۵) پایش، بازنگری و گزارشدهی (Monitoring & Review)
اگر برنامه پایش و بازنگری را مستند نکنید، Risk Register ظرف چند ماه قدیمی میشود. این خروجی معمولاً شامل «دوره بازنگری» (مثلاً فصلی/ششماهه)، «محرکهای رویدادمحور» (تغییر مهم زیرساخت، تغییر تامینکننده، رخداد امنیتی، تغییر قانونی/قراردادی) و «الگوی گزارشدهی به مدیریت» است. این بخش کمک میکند نشان دهید مدیریت ریسک یک فعالیت یکباره نیست، بلکه یک چرخه زنده است که با تغییرات سازمان حرکت میکند.
نمونه کوتاه یک ریسک (از Risk Register تا پذیرش ریسک باقیمانده)
برای اینکه خروجیهای ISO/IEC 27005 ملموس شود، این یک نمونه «واقعینما» از یک ردیف Risk Register است که نشان میدهد چطور یک سناریوی ریسک، به تصمیم درمان، شواهد اجرا و در نهایت ریسک باقیمانده وصل میشود. فرض کنید مقیاس امتیازدهی شما ۱ تا ۵ است (احتمال × پیامد).
- دارایی/فرآیند: حسابهای ادمین سرویس ایمیل سازمانی + فرآیند تأیید پرداختها
- سناریوی ریسک: یک ایمیل فیشینگ، نام کاربری/رمز یکی از ادمینها را افشا میکند و مهاجم با دسترسی به صندوق ایمیل، مسیر تأیید پرداخت را دور میزند (Business Email Compromise)؛ پیامد میتواند پرداخت غیرمجاز و افشای مکاتبات مالی باشد.
- کنترلهای موجود: SPF/DKIM/DMARC فعال، آنتیاسپم پایه، آموزش عمومی سالانه
- امتیاز اولیه ریسک: احتمال = 4 / پیامد = 5 → سطح ریسک = 20 (بالا و غیرقابل قبول طبق معیار سازمان)
- تصمیم درمان: Reduce (کاهش) + سختسازی کنترلهای پیشگیرانه و کشف
- اقدام/کنترلهای درمان (Treatment Plan): فعالسازی MFA برای همه ادمینها و کاربران حساس مالی، اعمال شرط «تأیید دومرحلهای خارج از ایمیل» برای تغییر اطلاعات حساب مقصد، Rule برای هشدار/بلوکهکردن فوروارد خودکار، اجرای شبیهسازی فیشینگ فصلی برای تیم مالی
- مالک ریسک: مدیر فناوری اطلاعات / هممالک: مدیر مالی
- شواهد اجرا (Evidence): گزارش فعال بودن MFA، اسکرینشات Policyها، صورتجلسه تغییر فرآیند تأیید پرداخت، گزارش کمپین شبیهسازی فیشینگ و نتایج
- ریسک باقیمانده (پس از اجرا): احتمال = 2 / پیامد = 4 → سطح ریسک = 8 (متوسط و قابل پذیرش با شرط پایش)
- تصمیم پذیرش ریسک باقیمانده: پذیرش مشروط توسط مدیریت (با الزام بازنگری ۶ماهه و بازنگری رویدادمحور در صورت رخداد یا تغییر سرویس/تأمینکننده)
این نمونه دقیقاً همان زنجیرهای را نشان میدهد که ممیز هم دنبال میکند: «سناریو ریسک → امتیازدهی/معیار → تصمیم درمان → اقدام و شواهد → ریسک باقیمانده و پذیرش».
اگر Risk Register دارید اما مطمئن نیستی سناریوها، معیارها و تصمیم درمان ریسکها در ممیزی قابل دفاع هستند، فایل فعلیات را بفرست تا یک بازبینی سریع انجام دهیم و نقاط ضعفش را دقیق مشخص کنیم.
پذیرش ریسک باقیمانده پس از درمان (Residual Risk Acceptance)
در ISO/IEC 27005، «پذیرش ریسک» به این معنا نیست که ریسک را نادیده بگیریم؛ یعنی ما اول ریسک را ارزیابی میکنیم، بعد برایش برنامه درمان مینویسیم و اقدامات/کنترلها را تعریف میکنیم، و پس از درمان دوباره سطح ریسک را میسنجیم تا «ریسک باقیمانده» (Residual Risk) مشخص شود. سپس تصمیمگیری اصلی اینجاست: آیا این ریسکِ باقیمانده، با توجه به معیارهای سازمان، قابل نگهداشتن است یا نه؟
برای اینکه این تصمیم سلیقهای نشود، باید از قبل معیار پذیرش ریسک (Risk Acceptance Criteria) را تعریف کرده باشید؛ همان معیارهایی که مشخص میکنند از چه سطحی به بعد ریسک «غیرقابل قبول» است، چه سطحی نیاز به اقدام فوری دارد، و چه سطحی را میشود با کنترلهای موجود یا با برنامه زمانبندیشده پذیرفت. نکته مهم این است که این معیارها باید توسط سطح مدیریت مجاز/مجاز به تصمیم تأیید شوند تا بعداً در ممیزی و تصمیمگیری داخلی، قابل دفاع باشد.
از نظر نقشها، معمولاً «مالک ریسک» (Risk Owner) کسی است که باید هم برنامه درمان ریسک را بفهمد و هم مسئولیت تصمیم را بپذیرد. وقتی Risk Treatment Plan آماده شد، ابتدا خودِ برنامه درمان باید توسط مالک(های) ریسک تأیید شود، و بعد مالک ریسک بر اساس معیار پذیرش، تصمیم میگیرد که ریسک باقیمانده را قبول کند یا نه. این تصمیم باید روشن، قابل پیگیری و ثبتشده باشد (مثلاً در Risk Register و همچنین در خروجی تصمیمات درمان).
اگر در بازسنجی مشخص شود سطح ریسک باقیمانده هنوز معیارهای پذیرش را پوشش نمیدهد، استاندارد عملاً شما را به یکی از این مسیرها هل میدهد: یا باید درمان را تقویت کنید (اقدام/کنترل اضافه، تغییر طراحی، یا افزایش اثربخشی کنترلها)، یا اگر سازمان بنا دارد استثنائاً ریسک را نگه دارد، این کار باید با تصمیم آگاهانه و تأیید مدیریت در سطح مناسب انجام شود—به زبان ساده: «پذیرش استثنا» باید دلیل و صاحب امضا داشته باشد.
بیشترین خطای ممیزی معمولاً از همینجا شروع میشود: معیار پذیرش ریسک مبهم است یا سطح تأیید مشخص نیست. در یک جلسه کوتاه، معیار پذیرش ریسک و سطح اختیارات را برای سازمانت قابل اجرا و قابل امضا طراحی میکنیم.
مزایای ISO/IEC 27005 برای سازمان شما
مهمترین مزیت ISO/IEC 27005 این است که مدیریت ریسک را از «حدس و گمان» و «چکلیستمحوری» جدا میکند و تبدیلش میکند به یک فرآیند تصمیمگیری قابلدفاع. به جای اینکه فقط بگویید «ریسک داریم»، شما دقیقاً نشان میدهید کدام سناریوها برای کدام دارایی/فرآیند مهمترند، چرا اینطور امتیاز گرفتهاند، و قرار است چه تصمیمی دربارهشان گرفته شود. نتیجهاش این میشود که هزینهکردهای امنیتی، اولویت پروژهها و انتخاب کنترلها، پشتوانه منطقی پیدا میکند و در جلسات مدیریتی هم قابل توضیح است.
از طرف دیگر، 27005 به شما کمک میکند خروجیهای امنیت اطلاعات را «مستندسازیپذیر و ممیزیپذیر» کنید. وقتی Risk Register و Risk Treatment Plan با منطق درست ساخته شوند، ممیز در Stage 1 و Stage 2 دقیقاً یک خط قابل ردیابی میبیند: ریسک → معیار ارزیابی → تصمیم درمان → اقدام/کنترل → شواهد اجرا → ریسک باقیمانده و پذیرش آن. این یعنی ممیزی از حالت دفاعیههای طولانی و بحثهای سلیقهای خارج میشود و شما با Evidence جلو میروید.
مطالعه پیشنهادی: تحلیل شکاف ISO 27001
مزیت بعدی، انعطافپذیری استاندارد است؛ اما نه به معنای «هر طور دوست داشتیم». 27005 اجازه میدهد مدل ارزیابی ریسک (کیفی، نیمهکمی یا کمی) و سطح جزئیات را با اندازه سازمان، حساسیت دادهها و بلوغ امنیت شما تنظیم کنید؛ در عین حال چارچوب را ثابت نگه میدارد تا فرآیند قابل تکرار باشد. این تعادل باعث میشود ریسکسنجی شما نه آنقدر پیچیده شود که اجرا نشود، و نه آنقدر ساده که تصمیمها بیاعتبار شوند.
نکته مهم دیگر این است که 27005 کمک میکند مدیریت ریسک «زنده» بماند. بسیاری از سازمانها یکبار ریسکها را مینویسند و فایلش بایگانی میشود؛ اما وقتی پایش و بازنگری دورهای و رویدادمحور را درست طراحی کنید، تغییرات مهم (مثل تغییر تامینکننده، مهاجرت سرویس، رخداد امنیتی، تغییر فرآیند یا تغییر الزامات قانونی) خودشان تبدیل میشوند به محرکهای رسمی برای بازنگری ریسک. نتیجه این است که ISMS شما با واقعیت سازمان حرکت میکند، نه با یک سند قدیمی.
و در نهایت، اگر دنبال «کاهش ریسک با حداقل اصطکاک» هستید، 27005 یک مزیت عملی بزرگ دارد: شما را مجبور میکند قبل از انتخاب کنترلها، مسئله را دقیق تعریف کنید. وقتی سناریو و پیامد روشن باشد، درمان ریسک هدفمند میشود؛ یعنی بهجای اجرای کنترلهای پراکنده، اقداماتی انتخاب میکنید که بیشترین اثر را روی ریسکهای اولویتدار دارند—و این دقیقاً همان چیزی است که هم بهرهوری امنیت را بالا میبرد و هم هزینهها را کنترل میکند.
چرا سازمانها باید از ISO/IEC 27005 استفاده کنند؟
برخلاف بعضی چارچوبهای مدیریت ریسک که یک نسخه تقریباً یکسان را برای همه سازمانها پیشنهاد میدهند، ISO/IEC 27005 عمداً انعطافپذیر طراحی شده تا بتوانی روش ارزیابی و مدیریت ریسک را با واقعیت کسبوکار خودت تنظیم کنی؛ یعنی معیارها، مدل امتیازدهی، سطح جزئیات، و حتی رویکرد شناسایی ریسکها را بر اساس هدفها، اندازه سازمان، نوع داراییها و میزان حساسیت دادهها انتخاب میکنی. مزیت این رویکرد این است که قبل از شروع هر فعالیت مدیریت ریسک، میدانی دقیقاً چه اطلاعاتی لازم است، چه کاری باید انجام شود، و خروجی مورد انتظار چیست؛ در نتیجه فرآیند ریسک از حالت سلیقهای و پراکنده خارج میشود و به یک چرخه ساده، قابلتکرار و قابلممیزی تبدیل میگردد.
در این استاندارد، هر فعالیت معمولاً با یک الگوی روشن توضیح داده میشود: اول ورودیها (اطلاعات و پیشنیازهای لازم)، بعد عمل (خود فعالیت اصلی)، سپس راهنمای اجرا (جزئیات و نکتههای پیادهسازی)، و در نهایت خروجیها (مستندات/اطلاعاتی که باید تولید شود)؛ دقیقاً همان چیزی که کمک میکند Risk Register و Risk Treatment Plan شما هم برای تصمیمگیری مدیریتی قابل اتکا باشد و هم در ممیزیهای ISO/IEC 27001 قابل دفاع.
جمعبندی
ISO/IEC 27005 در عمل به سازمان کمک میکند مدیریت ریسک امنیت اطلاعات را از حالت کلیگویی و چکلیستمحوری خارج کند و به یک چرخه تصمیمگیری قابلدفاع و قابلردیابی تبدیل کند. وقتی معیارهای ریسک، روش ارزیابی و سناریوهای ریسک درست تعریف شوند، شما دقیقاً میدانید کدام ریسکها اولویت واقعی دارند، چرا اینطور امتیاز گرفتهاند، و قرار است دربارهشان چه تصمیمی گرفته شود. نتیجه این میشود که امنیت اطلاعات فقط «اقدامهای پراکنده» نیست؛ یک مسیر منطقی و مستند دارد که هم برای مدیریت قابل فهم است و هم برای ممیزی قابل ارائه.
اگر هدف شما همراستا شدن با ISO/IEC 27001:2022 است، 27005 بهترین چارچوب عملی برای ساختن خروجیهایی مثل Risk Register و Risk Treatment Plan است؛ خروجیهایی که زنجیرهی «ریسک → تصمیم درمان → اقدام/کنترل → شواهد اجرا → ریسک باقیمانده و پذیرش آن» را شفاف میکنند. این شفافیت دقیقاً همان چیزی است که باعث میشود ارزیابی ریسک و درمان ریسک، در بازههای زمانی برنامهریزیشده و هنگام تغییرات مهم، قابل تکرار و قابل اثبات باقی بماند—و ISMS شما به جای یک سند ثابت، تبدیل به یک سیستم زنده و قابل بهبود شود.
در نهایت، اگر میخواهید مدیریت ریسک در سازمانتان واقعاً کار کند، معیارهای پذیرش ریسک را روشن کنید، ریسکها را سناریومحور بنویسید، درمان ریسک را به برنامه اجرایی با مسئول و زمانبندی و شواهد وصل کنید، و با پایش و بازنگری دورهای/رویدادمحور اجازه ندهید ریسکرجیستر به یک فایل قدیمی تبدیل شود. این دقیقاً نقطهای است که 27005 بیشترین ارزش را برای شما ایجاد میکند.
اگر میخواهی بدانی برای سازمان تو (با اندازه/حوزه فعالیت/چندسایتی بودن) زمانبندی واقعی و هزینه اجرای ISMS و آمادهسازی ممیزی چقدر میشود، مشخصات را ثبت کن تا برآورد دقیق ارائه دهیم.
منابع معتبر و استانداردهای مرجع
- ISO/IEC 27005:2022 — Guidance on managing information security risks (صفحه رسمی استاندارد در ISO؛ بهترین مرجع برای تعریف، دامنه و جایگاه 27005 کنار ISMS). (ISO)
- ISO/IEC 27001:2022 — ISMS Requirements (مرجع الزامات سیستم مدیریت امنیت اطلاعات و بندهای مرتبط با ریسک؛ پایهایترین استاندارد خانواده 27000). (ISO)
- ISO/IEC 27002:2022 — Implementation guidance for controls (مرجع راهنمای کنترلها؛ وقتی در درمان ریسک میخواهی کنترل/اقدام را انتخاب و توجیه کنی، این استاندارد پشتوانه اصلی است). (ISO)
- ISO/IEC 27000:2018 — Overview & Vocabulary / ISO/IEC 27000 family (برای واژهشناسی رسمی ISMS و اینکه اصطلاحات را یکدست و استاندارد استفاده کنی). (ISO)
- ISO 31000:2018 — Risk management guidelines (مرجع عمومی مدیریت ریسک؛ برای همراستاسازی ادبیات و چارچوب ریسک با رویکردهای سازمانی). (ISO)
- ANSI overview on ISO/IEC 27005:2022 changes (جمعبندی تغییرات نسخه 2022 توسط ANSI؛ مفید برای توضیح تفاوتها مثل سناریوی ریسک، رویکرد event-based و بازساختاردهی Annexها). (The ANSI Blog)
- NIST SP 800-30 Rev.1 — Guide for Conducting Risk Assessments (راهنمای بسیار معتبر از NIST برای روششناسی ارزیابی ریسک؛ بهعنوان رفرنس تکمیلی/مقایسهای عالی است). (NIST Computer Security Resource Center)
- ENISA — Risk Management Standards (گزارش ENISA که استانداردهای مدیریت ریسک را کنار هم میگذارد و به استفاده از ISO/IEC 27005 و ISO 31000 اشاره میکند؛ مناسب برای پشتوانه پژوهشی و مقایسهای). (ENISA)
- BSI overview of ISO/IEC 27005 (صفحه معرفی/کاربرد استاندارد در BSI؛ برای ارجاع عمومی و توضیح ارزش استاندارد به زبان ساده هم مفید است). (BSI)
