MedaGRC
دو سازمان ممکن است هر دو Risk Register داشته باشند، اما از نظر بلوغ GRC فاصله زیادی با هم داشته باشند. در سازمان اول ریسک‌ها سالی یک‌بار در Excel به‌روزرسانی می‌شوند؛ در سازمان دوم Owner، Treatment، KRI و ریسک باقیمانده به‌صورت مستمر پیگیری می‌شوند. داشتن فرم مشابه به معنی داشتن بلوغ مشابه نیست.
ارزیابی بلوغ GRC کمک می‌کند بفهمیم فرایندها تا چه حد تکرارپذیر، تعریف‌شده، اندازه‌پذیر و قابل بهبود هستند.
مدل پنج‌سطحی ساده و قابل استفاده
| سطح | وضعیت | نشانه رایج |
|---|---|---|
| ۱. واکنشی | Ad Hoc | کارها وابسته به افراد و نزدیک ممیزی انجام می‌شوند. |
| ۲. تکرارپذیر | Repeatable | چند الگو و روال وجود دارد اما یکپارچگی کم است. |
| ۳. تعریف‌شده | Defined | Role، Workflow و معیارها سازمانی شده‌اند. |
| ۴. اندازه‌پذیر | Measured | KRI، KPI و Control Effectiveness پایش می‌شوند. |
| ۵. تطبیقی | Adaptive | داده، تغییرات و Lessons Learned به بهبود مدل منجر می‌شوند. |
بلوغ را فقط با یک امتیاز نسنجید
یکی از خطاهای رایج این است که کل GRC به یک نمره مثل ۳.۲ تبدیل شود. عدد می‌تواند برای خلاصه مدیریتی مفید باشد، اما اگر ندانیم کدام بُعد عقب‌تر است، برنامه بهبود مبهم می‌شود. بهتر است حداقل چند محور جدا ارزیابی شوند.
- حاکمیت و مسئولیت‌پذیری
- مدیریت ریسک
- کنترل‌ها و اثربخشی آن‌ها
- انطباق و Mapping الزامات
- ممیزی و اقدامات اصلاحی
- Evidence و مستندات
- داده، گزارش و اتوماسیون
نمونه: مدیریت ریسک در سطح ۱ و ۴
در سطح ۱، Risk Register ممکن است فقط عنوان ریسک و امتیاز داشته باشد و Owner واقعی مشخص نباشد. در سطح ۴، سناریو، معیار ارزیابی، Inherent Risk، کنترل‌ها، Residual Risk، Treatment، KRI و Review Date قابل پیگیری هستند. تفاوت در تعداد ستون‌ها نیست؛ تفاوت در رفتار مدیریتی و کیفیت تصمیم است.
چطور ارزیابی را انجام دهیم؟
برای هر محور، Evidence بخواهید. اگر گفته می‌شود کنترل‌ها دوره‌ای بازبینی می‌شوند، نمونه واقعی Review را ببینید. اگر ادعا می‌شود ریسک‌ها Owner دارند، چند ریسک بحرانی را دنبال کنید و ببینید تصمیم آخر توسط چه کسی گرفته شده است.
ارزیابی بلوغ نباید پرسشنامه‌ای باشد که افراد بر اساس برداشت شخصی به آن نمره بدهند. Evidence و نمونه واقعی، نتیجه را قابل دفاع می‌کند.
از نتیجه ارزیابی چه استفاده‌ای کنیم؟
هدف «گرفتن نمره بالاتر» نیست. هدف انتخاب چند قابلیت با بیشترین اثر است. ممکن است سازمان در Documentation سطح ۴ باشد اما در Ownership سطح ۲. در این حالت خرید ابزار بیشتر لزوماً مشکل را حل نمی‌کند؛ باید مسئولیت و Escalation اصلاح شود.
نقشه ۹۰ روزه نمونه
| بازه | اقدام |
|---|---|
| ۳۰ روز اول | تعریف Scope، Role، معیار Risk و Inventory داده‌های موجود |
| ۳۰ روز دوم | Pilot روی چند Risk، Control و یک Framework |
| ۳۰ روز سوم | اندازه‌گیری، اصلاح Workflow و طراحی Rollout |
صفحه پیاده‌سازی MedaGRC همین رویکرد Pilot و Rollout مرحله‌ای را توضیح می‌دهد.
نقش نرم‌افزار در بلوغ
نرم‌افزار می‌تواند Ownership، Workflow، Reminder، Traceability و Reporting را پایدار کند؛ اما بلوغ را «خلق» نمی‌کند. اگر معیار ریسک نامفهوم یا Roleها اشتباه باشند، اتوماسیون فقط همان ضعف را سریع‌تر اجرا می‌کند. به همین دلیل انتخاب نرم‌افزار GRC باید همراه با طراحی Operating Model باشد.
سخن پایانی
ارزیابی بلوغ خوب به سازمان نمی‌گوید «چقدر خوب هستی»؛ می‌گوید «کدام قابلیت بعدی بیشترین ارزش را دارد». اگر نتیجه ارزیابی به چند اقدام مشخص با Owner و Deadline تبدیل نشود، خود ارزیابی هم به یک گزارش دیگر در آرشیو تبدیل می‌شود.
