حاکمیت ISMS و نقش‌ها در ISO 27001

اگر قرار است پیاده‌سازی ISO 27001 برای شما فقط «یک سری سند برای گرفتن گواهی» نباشد و واقعاً در سازمان کار کند، نقطه شروع همین‌جاست: حاکمیت ISMS و نقش‌ها. در این صفحه دقیقاً روشن می‌کنیم چه کسی تصمیم‌گیر است، چه کسی پاسخگوست، چه نقش‌هایی باید تعریف شوند (و کدام نقش‌ها در سازمان‌های کوچک می‌تواند تجمیع شود)، کمیته امنیت اطلاعات چه ساختاری و چه خروجی‌هایی باید داشته باشد، و چطور با مدل‌های RACI جلوی تداخل مسئولیت‌ها و رهاشدگی کارها را می‌گیریم. هدف این است که شما یک نقشه اجرایی قابل دفاع داشته باشید؛ نقشه‌ای که هم در ممیزی Stage 1 و Stage 2 قابل ارائه باشد، هم بعد از گرفتن گواهی، ISMS را زنده و قابل مدیریت نگه دارد.

حاکمیت ISMS دقیقاً یعنی چه و چرا در عمل شکست/موفقیت ISMS به آن وابسته است؟

حاکمیت ISMS یعنی «چارچوب تصمیم‌گیری، پاسخگویی و کنترل» برای امنیت اطلاعات؛ نه صرفاً مجموعه‌ای از سیاست‌ها و فرم‌ها. وقتی از حاکمیت حرف می‌زنیم، منظورمان این است که در سازمان شما دقیقاً مشخص باشد چه کسی درباره امنیت اطلاعات تصمیم می‌گیرد، چه کسی مسئول اجرای تصمیم است، چه کسی باید گزارش بدهد، و اگر کاری انجام نشد یا ریسکی پذیرفته شد، پاسخگو چه کسی است. این همان چیزی است که باعث می‌شود ISMS از حالت “پروژه کاغذی برای گرفتن گواهی” خارج شود و تبدیل به یک سیستم واقعیِ قابل اداره و قابل ممیزی شود.

تفاوت «داشتن سند» با «داشتن سازوکار تصمیم‌گیری و پاسخگویی»

خیلی از سازمان‌ها از نظر ظاهری همه چیز را دارند: سیاست امنیت اطلاعات، روش اجرایی مدیریت ریسک، SoA، حتی فرم‌های متعدد. اما در عمل، ISMS جلو نمی‌رود چون این اسناد به تصمیم‌گیری واقعی وصل نشده‌اند. داشتن سند یعنی «گفتن اینکه چه باید باشد». داشتن سازوکار حاکمیت یعنی «تضمین کردن اینکه واقعاً اتفاق می‌افتد».

در حاکمیت درست، هر موضوع امنیتی یک مسیر مشخص دارد: از شناسایی ریسک و مالک آن، تا تصمیم درمان ریسک، تا تعیین مالک کنترل، تا تولید Evidence و گزارش‌دهی دوره‌ای. به زبان ساده، اگر امروز یک ریسک مهم شناسایی شد (مثلاً دسترسی‌های بیش از حد یا نبود کنترل روی پیمانکار)، فردا معلوم است چه کسی باید تصمیم بگیرد، چه کسی باید اجرا کند، و چه کسی باید اثربخشی را تایید کند. همین زنجیره است که ISMS را “قابل اتکا” می‌کند—و دقیقاً همان چیزی است که در ممیزی Stage 1 و Stage 2 هم خودش را نشان می‌دهد.

نشانه‌های حاکمیت ضعیف (هشدارهایی که ISMS را زمین می‌زند)

اگر یکی از نشانه‌های زیر را در سازمان می‌بینید، معمولاً مشکل اصلی «کمبود سند» نیست؛ مشکل این است که حاکمیت ISMS درست بسته نشده است:

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

تداخل وظایف و مسئولیت‌های مبهم: دو نفر فکر می‌کنند “آن یکی” مسئول است؛ یا بدتر، چند نفر هم‌زمان مسئول می‌شوند و هیچ‌کس پاسخگو نیست. این دقیقاً جایی است که RACI و تعریف نقش‌ها حیاتی می‌شود، چون جلوی رهاشدگی کارها و دعوای بین واحدها را می‌گیرد.

عدم مالکیت ریسک (Risk Owner واقعی نداریم): ریسک‌ها روی کاغذ ثبت می‌شوند، اما مشخص نیست چه کسی باید تصمیم درمان ریسک را بگیرد یا پذیرش ریسک را امضا کند. وقتی مالک ریسک واقعی ندارید، ارزیابی ریسک تبدیل می‌شود به یک فایل اکسل که فقط برای ممیزی به‌روزرسانی می‌شود.

SoA صوری و غیرقابل دفاع: در ظاهر، SoA تکمیل شده و کنترل‌ها “تیک” خورده‌اند، اما وقتی ممیز سؤال می‌پرسد که چرا یک کنترل انتخاب شده یا چرا حذف شده، استدلال شفاف و قابل ردیابی ندارید. SoA باید خروجی تصمیم‌گیری مبتنی بر ریسک باشد، نه یک لیست تزئینی از Annex A.

Evidence ناقص یا پراکنده: کنترل‌ها شاید اجرا شده باشند، اما شواهدشان یا تولید نشده، یا در ایمیل‌ها و چت‌ها گم شده، یا مالک مشخصی برای نگهداری و ارائه آن وجود ندارد. اینجا هم حاکمیت تعیین می‌کند “مالک کنترل” چه کسی است، Evidence کجا نگهداری می‌شود، و گزارش‌دهی دوره‌ای چطور انجام می‌شود.

خروجی‌های قابل تحویل این صفحه چیست؟

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

اینکه در ISMS چه نقش‌هایی لازم است، کدام نقش‌ها می‌تواند در سازمان‌های کوچک تجمیع شود، و دقیقاً هر نقش بابت چه چیزی پاسخگوست. کنار آن، شما به مدل RACI عملیاتی می‌رسید تا برای فرآیندهای اصلی ISMS (ریسک، رخداد، دسترسی، تامین‌کننده، ممیزی داخلی، CAPA و…) مشخص شود چه کسی Responsible است، چه کسی Accountable، چه کسانی Consulted و چه کسانی Informed؛ یعنی دیگر کارها بین واحدها گم نمی‌شود و “همه فکر نمی‌کنند مسئول دیگری است”.

خروجی بعدی، ساختار کمیته امنیت اطلاعات است: ترکیب اعضا، حوزه اختیارات، تناوب جلسات و دستورجلسه‌های استاندارد، به‌علاوه یک چارتر/آیین‌نامه کمیته و قالب صورت‌جلسه‌ای که واقعاً برای ممیزی Evidence تولید می‌کند. همچنین چند نمونه شرح وظایف (Job Description) برای نقش‌های کلیدی مثل ISMS Manager، Risk Owner و Control Owner دارید تا سریع و استاندارد انتصاب‌ها را انجام دهید. در نهایت، یک ماتریس اختیارات و تصمیم‌ها خواهید داشت که روشن می‌کند تصمیم‌های مهم (مثل پذیرش ریسک، انتخاب/حذف کنترل‌ها در SoA، اولویت‌بندی اقدامات اصلاحی، مدیریت رخدادهای مهم و…) دقیقاً در چه سطحی و توسط چه کسی باید تأیید شود—هم برای جلوگیری از تصمیم‌های سلیقه‌ای، هم برای اینکه ISMS بعد از اخذ گواهی هم “قابل اداره” بماند.

نقش‌های کلیدی در ISMS (حداقل نقش‌های پیشنهادی)

در ISMS دو چیز باید هم‌زمان درست کار کند: تصمیم‌گیری و پاسخگویی (Governance) و اجرا و شواهد (Execution & Evidence). برای همین هم نقش‌ها را طوری می‌چینیم که هم در سازمان کوچک قابل اجرا باشد (با تجمیع منطقی نقش‌ها)، هم در سازمان متوسط و بزرگ قابل تفکیک و مقیاس‌پذیر باشد. نکته مهم این است: تجمیع نقش‌ها مجاز است، اما تجمیعِ نقش‌هایی که تضاد منافع ایجاد می‌کند (مثل اجرا و ممیزی) معمولاً به ضرر شما تمام می‌شود.

Sponsor / حامی مدیریتی (نماینده مدیریت ارشد)

این نقش «صاحب اختیار» ISMS است؛ یعنی جایی که تصمیم‌های کلان امنیت اطلاعات باید پشتوانه واقعی داشته باشد. Sponsor مسئول این است که ISMS در اولویت بماند، منابع (بودجه/نیروی انسانی/زمان) تأمین شود، و موانع بین واحدی برطرف شود. در عمل، وقتی ریسک مهمی مطرح می‌شود یا یک کنترل نیاز به هزینه یا تغییر فرآیند دارد، این نقش باید تصمیم را قطعی کند و جلوی “پاسکاری” را بگیرد. در ممیزی هم معمولاً انتظار می‌رود مدیریت ارشد نشان دهد آگاه است، حمایت می‌کند، و تصمیم‌های کلیدی را تأیید می‌کند (مثلاً پذیرش ریسک‌های مهم یا تایید سیاست‌ها و اهداف امنیتی).

ISMS Manager / مسئول ISMS

ISMS Manager ستون فقرات هماهنگی سیستم است. این نقش مالک «کل چرخه» است: برنامه‌ریزی، هماهنگی اجرا، پیگیری پیشرفت، مدیریت مستندات، آماده‌سازی ممیزی‌ها و دنبال‌کردن عدم انطباق‌ها و اقدامات اصلاحی. اگر بخواهیم ساده بگوییم، ISMS Manager تضمین می‌کند که ISMS از “فایل و فرم” تبدیل به “کارِ واقعی با خروجی قابل ارائه” شود. در سازمان‌های کوچک، این نقش می‌تواند با مسئول امنیت اطلاعات یا حتی مدیر کیفیت/سیستم‌ها تجمیع شود، اما باید اختیار پیگیری بین واحدی و گزارش‌دهی مستقیم به مدیریت را داشته باشد؛ وگرنه ISMS تبدیل به پروژه‌ای می‌شود که هر واحد فقط وقتی وقت داشت همکاری می‌کند.

Information Security Officer (ISO) / مسئول امنیت اطلاعات (اگر جدا از ISMS Manager است)

این نقش بیشتر روی “محتوای امنیت” و “کنترل‌های امنیتی” تمرکز دارد: سیاست‌ها و دستورالعمل‌های امنیتی، هم‌راستا کردن کنترل‌ها با ریسک‌ها، پایش وضعیت امنیت، هماهنگی پاسخ به رخدادها و گزارش‌دهی امنیتی. در بسیاری از سازمان‌ها، ISMS Manager نقش مدیریتی/سیستمی دارد و ISO نقش فنی/امنیتی؛ در سازمان‌های کوچک ممکن است هر دو یکی باشند. تفاوت کلیدی این است که ISO معمولاً بیشتر با IT/SOC/Network و تیم‌های عملیاتی امنیت درگیر می‌شود و باید بتواند از نظر فنی و مدیریتی، کنترل‌ها را «قابل اجرا و قابل سنجش» کند.

Risk Owner / مالک ریسک

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

Asset Owner / مالک دارایی

مالک دارایی مسئول این است که دارایی‌های اطلاعاتی (اطلاعات، سیستم‌ها، سرویس‌ها، پایگاه داده‌ها، اسناد حساس و…) درست شناسایی و طبقه‌بندی شوند و نیازمندی‌های حفاظتی‌شان مشخص باشد. Asset Owner باید بداند دارایی‌اش چه ارزشی دارد، چه تهدیدهایی دارد، سطح محرمانگی/یکپارچگی/دسترس‌پذیری مورد انتظار چیست و چه کنترل‌هایی برای آن لازم است. در سازمان کوچک، Asset Owner می‌تواند همان مدیر واحد یا مدیر سیستم باشد، اما مهم این است که مالکیت “شفاف” باشد تا هنگام رخداد یا ممیزی، مسئولیت بین افراد پخش و مبهم نشود.

Control Owner / مالک کنترل

Control Owner کسی است که می‌گوید «این کنترل واقعاً اجرا شده و شواهدش آماده است». او مسئول اجرای پایدار کنترل، نگهداری Evidence، پایش شاخص‌های کنترل (KPI/KRI) و رسیدگی به عدم انطباق‌های مرتبط با آن کنترل است. بسیاری از شکست‌های ممیزی از همین‌جا می‌آید: کنترل در SoA “انتخاب شده” ولی مالک ندارد، یا Evidence پراکنده است، یا اجرای کنترل فقط یک‌بار انجام شده و بعد رها شده است. Control Owner دقیقاً جلوی این اتفاق را می‌گیرد و کنترل را به یک فعالیت قابل اندازه‌گیری تبدیل می‌کند.

Incident Manager / مسئول رخداد

این نقش مسئول جریان «مدیریت رخداد» است: دریافت و ثبت رخداد، طبقه‌بندی، هماهنگی پاسخ، ارتباطات داخلی/خارجی (در صورت نیاز)، تحلیل علت، و درس‌آموخته‌ها (Lessons Learned). Incident Manager لزوماً فنی‌ترین فرد نیست؛ اما باید توان هماهنگی سریع بین تیم‌ها را داشته باشد و بداند چه زمانی موضوع باید به مدیریت ارشد یا کمیته امنیت گزارش شود. در سازمان‌های کوچک، این نقش می‌تواند با ISO یا مدیر IT تجمیع شود؛ ولی باید یک نفر “صاحب فرآیند” باشد تا رخدادها گم نشوند یا گزارش‌دهی دیرهنگام نشود.

Internal Auditor / ممیز داخلی ISMS

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

DPO / مسئول حفاظت داده (در صورت نیاز)

اگر سازمان شما داده‌های شخصی گسترده پردازش می‌کند (مشتری، کارمند، بیمار، کاربر، مخاطب آنلاین و…)، نقش DPO یا مسئول حفاظت داده می‌تواند ضروری باشد. نکته مهم مرزبندی است: امنیت اطلاعات روی حفاظت از دارایی‌ها و کنترل‌های امنیتی تمرکز دارد؛ حفاظت داده روی حقوق اشخاص، مبنای پردازش، حداقل‌سازی، نگهداری، پاسخ به درخواست‌ها، و الزامات قانونی/حریم خصوصی. در بعضی سازمان‌ها این نقش با حقوقی/Compliance نزدیک است و باید با ISMS هماهنگ باشد، اما جایگزین آن نیست.

نقش‌های پشتیبان: IT / Network / SOC / HR / Legal / Procurement

ISMS بدون نقش‌های پشتیبان، در بهترین حالت “روی کاغذ” می‌ماند. اما نکته کلیدی این است که مرز مسئولیت‌ها روشن باشد:

• IT/Network/SOC معمولاً مجری بخش مهمی از کنترل‌های فنی هستند (دسترسی، لاگ، پچینگ، پشتیبان‌گیری، مانیتورینگ، پاسخ فنی به رخداد). ولی مالک تصمیم‌گیری ISMS نیستند مگر سازمان شما کوچک باشد و نقش‌ها تجمیع شده باشد.
• HR در چرخه کارکنان حیاتی است: آموزش و آگاهی، تعهدنامه‌ها، فرآیند ورود/جابجایی/خروج (Joiner/Mover/Leaver)، و کاهش ریسک انسانی.
• Legal/Compliance برای الزامات قانونی و قراردادی، بندهای امنیتی، NDA، پاسخ‌های حقوقی در رخدادها و تعاملات با رگولاتور/مشتری لازم است.
• Procurement/Vendor Management برای کنترل تامین‌کننده: ارزیابی ریسک تامین‌کننده، بندهای امنیتی قرارداد، پایش سرویس‌دهنده‌ها و مدیریت تغییرات.

جمع‌بندی اجرایی (برای اینکه این بخش واقعاً قابل اجرا بماند)

اگر سازمان کوچک هستید، معمولاً این ترکیب عملی است: Sponsor (مدیریت) + ISMS Manager/ISO (تجمیع) + چند Risk Owner/Asset Owner در واحدها + Control Ownerها در IT/عملیات + Incident Manager (تجمیع) + ممیزی داخلی مستقل (ترجیحاً غیر از مجری). اگر سازمان بزرگ‌تر است، همین نقش‌ها را تفکیک می‌کنید، کمیته امنیت شکل می‌گیرد و RACI کمک می‌کند هر فرآیند صاحب مشخص داشته باشد و Evidenceها قابل ردیابی بماند.

ساختارهای رایج حاکمیت ISMS (مدل‌های پیشنهادی بر اساس اندازه سازمان)

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

سناریو ۱: سازمان کوچک (نقش‌های تجمیع‌شده)

در سازمان کوچک، بهترین مدل این است که نقش‌ها را تجمیع کنید اما تضاد منافع ایجاد نکنید. معمولاً یک نفر (یا یک نقش) باید ستون هماهنگی ISMS باشد و چند نقش دیگر هم به‌صورت پاره‌وقت و مشخص مسئولیت بگیرند.

چیدمان پیشنهادی (واقع‌بینانه و قابل اجرا):
مدیریت ارشد یا نماینده‌اش نقش Sponsor را دارد. یک نفر به‌عنوان ISMS Manager/ISO (تجمیع‌شده) کل کار را هماهنگ می‌کند. برای دارایی‌ها و ریسک‌ها، به جای ساختار پیچیده، کافی است 2–5 نفر از واحدهای کلیدی به‌عنوان Risk Owner/Asset Owner معرفی شوند (معمولاً مدیر فروش/عملیات/مالی/IT بسته به Scope). کنترل‌های فنی و عملیاتی هم به عهده Control Ownerهاست (مثلاً مدیر IT یا مسئول شبکه).

چه نقش‌هایی می‌تواند یکی باشد؟ (تجمیع‌های معمول و کم‌ریسک)

• ISMS Manager + Information Security Officer: در سازمان کوچک کاملاً رایج است و اگر فرد اختیار پیگیری داشته باشد، خوب جواب می‌دهد.
• Asset Owner + Risk Owner: در بسیاری از دارایی‌ها، همان مدیر واحد هم مالک دارایی است هم مالک ریسک مرتبط، به شرط اینکه تصمیم‌های پذیرش ریسک شفاف ثبت شود.
• Incident Manager + ISO/IT Manager: اگر تیم پاسخ رخداد جدا ندارید، این تجمیع معمول است.

چه نقش‌هایی نباید یکی شود؟ (برای جلوگیری از تضاد منافع و صوری شدن ممیزی)

• Internal Auditor با نقش‌های اجرایی کنترل‌ها: کسی که کنترل را اجرا می‌کند، نباید ممیزی داخلی همان کنترل را انجام دهد. اگر نیروی مستقل ندارید، ممیزی داخلی را به فردی از واحد دیگری بدهید یا برون‌سپاری کنید.
• Risk Owner با Internal Auditor: مالک ریسک نباید ممیز همان حوزه باشد؛ چون عملاً خودش عملکرد خودش را تایید می‌کند.
• Control Owner با تأییدکننده نهایی پذیرش ریسک‌های مهم: پذیرش ریسک‌های High معمولاً باید سطح مدیریتی/کمیته‌ای داشته باشد، نه همان مجری کنترل.

نتیجه این سناریو چیست؟
کمترین نقش‌ها را دارید، اما سه چیز کاملاً شفاف است: 1) تصمیم‌گیری کجاست (Sponsor)، 2) هماهنگی و پیگیری دست کیست (ISMS Manager/ISO)، 3) هر ریسک و کنترل “مالک” دارد و Evidence گم نمی‌شود.

سناریو ۲: سازمان متوسط (نقش‌های تفکیک‌شده با کمیته سبک)

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

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

• Sponsor/Top Management Representative: یک نفر که تصمیم‌ها را قطعی می‌کند و موانع را برمی‌دارد.
• ISMS Manager جدا از ISO/Security Lead (در صورت امکان): اولی سیستم و ممیزی و CAPA را می‌برد جلو، دومی کنترل‌ها و رخداد و پایش امنیت را.
• Information Security Committee (سبک): 4 تا 7 نفر (مدیریت/ISMS/IT/HR/Legal + دو Risk Owner کلیدی).
• Risk Ownerها برای حوزه‌های اصلی Scope (مثلاً عملیات، مالی، فناوری، مشتری).
• Control Ownerها برای کنترل‌های مهم (دسترسی، بکاپ، لاگ، تامین‌کننده، آموزش، …).
• Internal Auditor مستقل (درون‌سازمانی یا برون‌سپاری).

چرا “کمیته سبک” مهم است؟
چون تصمیم‌های کلیدی مثل پذیرش ریسک، اولویت اقدامات اصلاحی، و تغییرات مهم در Scope/SoA باید یک جای رسمی تصویب شود. اگر کمیته نداشته باشید، تصمیم‌ها یا معطل می‌ماند یا پراکنده و سلیقه‌ای می‌شود و در ممیزی هم قابل دفاع نیست.

ویژگی این مدل:
نقش‌ها خیلی زیاد نشده‌اند، اما دو اتفاق می‌افتد:

1. تصمیم‌ها سریع‌تر و قابل ردیابی می‌شوند (صورت‌جلسه + مصوبه)،
2. اجرای کنترل‌ها صاحب پیدا می‌کند و Evidenceها روی زمین نمی‌ماند.

سناریو ۳: سازمان بزرگ/چندسایت (کمیته + کارگروه‌ها)

در سازمان بزرگ یا چندسایت، اگر ساختار را یک‌لایه طراحی کنید، یا کنترل از دست می‌رود (به‌خاطر پراکندگی) یا سیستم بیش از حد بوروکراتیک می‌شود. مدل درست معمولاً لایه‌ای است: یک لایه مرکزی (Corporate) برای سیاست‌گذاری و تصمیم‌های کلان، و یک لایه محلی (Site/BU) برای اجرا و Evidence.

ساختار لایه‌ای (Corporate vs Site) و مدل گزارش‌دهی

لایه مرکزی (Corporate / Head Office):

• Steering Committee / کمیته راهبری ISMS (سطح تصمیم‌های کلان): تصویب سیاست‌ها، پذیرش ریسک‌های کلان، تایید برنامه سالانه، مدیریت منابع، گزارش‌دهی به مدیریت ارشد.
• CISO/Head of InfoSec یا Security Lead مرکزی: استانداردسازی کنترل‌ها، معماری امنیت، مدیریت رخدادهای重大، پایش کلان.
• ISMS Program Manager: هماهنگی بین سایت‌ها، یکپارچه‌سازی شواهد، آماده‌سازی ممیزی‌های چندسایت، مدیریت تغییرات و CAPA در سطح سازمان.

لایه محلی (Site / Business Unit):

• Site ISMS Coordinator: هماهنگ‌کننده محلی برای جمع‌آوری Evidence و اجرای برنامه‌ها.
• Local Risk Owners / Asset Owners: مالکیت ریسک و دارایی در همان سایت/واحد.
• Local Control Owners: اجرای کنترل‌ها و تولید Evidence در عملیات واقعی.

کارگروه‌ها (Working Groups) به‌جای کمیته‌های متعدد:
به جای اینکه برای هر موضوع یک کمیته رسمی بسازید، کارگروه‌های چابک تعریف کنید، مثل:

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

مدل گزارش‌دهی پیشنهادی (ساده اما حرفه‌ای):

• سایت‌ها به‌صورت ماهانه/دوماهه یک گزارش کوتاه KPI/KRI + وضعیت CAPA + رخدادهای مهم می‌دهند.
• تجمیع در سطح مرکزی انجام می‌شود و هر فصل یک گزارش مدیریتی برای Steering Committee تولید می‌شود.
• پذیرش ریسک‌های High یا رخدادهای Major مستقیماً به سطح مرکزی Escalate می‌شود.

مزیت این مدل:
هم استانداردسازی دارید (یکپارچگی سیاست‌ها و کنترل‌ها)، هم اجرا در محل واقعی انجام می‌شود (Evidence واقعی). ممیزی هم ساده‌تر می‌شود چون هم “کنترل مرکزی” دارید هم “شواهد محلی” قابل ردیابی.

کمیته امنیت اطلاعات (Information Security Committee) و سازوکار تصمیم‌گیری

کمیته امنیت اطلاعات جایی است که ISMS از حالت «پراکنده بین واحدها» خارج می‌شود و تبدیل می‌شود به یک سیستم قابل اداره: تصمیم‌ها به‌موقع گرفته می‌شوند، ریسک‌ها مالک و مسیر دارند، رخدادها جدی پیگیری می‌شوند، و اقدامات اصلاحی تا اثربخشی بسته می‌شود. اگر کمیته درست طراحی شود، هم اصطکاک بین IT/کسب‌وکار/حقوقی کم می‌شود، هم برای ممیزی Stage 1 و Stage 2 یک Evidence قوی و قابل دفاع تولید می‌کند. اما اگر کمیته تبدیل شود به جلسه‌های طولانی و بی‌خروجی، نتیجه‌اش دقیقاً برعکس است: فرسایش، مقاومت واحدها، و صوری شدن ISMS.

کمیته چه کاری می‌کند و چه کاری نباید بکند؟

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

• تصویب و جهت‌دهی کلان ISMS: تأیید سیاست‌های امنیت اطلاعات، اهداف امنیتی، اولویت‌های سالانه و مسیر کلی اجرا.
• تصمیم درباره ریسک‌های مهم: بررسی ریسک‌های High/Critical، تعیین اینکه کاهش/انتقال/پذیرش انجام شود، و در صورت پذیرش ریسک، ثبت تصمیم با دلیل و شرط‌های کنترلی.
• تأیید تغییرات اثرگذار: تغییر Scope، تغییرات مهم در SoA، تغییرات عمده در سرویس‌های برون‌سپاری/تامین‌کنندگان، یا تغییراتی که بر ریسک سازمان اثر مستقیم دارند.
• نظارت بر وضعیت کنترل‌ها با شاخص‌های ساده: نه ورود به جزئیات فنی، بلکه اینکه آیا کنترل‌های کلیدی “کار می‌کنند” و Evidence دارند یا خیر.
• Escalation و رفع بن‌بست‌ها: وقتی اجرای کنترل‌ها بین واحدها گیر می‌کند (بودجه، تعارض فرایندی، مخالفت واحدها)، کمیته تصمیم می‌گیرد و مانع را برمی‌دارد.
• پیگیری رخدادهای مهم و درس‌آموخته‌ها: رخدادهای Significant/Major باید در کمیته مرور شوند، تصمیم‌های اصلاحی کلان گرفته شود و پیگیری تا بسته شدن انجام شود.
• پایش CAPA و اثربخشی اقدامات اصلاحی: تمرکز روی موارد تکرارشونده، موارد پرریسک، و اقداماتی که بدون حمایت مدیریتی بسته نمی‌شوند.

اما کمیته نباید وارد «اجرای روزمره» شود. مواردی که بهتر است کمیته انجام ندهد:

• مایکرو-مدیریت و تصمیم‌های عملیاتی: مثل اینکه دقیقاً کدام تنظیمات فایروال چگونه باشد، یا اینکه یک کنترل فنی با چه ابزار خاصی پیاده شود. این‌ها جای کارگروه‌های فنی/عملیاتی است.
• بررسی همه ریسک‌ها و همه کنترل‌ها: کمیته باید روی “ریسک‌ها و کنترل‌های کلیدی” تمرکز کند؛ نه اینکه تبدیل شود به جلسه‌ای برای مرور کامل اکسل ریسک.
• جلسه صرفاً گزارش‌گیری بدون تصمیم: اگر خروجی کمیته فقط «شنیدن گزارش» باشد و هیچ تصمیم/مصوبه/اقدام مشخصی تولید نشود، کمیته عملاً ارزش Governance ندارد.
• دور زدن مالک‌ها: کمیته نباید جای Risk Owner یا Control Owner تصمیم‌های روتین را بگیرد. باید مالک‌ها پاسخگو باشند و کمیته فقط سطح تصمیم‌های کلان و بن‌بست‌ها را حل کند.

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

ترکیب اعضا (ترکیب حداقلی و ترکیب پیشنهادی)

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

ترکیب حداقلی (برای سازمان کوچک/متوسط):

• نماینده مدیریت ارشد (Sponsor/Chair): رئیس جلسه؛ برای تصمیم‌های کلان و رفع بن‌بست.
• ISMS Manager: دبیر کمیته؛ آماده‌سازی دستورجلسه، پیگیری مصوبات، جمع‌آوری Evidence.
• نماینده IT/Operations: برای کنترل‌های فنی و تغییرات عملیاتی.
• یک یا دو Risk Owner کلیدی (مثلاً عملیات/مالی/فروش، بسته به Scope): برای تصمیم‌های واقعی درمان ریسک.

این ترکیب حداقلی معمولاً 4–5 نفر می‌شود و اگر درست مدیریت شود، بسیار کارآمد است.

ترکیب پیشنهادی (برای سازمان متوسط/بزرگ یا Scope حساس):

• نماینده مدیریت ارشد (Chair)
• ISMS Manager (Secretary)
• مسئول امنیت اطلاعات / Security Lead (اگر جداست)
• IT (زیرساخت/شبکه/سیستم‌ها)
• HR (برای آگاهی‌رسانی، چرخه کارکنان، Joiner/Mover/Leaver)
• Legal/Compliance (برای الزامات قانونی، قراردادها، حریم خصوصی، تعهدات مشتری)
• Procurement/Vendor Manager (اگر تامین‌کننده‌ها/برون‌سپاری مهم است)
• 2–3 Risk Owner اصلی حوزه‌های در Scope

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

قاعده طلایی: اگر کسی در کمیته است ولی نه اختیار تصمیم دارد، نه مالکیت ریسک/کنترل، معمولاً فقط جلسه را سنگین می‌کند.

دستورجلسه‌های استاندارد (Template)

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

1. مرور مصوبات جلسه قبل (5–10 دقیقه)

• وضعیت هر مصوبه: انجام شد/در حال انجام/متوقف
• موارد متوقف: علت + تصمیم رفع مانع

2. ریسک‌های باز و ریسک‌های High/Critical (15–25 دقیقه)

• ریسک‌های جدید مهم
• ریسک‌های High که موعد تصمیم دارند (پذیرش/کاهش/انتقال)
• درخواست‌های پذیرش ریسک + شرایط پذیرش (کنترل جبرانی، بازه زمانی، تاریخ بازنگری)

3. رخدادها و شبه‌رخدادها (10–20 دقیقه)

• رخدادهای Significant/Major
• علت ریشه‌ای (در حد مدیریتی) + درس‌آموخته
• تصمیم‌های اصلاحی کلان و مسئول پیگیری

4. شاخص‌های کلیدی (KPI/KRI) کنترل‌ها (10–15 دقیقه)

• 5 تا 10 شاخص ثابت و ساده (مثلاً: وضعیت پچینگ بحرانی، درصد تکمیل آموزش، وضعیت بکاپ/بازیابی آزمون‌شده، رخدادهای تکرارشونده، دسترسی‌های پرریسک)
• تمرکز روی روند و تصمیم، نه گزارش‌خوانی

5. وضعیت CAPA / عدم انطباق‌ها و اثربخشی (10–20 دقیقه)

• عدم انطباق‌های باز و نزدیک به موعد
• اقدامات اصلاحی که Evidence اثربخشی ندارند
• موارد تکرارشونده: تصمیم اصلاح سیستماتیک

6. تغییرات مهم (Change) که ریسک را جابه‌جا می‌کند (5–10 دقیقه)

• تغییرات در Scope، سرویس‌های ابری/برون‌سپاری، فرآیندهای حساس، ساختار سازمان
• تصمیم درباره ارزیابی ریسک تغییر و کنترل‌های لازم

7. تامین‌کنندگان و قراردادهای حساس (5–10 دقیقه)

• تامین‌کنندگان High-risk
• وضعیت ارزیابی/ممیزی تامین‌کننده
• بندهای امنیتی قرارداد و موارد نقض/ریسک

8. ممیزی‌ها و آمادگی ممیزی (5–10 دقیقه)

• نتایج ممیزی داخلی/خارجی، روند عدم انطباق‌ها
• تصمیم‌های مدیریتی برای موارد پرریسک

9. جمع‌بندی مصوبات جلسه (5 دقیقه)

• تصمیم‌ها، مالک، موعد، Evidence مورد انتظار

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

تناوب جلسات و صورت‌جلسه قابل دفاع برای ممیزی

تناوب جلسات باید به سطح ریسک و بلوغ ISMS شما بخورد:

• ماهانه: برای سازمان‌هایی که تازه پیاده‌سازی می‌کنند، یا ریسک/تغییر/برون‌سپاری زیاد دارند، یا رخدادهای امنیتی تکرار می‌شود. این مدل در سال اول معمولاً بهترین است.
• فصلی (هر 3 ماه): برای سازمان‌هایی که سیستم جا افتاده و شاخص‌ها پایدار است، یا منابع محدود دارند اما می‌خواهند Governance رسمی و قابل دفاع داشته باشند.
• جلسه فوق‌العاده: برای رخداد Major، تغییرات کلان، یا پذیرش ریسک‌های خیلی مهم.

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

حداقل مواردی که در صورت‌جلسه باید ثبت شود (Evidence-ready):

• تاریخ/زمان/شرکت‌کنندگان (حاضر و غایب) + نقش هر نفر
• موارد بررسی‌شده (دستورجلسه)
• مصوبات دقیق: تصمیم چه بود، چرا گرفته شد، مالک پیگیری کیست، موعد چه زمانی است
• در تصمیم‌های ریسک: سطح ریسک، تصمیم درمان ریسک، شرط‌ها/کنترل‌های جبرانی، تاریخ بازنگری
• در رخدادها: خلاصه رخداد، تصمیم‌های اصلاحی کلان، مسئول و موعد، نیاز به اطلاع‌رسانی/گزارش‌دهی
• در CAPA: وضعیت، Evidence اثربخشی، موارد Escalate شده
• پیوست‌های کلیدی (در صورت وجود): داشبورد KPI، خلاصه ریسک‌های High، گزارش رخدادهای مهم، لیست اقدامات باز

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

مدل RACI برای ISMS (ستون فقرات جلوگیری از تداخل و رهاشدگی کارها)

اگر بخواهم یک ابزار را انتخاب کنم که بیشترین اثر را در «عملیاتی شدن ISMS» دارد، همان RACI است. چون اکثر شکست‌های اجرایی در ISO 27001 از کمبود کنترل نیست؛ از این است که کار بین نقش‌ها گم می‌شود: هر واحد فکر می‌کند مسئول دیگری است، تصمیم‌گیر مشخص نیست، شواهد تولید می‌شود اما مالک نگهداری ندارد، و در ممیزی هم همه چیز پراکنده به نظر می‌رسد. RACI دقیقاً این نقطه را حل می‌کند: برای هر فرآیند/فعالیت مشخص می‌کند چه کسی اجرا می‌کند، چه کسی پاسخگوست، چه کسانی باید مشورت داده شوند و چه کسانی باید در جریان باشند.

RACI چیست و چطور اشتباه اجرا می‌شود؟

RACI یک ماتریس نقش-مسئولیت است که چهار وضعیت را تعریف می‌کند:

• R (Responsible): انجام‌دهنده کار (کسی که کار را جلو می‌برد و خروجی تولید می‌کند)
• A (Accountable): پاسخگو/تصمیم‌گیر نهایی (کسی که تأیید می‌کند و پای تصمیم می‌ایستد)
• C (Consulted): مشورت‌شونده (کسی که نظر تخصصی می‌دهد و باید در تصمیم‌سازی دخیل باشد)
• I (Informed): مطلع‌شونده (کسی که باید بداند چه اتفاقی افتاد، بدون اینکه در تصمیم یا اجرا دخیل باشد)

اما RACI وقتی اشتباه اجرا شود، خودش تبدیل به یک فایل تزئینی می‌شود. خطاهای رایج که باید از همان ابتدا جلویشان را بگیرید:

۱) چند “A” برای یک فعالیت
اگر برای یک کار چند نفر را A بگذارید، یعنی در واقع هیچ‌کس پاسخگو نیست. در RACI اصولاً باید برای هر فعالیت یک A داشته باشید (به‌جز موارد خاص، که باز هم بهتر است تفکیک فعالیت کنید نه چند A بگذارید).

۲) “A” مبهم یا بدون اختیار واقعی
گاهی A را می‌گذارند “ISMS” یا “IT” یا “مدیریت”، اما فرد مشخص و اختیار تصمیم روشن نیست. A باید یک نقش/سمت قابل انتساب باشد که واقعاً بتواند تأیید کند و منابع/اولویت را تعیین کند.

۳) همه را “R” می‌کنند
وقتی همه R باشند، یعنی هیچ‌کس مالک خروجی نیست. برای هر فعالیت معمولاً یک R اصلی دارید (گاهی دو R در فعالیت‌های بزرگ قابل قبول است، اما باید خروجی‌ها تفکیک شود).

۴) RACI را برای “سند” می‌نویسند، نه برای “فرآیند واقعی”
مثلاً برای Annex A یک RACI می‌نویسند ولی برای مدیریت دسترسی، رخداد، تامین‌کننده، CAPA و… که واقعاً در ممیزی و اجرا مهم است چیزی ندارند. RACI باید روی جریان‌های واقعی کار بنشیند.

۵) به‌روزرسانی نمی‌شود
با تغییر ساختار سازمان، Scope یا سرویس‌دهنده‌ها، RACI هم باید آپدیت شود. یک RACI قدیمی بدتر از نداشتن RACI است چون تصمیم‌گیری را گمراه می‌کند.

RACI پیشنهادی برای فرآیندهای اصلی ISMS

در این بخش، شما می‌توانید RACI را روی فرآیندهای اصلی که تقریباً در هر ISMS وجود دارد بچینید. نکته مهم این است که “فعالیت‌ها” را خیلی کلی ننویسید؛ هرچه فعالیت دقیق‌تر باشد، RACI واقعی‌تر و قابل اجرا‌تر می‌شود.

1) مدیریت ریسک

فعالیت‌های کلیدی که بهتر است برایشان RACI داشته باشید:

• تعریف روش و معیارهای ریسک (Risk Criteria)
• شناسایی ریسک‌ها و ثبت در رجیستر
• تحلیل/ارزیابی ریسک و تعیین سطح
• تصمیم درمان ریسک (کاهش/انتقال/پذیرش/اجتناب)
• تدوین برنامه درمان ریسک (RTP)
• بازنگری دوره‌ای ریسک‌ها و گزارش به کمیته

نکته اجرایی: A در تصمیم درمان ریسک‌های مهم باید Risk Owner/مدیریت باشد، نه صرفاً IT.

2) کنترل مستندات و تغییرات

• ایجاد/بازنگری سیاست‌ها و روش‌ها
• کنترل نسخه و دسترسی مستندات
• انتشار و ابلاغ
• مدیریت تغییرات اثرگذار (Change that affects risk)
• نگهداری سوابق و Evidence

نکته اجرایی: R معمولاً ISMS Manager است؛ ولی A می‌تواند Sponsor یا کمیته باشد برای اسناد کلیدی.

3) مدیریت رخداد

• تعریف معیار رخداد و کانال گزارش‌دهی
• ثبت، طبقه‌بندی و اولویت‌بندی
• پاسخ اولیه و کنترل آسیب
• تحلیل علت و درس‌آموخته‌ها
• تصمیم‌های اصلاحی و پیشگیرانه (CAPA مرتبط)
• گزارش به کمیته/مدیریت (برای رخدادهای Significant/Major)

نکته اجرایی: R در اجرا معمولاً Incident Manager/IT است؛ اما A برای رخدادهای بزرگ می‌تواند Sponsor/کمیته باشد.

4) مدیریت دسترسی‌ها (Joiner/Mover/Leaver)

• درخواست و تأیید دسترسی
• ایجاد/تغییر/حذف دسترسی
• بازبینی دوره‌ای دسترسی‌ها
• مدیریت دسترسی‌های ویژه (Privileged Access)
• ثبت لاگ و Evidence تغییرات

نکته اجرایی: A باید “مالک داده/سیستم” یا “مالک فرآیند” باشد، نه کسی که فقط اکانت را می‌سازد.

5) مدیریت تامین‌کنندگان

• دسته‌بندی تامین‌کنندگان (Risk-based)
• ارزیابی ریسک تامین‌کننده قبل از قرارداد
• بندهای امنیتی قرارداد و SLA
• پایش و بازنگری دوره‌ای تامین‌کننده
• مدیریت رخداد/نقض از سمت تامین‌کننده

نکته اجرایی: Procurement معمولاً R بخشی از کار است، اما A در پذیرش ریسک تامین‌کننده باید مشخص باشد.

6) آموزش و آگاهی

• تعیین نیازهای آموزشی بر اساس نقش‌ها
• اجرای آموزش و سنجش اثربخشی
• مدیریت Onboarding/Offboarding از منظر امنیت
• کمپین‌های آگاهی و یادآوری دوره‌ای
• نگهداری Evidence حضور/آزمون

نکته اجرایی: HR معمولاً R اجراست؛ ISMS/ISO معمولاً C برای محتوا و استانداردهاست.

7) ممیزی داخلی و بازنگری مدیریت

• برنامه ممیزی داخلی
• اجرای ممیزی و گزارش
• ثبت عدم انطباق/مشاهده
• جلسه بازنگری مدیریت (Management Review) و خروجی‌ها
• پیگیری تصمیم‌های بازنگری

نکته اجرایی: ممیز داخلی باید مستقل باشد؛ A در برنامه ممیزی معمولاً ISMS Manager یا Sponsor است.

8) مدیریت عدم انطباق و CAPA

• ثبت عدم انطباق و علت
• تعریف Correction و Corrective Action
• تعیین مالک اقدام و موعد
• بررسی اثربخشی و بستن مورد
• تحلیل موارد تکرارشونده و اصلاح سیستمی

نکته اجرایی: هر CAPA باید یک Owner واقعی داشته باشد؛ A برای بستن، معمولاً ISMS Manager/Owner فرآیند است.

9) مدیریت دارایی و طبقه‌بندی

• شناسایی دارایی‌ها و مالکیت
• طبقه‌بندی اطلاعات و برچسب‌گذاری
• قواعد نگهداری/انتقال/امحا
• بازنگری دوره‌ای دارایی‌ها
• کنترل دسترسی بر اساس طبقه‌بندی

نکته اجرایی: Asset Owner باید واقعی باشد (واحد کسب‌وکار/مالک داده)، نه صرفاً IT.

نمونه جدول RACI (قابل کپی در اکسل/ورد)

در این نمونه کوچک، نقش‌ها را مینیمال نگه می‌دارم تا برای اکثر سازمان‌ها قابل تطبیق باشد:

نقش‌ها (ستون‌ها):

• Sponsor (مدیریت/حامی)
• ISMS Manager
• Security/IT (مسئول امنیت/IT)
• Risk Owner (مالک ریسک/فرآیند)
• Control Owner (مالک کنترل)
• Internal Auditor

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

* درباره «R/A*» در درمان ریسک‌های High: در بسیاری از سازمان‌ها Risk Owner هم پیشنهاد درمان را می‌دهد (R) و هم پاسخگوی تصمیم است (A). اگر تصمیم نهایی باید سطح مدیریت باشد، A را به Sponsor بدهید و Risk Owner را R نگه دارید.

اگر فایل کامل RACI (برای 9 فرآیند اصلی + خردفعالیت‌ها + نسخه سازمان کوچک/متوسط/بزرگ) را می‌خواهی، از اینجا دانلود کن.

شرح وظایف نقش‌ها (Job Description) + KPI/شاخص‌های پیشنهادی

اینجا هدف ما این نیست که یک JD «کلی و تزئینی» بنویسیم. هدف این است که هر نقش در ISMS دقیقاً بداند چه خروجی‌هایی باید تحویل بدهد، چه اختیارهایی لازم دارد، با چه واحدهایی باید تعامل کند و در نهایت، ممیز از آن نقش چه Evidenceهایی می‌خواهد. اگر همین چهار لایه روشن شود، هم اجرا روان‌تر می‌شود، هم در Stage 1/Stage 2 ارائه شما منسجم و قابل دفاع خواهد بود.

الگوی استاندارد برای نوشتن شرح وظایف نقش‌های ISMS

برای هر نقش، این اسکلت را ثابت نگه دارید و فقط محتوا را متناسب با سازمان و Scope تنظیم کنید:

۱) هدف نقش (Role Purpose)
این نقش برای چه مسئله‌ای در ISMS ساخته شده؟ خروجی نهایی‌اش چه تغییری در سازمان ایجاد می‌کند؟

۲) مسئولیت‌های کلیدی (Key Responsibilities)
6 تا 10 مسئولیت قابل اجرا و قابل پیگیری. فعل‌محور بنویسید: «تضمین می‌کند…»، «هماهنگ می‌کند…»، «بازنگری می‌کند…».

۳) اختیارات/حدود تصمیم‌گیری (Authorities)
کجا حق تأیید دارد؟ چه چیزی را می‌تواند متوقف کند؟ چه چیزی را باید Escalate کند؟

۴) خروجی‌ها و تحویل‌دادنی‌ها (Deliverables)
مثلاً: گزارش ماهانه KPI، برنامه ممیزی، صورت‌جلسه کمیته، Risk Register به‌روز، Evidence کنترل‌ها.

۵) شاخص‌های عملکرد (KPIs/KRIs)
3 تا 5 شاخص که هم واقع‌بینانه باشد هم ممیزی‌پسند.

۶) تعاملات و وابستگی‌ها (Interfaces)
با چه نقش‌ها/واحدهایی، برای چه موضوعاتی.

۷) تناوب گزارش‌دهی (Reporting Cadence)
هفتگی/ماهانه/فصلی؛ به چه کسی و با چه قالبی.

نمونه شرح وظایف: ISMS Manager (مسئول سیستم مدیریت امنیت اطلاعات)

هدف نقش (Role Purpose)
ISMS Manager مسئول این است که سیستم مدیریت امنیت اطلاعات در سازمان «واقعاً قابل اجرا و قابل ممیزی» باشد؛ یعنی ریسک‌ها درست مدیریت شوند، کنترل‌ها مالک و شواهد داشته باشند، مستندات کنترل نسخه شوند، و ممیزی‌های داخلی/خارجی بدون پراکندگی و استرس پیش بروند. خروجی نهایی این نقش یک ISMS زنده است که بعد از گرفتن گواهی هم پایدار می‌ماند، نه یک پروژه مقطعی برای صدور گواهینامه.

گزارش‌دهی و جایگاه سازمانی (Reporting Line)
به‌صورت ایده‌آل به Sponsor/نماینده مدیریت ارشد گزارش می‌دهد و دسترسی مستقیم به کمیته امنیت اطلاعات دارد. برای اینکه نقش اثرگذار باشد، باید اختیار پیگیری بین واحدی و مطالبه Evidence را داشته باشد.

مسئولیت‌های کلیدی (Key Responsibilities)

1. طراحی و نگهداری نقشه راه ISMS: Scope، اهداف امنیتی، برنامه‌های اجرایی و اولویت‌ها را تدوین می‌کند و در طول سال به‌روزرسانی می‌کند.
2. هدایت مدیریت ریسک: معیارهای ریسک، روش ارزیابی، Risk Register و برنامه درمان ریسک (RTP) را مدیریت می‌کند و اطمینان می‌دهد برای ریسک‌های مهم تصمیم درمان/پذیرش مستند وجود دارد.
3. کنترل کیفیت SoA: Statement of Applicability را از حالت صوری خارج می‌کند؛ منطق انتخاب/عدم انتخاب کنترل‌ها را قابل دفاع می‌سازد و تغییرات را ردیابی و نسخه‌بندی می‌کند.
4. مدیریت مستندات و سوابق: سیاست‌ها، روش‌ها، دستورالعمل‌ها و Records را کنترل نسخه می‌کند؛ ابلاغ، دسترسی و نگهداری Evidence را استاندارد می‌کند تا چیزی پراکنده یا گم نشود.
5. هماهنگی اجرای کنترل‌ها با مالک‌ها: با Risk Ownerها و Control Ownerها کار می‌کند تا کنترل‌ها به‌صورت پایدار اجرا شوند، KPI داشته باشند و Evidence به‌روز تولید شود.
6. آماده‌سازی و مدیریت ممیزی‌ها: برنامه ممیزی داخلی را طراحی/هماهنگ می‌کند، ممیزی‌های خارجی (Stage 1/Stage 2 و مراقبتی) را آماده می‌کند، شواهد را جمع‌آوری/سازمان‌دهی می‌کند و پاسخ به یافته‌ها را مدیریت می‌کند.
7. مدیریت عدم انطباق و CAPA: عدم انطباق‌ها را ثبت و دسته‌بندی می‌کند، Root Cause را پیگیری می‌کند، اقدامات اصلاحی را تا «اثربخشی» دنبال می‌کند و از تکرار جلوگیری می‌کند.
8. مدیریت تغییرات اثرگذار بر ریسک: تغییرات مهم (سیستم، فرایند، تامین‌کننده، ساختار) را شناسایی می‌کند، الزام ارزیابی ریسک تغییر را جا می‌اندازد و کنترل‌های جبرانی را تا اجرا پیگیری می‌کند.
9. گزارش‌دهی مدیریتی و اداره جلسات حاکمیتی: داشبورد KPI/KRI را تهیه می‌کند، دستورجلسه کمیته را آماده می‌کند، مصوبات را ثبت می‌کند و تا بسته شدن پیگیری می‌کند.
10. راهبری آگاهی و آموزش: نیازهای آموزشی مبتنی بر نقش را با HR/واحدها هماهنگ می‌کند و Evidence اثربخشی (آزمون/مشارکت/کاهش خطاهای انسانی) را قابل ارائه نگه می‌دارد.

اختیارات و حدود تصمیم‌گیری (Authorities)

• حق دارد از واحدها و مالک‌های کنترل/ریسک، Evidence و گزارش پیشرفت مطالبه کند و در صورت توقف کار، موضوع را به Sponsor/کمیته Escalate کند.
• می‌تواند انتشار/بازنگری مستندات ISMS را در چارچوب سیاست‌ها مدیریت و تأیید کند (یا برای اسناد سطح بالا، برای تصویب به Sponsor/کمیته ارائه دهد).
• در صورت ناقص بودن شواهد حیاتی، می‌تواند اعلام آمادگی ممیزی را متوقف کند و گزارش رسمی ارائه دهد.

خروجی‌ها و تحویل‌دادنی‌های اصلی (Deliverables)

• Risk Register به‌روز + گزارش ریسک‌های High/Critical
• SoA نسخه‌بندی‌شده با منطق انتخاب کنترل‌ها
• برنامه ممیزی داخلی + گزارش‌های ممیزی
• CAPA Tracker + شواهد اثربخشی
• داشبورد KPI/KRI + گزارش مدیریتی دوره‌ای
• صورت‌جلسات کمیته امنیت اطلاعات + پیگیری مصوبات

KPI / شاخص‌های پیشنهادی (3–5 مورد واقع‌بینانه)

• درصد ریسک‌های High که تصمیم درمان/پذیرش مستند + تاریخ بازنگری معتبر دارند.
• درصد کنترل‌های کلیدی که Evidence کامل و به‌روز دارند (Evidence Coverage).
• درصد CAPAهای بسته‌شده در موعد + درصد موارد دارای Evidence اثربخشی.
• میزان تحقق برنامه ممیزی داخلی (Planned vs Completed).
• نرخ تکرار عدم انطباق‌های مشابه در دوره‌های متوالی (Recurrence Rate).

Evidenceهای رایج و ممیزی‌پسند (نمونه‌ها)

• سیاست‌ها/روش‌ها با کنترل نسخه و سوابق ابلاغ
• Risk Register، RTP، سوابق پذیرش ریسک با دلیل و شرط‌ها
• SoA و تاریخچه تغییرات
• برنامه ممیزی داخلی، چک‌لیست‌ها، گزارش‌ها، پیگیری‌ها
• CAPA با Root Cause، اقدام، شواهد اجرا، شواهد اثربخشی
• صورت‌جلسات کمیته + داشبورد KPI/KRI

تعاملات کلیدی (Interfaces)
با Sponsor و کمیته برای تصمیم‌های کلان، با IT/Security برای کنترل‌های فنی و رخدادها، با Risk Ownerها برای تصمیم درمان ریسک، با Control Ownerها برای Evidence و KPI کنترل‌ها، و با HR/Legal/Procurement (در صورت وجود در Scope) برای آموزش، الزامات قانونی و تامین‌کنندگان.

تناوب گزارش‌دهی پیشنهادی (Cadence)
گزارش KPI/KRI و وضعیت ریسک‌ها/اقدامات اصلاحی معمولاً ماهانه به کمیته و فصلی به مدیریت ارشد؛ در رخدادهای مهم یا تغییرات حساس، گزارش فوری و خارج از نوبت.

نمونه شرح وظایف: Risk Owner (مالک ریسک)

هدف نقش (Role Purpose)
Risk Owner کسی است که «مالکیت واقعی ریسک» را در حوزه خودش می‌پذیرد؛ یعنی ریسک‌ها فقط در فایل اکسل ثبت نمی‌شوند، بلکه برای هر ریسک مهم تصمیم مشخص گرفته می‌شود و سازمان می‌داند چه چیزی را کاهش می‌دهد، چه چیزی را منتقل می‌کند، و چه چیزی را (با دلیل) می‌پذیرد. خروجی این نقش باید قابل دفاع باشد: هم برای مدیریت و تصمیم‌گیری داخلی، هم برای ممیزی Stage 1 و Stage 2.

جایگاه و تعریف دامنه (Scope of Ownership)
مالک ریسک معمولاً مدیر یک فرآیند/واحد/سرویس در Scope است (مثل عملیات، مالی، فروش، فناوری، پشتیبانی، یا مالک یک سرویس کلیدی). دامنه مالکیت باید شفاف باشد: ریسک‌های مربوط به کدام فرآیندها، کدام دارایی‌ها، کدام سرویس‌ها و کدام تامین‌کنندگان.

مسئولیت‌های کلیدی (Key Responsibilities)

1. شناسایی ریسک‌ها در حوزه خود: ریسک‌های عملیاتی/فرآیندی/فنی/انسانی/تامین‌کننده‌ای را شناسایی می‌کند و برای ثبت در Risk Register با ISMS Manager همکاری می‌کند.
2. مشارکت فعال در ارزیابی ریسک: احتمال و اثر (Impact) را بر اساس واقعیت‌های کسب‌وکار و داده‌های حوزه خودش برآورد می‌کند؛ نه صرفاً بر اساس حدس یا عرف.
3. تصمیم درمان ریسک (Risk Treatment Decision): برای ریسک‌های حوزه خود تصمیم می‌گیرد که کاهش/انتقال/پذیرش/اجتناب انجام شود و منطق تصمیم را مستند می‌کند.
4. تأیید و مالکیت برنامه درمان ریسک (RTP): اقدام‌ها، مسئول اجرا (Control Owner/Owner اقدام)، منابع موردنیاز و موعدها را با واحدهای ذی‌ربط تعیین می‌کند و پیگیری می‌کند.
5. پذیرش رسمی ریسک (در صورت Accept): اگر ریسکی پذیرفته می‌شود، پذیرش را با دلیل، شرایط (کنترل جبرانی/محدودیت‌ها)، سطح پذیرش، و تاریخ بازنگری مشخص می‌کند و امضا/تأیید لازم را می‌گیرد.
6. پایش و بازنگری دوره‌ای ریسک‌ها: حداقل در چرخه‌های تعریف‌شده (مثلاً فصلی) یا بعد از تغییرات مهم/رخدادها، ریسک‌ها را بازنگری می‌کند تا تصمیم‌ها منقضی و قدیمی نشوند.
7. اطمینان از مالکیت کنترل‌ها و وجود Evidence: برای ریسک‌های مهم، بررسی می‌کند کنترل‌های منتخب (طبق SoA/RTP) مالک مشخص دارند و شواهد اجرای کنترل قابل ارائه است.
8. Escalation ریسک‌های High/Critical: ریسک‌های سطح بالا یا مواردی که خارج از اختیار حوزه است (بودجه/تصمیم کلان/تعارض بین واحدی) را به کمیته/مدیریت ارشد ارجاع می‌دهد.
9. مدیریت ریسک تغییر (Change Impact): وقتی تغییر مهمی در حوزه رخ می‌دهد (سیستم جدید، تامین‌کننده جدید، تغییر فرآیند)، ارزیابی اثر تغییر بر ریسک را انجام می‌دهد یا درخواست می‌کند انجام شود.
10. همکاری در واکنش به رخدادها: اگر رخداد امنیتی به حوزه او مرتبط است، در تحلیل علت، تصمیم‌های اصلاحی و جلوگیری از تکرار مشارکت می‌کند.

اختیارات و حدود تصمیم‌گیری (Authorities)

• اختیار پیشنهاد و تصویب درمان ریسک‌های حوزه خود در چارچوب سطح اختیارات تعریف‌شده سازمان.
• اختیار درخواست اجرای کنترل/اقدام اصلاحی از واحدهای مرتبط (در محدوده فرآیند/سرویس تحت مالکیت) و ارجاع موارد متوقف به Sponsor/کمیته.
• برای پذیرش ریسک‌های High معمولاً باید مسیر تصویب مشخص باشد (مثلاً تأیید Sponsor/کمیته)؛ اما Risk Owner همچنان مالک پاسخگویی است.

خروجی‌ها و تحویل‌دادنی‌ها (Deliverables)

• ثبت و نگهداری ریسک‌های حوزه در Risk Register (به‌روز و قابل ردیابی)
• تصمیم‌های درمان/پذیرش ریسک با منطق و تاریخ بازنگری
• برنامه درمان ریسک (RTP) حوزه + وضعیت پیشرفت اقدام‌ها
• گزارش دوره‌ای ریسک‌های High و موارد Escalate شده
• سوابق ارزیابی ریسک تغییرات مهم (Change Impact)

KPI / شاخص‌های پیشنهادی (3–5 مورد)

• درصد ریسک‌های حوزه که تصمیم درمان/پذیرش مستند و تاریخ بازنگری معتبر دارند.
• زمان متوسط از شناسایی ریسک تا تصمیم درمان (Risk Decision Lead Time).
• درصد اقدام‌های درمان ریسک انجام‌شده در موعد (RTP On-time Completion).
• تعداد ریسک‌های High حوزه که بدون مالک کنترل/بدون Evidence باقی مانده‌اند (هدف: نزدیک صفر).
• کاهش روند رخدادهای تکرارشونده مرتبط با ریسک‌های شناخته‌شده (Trend).

Evidenceهای رایج و ممیزی‌پسند (نمونه‌ها)

• Risk Register با ارجاع به دارایی/فرآیند/مالک و تاریخچه تغییرات
• فرم/ثبت پذیرش ریسک (با دلیل، سطح ریسک، شرایط، تاریخ بازنگری، تأییدات)
• RTP و شواهد پیشرفت (تسک‌ها، ایمیل تصمیم، صورت‌جلسه، خروجی فنی/فرآیندی)
• صورت‌جلسات کمیته یا تصمیم‌های مدیریتی درباره ریسک‌های مهم
• سوابق ارزیابی ریسک تغییرات (Change Assessment)
• تحلیل رخدادهای مرتبط و اقدامات اصلاحی جلوگیری از تکرار

تعاملات کلیدی (Interfaces)
با ISMS Manager برای ثبت و چرخه مدیریت ریسک، با Control Ownerها برای اجرای کنترل‌ها و Evidence، با IT/Security برای ریسک‌های فنی و رخدادها، و با Legal/Procurement/HR (در صورت ارتباط) برای تامین‌کنندگان، قراردادها و ریسک انسانی.

تناوب بازنگری و گزارش‌دهی (Cadence)
بازنگری ریسک‌ها حداقل فصلی (یا مطابق سیاست سازمان) و همچنین بعد از رخدادهای مهم یا تغییرات کلیدی. گزارش ریسک‌های High معمولاً در جلسات کمیته امنیت ارائه می‌شود و موارد بحرانی خارج از نوبت Escalate می‌شود.

نمونه شرح وظایف: Control Owner (مالک کنترل)

هدف نقش (Role Purpose)
Control Owner مسئول این است که یک یا چند کنترل منتخب ISMS (طبق SoA/RTP) «واقعاً اجرا شود، پایدار بماند، و Evidence قابل ارائه تولید کند». یعنی کنترل فقط روی کاغذ انتخاب نشده باشد؛ بلکه در عمل اجرا شود، قابل اندازه‌گیری باشد، انحراف‌هایش پیگیری شود و در ممیزی هم بتوانید با شواهد روشن نشان بدهید کنترل کار می‌کند.

جایگاه و دامنه کنترل (Control Scope)
دامنه این نقش دقیقاً به کنترل‌های مشخص (مثلاً کنترل‌های دسترسی، پشتیبان‌گیری، لاگ/مانیتورینگ، پچینگ، مدیریت تغییر، مدیریت تامین‌کننده، آموزش و آگاهی، طبقه‌بندی اطلاعات و…) محدود می‌شود. هر Control Owner باید بداند «مالک کدام کنترل‌هاست» و خروجی و Evidence هر کنترل کجاست.

مسئولیت‌های کلیدی (Key Responsibilities)

1. اجرای کنترل طبق تعریف مصوب: کنترل‌های تخصیص‌یافته را مطابق سیاست/روش اجرایی و استانداردهای داخلی اجرا می‌کند و از اجرای پایدار (نه مقطعی) مطمئن می‌شود.
2. تعریف بسته شواهد (Evidence Pack) برای هر کنترل: مشخص می‌کند برای این کنترل دقیقاً چه شواهدی لازم است، کجا نگهداری می‌شود، با چه تناوبی تولید می‌شود، و چه مدت باید حفظ شود.
3. تولید و نگهداری Evidence قابل ردیابی: شواهد را طوری نگهداری می‌کند که در ممیزی بتوان آن را به کنترل، تاریخ، سیستم/فرآیند و مسئول اجرا وصل کرد (traceable).
4. پایش کارایی کنترل با KPI/KRI: برای کنترل، شاخص‌های ساده و قابل سنجش تعریف/پایش می‌کند (مثلاً درصد تکمیل، نرخ انحراف، تعداد خطا، میزان تأخیر، نتایج تست).
5. مدیریت انحراف‌ها و عدم انطباق‌های مرتبط با کنترل: وقتی کنترل طبق انتظار اجرا نشده یا شواهد ناقص است، انحراف را ثبت می‌کند، علت را مشخص می‌کند و با ISMS Manager در CAPA همکاری می‌کند تا اصلاح و اثربخشی بسته شود.
6. بازنگری دوره‌ای کنترل و بهبود: حداقل طبق تناوب مشخص (مثلاً فصلی/شش‌ماهه) کنترل را بازنگری می‌کند، نقاط ضعف را پیدا می‌کند و پیشنهاد بهبود می‌دهد؛ به‌ویژه بعد از رخدادها یا تغییرات مهم.
7. هماهنگی با سایر واحدها در اجرای کنترل: اگر اجرای کنترل به همکاری واحدهای دیگر نیاز دارد (مثل HR، Procurement، Legal، عملیات)، هماهنگی لازم را انجام می‌دهد و اگر مانع جدی وجود داشت Escalate می‌کند.
8. آمادگی ممیزی (Audit Readiness): قبل از ممیزی داخلی/خارجی، Evidenceها را مرور می‌کند، نقص‌ها را می‌بندد و در جلسه ممیزی پاسخ‌گو و مستند صحبت می‌کند.
9. مدیریت تغییرات اثرگذار بر کنترل: اگر تغییرات فنی/فرآیندی روی کنترل اثر می‌گذارد (ابزار جدید، تغییر معماری، تغییر تامین‌کننده)، موضوع را ثبت می‌کند و از ارزیابی ریسک تغییر و کنترل‌های جبرانی مطمئن می‌شود.
10. هم‌راستا کردن کنترل با ریسک: مطمئن می‌شود کنترل واقعاً برای کاهش ریسک‌های تعریف‌شده کار می‌کند؛ اگر کنترل دیگر اثربخش نیست، پیشنهاد اصلاح/جایگزینی را ارائه می‌دهد.

اختیارات و حدود تصمیم‌گیری (Authorities)

• اختیار اجرای رویه‌ها/تنظیمات لازم برای کنترل در چارچوب سیاست‌ها و Change Management.
• اختیار درخواست همکاری/اطلاعات/شواهد از افراد و تیم‌های دخیل در اجرای کنترل (در دامنه کنترل).
• اختیار Escalation به ISMS Manager و در صورت نیاز کمیته/مدیریت، وقتی اجرای کنترل به مانع سازمانی/بودجه‌ای/فرآیندی می‌خورد.

خروجی‌ها و تحویل‌دادنی‌ها (Deliverables)

• Evidence Pack کنترل (لیست شواهد + مسیر نگهداری + نمونه‌ها)
• گزارش دوره‌ای KPI/KRI کنترل (ماهانه/فصلی)
• ثبت انحراف‌ها و اقدامات اصلاحی مرتبط با کنترل + شواهد اثربخشی
• سوابق بازنگری کنترل و پیشنهادهای بهبود
• گزارش آماده‌سازی ممیزی (در صورت نیاز) برای کنترل‌های حیاتی

KPI / شاخص‌های پیشنهادی (3–5 مورد)

• نرخ اجرای کنترل طبق تناوب تعیین‌شده (Control Compliance Rate).
• درصد Evidenceهای کامل، به‌روز و قابل ردیابی (Evidence Completeness/Traceability).
• زمان متوسط بستن انحراف/عدم انطباق کنترل (Deviation Closure Time).
• تعداد عدم انطباق‌های تکرارشونده مرتبط با همان کنترل (Recurrence).
• نتیجه تست‌های مرتبط با کنترل (مثلاً موفقیت Restore Test، تکمیل Access Review، درصد پچ‌های بحرانی نصب‌شده در SLA).

Evidenceهای رایج و ممیزی‌پسند (نمونه‌ها)
(نوع Evidence بسته به کنترل متفاوت است، اما الگو ثابت است)

• لاگ‌ها و گزارش‌های سیستمی (پچینگ، بکاپ، مانیتورینگ، آلارم‌ها، اسکن آسیب‌پذیری)
• خروجی‌های بازبینی دسترسی‌ها (لیست کاربران، تایید مالک، تاریخ و نتیجه)
• نتایج تست‌ها (Restore/DR/BCP test/Phishing simulation)
• چک‌لیست‌های انجام فعالیت با تاریخ/امضا/سیستم ثبت
• مستندات پیکربندی یا اسکرین‌شات‌های کنترل‌شده (با تاریخ و سیستم مشخص)
• سوابق تغییرات (Change tickets) و تاییدها
• شواهد آموزش/آگاهی (اگر کنترل آموزشی است): حضور، آزمون، گزارش اثربخشی

تعاملات کلیدی (Interfaces)
با ISMS Manager برای هم‌راستایی کنترل با SoA/RTP و آماده‌سازی ممیزی؛ با Risk Owner برای نشان دادن اثر کنترل روی ریسک؛ با IT/Security/Operations برای اجرا (اگر کنترل فنی است)؛ با HR/Procurement/Legal برای کنترل‌های انسانی و تامین‌کننده‌ای.

تناوب گزارش‌دهی پیشنهادی (Cadence)
برای کنترل‌های حیاتی، گزارش KPI/Evidence معمولاً ماهانه؛ برای کنترل‌های پایدارتر فصلی. در صورت رخداد Major یا تغییرات مهم، گزارش خارج از نوبت و اقدامات اصلاحی فوری.

نمونه شرح وظایف: Internal Auditor (ممیز داخلی ISMS)

هدف نقش (Role Purpose)
ممیز داخلی ISMS نقش «کنترل کیفیت مستقل» را دارد: با ممیزی مبتنی بر شواهد، مشخص می‌کند ISMS واقعاً مطابق الزامات ISO 27001 و الزامات داخلی سازمان اجرا شده یا فقط روی کاغذ کامل است. خروجی این نقش باید به شما کمک کند قبل از ممیزی خارجی Stage 1/Stage 2، نقاط ضعف واقعی را پیدا کنید، عدم انطباق‌ها را درست تعریف کنید، و مطمئن شوید اقدامات اصلاحی تا اثربخشی بسته می‌شود.

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

• استفاده از ممیز از واحد دیگر (Cross-audit)
• ممیزی مشترک با فرد مستقل داخلی + نظارت ISMS Manager
• برون‌سپاری ممیزی داخلی (برای حفظ استقلال و کیفیت)

گزارش‌دهی و جایگاه (Reporting Line)
به‌صورت حرفه‌ای، گزارش ممیزی داخلی باید به ISMS Manager و Sponsor/کمیته امنیت ارائه شود (نه فقط به واحد ممیزی‌شونده)، تا پیگیری و رفع موانع اجرایی امکان‌پذیر باشد.

مسئولیت‌های کلیدی (Key Responsibilities)

1. تدوین برنامه ممیزی داخلی بر مبنای ریسک
   برنامه ممیزی سالانه/شش‌ماهه را بر اساس اهمیت فرآیندها، سطح ریسک، تغییرات اخیر، رخدادها و نتایج ممیزی‌های قبلی تنظیم می‌کند (Risk-based Audit Program).
2. تعریف معیارها و دامنه ممیزی (Audit Criteria & Scope)
   معیارهای ممیزی را مشخص می‌کند: الزامات ISO 27001، سیاست‌ها و روش‌های داخلی، SoA و کنترل‌های منتخب، الزامات قانونی/قراردادی مرتبط با Scope.
3. آماده‌سازی چک‌لیست و روش نمونه‌برداری
   چک‌لیست ممیزی و روش نمونه‌برداری (Sampling) را طراحی می‌کند؛ طوری که ممیزی «فرم‌محور» نباشد و روی Evidence واقعی تمرکز کند.
4. اجرای ممیزی مبتنی بر شواهد (Evidence-based Auditing)
   مصاحبه، مشاهده و بررسی سوابق را انجام می‌دهد و یافته‌ها را با شواهد قابل ردیابی ثبت می‌کند (چه دیدیم؟ کجا؟ چه زمانی؟ با چه سند/لاگی؟).
5. ثبت و طبقه‌بندی یافته‌ها
   یافته‌ها را به شکل شفاف و قابل دفاع دسته‌بندی می‌کند:

• عدم انطباق (NC) وقتی الزام برآورده نشده یا Evidence کافی وجود ندارد
• مشاهده/Observation وقتی ضعف وجود دارد اما الزام هنوز نقض نشده
• فرصت بهبود (OFI) برای پیشنهادهای بلوغ و بهینه‌سازی
  (به‌همراه رفرنس معیار و شواهد)

6. تهیه گزارش ممیزی و ارائه رسمی به ذی‌نفعان
   گزارش را طوری می‌نویسد که هر یافته شامل: معیار، وضعیت، شواهد، ریسک/اثر، و توصیه سطح بالا برای مسیر اصلاح باشد. سپس جلسه اختتامیه برگزار می‌کند و توافق روی مسیر CAPA را تسهیل می‌کند.
7. پیگیری CAPA تا بسته شدن با Evidence اثربخشی
   فقط «انجام اقدام» کافی نیست؛ ممیز داخلی باید بررسی کند اقدام اصلاحی اثربخش بوده و احتمال تکرار کاهش یافته است. برای همین پیگیری می‌کند تا مورد بسته شود و Evidence اثربخشی وجود داشته باشد.
8. تحلیل ریشه‌ای روندها و موارد تکرارشونده
   در پایان هر چرخه، الگوها را استخراج می‌کند: عدم انطباق‌های تکراری، نقاط شکست سیستمی، کنترل‌های پرریسک، و پیشنهادهای اصلاح ساختاری را به ISMS Manager/کمیته ارائه می‌دهد.
9. حفظ بی‌طرفی، محرمانگی و صلاحیت حرفه‌ای
   محرمانگی اطلاعات ممیزی را رعایت می‌کند، تضاد منافع را اعلام می‌کند، و صلاحیت خود را با آموزش/به‌روزرسانی دانش حفظ می‌کند.

اختیارات و حدود تصمیم‌گیری (Authorities)

• دسترسی به اسناد، سوابق، سیستم‌ها (در چارچوب دسترسی مجاز) و افراد مرتبط برای جمع‌آوری شواهد.
• ثبت رسمی عدم انطباق/مشاهده و درخواست برنامه اقدام اصلاحی با موعد مشخص.
• امکان Escalation موارد High/بحرانی به ISMS Manager و در صورت نیاز کمیته/مدیریت.

خروجی‌ها و تحویل‌دادنی‌ها (Deliverables)

• برنامه ممیزی داخلی (Audit Program / Audit Plan)
• چک‌لیست‌ها و سوابق نمونه‌برداری
• گزارش ممیزی داخلی (NC/Observation/OFI با شواهد و معیار)
• لیست پیگیری CAPA + نتیجه بررسی اثربخشی
• گزارش روندها و درس‌آموخته‌ها برای بهبود سیستم

KPI / شاخص‌های پیشنهادی (3–5 مورد)

• درصد ممیزی‌های اجراشده طبق برنامه (Audit Plan Completion Rate).
• درصد عدم انطباق‌ها/اقدامات اصلاحی که در موعد بسته شده‌اند و Evidence اثربخشی دارند.
• نرخ تکرار عدم انطباق‌های مشابه در چرخه‌های متوالی (Recurrence Rate).
• کیفیت گزارش‌ها از نظر «کامل بودن معیار + شواهد + نتیجه» (بر اساس بازبینی ISMS Manager).
• کاهش تعداد/شدت NCهای ممیزی خارجی پس از اجرای چرخه ممیزی داخلی (Trend).

Evidenceهای رایج و ممیزی‌پسند (نمونه‌ها)

• برنامه ممیزی و اعلامیه ممیزی (Audit Notification)
• چک‌لیست‌های ممیزی + یادداشت‌های ممیزی (Working Papers)
• گزارش‌های ممیزی با ارجاع به شواهد (Ticket/Log/Record/Meeting minute)
• سوابق جلسه افتتاحیه/اختتامیه و توافق روی CAPA
• پیگیری CAPA و شواهد اثربخشی (Before/After Evidence)
• سوابق صلاحیت ممیز (آموزش‌ها، تجربه، گواهی‌ها) + ثبت استقلال/عدم تضاد منافع

تعاملات کلیدی (Interfaces)

• با ISMS Manager برای هماهنگی برنامه ممیزی، دسترسی به اطلاعات، و پیگیری CAPA
• با Control Ownerها و Risk Ownerها برای بررسی شواهد و اثربخشی کنترل‌ها
• با Sponsor/کمیته برای گزارش موارد High، روندها و موانع سیستمی
• با HR/IT/Legal/Procurement بسته به Scope، برای ممیزی فرآیندهای مرتبط

تناوب گزارش‌دهی پیشنهادی (Cadence)

• برنامه ممیزی: سالانه/شش‌ماهه (با بازنگری فصلی بر اساس ریسک)
• اجرای ممیزی‌ها: معمولاً ماهانه/دوماهه (بسته به اندازه سازمان)
• گزارش وضعیت CAPA و اثربخشی: ماهانه به ISMS Manager و فصلی به کمیته/مدیریت
• موارد بحرانی: Escalation فوری خارج از نوبت

مرزبندی نقش‌ها با واحدهای سازمانی (برای جلوگیری از اصطکاک)

وقتی ISO 27001 را پیاده‌سازی می‌کنید، بخش سخت کار معمولاً «نوشتن سیاست» نیست؛ سختی واقعی اینجاست که چند واحد مختلف باید روی یک موضوع مشترک هماهنگ شوند: امنیت اطلاعات، IT، منابع انسانی، حقوقی، تدارکات، عملیات، حتی فروش یا پشتیبانی. اگر از ابتدا مرز نقش‌ها روشن نباشد، دو اتفاق رایج می‌افتد: یا کارها بین واحدها پاسکاری می‌شود و هیچ‌کس پاسخگو نیست، یا یک واحد احساس می‌کند مسئولیت‌های اضافه به او تحمیل شده و مقاومت می‌کند. مرزبندی درست نقش‌ها دقیقاً برای همین ساخته می‌شود: کاهش اصطکاک، افزایش سرعت تصمیم‌گیری، و تولید Evidence قابل دفاع.

در مرزبندی نقش‌ها، اصل این است که هر واحد بداند «مالکِ چه چیزی است» و «مجریِ چه چیزی». معمولاً امنیت اطلاعات/ISMS مالک چارچوب و الزامات است (سیاست‌ها، ریسک، استانداردهای حداقلی، شاخص‌ها و پیگیری)، اما اجرای بسیاری از کنترل‌ها در واحدهای دیگر رخ می‌دهد. از طرف دیگر، واحدهای اجرایی (مثل IT یا HR) باید مطمئن باشند امنیت اطلاعات قرار نیست وارد جزئیات روزمره آن‌ها شود؛ امنیت می‌خواهد نتیجه قابل سنجش و شواهد قابل ارائه داشته باشد. بنابراین ما باید بین سه سطح تفکیک ایجاد کنیم: تصمیم‌گیری (A)، اجرا (R)، و شواهد/گزارش‌دهی (Evidence & Reporting).

یک مرزبندی عملی و ممیزی‌پسند معمولاً با این منطق کار می‌کند: امنیت اطلاعات استاندارد و ریسک را تعریف می‌کند و می‌گوید «چه سطحی از کنترل لازم است و چرا»؛ IT/عملیات می‌گوید «چطور اجرا کنیم که پایدار و قابل نگهداری باشد»؛ HR، حقوقی و تدارکات هم در نقاط حساس (آدم‌ها، قراردادها، تامین‌کنندگان) نقش اجرا و کنترل را بر عهده می‌گیرند. مهم‌تر از همه، مالک فرآیند یا مالک ریسک در کسب‌وکار باید جایی مشخص باشد که تصمیم‌های ریسکی را تأیید کند؛ چون بسیاری از تصمیم‌ها (مثل پذیرش ریسک یا استثناهای امنیتی) تصمیم‌های کسب‌وکاری هستند، نه صرفاً فنی.

امنیت اطلاعات vs فناوری اطلاعات (IT): مرزبندی نقش‌ها برای جلوگیری از اصطکاک

یکی از رایج‌ترین دلایل اصطکاک در پیاده‌سازی ISO 27001 این است که امنیت اطلاعات و IT در عمل «روی یک زمین مشترک» کار می‌کنند، اما مرز تصمیم‌گیری و مرز اجرا شفاف نیست. نتیجه‌اش هم معمولاً یکی از این دو حالت می‌شود: یا امنیت اطلاعات تبدیل می‌شود به یک واحد “پلیس‌گونه” که فقط ایراد می‌گیرد، یا IT زیر بار کنترل‌ها نمی‌رود چون احساس می‌کند امنیت «فقط سند می‌خواهد» و واقعیت فنی را نمی‌فهمد. راه درست این است که از روز اول روشن کنید: امنیت اطلاعات مالک سیاست، ریسک و الزامات است؛ IT مالک اجرای فنی و عملیات پایدار است—و هر دو در کنار هم Evidence تولید می‌کنند.

1) مالکیت امنیت اطلاعات دقیقاً چیست؟

امنیت اطلاعات (یا نقش‌های ISMS Manager/ISO/CISO بسته به ساختار شما) معمولاً مالک این حوزه‌هاست:

• چارچوب و قواعد بازی: سیاست‌های امنیت اطلاعات، استانداردها، روش‌های اجرایی امنیتی، الزامات حداقلی (Minimum Security Baseline).
• مدیریت ریسک و تصمیم‌سازی امنیتی: روش ارزیابی ریسک، معیارها، تحلیل ریسک، پیشنهاد درمان ریسک و کنترل‌های لازم، کنترل کیفیت SoA.
• حاکمیت و پاسخگویی: تعریف نقش‌ها و RACI، سازوکار کمیته امنیت، Escalation موارد High، پیگیری مصوبات.
• پایش اثربخشی کنترل‌ها (در سطح مدیریتی): تعریف KPI/KRI، رصد روندها، شناسایی انحراف‌های سیستمی، هدایت CAPA.
• آمادگی ممیزی و دفاع ممیزی‌پسند: اینکه هر کنترل چرا انتخاب شده، چطور به ریسک وصل است، و Evidenceها چطور قابل ردیابی‌اند.
• مدیریت رخداد در سطح فرآیندی و حاکمیتی: تعریف فرآیند Incident، معیار طبقه‌بندی رخداد، الزامات گزارش‌دهی، درس‌آموخته‌ها و جلوگیری از تکرار.
• آگاهی و فرهنگ امنیت: برنامه‌های آموزش/آگاهی، محتوا و سنجش اثربخشی (معمولاً با همکاری HR).

به زبان ساده: امنیت اطلاعات باید بتواند بگوید «چه سطحی از امنیت لازم است و چرا» و بعد تضمین کند این سطح واقعاً در سازمان پایدار می‌شود.

2) مالکیت IT دقیقاً چیست؟

IT معمولاً مالک این بخش‌هاست:

• پیاده‌سازی فنی کنترل‌ها: تنظیمات دسترسی، شبکه، فایروال، سیستم‌عامل، پچینگ، بکاپ، مانیتورینگ، لاگ، EDR/AV، سخت‌سازی (Hardening)، مدیریت تغییرات.
• عملیات و پایداری سرویس‌ها: نگهداری روزمره، رفع خرابی، ظرفیت، دسترس‌پذیری، SLA، مدیریت رخدادهای عملیاتی و بازیابی سرویس.
• انتخاب و اداره ابزارها: انتخاب راهکارهای فنی در چارچوب الزامات امنیتی (نه الزاماً انتخاب “هدف امنیتی”).
• تولید Evidence فنی: لاگ‌ها، گزارش‌ها، خروجی تست‌ها، تیکت‌ها، تغییرات ثبت‌شده، گزارش بکاپ/ریستور، نتایج اسکن آسیب‌پذیری.
• پاسخ فنی به رخداد: اقدامات فوری، ایزوله‌سازی، بازیابی، جمع‌آوری شواهد فنی (در هماهنگی با فرآیند Incident).

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

3) نقطه حساس: چه چیزهایی باید مشترک باشد؟

بعضی موضوعات ذاتاً مشترک‌اند و اگر برایشان “RACI واضح” نداشته باشید، سریعاً اصطکاک ایجاد می‌شود:

• دسترسی‌ها (Joiner/Mover/Leaver): امنیت سیاست و الزام را می‌دهد؛ IT اجرا و گزارش را می‌دهد؛ مالک داده/فرآیند تأیید نهایی دسترسی است.
• مدیریت لاگ و مانیتورینگ: امنیت می‌گوید چه لاگ‌هایی و چه مدت نگهداری شود و چه هشدارهایی مهم است؛ IT ابزار و عملیات و نگهداری را انجام می‌دهد.
• پچینگ و مدیریت آسیب‌پذیری: امنیت معیارها و SLAها را تعریف می‌کند (مثلاً بحرانی در X روز)؛ IT اجرا و گزارش و استثناها را مدیریت می‌کند.
• رخداد امنیتی: IT پاسخ فنی می‌دهد؛ امنیت مدیریت فرآیند، هماهنگی گزارش‌دهی، درس‌آموخته و CAPA را راهبری می‌کند.
• تغییرات مهم (Change): IT تغییر را اجرا می‌کند؛ امنیت ارزیابی ریسک تغییر و کنترل‌های جبرانی را الزام می‌کند.

4) یک مرزبندی عملی و ممیزی‌پسند (قاعده طلایی)

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

1. امنیت اطلاعات = استاندارد/الزام + ریسک + پاسخگویی
2. IT = اجرا + عملیات + شواهد فنی
3. کسب‌وکار/مالک فرآیند = تأیید نهایی برای ریسک و دسترسی‌ها

این یعنی امنیت نباید وارد تنظیمات جزئی فنی شود (مگر در نقش‌های تخصصی)، و IT هم نباید تصمیم‌های ریسکی و پذیرش ریسک را “خودسرانه” انجام دهد.

5) مثال‌های سریع برای روشن شدن مرزها (به درد اجرا می‌خورد)

• پچ بحرانی نصب نشده
  • امنیت: معیار و SLA و ریسک را تعیین می‌کند، انحراف را گزارش می‌کند.
  • IT: علت تأخیر را مشخص می‌کند، برنامه جبران می‌دهد، Evidence اجرا را ارائه می‌کند.
  • تصمیم استثنا/پذیرش ریسک: Risk Owner/Sponsor.
• لاگ‌های یک سرویس نگهداری نمی‌شود
  • امنیت: الزام نگهداری/دوره نگهداری و نیازهای ممیزی/تحقیق رخداد را مشخص می‌کند.
  • IT: تنظیمات و ذخیره‌سازی و مانیتورینگ را اجرا می‌کند و گزارش می‌دهد.
• دسترسی ادمین برای پیمانکار
  • امنیت: الزام کنترل دسترسی ویژه، ثبت و بازبینی را تعریف می‌کند.
  • IT: دسترسی را ایجاد می‌کند، زمان‌بندی حذف را تنظیم می‌کند، لاگ و Evidence را نگه می‌دارد.
  • مالک سیستم/فرآیند: تأیید نهایی و مسئولیت ریسک.

HR و چرخه کارکنان: نقش حیاتی در امنیت اطلاعات (از جذب تا خروج)

اگر ISMS را فقط به IT بسپارید، یک نقطه کور بزرگ باقی می‌ماند: ریسک انسانی. بسیاری از رخدادهای امنیتی—از افشای ناخواسته اطلاعات تا سوءاستفاده از دسترسی‌ها—ریشه‌اش در «فرآیندهای منابع انسانی» است، نه در فایروال و سرور. به همین دلیل در ISO 27001، HR فقط یک واحد پشتیبان نیست؛ HR یکی از بازیگران اصلی «کنترل‌های سازمانی» است که باید چرخه کامل کارکنان را به امنیت اطلاعات وصل کند: از لحظه جذب و ورود، تا تغییر نقش، و تا خروج.

در این مرزبندی، قاعده ساده است: امنیت اطلاعات تعریف می‌کند چه الزاماتی باید رعایت شود و چه شواهدی لازم است؛ HR فرآیندها را اجرا می‌کند و سوابق/شواهد را تولید و نگهداری می‌کند؛ IT عملیات دسترسی را انجام می‌دهد اما شروع/تایید و زمان‌بندی‌اش باید به چرخه HR متصل باشد.

1) آموزش و آگاهی (Security Awareness) — آموزش “قابل سنجش”، نه جلسه تشریفاتی

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

• آموزش بدو ورود (Onboarding) باید بخشی از فرآیند رسمی جذب باشد، نه یک فایل که اگر وقت شد خوانده شود.
• آموزش‌های دوره‌ای باید نقش‌محور باشد: کسی که به داده‌های حساس دسترسی دارد، آموزش و تعهد سخت‌گیرانه‌تری می‌خواهد.
• برای ممیزی، صرفِ «گفتن اینکه آموزش داده‌ایم» کافی نیست؛ باید Evidence داشته باشید: لیست شرکت‌کنندگان، تاریخ، محتوای آموزشی، و یک سنجش ساده از اثربخشی (کوییز کوتاه، آزمون، یا KPI مثل کاهش خطاهای تکرارشونده).

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

2) تعهدنامه‌ها و الزامات رفتاری — قرارداد روان و قابل اجرا، نه فقط امضا

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

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

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

3) خروج کارکنان (Offboarding) — نقطه‌ای که بیشترین ریسک نشت و سوءاستفاده رخ می‌دهد

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

مسئولیت‌های کلیدی HR در Offboarding:

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

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

4) کنترل دسترسی در خروج — «قطع فوری»، «بازبینی»، و «Evidence قابل دفاع»

اینجا دقیقاً جایی است که ISO 27001 از شما Evidence می‌خواهد. یک Offboarding خوب یعنی:

• قطع یا تعلیق دسترسی‌ها در زمان درست: ایمیل، VPN، ابزارهای ابری، CRM/ERP، دسترسی‌های ادمین، گروه‌ها و اشتراک‌ها.
• بازبینی دسترسی‌های ویژه: اگر فرد دسترسی privileged داشته، باید بررسی شود دسترسی‌های جانبی/توکن‌ها/کلیدهای API هم جمع شده‌اند.
• ثبت شواهد: شماره تیکت/فرم خروج، لیست سیستم‌هایی که دسترسی قطع شده، تاریخ و مسئول انجام، و تأیید نهایی.

پیشنهاد اجرایی برای کاهش خطا: یک چک‌لیست کوتاه Offboarding بسازید که شامل 10–15 مورد ثابت باشد و همیشه با همان قالب اجرا شود. این کار هم ریسک را کم می‌کند، هم برای ممیزی Evidence استاندارد تولید می‌کند.

5) مرزبندی دقیق بین HR، امنیت اطلاعات و IT (برای اینکه پاسکاری نشود)

برای اینکه این بخش واقعاً در سازمان اجرا شود، مرزها را این‌طور شفاف کنید:

• امنیت اطلاعات (ISMS): الزامات آموزشی و تعهدها را تعریف می‌کند، حداقل‌های Offboarding را مشخص می‌کند، KPI می‌دهد و اثربخشی را پایش می‌کند.
• HR: فرآیند را مالک است (Onboarding/Offboarding)، امضاها و سوابق را نگه می‌دارد، تیکت خروج را فعال می‌کند و تکمیل مراحل را پیگیری می‌کند.
• IT: قطع/تغییر دسترسی‌ها را انجام می‌دهد، گزارش و Evidence فنی ارائه می‌کند، و موارد خاص (ادمین/کلیدها/ابری) را با دقت مدیریت می‌کند.
• مالک فرآیند/مدیر مستقیم: تایید می‌کند چه دسترسی‌هایی لازم بوده/باید حذف شود و مسئولیت ریسک را در حوزه کسب‌وکار می‌پذیرد.

KPIهای پیشنهادی برای HR در ISMS (ساده و کاربردی)

برای اینکه این بخش قابل مدیریت باشد، چند شاخص سبک اما قوی تعریف کنید:

• درصد تکمیل آموزش امنیتی (بدون استثنا) در بازه زمانی مشخص.
• درصد کارکنان جدید که آموزش بدو ورود و تعهدنامه را قبل از دسترسی امضا کرده‌اند.
• میانگین زمان قطع دسترسی پس از خروج (هدف: نزدیک به صفر در خروج‌های قطعی).
• تعداد موارد خروج که چک‌لیست Offboarding ناقص مانده است.
• نرخ رخدادهای مرتبط با خطای انسانی (ترند کاهشی).

حقوقی و قراردادها: بندهای امنیتی، NDA و مدیریت ریسک تامین‌کننده

در بسیاری از سازمان‌ها، ریسک‌های جدی امنیت اطلاعات نه از داخل شبکه، بلکه از «قراردادها و روابط بیرونی» وارد می‌شود: پیمانکاران، سرویس‌های ابری، شرکت‌های پشتیبانی، تامین‌کنندگان نرم‌افزار، حتی شرکای تجاری که داده به آن‌ها می‌دهید یا از آن‌ها می‌گیرید. اینجاست که واحد حقوقی (Legal) نقش کلیدی پیدا می‌کند؛ چون بدون بندهای درست در قرارداد، شما عملاً ابزار اجرایی برای الزام امنیت ندارید و در رخداد واقعی، دست‌تان خالی می‌ماند. مرزبندی درست این است: امنیت اطلاعات الزام‌ها و ریسک را مشخص می‌کند؛ حقوقی آن را به “تعهد قراردادی قابل اجرا” تبدیل می‌کند؛ تدارکات/مالک خدمت هم مدیریت رابطه و اجرا را پیگیری می‌کند.

1) NDA و تعهد محرمانگی: چه زمانی، برای چه کسی، با چه دامنه‌ای؟

NDA فقط یک فرم امضا نیست؛ باید دقیقاً برای سناریوهای واقعی شما طراحی شود. حقوقی باید مطمئن شود:

• NDA برای کارکنان، پیمانکاران، فریلنسرها، مشاوران، تامین‌کنندگان و حتی بازدیدکنندگان حساس (در صورت نیاز) تعریف شده و قبل از دسترسی به اطلاعات امضا می‌شود.
• دامنه NDA مشخص باشد: «چه چیزی محرمانه است»، «چطور باید نگهداری شود»، «چه چیزهایی اجازه انتشار دارد/ندارد»، «مدت زمان تعهد بعد از قطع همکاری چقدر است».
• اگر با داده‌های شخصی یا داده‌های حساس کار می‌کنید، NDA باید با الزامات حریم خصوصی و قوانین مرتبط هم‌راستا باشد (صرفاً یک متن عمومی نباشد).

خروجی ممیزی‌پسند: نسخه کنترل‌شده NDA، فهرست افراد/تامین‌کنندگانی که امضا کرده‌اند، تاریخ امضا، و مسیر نگهداری سوابق.

2) بندهای امنیتی قرارداد (Security Clauses): چرا حیاتی‌اند؟

کنترل‌های تامین‌کننده در ISO 27001 زمانی واقعی می‌شود که شما بتوانید از تامین‌کننده مطالبه کنید: سطح امنیت، نحوه حفاظت از داده، پاسخ به رخداد، و حتی حق ممیزی. این مطالبه بدون قرارداد، عملاً توصیه است نه الزام.

بندهای کلیدی که حقوقی باید با امنیت اطلاعات هم‌راستا کند، معمولاً شامل این موارد است:

• تعریف داده و مالکیت: داده‌های شما متعلق به شماست؛ نحوه استفاده، نگهداری، و محدودیت‌های پردازش باید روشن باشد.
• الزامات امنیتی حداقلی: حداقل استانداردهای امنیتی (Access Control، رمزنگاری در انتقال/ذخیره، بکاپ، لاگ، پچینگ، سخت‌سازی) متناسب با ریسک و نوع خدمت.
• مدیریت دسترسی و اصل کمترین دسترسی: دسترسی تامین‌کننده باید محدود، زمان‌دار و قابل ردیابی باشد؛ دسترسی‌های ویژه باید کنترل‌شده باشد.
• مدیریت رخداد و اعلان (Incident Notification): تامین‌کننده موظف است رخدادهای مرتبط با داده/خدمت شما را در بازه زمانی مشخص اعلام کند و همکاری در پاسخ به رخداد داشته باشد.
• زیرپیمانکارها (Sub-processors/Subcontractors): تامین‌کننده بدون اجازه شما نباید داده را به زیرپیمانکار بدهد؛ یا باید فهرست و تعهدات زیرپیمانکارها شفاف باشد.
• حق ممیزی یا دریافت تضمین: یا حق ممیزی (در سطح مناسب)، یا دریافت گزارش‌های معتبر (مثلاً گزارش ممیزی، گواهی‌های مرتبط، یا ارزیابی امنیتی دوره‌ای).
• SLA و پیامدهای نقض: اگر الزام امنیتی نقض شد، پیامدها و مسئولیت‌ها مشخص باشد (اصلاح، جبران خسارت، حق فسخ، جریمه، محدودیت دسترسی).
• خروج و بازگردانی/امحای داده (Exit & Data Return/Deletion): در پایان قرارداد، داده‌ها چگونه برگردانده/حذف می‌شود و چه گواهی/شواهدی ارائه می‌شود.

نکته اجرایی: بندها را باید ریسک‌محور نوشت. یک تامین‌کننده کم‌ریسک (مثلاً خدمات عمومی بدون دسترسی به داده حساس) با یک تامین‌کننده‌ای که به اطلاعات مشتری و سیستم‌های داخلی دسترسی دارد، بندهای یکسان نمی‌خواهد.

3) مدیریت ریسک تامین‌کننده: نقش حقوقی در کنار امنیت و تدارکات

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

• از تامین‌کننده گزارش امنیتی یا شواهد بخواهید
• زمان پاسخ به رخداد را الزام کنید
• دسترسی‌ها را محدود و زمان‌دار کنید
• در پایان قرارداد حذف/بازگردانی داده را کنترل کنید

مدل اجرایی پیشنهاد‌شده (خیلی ساده):
برای تامین‌کنندگان High/Medium/Low یک سطح‌بندی داشته باشید و برای هر سطح، یک «پکیج بندهای امنیتی» آماده کنید. حقوقی این پکیج را در قرارداد جا می‌دهد و تدارکات آن را در فرآیند خرید/تمدید قرارداد enforce می‌کند.

4) مرزبندی نقش‌ها (Legal vs ISMS vs Procurement) در یک جمله قابل اجرا

• امنیت اطلاعات (ISMS): معیار ریسک تامین‌کننده و الزامات امنیتی را مشخص می‌کند + می‌گوید چه Evidenceهایی لازم است.
• حقوقی (Legal): الزامات را تبدیل به بند قراردادی قابل اجرا می‌کند + پیامدهای نقض و حق پیگیری را شفاف می‌کند.
• تدارکات/مالک خدمت (Procurement/Service Owner): انتخاب تامین‌کننده، اجرای فرآیند ارزیابی، پیگیری تعهدات در طول قرارداد، و مدیریت تمدید/فسخ.

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

5) KPIهای ساده و کاربردی برای کنترل قراردادها و تامین‌کننده‌ها

برای اینکه این بخش قابل مدیریت باشد، چند شاخص سبک اما اثرگذار تعریف کنید:

• درصد تامین‌کنندگان High-risk که قراردادشان بندهای امنیتی استاندارد و به‌روز دارد.
• درصد تامین‌کنندگان High-risk که ارزیابی اولیه و بازنگری دوره‌ای را پاس کرده‌اند.
• زمان متوسط اعلان رخداد توسط تامین‌کننده (در رخدادهای واقعی/تمرینی).
• درصد قراردادهایی که بند Exit & Data Deletion/Return و Evidence دارند.
• تعداد استثناهای امنیتی قراردادی که بدون پذیرش ریسک رسمی ثبت شده‌اند (هدف: نزدیک صفر).

حداقل مستندات و Evidenceهای لازم که ممیز واقعاً دنبالشان می‌گردد

اگر بخواهیم خیلی واقع‌بینانه نگاه کنیم، ممیز ISO 27001 معمولاً دنبال «حجم سند» نیست؛ دنبال این است که بفهمد ISMS شما مدیریت می‌شود یا فقط مستندسازی شده. یعنی آیا نقش‌ها و تصمیم‌ها واقعی‌اند، آیا ریسک‌ها مالک دارند، آیا کنترل‌ها Evidence دارند، و آیا چرخه بهبود (ممیزی داخلی و CAPA) کار می‌کند. برای همین، در حاکمیت ISMS یک سری Evidence حداقلی وجود دارد که اگر درست و منظم ارائه شود، بخش بزرگی از نگرانی ممیزی از بین می‌رود—حتی اگر سازمان کوچک باشد.

1) صورت‌جلسه کمیته امنیت اطلاعات (Committee Minutes) — Evidence تصمیم‌گیری

ممیز با صورت‌جلسه می‌فهمد “Governance” شما واقعی است یا نه. صورت‌جلسه باید نشان بدهد تصمیم‌ها کجا گرفته می‌شود و پیگیری دارد. حداقل چیزهایی که در صورت‌جلسه لازم است:

• تاریخ/زمان جلسه و فهرست حاضرین با نقش‌ها
• دستورجلسه (ریسک‌های مهم، رخدادها، KPIها، CAPAها، تغییرات مهم)
• مصوبات شفاف: تصمیم چه بود، چرا گرفته شد، مالک پیگیری کیست، موعد چه زمانی است
• برای ریسک‌های High: تصمیم درمان/پذیرش + تاریخ بازنگری
• پیگیری مصوبات جلسه قبل (Done/On Track/Blocked)

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

2) ماتریس RACI تأییدشده — Evidence شفافیت مسئولیت‌ها

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

• RACI فقط برای Annex A نباشد؛ برای فرآیندهای واقعی مثل Risk, Access, Incident, Supplier, CAPA, Audit وجود داشته باشد
• برای هر فعالیت یک A مشخص باشد و حداقل یک R وجود داشته باشد
• نسخه و تاریخ داشته باشد و مشخص باشد “تأیید شده” است (بایگانی/امضا/مصوبه)

نکته اجرایی: اگر سازمان کوچک است، RACI را ساده نگه دارید اما واقعی؛ ممیز با «واقعی بودن» قانع می‌شود نه با پیچیدگی.

3) انتصاب رسمی نقش‌ها (Letter / Appointment) — Evidence اینکه نقش‌ها روی کاغذ نیستند

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

• نامه/ابلاغ رسمی برای ISMS Manager و نقش‌های کلیدی (مثل Incident Owner، Internal Auditor، Risk Ownerها در حوزه‌های اصلی)
• مشخص بودن دامنه مسئولیت (Scope of responsibility)
• تاریخ شروع و مرجع تأیید (مدیریت/کمیته)
• اگر نقش‌ها تجمیع شده‌اند، همان‌جا شفاف شود تا تضاد منافع ایجاد نکند (مثلاً ممیز داخلی نباید مجری کنترل باشد)

نکته اجرایی: انتصاب رسمی حتی اگر یک صفحه باشد، در ممیزی اثر زیادی دارد چون “Authority” را نشان می‌دهد.

4) برنامه ممیزی داخلی + گزارش‌ها — Evidence اینکه سیستم خودش را کنترل می‌کند

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

• برنامه ممیزی داخلی (سالانه/شش‌ماهه) ترجیحاً ریسک‌محور
• گزارش ممیزی داخلی (حتی اگر کوتاه) شامل معیار، شواهد، یافته‌ها (NC/Observation/OFI)
• پیگیری عدم انطباق‌ها تا بسته شدن (بهتر است با CAPA Tracker)

نکته اجرایی: “گزارش ممیزی داخلی بدون پیگیری” برای ممیز خارجی خیلی کم‌ارزش است؛ او دنبال چرخه کامل است.

5) شواهد KPIها و گزارش‌دهی‌ها — Evidence اینکه کنترل‌ها پایش می‌شوند

ممیز نمی‌خواهد شما 50 KPI داشته باشید؛ می‌خواهد چند KPI کلیدی داشته باشید که واقعاً پایش می‌شود. حداقل شواهد:

• یک داشبورد ساده (ماهانه/فصلی) با 5 تا 10 KPI/KRI مرتبط با Scope
• نمونه گزارش‌های دوره‌ای (حداقل 2 دوره اگر زمان داشته‌اید)
• تصمیم/اقدام در پاسخ به KPIهای بد (مثلاً اقدام اصلاحی، تغییر اولویت، Escalation)

نمونه KPIهای ممیزی‌پسند (ساده و رایج): درصد تکمیل آموزش، وضعیت پچینگ بحرانی، نتیجه تست Restore، درصد تکمیل بازبینی دسترسی‌ها، تعداد رخدادها و زمان پاسخ، وضعیت CAPAهای باز.

6) ریسک‌ها با مالک مشخص و تصمیم درمان ریسک — Evidence قلب ISMS

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

• دارایی/فرآیند مرتبط، تهدید/آسیب‌پذیری، اثر و احتمال
• Risk Owner مشخص
• تصمیم درمان ریسک (Reduce/Transfer/Avoid/Accept) با منطق
• اگر Accept: پذیرش ریسک با تاریخ بازنگری و مرجع تأیید
• لینک شدن به کنترل‌ها/SoA یا RTP (که نشان بدهد تصمیم تبدیل به اقدام شده)

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

اشتباهات رایج در حاکمیت ISMS و نسخه اصلاح سریع

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

1) نقش‌ها روی کاغذ هستند ولی اختیار ندارند

نشانه‌ها
شما ISMS Manager دارید، Risk Owner دارید، Control Owner هم تعیین شده… اما هر وقت تصمیم مهمی لازم است (بودجه، اولویت، توقف یک استثنا، الزام به انجام یک کنترل)، همه چیز متوقف می‌شود. افراد از نظر عنوان “مسئول” هستند، اما در عمل نمی‌توانند چیزی را جلو ببرند. این دقیقاً همان جایی است که ممیز هم با چند سؤال ساده متوجه می‌شود نقش‌ها واقعی نیستند: «اگر واحد X همکاری نکرد، چه کسی اختیار دارد تصمیم بگیرد؟ مسیر Escalation چیست؟»

چرا خطرناک است؟
چون ISMS تبدیل می‌شود به “هماهنگی بی‌پایان” و همه چیز به روابط شخصی و خواهش وابسته می‌شود. در ممیزی هم معمولاً به شکل “عدم اثربخشی” یا Evidence ناقص خودش را نشان می‌دهد.

نسخه اصلاح سریع

• برای نقش‌های کلیدی (ISMS Manager، Risk Ownerهای اصلی، Internal Auditor، Owner رخداد) یک ابلاغ رسمی ۱ صفحه‌ای داشته باشید که «دامنه اختیار» را شفاف کند: حق مطالبه Evidence، حق Escalation، و اینکه چه تصمیم‌هایی باید به کمیته برود.
• یک مسیر Escalation دو مرحله‌ای تعریف کنید: (۱) ISMS Manager → (۲) Sponsor/کمیته. مهم است این مسیر روی کاغذ باشد و در صورت‌جلسه‌ها هم نمونه استفاده از آن دیده شود.
• اختیار را با یک جمله ساده قابل اجرا کنید: «در صورت عدم همکاری واحدها در ارائه Evidence یا اجرای کنترل‌های High، ISMS Manager مجاز است موضوع را برای تصمیم‌گیری به کمیته ارجاع دهد.»

2) کمیته تشکیل می‌شود ولی خروجی تصمیمی ندارد

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

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

نسخه اصلاح سریع

• هر جلسه را با یک Decision Log ببندید: حداقل 3 ستون ثابت داشته باشد: مصوبه/تصمیم، مالک، موعد (و ترجیحاً Evidence مورد انتظار).
• دستورجلسه را کوتاه و تصمیم‌محور نگه دارید: ریسک‌های High، رخدادهای مهم، CAPAهای متوقف، تغییرات کلان، و شاخص‌های کلیدی. هر چیزی که «تصمیم نمی‌خواهد» بهتر است خارج از جلسه و به‌صورت گزارش کتبی باشد.
• یک قانون ساده بگذارید: «هر جلسه باید حداقل 2–5 مصوبه اجرایی داشته باشد.» اگر ندارد، یعنی جلسه موضوع درست نداشته یا باید شکلش عوض شود.

3) RACI هست ولی با فرآیندها هم‌راستا نیست

نشانه‌ها
یک فایل RACI دارید که پر از R/A/C/I است، اما وقتی وارد اجرای واقعی می‌شوید (مثلاً Offboarding، دسترسی ادمین، رخداد، پچ بحرانی، تامین‌کننده)، همان پاسکاری قدیمی تکرار می‌شود. چون RACI روی فعالیت‌های واقعی و حساس ننشسته یا نقش‌ها با ساختار سازمانی شما تطابق ندارد.

چرا خطرناک است؟
چون RACI اگر واقعی نباشد، بدتر از نبودنش است: حس “همه چیز مشخص است” می‌دهد، اما در عمل تصمیم‌گیری را گمراه می‌کند و باعث تاخیر می‌شود.

نسخه اصلاح سریع

• RACI را به‌جای Annex A، روی ۸–۱۰ فرآیند واقعی و ممیزی‌محور بنویسید: Risk، Incident، Access (JML)، Supplier، Change، Backup/Restore، Internal Audit، CAPA، Document Control.
• برای هر فعالیت فقط یک A تعریف کنید و A را به کسی بدهید که واقعاً اختیار دارد (نه نقش‌های مبهم).
• RACI را با یک تست سریع اعتبارسنجی کنید: «برای هر فعالیت، اگر کار انجام نشد، چه کسی پاسخگوست؟» اگر جوابش واضح نیست، RACI هنوز واقعی نشده.

4) مالک ریسک مشخص نیست یا پذیرش ریسک بدون شواهد است

نشانه‌ها
Risk Register دارید ولی Risk Ownerها کلی هستند (“IT”، “سازمان”، “مدیریت”). یا پذیرش ریسک انجام شده اما معلوم نیست چه کسی پذیرفته، چرا پذیرفته، تا چه زمانی پذیرفته، و با چه شرط‌هایی. این یکی از سریع‌ترین جاهایی است که ممیز به “صوری بودن” شک می‌کند.

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

نسخه اصلاح سریع

• برای ریسک‌های Medium/High حتماً Risk Owner واقعی تعیین کنید (یک سمت/نقش مشخص، نه عنوان کلی).
• پذیرش ریسک را یک صفحه‌ای کنید اما کامل: سطح ریسک، دلیل پذیرش، کنترل‌های جبرانی (اگر هست)، تاریخ بازنگری، مرجع تأیید، و شرایطی که پذیرش باطل می‌شود (مثلاً تغییر سرویس/تغییر تامین‌کننده/رخداد).
• هر پذیرش ریسک باید یک Evidence داشته باشد: صورت‌جلسه کمیته/ایمیل رسمی/فرم امضا شده. مهم نیست قالب چیست؛ مهم این است که قابل ردیابی و قابل دفاع باشد.