حاکمیت، ریسک و انطباق (GRC) چیست؟

حاکمیت، ریسک و انطباق (GRC) چیست؟ راهنمای جامع GRC با رویکرد امنیت سایبری

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

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

مفهوم GRC با هدف ایجاد پیوندی منسجم میان حاکمیت سازمانی، مدیریت ریسک و انطباق با الزامات شکل گرفته است. GRC به سازمان کمک می‌کند تصمیم‌های مدیریتی، کنترل‌های داخلی، ریسک‌های کسب‌وکار و تعهدات قانونی را در یک چارچوب هماهنگ بررسی کند.

1. GRC چیست؟

GRC مخفف سه واژه Governance, Risk, Compliance است:

• Governance — حاکمیت: مجموعه ساختارها، سیاست‌ها، اختیارات، مسئولیت‌ها و فرایندهایی که تعیین می‌کنند سازمان چگونه هدایت می‌شود، چگونه تصمیم می‌گیرد و چگونه بر عملکرد خود نظارت می‌کند.
• Risk — ریسک: احتمال وقوع رویدادها و پیامدهای نامطلوب یا انحراف از اهداف سازمان و میزان تأثیر آن‌ها بر کسب‌وکار را مشخص می‌کند.
• Compliance — انطباق: فرایند شناسایی، اجرا، پایش و اثبات رعایت الزامات قانونی، مقرراتی، قراردادی و سایر تعهدات الزام‌آور یا پذیرفته‌شده سازمان را تعیین می‌کند.

در تعریف رایج، GRC را می‌توان مجموعه‌ای هماهنگ از قابلیت‌ها دانست که به سازمان اجازه می‌دهد فعالیت‌های خود را در راستای اهداف راهبردی هدایت کند، ریسک‌ها را در محدوده قابل‌قبول مدیریت کند و تعهدات خود را به‌صورت قابل‌ارزیابی رعایت کند.

نکته مهم این است که GRC الزاماً یک استاندارد واحد، یک نرم‌افزار مشخص یا یک واحد سازمانی مستقل نیست. این مفهوم می‌تواند به‌صورت یک مدل عملیاتی، مجموعه‌ای از فرایندها و کنترل‌ها یا یک پلتفرم نرم‌افزاری پیاده‌سازی شود.

1.1. ارتباط میان حاکمیت، ریسک و انطباق

سه مؤلفه GRC مستقل از یکدیگر نیستند. تصمیم‌های حاکمیتی تعیین می‌کنند چه میزان ریسک برای سازمان قابل‌پذیرش است؛ مدیریت ریسک مشخص می‌کند چه تهدیدها و عدم‌قطعیت‌هایی می‌توانند اهداف سازمان را تحت تأثیر قرار دهند؛ و انطباق کمک می‌کند الزامات مرتبط در سیاست‌ها، کنترل‌ها و فرایندهای عملیاتی منعکس شوند.

برای مثال، فرض کنید یک شرکت خدمات مالی از یک سامانه ابری برای پردازش اطلاعات مشتریان استفاده می‌کند.

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

GRC تلاش می‌کند این ارتباطات را شفاف و قابل‌پیگیری کند.

1.2. تفاوت GRC با مدیریت ریسک سازمانی

مدیریت ریسک سازمانی یا ERM مخفف Enterprise Risk Management است. ERM بر شناسایی، ارزیابی و مدیریت ریسک‌هایی تمرکز دارد که اهداف و عملکرد کلی سازمان را تحت تأثیر قرار می‌دهند؛ از جمله ریسک‌های مالی، عملیاتی، راهبردی، حقوقی و فناوری.

GRC مفهومی گسترده‌تر از یک فرایند منفرد مدیریت ریسک است. این مفهوم ارتباط میان حاکمیت، مدیریت ریسک و مدیریت انطباق را نیز در بر می‌گیرد.

البته مرز این دو مفهوم در عمل می‌تواند هم‌پوشانی داشته باشد. برای مثال، یک برنامه ERM ممکن است حاکمیت ریسک، گزارش‌دهی به هیئت‌مدیره و رعایت الزامات را نیز پوشش دهد. بنابراین، تفاوت اصلی را باید در دامنه و مدل عملیاتی مورد استفاده سازمان جست‌وجو کرد، نه صرفاً در نام‌گذاری.

2. چرا سازمان‌ها به GRC نیاز دارند؟

نیاز به GRC از افزایش پیچیدگی محیط کسب‌وکار، گسترش وابستگی‌های فناوری، تنوع الزامات قانونی و دشوارتر شدن نظارت بر فعالیت‌های سازمان ناشی می‌شود.

2.1. پراکندگی اطلاعات و مسئولیت‌ها

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

این پراکندگی مشکلاتی ایجاد می‌کند؛ از جمله:

• وجود چند نسخه متفاوت از یک سیاست یا ارزیابی ریسک
• تکرار ارزیابی یک کنترل برای چند چارچوب
• نامشخص بودن مالک ریسک یا مسئول اصلاح یک نقص
• دشواری تهیه گزارش یکپارچه برای مدیران
• تأخیر در شناسایی وضعیت واقعی کنترل‌ها
• افزایش هزینه آماده‌سازی شواهد برای ممیزی

یک برنامه GRC مناسب، این اطلاعات را در یک مدل قابل‌ردیابی به یکدیگر مرتبط می‌کند و در صورت استفاده از نرم‌افزار، امکان مدیریت متمرکز آن‌ها را فراهم می‌سازد.

2.2. افزایش الزامات قانونی و قراردادی

سازمان‌ها ممکن است هم‌زمان با چندین دسته الزام مواجه باشند؛ برای مثال، قوانین بالادستی، قوانین حفاظت از داده، قراردادهای مشتریان، الزامات امنیت زنجیره تأمین و استانداردهای داوطلبانه.

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

GRC کمک می‌کند الزامات به کنترل‌های عملیاتی، مالکان مشخص، شواهد قابل‌بررسی و فعالیت‌های اصلاحی متصل شوند.

2.3. تغییر ماهیت ریسک‌های سایبری

تهدیدهای سایبری تنها به حملات فنی محدود نیستند. وابستگی به ارائه‌دهندگان خدمات، خطاهای پیکربندی، سوءاستفاده از حساب‌های دارای دسترسی بالا، ضعف در فرایند توسعه نرم‌افزار، سرقت اطلاعات و اختلال در زنجیره تأمین نیز می‌توانند پیامدهای جدی ایجاد کنند.

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

2.4. پاسخ‌گویی مدیریتی و شفافیت تصمیم‌ها

مدیریت ریسک تنها مسئولیت تیم امنیت اطلاعات نیست. مدیران کسب‌وکار، فناوری اطلاعات، حقوقی، منابع انسانی، تدارکات و سایر واحدها ممکن است در مالکیت ریسک‌ها و اجرای کنترل‌ها نقش داشته باشند.

یک مدل GRC مناسب موارد زیر را مشخص می‌کند:

• چه کسی مسئول هر ریسک است.
• چه کسی مسئول اجرای کنترل است.
• چه کسی اثربخشی کنترل را ارزیابی می‌کند.
• چه کسی اختیار پذیرش ریسک را دارد.
• چه زمانی یک مسئله باید به سطح بالاتر مدیریتی ارجاع شود.

این تفکیک، پاسخ‌گویی را تقویت می‌کند و از واگذاری ضمنی همه مسئولیت‌ها به واحد امنیت جلوگیری می‌کند.

2.5. بهبود تخصیص منابع

بودجه، نیروی انسانی و زمان سازمان محدود هستند. بنابراین، همه ریسک‌ها را نمی‌توان هم‌زمان و با شدت یکسان کاهش داد.

GRC با ایجاد ارتباط میان ریسک، اهداف کسب‌وکار، کنترل‌های موجود، هزینه اصلاح و میزان ریسک باقیمانده، به تصمیم‌گیری آگاهانه‌تر درباره سرمایه‌گذاری کمک می‌کند.

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

3. اجزای اصلی GRC

3.1. حاکمیت (Governance)

حاکمیت تعیین می‌کند سازمان چگونه هدایت و کنترل می‌شود. در چارچوب GRC، این بخش معمولاً شامل موارد زیر است:

• تعریف ساختار نظارتی و سطوح اختیار
• تدوین و تصویب سیاست‌ها
• تعیین نقش‌ها و مسئولیت‌ها
• تعریف اهداف و شاخص‌های عملکرد و ریسک
• نظارت بر اجرای تصمیم‌ها
• گزارش‌دهی به مدیریت ارشد و هیئت‌مدیره
• مدیریت استثناها و پذیرش ریسک
• نظارت بر عملکرد واحدهای مسئول

برای نمونه، سیاست امنیت اطلاعات باید علاوه بر بیان اصول کلی، مالک مشخص، مرجع تصویب، دامنه کاربرد، دوره بازبینی و ارتباط با فرایندهای اجرایی داشته باشد.

صرف انتشار یک سیاست به معنای اجرای مؤثر آن نیست. سازمان باید بتواند نشان دهد سیاست به کنترل‌های مشخص تبدیل شده، مسئول اجرای آن تعیین شده و میزان رعایت آن بررسی می‌شود.

3.2. مدیریت ریسک (Risk Management)

مدیریت ریسک فرایندی مستمر برای شناسایی، تحلیل، ارزیابی، پاسخ و پایش ریسک‌ها است.

در یک مدل متداول، مراحل مدیریت ریسک عبارت‌اند از:

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

در این فرایند، تمایز میان ریسک ذاتی و ریسک باقیمانده اهمیت دارد. ریسک ذاتی، پیش از در نظر گرفتن کنترل‌ها ارزیابی می‌شود؛ ریسک باقیمانده، ریسکی است که پس از لحاظ کردن کنترل‌های موجود یا برنامه‌ریزی‌شده باقی می‌ماند. نحوه محاسبه و تعریف دقیق این دو باید در روش‌شناسی سازمان مشخص باشد.

3.3. انطباق (Compliance)

انطباق به این معنا نیست که سازمان صرفاً فهرستی از استانداردها را در اختیار داشته باشد. سازمان باید بداند کدام الزامات برای آن قابل‌اعمال هستند، هر الزام چه تعهدی ایجاد می‌کند و چه شواهدی برای اثبات رعایت آن لازم است.

فعالیت‌های اصلی انطباق عبارت‌اند از:

• شناسایی منابع الزامات
• تعیین دامنه و قابلیت اعمال هر الزام
• نگاشت الزامات به سیاست‌ها و کنترل‌ها
• تعیین مسئولیت اجرا و نظارت
• جمع‌آوری شواهد
• ارزیابی شکاف‌ها
• مدیریت عدم‌انطباق‌ها و اقدامات اصلاحی
• پیگیری تغییرات قوانین و الزامات.

برای مثال، اگر یک قرارداد مشتری سازمان را ملزم به استفاده از احراز هویت چندعاملی برای دسترسی‌های مدیریتی کند، سازمان باید این تعهد را به کنترل اجرایی مشخصی تبدیل کند، مسئول آن را تعیین کند و شواهدی از اجرای کنترل فراهم آورد.

این رویکرد باعث می‌شود انطباق از سطح مستندسازی به سطح اجرا و ارزیابی منتقل شود.

4. استانداردها و چارچوب‌های مرتبط با GRC

یکی از نکات مهم برای درک دقیق GRC این است که یک استاندارد واحد و جهان‌شمول با عنوان GRC وجود ندارد که همه ابعاد این مفهوم را به‌تنهایی تعریف کند. GRC بیشتر یک رویکرد یکپارچه است که می‌تواند از استانداردها، چارچوب‌ها و الزامات مختلف استفاده کند.

استانداردها و چارچوب‌های زیر از منابع مهم در طراحی و اجرای برنامه‌های GRC هستند.

4.1. ISO 31000 مدیریت ریسک

استاندارد ISO 31000 اصول، چارچوب و فرایندهای مدیریت ریسک را ارائه می‌کند. این استاندارد برای سازمان‌های مختلف و انواع گوناگون ریسک طراحی شده است.

از کاربردهای آن می‌توان به موارد زیر اشاره کرد:

• ایجاد زبان مشترک برای بحث درباره ریسک
• تعریف معیارهای ارزیابی و پذیرش ریسک
• ادغام مدیریت ریسک با تصمیم‌گیری و فرایندهای سازمان
• ایجاد سازوکار پایش و بهبود مستمر.

ISO 31000 راهنمای مدیریت ریسک است و نباید آن را به‌عنوان یک استاندارد صدور گواهی مستقل برای سازمان تلقی کرد.

4.2. ISO/IEC 27001 سیستم مدیریت امنیت اطلاعات

ISO/IEC 27001 الزامات ایجاد، پیاده‌سازی، نگهداری و بهبود مستمر سیستم مدیریت امنیت اطلاعات (ISMS) را تعیین می‌کند.

این استاندارد در GRC امنیت سایبری نقش مهمی دارد، زیرا مدیریت ریسک امنیت اطلاعات، سیاست‌ها، مسئولیت‌ها، کنترل‌ها، ارزیابی عملکرد و بهبود مستمر را در یک ساختار مدیریتی قرار می‌دهد.

نسخه ۲۰۲۲ این استاندارد، همراه با اصلاحیه‌های منتشرشده، یکی از مراجع اصلی جاری در این حوزه است. سازمانی که در پی گواهی ISO/IEC 27001 است باید الزامات نسخه قابل‌اعمال و دامنه گواهی موردنظر را دقیق بررسی کند.

نکته مهم آن است که اجرای یک نرم‌افزار GRC به‌تنهایی به معنای انطباق با ISO/IEC 27001 یا دریافت گواهی آن نیست. نرم‌افزار ممکن است اجرای بخشی از الزامات را تسهیل کند، اما مسئولیت استقرار و اثربخشی سیستم مدیریت بر عهده سازمان باقی می‌ماند.

4.3. چارچوب امنیت سایبری NIST

چارچوب امنیت سایبری NIST یا NIST CSF 2.0 در سال ۲۰۲۴ منتشر شد و برای کمک به سازمان‌ها در مدیریت ریسک سایبری طراحی شده است.

شش کارکرد سطح بالای آن عبارت‌اند از:

• Govern (حاکمیت): تعیین راهبرد، سیاست‌ها، نقش‌ها و نظارت بر ریسک سایبری
• Identify (شناسایی): درک دارایی‌ها، محیط، وابستگی‌ها و ریسک‌ها
• Protect (حفاظت): اجرای اقدامات حفاظتی
• Detect (تشخیص): کشف و تحلیل رخدادهای امنیتی
• Respond (پاسخ): مدیریت و پاسخ‌گویی به رخدادها
• Recover (بازیابی): بازگرداندن قابلیت‌ها و خدمات پس از اختلال

افزوده شدن کارکرد Govern در CSF 2.0 اهمیت حاکمیت و مدیریت ریسک را در کنار فعالیت‌های فنی امنیت سایبری برجسته می‌کند.

CSF یک چارچوب برای مدیریت و بهبود وضعیت امنیت سایبری است؛ یک قانون عمومی و گواهی انطباق نیست.

4.4. NIST SP 800-53 کنترل‌های امنیت و حریم خصوصی

NIST SP 800-53 مجموعه‌ای گسترده از کنترل‌های امنیتی و حریم خصوصی را برای سامانه‌ها و سازمان‌ها ارائه می‌کند. این کنترل‌ها موضوعاتی مانند کنترل دسترسی، حسابرسی، پاسخ به رخداد، مدیریت پیکربندی، حفاظت از اطلاعات و مدیریت ریسک را پوشش می‌دهند.

این مرجع برای سازمان‌هایی که به یک کاتالوگ دقیق کنترل نیاز دارند مفید است. با این حال، انتخاب و اعمال کنترل‌ها باید با توجه به دامنه، زمینه، ریسک و الزامات مربوط انجام شود؛ استفاده از تمام کنترل‌ها در همه سازمان‌ها لزوماً مناسب یا ضروری نیست.

4.5. COBIT حاکمیت و مدیریت فناوری اطلاعات

COBIT چارچوبی برای حاکمیت و مدیریت اطلاعات و فناوری سازمانی است. این چارچوب به هم‌راستایی فناوری اطلاعات با اهداف کسب‌وکار، تعیین مسئولیت‌ها، مدیریت ریسک و ارزیابی عملکرد کمک می‌کند.

COBIT به‌ویژه برای سازمان‌هایی مفید است که می‌خواهند ارتباط میان اهداف راهبردی، تصمیم‌های فناوری، فرایندهای مدیریتی و سازوکارهای نظارتی را روشن‌تر کنند.

COBIT را نباید صرفاً یک چارچوب امنیت سایبری دانست؛ دامنه آن گسترده‌تر است و حاکمیت و مدیریت فناوری اطلاعات را هدف قرار می‌دهد.

4.6. COSO ERM مدیریت ریسک سازمانی

چارچوب COSO ERM ارتباط میان ریسک، راهبرد و عملکرد را بررسی می‌کند. این چارچوب به سازمان کمک می‌کند ریسک را در تصمیم‌گیری‌های کلان و فرایندهای کسب‌وکار وارد کند.

در GRC، COSO ERM می‌تواند برای طراحی حاکمیت ریسک، تعیین نقش‌های نظارتی و ارتباط دادن ریسک‌های فناوری و امنیتی با اهداف مالی و راهبردی به کار رود.

4.7. استانداردهای ممیزی و تضمین

استانداردهای مجموعه ISO 19011 راهنمای ممیزی سیستم‌های مدیریت را ارائه می‌کنند. همچنین، چارچوب‌ها و استانداردهای مرتبط با حسابرسی داخلی و تضمین مستقل می‌توانند برای طراحی برنامه‌های ارزیابی و گزارش‌دهی مفید باشند.

در استفاده از این منابع باید میان راهنمای ممیزی، الزامات یک سیستم مدیریت و الزامات یک ارزیابی مستقل تمایز قائل شد. این اسناد اهداف و کاربردهای متفاوتی دارند.

4.8. مقررات و الزامات بخشی

علاوه بر استانداردها، سازمان ممکن است ملزم به رعایت قوانین حفاظت از داده، مقررات مالی، الزامات حوزه سلامت، تعهدات قراردادی یا قواعد امنیتی خاص صنعت خود باشد.

برای مثال، GDPR برای سازمان‌هایی که در دامنه اعمال آن قرار می‌گیرند الزامات حفاظت از داده‌های شخصی ایجاد می‌کند. PCI DSS نیز مجموعه‌ای از الزامات امنیتی مرتبط با محیط داده دارنده کارت و دامنه قابل‌اعمال پرداخت را تعریف می‌کند.

این منابع را نباید بدون بررسی دامنه کاربرد، برای همه سازمان‌ها الزام‌آور دانست. تعیین اینکه کدام الزام برای یک سازمان مشخص قابل‌اعمال است، به محل فعالیت، نوع داده، نوع خدمات، روابط قراردادی و شرایط حقوقی مربوط بستگی دارد.

5. برداشت‌های اشتباه درباره GRC

شناخت برداشت‌های نادرست اهمیت زیادی دارد؛ زیرا ممکن است سازمان را به سمت پیاده‌سازی پرهزینه اما کم‌اثر سوق دهد.

برداشت اشتباه اول: GRC همان نرم‌افزار GRC است

GRC در اصل یک رویکرد مدیریتی و مجموعه‌ای از قابلیت‌های سازمانی است. نرم‌افزار تنها ابزاری برای پشتیبانی از این قابلیت‌ها محسوب می‌شود.

اگر نقش‌ها، معیارهای ریسک، سیاست‌ها و فرایندهای سازمان مبهم باشند، نرم‌افزار معمولاً همان ابهام‌ها را به شکلی دیجیتال بازتولید می‌کند.

برداشت اشتباه دوم: GRC فقط برای سازمان‌های بزرگ است

پیچیدگی و مقیاس پیاده‌سازی باید متناسب با اندازه، صنعت، ریسک و الزامات سازمان باشد. یک شرکت کوچک نیز ممکن است به دلیل نوع اطلاعات پردازش‌شده یا تعهدات قراردادی به سازوکار مشخصی برای مدیریت ریسک و انطباق نیاز داشته باشد.

در چنین شرایطی، یک مدل ساده و متمرکز می‌تواند مناسب‌تر از یک سامانه پیچیده و پرهزینه باشد.

برداشت اشتباه سوم: GRC معادل انطباق با استانداردها است

انطباق یکی از سه مؤلفه اصلی GRC است، اما تمام آن نیست. سازمان ممکن است الزامات یک استاندارد را مستند کرده باشد، در حالی که ریسک‌های مهم کسب‌وکار را به‌درستی مدیریت نمی‌کند یا ساختار تصمیم‌گیری روشنی ندارد.

هدف GRC صرفاً گذراندن ممیزی نیست؛ بلکه ایجاد سازوکاری پایدار برای تصمیم‌گیری، کنترل و پاسخ‌گویی است.

برداشت اشتباه چهارم: داشتن کنترل یعنی مدیریت شدن ریسک

وجود یک کنترل در سیاست یا فهرست کنترل‌ها لزوماً نشان نمی‌دهد که کنترل به‌درستی اجرا می‌شود یا ریسک را به میزان مورد انتظار کاهش می‌دهد.

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

برداشت اشتباه پنجم: هدف GRC حذف همه ریسک‌ها است

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

GRC کمک می‌کند ریسک‌ها شناخته شوند، پاسخ مناسب برای آن‌ها انتخاب شود و پذیرش ریسک‌های باقیمانده به‌صورت آگاهانه و در سطح اختیار مناسب انجام گیرد.

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

کنترل‌ها باید با توجه به ریسک، نوع دارایی، الزام قابل‌اعمال و زمینه عملیاتی انتخاب و پیاده‌سازی شوند. ممکن است دو سازمان کنترل‌های متفاوتی به کار گیرند و هر دو بتوانند از رویکرد خود دفاع کنند، مشروط بر اینکه الزامات مربوط را رعایت کرده و اثربخشی کنترل‌های خود را به‌درستی ارزیابی کنند.

البته این اصل به معنای امکان نادیده گرفتن الزامات صریح قانونی یا قراردادی نیست.

برداشت اشتباه هفتم: داشبورد سبز یعنی سازمان امن است

داشبوردها معمولاً نمایشی فشرده از داده‌های ثبت‌شده هستند. اگر داده‌ها ناقص، قدیمی یا فاقد پشتوانه شواهد باشند، وضعیت ظاهراً مطلوب ممکن است با واقعیت تفاوت داشته باشد.

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

برداشت اشتباه هشتم: GRC مسئولیت امنیت را از واحد فناوری اطلاعات می‌گیرد

GRC مسئولیت‌ها را حذف نمی‌کند؛ بلکه آن‌ها را شفاف‌تر می‌سازد. تیم امنیت ممکن است مسئول طراحی کنترل باشد، واحد فناوری مسئول اجرای آن و مالک کسب‌وکار مسئول پذیرش ریسک مربوط. ارزیابی مستقل نیز باید تا حد امکان از اجرای همان کنترل تفکیک شود.

این تفکیک به‌ویژه برای جلوگیری از تعارض منافع و افزایش اعتبار گزارش‌ها اهمیت دارد.

6. GRC با رویکرد امنیت سایبری

GRC امنیت سایبری یا Cybersecurity GRC به مجموعه قابلیت‌ها و فرایندهایی گفته می‌شود که حاکمیت امنیت سایبری، مدیریت ریسک‌های سایبری و رعایت الزامات مرتبط را در سطح سازمان هماهنگ می‌کنند.

در این رویکرد، امنیت سایبری صرفاً یک مسئله فنی نیست؛ بلکه بخشی از مدیریت ریسک سازمان و یکی از عوامل مؤثر بر تداوم فعالیت، اعتماد مشتریان و تحقق اهداف کسب‌وکار محسوب می‌شود.

چارچوب NIST CSF 2.0 نیز با افزودن کارکرد Govern، بر اهمیت حاکمیت، سیاست‌گذاری، تعیین مسئولیت‌ها و هم‌راستایی مدیریت ریسک سایبری با اهداف سازمان تأکید می‌کند. این چارچوب برای سازمان‌های مختلف قابل استفاده است و روش واحد و اجباری برای اجرای همه کنترل‌ها تجویز نمی‌کند.

6.1. اهداف GRC در امنیت سایبری

مهم‌ترین اهداف یک برنامه GRC با تمرکز بر امنیت سایبری عبارت‌اند از:

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

6.2. چه ریسک‌هایی در GRC امنیت سایبری بررسی می‌شوند؟

دامنه ریسک‌ها به نوع فعالیت سازمان وابسته است، اما موارد زیر در بسیاری از برنامه‌های GRC اهمیت دارند.

• هویت و دسترسی: دسترسی غیرمجاز، سرقت اعتبارنامه یا باقی ماندن دسترسی کارکنان سابق
• داده و حریم خصوصی: افشای اطلاعات حساس یا نگهداری داده بیش از مدت مجاز
• زیرساخت و شبکه: پیکربندی ناامن، دسترسی مدیریتی غیرضروری یا اختلال در سرویس
• آسیب‌پذیری‌ها: بهره‌برداری از آسیب‌پذیری یک سامانه حیاتی
• عملیات امنیت: تشخیص دیرهنگام رخداد یا نبود فرایند پاسخ‌گویی مؤثر
• تداوم کسب‌وکار: از دسترس خارج شدن سامانه‌های حیاتی و ناکافی بودن قابلیت بازیابی
• زنجیره تأمین: اختلال یا رخداد امنیتی در ارائه‌دهنده خدمات یا پیمانکار
• توسعه نرم‌افزار: انتشار نسخه آسیب‌پذیر یا افشای اسرار در مخزن کد
• کارکنان و فرایندها: خطای انسانی، سوءاستفاده از دسترسی یا ضعف در آموزش و آگاهی
• حاکمیت و انطباق: عدم اجرای تعهد قراردادی یا نبود شواهد معتبر از اجرای کنترل

این فهرست یک طبقه‌بندی نمونه است، نه فهرستی جامع یا الزام‌آور. هر سازمان باید دامنه ریسک خود را متناسب با مدل کسب‌وکار، دارایی‌ها، تهدیدها و الزامات مربوط تعریف کند.

6.3. چرخه مدیریت ریسک سایبری در GRC

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

1. شناخت دارایی‌ها و فرایندهای حیاتی: سامانه‌ها، داده‌ها، خدمات و وابستگی‌های کسب‌وکار
2. شناسایی و تحلیل سناریوهای ریسک: تهدید، آسیب‌پذیری، احتمال یا امکان وقوع و پیامدها
3. ارزیابی ریسک و مقایسه با معیارهای پذیرش: اولویت‌بندی بر اساس اثر کسب‌وکار و معیارهای مصوب
4. انتخاب پاسخ و تعیین مالک: کاهش، اجتناب، انتقال یا پذیرش ریسک در سطح اختیار مناسب
5. اجرای کنترل‌ها و جمع‌آوری شواهد: اقدامات اصلاحی، مسئول اجرا، مهلت و شواهد قابل‌بررسی
6. پایش، گزارش‌دهی و ارزیابی مجدد

در این چرخه، ثبت ریسک پایان کار نیست. یک ریسک باید به تصمیم مشخصی منجر شود: اقدام اصلاحی، تغییر روش کار، انتقال ریسک یا پذیرش مستند آن توسط فرد دارای اختیار.

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

6.4. ارتباط GRC با مدیریت امنیت اطلاعات (ISMS)

سیستم مدیریت امنیت اطلاعات یا ISMS یکی از بسترهای مهم برای پیاده‌سازی مدیریت ریسک امنیت اطلاعات است. استاندارد ISO/IEC 27001:2022 الزامات یک ISMS را تعریف می‌کند و سازمان را به ایجاد، نگهداری و بهبود مستمر آن ملزم می‌سازد.

GRC و ISMS از نظر دامنه دقیقاً یکسان نیستند. ISMS ممکن است یکی از اجزای اصلی برنامه GRC باشد، در حالی که GRC می‌تواند علاوه بر امنیت اطلاعات، مدیریت ریسک سازمانی، حاکمیت فناوری، انطباق حقوقی و سایر حوزه‌های کنترلی را نیز پوشش دهد.

برای نمونه، یک سازمان ممکن است ISMS خود را بر اساس ISO/IEC 27001 مدیریت کند و در کنار آن، الزامات قراردادی مشتریان، ریسک ارائه‌دهندگان ابری و ریسک‌های کلان کسب‌وکار را در برنامه GRC یکپارچه سازد.

این تفکیک به جلوگیری از اشتباه رایج «برابر دانستن GRC با ISO 27001» کمک می‌کند.

6.5. ارتباط GRC با SOC و ابزارهای امنیتی

مرکز عملیات امنیت (SOC) و ابزارهایی مانند SIEM، EDR، سامانه‌های مدیریت آسیب‌پذیری و ابزارهای اسکن پیکربندی، داده‌های مهمی درباره وضعیت امنیتی سازمان تولید می‌کنند.

GRC می‌تواند از این داده‌ها برای ارزیابی ریسک، سنجش اجرای کنترل‌ها، پیگیری شکاف‌ها و تهیه گزارش مدیریتی استفاده کند؛ اما جایگزین عملیات امنیت یا سامانه‌های تخصصی آن‌ها نیست.

برای مثال:

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

6.6. شاخص‌های کلیدی عملکرد و ریسک در GRC امنیت سایبری

برای مدیریت مؤثر، سازمان به شاخص‌هایی نیاز دارد که وضعیت واقعی ریسک و کنترل‌ها را منعکس کنند.

دو دسته شاخص پرکاربرد عبارت‌اند از:

• KPI (شاخص کلیدی عملکرد): میزان تحقق یک هدف یا عملکرد یک فرایند را اندازه‌گیری می‌کند.
• KRI (شاخص کلیدی ریسک): تغییرات یا شرایطی را نشان می‌دهد که می‌توانند بیانگر افزایش یا کاهش ریسک باشند.

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

به همین دلیل، شاخص‌ها باید همراه با تعریف دقیق، منبع داده، دامنه پوشش، تناوب اندازه‌گیری و محدودیت‌های تفسیر گزارش شوند.

7. نرم‌افزار GRC چیست و چه کاربردی دارد؟

نرم‌افزار GRC یا GRC Platform سامانه‌ای است که فرایندها، اطلاعات و ارتباطات مورد نیاز برای مدیریت حاکمیت، ریسک و انطباق را به شکل ساختاریافته پشتیبانی می‌کند.

این نرم‌افزار می‌تواند یک سامانه مستقل باشد یا به‌صورت مجموعه‌ای از ماژول‌ها در یک پلتفرم بزرگ‌تر مدیریت ریسک و امنیت سازمانی ارائه شود.

هدف اصلی نرم‌افزار GRC صرفاً نگهداری مستندات نیست. یک سامانه مناسب باید بتواند ارتباط میان الزامات، کنترل‌ها، ریسک‌ها، دارایی‌ها، مسئولیت‌ها، شواهد و تصمیم‌های مدیریتی را حفظ کند.

7.1. قابلیت‌های اصلی یک نرم‌افزار GRC

مدیریت کنترل‌ها و الزامات

ثبت الزامات، طراحی کنترل‌ها، نگاشت کنترل‌ها به چند چارچوب، تعیین مالک و ارزیابی وضعیت اجرا.

مدیریت ریسک

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

مدیریت شواهد و ممیزی

نگهداری مستندات، ثبت منشأ شواهد، مدیریت درخواست‌های ممیزی، ثبت یافته‌ها و پیگیری اقدامات اصلاحی.

مدیریت گردش کار و مسئولیت‌ها

تخصیص وظایف، تعیین مهلت، تأیید یا رد ارزیابی‌ها، ارجاع مسائل و ثبت تاریخچه تصمیم‌ها.

گزارش‌دهی و داشبورد

نمایش وضعیت ریسک‌ها، شکاف‌های انطباق، اثربخشی کنترل‌ها، تأخیرها و موضوعات نیازمند تصمیم مدیریتی.

یکپارچگی با سامانه‌های دیگر

دریافت داده از سامانه‌های هویت، مدیریت آسیب‌پذیری، تیکتینگ، مدیریت دارایی، مدیریت تغییر و ابزارهای امنیتی.

وجود این قابلیت‌ها در همه محصولات الزامی نیست؛ دامنه مناسب به نیاز سازمان، پیچیدگی فرایندها و معماری انتخاب‌شده بستگی دارد.

7.2. تفاوت نرم‌افزار GRC با سامانه مدیریت آسیب‌پذیری و SIEM

نرم‌افزار GRC، سامانه مدیریت آسیب‌پذیری و SIEM ممکن است در برخی گردش کارها با یکدیگر ارتباط داشته باشند، اما مسئله اصلی هر کدام متفاوت است. در سامانه GRC مسئله اصلی ریسک، کنترل، انطباق و پاسخ‌گویی سازمانی است در حاله که SIEM گردآوری و تحلیل رخدادها و ثبت‌های امنیتی را پوشش می‌دهد.

یک پلتفرم GRC می‌تواند بعضی قابلیت‌های سامانه‌های دیگر را در خود داشته باشد، اما ادغام آن‌ها لزوماً به معنای جایگزینی ابزارهای تخصصی نیست.

8. چگونه مفهوم GRC را به یک محصول نرم‌افزاری قابل استفاده تبدیل کنیم؟

تبدیل GRC به نرم‌افزار، صرفاً به معنای ایجاد فرم‌هایی برای ثبت ریسک، کنترل و مستندات نیست. محصولی که قرار است در محیط واقعی سازمان استفاده شود، باید مدل داده مشخص، فرایندهای اجرایی قابل‌اعتماد، کنترل دسترسی، سازوکار ثبت شواهد، گردش کار، گزارش‌دهی و قابلیت توسعه داشته باشد.

در ادامه، یک الگوی پیشنهادی برای طراحی چنین محصولی بررسی می‌شود. این الگو یک نسخه الزامی از سوی استاندارد خاصی نیست؛ بلکه از اصول عمومی مهندسی نرم‌افزار، مدیریت ریسک و نیازهای رایج GRC استخراج شده است.

گام اول: تعیین مسئله و کاربران محصول

پیش از انتخاب فناوری یا طراحی پایگاه داده، باید مشخص شود محصول قرار است کدام مسئله را حل کند.

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

• مدیریت انطباق با ISO/IEC 27001
• ایجاد رجیستری متمرکز ریسک‌های سایبری
• مدیریت کنترل‌ها و شواهد ممیزی
• مدیریت ریسک تأمین‌کنندگان
• یکپارچه‌سازی فرایندهای امنیت، حقوقی و ممیزی
• ارائه یک پلتفرم چندماژوله برای GRC سازمانی

این اهداف نیازمندی‌های متفاوتی ایجاد می‌کنند. محصولی که صرفاً برای ارزیابی آمادگی ISO/IEC 27001 طراحی شده است، الزاماً به همان معماری یا امکانات محصولی که مدیریت ریسک چندشرکتی و چندچارچوبی انجام می‌دهد، نیاز ندارد.

همچنین باید کاربران اصلی مشخص شوند. این کاربران ممکن است شامل مدیر GRC، مدیر امنیت اطلاعات، مسئول کنترل، مسئول ریسک، ممیز، مدیر واحد کسب‌وکار، مدیر ارشد امنیت اطلاعات (CISO) و مدیران ارشد باشند. هر گروه به سطح متفاوتی از جزئیات، اختیار و گزارش نیاز دارند.

گام دوم: طراحی مدل دامنه و موجودیت‌های اصلی

یکی از مهم‌ترین تصمیم‌های معماری، طراحی مدل دامنه (Domain Model) است؛ یعنی مشخص کردن مفاهیم اصلی محصول و روابط میان آن‌ها.

موجودیت‌های پیشنهادی عبارت‌اند از:

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

این مدل باید روابط را نیز تعریف کند. برای نمونه، یک الزام می‌تواند به چند کنترل نگاشت شود و یک کنترل ممکن است از چند الزام پشتیبانی کند. همچنین، یک ریسک می‌تواند چند دارایی یا فرایند را تحت تأثیر قرار دهد و چند کنترل در کاهش آن نقش داشته باشند.

این روابط چندبه‌چند اهمیت زیادی دارند؛ زیرا در سازمان واقعی، رابطه میان الزام، کنترل و ریسک معمولاً یک‌به‌یک نیست.

گام سوم: طراحی ارتباط میان چارچوب‌ها و کنترل‌ها

یکی از ارزش‌های اصلی نرم‌افزار GRC، جلوگیری از تکرار غیر ضروری فعالیت‌ها برای چارچوب‌های مختلف است.

فرض کنید سازمان باید الزامات ISO/IEC 27001، کنترل‌های منتخب NIST و تعهدات امنیتی مشتریان را مدیریت کند. ممکن است هر یک از این منابع به شکلی متفاوت به کنترل دسترسی، ثبت رخداد یا مدیریت آسیب‌پذیری اشاره کنند.

سامانه باید اجازه دهد:

1. منابع و نسخه‌های چارچوب‌ها به‌صورت مجزا ثبت شوند.
2. الزامات هر منبع با شناسه، عنوان، متن، دامنه و اطلاعات نسخه نگهداری شوند.
3. کنترل‌های داخلی سازمان مستقل از متن هر چارچوب تعریف شوند.
4. ارتباط میان کنترل‌های داخلی و الزامات به‌صورت قابل‌ردیابی ثبت شود.
5. شواهد و نتایج ارزیابی، تا حد امکان، برای کنترل مشترک استفاده مجدد شوند.
6. تفاوت دامنه، معیار پذیرش و روش ارزیابی هر الزام حفظ شود.

نکته مهم: نگاشت دو الزام به یک کنترل به این معنا نیست که رعایت یکی خودبه‌خود رعایت دیگری را اثبات می‌کند. یک کنترل مشترک ممکن است فقط بخشی از نیاز هر دو الزام را پوشش دهد یا به شواهد و آزمون‌های تکمیلی نیاز داشته باشد.

بنابراین، سامانه باید امکان ثبت پوشش کامل، پوشش جزئی، عدم پوشش و نگاشت نیازمند بازبینی را فراهم کند.

گام چهارم: طراحی موتور ارزیابی ریسک

موتور ارزیابی ریسک یکی از بخش‌های حساس محصول است. در این بخش نباید فرض شود که یک فرمول واحد برای همه سازمان‌ها مناسب است.

یک سامانه قابل‌تنظیم باید حداقل امکانات زیر را در نظر بگیرد:

• تعریف معیارهای احتمال یا امکان وقوع
• تعریف معیارهای اثر و پیامد
• تعریف سطوح شدت و حدود پذیرش
• تعیین روش محاسبه یا ترکیب امتیازها
• ثبت ریسک ذاتی و باقیمانده
• تعیین عوامل تعدیل‌کننده یا کنترل‌های موجود
• ثبت مالک ریسک و برنامه پاسخ
• ثبت مبانی ارزیابی و سطح اطمینان به آن
• نسخه‌بندی روش‌شناسی و نگهداری تاریخچه نتایج

برای مثال، یک سازمان ممکن است از ماتریس ۵ در ۵ استفاده کند که در آن احتمال و اثر هر کدام از یک تا پنج امتیاز می‌گیرند. سازمانی دیگر ممکن است از تحلیل کیفی، سناریومحور یا مدل کمی استفاده کند.

اگر از حاصل‌ضرب احتمال و اثر برای تولید امتیاز استفاده شود، باید روشن باشد که این عدد یک ابزار رتبه‌بندی داخلی است و لزوماً احتمال واقعی وقوع یا مقدار پولی زیان را نشان نمی‌دهد.

همچنین، تغییر روش ارزیابی نباید باعث شود نتایج قدیمی بدون ثبت تغییرات بازنویسی شوند. برای مقایسه معتبر، باید نسخه روش، تاریخ ارزیابی و مبنای امتیازدهی مشخص باشد.

گام پنجم: طراحی گردش کار و مسئولیت‌ها

یک محصول GRC باید بتواند فرایندهای سازمان را اجرا کند، نه اینکه فقط وضعیت آن‌ها را نمایش دهد.

برای نمونه، گردش کار ارزیابی کنترل می‌تواند مراحل زیر را داشته باشد:

1. سامانه ارزیابی جدید را بر اساس تقویم یا رویداد مشخص ایجاد می‌کند.
2. مالک کنترل، پرسش‌ها و درخواست‌های شواهد را دریافت می‌کند.
3. مالک کنترل اطلاعات و شواهد را ثبت می‌کند.
4. ارزیاب مستقل یا مسئول تعیین‌شده، شواهد را بررسی می‌کند.
5. در صورت کافی نبودن شواهد، ارزیابی برای تکمیل بازگردانده می‌شود.
6. نتیجه نهایی ثبت می‌شود و در صورت نیاز، یافته یا اقدام اصلاحی ایجاد می‌شود.
7. وضعیت کنترل، ریسک مرتبط و گزارش‌های مدیریتی مطابق قواعد سامانه به‌روزرسانی می‌شوند.

در این گردش کار، وضعیت‌هایی مانند «پیش‌نویس»، «در انتظار شواهد»، «در حال ارزیابی»، «نیازمند اصلاح»، «تأییدشده» و «بسته‌شده» باید معنای دقیق داشته باشند.

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

گام ششم: مدیریت شواهد و قابلیت ممیزی

شواهد، یکی از حساس‌ترین بخش‌های محصول GRC هستند؛ زیرا نتیجه ارزیابی و بسیاری از تصمیم‌های مدیریتی به اعتبار آن‌ها وابسته است.

یک سامانه مناسب باید اطلاعاتی مانند موارد زیر را برای هر شاهد ثبت کند:

• شناسه یکتا
• نوع و شرح شاهد
• منبع تولیدکننده
• مالک یا مسئول ارائه
• تاریخ ایجاد یا استخراج
• تاریخ دریافت و ثبت
• دوره اعتبار یا زمان مورد پوشش
• ارتباط با کنترل، الزام، ریسک یا ممیزی
• نتیجه بررسی و نام ارزیاب
• محدودیت دسترسی و طبقه‌بندی اطلاعات
• نسخه و تاریخچه تغییرات

در صورت نیاز به یکپارچگی شواهد، می‌توان از هش رمزنگاری‌شده برای تشخیص تغییر فایل استفاده کرد. با این حال، هش به‌تنهایی اصالت منبع، صحت محتوای اولیه یا معتبر بودن ادعای ثبت‌شده را ثابت نمی‌کند.

همچنین باید میان ثبت یک فایل و ثبت نتیجه آزمون تمایز وجود داشته باشد. برای مثال، گزارش اسکن آسیب‌پذیری تنها زمانی پشتوانه مناسبی برای ارزیابی یک کنترل است که دامنه اسکن، زمان اجرا، پوشش دارایی‌ها و محدودیت‌های گزارش نیز مشخص باشند.

گام هفتم: طراحی داشبوردها و گزارش‌های مدیریتی

داشبورد GRC باید متناسب با تصمیمی که کاربر می‌خواهد بگیرد طراحی شود.

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

در مقابل، مدیر امنیت یا مسئول GRC ممکن است به جزئیات بیشتری درباره کنترل‌ها، شواهد، استثناها، الزامات و ارزیابی‌ها نیاز داشته باشد.

گزارش‌های متداول عبارت‌اند از:

• نقشه حرارتی (Heat Map) ریسک‌ها
• فهرست ریسک‌های باقیمانده بالا
• وضعیت انطباق بر اساس چارچوب
• وضعیت کنترل‌ها و ارزیابی‌های سررسیدشده
• اقدامات اصلاحی معوق
• استثناهای منقضی یا نزدیک به انقضا
• وضعیت شواهد ناقص یا منقضی
• روند تغییر ریسک در دوره‌های زمانی
• گزارش پذیرش ریسک و تصمیم‌های مدیریتی

برای جلوگیری از ایجاد برداشت اشتباه، هر داشبورد باید تاریخ آخرین به‌روزرسانی، دامنه داده‌ها، تعریف شاخص و در صورت نیاز، میزان پوشش اطلاعات را نشان دهد.

گام هشتم: طراحی معماری فنی محصول

معماری فنی باید با توجه به تعداد سازمان‌ها، حجم شواهد، نیازهای یکپارچگی، سطح محرمانگی و الزامات استقرار انتخاب شود.

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

• لایه رابط کاربری
• داشبورد، فرم‌ها، گزارش‌ها و گردش کار
• لایه خدمات و منطق کسب‌وکار
• مدیریت ریسک، کنترل، انطباق، ارزیابی و تأیید
• لایه گردش کار و سیاست‌های دسترسی
• مجوزها، تفکیک وظایف، اعلان‌ها و قواعد ارجاع
• لایه داده و شواهد
• پایگاه داده رابطه‌ای، مخزن مستندات و ثبت رویدادهای ممیزی
• لایه یکپارچگی
• API، اتصال‌دهنده‌ها، دریافت داده و پردازش خطاهای همگام‌سازی

در انتخاب فناوری، موارد زیر اهمیت دارند:

پایگاه داده: یک پایگاه داده رابطه‌ای برای مدل‌سازی روابط میان ریسک‌ها، کنترل‌ها، الزامات، ارزیابی‌ها و گردش کار می‌تواند انتخاب مناسبی باشد. فایل‌های شواهد حجیم نیز ممکن است در یک مخزن شیءگرا نگهداری شوند و فراداده آن‌ها در پایگاه داده قرار گیرد.

API و یکپارچگی: رابط‌های برنامه‌نویسی باید احراز هویت، مجوزدهی، اعتبارسنجی ورودی، محدودسازی نرخ در صورت نیاز، ثبت خطا و مدیریت نسخه داشته باشند.

مقیاس‌پذیری: سامانه باید بتواند با افزایش تعداد ارزیابی‌ها، شواهد، کاربران و یکپارچگی‌ها رشد کند. استفاده از معماری میکروسرویس از ابتدا الزام نیست؛ برای بسیاری از محصولات اولیه، معماری ماژولار یکپارچه می‌تواند ساده‌تر و قابل‌نگهداری‌تر باشد.

استقرار: استقرار ابری، محلی یا ترکیبی باید بر اساس نیازهای امنیتی، قانونی، عملیاتی و ترجیح مشتری انتخاب شود. محل نگهداری داده و شواهد باید با تعهدات سازمان و الزامات قابل‌اعمال سازگار باشد.

نسخه‌بندی: تغییر چارچوب‌ها، معیارهای ارزیابی، کنترل‌ها و گردش کار باید قابل‌ردیابی باشد تا نتایج تاریخی قابل تفسیر باقی بمانند.

گام نهم: امنیت خود نرم‌افزار GRC

نرم‌افزار GRC معمولاً اطلاعات بسیار حساسی را نگهداری می‌کند؛ از جمله ریسک‌های مهم، نقاط ضعف امنیتی، گزارش‌های ممیزی، اطلاعات دارایی‌ها، تصمیم‌های پذیرش ریسک و اسناد قراردادی.

به همین دلیل، خود محصول باید به‌عنوان یک سامانه حساس طراحی و محافظت شود.

مهم‌ترین الزامات عبارت‌اند از:

• کنترل دسترسی مبتنی بر نقش (RBAC): محدود کردن قابلیت‌ها بر اساس نقش کاربران.
• کنترل دسترسی مبتنی بر ویژگی یا زمینه (ABAC): اعمال محدودیت‌های دقیق‌تر بر اساس سازمان، واحد، مالکیت، طبقه‌بندی یا ویژگی‌های درخواست.
• تفکیک وظایف: جلوگیری از ترکیب نامناسب اختیارهایی مانند ثبت، تأیید مستقل و بستن نهایی یک فرایند حساس.
• احراز هویت قوی: پشتیبانی از احراز هویت چندعاملی و در صورت نیاز، یکپارچگی با ارائه‌دهنده هویت سازمان.
• امنیت داده: رمزنگاری ارتباطات و محافظت از داده‌های ذخیره‌شده، مدیریت امن کلیدها و محدودسازی دسترسی به شواهد.
• ثبت رویداد ممیزی: ثبت عملیات حساس شامل تغییرات، تأییدها، دسترسی‌ها و تصمیم‌های مهم.
• مدیریت نشست و حساب‌ها: کنترل نشست‌های کاربری، لغو دسترسی و مدیریت چرخه عمر هویت.
• پشتیبان‌گیری و بازیابی: طراحی، آزمایش و مستندسازی قابلیت بازیابی داده و سرویس.
• آزمون امنیتی: بررسی کد، وابستگی‌ها، پیکربندی و سطح حمله محصول پیش از انتشار و در طول چرخه عمر.
• مدیریت آسیب‌پذیری: تعریف فرایند کشف، اولویت‌بندی، اصلاح و اعلام آسیب‌پذیری‌های محصول.
• امنیت چندمستاجری: در محصولات SaaS، جداسازی قابل‌اعتماد داده، فایل‌ها، وظایف و خروجی‌های هر سازمان.
• حفاظت از یکپارچگی شواهد: محدود کردن تغییرات غیرمجاز و نگهداری تاریخچه معتبر عملیات.

در این محصول، کنترل دسترسی صرفاً به صفحه‌های رابط کاربری محدود نمی‌شود. مجوزها باید در سمت سرور و برای هر عملیات حساس بررسی شوند؛ در غیر این صورت، ممکن است کاربر با دسترسی مستقیم به API یا شناسه یک شیء، به اطلاعاتی خارج از دامنه مجاز خود دسترسی پیدا کند.

همچنین، ثبت رویداد ممیزی باید تا حد امکان در برابر تغییر یا حذف غیرمجاز محافظت شود. استفاده از یک جدول ثبت وقایع بدون کنترل دسترسی مناسب، سیاست نگهداری، پایش و پشتیبان‌گیری، به‌تنهایی تضمین‌کننده اعتبار سوابق نیست.

گام دهم: طراحی مدل استقرار و چندمستاجری

اگر محصول قرار است به چند مشتری ارائه شود، باید از ابتدا مشخص شود که داده‌های هر مشتری چگونه از دیگر مشتریان جدا می‌شوند.

سه الگوی رایج عبارت‌اند از:

1. پایگاه داده مشترک با جداسازی منطقی: داده‌های چند مشتری در یک پایگاه داده نگهداری می‌شوند و شناسه مستأجر (Tenant ID) و سیاست‌های کنترل دسترسی برای جداسازی استفاده می‌شوند.

2. پایگاه داده جداگانه برای هر مشتری: هر مشتری پایگاه داده مستقل دارد که جداسازی را تقویت می‌کند، اما مدیریت و نگهداری پیچیده‌تری دارد.

3. محیط مستقل برای هر مشتری: اجزای اصلی سامانه در محیط جداگانه مستقر می‌شوند؛ این روش می‌تواند برای مشتریان با نیازهای خاص امنیتی یا عملیاتی مناسب باشد، ولی هزینه و پیچیدگی بیشتری دارد.

هیچ‌کدام از این الگوها به‌صورت مطلق بهترین گزینه نیستند. انتخاب باید بر اساس مدل تهدید، سطح حساسیت داده، نیازهای مشتری، هزینه عملیاتی و توان تیم فنی انجام شود.

در معماری چندمستاجری، کنترل دسترسی باید در همه مسیرها اعمال شود؛ از API و جست‌وجو تا فایل‌های ضمیمه، خروجی گزارش، صف پردازش، کش و فرایندهای زمان‌بندی‌شده. جداسازی صرفاً در رابط کاربری کافی نیست.

گام یازدهم: یکپارچگی با سامانه‌های سازمان

ارزش نرم‌افزار GRC زمانی بیشتر می‌شود که بتواند اطلاعات مورد نیاز را از سامانه‌های موجود دریافت کند و از ثبت چندباره داده جلوگیری شود.

اتصال‌های متداول عبارت‌اند از:

• سامانه مدیریت هویت و دسترسی
• مدیریت دارایی‌های فناوری اطلاعات
• مدیریت آسیب‌پذیری
• سامانه‌های SIEM و EDR
• ابزارهای تیکتینگ و مدیریت پروژه
• سامانه‌های مدیریت تغییر
• مخازن اسناد و قراردادها
• سامانه‌های منابع انسانی و تدارکات، در محدوده مجاز

با این حال، یکپارچگی باید بر مبنای نیاز مشخص طراحی شود. دریافت همه رویدادهای SIEM در GRC معمولاً ضروری نیست؛ ممکن است تنها دریافت یافته‌های منتخب، خلاصه شاخص‌ها یا رخدادهایی که معیار مشخصی دارند، مفید باشد.

در هر اتصال باید منبع اصلی داده، تناوب همگام‌سازی، نحوه مدیریت خطا، قواعد تطبیق شناسه‌ها و مسئول بررسی مغایرت‌ها مشخص باشند.

گام دوازدهم: تعریف نسخه اولیه قابل عرضه (MVP)

تلاش برای پیاده‌سازی همه قابلیت‌های GRC در نسخه نخست معمولاً زمان توسعه را افزایش می‌دهد و اعتبارسنجی نیازهای واقعی مشتری را دشوار می‌کند.

یک MVP مناسب باید یک مسئله مشخص را به‌صورت کامل حل کند. برای مثال، نسخه نخست یک محصول GRC امنیت سایبری می‌تواند شامل موارد زیر باشد:

• مدیریت سازمان، کاربران و نقش‌ها
• ثبت الزامات و کنترل‌ها
• نگاشت الزامات به کنترل‌ها
• ثبت و ارزیابی ریسک‌ها
• تعیین مالک و برنامه پاسخ به ریسک
• جمع‌آوری شواهد
• ثبت یافته‌ها و اقدامات اصلاحی
• گردش کار تأیید
• داشبورد وضعیت و گزارش‌های پایه
• ثبت تاریخچه تغییرات حساس

پس از اعتبارسنجی این هسته، می‌توان امکانات پیشرفته‌تری مانند مدیریت ریسک تأمین‌کنندگان، اتوماسیون جمع‌آوری شواهد، کتابخانه‌های محتوایی تخصصی، تحلیل روند و یکپارچگی‌های گسترده‌تر را اضافه کرد.

معیار موفقیت MVP تعداد ماژول‌های ساخته‌شده نیست؛ بلکه توانایی محصول در اجرای یک فرایند واقعی، قابل‌ردیابی و قابل‌اعتماد در سازمان است.

گام سیزدهم: آزمون و اعتبارسنجی محصول

پیش از عرضه، محصول باید از نظر عملکردی، امنیتی و صحت منطق GRC بررسی شود.

آزمون‌های مهم عبارت‌اند از:

• آزمون قواعد محاسبه ریسک و حدود پذیرش
• آزمون گردش کار و جلوگیری از تأییدهای غیرمجاز
• آزمون مجوزها و جداسازی داده مشتریان
• آزمون ثبت رویدادهای ممیزی
• آزمون پشتیبان‌گیری و بازیابی
• آزمون بار و کارایی
• آزمون یکپارچگی و مدیریت خطا
• آزمون مهاجرت داده و نسخه‌بندی
• آزمون گزارش‌ها در برابر داده‌های مبنا
• آزمون تجربه کاربری با کاربران واقعی GRC و امنیت اطلاعات

همچنین باید مشخص شود که محصول در برابر چه مدل تهدیدی طراحی شده، چه داده‌هایی را پردازش می‌کند و کدام مسئولیت‌ها بر عهده مشتری و کدام مسئولیت‌ها بر عهده ارائه‌دهنده محصول هستند.

این موضوع برای محصولات SaaS اهمیت بیشتری دارد؛ زیرا سازمان مشتری باید بتواند سطح امنیت و مسئولیت‌پذیری ارائه‌دهنده را ارزیابی کند.

9. یک مثال عملی از ریسک سایبری تا اقدام قابل‌ردیابی در GRC

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

در یک ارزیابی امنیتی مشخص می‌شود که برخی حساب‌های دارای دسترسی بالا هنوز از احراز هویت چندعاملی استفاده نمی‌کنند.

این یافته در ابتدا یک مشاهده فنی است؛ اما برای تبدیل شدن به یک مسئله قابل‌مدیریت در GRC باید مراحل زیر طی شود.

مرحله اول: ثبت ریسک

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

مرحله دوم: تعیین مسئول و ارزیابی

مسئول ریسک با توجه به ساختار سازمان تعیین می‌شود. سپس احتمال یا امکان وقوع، پیامدها، کنترل‌های موجود و سطح ریسک باقیمانده طبق روش‌شناسی مصوب ارزیابی می‌شوند.

امتیاز نهایی نباید صرفاً بر اساس شدت یک یافته فنی تعیین شود؛ اهمیت سامانه، میزان دسترسی، نوع داده، مسیرهای حمله و کنترل‌های جبرانی نیز باید در نظر گرفته شوند.

مرحله سوم: اتصال به کنترل‌ها و الزامات

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

مرحله چهارم: تعیین اقدام اصلاحی

اقدام اصلاحی می‌تواند شامل فعال‌سازی احراز هویت چندعاملی، بررسی حساب‌های استثناشده، اصلاح فرایند ایجاد حساب و تعریف سازوکار بازبینی دسترسی باشد. برای هر اقدام، مسئول، مهلت، معیار تکمیل و شواهد موردنیاز تعیین می‌شود.

مرحله پنجم: تأیید و جمع‌آوری شواهد

پس از اجرا، گزارش پیکربندی، خروجی سامانه هویت یا نتایج آزمون کنترل بررسی می‌شوند. در صورت نیاز، ارزیابی مستقل یا آزمون نمونه‌ای انجام می‌شود تا مشخص شود کنترل فقط در سیاست تعریف نشده، بلکه در عمل نیز اجرا شده است.

مرحله ششم: ارزیابی مجدد و تصمیم مدیریتی

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

این مثال نشان می‌دهد ارزش GRC در ایجاد یک زنجیره قابل‌ردیابی میان یافته فنی، ریسک کسب‌وکار، کنترل، اقدام اصلاحی، شواهد و تصمیم نهایی است.

10. چالش‌های پیاده‌سازی GRC در سازمان‌ها

پیاده‌سازی GRC حتی با وجود ابزار مناسب، ممکن است با چالش‌های جدی روبه‌رو شود.

10.1. پیچیدگی بیش از حد فرایندها

اگر سازمان برای هر فعالیت فرم‌ها و تأییدهای غیرضروری ایجاد کند، GRC به مانع انجام کار تبدیل می‌شود.

راهکار مناسب، تعریف فرایندهای متناسب با سطح ریسک و حذف مراحل غیرضروری است؛ بدون آنکه کنترل‌های مهم یا الزامات الزام‌آور کنار گذاشته شوند.

10.2. نبود مسئول مشخص

ثبت ریسک بدون تعیین مسئول، معمولاً به اقدامی کم‌اثر تبدیل می‌شود. هر ریسک باید فرد یا نقش مسئول مشخصی داشته باشد که اختیار پیگیری و پاسخ‌گویی در برابر آن را داشته باشد.

10.3. داده‌های ناقص و ارزیابی‌های قدیمی

اگر موجودی دارایی‌ها ناقص باشد یا شواهد به‌روز نباشند، ارزیابی ریسک و گزارش انطباق قابل‌اعتماد نخواهد بود.

برای رفع این مشکل باید منابع داده، مسئول به‌روزرسانی، دوره اعتبار و شرایط فعال شدن ارزیابی مجدد تعریف شوند.

10.4. تمرکز بر ممیزی به‌جای کاهش ریسک

گاهی سازمان فقط در آستانه ممیزی، شواهد را جمع‌آوری و مستندات را به‌روزرسانی می‌کند. این رویکرد ممکن است وضعیت ظاهری انطباق را بهبود دهد، اما لزوماً مدیریت ریسک روزمره را تقویت نمی‌کند.

راهکار مناسب، پیوند دادن ارزیابی‌ها به چرخه عملیاتی کنترل‌ها، تغییرات فناوری، رخدادهای امنیتی و تصمیم‌های مدیریتی است.

10.5. مقاومت سازمانی

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

10.6. وابستگی بیش از حد به اتوماسیون

اتوماسیون می‌تواند جمع‌آوری داده و اجرای گردش کار را سریع‌تر کند، اما جایگزین قضاوت حرفه‌ای در ارزیابی ریسک، تفسیر الزامات یا پذیرش مسئولانه ریسک نیست.

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

11. چگونه اثربخشی برنامه GRC را ارزیابی کنیم؟

اثربخشی GRC را نباید فقط با تعداد کنترل‌ها، تعداد مستندات یا درصد تکمیل فرم‌ها اندازه‌گیری کرد.

یک ارزیابی معنادار باید نشان دهد که آیا سازمان توانسته است ریسک‌ها را بهتر بشناسد، تصمیم‌ها را به‌موقع اتخاذ کند، کنترل‌ها را مؤثرتر اجرا کند و الزامات قابل‌اعمال را با شواهد معتبر پوشش دهد یا خیر.

برای این منظور می‌توان چند دسته شاخص تعریف کرد:

شاخص‌های حاکمیت

• درصد ریسک‌های مهم دارای مسئول و مرجع تصمیم‌گیری
• زمان رسیدگی به تصمیم‌های ارجاع‌شده به مدیریت
• درصد پذیرش‌های ریسک دارای تأیید معتبر و تاریخ بازبینی

شاخص‌های مدیریت ریسک

• تعداد و روند ریسک‌های بالاتر از حد پذیرش
• درصد برنامه‌های پاسخ دارای پیشرفت قابل‌تأیید
• زمان رفع ریسک‌های اولویت‌دار
• میزان تغییر ریسک باقیمانده پس از اجرای اقدامات

شاخص‌های انطباق

• درصد الزامات قابل‌اعمال دارای کنترل و مسئول مشخص
• درصد ارزیابی‌های کنترل دارای شواهد معتبر
• تعداد شکاف‌های مهم باز و مدت زمان رفع آن‌ها
• میزان پوشش الزامات قراردادی و مقرراتی در دامنه تعریف‌شده

شاخص‌های کیفیت داده و اتوماسیون

• درصد داده‌های دارای منبع و تاریخ به‌روزرسانی مشخص
• نرخ شکست اتصال‌ها و همگام‌سازی‌ها
• تعداد ارزیابی‌های معوق
• میزان کاهش کار تکراری در تهیه شواهد

این شاخص‌ها باید با اهداف اولیه سازمان مقایسه شوند. برای مثال، اگر هدف کاهش زمان آماده‌سازی ممیزی است، باید زمان پایه پیش از پیاده‌سازی ثبت شود و پس از استقرار، تغییر آن با توجه به حجم و پیچیدگی ممیزی بررسی شود.

همچنین، بهبود یک شاخص منفرد نباید به‌عنوان اثبات قطعی بهبود امنیت تعبیر شود. ارزیابی اثربخشی GRC به ترکیبی از شواهد، روندها، بازبینی‌های مستقل و قضاوت حرفه‌ای نیاز دارد.

 12. جمع‌بندی: GRC چه ارزشی برای سازمان ایجاد می‌کند؟

GRC را باید رویکردی برای ایجاد هماهنگی میان تصمیم‌های مدیریتی، مدیریت ریسک و رعایت الزامات دانست؛ رویکردی که در امنیت سایبری، فاصله میان یافته‌های فنی و تصمیم‌های کسب‌وکار را کاهش می‌دهد.

ارزش GRC زمانی آشکار می‌شود که سازمان بتواند به پرسش‌های مهمی پاسخ دهد:

1. مهم‌ترین ریسک‌های سایبری مؤثر بر اهداف کسب‌وکار کدام‌اند؟
2. چه کسی مسئول هر ریسک است و چه کسی اختیار پذیرش آن را دارد؟
3. کدام کنترل‌ها برای مدیریت ریسک و برآورده کردن الزامات به کار گرفته شده‌اند؟
4. شواهد اجرای کنترل‌ها از کجا می‌آیند و چه میزان اعتبار دارند؟
5. چه شکاف‌هایی نیازمند اقدام فوری یا تصمیم مدیریتی هستند؟
6. آیا اقدامات انجام‌شده واقعاً سطح ریسک را کاهش داده‌اند؟

نرم‌افزار GRC می‌تواند پاسخ‌گویی به این پرسش‌ها را سریع‌تر، منسجم‌تر و قابل‌ردیابی‌تر کند؛ اما تنها زمانی که بر پایه روش‌شناسی روشن، داده معتبر، مسئولیت‌های مشخص و فرایندهای قابل‌اجرا طراحی شده باشد.

در نهایت، GRC موفق به معنای داشتن بیشترین تعداد کنترل، کامل‌ترین داشبورد یا بیشترین حجم مستندات نیست؛ بلکه به معنای توانایی سازمان در تصمیم‌گیری آگاهانه، مدیریت ریسک در سطح موردنظر و ارائه شواهد معتبر از عملکرد خود است.