MedaGRC
گزارش‌های Service Desk می‌توانند نشان دهند چند تیکت بسته شده، میانگین زمان پاسخ چقدر بوده و چه درصدی از SLA رعایت شده است؛ اما ممیزی یک سؤال عمیق‌تر دارد: آیا فرایند همان‌طور که طراحی شده، در عمل اجرا می‌شود و ریسک‌های آن کنترل شده‌اند؟
MedaGRC در این سناریو نقش لایه حاکمیتی را دارد. داده‌های عملیاتی از Service Desk می‌آیند، اما معیار ممیزی، کنترل، Finding، ریسک و اقدام اصلاحی در یک مسیر قابل ردیابی مدیریت می‌شوند.
سناریو: درخواست‌های دسترسی بدون Approval کامل بسته می‌شوند
در فرایند درخواست دسترسی، سیاست سازمان می‌گوید درخواست باید توسط مدیر واحد و مالک سیستم تأیید شود. ممیز از میان تیکت‌های سه ماه اخیر نمونه‌برداری می‌کند و متوجه می‌شود در بخشی از درخواست‌ها Approval دوم ثبت نشده، با این حال تیکت بسته و دسترسی ایجاد شده است.
جدول گام‌های ممیزی فرایند IT در MedaGRC
| گام | فعالیت ممیزی | داده یا شاهد | خروجی در MedaGRC |
|---|---|---|---|
| ۱ | تعریف فرایند مورد ممیزی | Incident، Request، Change یا Access Request | Scope |
| ۲ | تعیین معیارها | Policy، SLA، Workflow، ISO 20000 یا کنترل داخلی | Audit Criteria |
| ۳ | انتخاب نمونه | تیکت‌های پرریسک، SLA Breach و موارد تصادفی | Sample Set |
| ۴ | بررسی اجرای Workflow | Status History، Approval، Worklog و Assignment | Test Result |
| ۵ | بررسی انحراف | تیکت بسته‌شده بدون Approval کامل | Finding |
| ۶ | تحلیل علت و ریسک | ضعف Workflow یا امکان Bypass | Root Cause / Risk |
| ۷ | تعریف اقدام اصلاحی | اصلاح Workflow، Mandatory Approval و کنترل استثنا | CAPA |
| ۸ | نمونه‌برداری مجدد | تیکت‌های پس از اصلاح | Effectiveness Test |
| ۹ | بستن یافته | شاهد اجرای پایدار کنترل | Closure |
چرا صرفاً SLA برای ممیزی کافی نیست؟
ممکن است یک تیم ۹۸ درصد SLA را رعایت کند اما همچنان کنترل‌های مهم را دور بزند. برای مثال درخواست سریع بسته می‌شود، ولی Approval انجام نشده یا طبقه‌بندی اشتباه باعث می‌شود رخداد امنیتی به‌عنوان درخواست عادی ثبت شود. بنابراین KPI عملیاتی و نتیجه ممیزی مکمل هم هستند، نه جایگزین یکدیگر.
چه چیزهایی از Service Desk می‌تواند Evidence باشد؟
- تاریخچه وضعیت و زمان‌های پاسخ و حل
- Approvalها و رد یا تأیید درخواست
- Worklog و اقدامات کارشناس
- تغییر گروه یا تکنسین مسئول
- ارتباط Request با Change، Asset یا Problem
- علت SLA Breach و Escalation
- نمونه درخواست‌های بسته‌شده و بازگشایی‌شده
از کشف نقص تا اصلاح فرایند
اگر ممیز پنج تیکت بدون Approval پیدا کند، اقدام اصلاحی نباید فقط یادآوری به کارشناسان باشد. اقدام پایدارتر می‌تواند اصلاح Workflow باشد تا بدون تأیید لازم امکان عبور به مرحله بعد وجود نداشته باشد. سپس ممیز باید نمونه جدیدی از تیکت‌ها را بررسی کند تا مطمئن شود کنترل واقعاً در عملیات روزمره اثر کرده است.
رابطه MedaGRC و ServiceDesk Plus چیست؟
ServiceDesk Plus سامانه اجرای عملیات ITSM است؛ MedaGRC لایه حاکمیت، ریسک، کنترل و ممیزی را روی این عملیات قرار می‌دهد. یکی Workflow روزمره را اجرا می‌کند و دیگری کمک می‌کند سازمان ثابت کند این Workflow با سیاست‌ها، کنترل‌ها و الزامات مورد انتظار هم‌راستا است.
برای مطالعه بیشتر، مقاله ISO 20000 و GRC در مدیریت خدمات فناوری اطلاعات و راهنمای طراحی برنامه ممیزی داخلی را ببینید.
چه زمانی Finding بسته می‌شود؟
وقتی اقدام انجام شد، نه؛ وقتی اثربخشی اقدام اثبات شد. این تفاوت مهمی است. تغییر Workflow یک فعالیت است، اما نمونه‌برداری دوباره و مشاهده اجرای صحیح Approval، شاهد اثربخشی است. در MedaGRC می‌توان این دو مرحله را از هم جدا نگه داشت تا Closure صوری اتفاق نیفتد.
جمع‌بندی
ممیزی فرایند IT با MedaGRC از یک سؤال ساده شروع می‌شود: قرار بود فرایند چگونه کار کند؟ سپس با نمونه واقعی از Service Desk بررسی می‌شود واقعاً چگونه کار کرده است. فاصله میان این دو تبدیل به Finding می‌شود و تا اصلاح، آزمون اثربخشی و بستن نهایی دنبال می‌شود.
برای آشنایی با مدیریت Finding و اقدام اصلاحی، مقاله CAPA در GRC و صفحه نرم‌افزار مدیریت ممیزی MedaGRC را ببینید.
