هر مفهوم GRC را در کمتر از ۱۰۰ کلمه یاد بگیرید

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

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

مدیریت انطباق یعنی سازمان بداند چه الزاماتی باید رعایت کند و بتواند رعایت آن‌ها را اثبات کند. الزام ممکن است از استاندارد، قانون، قرارداد یا سیاست داخلی بیاید. صرف داشتن یک چک‌لیست کافی نیست؛ باید بدانیم کدام کنترل پاسخ‌گوی الزام است، Evidence اجرای کنترل چیست و اگر شکافی وجود دارد چه کسی آن را اصلاح می‌کند. در MedaGRC، Compliance زمانی معنا دارد که Requirement، Control، Evidence و Action Plan به هم متصل باشند.

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

ISMS سیستم مدیریت امنیت اطلاعات است و تمرکزش روی حفاظت از اطلاعات و مدیریت ریسک‌های امنیتی است. GRC دامنه وسیع‌تری دارد و حاکمیت، ریسک و انطباق را در سطح سازمان به هم متصل می‌کند. یک ISMS می‌تواند یکی از دامنه‌های اجرایی GRC باشد. برای مثال ISO 27001، کنترل‌های امنیتی و Risk Register می‌توانند در MedaGRC مدیریت شوند، اما همان پلتفرم می‌تواند ریسک تأمین‌کننده، ممیزی داخلی و کنترل‌های سازمانی دیگر را نیز پوشش دهد.

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

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

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

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

ریسک ذاتی یا Inherent Risk سطح ریسک پیش از درنظرگرفتن اثر کنترل‌های موجود است. این مفهوم نشان می‌دهد اگر کنترل‌ها نبودند، سناریو ذاتاً چقدر جدی بود. برای مثال دسترسی ممتاز به سامانه مالی بدون درنظرگرفتن MFA، PAM یا بازبینی دسترسی می‌تواند ریسک ذاتی بالایی داشته باشد. مقایسه ریسک ذاتی و باقیمانده کمک می‌کند بفهمیم کنترل‌ها واقعاً چه مقدار از ریسک را کاهش داده‌اند.

ریسک باقیمانده یا Residual Risk سطح ریسکی است که بعد از درنظرگرفتن کنترل‌های واقعی باقی می‌ماند. اگر MFA، لاگ‌برداری و بازبینی دسترسی اجرا شده باشند، ریسک دسترسی غیرمجاز کاهش پیدا می‌کند اما معمولاً صفر نمی‌شود. مدیریت باید ریسک باقیمانده را با Risk Appetite مقایسه کند و تصمیم بگیرد آیا قابل پذیرش است یا کنترل و اقدام بیشتری لازم دارد.

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

Risk Tolerance یا تحمل ریسک محدوده انحراف قابل قبول از هدف است. Appetite جهت کلی را مشخص می‌کند، اما Tolerance معمولاً عملیاتی‌تر است. مثلاً سازمان ممکن است اشتهای پایینی برای اختلال سرویس حیاتی داشته باشد و تحمل کند حداکثر ۳۰ دقیقه قطعی رخ دهد. وقتی Tolerance روشن باشد، KRI و Escalation نیز قابل تعریف‌تر می‌شوند.

Risk Treatment یعنی تصمیم و برنامه سازمان برای برخورد با ریسک. گزینه‌های رایج شامل کاهش، اجتناب، انتقال و پذیرش هستند. Treatment فقط انتخاب یک گزینه نیست؛ باید کنترل‌ها، Action Plan، Owner، Deadline و معیار بازبینی را هم مشخص کند. اگر تصمیم بگیریم ریسک را کاهش دهیم اما اقدام و مسئول مشخص نباشد، Treatment عملاً اتفاق نیفتاده است.

Risk Owner فرد یا نقشی است که اختیار و مسئولیت تصمیم درباره یک ریسک را دارد. مالک ریسک لزوماً کسی نیست که همه کنترل‌ها را اجرا می‌کند؛ ممکن است کنترل توسط تیم دیگری اجرا شود. Owner باید بتواند Treatment را تأیید کند، ریسک باقیمانده را بپذیرد یا موضوع را Escalate کند. نوشتن نام یک واحد کلی مثل «IT» معمولاً پاسخ‌گویی کافی ایجاد نمی‌کند.

KRI یا Key Risk Indicator شاخصی است که تغییر سطح یا احتمال یک ریسک را زودتر قابل مشاهده می‌کند. برای مثال افزایش تعداد حساب‌های ممتاز بدون MFA می‌تواند KRI مرتبط با ریسک دسترسی غیرمجاز باشد. KRI باید به یک ریسک و یک آستانه تصمیم متصل باشد. شاخصی که فقط اندازه‌گیری شود اما معلوم نباشد عبور از آستانه چه اقدامی ایجاد می‌کند، ارزش مدیریتی محدودی دارد.

کنترل اقدامی است که برای کاهش ریسک، پاسخ به الزام یا جلوگیری از خطا اجرا می‌شود. کنترل می‌تواند فنی، فرایندی یا مدیریتی باشد؛ مثل MFA، بازبینی دسترسی، تفکیک وظایف یا تصویب تغییر. کنترل خوب باید Owner، دامنه، روش اجرا، تناوب و Evidence مشخص داشته باشد. وجود نام کنترل در یک Policy به معنی اجرای واقعی آن نیست.

Control Assessment بررسی می‌کند آیا کنترل درست طراحی شده و در عمل هم درست اجرا می‌شود. ممکن است یک کنترل از نظر طراحی مناسب باشد، اما فقط روی بخشی از دارایی‌ها اجرا شود یا Evidence آن قدیمی باشد. ارزیابی باید دامنه، نمونه‌ها، استثناها و نتیجه را بررسی کند. هدف فقط Pass یا Fail نیست؛ باید بفهمیم کنترل تا چه حد ریسک هدف را واقعاً کاهش می‌دهد.

Control Effectiveness نشان می‌دهد یک کنترل با چه پوشش، کیفیت و نتیجه‌ای کار می‌کند. برای اندازه‌گیری آن می‌توان درصد پوشش، اجرای به‌موقع، تعداد استثناها، کیفیت Evidence و تغییر ریسک مرتبط را بررسی کرد. کنترل فعال لزوماً کنترل مؤثر نیست. برای مثال Patch Management ممکن است نصب باشد، اما اگر ۲۰ درصد سرورهای حیاتی خارج از دامنه باشند، اثربخشی کامل نیست.

Compensating Control کنترلی است که وقتی کنترل اصلی قابل اجرا نیست، برای کاهش همان ریسک یا رسیدن به هدف مشابه استفاده می‌شود. مثلاً اگر یک سامانه قدیمی MFA را پشتیبانی نکند، محدودکردن شبکه، ثبت Session و کنترل دسترسی سخت‌گیرانه می‌تواند بخشی از ریسک را جبران کند. کنترل جبرانی باید مستند، قابل ارزیابی و متناسب با ریسک باشد؛ نه صرفاً راهی برای تیک‌زدن الزام.

Gap Analysis یا تحلیل شکاف مقایسه وضعیت فعلی با وضعیت مورد انتظار است. در GRC، انتظار می‌تواند از استاندارد، Policy یا کنترل مرجع بیاید. Gap خوب باید مشخص کند چه چیزی کم است، اثر آن چیست، Owner چه کسی است و اقدام اصلاحی چیست. تحلیل شکاف اگر فقط به درصد انطباق ختم شود، ارزش محدودی دارد؛ باید به Action Plan قابل پیگیری تبدیل شود.

Continuous Compliance یعنی وضعیت انطباق فقط سالی یک‌بار و نزدیک ممیزی بررسی نشود. کنترل‌ها، Evidence، استثناها و اقدامات باید در طول زمان پایش شوند. این مفهوم الزاماً به معنی کنترل کاملاً خودکار نیست؛ بخش مهم آن داشتن Trigger، Reminder و Workflow برای بازبینی‌های دوره‌ای است. هدف این است که شکاف‌ها زودتر دیده شوند و ممیزی به پروژه اضطراری آخر سال تبدیل نشود.

Audit Evidence مدرکی است که اجرای یک کنترل یا وضعیت یک الزام را اثبات می‌کند. Evidence خوب باید مرتبط، تازه، قابل انتساب و قابل راستی‌آزمایی باشد. یک اسکرین‌شات قدیمی که معلوم نیست مربوط به چه دوره‌ای است، Evidence ضعیفی است. بهتر است شواهد کنار همان Control و Assessment نگهداری شوند تا در ممیزی نیاز به جست‌وجوی پوشه‌های مختلف نباشد.

Audit Finding نتیجه‌ای است که از ارزیابی یا ممیزی به دست می‌آید و نشان می‌دهد وضعیت واقعی با معیار مورد انتظار فاصله دارد یا نیاز به توجه دارد. Finding خوب باید معیار، وضعیت مشاهده‌شده و Evidence را روشن کند. جمله‌هایی مثل «کنترل ضعیف است» کافی نیستند. یافته باید آن‌قدر دقیق باشد که Owner بداند چه چیزی باید اصلاح شود و ارزیاب بتواند بعداً اثربخشی اقدام را بررسی کند.

Nonconformity زمانی است که یک الزام مشخص رعایت نشده باشد. برای مدیریت آن باید ابتدا وضعیت و Evidence ثبت شود، سپس Correction برای رفع فوری و Corrective Action برای حذف علت تکرار تعریف شود. عدم انطباق با گفتن «حل شد» بسته نمی‌شود؛ باید معیار Closure و تأیید اثربخشی وجود داشته باشد.

Corrective Action اقدامی برای حذف علت یک مشکل یا عدم انطباق است تا دوباره تکرار نشود. اگر Patch چند سرور عقب افتاده، نصب فوری Patch یک Correction است؛ اما اصلاح فرایند برنامه‌ریزی Patch یا مالکیت آن می‌تواند Corrective Action باشد. اقدام اصلاحی باید Owner، Deadline و معیار اثربخشی داشته باشد.

Internal Audit یک نگاه مستقل به طراحی و اجرای کنترل‌ها و فرایندها می‌دهد. در GRC، ممیزی نباید جدا از Risk Register و کنترل‌ها باشد. یافته ممیزی باید به Control، Evidence و Action Plan متصل شود تا سازمان بتواند تا Closure آن را دنبال کند. این اتصال کمک می‌کند ممیزی از یک گزارش PDF جدا به بخشی از چرخه بهبود تبدیل شود.

ISO/IEC 27001 استاندارد سیستم مدیریت امنیت اطلاعات است. این استاندارد از سازمان می‌خواهد دامنه ISMS، ریسک‌های امنیت اطلاعات، کنترل‌ها، مسئولیت‌ها، ممیزی و بهبود مستمر را ساختاریافته مدیریت کند. ISO 27001 به‌تنهایی نرم‌افزار نیست؛ یک چارچوب مدیریتی است. ابزار GRC می‌تواند اجرای الزامات، Risk Register، SoA، Evidence و اقدامات اصلاحی را در یک مدل قابل ردیابی نگه دارد.

Annex A در ISO/IEC 27001:2022 مجموعه‌ای از ۹۳ کنترل مرجع را ارائه می‌کند که در چهار گروه سازمانی، انسانی، فیزیکی و فناوری دسته‌بندی شده‌اند. سازمان نباید همه کنترل‌ها را کورکورانه تیک بزند؛ باید بر اساس ریسک و دامنه درباره کاربردپذیری آن‌ها تصمیم بگیرد و نتیجه را در Statement of Applicability منعکس کند.

ISO/IEC 27005:2022 راهنمای مدیریت ریسک امنیت اطلاعات است و از پیاده‌سازی ISMS مبتنی بر ISO 27001 پشتیبانی می‌کند. این استاندارد برای Context، شناسایی، تحلیل، ارزیابی، Treatment و Monitoring ریسک راهنما می‌دهد؛ اما سازمان باید Risk Methodology را متناسب با دامنه و نیاز خود طراحی کند.

NIST Cybersecurity Framework یا NIST CSF چارچوبی برای مدیریت ریسک امنیت سایبری است. نسخه 2.0 ساختار خود را حول شش Function اصلی Governance، Identify، Protect، Detect، Respond و Recover سازمان‌دهی می‌کند. این چارچوب کمک می‌کند وضعیت امنیت سایبری به زبان قابل فهم‌تری برای مدیریت و تیم فنی بیان شود و می‌تواند در GRC به کنترل‌ها، ریسک‌ها و Evidenceهای واقعی سازمان متصل شود.

CIS Controls مجموعه‌ای از کنترل‌های اولویت‌دار امنیت سایبری است که روی اقدامات عملی و قابل اجرا تمرکز دارد. این کنترل‌ها برای سازمان‌هایی که می‌خواهند برنامه امنیتی را از فعالیت‌های مشخص شروع کنند مفیدند. در GRC می‌توان Safeguardهای CIS را به Applied Controlهای سازمان وصل کرد و Evidence اجرای آن‌ها را کنار همان کنترل نگه داشت.

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

TPRM یا Third Party Risk Management مدیریت ریسک اشخاص ثالث است؛ یعنی شناخت و کنترل ریسک‌هایی که از Vendor، پیمانکار، سرویس ابری یا شریک تجاری ایجاد می‌شوند. ارزیابی خوب فقط پرسشنامه نیست. باید اهمیت تأمین‌کننده، نوع دسترسی، داده، وابستگی عملیاتی، Evidence، شروط قراردادی و ریسک باقیمانده بررسی شوند.

BCM یا Business Continuity Management مدیریت تداوم کسب‌وکار است؛ یعنی سازمان برای ادامه فعالیت‌های حیاتی در زمان اختلال برنامه و توان عملیاتی داشته باشد. BCM فقط Disaster Recovery فناوری اطلاعات نیست. افراد، مکان، تأمین‌کننده، فرایند و فناوری همگی می‌توانند در تداوم اثر داشته باشند. نتیجه BCM باید با Risk Register و مدیریت بحران مرتبط باشد.

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

DRP یا Disaster Recovery Plan برنامه بازیابی فناوری و زیرساخت پس از بحران است. DRP باید مشخص کند چه سامانه‌هایی با چه اولویتی، در چه زمانی و با چه وابستگی‌هایی بازیابی می‌شوند. داشتن Backup به معنی داشتن DRP نیست؛ بازیابی باید تست شود و نتیجه Evidence داشته باشد. DRP بخشی از برنامه تداوم است و باید با BIA و ریسک‌های فناوری هماهنگ باشد.

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

Control Mapping ارتباط بین کنترل‌های مختلف یا بین کنترل و Requirement را نشان می‌دهد. برای مثال یک Applied Control واقعی سازمان ممکن است هم‌زمان چند بند ISO 27001 و چند Safeguard در CIS Controls را پوشش دهد. Mapping باعث می‌شود کنترل یک‌بار مدیریت شود اما پوشش آن در چند چارچوب قابل مشاهده باشد.

Policy Management یعنی خط‌مشی فقط یک فایل نباشد؛ Owner، وضعیت، مرجع تصویب، تاریخ اثرگذاری، Review Date و ارتباط آن با Control و Requirement قابل پیگیری باشد. چرخه عمر Policy از تدوین و بازبینی شروع می‌شود و به تصویب، انتشار، بازنگری و در نهایت بازنشستگی می‌رسد. ارزش GRC این است که سند را به اجرای واقعی و Evidence متصل می‌کند.

بلوغ GRC نشان می‌دهد فرایندهای حاکمیت، ریسک، کنترل و انطباق تا چه حد تکرارپذیر، تعریف‌شده، اندازه‌پذیر و قابل بهبود هستند. داشتن Risk Register به‌تنهایی نشانه بلوغ نیست؛ Ownership، Workflow، Evidence، KRI و Action Plan مهم‌اند. ارزیابی بلوغ باید چند بُعد جدا را بسنجد و خروجی آن به نقشه بهبود واقعی تبدیل شود.

ISO 22301 استاندارد سیستم مدیریت تداوم کسب‌وکار است. این استاندارد کمک می‌کند سازمان اثر توقف خدمات حیاتی را بشناسد، استراتژی تداوم و بازیابی طراحی کند، Plan داشته باشد و آن را تمرین و بازبینی کند. در GRC، BIA، Risk، Control، Evidence، Finding و اقدام اصلاحی می‌توانند در یک چرخه مرتبط مدیریت شوند.

ISO 27701 چارچوبی برای مدیریت اطلاعات حریم خصوصی و PIMS است و در کنار ISO 27001 استفاده می‌شود. تمرکز آن فقط روی Security نیست؛ هدف پردازش، نگهداری داده شخصی، اشخاص ثالث، مسئولیت و کنترل‌های Privacy را هم بررسی می‌کند. در GRC می‌توان Requirementهای Privacy را به Risk، Control و Evidence مشترک متصل کرد.

Audit Program برنامه دوره‌ای یا سالانه ممیزی‌هاست و مشخص می‌کند کدام حوزه‌ها، با چه اولویتی و بر اساس چه ریسکی ممیزی شوند. این مفهوم با Plan یک ممیزی مشخص فرق دارد. Program خوب به Risk Register، Findingهای قبلی، تغییرات و الزامات متصل است و با تغییر Risk می‌تواند اولویت‌هایش را هم تغییر دهد.

Compliance Obligation تعهدی است که سازمان از قانون، قرارداد، استاندارد یا Policy می‌پذیرد. فهرست الزامات انطباق باید Source، Requirement، Owner، Control، Evidence و Review Date داشته باشد. وقتی این اجزا به هم متصل باشند، سازمان می‌تواند قبل از ممیزی بفهمد کدام الزام Owner یا Evidence کافی ندارد.

Exception Management یعنی استثنا از Policy یا Control با دلیل، Scope، Risk، Approver، کنترل جبرانی و Expiry Date ثبت و بازبینی شود. استثنا نباید یک ایمیل بدون تاریخ پایان باشد. هر Exception معمولاً بخشی از Risk را می‌پذیرد و باید با Risk Appetite، Compensating Control و Action Plan مرتبط بماند.

MTPD یا Maximum Tolerable Period of Disruption بیشترین مدت توقفی است که بعد از آن اثر اختلال برای سازمان غیرقابل قبول می‌شود. این مفهوم در BIA کمک می‌کند اولویت بازیابی و اهدافی مثل RTO واقع‌بینانه تعیین شوند. MTPD باید از اثر کسب‌وکار به دست بیاید، نه صرفاً از توان فعلی زیرساخت.

ISO 31000 راهنمای بین‌المللی مدیریت ریسک است و به سازمان کمک می‌کند Context، Risk Assessment، Treatment، Monitoring و Communication را در یک رویکرد منسجم طراحی کند. ارزش آن در ساختن یک Risk Register زنده و معیار مشترک تصمیم‌گیری است؛ نه تولید فرم بیشتر. نسخه جاری آن ISO 31000:2018 است.

NIST Cybersecurity Framework 2.0 چارچوبی برای مدیریت ریسک سایبری است و شش Function دارد: Govern، Identify، Protect، Detect، Respond و Recover. اضافه‌شدن Govern در نسخه 2.0 نقش حاکمیت، مسئولیت و Risk Strategy را پررنگ‌تر کرده است. در GRC، Outcomeهای CSF می‌توانند به Control، Evidence و Assessment واقعی سازمان متصل شوند.

CIS Controls v8.1 مجموعه‌ای اولویت‌دار از ۱۸ Control امنیت سایبری است که با Safeguardهای عملی تکمیل می‌شود. این چارچوب برای سازمان‌هایی مناسب است که می‌خواهند اقدامات امنیتی را اولویت‌بندی و قابل اندازه‌گیری کنند. در GRC می‌توان Safeguardها را به Applied Control، Evidence و Gap متصل کرد.

SOC 2 چارچوب گزارش‌دهی و ارزیابی کنترل‌های یک Service Organization بر اساس Trust Services Criteria است. حوزه‌های اصلی شامل Security، Availability، Processing Integrity، Confidentiality و Privacy هستند. برای آمادگی SOC 2، Scope، Control، Evidence و اجرای دوره‌ای اهمیت زیادی دارند؛ به‌ویژه در Type II.

PCI DSS v4.0.1 نسخه فعال استاندارد امنیت داده کارت است. سازمان‌هایی که داده کارت را ذخیره، پردازش یا منتقل می‌کنند باید Scope، Control، Evidence و Third Partyهای مرتبط را دقیق مدیریت کنند. در GRC، Requirementهای PCI می‌توانند به کنترل‌های واقعی و Evidence دوره‌ای متصل شوند.

GDPR مقررات حفاظت از داده شخصی اتحادیه اروپاست و بر Governance پردازش داده، حقوق افراد، امنیت، Retention و مسئولیت سازمان تأکید دارد. در GRC می‌توان Processing Activity، Risk، Third Party، Control و Evidence را به هم متصل کرد تا Privacy از مجموعه‌ای از Policyهای جدا به یک چرخه مدیریتی تبدیل شود.

TPRM یا Third Party Risk Management چرخه مدیریت ریسک اشخاص ثالث از Intake و Risk Tiering تا Due Diligence، Contract، Monitoring، Reassessment و Offboarding است. پرسشنامه فقط یکی از مراحل این چرخه است. Vendor باید در تمام عمر رابطه Owner و Risk Context مشخص داشته باشد.

Vendor Assessment ارزیابی تأمین‌کننده بر اساس Risk Tier، نوع دسترسی، داده، وابستگی کسب‌وکار و Evidence است. Vendor بحرانی باید بررسی عمیق‌تری نسبت به تأمین‌کننده کم‌ریسک داشته باشد. سؤال Yes/No به‌تنهایی کافی نیست؛ پاسخ مهم باید با Evidence، Finding و در صورت نیاز Action Plan همراه شود.

ISO/IEC 27002:2022 راهنمای کنترل‌های امنیت اطلاعات است و ۹۳ کنترل را در چهار Theme سازمانی، انسانی، فیزیکی و فناوری سازمان‌دهی می‌کند. ارزش آن در تبدیل Control مرجع به Applied Control واقعی با Owner، Scope، Evidence و Assessment است؛ نه صرفاً تیک‌زدن یک چک‌لیست.

ISO/IEC 20000-1:2018 استاندارد الزامات سیستم مدیریت خدمات فناوری اطلاعات است. این استاندارد روی طراحی، انتقال، ارائه و بهبود خدمات تمرکز دارد. در GRC می‌توان داده‌های Service Management مثل SLA، Change و Incident را به Risk، Control و تصمیم حاکمیتی متصل کرد.

مدیریت ریسک سایبری یعنی داده‌های فنی مثل Vulnerability، Incident و Threat به سناریوی Risk قابل تصمیم تبدیل شوند. Asset Criticality، Control، KRI، Residual Risk و Treatment باید کنار هم دیده شوند تا مدیریت بداند کدام Exposure از حد قابل قبول عبور کرده و کدام اقدام بیشترین کاهش ریسک را ایجاد می‌کند.

Control Testing بررسی می‌کند یک کنترل هم از نظر طراحی مناسب است و هم در عمل طبق طراحی اجرا می‌شود. Test Procedure باید Population، Sample، Evidence و Criteria را روشن کند. نتیجه Test می‌تواند Exception، Finding و Remediation ایجاد کند و در نهایت روی Control Effectiveness و Residual Risk اثر بگذارد.

Design Effectiveness می‌پرسد اگر Control دقیقاً طبق طراحی اجرا شود، آیا برای رسیدن به Control Objective و کاهش Risk مناسب است؟ ممکن است Control منظم اجرا شود اما Frequency، Scope یا روش آن از اساس برای Risk کافی نباشد. این ضعف، مشکل طراحی است نه اجرای روزمره.

Operating Effectiveness بررسی می‌کند Control در دوره مورد ارزیابی واقعاً و به‌صورت پایدار اجرا شده یا نه. کنترل می‌تواند طراحی مناسبی داشته باشد اما به‌دلیل اجرا نشدن Reviewها، Evidence ناقص یا Exceptionهای متعدد، از نظر عملیاتی Ineffective باشد.

CAPA مخفف Corrective and Preventive Action است. Correction مشکل فعلی را رفع می‌کند، Corrective Action علت تکرار را هدف می‌گیرد و رویکرد پیشگیرانه روی علت‌های بالقوه کار می‌کند. CAPA خوب Root Cause، Owner، Due Date، Evidence و Effectiveness Review دارد و فقط با تغییر Status بسته نمی‌شود.

Continuous Compliance یعنی وضعیت Requirement، Control، Evidence، Exception و Action در طول سال قابل مشاهده باشد و Compliance فقط نزدیک ممیزی فعال نشود. این مفهوم الزاماً کاملاً خودکار نیست؛ Reminder، Testing، Evidence Freshness و Workflow انسانی هم بخشی از انطباق مستمر هستند.

Evidence Freshness یعنی مدرکی که برای اثبات اجرای Control استفاده می‌شود هنوز وضعیت فعلی را نشان دهد. یک Evidence قدیمی ممکن است ثابت کند Control زمانی اجرا شده، اما برای Control دوره‌ای کافی نباشد. Frequency، Validity و Review Date باید مشخص کنند چه زمانی Evidence نیاز به تجدید دارد.

Asset Inventory فهرست زنده دارایی‌های مهم سازمان است؛ اما فقط نام و IP کافی نیست. Owner، Criticality، Classification، Dependency، Lifecycle و Riskهای مرتبط باید مشخص باشند. در GRC، Asset Register باید به Risk و Control متصل باشد تا معلوم شود هر دارایی چرا مهم است و چگونه محافظت می‌شود.

Information Classification یعنی اطلاعات بر اساس حساسیت و اثر احتمالی افشا، تغییر یا از دسترس خارج‌شدن دسته‌بندی شوند. برچسب‌هایی مثل عمومی، داخلی و محرمانه زمانی مفیدند که Handling Rule مشخصی برای Access، Sharing، Encryption، Retention و Disposal ایجاد کنند.

Threat عامل یا رویدادی است که می‌تواند آسیب ایجاد کند؛ Vulnerability ضعفی است که Threat می‌تواند از آن استفاده کند؛ Risk سناریوی اثر این رویداد بر یک هدف یا Asset است. نوشتن CVE یا Phishing به‌تنهایی به‌عنوان Risk معمولاً کافی نیست؛ باید Consequence و Context کسب‌وکار هم روشن باشد.

Statement of Applicability یا SoA نشان می‌دهد کدام کنترل‌های مرجع ISO 27001 برای سازمان Applicable هستند، چرا، چه وضعیتی دارند و چگونه اجرا می‌شوند. Applicable بودن با Implemented بودن فرق دارد. SoA خوب باید با Risk، Applied Control و Evidence واقعی هماهنگ باشد، نه اینکه فقط یک جدول Yes/No برای ممیزی باشد.

Risk Acceptance تصمیم آگاهانه برای پذیرش Residual Risk در شرایط مشخص است. پذیرش باید دلیل، Owner، Approver، سطح Risk و Review Date داشته باشد و با Risk Appetite و سطح اختیار تصمیم‌گیر سازگار باشد. Acceptance بدون تاریخ بازبینی یا بدون شناخت Risk، تصمیم حاکمیتی قابل دفاعی نیست.

Cybersecurity Supply Chain Risk Management یا C-SCRM مدیریت ریسک سایبری در محصولات، خدمات و زنجیره تأمین است. نگاه آن از Vendor Assessment گسترده‌تر است و شامل Subsupplier، Secure Development، اصالت محصول، Vulnerability و تاب‌آوری زنجیره می‌شود. Due Diligence و Monitoring باید متناسب با Criticality باشند.

BCM روی تداوم فرایندها و خدمات حیاتی کسب‌وکار تمرکز دارد؛ Disaster Recovery بیشتر بر بازیابی فناوری، زیرساخت و داده متمرکز است. DR بخشی از تداوم است، نه کل آن. مدیریت بحران نیز لایه تصمیم، فرماندهی و ارتباط در رخداد بزرگ را پوشش می‌دهد.

RTO هدف زمانی برای بازگرداندن سرویس پس از اختلال است؛ RPO میزان قابل تحمل از دست‌رفتن داده را از منظر زمان نشان می‌دهد. MTPD بیشترین مدت اختلال قابل تحمل کسب‌وکار است. RTO باید با MTPD سازگار باشد و RPO روی طراحی Backup و Replication اثر می‌گذارد.

Disaster Recovery Plan برنامه عملی بازیابی فناوری پس از اختلال جدی است. DRP باید Scope، Dependency، ترتیب Recovery، RTO/RPO، Runbook، نقش‌ها، Communication و روش Validation را مشخص کند. Backup به‌تنهایی DRP نیست؛ کیفیت برنامه با Exercise و نتیجه واقعی بازیابی سنجیده می‌شود.

Asset Owner پاسخ‌گوی ارزش و نیاز حفاظتی یک دارایی است؛ Risk Owner درباره یک سناریوی Risk تصمیم می‌گیرد؛ Control Owner پاسخ‌گوی طراحی یا اجرای کنترل است. این نقش‌ها می‌توانند افراد متفاوتی باشند و تفکیکشان جلوی ابهام در Accountability را می‌گیرد.

Risk-Based Vulnerability Prioritization یعنی Severity فنی تنها معیار نباشد. Business Criticality، Internet Exposure، Exploitation، KEV، Data Sensitivity و Controlهای موجود هم در Priority اثر می‌گذارند. هدف این است که Remediation روی Vulnerabilityهایی متمرکز شود که Risk واقعی بیشتری برای سازمان دارند.

Risk Heatmap نمایش تصویری Riskها بر اساس Likelihood و Impact است. رنگ‌ها فقط وقتی ارزش دارند که Thresholdهای مشخص، Risk Appetite و منطق امتیازدهی روشن پشت آن‌ها باشد. بهتر است Inherent و Residual Risk جدا دیده شوند و Trend نیز کنار Snapshot فعلی بررسی شود.

Risk Taxonomy زبان مشترک برای دسته‌بندی Riskها در سطح سازمان است؛ مثل Cyber، Operational، Compliance و Third Party. Taxonomy باید به تجمیع و گزارش کمک کند، اما جای Risk Scenario را نگیرد. Category کلی است و Scenario باید علت، رویداد و پیامد واقعی را توضیح دهد.

Control Self-Assessment یا CSA خودارزیابی دوره‌ای کنترل توسط Owner یا واحد مسئول است. CSA برای Coverage گسترده مفید است، اما پاسخ Yes/No بدون Evidence کافی نیست. کنترل‌های مهم بهتر است همراه Attestation، Sample یا Independent Testing اعتبارسنجی شوند تا Self-Assessment بیش‌ازحد خوش‌بینانه نشود.

Compliance Calendar تقویم موعدهای انطباق است؛ مانند Policy Review، Control Test، Evidence Renewal، Audit، Certification، Contract Review و Exception Expiry. هر رویداد باید Owner، Due Date، Lead Time و Escalation داشته باشد تا Calendar فقط Reminder نباشد و به Workflow واقعی متصل شود.

Audit Trail تاریخچه قابل ردیابی تغییرات و تصمیم‌هاست؛ چه کسی، چه چیزی را، چه زمانی و در صورت نیاز چرا تغییر داده است. برای Risk Acceptance، Closure Finding یا تغییر Control Status، Audit Trail به Accountability و ممیزی کمک می‌کند و از Log فنی ساده فراتر می‌رود.

Data Retention تعیین می‌کند هر نوع اطلاعات بر اساس نیاز کسب‌وکار، قانون، قرارداد و Classification تا چه زمانی نگهداری شود و بعد چگونه حذف یا ناشناس شود. Retention خوب Owner، Period، Legal Hold، Backup Behavior و Evidence Disposal را مشخص می‌کند و از نگهداری بی‌دلیل داده جلوگیری می‌کند.

Data Owner درباره ارزش، Classification، Access و Retention داده تصمیم می‌گیرد و معمولاً در Business قرار دارد. Data Custodian اجرای فنی این تصمیم‌ها مثل Backup، Permission و Encryption را بر عهده دارد. جداکردن این دو نقش باعث می‌شود IT به‌اشتباه Owner تمام داده‌های سازمان فرض نشود.

Concentration Risk زمانی ایجاد می‌شود که چند سرویس یا فرایند حیاتی به یک Vendor، Cloud Region، Identity Provider، Technology یا Subprocessor مشترک وابسته باشند. ممکن است هر Vendor به‌تنهایی Risk قابل قبولی داشته باشد، اما Portfolio در مجموع یک Single Point of Failure پنهان ایجاد کند.

وقتی چند نسخه از Risk Register دارید، Evidence در پوشه و ایمیل پخش شده، Reminderها دستی‌اند، Mapping تکراری است و Audit Trail ندارید، هزینه هماهنگی از سادگی Excel بیشتر شده است. مهاجرت باید با پاک‌سازی Owner، Field و Duplicateها شروع شود، نه Import کور همان آشفتگی قبلی.