تجزیه‌وتحلیل شکاف ISO 27001 چیست و چطور درست انجامش بدهیم؟ (نسخه 2022)

اگر قصد داری برای ISO/IEC 27001:2022 اقدام کنی، قبل از هر چیزی باید یک سؤال را صادقانه جواب بدهی: «واقعاً الان کجای کاریم؟» خیلی از پروژه‌ها از همین‌جا ضربه می‌خورند؛ چون سازمان وارد مسیر پیاده‌سازی یا حتی ممیزی می‌شود، اما تازه وسط راه مشخص می‌شود بعضی کنترل‌ها فقط روی کاغذ هستند، شواهد کافی وجود ندارد، یا Scope و ریسک‌ها قابل دفاع نیستند.

تحلیل شکاف (Gap Analysis) دقیقاً برای همین است: یک تصویر شفاف و قابل‌اتکا از فاصله‌ی وضعیت فعلی شما تا الزامات استاندارد—هم در بندهای ۴ تا ۱۰ و هم در کنترل‌های Annex A نسخه 2022—و مهم‌تر از آن، تبدیل این تصویر به یک نقشه‌راه اجرایی با اولویت‌بندی، مسئول مشخص و زمان‌بندی واقعی؛ طوری که هم دوباره‌کاری و هزینه‌های پنهان کم شود، هم احتمال عدم انطباق در ممیزی به حداقل برسد.

تجزیه‌وتحلیل شکاف ISO 27001 در یک نگاه

تحلیل شکاف دقیقاً چه مشکلی را حل می‌کند؟

اگر همین امروز تصمیم بگیری برای ISO 27001 اقدام کنی، بزرگ‌ترین ریسک این است که «فکر کنی آماده‌ای» ولی در ممیزی (یا حتی قبل‌تر، هنگام جمع‌آوری شواهد) بفهمی بخش‌هایی از ISMS فقط روی کاغذ وجود دارند. تحلیل شکاف دقیقاً برای همین ساخته شده: اینکه خیلی سریع و قابل‌اتکا مشخص کند فاصله‌ی وضعیت فعلی سازمان تو با الزامات ISO/IEC 27001:2022 چقدر است و این فاصله دقیقاً کجاهاست.

مطالعه پیشنهادی: ISO 27001 دقیقاً چیست و به چه سازمانی می‌خورد؟

به زبان ساده، تحلیل شکاف سه سؤال را بدون تعارف جواب می‌دهد:

1. الان چه چیزهایی داریم که واقعاً اجرا می‌شود و «شواهد» دارد؟
2. چه چیزهایی نداریم یا ناقص است (سیاست‌ها، روش‌ها، کنترل‌ها، رکوردها)؟
3. برای رسیدن به سطح قابل‌قبول ممیزی، دقیقاً چه اقدام‌هایی باید انجام شود و اولویت‌شان چیست؟

پس اگر نمی‌خواهی پروژه‌ات تبدیل شود به یک سری فایل و فرم صوری، یا وسط کار با موج عدم انطباق‌ها (NCR) و دوباره‌کاری‌ها درگیر شوی، Gap Analysis مسیر را از همان اول شفاف می‌کند؛ هم برای مدیرعامل/مدیریت تصمیم‌گیر، هم برای تیم IT و امنیت، هم برای واحدهایی مثل منابع انسانی، حقوقی و عملیات.

خروجی نهایی شما چیست؟ (گزارش شکاف + برنامه اقدام + اولویت‌بندی)

تحلیل شکاف خوب «لیست ایرادها» نیست؛ یک بسته خروجی اجرایی است که بتوانی با آن پروژه را مدیریت کنی و جلو ببری. خروجی نهایی معمولاً این سه بخش را باید داشته باشد:

1) گزارش تحلیل شکاف (Gap Report)
در این گزارش، وضعیت شما نسبت به دو محور اصلی سنجیده می‌شود:

• الزامات بندهای 4 تا 10 استاندارد (Context، Leadership، Planning، Support، Operation، Performance Evaluation، Improvement)
• کنترل‌های Annex A در نسخه 2022 (کنترل‌های سازمانی، انسانی، فیزیکی، فناورانه)
  برای هر بند/کنترل باید مشخص باشد: وضعیت فعلی چیست، چه مدرکی وجود دارد، شکاف دقیقاً کجاست و ریسک آن چیست.

مطالعه پیشنهادی: جدول کنترل‌های Annex A (نسخه 2022)

2) برنامه اقدام (Action Plan / Roadmap)
اینجا تبدیل می‌شود به کار عملی: برای هر شکاف، اقدام اصلاحی/تکمیلی تعریف می‌شود با:

• مالک اقدام (Owner)
• زمان‌بندی (Due Date)
• منابع/ابزار لازم
• خروجی قابل تحویل (Deliverable)
• معیار بستن اقدام (Done Criteria)
  بدون این بخش، تحلیل شکاف نهایتاً تبدیل می‌شود به یک فایل تزئینی.

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

• کدام شکاف‌ها «ریسکی/حیاتی» هستند و باید فوری بسته شوند
• کدام‌ها می‌تواند در فاز بعدی تکمیل شود
• کدام‌ها وابسته به تصمیم مدیریتی است (Scope، پذیرش ریسک، منابع، برون‌سپاری)
  این اولویت‌بندی معمولاً بر اساس ریسک، اثر کسب‌وکار، الزامات قانونی/قراردادی و میزان آمادگی برای ممیزی انجام می‌شود.

چه زمانی انجامش بدهیم؟ (قبل از شروع ISMS / قبل از Stage 1 / قبل از Stage 2)

زمان انجام Gap Analysis بستگی به وضعیت فعلی تو دارد، ولی سه سناریوی رایج دارد:

سناریو 1: قبل از شروع ISMS (بهترین حالت برای شروع درست)
اگر هنوز ISMS را جدی شروع نکرده‌ای یا مطمئن نیستی Scope و دارایی‌ها و ریسک‌ها درست تعریف شده‌اند، تحلیل شکاف در این مرحله کمک می‌کند پروژه را از همان روز اول درست بچینی: مرزها مشخص، نقش‌ها روشن، اولویت‌ها واقعی.

سناریو 2: قبل از Stage 1 (برای جلوگیری از ورود به ممیزی با دست خالی)
Stage 1 بیشتر روی «آمادگی مستنداتی و طراحی سیستم» می‌چرخد. اگر قبل از Stage 1 تحلیل شکاف انجام شود، معمولاً جلوی این اتفاق را می‌گیرد که در Stage 1 با کمبودهای پایه‌ای (مثل Scope غیرقابل دفاع، ریسک‌متد نامشخص، SoA ضعیف، نبود شواهد کلیدی) زمین بخوری.

سناریو 3: قبل از Stage 2 (وقتی ISMS دارید ولی می‌خواهید ریسک NCR را کم کنید)
Stage 2 جایی است که ممیز دنبال «اجرا و شواهد واقعی» می‌گردد. اگر ISMS را پیاده کرده‌ای ولی مطمئن نیستی کنترل‌ها واقعاً Evidence دارند، تحلیل شکاف نزدیک Stage 2 مثل یک تست فشار عمل می‌کند: نشان می‌دهد کدام کنترل‌ها اجرا شده‌اند، کدام‌ها فقط نوشته شده‌اند، و چه چیزهایی باید قبل از ممیزی تکمیل شود.

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

ISO 27001:2022 چه تغییری کرده و چرا روی تحلیل شکاف اثر می‌گذارد؟

تفاوت‌های کلیدی 2013 با 2022 (بدون حاشیه، کاربردی)

نسخه 2022 در اصل «ماهیت ISMS» را از نو اختراع نکرده؛ چارچوب مدیریتی همان است، اما متن استاندارد با ساختار هماهنگ استانداردهای سیستم مدیریتی (Harmonized Structure) هم‌راستا شده و چند به‌روزرسانی کوچک اما مهم در بندها آمده که روی ارزیابی شکاف اثر می‌گذارد—به‌خصوص جاهایی که درباره برنامه‌ریزی تغییرات، بازبینی‌ها و کنترل اجرای برنامه‌ها صحبت می‌کند.

مطالعه پیشنهادی: متن ISO 27001:2022 (دانلود/مطالعه)

تغییر بزرگ اما جایی است که اکثر سازمان‌ها ضربه می‌خورند: Annex A. چون اگر هنوز با ذهنیت 2013 جلو بروی، هم در گزارش شکاف دچار خطای شمارش/طبقه‌بندی کنترل‌ها می‌شوی، هم در SoA و جمع‌آوری Evidence سردرگم می‌مانی. ضمن اینکه استاندارد 2022 در 25 اکتبر 2022 منتشر شد و مهلت انتقال 31 اکتبر 2025 بود؛ یعنی امروز (5 فوریه 2026) عملاً هر مسیر ممیزی معتبر باید روی 2022 بسته شود و گواهی‌های 2013 در صورت انتقال‌ندادن می‌تواند نامعتبر تلقی شود.

Annex A در 2022: دسته‌بندی‌های جدید و منطق پوشش کنترل‌ها

در 2013 کنترل‌ها 114 تا و در 14 دامنه چیده شده بودند. در 2022 کنترل‌ها 93 تا شده‌اند و به 4 دسته ساده‌تر تقسیم شده‌اند: سازمانی (Organizational)، افراد (People)، فیزیکی (Physical) و فناورانه (Technological). این تغییر فقط «کم‌شدن عدد» نیست؛ برای تحلیل شکاف یعنی باید نگاهت از “چند کنترل داریم؟” برود به سمت “این کنترل‌ها در عمل کدام ریسک را پوشش می‌دهند و شواهدش چیست؟”.

یک نکته کاربردی دیگر: در Annex A 2022 عنوان و چینش هم تغییر کرده و «اهداف کنترلیِ هر گروه» که قبلاً کنار دامنه‌ها بود، حذف شده است. نتیجه‌اش در Gap Analysis روشن است: باید برای هر کنترل، Evidence را دقیق‌تر و مستقیم‌تر به “الزام/کنترل” وصل کنی، نه اینکه با چند جمله کلی از زیرش رد شوی.

و اگر بخواهی تحلیل شکاف را حرفه‌ای‌تر ببندی (خصوصاً وقتی می‌خواهی گزارش را برای مدیریت/ممیز قابل دفاع کنی)، ISO 27002:2022 برای هر کنترل «Attribute» هم تعریف کرده (مثل نوع کنترل، ویژگی‌های CIA، مفاهیم سایبری و…)، که کمک می‌کند شکاف‌ها را از چند زاویه دسته‌بندی و اولویت‌بندی کنی.

مطالعه پیشنهادی: ISO 27002:2022 و منطق کنترل‌ها / ISO 27002 چه کمکی به پیاده‌سازی کنترل‌های 27001 می‌کند؟

اگر مستندات قدیمی دارید، از کجا شروع کنید؟

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

اول، وضعیتت را شفاف کن: آیا فقط مستندات داخلی داری، یا گواهی 2013 هم داشته‌ای؟ چون بعد از پایان مهلت انتقال (31 Oct 2025)، بسیاری از CBها برای برگشت به وضعیت معتبر، مسیر ممیزی انتقال/یا حتی ممیزی کامل را مطرح می‌کنند.

بعد، SoA قدیمی را تبدیل به «نقشه تطبیق» کن: کنترل‌های 2013 را به کنترل‌های 2022 مپ کن (خیلی‌ها ادغام/بازچینش شده‌اند). این کار باعث می‌شود در گزارش شکاف دقیقاً مشخص باشد کدام کنترل واقعاً پوشش داده شده، کدام “ادغام‌شده ولی Evidence ندارد” و کدام “جدید/تقویت‌شده” است و باید برایش اقدام تعریف شود.

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

1. SoA 2022 قابل دفاع (با دلیل انتخاب/عدم انتخاب و لینک به ریسک‌ها)
2. Evidence واقعی برای کنترل‌های کلیدی (نه صرفاً Policy و Procedure)
3. برنامه اقدام اولویت‌بندی‌شده که شکاف‌ها را به کار اجرایی تبدیل کند (مالک/زمان/Deliverable).

مثال‌های خیلی ملموس از «شکاف‌های رایج» وقتی از 2013 به 2022 می‌آیید

1. کنترل‌ها روی کاغذ هست، اما Evidence اجرایی ندارند (خصوصاً برای Annex A)
   خیلی وقت‌ها سازمان Policy و Procedure دارد، حتی امضا هم شده؛ اما وقتی می‌رویم سراغ اجرا، چیزی برای نشان‌دادن نیست. مثال واقعی‌اش این است که می‌گویید «مدیریت دسترسی داریم»، ولی Evidence شما فقط یک فایل Word است. ممیز معمولاً دنبال نشانه‌های اجرای روزمره است: لاگ تغییر دسترسی‌ها، تیکت‌های ایجاد/حذف کاربر، گزارش بازبینی دسترسی‌های دوره‌ای، و رد پای تأیید مدیر واحد. اگر این‌ها نیست، شکاف شما «عدم اجرای کنترل» تلقی می‌شود، نه «کمبود مستندات».
2. کنترل‌های ادغام‌شده: قبلاً چند تا عنوان داشتید، الان یک کنترل شده؛ شما هم فکر می‌کنید چون “یکی” شده راحت‌تر است
   در عمل برعکس می‌شود: کنترل ادغام‌شده یعنی ممیز انتظار دارد یک تصویر یکپارچه از مدیریت آن موضوع ببیند. مثلاً در 2013 ممکن بود بخش‌هایی از دسترسی‌ها، رمزها، بازبینی‌ها، و مدیریت حساب‌های ویژه هر کدام یک گوشه باشند؛ حالا شما اگر فقط یکی از آن‌ها را خوب کرده باشید، اما بقیه شواهد پراکنده/ناموجود باشد، کنترل از نظر ممیزی «ناقص» است. شکاف رایج اینجاست: سازمان یک سند جامع می‌نویسد ولی رد اجرایی بخش‌هایش را ندارد.
3. SoA را دارید، اما “منطق انتخاب/عدم انتخاب” قابل دفاع نیست
   این یکی خیلی ملموس است: کنترل‌ها را در SoA تیک می‌زنید، جلویشان می‌نویسید Applicable، اما وقتی سؤال می‌شود «چرا؟» یا «بر اساس کدام ریسک؟» جواب روشن نیست. در 2022، اگر SoA به ریسک‌ها و Risk Treatment Plan لینک نشده باشد، عملاً صوری به نظر می‌رسد. Evidence قابل قبول این است که برای هر کنترل کلیدی، به یک یا چند ریسک مشخص ارجاع بدهید و نشان بدهید این کنترل چگونه ریسک را کاهش می‌دهد و معیار پذیرش ریسک چیست.
4. Cloud را استفاده می‌کنید، ولی کنترل‌های مرتبط فقط با فرض On-Prem نوشته شده
   این سناریو خیلی تکرار می‌شود: ایمیل و فایل‌ها روی Microsoft 365/Google Workspace است، یا بخشی از سرویس‌ها روی VPS/ابر است، ولی مستندات و شواهد شما انگار همه‌چیز داخل دیتاسنتر خودتان است. شکاف واقعی اینجاست که قرارداد/مسئولیت‌ها، تنظیمات امنیتی سرویس ابری، لاگ‌های دسترسی، MFA، سیاست نگهداری داده، و مدیریت رخداد در محیط Cloud شفاف نیست یا کسی مالک آن نیست. ممیز اگر حس کند “مرز مسئولیت با سرویس‌دهنده” روشن نشده، معمولاً NCR می‌دهد.
5. پشتیبان‌گیری دارید، اما «قابل بازیابی بودن» را اثبات نکرده‌اید
   می‌گویید بکاپ گرفته می‌شود، حتی اسکرین‌شات از نرم‌افزار بکاپ هم دارید. ولی سؤال ساده: آخرین بار چه زمانی Restore تست شده؟ نتیجه تست کجاست؟ در Gap Analysis این معمولاً یک شکاف پرریسک است، چون بکاپ بدون تست بازیابی، از نگاه امنیت اطلاعات یک اطمینان کاذب می‌سازد. Evidence قوی: گزارش‌های دوره‌ای تست بازیابی، زمان RTO/RPO هدف‌گذاری‌شده، و ثبت رخدادهای شکست/اصلاح.
6. مدیریت تغییر (Change) و پیکربندی (Config) در عمل “شفاهی” است
   یکی از ملموس‌ترین جاهایی که سازمان‌ها Evidence کم می‌آورند همین است: تغییرات روی فایروال/سرور/اپلیکیشن انجام می‌شود، اما تیکت، تأیید، ارزیابی اثر، و امکان Rollback مستند نیست. شما شاید بگویید «تیم IT خودش می‌داند»، اما ممیز دنبال سیستم قابل تکرار است، نه دانش فردی. اینجا Gap Analysis دقیقاً باید نشان دهد آیا جریان تغییرات در ابزار تیکتینگ/گیت/چنج‌لاگ ثبت می‌شود یا نه، و آیا تغییرات مهم قبل و بعدش بازبینی می‌شوند یا خیر.
7. مدیریت رخداد دارید، اما “تمرین” و “یادگیری بعد از رخداد” ندارید
   سازمان یک روش واکنش به رخداد دارد، شماره تماس‌ها هم هست، اما وقتی می‌پرسیم آخرین Incident چه بود، چطور ثبت شد، چه کسی تصمیم گرفت، و درس‌آموخته‌ها چه شد، چیزی نیست. در Gap Analysis این یعنی سیستم شما به بلوغ عملیاتی نرسیده. Evidence خوب: Incident ticket، گزارش Root Cause، اقدامات اصلاحی، و تمرین‌های Tabletop یا مانور ساده (حتی اگر کوچک باشد).
8. آگاهی‌رسانی انجام می‌دهید، اما اثربخشی‌اش اندازه‌گیری نشده
   خیلی جاها آموزش امنیت اطلاعات به شکل یک فایل PDF یا یک جلسه کوتاه انجام می‌شود و تمام. شکاف وقتی ایجاد می‌شود که هیچ شواهدی از سنجش اثربخشی نیست: آزمون کوتاه، نرخ مشارکت، نتایج فیشینگ شبیه‌سازی‌شده، یا KPIهای رفتاری. ممیز معمولاً با یک سؤال ساده گیر می‌دهد: «از کجا می‌فهمید این آموزش اثر کرده؟» اگر جواب فقط “حس ما” باشد، شکاف دارید.
9. تأمین‌کنندگان را دارید، اما کنترل امنیتی در قرارداد/نظارت ندارید
   این یکی خیلی واقعی است: شرکت با پیمانکار IT، توسعه‌دهنده، دیتاسنتر، یا شرکت نگهداری کار می‌کند؛ اما معیارهای امنیتی، سطح دسترسی، تعهد محرمانگی، و نظارت دوره‌ای تعریف نشده. Gap Analysis باید نشان بدهد آیا ارزیابی ریسک تأمین‌کننده انجام شده، آیا بندهای امنیتی در قرارداد هست، و آیا حداقل سالی یک بار بازبینی/ارزیابی عملکرد امنیتی انجام می‌دهید یا نه.
10. BCP/DRP دارید، اما ICT Readiness واقعی نیست
    ممکن است یک برنامه تداوم کسب‌وکار نوشته باشید، اما آمادگی IT برای سناریوهای واقعی (قطع اینترنت، خرابی سرور، باج‌افزار، از دست رفتن دسترسی به سرویس ابری) تمرین نشده یا نقش‌ها و اولویت سرویس‌ها مشخص نیست. شکاف ملموس این است که در زمان بحران، همه چیز به چند نفر کلیدی وابسته می‌شود. Evidence قوی: فهرست سرویس‌های حیاتی، سناریوهای آزموده‌شده، نتایج تست، و اقدام اصلاحی بعد از تست.

تحلیل شکاف با ممیزی داخلی، Stage 1 و Stage 2 چه فرقی دارد؟

Gap Analysis vs Internal Audit vs Pre-assessment

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

تحلیل شکاف (Gap Analysis) یعنی ما وضعیت فعلی تو را با الزامات ISO 27001 (بندهای ۴ تا ۱۰ + Annex A نسخه 2022) خط‌به‌خط می‌سنجیم تا دقیقاً معلوم شود کجاها «شاهد» داری، کجاها فقط ادعاست، و کجاها اصلاً چیزی وجود ندارد. خروجی‌اش باید یک نقشه‌راه اجرایی باشد (شکاف‌ها + اولویت + اقدام + مالک + زمان). این کار به‌خودیِ‌خود «ممیزی صدور» نیست و قرار نیست در پایانش کسی به تو گواهی بدهد؛ هدفش این است که قبل از ممیزی، تکلیف‌ات را روشن کند.

Pre-assessment (پیش‌ممیزی/آمادگی ممیزی) یک قدم نزدیک‌تر به ممیزی صدور است، اما هنوز هم «اختیاری» و غیرالزامی است و معمولاً به شکل یک ممیزی تمرینی انجام می‌شود تا مشکلات قبل از ممیزی اصلی دیده شوند. بعضی CBها یا مشاوران این سرویس را ارائه می‌دهند، دقیقاً با همین منطق که بهتر است ایرادها قبل از ممیزی اصلی پیدا شوند.

ممیزی داخلی (Internal Audit) بخشی از خودِ سیستم مدیریتی توست، یعنی باید داخل سازمان انجام شود تا نشان بدهی ISMS فقط طراحی نشده، بلکه در حال کنترل و بهبود است. ممیزی داخلی به جای اینکه صرفاً «فهرست کمبودها» بدهد، باید بررسی کند الزامات و کنترل‌هایی که گفتی اجرا می‌کنی واقعاً اجرا می‌شود یا نه و آیا اثربخش است یا خیر؛ و خروجی‌اش باید وارد چرخه اقدام اصلاحی و بازنگری مدیریت شود (همان چیزی که ممیز خارجی هم انتظار دارد ببیند).

مطالعه پیشنهادی: ممیزی داخلی چیست و چه خروجی‌هایی باید داشته باشد؟ / راهنمای اجرای ممیزی داخلی طبق ISO 19011

یک قاعده ساده: Gap Analysis برای “تصویر کلی + نقشه‌راه”، Internal Audit برای “کنترل داخلی و بلوغ سیستم”، و Pre-assessment برای “تست نهایی قبل از ممیزی صدور”.

Stage 1 چه چیزی را می‌سنجد؟ Stage 2 چه چیزی را؟

در ممیزی صدور ISO 27001 (وقتی با یک CB می‌روی جلو)، معمولاً با دو مرحله طرفی:

Stage 1 (مرحله ۱) بیشتر روی «آمادگی و طراحی سیستم» تمرکز دارد؛ یعنی ممیز بررسی می‌کند مستندات کلیدی ISMS و ساختار کلی‌اش وجود دارد و مسیر کلی منطقی است، Scope و زمینه سازمان مشخص است، روش ارزیابی ریسک/درمان ریسک قابل دفاع است، و سازمان برای ورود به مرحله دوم آماده هست یا نه. به همین دلیل خیلی جاها Stage 1 را “documentation & readiness review” هم می‌دانند.

Stage 2 (مرحله ۲) همان جایی است که ممیز می‌خواهد “در عمل” ببیند سیستم کار می‌کند: اجرای کنترل‌ها، شواهد واقعی، مصاحبه با افراد، نمونه‌برداری از رکوردها/لاگ‌ها، رسیدگی به رخدادها، ممیزی داخلی، اقدامات اصلاحی و بهبود. Stage 2 عملاً همان ممیزی‌ای است که بر اساس آن درباره صدور گواهی تصمیم‌گیری می‌شود.

پس اگر بخواهیم خیلی شفاف بگوییم: Stage 1 می‌پرسد «سیستم را درست طراحی کرده‌ای؟» و Stage 2 می‌پرسد «این سیستم واقعاً اجرا می‌شود و اثربخش است؟»

اشتباه رایج: جایگزین‌کردن Gap Analysis با ممیزی صدور

اشتباه پرتکرار این است که سازمان Gap Analysis انجام می‌دهد، چند سند مرتب تولید می‌کند و خیال می‌کند “پس آماده ممیزی هستیم”. اما روز Stage 2 ممیز دنبال Evidence اجرایی است، نه صرفاً فایل‌ها. نتیجه‌اش معمولاً یکی از این سناریوهاست: عدم انطباق‌های متعدد، زمان‌کشی برای بستن NCRها، یا برگشت به عقب برای تکمیل شواهد و اجرای واقعی کنترل‌ها.

نسخه درستِ مسیر (کم‌ریسک و قابل دفاع) معمولاً این‌طور است: اول Gap Analysis برای تعیین شکاف‌ها و اولویت‌ها، بعد بستن شکاف‌های پرریسک و تولید شواهد واقعی، بعد ممیزی داخلی + بازنگری مدیریت برای اینکه نشان بدهی سیستم “کنترل و بهبود” می‌شود، و اگر خواستی ریسک را باز هم کمتر کنی، یک Pre-assessment اختیاری قبل از ورود به Stage 1/2.

پیش‌نیازهای تحلیل شکاف (قبل از اینکه هزینه و زمان بسوزانید)

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

تعیین Scope و مرزهای ISMS (سایت‌ها/فرآیندها/سامانه‌ها)

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

اگر Scope را درست نبندید، در تحلیل شکاف دو اتفاق بد می‌افتد: یا کنترل‌های زیادی را بی‌دلیل “Applicable” می‌زنید و پروژه سنگین می‌شود، یا کنترل‌های مهم را حذف می‌کنید و روز ممیزی قابل دفاع نیست. پیشنهاد اجرایی ما این است که قبل از هر چیزی، یک پاراگراف Scope بنویسید که «مرزها و استثناها» را شفاف کند و همین‌طور «اینترفیس‌ها» را مشخص کند؛ یعنی جاهایی که بیرون Scope هستند ولی با شما تبادل داده دارند (مثلاً پیمانکار IT، شرکت هاستینگ، سرویس Cloud، یا مرکز تماس برون‌سپاری‌شده). این مرزبندی همان چیزی است که بعداً در Gap Analysis به شما کمک می‌کند هر کنترل را دقیق در جای خودش ارزیابی کنید.

دارایی‌های اطلاعاتی و مالکیت‌ها (Asset Register حداقلی)

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

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

نام دارایی، نوع دارایی (داده/نرم‌افزار/زیرساخت/سرویس/حساب کاربری ویژه)، مالک دارایی (Asset Owner)، محل نگهداری/پردازش (On-prem/Cloud/پیمانکار)، سطح حساسیت یا طبقه‌بندی، و اهمیت در سه‌گانه محرمانگی-یکپارچگی-دسترس‌پذیری. همین اطلاعات ساده باعث می‌شود در تحلیل شکاف، کنترل‌ها را به دارایی‌های واقعی وصل کنید و بعداً برای Evidence هم دست‌تان پر باشد (مثلاً برای کنترل‌های دسترسی، بکاپ، لاگینگ، رمزنگاری، مدیریت تغییر و…).

ریسک‌ها و معیار پذیرش ریسک (Risk Method + Risk Treatment)

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

در کنار Risk Method، باید منطق Risk Treatment هم روشن باشد: قرار است ریسک را کاهش بدهید، اجتناب کنید، منتقل کنید (مثلاً با قرارداد/بیمه/برون‌سپاری)، یا بپذیرید؟ و وقتی درمان انتخاب می‌شود، مالک ریسک چه کسی است و شواهد پذیرش ریسک (اگر پذیرفته شد) چگونه ثبت می‌شود؟ اگر این‌ها شفاف نباشد، خروجی Gap Analysis تبدیل می‌شود به یک لیست کنترل که “همه‌چیز را باید پیاده کنیم”؛ در حالی که هدف ISO 27001 این نیست. هدف این است که کنترل‌ها را بر اساس ریسک‌های واقعی و تصمیم مدیریتی «هوشمندانه» انتخاب کنید.

مطالعه پیشنهادی: پارامترهای ارزیابی ریسک در ISO 27001 / راهنمای ریسک‌محور (ISO 27005)

SoA و دلیل انتخاب/عدم انتخاب کنترل‌ها

SoA (Statement of Applicability) قلب پروژه شماست، چون نشان می‌دهد کدام کنترل‌های Annex A نسخه 2022 برای شما «قابل اعمال» است و چرا. خیلی‌ها SoA را یک فایل تیک‌زدنی می‌بینند؛ اما در ممیزی و حتی در تحلیل شکاف، SoA باید یک سند استدلالی باشد: برای هر کنترل باید معلوم باشد Applicable هست یا نه، اگر هست به کدام ریسک/نیاز کسب‌وکار وصل است، و اگر نیست دلیل منطقی و قابل دفاعش چیست.

نکته کلیدی این است: SoA باید به Risk Treatment Plan لینک داشته باشد. یعنی اگر گفتید فلان کنترل را اجرا می‌کنیم، باید بتوانید نشان دهید این کنترل بخشی از درمان کدام ریسک است و بعدش Evidence اجرای آن چگونه تولید می‌شود (سند، رکورد، لاگ، تیکت، گزارش، تنظیمات). اگر این اتصال را از همان اول درست بسازید، Gap Analysis شما دقیقاً تبدیل می‌شود به یک نقشه‌راه: «کدام کنترل‌ها اولویت ۱ هستند چون ریسک بالا دارند و Evidence ندارند»، «کدام‌ها اولویت ۲ هستند چون بخشی از بلوغ سیستم‌اند»، و «کدام‌ها فعلاً خارج از Scope یا غیرقابل اعمال‌اند و دلیلش ثبت شده است».

روش استاندارد انجام Gap Analysis در 9 گام

اگر بخواهی تحلیل شکاف ISO 27001 واقعاً به خروجی اجرایی برسد (نه یک گزارش کلی و تزئینی)، باید آن را مثل یک پروژه کوتاه‌مدت و مرحله‌ای جلو ببری؛ با ورودی مشخص، روش ارزیابی ثابت، و خروجی قابل اندازه‌گیری در انتهای هر گام. این 9 گام، همان مسیر کم‌ریسکی است که هم برای سازمان‌های کوچک جواب می‌دهد، هم برای سازمان‌های چندسایته و حساس—فقط حجم نمونه‌برداری و عمق شواهد تغییر می‌کند.

گام 1: شناخت وضعیت فعلی و جمع‌آوری شواهد (Evidence)

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

اینجا کلید موفقیت، جمع‌آوری شواهد است نه جمع‌آوری فایل. شواهد قابل دفاع معمولاً چهار جنس دارند: سیاست/روش اجرایی (Policy/Procedure)، رکوردهای انجام کار (Record/Ticket/Report)، شواهد فنی (Log/Config/Screenshot/Monitoring)، و شواهد آموزشی و آگاهی (Training/Attendance/Quiz). خروجی این گام باید یک «فهرست شواهد موجود و مفقود» باشد که بعداً هنگام بررسی بندها و Annex A دقیقاً بدانید برای هر موضوع، دنبال چه Evidenceی باید بگردید و از کدام واحد.

گام 2: بررسی الزامات بندهای 4 تا 10 (Clause-by-Clause)

حالا نوبت ستون فقرات استاندارد است: بندهای 4 تا 10. پیشنهاد ما این است که Clause-by-Clause جلو بروی، اما با یک سؤال ثابت: «این الزام در سازمان شما چگونه پیاده شده و چه شاهدی برایش دارید؟» نه اینکه فقط متن بند را تکرار کنید.

مثلاً در بند 4 (Context) باید Scope و مرزها قابل دفاع باشد و ذی‌نفع‌ها و الزامات قانونی/قراردادی دیده شده باشد. در بند 5 (Leadership) دنبال نقش‌های روشن، تعهد مدیریت، خط‌مشی امنیت اطلاعات و تخصیص مسئولیت‌ها هستید. بند 6 (Planning) معمولاً جایی است که ریسک‌متد و معیار پذیرش ریسک و برنامه درمان ریسک باید قابل دفاع باشد.

بند 7 (Support) روی منابع، شایستگی، آگاهی، ارتباطات و کنترل مستندات می‌چرخد. بند 8 (Operation) می‌گوید برنامه‌های ریسک را واقعاً اجرا کرده‌اید یا نه. بند 9 (Performance Evaluation) همان جایی است که اندازه‌گیری، پایش، ممیزی داخلی و بازنگری مدیریت باید Evidence داشته باشد. و بند 10 (Improvement) یعنی چرخه اقدام اصلاحی واقعی دارید و از رخدادها/عدم انطباق‌ها یاد می‌گیرید.

خروجی این گام باید یک ماتریس ساده باشد: برای هر بند، وضعیت (مثلاً کامل/نیمه‌کامل/غایب)، شواهد موجود، شواهد مفقود، و توضیح شکاف.

گام 3: بررسی کنترل‌های Annex A (کنترل‌به‌کنترل)

بعد از بندها، وارد Annex A می‌شوید؛ جایی که خیلی‌ها فقط “تیک می‌زنند” و بعد در ممیزی زمین می‌خورند. روش درست این است که کنترل‌ها را از دریچه SoA و ریسک‌ها ببینید: هر کنترل اگر Applicable است باید به یک ریسک/نیاز مشخص وصل باشد و Evidence اجرایی داشته باشد. اگر Not Applicable است باید دلیلش روشن و قابل دفاع باشد—نه یک جمله کلی.

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

خروجی این گام، تکمیل بخش Annex A در ماتریس شکاف است: وضعیت هر کنترل + Evidence + شکاف + ارجاع به ریسک/SoA.

گام 4: امتیازدهی/بلوغ (Maturity) و ثبت شکاف‌ها

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

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

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

گام 5: تحلیل ریشه‌ای (Root Cause) برای شکاف‌های مهم

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

تحلیل ریشه‌ای یعنی جدا کردن “علامت” از “علت”. مثلاً علت نبودِ رکورد بازبینی دسترسی ممکن است کمبود ابزار نباشد؛ شاید نقش مالک سیستم مشخص نیست، یا فرآیند خروج کارکنان (Offboarding) با IT هم‌زمان نیست، یا KPI و مسئولیت برایش تعریف نشده. خروجی این مرحله باید به زبان اجرایی باشد: ریشه مشکل در People/Process/Technology کجاست و برای حذف ریشه، چه تغییری لازم است.

گام 6: اولویت‌بندی بر اساس ریسک و اثر کسب‌وکار

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

اینجا معمولاً دو سبد اقدام شکل می‌گیرد: اقدام‌های “باید قبل از ممیزی بسته شود” (خصوصاً شواهد اجرایی کنترل‌های حیاتی و الزامات بند 9 و 10 مثل ممیزی داخلی و اقدام اصلاحی) و اقدام‌های “بلوغ‌ساز” که می‌تواند فاز دوم باشد (مثل بهینه‌سازی شاخص‌ها، اتوماسیون برخی کنترل‌ها، یا تکمیل جزئیات).

خروجی این گام: لیست شکاف‌ها با برچسب اولویت (بالا/متوسط/پایین) و منطق اولویت.

گام 7: برنامه اقدام (Action Plan) با مالک، زمان، منابع

اینجا جایی است که Gap Analysis تبدیل به پروژه واقعی می‌شود. برنامه اقدام باید برای هر شکاف این‌ها را روشن کند: اقدام دقیق چیست، مالک آن چه کسی است، تا چه تاریخی باید بسته شود، چه منابعی لازم دارد (ابزار، نفر-ساعت، بودجه، پیمانکار)، خروجی قابل تحویل چیست، و معیار بسته‌شدن اقدام چیست (صرفاً “انجام شد” کافی نیست؛ باید معلوم باشد چه Evidenceی تولید می‌شود).

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

گام 8: بازبینی مدیریت و تصمیم‌های کلیدی

در ISO 27001 تصمیم‌های کلیدی باید از مسیر مدیریت عبور کند و این تصمیم‌ها باید رکورد داشته باشد. بازبینی مدیریت فقط یک جلسه تشریفاتی نیست؛ نقطه‌ای است که مدیریت درباره Scope، منابع، پذیرش ریسک‌های باقی‌مانده، اولویت‌های سرمایه‌گذاری، و زمان‌بندی ممیزی تصمیم می‌گیرد. اگر این مرحله را جدی نگیرید، معمولاً وسط پروژه با “کمبود اختیار/بودجه/زمان” گیر می‌کنید.

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

گام 9: آماده‌سازی برای ممیزی (Readiness Check)

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

اگر می‌خواهی ریسک Stage 2 را کم کنی، اینجا بهترین نقطه برای یک “ممیزی داخلی جمع‌وجورِ نهایی” است تا آخرین شکاف‌های اجرایی بیرون بیاید و قبل از ممیزی رسمی بسته شود.

چطور شکاف‌ها را امتیازدهی و اولویت‌بندی کنیم؟

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

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

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

1) ریسک (Risk)
این معیار ستون اصلی است: شکافِ شما احتمال وقوع رخداد را زیاد می‌کند یا اثر رخداد را سنگین‌تر؟ مثال: نبود بازبینی دسترسی‌ها یا نبود تست بازیابی بکاپ، معمولاً ریسک بالایی دارد چون مستقیماً روی محرمانگی/دسترس‌پذیری اثر می‌گذارد. در عمل، اگر شکاف به دارایی‌های حیاتی وصل است (داده مشتری، سیستم مالی، سرویس تولیدی)، امتیاز ریسک بالاتر می‌گیرد.

2) انطباق (Compliance / Conformity)
بعضی شکاف‌ها حتی اگر از نظر فنی “فاجعه” نباشند، از نظر استاندارد و ممیزی می‌توانند سریع NCR بسازند؛ مخصوصاً شکاف‌های مربوط به بندهای مدیریتی مثل ممیزی داخلی، بازنگری مدیریت، اقدام اصلاحی، کنترل مستندات، روش ریسک و SoA. این‌ها همان چیزهایی هستند که ممیز برای اثبات “سیستم مدیریتی” رویشان حساس است.

3) اثر عملیاتی (Operational Impact)
گاهی یک شکاف، ریسک متوسط دارد اما عملیات را زمین‌گیر می‌کند یا هزینه ایجاد می‌کند: مثلاً نبود فرآیند مدیریت تغییر باعث قطعی‌های تکرارشونده می‌شود، یا نبود مدیریت رخداد باعث طولانی‌شدن بازیابی سرویس می‌شود. این معیار کمک می‌کند تصمیم‌گیری فقط امنیتی نباشد؛ کسب‌وکار هم دیده شود.

4) الزامات قانونی/قراردادی (Legal / Contractual)
اگر شکاف شما به قوانین، مقررات، یا تعهدات قراردادی مربوط است (مثل حریم خصوصی، نگهداری لاگ، الزامات مشتریان سازمانی، یا شروط پیمانکار/کارفرما)، معمولاً باید اولویت بالاتر بگیرد؛ چون ریسک آن فقط فنی نیست—حقوقی و اعتباری هم هست.

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

مدل امتیازدهی ساده و قابل دفاع (نمونه مقیاس 0 تا 3/5)

مدلی که هم ساده باشد و هم دفاع‌پذیر، معمولاً دو لایه دارد: شدت شکاف (Maturity/Implementation) و اولویت اقدام (Priority). پیشنهاد عملی:

لایه 1: امتیاز “وضعیت اجرا/بلوغ” برای هر بند یا کنترل (0 تا 3)

• 0 = وجود ندارد (نه سند، نه اجرا، نه شواهد)
• 1 = تعریف شده ولی اجرا ناقص / شواهد ضعیف (سند هست، اما Evidence کم یا پراکنده)
• 2 = اجرا می‌شود ولی پایش/کنترل سیستماتیک ندارد (Evidence هست، اما KPI/بازبینی/ثبات ضعیف است)
• 3 = اجرا و پایش می‌شود و بهبود دارد (Evidence کافی + پایش + اصلاحات)

این مقیاس باعث می‌شود “داریم/نداریم” تبدیل شود به “در چه سطحی هستیم”.

لایه 2: امتیاز “اولویت اقدام” برای هر شکاف (0 تا 5)
اینجا چهار معیار بالا را وارد کنید. یک روش بسیار ساده و قابل دفاع:

• به هر معیار (ریسک، انطباق، اثر عملیاتی، قانونی/قراردادی) از 0 تا 5 امتیاز بدهید.
• اگر می‌خواهید ساده بماند، وزن‌ها را برابر بگیرید و جمع بزنید:
  Priority Score = Risk + Compliance + Operational + Legal
• آستانه تعریف کنید:
  • 16 تا 20 = اولویت بحرانی (P1)
  • 11 تا 15 = اولویت بالا (P2)
  • 6 تا 10 = اولویت متوسط (P3)
  • 0 تا 5 = اولویت پایین (P4)

اگر سازمان شما حساس است (مالی/سلامت/داده زیاد)، می‌توانید وزن ریسک را کمی بالاتر ببرید (مثلاً ریسک × 1.5) ولی پیشنهاد من این است در مقاله عمومی، همان مدل برابر را معرفی کنید تا مخاطب سردرگم نشود.

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

تبدیل “لیست ایرادها” به “نقشه راه اجرایی”

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

1) هر شکاف را به یک اقدام دقیق تبدیل کنید
به‌جای اینکه بنویسید «مدیریت دسترسی ضعیف است»، بنویسید:

• «تعریف و اجرای بازبینی دوره‌ای دسترسی‌ها (هر 3 ماه) برای سیستم‌های حیاتی + تولید رکورد بازبینی + مسیر تأیید مدیر واحد»

2) مالک، خروجی و معیار پایان را مشخص کنید
هر اقدام باید سه چیز روشن داشته باشد:

• Owner (مسئول اصلی)
• Deliverable (خروجی قابل ارائه: گزارش، تیکت‌ها، لاگ‌ها، اسکرین‌شات تنظیمات، رکورد جلسه، فرم‌های امضا شده)
• Done Criteria (چه زمانی می‌گوییم بسته شد؟ با چه شاهدی؟)

3) اقدام‌ها را به فازها بشکنید
برای اینکه پروژه قابل مدیریت شود، نقشه راه را معمولاً به 3 فاز تقسیم کنید:

• فاز 1 (P1/P2): شکاف‌های پرریسک و ممیزی‌ساز (خصوصاً شواهد اجرایی کنترل‌های حیاتی + الزامات بند 9 و 10 مثل ممیزی داخلی/بازنگری مدیریت/اقدام اصلاحی)
• فاز 2 (P2/P3): تکمیل فرآیندها و استانداردسازی اجرا (مثل مدیریت تغییر، بهبود مدیریت رخداد، بلوغ مدیریت تأمین‌کننده)
• فاز 3 (P3/P4): بلوغ و بهینه‌سازی (شاخص‌ها، اتوماسیون، مانیتورینگ پیشرفته، تمرین‌های منظم)

4) وابستگی‌ها را مشخص کنید
خیلی از کارها بدون پیش‌نیاز جلو نمی‌روند: مثلاً تا Scope و Asset Register درست نباشد، ریسک‌ارزیابی و SoA هم دقیق نمی‌شود. اگر وابستگی‌ها را ننویسید، تیم‌ها کارها را غلط جلو می‌برند و دوباره‌کاری می‌شود.

خروجی‌ها و تحویل‌دادنی‌های حرفه‌ای تحلیل شکاف

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

ساختار گزارش Gap Analysis (Executive Summary تا ضمائم)

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

• Executive Summary: خلاصه مدیریتی یک تا دو صفحه‌ای؛ شامل سطح آمادگی کلی، 5 تا 10 شکاف بحرانی، و پیشنهاد مسیر اجرایی (فازبندی). این بخش باید طوری نوشته شود که مدیر تصمیم‌گیر بدون ورود به جزئیات فنی، بتواند درباره منابع و زمان‌بندی تصمیم بگیرد.
• Scope & Assumptions: دقیقاً چه چیزی ارزیابی شده (سایت‌ها/فرآیندها/سیستم‌ها)، چه چیزی خارج بوده، و فرض‌های کلیدی تحلیل چیست (مثلاً محدودیت دسترسی به لاگ‌ها یا عدم حضور یک واحد).
• Methodology: روش ارزیابی شما؛ یعنی معیار امتیازدهی، شیوه نمونه‌برداری، منابع شواهد، و اینکه بررسی‌ها بر اساس بندهای 4–10 و کنترل‌های Annex A انجام شده.
• Findings by Clauses (4–10): خروجی بندبه‌بند؛ با وضعیت، شواهد، شکاف‌ها و توضیح اثر/ریسک.
• Findings by Annex A Controls (2022): خروجی کنترل‌به‌کنترل؛ با وضعیت هر کنترل و Evidence آن.
• Top Risks & Root Causes: جمع‌بندی شکاف‌های پرریسک و ریشه‌های پرتکرار (فرآیندی/نقشی/ابزاری).
• Roadmap / Action Plan Overview: نقشه راه در سه فاز (بحرانی/بالا/متوسط) و نقاط کنترل (Milestones).
• Appendices: ماتریس کامل شکاف‌ها، فهرست شواهد بررسی‌شده، لیست مصاحبه‌ها، و هر نمودار/جدول تکمیلی.

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

ماتریس شکاف‌ها (Clause + Annex A + Evidence + Status)

ماتریس شکاف‌ها همان چیزی است که گزارش را از حالت متنی و کلی خارج می‌کند و تبدیلش می‌کند به ابزار مدیریت پروژه. یک ماتریس حرفه‌ای معمولاً دو بخش دارد: یکی برای Clauseهای 4 تا 10 و یکی برای Annex A. ستون‌های پیشنهادی که واقعاً کار می‌کنند:

• Reference: شماره بند یا کنترل (مثلاً 6.1 یا A.5.xx)
• Requirement / Control: شرح کوتاه الزام یا کنترل
• Applicable? (برای Annex A): قابل‌اعمال هست یا نه + دلیل کوتاه
• Current Evidence: شواهد موجود (نام سند/لینک/نوع لاگ/شماره تیکت)
• Status / Maturity: وضعیت (مثلاً 0 تا 3) یا (Missing/Partial/Implemented/Effective)
• Gap Statement: شکاف دقیق در یک جمله اجرایی (نه کلی‌گویی)
• Risk / Impact: اثر و ریسک (کسب‌وکار/فنی/انطباقی)
• Owner (Candidate): مالک پیشنهادی اقدام (واحد/نقش)
• Priority: اولویت (P1 تا P4)
• Target Evidence: شواهدی که باید تولید شود تا شکاف بسته شود

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

برنامه اقدام اصلاحی (CAPA/Action Plan)

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

• Action: اقدام دقیق و قابل انجام (Actionable)
• Related Gap / Reference: ارجاع به ردیف ماتریس شکاف‌ها
• Owner: مالک اقدام (یک نفر/نقش مشخص، نه “IT” به‌صورت کلی)
• Support / Stakeholders: واحدهای همکار
• Due Date: تاریخ هدف
• Deliverable: خروجی قابل تحویل (سند/رکورد/لاگ/گزارش/تنظیمات)
• Done Criteria: معیار بسته‌شدن (چه چیزی باید نشان داده شود؟)
• Resources: نیازمندی‌ها (ابزار، نفر-ساعت، بودجه)
• Dependency: پیش‌نیازها (مثلاً تا Asset Register کامل نشود، SoA نهایی نمی‌شود)
• Progress: وضعیت پیشرفت و تاریخ آخرین به‌روزرسانی

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

RACI یا مسئولیت‌ها (چه کسی مالک کدام اقدام است؟)

یکی از دلایل اصلی شکست پروژه‌های ISO 27001 این است که مسئولیت‌ها مبهم می‌ماند. RACI کمک می‌کند از همان ابتدا روشن کنید در هر حوزه چه کسی تصمیم‌گیر است و چه کسی اجرا می‌کند. RACI یعنی:

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

برای Gap Analysis یک RACI حداقلی هم کافی است، اما باید برای حوزه‌های کلیدی باشد: مدیریت دسترسی، مدیریت تغییرات، بکاپ و بازیابی، رخداد، تأمین‌کننده، آموزش و آگاهی، کنترل مستندات، ریسک و SoA. وقتی این جدول را داشته باشید، Action Plan روی زمین نمی‌ماند چون هر اقدام “مالک پاسخ‌گو” دارد و تصمیم‌ها سرگردان نمی‌شود.

لیست شواهد پیشنهادی برای هر حوزه

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

• Governance & ISMS: خط‌مشی، اهداف، Scope، روش ریسک، SoA، برنامه درمان ریسک، کنترل مستندات
• Access Management: سیاست دسترسی، فرآیند ایجاد/حذف دسترسی، تیکت‌ها، گزارش بازبینی دسترسی دوره‌ای، لیست حساب‌های ویژه
• Asset & Data: Asset Register، طبقه‌بندی اطلاعات، دستورالعمل نگهداری/انتقال داده، نمونه برچسب‌گذاری یا کنترل دسترسی به داده حساس
• Operations / Change: Change log یا تیکت تغییرات، تأیید تغییر، تست/rollback، پیکربندی‌های کلیدی
• Backup & Recovery: سیاست بکاپ، گزارش اجرای بکاپ، گزارش تست بازیابی، RTO/RPO
• Incident Management: روش رسیدگی به رخداد، تیکت‌های رخداد، گزارش RCA، اقدامات اصلاحی، تمرین/مانور
• Supplier Management: لیست تأمین‌کنندگان، ارزیابی ریسک تأمین‌کننده، بندهای امنیتی قرارداد، بازبینی دوره‌ای
• Awareness & HR: برنامه آموزش، حضور و غیاب، آزمون/ارزیابی اثربخشی، NDA، فرآیند Onboarding/Offboarding
• Monitoring & Logging: سیاست لاگ، تنظیمات جمع‌آوری لاگ، نمونه گزارش‌های بررسی لاگ، هشدارها/Incident linkage

وجود این لیست باعث می‌شود خواننده صفحه شما دقیقاً بفهمد “شواهد یعنی چه” و برای بستن شکاف‌ها باید دنبال چه چیزهایی باشد؛ و این همان جایی است که مقاله از حالت توضیحیِ کلی خارج می‌شود و تبدیل می‌شود به راهنمای اجرایی.

دانلود فایل ورد قالب‌های آماده تحلیل شکاف ISO 27001

این فایل شامل:

• ماتریس شکاف (نمونه 10 ردیفی)
• برنامه اقدام / CAPA (نمونه 10 ردیفی)
• جدول RACI ساده برای حوزه‌های کلیدی ISMS

نمونه شواهدی که ممیز معمولاً می‌پذیرد

وقتی صحبت از «شواهد» در ISO 27001 می‌شود، منظور فقط یک سری فایل Word نیست. ممیز دنبال این است که شما بتوانید نشان بدهید کنترل‌ها واقعاً اجرا می‌شوند و آن اجرا قابل ردیابی است. بهترین رویکرد این است که برای هر الزام/کنترل، حداقل یک ترکیب منطقی از شواهد داشته باشید: یک سند راهنما (Policy/Procedure) + یک یا چند رکورد اجرایی (Record/Log/Ticket) + اگر لازم است شواهد فنی (Config/Screenshot) + شواهد آگاهی/شایستگی افراد. در ادامه، نمونه‌های ملموس و قابل استفاده را به تفکیک می‌بینید.

مطالعه پیشنهادی: چک‌لیست ممیزی داخلی برای آماده‌سازی Stage 2

شواهد سیاستی/فرآیندی (Policy/Procedure)

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

نمونه‌های رایج و پذیرفته‌شده:

• خط‌مشی امنیت اطلاعات (Information Security Policy) + تاریخ بازبینی و تأیید مدیریت
• Scope ISMS و حدود و استثناها (چه چیزهایی داخل/خارج است و چرا)
• روش ارزیابی ریسک و معیار پذیرش ریسک (Risk Methodology + Risk Criteria)
• روش درمان ریسک و قواعد انتخاب کنترل‌ها
• SoA (Statement of Applicability) با دلیل “Applicable/Not applicable”
• روش مدیریت دسترسی (ایجاد/تغییر/حذف دسترسی، حساب‌های ویژه، MFA، بازبینی دوره‌ای)
• روش مدیریت تغییرات (Change Management) و قواعد تست/rollback/تأیید
• روش مدیریت رخداد امنیتی (Incident Management) + مسیر Escalation
• روش کنترل مستندات و سوابق (Documented Information Control)
• روش مدیریت تأمین‌کنندگان (Supplier/Sourcing Security) + الزامات قراردادی امنیتی
• سیاست بکاپ و بازیابی (Backup & Restore) + RTO/RPO هدف
• سیاست لاگینگ و پایش (Logging/Monitoring Policy) + نگهداری/دسترسی/بازبینی

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

شواهد اجرایی (Log/Record/Ticket/Report)

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

نمونه‌های قوی و پرتکرار:

• تیکت‌های ایجاد/حذف/تغییر دسترسی کاربران (با تأیید مدیر واحد) + نمونه برای چند سیستم حیاتی
• گزارش بازبینی دوره‌ای دسترسی‌ها (مثلاً فصلی) + اقدامات اصلاحی پس از بازبینی
• Change Tickets / Change Log برای تغییرات مهم (فایروال، سرور، اپلیکیشن) + تأیید + نتیجه تست
• ثبت رخدادها (Incident Tickets) + گزارش Root Cause + اقدامات اصلاحی (CAPA)
• گزارش اجرای بکاپ‌ها (موفق/ناموفق) + گزارش تست بازیابی (Restore Test) و نتیجه
• ثبت آموزش‌ها و حضور و غیاب + آزمون/ارزیابی (اگر دارید)
• گزارش ممیزی داخلی + لیست عدم انطباق‌ها + برنامه اقدام + وضعیت بستن اقدامات
• صورتجلسه بازنگری مدیریت (Management Review Minutes) + تصمیم‌ها و اقدامات
• ارزیابی ریسک تأمین‌کننده + فرم ارزیابی/چک‌لیست + نتیجه تصمیم
• گزارش‌های دوره‌ای KPI/پایش (مثلاً تعداد رخدادها، وضعیت وصله‌ها، نرخ مشارکت آموزش)

نکته اجرایی: ممیز معمولاً چند نمونه می‌خواهد، نه همه‌چیز. اما آن نمونه‌ها باید “خوب انتخاب شده” باشند: سرویس حیاتی، داده حساس، دسترسی‌های ویژه، تغییرات پرریسک، رخداد واقعی یا تمرین‌شده.

شواهد فنی (Config/Screenshot/Monitoring)

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

نمونه‌های رایج و قابل قبول:

• اسکرین‌شات یا خروجی تنظیمات MFA برای ایمیل/SSO/حساب‌های ادمین
• خروجی تنظیمات Password Policy (حداقل طول، پیچیدگی، قفل‌شدن، تاریخ انقضا) یا استانداردهای رمز
• لیست کاربران و نقش‌ها (RBAC) برای سیستم‌های حساس + نشان دادن اصل حداقل دسترسی (Least Privilege)
• پیکربندی فایروال/ACL (در حد نشان دادن قواعد کلی و تغییرات اخیر، بدون افشای اطلاعات حساس)
• وضعیت Patch Management: گزارش وصله‌ها/نسخه‌ها، یا خروجی ابزار مدیریت به‌روزرسانی
• تنظیمات بکاپ (زمان‌بندی، مقصد، رمزنگاری، retention) + نمونه لاگ بکاپ
• خروجی SIEM/EDR یا ابزار مانیتورینگ: هشدارها، داشبوردها، نمونه Alert و پیگیری آن
• تنظیمات Logging/Auditing روی سرویس‌های کلیدی (مثلاً ثبت لاگ ورود/خروج، تغییرات حساس)
• تنظیمات DLP یا سیاست‌های اشتراک‌گذاری در سرویس‌های ابری (اگر استفاده می‌کنید)

نکته مهم: شواهد فنی باید “به‌اندازه” باشد؛ نه آن‌قدر جزئی که اطلاعات حساس لو برود، نه آن‌قدر کلی که چیزی ثابت نکند. معمولاً یک صفحه خروجی/اسکرین‌شات تمیز + توضیح یک‌خطی کافی است.

شواهد آموزشی و آگاهی (Training/Awareness)

در ISO 27001، ممیز دنبال این است که افراد فقط “شنیده باشند”، بلکه واقعاً بدانند چه مسئولیتی دارند و سازمان توانسته سطح آگاهی را مدیریت کند. اگر آموزش‌ها فقط یک پیام در گروه یا یک فایل PDF باشد، معمولاً اثربخشی زیر سؤال می‌رود. شواهد خوب باید نشان بدهد آموزش انجام شده، پوشش داشته، و حداقل یک روش برای سنجش اثربخشی وجود دارد.

نمونه‌های قابل ارائه:

• برنامه سالانه آموزش و آگاهی امنیت اطلاعات (موضوعات، مخاطب، زمان‌بندی)
• لیست شرکت‌کنندگان و حضور و غیاب + تاریخ و مدرس/مسئول
• محتوای آموزشی (اسلاید/ویدئو/راهنما) + نسخه و تاریخ
• آزمون کوتاه یا کوییز و نتایج (حتی ساده) برای سنجش اثربخشی
• کمپین‌های آگاهی مثل پوستر، ایمیل، پیام‌های دوره‌ای + گزارش ارسال/بازخورد
• آموزش‌های نقش‌محور (مثلاً برای ادمین‌ها، توسعه‌دهنده‌ها، پشتیبانی) + شواهد تکمیل
• تعهدنامه محرمانگی (NDA) و آموزش Onboarding/Offboarding برای کارکنان جدید/خارج‌شونده

نکته اجرایی: اگر سازمان شما کوچک است، لازم نیست سیستم آموزشی پیچیده بسازید؛ اما باید بتوانید نشان بدهید آموزش هدفمند بوده و حداقل یک مکانیزم ساده برای ارزیابی اثربخشی دارید (مثلاً کوییز 5 سؤالی یا ثبت فهم کلیدی‌ها).

زمان‌بندی و میزان درگیری تیم (واقع‌بینانه)

یکی از اشتباهات رایج این است که تحلیل شکاف را یا خیلی کوچک می‌بینند (“دو روزه جمعش می‌کنیم”) یا آن‌قدر بزرگ می‌کنند که عملاً شروعش عقب می‌افتد. واقعیت این است که زمان و درگیری تیم، مستقیم به 4 عامل وابسته است: اندازه Scope، تعداد سایت‌ها و سرویس‌های حیاتی، میزان برون‌سپاری/Cloud، و میزان بلوغ فعلی در مستندسازی و Evidence. در ادامه، سه سناریوی رایج را خیلی عملی و قابل استفاده می‌گوییم—به‌همراه اینکه چه کسانی باید درگیر شوند و معمولاً چند نفر-ساعت زمان می‌برد.

سازمان کوچک (کم‌ریسک)

این سناریو معمولاً شامل یک سایت، تیم کوچک، داده حساس محدود، و سرویس‌های نسبتاً ساده است (مثلاً شرکت خدماتی/استارتاپ کوچک بدون الزامات سخت‌گیرانه قراردادی).

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

درگیری تیم (تقریبی):

• مالک پروژه/نماینده مدیریت ISMS: حدود 6 تا 12 ساعت
• IT/ادمین/امنیت: حدود 12 تا 25 ساعت
• منابع انسانی (Onboarding/Offboarding/آگاهی): حدود 2 تا 5 ساعت
• عملیات/مدیر واحدهای کلیدی: حدود 4 تا 8 ساعت
• حقوقی/تدارکات (اگر تامین‌کننده دارید): حدود 2 تا 4 ساعت

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

سازمان متوسط / چند سایت

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

زمان واقع‌بینانه تحلیل شکاف: حدود 2 تا 4 هفته کاری
(بسته به تعداد سایت‌ها، تعداد سرویس‌های حیاتی و میزان پراکندگی شواهد)

درگیری تیم (تقریبی):

• مالک پروژه/ISMS Lead: حدود 15 تا 30 ساعت
• IT/امنیت: حدود 25 تا 50 ساعت
• مدیران واحدها (هر واحد کلیدی): حدود 3 تا 6 ساعت
• منابع انسانی: حدود 4 تا 8 ساعت
• حقوقی/تدارکات/قراردادها: حدود 4 تا 10 ساعت
• نماینده هر سایت/شعبه: حدود 2 تا 5 ساعت (برای مصاحبه و شواهد محلی)

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

سازمان حساس (مالی/سلامت/داده‌های گسترده)

اینجا معمولاً داده‌های حساس زیاد است، الزامات قانونی/قراردادی سنگین‌تر است، سرویس‌ها حیاتی‌ترند، و ممیز هم انتظار Evidence و کنترل‌های عملیاتی قوی‌تری دارد. علاوه بر این، معمولاً تیم‌ها چندلایه‌اند (IT، امنیت، توسعه، شبکه، عملیات، ریسک/انطباق) و Scope هم پیچیده‌تر است.

زمان واقع‌بینانه تحلیل شکاف: حدود 4 تا 8 هفته کاری
(گاهی بیشتر، اگر نمونه‌برداری گسترده و بررسی تامین‌کنندگان متعدد لازم باشد)

درگیری تیم (تقریبی):

• ISMS Lead / امنیت اطلاعات: حدود 30 تا 60 ساعت
• IT/شبکه/زیرساخت: حدود 40 تا 80 ساعت
• توسعه/DevOps (اگر محصول نرم‌افزاری دارید): حدود 15 تا 40 ساعت
• انطباق/حقوقی/حریم خصوصی: حدود 10 تا 25 ساعت
• عملیات/واحدهای کسب‌وکار: حدود 10 تا 25 ساعت (تجمیعی)
• مالکین سرویس‌های حیاتی: برای هر سرویس 2 تا 6 ساعت نمونه‌برداری و شواهد

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

چه چیزهایی زمان پروژه را طولانی می‌کند؟

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

1. Scope مبهم یا در حال تغییر
   هر بار که Scope عوض می‌شود، ریسک‌ها، SoA، و حتی لیست شواهد هم تغییر می‌کند. نتیجه: دوباره‌کاری.
2. نبود Asset Register و مالکیت‌ها
   وقتی مشخص نباشد مالک داده/سیستم کیست، گرفتن Evidence و تصمیم درباره کنترل‌ها کند و پراکنده می‌شود.
3. Evidence پراکنده و بدون سیستم نگهداری
   اگر تیکت‌ها یک‌جا نیست، لاگ‌ها نگهداری نمی‌شود، یا مستندات نسخه‌بندی ندارند، زمان زیادی صرف “پیدا کردن” می‌شود.
4. برون‌سپاری/Cloud بدون مرزبندی مسئولیت‌ها
   وقتی معلوم نیست کدام کنترل با شماست و کدام با سرویس‌دهنده، هم تحلیل کند می‌شود هم در خروجی‌ها ابهام ایجاد می‌شود (خصوصاً برای قراردادها و نظارت تامین‌کننده).
5. عدم دسترسی سریع به افراد کلیدی
   Gap Analysis به مصاحبه‌های کوتاه اما دقیق نیاز دارد. اگر مدیران یا ادمین‌های کلیدی در دسترس نباشند، پروژه کش می‌آید.
6. نبود روش ریسک یا اختلاف نظر درباره معیار پذیرش ریسک
   اگر مدیریت هنوز تصمیم نگرفته چه ریسکی را می‌پذیرد و چه ریسکی را نه، SoA و اولویت‌بندی معلق می‌ماند.
7. تمرکز بیش از حد روی “سندسازی” به جای “شواهد اجرایی”
   وقتی تیم‌ها به جای اینکه رکورد و Evidence تولید کنند، فقط سند می‌نویسند، در پایان مجبور می‌شوند دوباره برگردند و اجرا/رکورد را بسازند—یعنی دو بار زمان می‌گذارند.

تحلیل شکاف را چه کسی انجام بدهد؟

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

تیم داخلی (مزایا/ریسک‌ها/شرط موفقیت)

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

اما ریسک بزرگ این روش، «کور شدن نسبت به ضعف‌ها»ست؛ یعنی چون تیم سال‌ها با همین وضعیت کار کرده، برخی شکاف‌ها را طبیعی فرض می‌کند یا به خاطر درگیری‌های داخلی، سخت‌گیری لازم را انجام نمی‌دهد. ریسک دوم هم نبود تجربه ممیزی است: ممکن است کنترل‌ها را اجرا کنید، ولی نتوانید آن را به شکل Evidence قابل دفاع مستندسازی و ارائه کنید. نتیجه‌اش این می‌شود که در Stage 2 ممیز می‌گوید “شاهد کافی نیست” و شما مجبور می‌شوید در زمان کم، رکوردسازی و ساماندهی انجام دهید.

اگر می‌خواهید تیم داخلی Gap Analysis را انجام دهد، سه شرط موفقیت خیلی مهم است: اول، یک نفر باید نقش «ISMS Lead» یا رهبر پروژه را واقعی بگیرد (مالک خروجی‌ها باشد، نه هماهنگ‌کننده صرف). دوم، از همان اول مدل امتیازدهی و قالب خروجی (ماتریس شکاف + اکشن‌پلن) را استاندارد کنید تا گزارش کلی‌گویی نشود. سوم، نمونه‌برداری را جدی بگیرید: برای کنترل‌های حساس فقط به سند اکتفا نکنید و حتماً رکورد/لاگ/تیکت و شواهد اجرایی جمع کنید.

مشاور بیرونی (چه خروجی‌هایی باید تحویل بدهد؟)

اگر سازمان شما متوسط یا حساس است، یا تیم داخلی تجربه ممیزی و نگاه استانداردی ندارد، مشاور بیرونی معمولاً می‌تواند پروژه را سریع‌تر “قابل دفاع” کند. مزیت مشاور این است که نگاه بیرونی دارد و می‌تواند شکاف‌ها را بی‌طرفانه ببیند، و مهم‌تر از آن، می‌داند ممیزها معمولاً در چه نقاطی سخت‌گیری می‌کنند و چه نوع Evidenceی قابل قبول است. در سازمان‌هایی که Cloud، برون‌سپاری، یا چند سایت دارند، این تجربه بیرونی خیلی ارزشمند می‌شود چون یک اشتباه کوچک در Scope یا SoA می‌تواند پروژه را چند هفته عقب بیندازد.

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

حداقل خروجی‌هایی که از یک مشاور Gap Analysis باید بخواهید این‌هاست:

• Scope پیشنهادی/بازبینی‌شده با مرزها و استثناها و اینترفیس‌های بیرونی
• ماتریس شکاف بندهای 4 تا 10 با وضعیت، Evidence، شکاف دقیق و ریسک
• ماتریس شکاف Annex A (2022) کنترل‌به‌کنترل با Applicability و دلیل و Evidence
• SoA قابل دفاع (یا بازنگری SoA شما) با لینک به ریسک‌ها/درمان ریسک
• Action Plan / CAPA با اولویت‌بندی، مالک اقدام، زمان‌بندی و Deliverable مشخص
• یک بسته Evidence List (لیست شواهد لازم/پیشنهادی برای حوزه‌های کلیدی) که تیم بداند دقیقاً چه چیزی باید تولید و نگهداری کند
• در صورت نیاز، یک Readiness Check کوتاه قبل از ورود به ممیزی تا ریسک NCR کم شود

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

نقش CB و ممیز (چه کارهایی را نباید از CB انتظار داشت)

اینجا یک سوءبرداشت خیلی رایج وجود دارد: بعضی سازمان‌ها فکر می‌کنند CB (Certification Body) یا ممیز قرار است به آن‌ها “مشاوره بدهد” که چطور سیستم را پیاده کنند یا شکاف‌ها را ببندند. واقعیت این است که CB باید استقلال ممیزی را حفظ کند؛ یعنی وظیفه‌اش این است که ارزیابی کند شما با استاندارد منطبق هستید یا نه، نه اینکه برای شما سیستم طراحی کند یا اجرا را جلو ببرد. اگر CB وارد طراحی و پیاده‌سازی شود، تضاد منافع ایجاد می‌شود و اعتبار ممیزی زیر سؤال می‌رود.

مطالعه پیشنهادی: لیست شرکت‌های صادرکننده گواهینامه ایزو در ایران (CBها)

پس چه چیزی را نباید از CB انتظار داشته باشید؟

• اینکه برای شما Scope بنویسد یا تعیین کند چه چیزی داخل/خارج باشد
• اینکه SoA را برایتان پر کند یا کنترل‌ها را انتخاب کند
• اینکه روش ریسک و معیار پذیرش ریسک را طراحی کند
• اینکه برای هر کنترل، Procedure و Evidence بسازد یا به شما بگوید دقیقاً “این سند را بنویس”
• اینکه نقش «مشاور پروژه» را بازی کند یا برنامه اقدام شما را مدیریت کند

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

اشتباهات رایج در Gap Analysis (و نسخه سریع اصلاح)

واقعیت این است که بیشتر پروژه‌های ISO 27001 نه به خاطر “کمبود دانش فنی”، بلکه به خاطر چند خطای تکراری در Gap Analysis از مسیر خارج می‌شوند. این خطاها باعث می‌شوند خروجی تحلیل شکاف یا غیرقابل دفاع شود (روز ممیزی)، یا غیرقابل اجرا (روز عمل). اینجا دقیقاً همان 5 اشتباه پرتکرار را می‌گوییم و کنار هرکدام یک نسخه سریع و عملی برای اصلاح می‌دهیم—طوری که بتوانی همین امروز در پروژه‌ات اعمالش کنی.

Scope غیرقابل دفاع

اشتباه رایج: Scope را یا خیلی باز می‌بندند (“کل سازمان، همه چیز”) یا خیلی بسته (“فقط یک واحد کوچک”)، بدون اینکه مرزها، استثناها و اینترفیس‌ها روشن باشد. نتیجه‌اش این می‌شود که یا پروژه از توان اجرا خارج می‌شود، یا ممیز می‌گوید Scope شما ریسک‌های واقعی را پوشش نمی‌دهد. یک نشانه واضح Scope بد این است که وقتی می‌پرسی “این سرویس/داده مهم داخل Scope هست یا نه؟” جواب‌ها بین واحدها متفاوت است.

نسخه سریع اصلاح: یک Scope یک‌صفحه‌ای بنویس و در آن چهار چیز را شفاف کن:

1. چه چیزهایی داخل است (سایت‌ها، فرآیندها، سامانه‌ها)
2. چه چیزهایی خارج است (با دلیل)
3. اینترفیس‌ها (ارتباط با پیمانکار/Cloud/شرکای بیرونی)
4. دارایی‌های حیاتی و داده‌های حساس مرتبط با Scope
   بعد همین Scope را با 2–3 سناریوی واقعی “تست” کن: خروج کارمند، رخداد امنیتی، بازیابی بکاپ. اگر در هر سناریو معلوم نبود مسئولیت و مرز کجاست، Scope هنوز قابل دفاع نیست.

SoA صوری و بدون دلیل

اشتباه رایج: SoA تبدیل می‌شود به یک جدول تیک‌زدنی. کنترل‌ها را Applicable می‌زنند چون “بهتر است همه را اجرا کنیم” یا Not Applicable می‌زنند چون “فعلاً وقت نداریم”. روز ممیزی، اولین سؤال ممیز همین است: چرا این کنترل را انتخاب کردی؟ بر اساس کدام ریسک؟ و Evidence کجاست؟ اگر SoA شما نتواند جواب بدهد، عملاً سیستم از نظر منطقی فرو می‌ریزد.

نسخه سریع اصلاح: برای هر کنترل Annex A فقط همین سه فیلد را جدی کن و کافی است:

• Applicability + دلیل یک‌خطی (واقعی و مرتبط با کسب‌وکار)
• لینک به ریسک/نیاز (شماره ریسک یا سناریوی ریسک)
• Evidence مورد انتظار (نوع شاهد: تیکت/لاگ/گزارش/سیاست/تنظیمات)
  اگر کنترل Not Applicable است، دلیل باید “فنی/سازمانی” باشد نه “نداریم/نمی‌خواهیم”. و اگر Applicable است اما Evidence ندارید، همان‌جا باید به عنوان شکاف با اولویت ثبت شود.

کنترل‌ها بدون Evidence

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

نسخه سریع اصلاح: برای کنترل‌های پرریسک یک قاعده ساده بگذار:
هر کنترل مهم باید حداقل 2 نوع Evidence داشته باشد:

1. یک سند راهنما (Policy/Procedure)
2. یک شاهد اجرایی (Record/Ticket/Log/Report)
   و اگر کنترل فنی است، یک شاهد فنی هم اضافه کن (Config/Screenshot).
   بعد برای هر کنترل، 2–3 نمونه واقعی انتخاب کن (نمونه‌برداری) و کنار کنترل بنویس: “Evidence شماره 1، 2، 3 کجاست؟”. اگر نمونه ندارید، یعنی کنترل شما فعلاً اجرا نشده، حتی اگر سندش موجود باشد.

ریسک‌ارزیابی غیرواقعی یا کپی‌پیستی

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

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

• 10 دارایی/سرویس حیاتی را لیست کن (داده مشتری، ایمیل، مالی، ERP، سرویس تولید، بکاپ، اکانت‌های ادمین…)
• برای هرکدام 2–3 سناریوی ریسک واقعی بنویس (نه کلی)
• معیار احتمال/اثر را ساده تعریف کن (مثلاً 1 تا 5)
• یک خط قرمز تعیین کن: Risk Acceptance Criteria (از چه امتیازی به بالا باید درمان انجام شود)
  اگر ریسک‌ها به سرویس‌های واقعی شما وصل شوند، SoA و Gap Analysis هم خودبه‌خود واقعی و اجرایی می‌شود.

برنامه اقدام بدون مالک و زمان

اشتباه رایج: در پایان Gap Analysis یک لیست اقدام نوشته می‌شود اما هیچ‌کس مالک نیست، زمان ندارد، خروجی قابل تحویل ندارد، و وابستگی‌ها مشخص نیست. نتیجه‌اش این است که پروژه در بهترین حالت “شروع می‌شود” ولی به پایان نمی‌رسد؛ و نزدیک ممیزی همه چیز فشرده و اضطراری می‌شود.

نسخه سریع اصلاح: برای هر اقدام فقط این 5 چیز را اجباری کن و تمام:

1. Owner (یک نفر/نقش مشخص)
2. Due Date (تاریخ هدف)
3. Deliverable (خروجی قابل ارائه)
4. Done Criteria (چه زمانی می‌گوییم بسته شد؟ با چه شاهدی؟)
5. Dependency (پیش‌نیازها)
   بعد اقدام‌ها را به 3 فاز تقسیم کن: “قبل از ممیزی ضروری”، “تکمیل و استانداردسازی”، “بلوغ و بهینه‌سازی”. این فازبندی کمک می‌کند تیم شما هم فشار غیرواقعی نگیرد، هم شکاف‌های ممیزی‌ساز سریع بسته شود.

چک‌لیست سریع Gap Analysis برای ISO 27001:2022

این چک‌لیست برای این طراحی شده که در یک نگاه بفهمی «کجای کار هستی» و Gap Analysis را از حالت کلی‌گویی خارج کنی. پیشنهاد ما این است که هنگام ارزیابی، برای هر آیتم فقط سه وضعیت بگذاری: داریم + Evidence مشخص / داریم ولی Evidence ضعیف / نداریم. اگر “Evidence مشخص” نداشته باشی، از نگاه ممیزی یعنی هنوز اجرا قابل اثبات نیست.

مطالعه پیشنهادی: چک‌لیست ممیزی (برای تکمیل Evidenceها)

چک‌لیست بندهای 4 تا 10

بند 4 – Context

• Scope ISMS نوشته شده، مرزها/استثناها و اینترفیس‌ها (پیمانکار/Cloud) مشخص است.
• ذی‌نفع‌ها و الزامات قانونی/قراردادی شناسایی و ثبت شده‌اند.
• فرآیندها/سرویس‌های حیاتی و نیازهای امنیت اطلاعات‌شان تعریف شده است.

بند 5 – Leadership

• خط‌مشی امنیت اطلاعات (Policy) تأیید مدیریت و ابلاغ شده است.
• نقش‌ها و مسئولیت‌ها (ISMS Lead، مالکان دارایی/ریسک/کنترل) مشخص است.
• اهداف کلان امنیت اطلاعات و تعهد مدیریت برای منابع/پشتیبانی قابل ردیابی است.

بند 6 – Planning

• روش ارزیابی ریسک (Risk Methodology) و معیار پذیرش ریسک تعریف شده است.
• Risk Register دارید (سناریوهای واقعی، نه کلی) و سطح ریسک‌ها قابل دفاع است.
• Risk Treatment Plan دارید (اقدام‌ها، مسئول، زمان، وضعیت) و به SoA لینک می‌شود.
• اهداف امنیت اطلاعات قابل اندازه‌گیری (یا حداقل قابل پیگیری) تعریف شده‌اند.

بند 7 – Support

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

بند 8 – Operation

• برنامه‌های درمان ریسک اجرا شده و Evidence اجرایی برای کنترل‌های حیاتی موجود است.
• فرآیند مدیریت تغییرات (Change) در عمل اجرا می‌شود (نه فقط روی کاغذ).
• کنترل‌های عملیاتی کلیدی مثل دسترسی، بکاپ، لاگینگ، رخداد، تامین‌کننده‌ها، قابل ردیابی هستند.

بند 9 – Performance Evaluation

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

بند 10 – Improvement

• فرآیند اقدام اصلاحی دارید (علت‌یابی، اقدام، پیگیری، اثربخشی).
• رخدادها/عدم انطباق‌ها باعث اصلاح واقعی می‌شوند (Evidence بسته شدن اقدامات).
• بهبود مستمر در حداقل چند نمونه قابل نشان دادن است.

چک‌لیست Annex A (سطح حداقلی/سطح بالغ)

اینجا دو سطح گذاشته‌ام:

• حداقلی یعنی برای گذر امن از ممیزی و کنترل‌های حیاتی Evidence داشته باشی.
• بالغ یعنی کنترل‌ها فقط اجرا نمی‌شوند، بلکه پایش و بهبود هم دارند.

A) سطح حداقلی (Minimum Viable Controls)

• مدیریت دسترسی‌ها: چرخه ایجاد/تغییر/حذف دسترسی + MFA برای حساب‌های حساس + بازبینی دوره‌ای دسترسی‌ها.
• حساب‌های ویژه (Admin/Privileged): لیست حساب‌ها + محدودیت استفاده + ثبت فعالیت‌ها (حداقل برای سیستم‌های حیاتی).
• بکاپ و بازیابی: برنامه بکاپ + گزارش اجرا + حداقل یک تست بازیابی مستند.
• لاگینگ و پایش: ثبت لاگ‌های ورود/تغییرات حساس + نگهداری/دسترسی مشخص + نمونه بازبینی لاگ یا هشدار.
• مدیریت رخداد: روش رسیدگی + کانال اعلام + حداقل یک رخداد ثبت‌شده یا تمرین‌شده + درس‌آموخته.
• مدیریت تغییرات: ثبت تغییرات مهم + تأیید + تست/rollback.
• امنیت تامین‌کننده‌ها: لیست تامین‌کنندگان کلیدی + ارزیابی ریسک حداقلی + بندهای امنیتی در قرارداد.
• آگاهی امنیت اطلاعات: آموزش پایه برای همه + ثبت حضور/اثربخشی حداقلی.
• طبقه‌بندی اطلاعات/دارایی‌ها: Asset Register حداقلی + سطح‌بندی داده‌های حساس + قواعد نگهداری/اشتراک‌گذاری.

B) سطح بالغ (Mature / Audit-Resilient)

• پایش اثربخشی کنترل‌ها: KPI/KRI تعریف شده و دوره‌ای بررسی می‌شود.
• مدیریت آسیب‌پذیری/وصله‌ها: روند منظم وصله‌گذاری + گزارش‌های دوره‌ای + اولویت‌بندی بر اساس ریسک.
• رمزنگاری و مدیریت کلیدها: سیاست رمزنگاری + کنترل دسترسی به کلیدها + مدیریت چرخه عمر کلیدها (حداقل برای داده حساس).
• DLP/کنترل نشت داده (در صورت نیاز کسب‌وکار): قواعد و شواهد کنترل خروج داده‌ها (ایمیل/Cloud/USB).
• امنیت توسعه و تغییرات نرم‌افزار (اگر دارید): کنترل دسترسی به repo، بازبینی کد، مدیریت اسرار (Secrets).
• تمرین BCP/DR: سناریوهای واقعی + نتایج تمرین + اقدام اصلاحی.
• بهبود تامین‌کنندگان: ارزیابی دوره‌ای، بازبینی SLAهای امنیتی، و پیگیری عدم انطباق تامین‌کننده.

چک‌لیست شواهد (Evidence Checklist)

این بخش را مثل “لیست خرید” ببین: اگر این‌ها را داشته باشی، Gap Analysis و بعدش ممیزی خیلی روان‌تر می‌شود.

Governance / ISMS

• Scope + خط‌مشی امنیت اطلاعات + اهداف امنیت اطلاعات
• Risk Methodology + Risk Register + Risk Treatment Plan
• SoA 2022 با دلیل انتخاب/عدم انتخاب
• کنترل مستندات (نسخه/تأیید/دسترسی/آرشیو)

Access

• تیکت‌های ایجاد/حذف دسترسی + تأیید مدیر
• گزارش بازبینی دوره‌ای دسترسی‌ها
• لیست حساب‌های ویژه + شواهد MFA/کنترل استفاده

Operations / Change

• Change Tickets / Change Log + تأیید + تست/نتیجه
• پیکربندی‌های کلیدی (در حد اسکرین‌شات/خروجی امن)

Backup / Recovery

• گزارش اجرای بکاپ‌ها
• گزارش تست بازیابی (Restore Test) + نتیجه + اقدام اصلاحی

Logging / Monitoring

• سیاست لاگینگ/نگهداری لاگ
• نمونه لاگ‌های ورود/تغییرات حساس
• نمونه هشدار/Alert و پیگیری آن

Incidents

• رکورد رخداد (تیکت/گزارش)
• RCA + اقدامات اصلاحی + وضعیت بستن

Suppliers

• لیست تامین‌کنندگان کلیدی
• ارزیابی ریسک تامین‌کننده
• بندهای امنیتی قرارداد + بازبینی دوره‌ای (اگر انجام شده)

People / Awareness

• برنامه آموزش + حضور و غیاب
• سنجش اثربخشی (کوییز/نتیجه کمپین)
• مدارک Onboarding/Offboarding + NDA (در صورت استفاده)

سوالات متداول (FAQ)

قدم بعدی

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

اگر هدف‌تان این است که هم از دوباره‌کاری جلوگیری کنید، هم روز ممیزی غافلگیر نشوید، بهترین مسیر این است که پروژه را «ریسک‌محور» و مرحله‌ای جلو ببرید، نه اینکه از روز اول درگیر تولید انبوه سند شوید. مسیر پیشنهادی ما معمولاً این‌طور جواب می‌دهد: اول Scope را یک‌صفحه‌ای و قابل دفاع می‌بندید (سایت‌ها/فرآیندها/سرویس‌ها/استثناها)، بعد یک Asset Register حداقلی و روش ریسک را آماده می‌کنید تا SoA روی هوا نوشته نشود.

سپس Gap Analysis را انجام می‌دهید اما با تمرکز روی شواهد واقعی: بندهای ۴ تا ۱۰ + کنترل‌های کلیدی Annex A (نسخه 2022) که بیشترین ریسک NCR را دارند. خروجی این مرحله باید یک ماتریس شکاف + برنامه اقدام اولویت‌بندی‌شده باشد؛ یعنی دقیقاً معلوم باشد کدام شکاف‌ها باید قبل از Stage 1/Stage 2 بسته شوند، مالک هر اقدام کیست، چه خروجی‌ای باید تولید شود و تا چه زمانی.

بعد از اینکه اقدامات P1/P2 را بستید، یک Readiness Check کوتاه انجام می‌دهید (در حد نمونه‌برداری از چند کنترل حیاتی و چند الزام مدیریتی مثل ممیزی داخلی/بازنگری مدیریت/اقدام اصلاحی). این کار مثل “تست نهایی” است: اگر این مرحله را جدی بگیرید، احتمال NCR در ممیزی اصلی به‌طور محسوسی پایین می‌آید و پروژه از حالت اضطراری خارج می‌شود.

مطالعه پیشنهادی: گواهینامه ایزو چیست و دقیقاً چه چیزی صادر می‌شود؟

درخواست مشاوره/برآورد زمان و هزینه

اگر می‌خواهید برای سازمان خودتان یک برآورد دقیق و قابل اتکا بگیرید (نه یک عدد کلی)، کافی است این چند اطلاعات را آماده کنید: حوزه فعالیت، تعداد سایت‌ها/شعبه‌ها، تعداد کارکنان، سرویس‌های حیاتی (ایمیل/ERP/وب‌سایت/CRM/محصول نرم‌افزاری)، میزان استفاده از Cloud یا برون‌سپاری، تعداد تأمین‌کنندگان کلیدی، و اینکه آیا قبلاً روی نسخه 2013 کار کرده‌اید یا نه. با همین ورودی‌ها می‌شود مشخص کرد Gap Analysis شما در کدام سناریو قرار می‌گیرد، چه عمقی از نمونه‌برداری لازم است، و چه زمان‌بندی واقع‌بینانه‌ای دارید.

مطالعه پیشنهادی: اخذ گواهینامه ایزو را از کجا شروع کنیم؟