MedaGRC
در بسیاری از سازمان‌ها مشکل Policy کمبود سند نیست؛ مشکل این است که کسی مطمئن نیست کدام نسخه معتبر است، آخرین بار چه زمانی بازبینی شده و آیا کنترل‌هایی که داخل سند نوشته شده‌اند واقعاً اجرا می‌شوند یا نه. ممکن است «سیاست کنترل دسترسی» در سه پوشه، با سه شماره نسخه متفاوت وجود داشته باشد و هر واحد به یکی از آن‌ها استناد کند.
اینجاست که مدیریت خط‌مشی از نگهداری فایل جدا می‌شود و به بخشی از GRC تبدیل می‌شود. Policy باید Owner، وضعیت، چرخه بازبینی، مرجع تصویب و ارتباط روشن با Requirementها و Controlهای واقعی سازمان داشته باشد.
Policy با Procedure فرق دارد
Policy جهت و قاعده را مشخص می‌کند؛ Procedure توضیح می‌دهد آن قاعده چگونه اجرا می‌شود. اگر Policy بگوید دسترسی ممتاز باید کنترل شود، Procedure می‌تواند فرآیند درخواست، تأیید، ایجاد، بازبینی و حذف دسترسی را توضیح دهد. در یک مدل GRC بهتر است این دو نوع سند از هم تفکیک شوند، اما رابطه‌شان قابل ردیابی باقی بماند.
| نوع | پرسش اصلی | نمونه |
|---|---|---|
| Policy | چه قاعده‌ای باید رعایت شود؟ | دسترسی ممتاز باید مبتنی بر نیاز کاری باشد. |
| Procedure | این قاعده چگونه اجرا می‌شود؟ | فرآیند درخواست و تأیید دسترسی ادمین. |
| Control | چه مکانیزمی ریسک را کاهش می‌دهد؟ | PAM، MFA و بازبینی دوره‌ای دسترسی. |
| Evidence | از کجا می‌فهمیم اجرا شده؟ | گزارش بازبینی دسترسی و لاگ تأییدها. |
چرخه عمر Policy را مرحله‌ای ببینید
یک چرخه عملی می‌تواند از هفت مرحله تشکیل شود: تعریف نیاز، تعیین Owner، تدوین، بازبینی تخصصی، تصویب، انتشار و بازبینی دوره‌ای. در پایان نیز سند باید بازنشسته یا جایگزین شود؛ نه اینکه تا سال‌ها در Share باقی بماند.
- نیاز: مشخص کنید Policy پاسخ‌گوی چه ریسک، الزام یا تصمیم مدیریتی است.
- مالک: یک Owner واقعی تعیین کنید؛ نه صرفاً نام یک واحد.
- تدوین: دامنه، نقش‌ها و قواعد را روشن بنویسید.
- بازبینی: امنیت، حقوقی، منابع انسانی یا واحدهای ذی‌ربط نظر بدهند.
- تصویب: مرجع تصویب و تاریخ اثرگذاری ثبت شود.
- انتشار: نسخه معتبر در محل مشخص در دسترس باشد.
- بازبینی/بازنشستگی: تاریخ بازبینی بعدی و علت تغییر ثبت شود.
کنترل نسخه به‌تنهایی کافی نیست
شماره نسخه مهم است، اما ارزش مدیریتی زمانی ایجاد می‌شود که بدانیم تغییر چرا انجام شده است. برای هر Revision بهتر است تاریخ، تغییرات اصلی، درخواست‌کننده، تأییدکننده و اثر احتمالی روی Control یا Requirement ثبت شود. اگر سیاست دسترسی از «بازبینی سالانه» به «بازبینی فصلی» تغییر کرد، کنترل متناظر نیز باید به‌روزرسانی شود.
سناریو: سیاست دسترسی راه دور
فرض کنید سازمان Policy دسترسی راه دور دارد. نسخه جدید الزام MFA را اضافه کرده است. اگر سند فقط آپلود شود، هنوز معلوم نیست VPN واقعاً MFA دارد یا همه کاربران را پوشش می‌دهد. در مدل GRC، Policy به Requirement مرتبط می‌شود، Requirement به Applied Control متصل می‌شود و Evidence اجرای MFA کنار همان کنترل قرار می‌گیرد. اگر پوشش ناقص باشد، Gap یا Action Plan ایجاد می‌شود.
این همان تفاوت میان «مدیریت مستند» و «مدیریت حاکمیتی مستند» است.
چه فیلدهایی برای Policy مفیدند؟
| فیلد | کاربرد |
|---|---|
| Owner | پاسخ‌گویی و تصمیم درباره تغییر |
| Approver | مرجع رسمی تصویب |
| Effective Date | زمان لازم‌الاجرا شدن |
| Review Date | جلوگیری از قدیمی ماندن سند |
| Status | Draft، Approved، Retired |
| Related Controls | اتصال سند به اجرای واقعی |
| Related Requirements | ردیابی استاندارد و مقرره |
Policy Management در MedaGRC
در MedaGRC هدف این است که Policy جزیره جداگانه نباشد. سند باید به کنترل، الزام، ریسک و Evidence مرتبط شود. این ارتباط برای سازمانی که چند چارچوب را هم‌زمان مدیریت می‌کند اهمیت بیشتری دارد؛ چون یک Policy ممکن است هم‌زمان چند Requirement را پوشش دهد.
اگر در مرحله انتخاب ابزار هستید، صفحه نرم‌افزار GRC معیارهای اصلی انتخاب پلتفرم را توضیح می‌دهد.
سخن پایانی
Policy زمانی ارزش دارد که معتبر، قابل پیدا کردن، دارای Owner و متصل به کنترل واقعی باشد. فایل بدون چرخه عمر خیلی زود به سندی تبدیل می‌شود که فقط در زمان ممیزی پیدا می‌شود. مدیریت خط‌مشی در GRC یعنی تبدیل سند به بخشی از سیستم تصمیم، کنترل و Evidence سازمان.
