چک‌لیست ممیزی ISO 27001 (نسخه 2022) + نمونه سوالات ممیز + فایل‌های آماده

اگر می‌خواهی قبل از اینکه ممیز بیرونی وارد سازمان شود، خودت دقیقاً بفهمی «کجای کار ISMS می‌لنگد»، چک‌لیست ممیزی ISO 27001 بهترین نقطه شروع است—به شرطی که فقط یک فایل تیک‌زدنی نباشد. ما در این مقاله چک‌لیستی می‌سازیم که هم الزامات اصلی استاندارد (بندهای ۴ تا ۱۰) را پوشش بدهد و هم کنترل‌های Annex A نسخه 2022 را طوری جلو ببرد که خروجی‌اش قابل دفاع باشد: از Scope و ارزیابی ریسک و SoA گرفته تا شواهد اجرایی، ثبت عدم‌انطباق و برنامه اقدام اصلاحی.

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

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

این چک‌لیست دقیقاً به درد چه کسی می‌خورد؟

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

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

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

ممیز داخلی: چطور سوال‌ها را Evidence-محور طراحی کنی

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

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

مدیرعامل/مدیریت ارشد: خروجی قابل تصمیم‌گیری (ریسک، اولویت‌ها، منابع)

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

وقتی این بخش درست اجرا شود، مدیریت ارشد به‌جای اینکه صرفاً «تأیید» کند، واقعاً می‌تواند جهت بدهد: Scope را واقع‌بینانه‌تر کند، اهداف امنیت اطلاعات را با KPIهای سازمان همسو کند، روی چند اقدام اصلاحی کلیدی سرمایه‌گذاری کند و مطمئن شود ممیزی داخلی تبدیل شده به یک ابزار کاهش ریسک و افزایش اعتماد مشتری—نه یک فعالیت تشریفاتی.

خروجی نهایی ممیزی داخلی چیست؟

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

برنامه ممیزی (Audit Plan) و معیارها/دامنه

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

در یک برنامه ممیزی خوب، حداقل این موارد باید شفاف باشد:

• Scope ممیزی (واحدها/فرآیندها/مکان‌ها/سامانه‌ها) و اینکه آیا ممیزی را فرآیندمحور می‌روید یا بندمحور
• معیارهای ممیزی: ISO 27001:2022 (الزامات بندهای 4 تا 10)، کنترل‌های Annex A که در SoA «قابل‌اعمال» اعلام شده‌اند، سیاست‌ها و روش‌های داخلی، و الزامات قانونی/قراردادی مرتبط
• برنامه زمان‌بندی: تاریخ، مدت، ترتیب جلسات، و اینکه هر بخش با چه کسانی مصاحبه می‌شود
• روش جمع‌آوری شواهد: بررسی مستندات/سوابق، مصاحبه، مشاهده، و در صورت نیاز تست‌های ساده (مثل نمونه‌گیری از لاگ‌ها یا بررسی نمونه‌ای از درخواست‌های دسترسی)
• نحوه نمونه‌برداری: تعداد نمونه‌ها، بازه زمانی نمونه‌ها (مثلاً 3 ماه اخیر)، و معیار انتخاب نمونه (تصادفی یا مبتنی بر ریسک)

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

مطالعه پیشنهادی: ممیزی داخلی چیست و چطور استاندارد اجرا می‌شود؟ / تجزیه‌وتحلیل شکاف ISO 27001 (Gap Analysis)

گزارش ممیزی + عدم انطباق/مشاهده/فرصت بهبود

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

در گزارش ممیزی معمولاً سه نوع نتیجه ثبت می‌شود:

• عدم انطباق (Nonconformity): یعنی یک الزام مشخص استاندارد/SoA/روش داخلی وجود دارد، اما شواهد نشان می‌دهد انجام نشده یا اثربخش نیست.
• مشاهده (Observation): الزام ممکن است فعلاً برقرار باشد، اما نشانه‌هایی از ضعف یا ریسک دیده می‌شود (مثلاً اجرا وابسته به افراد است، یا کنترل با یک نقطه شکست ساده می‌افتد).
• فرصت بهبود (Opportunity for Improvement – OFI): الزام را دارید، ولی می‌شود کاراتر/پایدارتر/کم‌ریسک‌تر اجرا کرد.

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

1. Requirement: دقیقاً کدام بند/کنترل/الزام؟
2. Evidence: چه شواهدی دیدید؟ (سند، رکورد، مصاحبه، مشاهده)
3. Gap/Impact: شکاف دقیقاً چیست و ریسک/اثر احتمالی آن چیست؟
4. (اختیاری ولی عالی) Reference: لینک/کد سند، شماره رکورد، تاریخ نمونه

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

برنامه اقدام اصلاحی (CAPA) + پیگیری اثربخشی

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

CAPA حرفه‌ای معمولاً دو لایه دارد:

• Correction (اصلاح فوری): اقدام سریع برای کنترل وضعیت (مثلاً بستن یک دسترسی اشتباه، تکمیل یک رکورد جاافتاده، یا اعمال یک تنظیم حیاتی)
• Corrective Action (اقدام اصلاحی ریشه‌ای): حل علت ریشه‌ای تا تکرار نشود (مثلاً اصلاح فرآیند Joiner/Mover/Leaver، آموزش، اصلاح فرم‌ها، به‌روزرسانی روش اجرایی، اتوماسیون کنترل‌ها)

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

• آیا در بازه 1 تا 3 ماه آینده همان خطا تکرار نشده؟
• آیا رکوردها کامل و به‌موقع ثبت شده‌اند؟
• آیا کنترل واقعاً اجرا می‌شود یا فقط روی کاغذ اصلاح شده؟
• آیا شاخص/لاگ/نمونه‌گیری این را تأیید می‌کند؟

در نهایت، وقتی این سه خروجی کنار هم قرار می‌گیرد (Audit Plan + Audit Report + CAPA/Evidence of Effectiveness)، ممیزی داخلی شما تبدیل می‌شود به چیزی که هم برای گواهی‌گیری قابل دفاع است، هم برای کاهش ریسک واقعی ارزش تولید می‌کند.

قبل از شروع: ممیزی ISO 27001 را درست بفهمیم

تفاوت Internal Audit با ممیزی صدور گواهی (Stage 1 / Stage 2)

ممیزی داخلی (Internal Audit) برای این نیست که فقط «نمره قبولی» بگیری؛ هدفش این است که قبل از ممیزی بیرونی، با نگاه بی‌طرفانه بفهمی سیستم واقعاً کار می‌کند یا فقط روی کاغذ درست به نظر می‌رسد. یعنی از دلِ شواهد (رکوردها، اجرا، مصاحبه‌ها، مشاهده‌ها) مشخص شود که الزامات ISO 27001 و کنترل‌های انتخاب‌شده در SoA واقعاً پیاده‌سازی شده‌اند، ریسک‌ها مدیریت می‌شوند و نقاط ضعف، قبل از اینکه تبدیل به عدم‌انطباق بیرونی شوند، کشف و اصلاح می‌گردند.

در مقابل، ممیزی صدور گواهی توسط نهاد صدور انجام می‌شود و خروجی‌اش تصمیم درباره صدور/عدم صدور گواهی است. اینجا نگاه ممیز بیرونی «تصمیم‌محور» است: آیا سازمان به‌طور قابل قبول با استاندارد منطبق است یا نه. بنابراین استانداردِ سخت‌گیری، نحوه ثبت عدم‌انطباق و حساسیت روی قابل‌دفاع بودن شواهد معمولاً بیشتر از ممیزی داخلی است.

Stage 1 معمولاً بیشتر روی آمادگی سیستم تمرکز دارد: دامنه (Scope) قابل دفاع است؟ مستندات کلیدی وجود دارد؟ روش ارزیابی ریسک و SoA و اهداف امنیت اطلاعات منطقی و قابل ردیابی هستند؟ ممیز در این مرحله دنبال این است که مطمئن شود شما “چیزی برای ممیزی شدن” دارید و مسیر Stage 2 می‌تواند معنی‌دار باشد.

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

اگر بخواهم خیلی ساده بگویم: ممیزی داخلی باید قبل از ممیزی بیرونی، همان سوال‌های سخت را از خودت بپرسد—اما با هدف «اصلاح و بهبود»، نه صرفاً «قبول شدن». هرچه ممیزی داخلی‌ات شبیه‌تر به Stage 2 و Evidence-محورتر باشد، ریسک غافلگیری در ممیزی گواهی کمتر می‌شود.

مطالعه پیشنهادی: ISO 27006-1:2024 و معیارهای انتخاب مرجع صدور/کیفیت ممیزی

«معیار ممیزی» دقیقاً چیست؟ (استاندارد، سیاست‌ها، الزامات قانونی/قراردادی، روش‌ها)

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

در ISO 27001، معیارهای معمول چند لایه‌اند. یک لایه‌اش الزامات بندهای 4 تا 10 است (Context تا Improvement). لایه بعدی Annex A است، اما نه همه کنترل‌ها؛ دقیقاً کنترل‌هایی که در Statement of Applicability گفته‌ای “قابل اعمال” هستند. یعنی SoA خودش تبدیل می‌شود به یکی از مهم‌ترین معیارهای ممیزی. اگر SoA دقیق و قابل دفاع نباشد، ممیزی Annex A هم از همان ابتدا می‌لنگد.

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

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

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

ممیزی نمونه‌برداری یعنی چه و چطور سوءبرداشت ایجاد می‌کند؟

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

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

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

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

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

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

این چک‌لیست وقتی «نتیجه واقعی» می‌دهد که مثل یک پروژه کوچک جلو برود: اول Scope و معیارها را قفل می‌کنی، بعد چک‌لیست را فرآیندمحور می‌چینی، بعد شواهد را نمونه‌برداری می‌کنی، و نهایتاً خروجی را به شکل عدم‌انطباق‌های قابل‌پیگیری و CAPA می‌بندی. برای اینکه مسیرت استاندارد و قابل دفاع باشد، چارچوب کلی ممیزی را از ISO 19011:2018 بگیر و جزئیات ممیزی ISMS را با ISO/IEC 27007:2020 هم‌راستا کن.

تعیین دامنه (Scope) و مرزهای ISMS + ریسک‌های کلیدی

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

بعد از Scope، دو چیز را به‌عنوان قطب‌نما کنار دستت بگذار:

1. ریسک‌های کلیدی (دارایی‌های حیاتی، داده‌های حساس، دسترسی‌های ممتاز، سرویس‌های حیاتی، برون‌سپاری/کلود)
2. تعهدات مهم (الزامات قانونی/قراردادی/مشتری)
   در ISO 27001، منطق انتخاب و اجرای کنترل‌ها باید به ریسک وصل باشد؛ پس اگر ریسک‌های کلیدی را اول کار شفاف نکنی، چک‌لیست Annex A هم تبدیل می‌شود به یک بررسی پراکنده.

یک کار خیلی کاربردی در همین مرحله: یک «نقشه ۱ صفحه‌ای Scope + دارایی‌های کلیدی + فرآیندهای اصلی» بساز. همین یک صفحه بعداً سرعت ممیزی را چند برابر می‌کند.

طراحی برنامه ممیزی و چک‌لیست بر اساس فرآیندها (نه فقط بندها)

اشتباه رایج این است که چک‌لیست را فقط بندبه‌بند جلو ببری (۴ تا ۱۰ + Annex A). این کار ممکن است پوشش استاندارد بدهد، اما معمولاً «واقعیت اجرا» را خوب شکار نمی‌کند. راه بهتر این است که چک‌لیست را روی فرآیندهای واقعی سازمان بچینی و بندها/کنترل‌ها را روی آن سوار کنی.

مثلاً به‌جای اینکه جداگانه درباره کنترل‌های دسترسی، تغییرات، تامین‌کننده، رخدادها سوال بپرسی، این‌ها را به شکل فرآیندی ممیزی کن:

• Joiner/Mover/Leaver (ورود/جابجایی/خروج کارکنان) → هم بندهای پشتیبانی و عملیات را پوشش می‌دهد، هم کنترل‌های دسترسی و نقش‌ها
• مدیریت تغییرات → هم کنترل‌های تکنولوژیک/سازمانی، هم عملیات و ارزیابی ریسک
• مدیریت رخداد امنیتی → هم Annex A، هم بند ۹ و ۱۰ (پایش، بهبود، اقدام اصلاحی)

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

جمع‌آوری شواهد: مستندات، سوابق، مصاحبه، مشاهده، تست

در ممیزی ISO 27001، «داشتن سند» کافی نیست؛ ممیز (داخلی یا بیرونی) دنبال زنجیره شواهد است: سیاست/روش → اجرا → رکورد → پایش و بهبود. برای همین ما شواهد را چهار لایه می‌بینیم:

1. مستندات: سیاست‌ها، روش‌ها، استانداردهای داخلی، SoA، روش ارزیابی ریسک
2. سوابق/رکوردها: لاگ‌ها، تیکت‌ها، گزارش رخداد، گزارش اسکن آسیب‌پذیری، رکورد آموزش، صورت‌جلسات بازنگری
3. مصاحبه: با نقش‌های کلیدی (IT, HR, مالک فرآیند، مدیر ISMS) برای سنجش «درک و اجرا»
4. مشاهده/تست: نمونه‌گیری عملی (مثلاً بررسی چند مورد واقعی از درخواست دسترسی، چند تغییر اخیر، چند رخداد ثبت‌شده)

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

امتیازدهی/سطح بلوغ (اختیاری) برای اولویت‌بندی اقدامات

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

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

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

بعد امتیاز را با «ریسک» ترکیب کن: هر کنترل/فرآیند که ریسک بالا + امتیاز پایین دارد، می‌شود اولویت شماره ۱ برای اقدام اصلاحی. این همان منطقی است که ISO 27001 هم از تو انتظار دارد (ریسک‌محور بودن تصمیم‌ها).

قواعد نوشتن عدم انطباق استاندارد (Requirement + Evidence + Gap)

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

• Requirement (الزام): دقیقاً کدام بند/کنترل/الزام داخلی؟
• Evidence (شاهد): چه چیزی دیدی/شنیدی/بررسی کردی؟ (با نمونه و تاریخ)
• Gap (شکاف): اختلاف دقیق بین الزام و وضعیت موجود چیست؟ (ترجیحاً با اثر/ریسک)

یک مثال کوتاه (سبک درست نوشتن):

• الزام: «سازمان باید ممیزی داخلی را در فواصل برنامه‌ریزی‌شده انجام دهد و نتایج را نگهداری کند.» (ارجاع به برنامه ممیزی/الزامات ممیزی)
• شاهد: «برای ۱۲ ماه گذشته برنامه ممیزی مصوب وجود ندارد و تنها یک گزارش ممیزی بدون دامنه/معیار/نمونه‌برداری ثبت شده است.»
• شکاف: «ممیزی داخلی طبق برنامه انجام نشده و سوابق برای اثبات پوشش و اثربخشی ممیزی کافی نیست؛ ریسک کشف‌نشدن گپ‌ها قبل از ممیزی بیرونی افزایش می‌یابد.»

نکته مهم: اگر خودت هم‌راستا با ISO 19011:2018 جلو بروی، کیفیت نوشتن عدم‌انطباق‌ها و مدیریت برنامه ممیزی‌ات استانداردتر می‌شود. (در سایت ISO حتی اشاره شده که نسخه جدید این راهنما در مسیر جایگزینی است؛ بنابراین در مستندسازی داخلی، نسخه مرجع را شفاف ذکر کن.)

بند 4) Context of the Organization — زمینه سازمان

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

شناسایی ذی‌نفعان و نیازمندی‌هایشان (قراردادی/قانونی/مشتری)

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

برای اینکه این بخش ممیزی‌پذیر و قابل دفاع شود، معمولاً یک «ثبت ذی‌نفعان و نیازمندی‌ها» لازم داریم که در آن مشخص باشد:

• هر ذی‌نفع دقیقاً چه الزام/انتظاری دارد (مثلاً بندهای امنیتی قرارداد، SLA، الزامات محرمانگی، الزامات نگهداری داده، الزام گزارش‌دهی رخداد، محدودیت‌های دسترسی، قوانین مرتبط با حریم خصوصی و…)
• این الزام‌ها کجا مدیریت می‌شوند (مالک الزام کیست؟ در کدام سند/فرآیند آمده؟ چطور پایش می‌شود؟)
• چه چیزی اثبات می‌کند که این نیازمندی‌ها رعایت شده‌اند (نمونه قرارداد، سیاست‌ها، رکوردهای پایش، گزارش ممیزی تأمین‌کننده، گزارش رخدادها، شواهد آموزش و آگاهی، و…)

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

تعریف Scope قابل دفاع + استثناها (اگر دارید، چرا و چطور)

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

یک Scope قابل دفاع معمولاً این ویژگی‌ها را دارد:

• مرزهای واضح: چه چیزی داخل است و چه چیزی خارج؛ با دلیل و منطق.
• اتصال مستقیم به واقعیت کسب‌وکار: مثلاً اگر شما سرویس SaaS می‌دهید، نمی‌شود محیط تولید، داده مشتری یا مدیریت دسترسی را خارج از Scope گذاشت.
• تعریف دقیق “اینترفیس‌ها”: اگر چیزی برون‌سپاری شده (مثلاً دیتاسنتر/کلود، پشتیبانی نرم‌افزار، SOC، توسعه)، باید در Scope مشخص باشد که امنیت آن چگونه مدیریت می‌شود (قرارداد، SLA، ارزیابی تأمین‌کننده، کنترل دسترسی، گزارش‌دهی رخداد و…).

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

1. استثناء ریسک غیرقابل قبول ایجاد نمی‌کند،
2. مسئولیت‌ها و کنترل‌ها در مرز Scope قطع نمی‌شود (یعنی داده/فرآیند در مرز امن مدیریت می‌شود)،
3. دلیل استثناء منطقی و مستند است (مثلاً خارج بودن یک شرکت زیرمجموعه که کاملاً جداست و هیچ تبادل داده/فرآیندی ندارد—و این جدا بودن هم شواهد دارد).

در ممیزی داخلی، یک تست سریع برای Scope این است: آیا می‌توانی در ۲ دقیقه به ممیز توضیح بدهی که «کسب‌وکار ما چیست، داده‌های حساس کجاست، جریان‌های کلیدی کدام‌اند، و ISMS دقیقاً کدام قسمت این جریان را کنترل می‌کند»؟ اگر این توضیح سخت است، Scope احتمالاً نیاز به بازنویسی دارد.

تعیین فرآیندهای ISMS و تعاملاتشان

ممیز در بند ۴ انتظار دارد شما ISMS را مثل یک سیستم مدیریتی واقعی ببینید، نه مجموعه‌ای از سندها. یعنی باید فرآیندهای کلیدی ISMS مشخص باشند، مالک داشته باشند، ورودی/خروجی داشته باشند، و تعاملشان با هم قابل ردیابی باشد.

برای کاربردی کردن این بخش، ما معمولاً یک «نقشه فرآیندهای ISMS» طراحی می‌کنیم که حداقل این‌ها را نشان بدهد:

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

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

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

بند 5) Leadership — رهبری

اگر بند ۴ “زمینه و مرزهای ISMS” را مشخص می‌کند، بند ۵ نشان می‌دهد این سیستم واقعاً «صاحب» دارد یا نه. ممیز در بند ۵ دنبال یک پیام روشن است: آیا مدیریت ارشد فقط یک سیاست امضا کرده، یا واقعاً امنیت اطلاعات را در تصمیم‌ها، منابع، اولویت‌ها و پاسخ‌گویی سازمان جاری کرده است؟ این بخش معمولاً جایی است که سیستم‌های صوری لو می‌روند؛ چون روی کاغذ همه چیز خوب است، اما شواهد مدیریتی وجود ندارد.

تعهد مدیریت ارشد: شواهد واقعی (نه فقط متن سیاست)

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

شواهدی که معمولاً تعهد را واقعی می‌کند این‌هاست: وقتی مدیریت ارشد Scope را تأیید کرده و برایش حد و مرز گذاشته، وقتی ریسک‌های کلیدی را پذیرفته/رد کرده و تصمیم درمان ریسک را امضا کرده، وقتی برای اقدامات امنیتی بودجه/منابع داده، و وقتی در برابر رخدادها یا عدم‌انطباق‌ها پیگیری و مطالبه‌گری کرده است. حتی اگر سازمان کوچک باشد، باز هم باید ردپای تصمیم مدیریتی وجود داشته باشد: یک صورت‌جلسه، یک ایمیل رسمی، یک تصمیم ثبت‌شده در Management Review، یا یک تاییدیه برای برنامه آموزش/ابزارهای امنیتی.

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

نقش‌ها و مسئولیت‌ها + اختیارها

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

در عمل، برای دفاع‌پذیری این بخش باید روشن باشد:

• چه کسی «مالک ISMS» است و چه کسی «مجری/هماهنگ‌کننده» است؛
• نقش‌ها در فرآیندهای کلیدی مثل ارزیابی ریسک، انتخاب کنترل‌ها (SoA)، مدیریت رخداد، مدیریت دسترسی، مدیریت تغییرات و تامین‌کنندگان دقیقاً چه کاری می‌کنند؛
• اگر یک ریسک یا عدم‌انطباق جدی شناسایی شد، چه کسی حق دارد موضوع را Escalate کند و چه کسی باید تصمیم بگیرد.

یک نکته خیلی کاربردی: نقش‌ها را فقط با عنوان شغلی ننویس؛ با “کاری که انجام می‌دهد” بنویس. مثلاً به‌جای اینکه بگویی «مدیر IT مسئول امنیت است»، مشخص کن در کنترل دسترسی‌ها چه مسئولیتی دارد، چه رکوردی تولید می‌کند، چه چیزی را تأیید می‌کند و به چه KPI یا گزارش دوره‌ای پاسخ می‌دهد. این مدل تعریف، هم ممیزی داخلی را ساده‌تر می‌کند، هم در Stage 2 از سوال‌های چالشی جلوگیری می‌کند.

سیاست امنیت اطلاعات: ابلاغ، درک، به‌روزرسانی

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

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

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

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

بند 6) Planning — برنامه‌ریزی

بند ۶ جایی است که ممیز می‌فهمد ISMS شما «تصمیم‌محور و ریسک‌محور» جلو می‌رود یا صرفاً یک‌سری سند تولید می‌کند. اگر این بند درست بسته شود، انتخاب کنترل‌ها در Annex A منطقی و قابل دفاع می‌شود، SoA معنی پیدا می‌کند، و در Stage 2 هم می‌توانی با شواهد واقعی نشان بدهی چرا فلان کنترل را اجرا کرده‌ای و چرا فلان ریسک را پذیرفته‌ای. اگر هم این بند ضعیف باشد، معمولاً سه دردسر همزمان داری: ارزیابی ریسک غیرواقعی، Treatment صوری، و اهداف امنیت اطلاعات بدون شاخص و پیگیری.

روش ارزیابی ریسک (Criteria، احتمال/اثر، پذیرش ریسک)

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

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

یک نشانه مهم بلوغ در این بخش این است که ارزیابی ریسک شما به «واقعیت سازمان» وصل باشد: یعنی دارایی‌های کلیدی واقعی (سیستم‌های حیاتی، داده مشتری، دسترسی‌های ممتاز، سرویس‌های کلود/برون‌سپاری) در Risk Register دیده شوند و ریسک‌ها با شواهد پشتیبانی شوند، نه حدس. در ممیزی داخلی بهتر است چند ریسک مهم را نمونه‌برداری کنی و ببینی آیا برایشان مالک (Risk Owner)، تاریخ بازنگری، و منطق امتیازدهی مشخص است یا نه. اگر این‌ها نباشد، معمولاً در Stage 1 گیر می‌دهد.

Risk Treatment Plan و پیوند با کنترل‌ها

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

ارزش واقعی Risk Treatment Plan زمانی دیده می‌شود که قابل ردیابی باشد: از ریسک → به تصمیم درمان → به کنترل/کنترل‌ها → به شواهد اجرا. این همان جایی است که باید پیوند بین RTP و SoA روشن باشد. یعنی اگر در RTP گفته‌ای ریسک با کنترل‌های Annex A کاهش می‌یابد، باید در SoA هم همان کنترل‌ها به‌عنوان قابل‌اعمال ثبت شده باشند و برایشان وضعیت پیاده‌سازی، مالک، و Evidence مشخص باشد.

در ممیزی داخلی، یک تست ساده اما خیلی افشاگر این است: یک ریسک کلیدی را انتخاب کن و مسیرش را کامل دنبال کن. آیا می‌توانی نشان بدهی این ریسک چرا امتیازش این است، چرا این درمان انتخاب شده، کدام کنترل‌ها برایش گذاشته‌ای، و شواهد اجرا کجاست؟ اگر در میانه مسیر “قطع” شد (مثلاً کنترل انتخاب شده ولی Evidence نیست، یا SoA چیزی می‌گوید و RTP چیز دیگر)، احتمال عدم‌انطباق در Stage 2 بالا می‌رود.

مطالعه پیشنهادی: پارامترهای ارزیابی ریسک مؤثر برای ISO 27001 (Risk Criteria واقعی)

اهداف امنیت اطلاعات + شاخص‌ها + برنامه تحقق

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

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

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

برنامه‌ریزی تغییرات ISMS

سازمان‌ها تغییر می‌کنند: سرویس جدید، جابه‌جایی زیرساخت، مهاجرت به کلود، تغییر تامین‌کننده، تغییر ساختار سازمانی، اضافه شدن سایت جدید، حتی تغییرات قانونی. بند ۶ می‌خواهد مطمئن شود وقتی این تغییرات رخ می‌دهد، ISMS “جا نمی‌ماند” و کنترل‌ها به هم نمی‌ریزند. بنابراین ممیزی این بخش یعنی بررسی اینکه شما برای تغییرات روش برنامه‌ریزی‌شده دارید یا هر تغییر، امنیت را به شکل اتفاقی تحت تأثیر قرار می‌دهد.

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

در ممیزی داخلی، بهترین روش این است که یک یا دو «تغییر واقعی اخیر» را نمونه‌برداری کنی و ببینی آیا تغییر در چارچوب ISMS مدیریت شده یا نه. اگر تغییرات بزرگ در سازمان رخ داده ولی Risk Register، SoA، یا برنامه‌های کنترل و پایش به‌روز نشده‌اند، این بخش احتمالاً یک گپ جدی دارد و بهتر است قبل از ممیزی بیرونی جمع شود.

بند 7) Support — پشتیبانی

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

منابع (بودجه/ابزار/نیروی انسانی)

ممیز در این قسمت دنبال این نیست که شما “خیلی هزینه کرده‌اید”؛ دنبال این است که منابع متناسب با ریسک‌ها و Scope هستند یا نه. یعنی اگر شما داده‌های حساس مشتری را مدیریت می‌کنید ولی هیچ ابزار پایه‌ای برای کنترل دسترسی، لاگینگ، بکاپ، مدیریت آسیب‌پذیری یا پاسخ‌گویی رخداد ندارید، بند ۷ از نظر ممیز ضعف دارد—even اگر سیاست‌هایتان عالی باشد.

شواهدی که این بخش را قابل دفاع می‌کند معمولاً این‌هاست:

• تخصیص نقش‌ها و زمان (چه کسی چه مقدار از زمانش روی ISMS است؟ مسئولیت‌ها فقط روی کاغذ نیست؟)
• وجود ابزارها/سرویس‌های حداقلی متناسب با ریسک (مثلاً IAM/MFA، بکاپ و تست بازیابی، لاگینگ/مانیتورینگ، ابزار مدیریت رخداد یا حداقل فرآیند ثبت و پیگیری)
• تصمیم‌های مدیریتی درباره اولویت‌بندی منابع (مثلاً چرا اول لاگینگ را تقویت کردید و بعد رفتید سراغ DLP—این “منطق” برای ممیز مهم است)
• برون‌سپاری‌ها: اگر بخشی از امنیت را برون‌سپاری کرده‌ای (SOC، تست نفوذ، کلود)، باید شواهد قرارداد/تعهدات امنیتی و پایش عملکرد وجود داشته باشد.

در ممیزی داخلی، یک روش کاربردی این است که منابع را به چند «ریسک کلیدی» گره بزنی: برای ریسک دسترسی‌های غیرمجاز، چه منابع/ابزارهایی داریم؟ برای ریسک از دست رفتن داده، چه منابعی داریم؟ اگر جواب‌ها مبهم بود، بند ۷ عملاً تبدیل می‌شود به نقطه ضعف Stage 2.

شایستگی، آموزش و آگاهی (Awareness)

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

در ممیزی، شواهد این بخش معمولاً در سه لایه بررسی می‌شود:

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

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

ارتباطات داخلی/خارجی (چه کسی، چه چیزی، چه زمانی)

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

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

• ارتباطات داخلی: گزارش‌دهی رخداد، اطلاع‌رسانی تغییرات حساس، اعلان‌های امنیتی، و مسیر Escalation (از کارمند تا مدیر ISMS تا مدیریت ارشد)
• ارتباطات خارجی: مشتریان، تامین‌کنندگان، نهادهای قانونی/رگولاتوری (در صورت نیاز)، و حتی رسانه (برای سازمان‌های حساس)
• زمان‌بندی و شرایط: چه زمانی باید اطلاع داده شود؟ چه چیزی قابل اعلام است و چه چیزی محرمانه است؟

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

کنترل مستندات و سوابق (Documented Information)

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

در ممیزی، دو مفهوم باید از هم جدا شوند:

• Document (مستند): سیاست‌ها، روش‌ها، دستورالعمل‌ها، فرم‌ها، SoA، روش ارزیابی ریسک
• Record (رکورد/سابقه): خروجی اجرای کار؛ مثل لاگ‌ها، تیکت‌ها، گزارش رخداد، رکورد آموزش، صورت‌جلسات بازنگری، نتایج اسکن آسیب‌پذیری

آنچه ممیز معمولاً بررسی می‌کند:

• آیا نسخه‌بندی و کنترل تغییرات دارید؟ (Version/Approval/Review date)
• آیا مشخص است چه کسی سند را ایجاد/تأیید/بازنگری می‌کند؟
• آیا دسترسی‌ها به مستندات کنترل شده است؟ (خصوصاً برای اسناد حساس مثل روش‌های دسترسی، طرح پاسخ‌گویی رخداد، لیست دارایی‌های حیاتی)
• آیا سوابق طبق دوره نگهداری مشخص نگهداری می‌شوند؟ (Retention)
• آیا می‌توانید «شواهد» را سریع و بدون آشفتگی پیدا کنید؟ (این در Stage 2 حیاتی است)

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

بند 8) Operation — عملیات

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

کنترل‌های عملیاتی برنامه‌ریزی‌شده (Operational planning & control)

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

در عمل، کنترل‌های عملیاتی معمولاً در چند فرآیند حیاتی خلاصه می‌شوند:

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

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

برای اینکه این بند در ممیزی داخلی خوب جمع شود، یک روش ساده اما موثر این است: برای هر فرآیند عملیاتی مهم، یک جدول خیلی کوتاه داشته باشی با چهار ستون:

1. فعالیت کلیدی، 2) مسئول، 3) رکورد/شاهد، 4) تناوب/زمان.
   همین جدول باعث می‌شود عملیات از حالت «متکی به حافظه افراد» خارج شود.

اجرای ارزیابی ریسک و Treatment در عمل (Evidence محور)

خیلی‌ها ارزیابی ریسک و Risk Treatment Plan را در بند ۶ تولید می‌کنند، اما در بند ۸ باید ثابت کنند که این‌ها واقعاً اجرا شده‌اند. یعنی Treatment فقط یک تصمیم نیست؛ یک سری اقدام عملی است که باید ردپایش در عملیات دیده شود.

ممیز در این بخش معمولاً سه نوع ردیابی انجام می‌دهد:

• از «ریسک» به «کنترل»: این ریسک با چه کنترل/اقدامی درمان شده؟
• از «کنترل» به «اجرا»: این کنترل کجا اجرا می‌شود؟ در کدام سیستم/فرآیند؟
• از «اجرا» به «رکورد»: چه چیزی نشان می‌دهد کنترل واقعاً انجام شده و ادامه‌دار است؟

مثال خیلی رایج: اگر در Risk Treatment گفته‌ای ریسک دسترسی غیرمجاز را با MFA و بازبینی دسترسی‌ها کاهش می‌دهی، در بند ۸ باید بتوانی نشان بدهی MFA واقعاً فعال است (نه فقط سیاستش وجود دارد) و بازبینی دسترسی‌ها رکورد دارد (نمونه بازبینی دوره‌ای، لیست دسترسی‌های اصلاح‌شده، تیکت‌های حذف دسترسی). یا اگر در Treatment گفته‌ای مدیریت آسیب‌پذیری انجام می‌دهی، باید خروجی اسکن، اولویت‌بندی اصلاحات، و شواهد Patch شدن را نشان بدهی.

یک تکنیک عملی برای ممیزی داخلی: “۳ ریسک کلیدی” انتخاب کن و برای هرکدام یک مسیر کامل Evidence بساز:

• Risk Register → تصمیم درمان → کنترل‌های مربوط → نمونه اجرای کنترل → رکوردها/لاگ‌ها/تیکت‌ها
  اگر یکی از این حلقه‌ها قطع باشد، احتمالاً بند ۸ یک گپ جدی دارد و بهتر است قبل از ممیزی بیرونی ترمیم شود.

مدیریت تغییرات و برون‌سپاری/تأمین‌کنندگان (در عملیات)

در بند ۸، تغییرات و تامین‌کنندگان دو نقطه‌ای هستند که بیشترین ریسک عملیاتی را وارد ISMS می‌کنند؛ چون کنترل‌ها معمولاً در همین دو جا دور زده می‌شوند: یا تغییرات سریع انجام می‌شود بدون ارزیابی امنیتی، یا سرویس/پیمانکار بیرونی می‌آید و مرزهای کنترل را مبهم می‌کند.

مدیریت تغییرات (Change Management) در عملیات یعنی:

• تغییرات مهم قبل از اجرا ارزیابی می‌شوند (حداقل از زاویه امنیت و ریسک)
• تأییدها مشخص است (چه کسی تغییر را مجاز می‌کند؟)
• تست/بازگشت (Rollback) و برنامه بازیابی برای تغییرات حساس وجود دارد
• بعد از تغییر، کنترل می‌کنی که تغییر اثر ناخواسته امنیتی ایجاد نکرده

ممیز معمولاً با نمونه‌برداری جلو می‌رود: چند Change اخیر را نشان بدهید (خصوصاً تغییرات مرتبط با دسترسی‌ها، شبکه، سرویس‌های اینترنتی، دیتابیس‌ها، کلود). اگر تغییرات انجام شده ولی هیچ رکوردی از ارزیابی ریسک/تأیید/تست نیست، بند ۸ عملاً “کنترل عملیاتی” ندارد.

برون‌سپاری/تأمین‌کنندگان هم در عملیات یعنی شما فقط قرارداد امضا نکرده‌ای؛ بلکه امنیت را در طول همکاری مدیریت می‌کنی. ممیز در این قسمت دنبال چند شاهد کلیدی است:

• معیارهای امنیتی در انتخاب تامین‌کننده (پیش از قرارداد)
• تعهدات امنیتی در قرارداد/SLA (گزارش‌دهی رخداد، دسترسی‌ها، محرمانگی، محل نگهداری داده، برگشت/حذف داده)
• کنترل دسترسی پیمانکاران (کمترین دسترسی، مدت‌دار، قابل لغو)
• پایش عملکرد تامین‌کننده و بازنگری دوره‌ای (حتی ساده: چک‌لیست ارزیابی سالانه یا هر ۶ ماه)
• مدیریت تغییر تامین‌کننده یا خاتمه همکاری (تحویل/حذف داده، لغو دسترسی‌ها، بستن حساب‌ها)

یک نقطه خیلی مهم که در ممیزی بیرونی زیاد گیر می‌دهد: سازمان‌ها تامین‌کننده را “خارج از Scope” تصور می‌کنند، در حالی که اگر تامین‌کننده روی داده یا سرویس حیاتی اثر دارد، شما باید نشان بدهید ریسک آن را مدیریت می‌کنید—even اگر سیستم‌ها دست شما نیست.

بند 9) Performance Evaluation — ارزیابی عملکرد

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

پایش و اندازه‌گیری (چه چیزی را چطور می‌سنجید؟)

در ISO 27001 صرفاً گفتن اینکه “پایش داریم” کافی نیست. ممیز دنبال این است که شما دقیقاً تعریف کرده باشید:

• چه چیزی را پایش می‌کنید (What)
• چطور اندازه‌گیری می‌کنید (How)
• چه زمانی/با چه تناوبی (When)
• چه کسی مسئول است (Who)
• نتیجه را کجا ثبت می‌کنید و چه تصمیمی از آن درمی‌آید (So what)

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

۱) شاخص‌های ریسک‌محور (Risk-based KPIs/KRIs)
این‌ها شاخص‌هایی هستند که مستقیم به ریسک‌های کلیدی شما وصل‌اند. مثال‌های رایج (بسته به سازمان): درصد سیستم‌های حیاتی با MFA فعال، تعداد حساب‌های ادمین بدون بازبینی دوره‌ای، تعداد تغییرات حساس بدون تأیید امنیتی، پوشش بکاپ و موفقیت تست بازیابی. نکته مهم این است که شاخص باید «قابل اندازه‌گیری با داده واقعی» باشد، نه شاخصی که آخرش با حدس پر می‌شود.

۲) شاخص‌های عملیات امنیت (Operational metrics)
این‌ها نشان می‌دهند کنترل‌ها در عمل کار می‌کنند: تعداد رخدادهای ثبت‌شده، میانگین زمان پاسخ‌گویی به رخداد (MTTR)، تعداد آسیب‌پذیری‌های High/Critical باز مانده و مدت ماندگاری‌شان، درصد Patch شدن سیستم‌ها در SLA تعیین‌شده، نرخ تکمیل آموزش‌های آگاهی. ممیز معمولاً دنبال روند (Trend) است: آیا بهتر می‌شوید یا فقط عددها را یک‌بار ثبت کرده‌اید؟

۳) شاخص‌های انطباق و اثربخشی (Compliance & effectiveness)
اینجا بحث فقط “انجام شد” نیست؛ “اثر داشت” مهم است. مثلاً اگر آموزش برگزار می‌کنی، آیا آزمون کوتاه/شبیه‌سازی فیشینگ/شاخص گزارش‌دهی رخداد نشان می‌دهد رفتار بهتر شده؟ اگر کنترل دسترسی داری، آیا نمونه‌برداری نشان می‌دهد دسترسی‌ها کم‌کم تمیزتر شده‌اند؟

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

برنامه و اجرای ممیزی داخلی (Audit Program)

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

یک Audit Program قابل دفاع معمولاً این ویژگی‌ها را دارد:

• سالانه/دوره‌ای است و پوشش می‌دهد که در چه بازه‌ای کدام فرآیندها/واحدها ممیزی می‌شوند.
• ریسک‌محور است: بخش‌های حساس‌تر (داده مشتری، دسترسی‌های ممتاز، کلود، رخدادها، تامین‌کنندگان) بیشتر و عمیق‌تر ممیزی می‌شوند.
• معیار مشخص دارد: بندهای ۴ تا ۱۰، کنترل‌های قابل‌اعمال SoA، سیاست‌ها/روش‌های داخلی، و تعهدات قانونی/قراردادی.
• روش نمونه‌برداری و روش جمع‌آوری شواهد مشخص است (مصاحبه/مستندات/مشاهده/تست نمونه‌ای).
• صلاحیت ممیز مشخص است و تعارض منافع مدیریت می‌شود (مثلاً کسی که خودش مجری همان فرآیند است، ممیز اصلی همان فرآیند نباشد).

در اجرا هم دو نکته معمولاً ممیزی داخلی را “واقعی” می‌کند:

1. گزارش ممیزی باید خروجی‌های قابل پیگیری داشته باشد (عدم انطباق/مشاهده/OFI) با ارجاع به Requirement و Evidence.
2. نتایج ممیزی باید وارد چرخه اقدام اصلاحی و بازنگری مدیریت شود؛ یعنی ممیزی داخلی نباید در پوشه بایگانی دفن شود.

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

بازنگری مدیریت (Management Review): ورودی‌ها/خروجی‌ها/تصمیم‌ها

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

• وضعیت ISMS را با داده واقعی دیده،
• درباره ریسک‌ها و اولویت‌ها تصمیم گرفته،
• منابع و اقدامات لازم را تعیین کرده،
• و این تصمیم‌ها قابل ردیابی هستند.

برای اینکه Management Review قابل دفاع باشد، بهتر است ورودی‌ها و خروجی‌ها را شفاف ببندی:

ورودی‌های کلیدی (Inputs)

• وضعیت اقدامات بازنگری قبلی (چه چیزهایی انجام شد/نشد و چرا)
• تغییرات داخلی/خارجی مرتبط با ISMS (تغییر سرویس، تغییر تامین‌کننده، تغییر قانونی، رشد سازمان، کلود، رخداد مهم)
• نتایج ممیزی داخلی و وضعیت عدم انطباق‌ها
• نتایج پایش و اندازه‌گیری (شاخص‌ها، روندها، عبور از آستانه‌ها)
• وضعیت رخدادهای امنیتی و درس‌آموخته‌ها
• وضعیت تحقق اهداف امنیت اطلاعات
• وضعیت ریسک‌ها و درمان ریسک (ریسک‌های جدید، ریسک‌های پذیرفته‌شده، نیاز به بازنگری SoA)

خروجی‌های کلیدی (Outputs / Decisions)

• تصمیم درباره بهبودها و اقدامات اصلاحی (چه کاری، با چه اولویتی)
• تصمیم درباره منابع (بودجه، ابزار، نیروی انسانی، برون‌سپاری)
• تصمیم درباره تغییرات مورد نیاز در ISMS (Scope، سیاست‌ها، فرآیندها، کنترل‌ها، SoA)
• تعیین/بازنگری اهداف امنیت اطلاعات و KPIها
• پذیرش/تغییر در سطح پذیرش ریسک (Risk acceptance) در صورت نیاز

نکته خیلی مهم: در ممیزی، “صورت‌جلسه” باید نشان بدهد مدیریت واقعاً تصمیم گرفته است، نه فقط “گزارش شنیده است”. یعنی باید اقدام‌ها، مسئول‌ها، موعدها و معیار پیگیری مشخص باشد. اگر خروجی‌ها قابل پیگیری نباشند، بند ۹ در عمل ضعیف می‌شود و بند ۱۰ (بهبود) هم روی هوا می‌ماند.

بند 10) Improvement — بهبود

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

عدم انطباق و اقدام اصلاحی (Root Cause + Effectiveness)

در ممیزی داخلی، عدم انطباق را نباید فقط به‌عنوان یک “ایراد” دید؛ عدم انطباق یک فرصت است برای اینکه ریسک را از ریشه کم کنی. اما شرطش این است که اقدام اصلاحی را درست اجرا کنی: Correction را از Corrective Action جدا کنی، علت ریشه‌ای را پیدا کنی، و بعد اثربخشی را بررسی کنی.

۱) Correction (اصلاح فوری)
این همان اقدام سریع برای کنترل وضعیت است؛ کاری که انجام می‌دهی تا مشکل همین الآن ادامه پیدا نکند. مثال: دسترسی اشتباه را حذف می‌کنی، یک تنظیم امنیتی را برمی‌گردانی، یک رکورد حیاتی را تکمیل می‌کنی، یا یک تغییر را Rollback می‌کنی.
ممیز معمولاً Correction را می‌پذیرد، اما اگر همین‌جا متوقف شوی، مشکل احتمالاً دوباره برمی‌گردد.

۲) Corrective Action (اقدام اصلاحی ریشه‌ای)
اینجا باید نشان بدهی چرا مشکل ایجاد شد و چه تغییری می‌دهی تا تکرار نشود. این بخش باید به Root Cause برسد، نه به علامت‌ها. مثلاً:

• اگر «حذف دسترسی کاربران خروجی» با تأخیر انجام می‌شود، علت ریشه‌ای احتمالاً “نبود فرآیند Joiner/Mover/Leaver با مالک مشخص” یا “عدم اتصال HR به IT” است؛ نه اینکه “فلانی فراموش کرد”.
• اگر «Patchها عقب می‌ماند»، علت ریشه‌ای می‌تواند “نبود SLA و اولویت‌بندی بر اساس ریسک” یا “نبود پنجره تغییرات” یا “نبود مسئول مشخص برای تایید Patch” باشد.

در ممیزی داخلی برای اینکه Root Cause واقعی باشد، بهتر است از یک روش ساده و قابل اجرا استفاده کنی (مثلاً 5 Whys یا Ishikawa) ولی مهم‌تر از روش، کیفیت نتیجه است: علت ریشه‌ای باید چیزی باشد که اگر اصلاحش کنی، مشکل واقعاً کمتر تکرار می‌شود.

۳) اثربخشی (Effectiveness Check)
این قسمت همان جایی است که خیلی‌ها اقدام اصلاحی را “می‌بندند” بدون اینکه اثربخشی را ثابت کنند. در ISO 27001، بستن اقدام اصلاحی یعنی نشان بدهی:

• اقدام انجام شده،
• و بعد از انجام، مشکل تکرار نشده یا به‌طور معنی‌دار کاهش یافته،
• و کنترل مرتبط واقعاً بهتر کار می‌کند.

برای اثربخشی، از قبل معیار بگذار. مثال‌های قابل دفاع:

• بازه ۳۰/۶۰/۹۰ روزه نمونه‌برداری از موارد مشابه (مثلاً درخواست‌های دسترسی یا تغییرات حساس)
• کاهش تعداد رخدادهای مشابه یا کاهش زمان پاسخ‌گویی
• تکمیل شدن رکوردها طبق SLA
• بهبود شاخص‌های پایش (مثلاً درصد سیستم‌های Patch شده در SLA)

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

بهبود مستمر: شواهد تغییر واقعی

بهبود مستمر یعنی ISMS فقط برای “حفظ وضعیت” نیست؛ باید با تغییرات و ریسک‌های جدید رشد کند. ممیز در این قسمت دنبال «شواهد تغییر» است، نه شعار. یعنی باید بتوانی نشان بدهی سیستم چگونه از تجربه‌ها و داده‌ها یاد گرفته و بهتر شده است.

بهبود مستمر معمولاً از چند منبع تغذیه می‌شود:

• نتایج ممیزی داخلی و بازنگری مدیریت
• رخدادهای امنیتی و درس‌آموخته‌ها
• نتایج پایش و اندازه‌گیری (KPI/KRIها)
• تغییرات فناوری/سرویس‌ها (کلود، سرویس جدید، ادغام سازمانی)
• بازخورد مشتریان/تأمین‌کنندگان/الزامات قانونی

اما “شواهد تغییر واقعی” دقیقاً چه شکلی است؟ چند نمونه کاملاً قابل دفاع:

• به‌روزرسانی SoA و منطق Applicability بعد از تغییر ریسک‌ها (نه فقط تغییر تاریخ)
• تغییر در فرآیندها (مثلاً اضافه شدن مرحله تأیید امنیتی به Change Management، یا ایجاد روال رسمی JML)
• تقویت کنترل‌ها و ابزارها بر اساس تحلیل رخداد/ریسک (مثلاً فعال‌سازی MFA برای حساب‌های ممتاز، بهبود لاگینگ، اضافه کردن مانیتورینگ روی سرویس‌های حیاتی)
• بهبود در آموزش و آگاهی با سنجش اثربخشی (مثلاً بعد از افزایش فیشینگ، کمپین آگاهی و سپس کاهش کلیک)
• بهبود در مدیریت تامین‌کنندگان (چک‌لیست ارزیابی امنیتی، بندهای قراردادی بهتر، پایش دوره‌ای)
• بهبود شاخص‌ها که روند آن نشان بدهد کنترل‌ها اثربخش‌تر شده‌اند (نه فقط یک عدد نقطه‌ای)

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

ساختار Annex A در 2022 و نحوه ممیزی آن

Annex A در نسخه 2022 یک «کاتالوگ کنترل‌های پیشنهادی» است که سازمان باید بر اساس ریسک‌ها، Scope و تعهدات قانونی/قراردادی از آن کنترل‌های لازم را انتخاب کند؛ نه اینکه صرفاً همه را تیک بزند. خود استاندارد هم صریح می‌گوید کنترل‌های Annex A کامل و exhaustiv نیستند و اگر لازم باشد می‌توان کنترل‌های دیگری هم اضافه کرد.
از طرف دیگر، کنترل‌ها در 2022 در چهار دسته/تم گروه‌بندی شده‌اند (سازمانی، افراد، فیزیکی، فناورانه) تا مالکیت و ممیزی‌شان ساده‌تر شود.

در ممیزی Annex A، ما عملاً سه سند/لایه را به هم وصل می‌کنیم: ارزیابی ریسک و Risk Treatment → Statement of Applicability (SoA) → شواهد اجرا (Evidence). اگر این زنجیره قابل ردیابی نباشد، Stage 2 معمولاً سخت می‌شود و عدم‌انطباق‌ها از همین‌جا بیرون می‌آید.

«کنترل قابل‌اعمال» یعنی چه؟ (Applicability)

«قابل‌اعمال بودن» یعنی این کنترل برای سازمان شما لازم است یا نه—با توجه به اینکه چه داده‌ای دارید، چه سرویس‌هایی ارائه می‌دهید، چه تهدیدهایی واقعی است، و چه تعهداتی به مشتری/قانون دارید. این تصمیم باید نتیجه‌ی فرآیند درمان ریسک باشد، نه سلیقه‌ای و نه بر اساس «فلان شرکت هم این را دارد».

در ممیزی داخلی، وقتی یک کنترل را “Applicable” می‌زنیم، ممیز (داخلی/بیرونی) معمولاً سه چیز می‌خواهد ببیند:
اول اینکه این کنترل به کدام ریسک/نیازمندی وصل است؛ دوم اینکه وضعیت اجرا چیست (طراحی شده؟ پیاده شده؟ پایش می‌شود؟)؛ و سوم اینکه Evidence واقعی‌اش کجاست. اگر کنترل را “Not applicable” زده‌ای، باز هم باید با منطق درمان ریسک توضیح بدهی چرا لازم نیست (مثلاً چون آن سناریوی ریسک در Scope شما وجود ندارد، یا با کنترل‌های دیگر معادل/کافی پوشش داده شده است). این نگاه ریسک‌محور دقیقاً همان چیزی است که استاندارد و یادداشت‌های راهنمای ممیزی هم روی آن تأکید دارند.

نکته کلیدی: «N/A» بدون توضیح، در عمل یعنی “ریسک را نفهمیده‌ایم”. اگر واقعاً N/A است، باید بتوانی آن را در دو سه خط دفاع کنی.

SoA چیست و ممیز از آن چه می‌خواهد؟

SoA (Statement of Applicability) سندی است که نشان می‌دهد شما کدام کنترل‌ها را لازم دانسته‌اید، چرا انتخاب کرده‌اید، وضعیت اجرا چیست، و چرا بعضی کنترل‌ها را حذف/غیرقابل‌اعمال کرده‌اید. SoA از مستندات الزامی و بسیار کلیدی در ISO 27001:2022 است و در ممیزی بیرونی حتماً درخواست می‌شود.

یک SoA قابل دفاع معمولاً این چهار ستون را (به هر قالبی) دارد:

• کنترل‌های لازم (نه الزاماً “همه کنترل‌ها”)
• دلیل انتخاب/گنجاندن کنترل‌ها
• وضعیت پیاده‌سازی (Implemented / Partially / Planned / Not implemented)
• توجیه حذف کنترل‌ها (وقتی Applicable نیست یا وقتی تصمیم گرفته‌ای به روش دیگری ریسک را مدیریت کنی)

خود متن استاندارد هم همین اجزا را برای SoA الزام می‌کند: کنترل‌های لازم + توجیه گنجاندن + وضعیت پیاده‌سازی + توجیه حذف کنترل‌های Annex A.

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

کنترل‌های انتخاب‌شده چطور به ریسک‌ها وصل می‌شوند؟

اینجا نقطه اصلی ممیزی Annex A است: کنترل‌ها باید از دل Risk Treatment بیرون آمده باشند و قابل ردیابی باشند. بهترین شکل اتصال، یک مسیر شفاف است:
Risk ID / سناریوی ریسک → تصمیم درمان (کاهش/انتقال/پذیرش/اجتناب) → کنترل(ها) → مالک کنترل → شواهد اجرا → شاخص/پایش اثربخشی

ممیز وقتی دنبال این ردیابی می‌گردد، معمولاً دو نوع ضعف را سریع پیدا می‌کند:

1. کنترل انتخاب شده ولی به هیچ ریسکی وصل نیست: یعنی کنترل‌ها از روی چک‌لیست آمده‌اند، نه از روی ریسک. این مورد معمولاً باعث می‌شود در Stage 2 نتوانی دفاع کنی “چرا این کنترل را داریم/نداریم”.
2. کنترل روی کاغذ هست ولی Evidence ندارد: یعنی در SoA نوشته‌ای Implemented، اما وقتی نمونه می‌خواهند، یا رکورد نیست یا فقط یک سند کلی نشان می‌دهی. اینجا بهتر است صادقانه وضعیت را “Partially/Planned” ثبت کنی و برایش برنامه اقدام اصلاحی بدهی؛ چون “Implemented بدون Evidence” ریسک عدم‌انطباق را بالا می‌برد.

مطالعه پیشنهادی: تغییرات ISO/IEC 27002:2022 و تاثیرش روی Annex A

تم ۱) کنترل‌های سازمانی (Organizational)

کنترل‌های سازمانی (در Annex A نسخه 2022 عموماً در خانواده A.5) همان بخش‌هایی هستند که نشان می‌دهند امنیت اطلاعات در سازمان شما «حاکمیت دارد» و فقط محدود به تیم IT نیست. ممیز در این تم معمولاً دنبال یک تصویر روشن است: آیا امنیت اطلاعات در سیاست‌ها، مالکیت‌ها، قراردادها، مدیریت رخداد و برنامه‌ریزی تداوم کسب‌وکار، تبدیل به روال اجرایی و قابل پایش شده یا نه. اگر این بخش درست بسته شود، بخش بزرگی از ریسک‌های Stage 2 از همان ابتدا کنترل می‌شود، چون خیلی از عدم‌انطباق‌های واقعی دقیقاً از همین جا بیرون می‌آیند: سیاست‌های صوری، مالکیت مبهم دارایی‌ها، تامین‌کننده‌های بدون کنترل، رخدادهای بدون درس‌آموخته، و BCP/DR بدون تست واقعی.

سیاست‌ها و حاکمیت امنیت اطلاعات

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

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

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

مدیریت دارایی‌ها و اطلاعات (طبقه‌بندی، مالکیت)

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

برای ممیزی عملی، ما معمولاً از سه نقطه شروع می‌کنیم:
اول «فهرست دارایی‌ها» (Asset Inventory) و اینکه مالک دارایی (Asset Owner) و مالک اطلاعات (Information Owner) واقعاً مشخص است یا فقط اسم نوشته شده. دوم «طبقه‌بندی» و اینکه معیار طبقه‌بندی قابل فهم و قابل اجرا هست یا نه. سوم «رفتار واقعی با اطلاعات طبقه‌بندی‌شده»؛ یعنی آیا برچسب‌گذاری، کنترل دسترسی، اشتراک‌گذاری، نگهداری و حذف اطلاعات طبق طبقه‌بندی انجام می‌شود؟

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

مدیریت تأمین‌کنندگان و قراردادها

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

در ممیزی داخلی، بهترین روش این است که چند تامین‌کننده را بر اساس ریسک دسته‌بندی کنی (حیاتی/متوسط/کم‌ریسک) و برای تامین‌کننده‌های حیاتی، شواهد زیر را دنبال کنی: آیا معیارهای امنیتی در انتخاب وجود داشته؟ آیا در قرارداد بندهای امنیتی روشن هست (محرمانگی، گزارش‌دهی رخداد، محل نگهداری داده، زیرپیمانکار، حذف/بازگشت داده در پایان قرارداد، حق ممیزی یا حداقل حق دریافت گزارش)؟ آیا دسترسی‌های پیمانکاران محدود، مدت‌دار و قابل لغو بوده؟ آیا پایش دوره‌ای انجام می‌شود یا فقط یک‌بار در شروع همکاری بررسی شده؟

نقطه‌ای که معمولاً Stage 2 گیر می‌دهد:
سازمان می‌گوید “دیتا روی کلود است، مسئولیت با تامین‌کننده است.” ممیز معمولاً این را نمی‌پذیرد. شما باید نشان بدهی ریسک تامین‌کننده را مدیریت کرده‌ای: قرارداد، کنترل دسترسی، مانیتورینگ، و برنامه واکنش در صورت رخداد.

مدیریت رخداد امنیتی و درس‌آموخته‌ها

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

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

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

تداوم کسب‌وکار و آمادگی (BCP/DR از نگاه امنیت)

در این قسمت، ممیز می‌خواهد مطمئن شود سازمان فقط درباره “در دسترس بودن” حرف نمی‌زند؛ بلکه برای تداوم سرویس‌های حیاتی و حفاظت از اطلاعات در شرایط بحران آماده است. اینجا سه تکه مهم داریم: شناسایی سرویس‌های حیاتی و RTO/RPO (در حد نیاز سازمان)، برنامه‌های تداوم/بازیابی، و تست واقعی.

ممیزی BCP/DR وقتی قانع‌کننده می‌شود که شما برای سرویس‌ها و داده‌های حیاتی، برنامه‌ عملی دارید و حداقل چند شواهد کلیدی ارائه می‌دهید: وجود بکاپ، نگهداری امن بکاپ، کنترل دسترسی به بکاپ‌ها، و مهم‌تر از همه «تست بازیابی» با خروجی مستند. خیلی از سازمان‌ها بکاپ دارند اما هیچ‌وقت بازیابی را تست نکرده‌اند؛ این دقیقاً همان نقطه‌ای است که در ممیزی بیرونی می‌تواند به ضعف جدی تبدیل شود، چون “قابلیت بازیابی” بدون تست، قابل اثبات نیست.

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

تم ۲) کنترل‌های مرتبط با افراد (People)

کنترل‌های مرتبط با افراد در Annex A نسخه 2022 (عموماً در خانواده A.6) دقیقاً همان جایی است که خیلی از رخدادها از آن شروع می‌شود: خطای انسانی، دسترسی‌های باقی‌مانده بعد از خروج، ناآگاهی از سیاست‌ها، یا رفتارهای پرریسک در کار روزمره. ممیز در این تم دنبال یک تصویر روشن است: آیا سازمان شما برای «عامل انسانی» فقط شعار دارد، یا واقعاً با فرآیندهای منابع انسانی، آموزش، آگاهی و پاسخ‌گویی، ریسک را مدیریت می‌کند.

نکته مهم این است که در ممیزی ISO 27001، “People Controls” معمولاً با یک سند حل نمی‌شود؛ باید ردپای اجرا در فرآیندهای HR + رکوردهای آموزشی + شواهد پذیرش سیاست‌ها + نمونه‌های عملی مدیریت تخلف دیده شود.

منابع انسانی قبل/حین/بعد از همکاری

اینجا ممیز می‌خواهد مطمئن شود امنیت اطلاعات در چرخه عمر همکاری افراد “درست و کامل” مدیریت می‌شود؛ یعنی از قبل از استخدام/شروع همکاری تا زمان خروج. چون اگر Joiner/Mover/Leaver درست نباشد، تقریباً مطمئن باش در Stage 2 روی دسترسی‌ها و مالکیت‌ها گیر می‌خوری.

قبل از شروع همکاری (Pre-employment / Pre-engagement)
در ممیزی، مواردی که معمولاً بررسی می‌شود:

• آیا نقش‌های حساس (مثل ادمین‌ها، دسترسی به داده مشتری، مالی، توسعه‌دهندگان) تعریف شده‌اند و سطح حساسیتشان معلوم است؟
• آیا تعهدات محرمانگی (NDA/Confidentiality) متناسب با نقش وجود دارد؟
• آیا بررسی‌های لازم (در حد سیاست سازمان و قوانین) برای نقش‌های حساس انجام می‌شود یا حداقل تصمیمش مستند است؟

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

حین همکاری (During employment / engagement)
این قسمت معمولاً به سه موضوع گره می‌خورد: آگاهی، رعایت سیاست‌ها، و کنترل دسترسی‌ها. ممیز می‌پرسد:

• آیا افراد مرتبط، آموزش و آگاهی لازم را گرفته‌اند و این آموزش‌ها تکرارشونده است؟
• آیا سیاست‌ها و دستورالعمل‌ها (مثل استفاده قابل قبول از منابع، رمز عبور/MFA، کار از راه دور، گزارش‌دهی رخداد) به افراد رسیده و پذیرفته شده؟
• آیا تغییر نقش/جابجایی (Mover) باعث تغییر دسترسی‌ها می‌شود یا دسترسی‌ها انباشته می‌ماند؟

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

بعد از پایان همکاری (Termination / Change of contract)
اینجا یکی از پرتکرارترین نقاط ضعف در ممیزی‌هاست. ممیز معمولاً دنبال شواهد زیر است:

• فرآیند خروج (Leaver) تعریف شده و مالک دارد (HR اطلاع می‌دهد، IT اقدام می‌کند، مالک فرآیند تأیید می‌کند).
• حذف/غیرفعال‌سازی دسترسی‌ها سریع و قابل ردیابی انجام می‌شود (SLA مشخص یا حداقل عرف مشخص).
• تحویل/بازپس‌گیری تجهیزات و دارایی‌ها ثبت می‌شود.
• دسترسی‌های طرف ثالث/پیمانکار هم در خروج کنترل می‌شود (حساب‌های موقت، دسترسی‌های مدت‌دار).

در مقاله‌ات اگر می‌خواهی این بخش “خیلی کاربردی” شود، پیشنهاد می‌کنم یک ردیف چک‌لیست اختصاصی برای Joiner/Mover/Leaver بگذاری، چون ممیز بیرونی هم معمولاً از همین مسیر وارد می‌شود.

آموزش و آگاهی امنیتی + سنجش اثربخشی

آموزش و آگاهی در ISO 27001 دو سطح دارد:

• Training (آموزش نقش‌محور): برای کسانی که اجرای کنترل‌ها دست آن‌هاست (ادمین‌ها، توسعه، پشتیبانی، HR، مالک‌های داده).
• Awareness (آگاهی عمومی): برای همه کارکنان، تا ریسک‌های رایج (فیشینگ، اشتراک‌گذاری داده، رمز عبور، کار از راه دور) را بشناسند و رفتار درست داشته باشند.

ممیز فقط “لیست حضور و غیاب” نمی‌خواهد؛ دنبال این است که آگاهی واقعاً اثر داشته. بنابراین در ممیزی داخلی بهتر است سه لایه شواهد را آماده داشته باشی:

۱) برنامه و پوشش

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

۲) رکوردها و ردیابی

• رکورد آموزش (تاریخ، محتوا، مخاطب، مدرس/منبع، مدت)
• ردیابی تکمیل آموزش (Completion rate)
• پذیرش سیاست‌ها بعد از آموزش (Acknowledgement)

۳) اثربخشی (Effectiveness)
اینجا لازم نیست پیچیده عمل کنی؛ کافی است یک یا دو معیار داشته باشی که نشان بدهد آموزش “اثر” گذاشته:

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

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

مسئولیت‌پذیری، پذیرش سیاست‌ها، تخلفات

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

پذیرش سیاست‌ها و مسئولیت‌پذیری
شواهدی که این بخش را محکم می‌کند:

• Acknowledgement رسمی (دیجیتال یا کتبی) برای سیاست‌های کلیدی مثل Acceptable Use، محرمانگی، کار از راه دور، گزارش‌دهی رخداد
• تعریف مسئولیت‌ها در شرح شغل یا دستورالعمل‌های داخلی برای نقش‌های حساس
• کانال گزارش‌دهی رخداد/رفتار مشکوک و اینکه کارکنان آن را می‌شناسند

مدیریت تخلفات و اقدامات اصلاحی
ممیز معمولاً می‌خواهد بداند اگر نقض سیاست یا رفتار پرریسک رخ داد:

• چگونه ثبت می‌شود (Incident/Nonconformity/HR case)
• چه کسی بررسی می‌کند و تصمیم می‌گیرد
• اقدامات اصلاحی/پیشگیرانه چیست (آموزش مجدد، محدودسازی دسترسی، اصلاح فرآیند، اقدام انضباطی در صورت نیاز)
• آیا درس‌آموخته‌ها به ISMS برمی‌گردد (مثلاً بهبود آموزش، بهبود فرآیند دسترسی، تغییر کنترل‌ها)

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

تم ۳) کنترل‌های فیزیکی (Physical)

کنترل‌های فیزیکی در Annex A نسخه 2022 (عموماً در خانواده A.7) برای خیلی از سازمان‌ها «کم‌اهمیت» به نظر می‌رسد، چون ذهن همه سریع می‌رود سمت کنترل‌های IT. اما در ممیزی ISO 27001، کنترل فیزیکی دقیقاً همان بخشی است که ثابت می‌کند شما امنیت اطلاعات را فقط در سطح نرم‌افزار نمی‌بینید. یک دسترسی فیزیکی کنترل‌نشده به اتاق سرور، یک لپ‌تاپ رهاشده، یا یک کاغذ چاپ‌شده روی میز، می‌تواند همان‌قدر خطرناک باشد که یک ضعف شبکه‌ای. ممیز در این تم معمولاً دنبال سه چیز است: مرزبندی «نواحی امن»، کنترل ورود/خروج افراد و بازدیدکنندگان، و حفاظت از تجهیزات/رسانه‌ها در طول چرخه عمرشان.

کنترل دسترسی فیزیکی، نواحی امن، بازدیدکنندگان

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

در ممیزی داخلی، این بخش را با یک مسیر ساده و کاملاً عملی بررسی کن:

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

یک نقطه‌ای که در ممیزی بیرونی خیلی گیر می‌دهد، “تضاد بین سیاست و واقعیت” است: روی کاغذ نوشته‌اید «اتاق سرور فقط با دسترسی مجاز» اما در عمل کلید دست همه است یا درِ اتاق باز می‌ماند. برای همین در ممیزی داخلی بهتر است علاوه بر بررسی سندها، یک Walkthrough کوتاه انجام بدهی: واقعاً برو و ببین درِ نواحی حساس چگونه کنترل می‌شود، و یک یا دو نمونه رکورد ورود/بازدید (اگر دارید) را هم بررسی کن. اگر رکورد ندارید، حداقل باید یک کنترل قابل مشاهده وجود داشته باشد (قفل، دسترسی محدود، همراهی بازدیدکننده، و…).

حفاظت از تجهیزات و رسانه‌ها

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

برای ممیزی کاربردی، این موارد را شفاف بررسی کن:

• مالکیت و تحویل‌گیری تجهیزات: آیا مشخص است هر لپ‌تاپ/گوشی/تجهیز به چه کسی تحویل شده؟ رکورد تحویل/عودت دارید؟
• حفاظت در محل: نگهداری در کمد قفل‌دار برای تجهیزات حساس، عدم رهاسازی روی میز، سیاست Clean Desk/ Clear Screen برای فضاهای حساس (لازم نیست سخت‌گیرانه باشد، اما باید حداقل برای داده‌های حساس تعریف شود).
• جابه‌جایی و خروج از سازمان: اگر لپ‌تاپ/هارد از محل خارج می‌شود، آیا مجاز است؟ چه کسی تأیید می‌کند؟ آیا رمزگذاری/کنترل‌های لازم انجام شده؟
• رسانه‌های بکاپ و ذخیره‌سازی: بکاپ‌ها کجا نگهداری می‌شوند؟ دسترسی به آن‌ها محدود است؟ اگر بکاپ آفلاین دارید، نگهداری فیزیکی‌اش چگونه است؟
• امحاء یا Disposal امن: وقتی تجهیز از رده خارج می‌شود یا به تعمیرگاه می‌رود، اطلاعات روی آن چگونه پاک می‌شود؟ آیا روال و رکورد دارید (حتی ساده: فرم امحاء/پاک‌سازی)؟

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

کار در محل/دورکاری از منظر کنترل فیزیکی

دورکاری و کار خارج از سایت، یک موضوع ترکیبی است: هم People Controls دارد، هم Technological، اما در تم فیزیکی تمرکز روی این است که محیط کار بیرون از سازمان هم «حداقل‌های حفاظت فیزیکی» را رعایت کند. ممیز دنبال این نیست که خانه کارمند را با استاندارد اتاق سرور مقایسه کند؛ دنبال این است که سازمان ریسک‌های واضح را شناسایی کرده و برایشان قاعده گذاشته است.

در ممیزی داخلی، برای کار در محل/دورکاری این موارد را بررسی کن:

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

برای کاربردی شدن این بخش در مقاله، پیشنهاد می‌کنم یک روال خیلی ساده اضافه کنی: “حداقل الزامات دورکاری” در ۸–۱۰ خط که دقیقاً رفتارهای پرریسک را پوشش بدهد (کار در مکان عمومی، قفل کردن، نگهداری اسناد، گزارش‌دهی). همین حداقل‌ها در ممیزی بیرونی یک امتیاز جدی محسوب می‌شود چون نشان می‌دهد سازمان به ریسک‌های واقعی فکر کرده و کنترل گذاشته است.

تم ۴) کنترل‌های فناورانه (Technological)

کنترل‌های فناورانه جایی است که ممیز خیلی سریع می‌فهمد امنیت اطلاعات شما «واقعاً در سیستم‌ها جاری است» یا بیشتر روی کاغذ و سیاست‌ها مانده. نکته مهم این است که در ممیزی ISO 27001، صرفِ داشتن ابزار یا تنظیمات فنی کافی نیست؛ ممیز دنبال یک زنجیره قابل دفاع است: سیاست و نقش‌ها → پیاده‌سازی فنی → رکورد/لاگ → پایش و بهبود. پس ما این تم را طوری ممیزی می‌کنیم که هم شواهد اجرایی داشته باشد، هم بتوانی نشان بدهی کنترل‌ها پایدارند و به افراد وابسته نیستند.

کنترل دسترسی منطقی (IAM، MFA، Joiner/Mover/Leaver)

در این بخش، ممیز معمولاً از «مهم‌ترین ریسک سازمان» شروع می‌کند: دسترسی. یعنی چه کسی به چه چیزی دسترسی دارد، چرا دارد، و چطور این دسترسی کنترل و بازنگری می‌شود. اگر IAM و MFA و چرخه عمر دسترسی‌ها (Joiner/Mover/Leaver) مرتب نباشد، حتی با بهترین سیاست‌ها هم احتمال عدم‌انطباق و حتی رخداد واقعی بالا می‌رود.

از نگاه ممیزی، چند نشانه خیلی تعیین‌کننده است: آیا MFA برای حساب‌های حساس (ادمین‌ها، دسترسی به سیستم‌های حیاتی، ایمیل سازمانی، کنسول‌های کلود) واقعاً فعال است؟ آیا اصل حداقل دسترسی و تفکیک وظایف در نقش‌ها دیده می‌شود یا همه دسترسی‌های اضافه دارند؟ آیا برای تغییر نقش یا خروج افراد، دسترسی‌ها سریع حذف/اصلاح می‌شود و رکورد دارد؟ ممیز معمولاً چند نمونه واقعی می‌خواهد: ۲–۳ درخواست دسترسی اخیر، ۱–۲ نمونه خروج یا تغییر نقش، و یک نمونه بازبینی دوره‌ای دسترسی‌ها. اگر در این نمونه‌ها تاییدها، تاریخ‌ها، و دلیل دسترسی‌ها روشن نباشد، این بخش تبدیل به گپ جدی می‌شود.

امنیت شبکه و تفکیک (Segmentation)

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

در ممیزی داخلی، این بخش را با سوال‌های عملی جلو ببرید: آیا نقشه یا توصیف قابل فهمی از معماری شبکه دارید که نشان دهد چه VLAN/Zoneهایی دارید و چرا؟ آیا دسترسی از شبکه کاربری به سرورها محدود و مبتنی بر نیاز است؟ آیا دسترسی‌های مدیریتی از مسیر امن انجام می‌شود (مثلاً از طریق Jump host/VPN/شبکه مدیریت) یا هر کسی از هر جا می‌تواند به سیستم‌های حساس وصل شود؟ ممیز معمولاً یک نمونه از Ruleهای فایروال یا سیاست‌های دسترسی شبکه را می‌خواهد، و یک تست ساده: “از کجا به کجا اجازه دارید؟” اگر پاسخ‌ها شفاهی باشد و سند/پیکربندی قابل ارائه نباشد، این بخش در Stage 2 سخت می‌شود.

رمزنگاری و مدیریت کلیدها

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

برای ممیزی قابل دفاع، باید بتوانی نشان بدهی داده‌های حساس شما در سه حالت مهم چگونه محافظت می‌شوند: در حال انتقال (in transit)، در حال ذخیره (at rest) و در بکاپ‌ها. سپس ممیز معمولاً سراغ مدیریت کلید می‌رود: کلیدها کجا نگهداری می‌شوند؟ دسترسی به کلیدها محدود است؟ چرخش کلید/گواهی‌نامه‌ها برنامه دارد؟ چه کسی مسئول است و چه رکوردی وجود دارد؟ اگر از سرویس‌های کلودی استفاده می‌کنید، ممیز می‌خواهد بداند مدل مسئولیت مشترک را فهمیده‌اید و تنظیمات مربوط به کلیدها/رمزنگاری را رها نکرده‌اید.

لاگینگ/مانیتورینگ و پاسخ‌گویی

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

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

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

مدیریت آسیب‌پذیری و Patch

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

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

بکاپ، بازیابی، و تست‌های دوره‌ای

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

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

چک‌لیست Stage 1 (Document Review) — دقیقاً چه چیزهایی باید آماده باشد؟

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

مستندات حداقلی الزامی

اگر بخواهم خیلی عملی بگویم، «حداقل بسته Stage 1» باید طوری باشد که ممیز بتواند در ۳۰–۶۰ دقیقه تصویر کامل طراحی ISMS شما را ببیند (Scope، ریسک، انتخاب کنترل‌ها، و نحوه کنترل مستندات). معمولاً این‌ها در Stage 1 چک می‌شوند: Scope، خط‌مشی امنیت اطلاعات، روش‌شناسی ارزیابی ریسک، رجیستر ریسک، برنامه درمان ریسک، SoA، نقش‌ها و مسئولیت‌ها، و برنامه‌ریزی ممیزی داخلی و بازنگری مدیریت.

پیشنهاد من این است که این بسته را (ترجیحاً در یک فولدر واحد یا یک لینک Share امن) با این ساختار آماده کنی:

1. Scope ISMS (دامنه و مرزها): دقیقاً چه واحدها/فرآیندها/مکان‌ها/سیستم‌ها داخل Scope هستند و هر Exclusion چرا و با چه منطق/توجیهی انجام شده.
2. خط‌مشی امنیت اطلاعات (Information Security Policy): نسخه، تاریخ تأیید، مالک سند، و اینکه با Scope و جهت‌گیری سازمان هم‌راستا است.
3. اهداف امنیت اطلاعات + برنامه تحقق (Objectives & plan): هدف‌ها باید قابل سنجش و ردیابی باشند (حتی اگر ساده‌اند).
4. تعریف نقش‌ها و مسئولیت‌ها در ISMS: حداقل نقش‌هایی مثل ISMS Manager/Owner، مالکان دارایی/فرآیندهای حساس، و مسیر گزارش‌دهی/تصمیم‌گیری.
5. روش‌شناسی ارزیابی ریسک + معیار پذیرش ریسک: اینکه ریسک را چطور شناسایی/امتیازدهی می‌کنید، معیار Impact/Likelihood چیست، و از چه سطحی به بعد ریسک «غیرقابل قبول» می‌شود.
6. خروجی ارزیابی ریسک (Risk Register/Report): ریسک‌های کلیدی، دارایی/فرآیند مرتبط، کنترل‌های موجود، و تصمیم درمان پیشنهادی.
7. Risk Treatment Plan (RTP): برای ریسک‌های غیرقابل قبول، دقیقاً چه اقدام/کنترلی، با چه مالک و موعدی اجرا می‌شود.
8. Statement of Applicability (SoA): لیست کنترل‌های Annex A + وضعیت اجرا + توجیه انتخاب/عدم انتخاب (و بهتر: لینک به ریسک/نیازمندی مربوط).
9. کنترل مستندات و سوابق (Documented Information Control): روال نسخه‌بندی، تأیید، بازنگری، دسترسی، و نگهداری—چون Stage 1 اساساً روی “کنترل‌پذیر بودن” مستندات حساس است.

دو نکته برای اینکه Stage 2 کم‌ریسک‌تر شود:

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

SoA و RTP و ریسک‌ها (تست سریع قابل‌قبول بودن)

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

برای اینکه خودت قبل از ممیز، یک تست سریع و سخت‌گیرانه انجام بدهی، این چند چک را اجرا کن:

1. هر ریسک غیرقابل قبول باید درمان داشته باشد: اگر در Risk Register ریسک High/Critical داری ولی در RTP برایش اقدام/مالک/موعد مشخص نیست، Stage 1 معمولاً همان‌جا علامت خطر می‌زند.
2. RTP باید اجرایی باشد، نه شعاری: یعنی کنار هر اقدام، حداقل «مالک + تاریخ هدف + نتیجه مورد انتظار/خروجی» مشخص باشد (صرف نوشتن “پیاده‌سازی کنترل‌ها” کافی نیست).
3. SoA باید سه چیز را شفاف بگوید: کنترل انتخاب شده/نشده، وضعیت پیاده‌سازی، و توجیه انتخاب/عدم انتخاب. اگر “N/A” زیاد داری ولی توجیه‌ها کلی است، دفاع سخت می‌شود.
4. صداقت در وضعیت اجرا (Implementation status): اگر کنترل را “Implemented” زده‌ای، باید بتوانی در Stage 2 شواهد واقعی نشان بدهی. اگر هنوز در حال اجراست، “Planned/Partially” بهتر از ادعای کامل است (این کار ریسک عدم‌انطباق را کم می‌کند).
5. ردیابی ۳تایی را برای چند نمونه تست کن: ۳ ریسک کلیدی را انتخاب کن و مسیر را کامل برو: Risk → تصمیم درمان → کنترل(های) SoA → اقدام RTP. اگر در هر نقطه لینک/ارجاع مبهم شد، یعنی زنجیره هنوز محکم نیست. (این دقیقاً همان چیزی است که راهنمای ممیزی روی آن حساس است.)
6. هم‌خوانی معیارها: معیار پذیرش ریسک، امتیازدهی، و اولویت‌بندی RTP باید با هم سازگار باشند؛ نباید ریسک با امتیاز پایین در RTP جلوتر از ریسک‌های بالاتر قرار بگیرد مگر اینکه دلیل کسب‌وکاری/قانونی واضح داشته باشد.
7. توابع پشتیبان را فراموش نکن: اگر در SoA کنترل‌های مهمی را Applicable کرده‌ای (مثل دسترسی، لاگینگ، بکاپ، تامین‌کننده)، در RTP یا باید اجرای آن‌ها را دیده باشی یا حداقل «روش اجرای کنترل» را در مستندات طراحی‌ات قابل ردیابی کرده باشی.

یک جمع‌بندی کاملاً اجرایی: اگر فقط یک کار انجام بدهی تا Stage 1 بدون رفت‌وبرگشت جمع شود، این است که SoA را تبدیل به “نقشه راه ممیزی” کنی؛ یعنی کنار هر کنترل Applicable، یک ارجاع روشن به Risk ID/نیازمندی و (در صورت وجود) اقدام RTP بگذاری. خودِ ممیز هم در مرحله بازبینی مستندات معمولاً دقیقاً دنبال همین ارتباط‌هاست.

چک‌لیست Stage 2 (Implementation Evidence) — ممیز دنبال چه شواهدی است؟

Stage 2 جایی است که ممیز دیگر با «سند» قانع نمی‌شود؛ می‌خواهد ببیند کنترل‌ها واقعاً اجرا می‌شوند، رکورد تولید می‌کنند، پایش می‌شوند و اگر مشکل پیش آمد، اصلاح می‌شوند. اگر Stage 1 یعنی “طراحی ISMS”، Stage 2 یعنی “اثبات اجرای ISMS”. بنابراین موفقیت شما در Stage 2 تا حد زیادی به این بستگی دارد که بتوانی سریع و بدون آشفتگی، برای کنترل‌های Applicable در SoA Evidence قابل ارائه داشته باشی.

دو اصل ساده اما تعیین‌کننده برای Stage 2:

1. هر ادعای Implemented باید شاهد اجرایی داشته باشد (نمونه واقعی، نه توضیح شفاهی).
2. شاهد باید قابل ردیابی باشد: از کنترل → به فرآیند/سیستم → به رکورد/لاگ/تیکت → به پایش/بهبود.

Evidence Map: هر کنترل → چه سند/چه رکورد/چه تست

Evidence Map یعنی شما قبل از ممیز، برای هر کنترل (یا برای هر خوشه کنترل) یک نقشه آماده می‌کنی که دقیقاً می‌گوید:

• سند (Document): “قانون/روش انجام کار” کجاست؟
• رکورد (Record): “اثبات انجام شدن” کجاست؟
• تست/نمونه‌برداری (Sample/Test): ممیز اگر بخواهد صحت را چک کند، چه نمونه‌ای می‌دهی؟

اگر این نقشه را داشته باشی، Stage 2 از حالت دفاع پراکنده خارج می‌شود و تبدیل می‌شود به ارائه منظم شواهد. در عمل، ممیز هم دقیقاً همین مسیر را می‌رود: یک کنترل را انتخاب می‌کند، بعد می‌خواهد یک سند + چند رکورد + یک نمونه اجرایی/تست ببیند.

برای اینکه مقاله‌ات کاربردی شود، این قالب ساده را پیشنهاد بده (هم برای تیم خودت خوب است، هم برای مخاطب مقاله):

قالب Evidence Map (پیشنهادی برای هر کنترل یا فرآیند):

• Control/Process: (مثلاً مدیریت دسترسی)
• Where implemented: (کدام سیستم/ابزار/فرآیند)
• Document: (سیاست/روش اجرایی/استاندارد داخلی)
• Records: (تیکت‌ها، لاگ‌ها، صورتجلسه‌ها، گزارش‌ها)
• Sampling: (۲–۵ نمونه از ۳ ماه اخیر یا بر اساس ریسک)
• Owner: (مسئول ارائه شواهد)

و برای اینکه کاملاً ملموس شود، چند نمونه Evidence Map کوتاه (به‌صورت فشرده) ارائه بده:

| حوزه/کنترل نمونه | سندهایی که نشان می‌دهی | رکوردهایی که نشان می‌دهی | تست/نمونه‌برداری پیشنهادی |
|—|—|—|
| Joiner/Mover/Leaver (دسترسی‌ها) | روش JML + سیاست کنترل دسترسی | ۳ درخواست دسترسی اخیر + ۱ خروج کارمند + لاگ/گزارش غیرفعال‌سازی اکانت | نمونه‌گیری از ۳ ماه اخیر؛ بررسی «تأیید، دلیل دسترسی، زمان حذف» |
| MFA و حساب‌های ممتاز | سیاست MFA/Privileged Access | خروجی تنظیمات MFA + لیست حساب‌های ادمین + گزارش استثناها | یک تست نمایشی روی یک سیستم غیرحساس یا اسکرین‌شات تنظیمات + بررسی استثناها |
| Log & Monitoring | سیاست لاگینگ + روال بازبینی | نمونه لاگ احراز هویت/ادمین + رکورد بازبینی لاگ + یک تیکت بررسی هشدار | انتخاب یک هشدار/رویداد و نشان دادن “از کشف تا اقدام” |
| Vulnerability & Patch | روش مدیریت آسیب‌پذیری + SLA اصلاح | آخرین گزارش اسکن + لیست High/Critical + تیکت‌های Patch | پیگیری ۲ مورد High از کشف تا بسته شدن + دلیل موارد باز |
| Backup & Restore | سیاست بکاپ + برنامه بازیابی | لاگ بکاپ + گزارش تست بازیابی | انتخاب یک سرویس حیاتی؛ ارائه گزارش تست بازیابی و نتیجه |
| Supplier Security | روش ارزیابی تامین‌کننده + بندهای امنیتی قرارداد | چک‌لیست ارزیابی یک تامین‌کننده حیاتی + صورتجلسه بازنگری | نمونه قرارداد/بندهای امنیتی (با ماسک اطلاعات حساس) + کنترل دسترسی پیمانکار |

نکته کلیدی این است که Evidence Map را لازم نیست برای “همه ۹۳ کنترل” جداگانه سنگین کنی. در عمل می‌توانی آن را فرآیندمحور بسازی: مثلاً “مدیریت دسترسی” خودش چند کنترل Annex A را پوشش می‌دهد. ممیز هم از ارائه منظم فرآیندمحور استقبال می‌کند، چون سریع‌تر به اثربخشی می‌رسد.

یک توصیه اجرایی که در مقاله خیلی به درد می‌خورد:
برای هر حوزه، یک “Evidence Pack” آماده کن (پوشه یا لینک) با نام‌گذاری ثابت:
01-Documents، 02-Records، 03-Samples، 04-ManagementReview
این کار زمان ممیزی را کم می‌کند و مهم‌تر از آن، حس بلوغ و کنترل‌پذیری به ممیز می‌دهد.

نمونه سوالات مصاحبه برای نقش‌های کلیدی (IT, HR, Legal, Ops)

در Stage 2 مصاحبه‌ها «برای گرفتن حرف» نیست؛ برای این است که ممیز بفهمد افراد کلیدی:

• نقش و مسئولیتشان را می‌فهمند،
• فرآیند را همان‌طور که نوشته شده اجرا می‌کنند،
• و می‌توانند سریع شواهد را نشان بدهند.

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

مصاحبه با IT / Security / Infra

1. اگر امروز یک درخواست دسترسی جدید بیاید، مسیر تأیید و اجرا دقیقاً چیست و کجا ثبت می‌شود؟
2. برای حساب‌های ادمین/حساس، MFA و کنترل‌های اضافی چگونه اعمال شده؟ استثناها چطور مدیریت می‌شوند؟
3. آخرین تغییر حساس (Change) چه بوده و قبل/بعد از تغییر چه چک‌های امنیتی انجام شده؟ رکوردش کجاست؟
4. لاگ‌های حیاتی (احراز هویت، تغییرات دسترسی، تغییر تنظیمات) کجا جمع می‌شود و چه کسی/چطور بازبینی می‌کند؟ نمونه‌ای نشان بدهید.
5. آسیب‌پذیری‌های High/Critical را چطور اولویت‌بندی و اصلاح می‌کنید؟ اگر موردی باز مانده، منطق پذیرش/کنترل جبرانی چیست؟
6. در رخداد امنیتی، “اولین ۳۰ دقیقه” چه می‌کنید؟ چه کسی تصمیم‌گیر است و مسیر Escalation چیست؟
7. بکاپ‌ها کجا نگهداری می‌شوند، دسترسی به بکاپ‌ها چطور کنترل می‌شود و آخرین تست بازیابی چه نتیجه‌ای داشته؟

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

مصاحبه با HR

1. در ورود کارمند جدید، چه زمانی و چگونه IT مطلع می‌شود و دسترسی‌ها چطور ایجاد می‌شود؟
2. در خروج کارمند، SLA حذف دسترسی چیست و چه چیزی ثابت می‌کند دسترسی‌ها حذف شده؟
3. آیا نقش‌های حساس دسته‌بندی شده‌اند و برای آن‌ها کنترل/تعهدات خاص دارید؟
4. آموزش آگاهی امنیت اطلاعات چگونه برنامه‌ریزی شده و تکمیل آن چگونه ردیابی می‌شود؟
5. کارکنان چطور سیاست‌های کلیدی (محرمانگی، استفاده قابل قبول، گزارش رخداد) را تأیید می‌کنند؟
6. اگر نقض سیاست رخ دهد، فرآیند ثبت/رسیدگی/اقدام اصلاحی چیست (بدون ورود به جزئیات محرمانه پرونده‌ها)؟

اینجا ممیز دنبال رکوردهای قابل ارائه است: فرم‌های JML، رکورد آموزش، تأییدیه سیاست‌ها.

مصاحبه با Legal / Contracts

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

ممیز اینجا “سند قرارداد + فرآیند کنترل تامین‌کننده + رکورد ارزیابی/بازنگری” را می‌خواهد.

مصاحبه با Ops / Business Owners

1. دارایی‌ها/اطلاعات حیاتی شما چیست و مالک آن‌ها چه کسی است؟ طبقه‌بندی چگونه انجام می‌شود؟
2. اگر یک رخداد یا اختلال سرویس رخ دهد، چه کسی را مطلع می‌کنید و چه رکوردی تولید می‌شود؟
3. آیا فرآیندهای روزمره شما (مثلاً درخواست دسترسی، تغییرات، کار با تامین‌کننده) با سیاست‌های امنیتی هم‌خوان است؟ یک نمونه واقعی نشان بدهید.
4. KPIهای مرتبط با امنیت در واحد شما چیست و چطور گزارش/پیگیری می‌شود؟
5. اگر ممیزی داخلی یک عدم‌انطباق پیدا کند، شما چطور CAPA را اجرا و اثربخشی را ثابت می‌کنید؟

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

چک‌لیست ممیزی بر اساس فرآیندهای رایج سازمان

اگر بخواهی ممیزی داخلی ISO 27001 واقعاً «پیش‌بینی‌کننده Stage 2» باشد، بهتر است به‌جای اینکه فقط کنترل‌ها را یکی‌یکی تیک بزنی، ممیزی را روی فرآیندهای واقعی سازمان ببری. دلیلش ساده است: رخدادها، نشت اطلاعات، و عدم‌انطباق‌ها معمولاً از دل همین فرآیندها بیرون می‌آیند (تغییرات، دسترسی‌ها، رخدادها، تأمین‌کنندگان، توسعه نرم‌افزار، کلود). ما در این بخش، برای هر فرآیند یک چارچوب ممیزی می‌دهیم که سه چیز را همزمان پوشش دهد: سند/روش (Document)، رکورد/ردپا (Record)، و نمونه‌برداری اجرایی (Sample/Test).

فرآیند مدیریت تغییرات (Change)

در ممیزی Change، ممیز دنبال این نیست که شما فرم‌های زیاد دارید؛ دنبال این است که تغییرات حساس «بدون کنترل» انجام نمی‌شود. یعنی قبل از تغییر ارزیابی می‌کنی، تأیید می‌گیری، تست می‌کنی، و بعد از تغییر هم اثر امنیتی را چک می‌کنی. اگر سازمانت Change را شل گرفته باشد، Stage 2 معمولاً از همین جا ضربه می‌زند چون خیلی از رخدادها ریشه در تغییرات عجولانه دارند.

در ممیزی داخلی، Change را این‌طور ببند:

• آیا تعریف “تغییر حساس” روشن است؟ (تغییرات مربوط به دسترسی، فایروال، سرویس‌های اینترنتی، دیتابیس، کلود، تنظیمات امنیتی، CI/CD)
• آیا برای تغییرات حساس یک مرحله «بررسی امنیت/ریسک» دارید یا همه چیز فقط فنی دیده می‌شود؟
• آیا تأییدکننده مشخص است و تضاد منافع مدیریت می‌شود؟ (کسی که تغییر را اجرا می‌کند، لزوماً تأییدکننده نهایی نباشد)
• آیا تست و Rollback Plan برای تغییرات حساس وجود دارد؟
• آیا تغییرات اضطراری (Emergency Change) مسیر کنترل‌شده دارد یا بهانه‌ای برای دور زدن فرآیند است؟

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

نمونه‌برداری پیشنهادی: ۵ تغییر اخیر (حداقل ۲ تغییر حساس + ۱ تغییر اضطراری اگر دارید) از ۳ ماه اخیر را بردار و مسیرشان را کامل دنبال کن: از درخواست تا تأیید تا اجرا و بعد-از-اجرا. اگر همین مسیر تمیز باشد، بخش بزرگی از ممیزی فناورانه و عملیاتی هم هم‌زمان تقویت می‌شود.

مدیریت دسترسی‌ها

Access Management معمولاً “پرتکرارترین نقطه ضعف Stage 2” است، چون خیلی از سازمان‌ها دسترسی را می‌دهند اما بازپس‌گیری، بازبینی و کنترل حساب‌های ممتاز را جدی نمی‌گیرند. ممیزی این فرآیند باید نشان دهد چرخه دسترسی کنترل‌پذیر و قابل ردیابی است، نه وابسته به حافظه افراد.

در ممیزی داخلی روی این محورهای اصلی تمرکز کن:

• درخواست دسترسی‌ها: آیا هر دسترسی «دلیل کسب‌وکاری» دارد و تأییدکننده‌اش مشخص است؟
• اصل حداقل دسترسی و نقش‌محوری: آیا Role/Groupها تعریف شده یا دسترسی‌ها موردی و پراکنده است؟
• Joiner/Mover/Leaver: آیا HR/مدیر مستقیم روال اطلاع‌رسانی دارد؟ زمان حذف دسترسی‌ها بعد از خروج چقدر است و آیا رکورد دارد؟
• حساب‌های ممتاز (Privileged): آیا MFA، محدودیت IP/شبکه، ثبت لاگ، و بازبینی دوره‌ای دارید؟ استثناها چطور مدیریت می‌شوند؟
• بازبینی دوره‌ای دسترسی‌ها: آیا حداقل برای سیستم‌های حیاتی انجام می‌شود و خروجی‌اش (اصلاح دسترسی‌ها) ثبت می‌شود؟

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

نمونه‌برداری پیشنهادی: ۳ درخواست دسترسی اخیر + ۱ جابجایی نقش (Mover) + ۱ خروج (Leaver) + یک نمونه بازبینی دسترسی‌ها. اگر این چهار نمونه درست باشد، ادعای “Implemented” در SoA هم قابل دفاع می‌شود.

مدیریت رخدادها

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

در ممیزی داخلی این سؤال‌ها را محور قرار بده:

• کانال گزارش‌دهی مشخص است؟ (کارمند بداند چه چیزی را و به چه کسی گزارش دهد)
• ثبت رخداد استاندارد دارید؟ (Severity، زمان، مالک رسیدگی، اقدامات انجام‌شده)
• Escalation روشن است؟ (چه زمانی به مدیریت ارشد/حقوقی/مشتری اطلاع داده می‌شود)
• پاسخ‌گویی عملیاتی دارید؟ (Containment، Recovery، جلوگیری از تکرار)
• بعد از رخداد “Lesson Learned” و CAPA واقعاً انجام می‌شود یا رخداد فقط بسته می‌شود؟

شواهد مورد انتظار: Incident Register یا تیکت‌های رخداد، تایم‌لاین اقدامات، شواهد ارتباطات داخلی/خارجی (در حد مجاز)، گزارش تحلیل علت ریشه‌ای، و اقدام اصلاحی + بررسی اثربخشی.

نمونه‌برداری پیشنهادی: ۲ رخداد اخیر (یا ۱ رخداد + ۱ near-miss) را کامل دنبال کن: از کشف تا بستن و CAPA. اگر رخداد ثبت‌شده ندارید، حداقل یک سناریوی تمرینی (Tabletop) با خروجی مکتوب اجرا کن تا “آمادگی قابل اثبات” داشته باشی.

مدیریت تأمین‌کنندگان

هر جا داده یا سرویس حیاتی دست بیرون است، ممیز انتظار دارد تو ریسک را مدیریت کنی—even اگر سرویس روی کلود یا برون‌سپاری باشد. این فرآیند باید نشان دهد سازمان شما انتخاب تأمین‌کننده را امنیتی می‌بیند، قرارداد را درست می‌بندد، دسترسی پیمانکار را کنترل می‌کند، و همکاری را دوره‌ای پایش می‌کند.

در ممیزی داخلی، تأمین‌کنندگان را ریسک‌محور دسته‌بندی کن و برای تأمین‌کننده‌های حیاتی این‌ها را بررسی کن:

• پیش از قرارداد: آیا ارزیابی امنیتی حداقلی دارید؟ (پرسش‌نامه، سوابق، گواهی‌ها، سابقه رخداد)
• داخل قرارداد/SLA: بندهای امنیتی روشن دارید؟ (گزارش‌دهی رخداد، محل پردازش/ذخیره داده، زیرپیمانکار، حذف/بازگشت داده، محرمانگی، دسترسی‌ها)
• دسترسی پیمانکار: حداقل دسترسی، مدت‌دار، قابل لغو، با MFA (در صورت امکان)
• پایش: بازبینی دوره‌ای عملکرد/ریسک (حتی ساده هر ۶ یا ۱۲ ماه)
• خاتمه همکاری: لغو دسترسی‌ها، تحویل/حذف داده، بستن حساب‌ها، جمع‌آوری تجهیزات/کلیدها

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

نمونه‌برداری پیشنهادی: ۲ تأمین‌کننده حیاتی + ۱ تأمین‌کننده متوسط را انتخاب کن و مسیر “انتخاب تا پایش” را روی آن‌ها بررسی کن. همین سه نمونه معمولاً برای کشف شکاف‌های سیستماتیک کافی است.

توسعه نرم‌افزار/DevOps (اگر دارید)

اگر توسعه نرم‌افزار یا CI/CD دارید، ممیز Stage 2 معمولاً دنبال این است که “تغییرات نرم‌افزار” از مسیر امن عبور می‌کند یا نه. اینجا فقط بحث کدنویسی نیست؛ بحث کنترل دسترسی به مخازن، مدیریت اسرار (Secrets)، جداسازی محیط‌ها، و ردیابی از commit تا release است.

در ممیزی داخلی، این نقاط را دقیق چک کن:

• کنترل دسترسی به Repo و Pipeline: چه کسی می‌تواند merge/deploy کند؟ آیا دسترسی‌ها بازبینی می‌شود؟
• تفکیک محیط‌ها: Dev/Test/Prod جداست؟ داده Production به محیط‌های غیرتولیدی نشت نمی‌کند؟
• مدیریت Secrets: کلیدها و توکن‌ها کجا نگهداری می‌شوند؟ در کد هاردکد نمی‌شوند؟ چرخش کلید دارید؟
• کنترل کیفیت امنیتی: Code review، اسکن وابستگی‌ها، SAST/DAST (در حد توان)، و مدیریت آسیب‌پذیری‌ها
• تغییرات Release: آیا هر release درخواست/تأیید دارد و قابل ردیابی است؟

شواهد مورد انتظار: سیاست/راهنمای Secure SDLC (حتی ساده)، تنظیمات دسترسی repo، لاگ/گزارش pipeline، نمونه PR با review، خروجی اسکن وابستگی‌ها یا گزارش vulnerability، و یک مسیر traceable از “commit → build → deploy”.

نمونه‌برداری پیشنهادی: یک release اخیر را انتخاب کن و از روی آن نشان بده چه کسی تغییر را پیشنهاد داده، چه کسی review کرده، چه تست‌هایی اجرا شده، چه کسی deploy کرده و چه رکوردی از آن مانده است. این یک نمونه اگر درست باشد، ممیز را قانع می‌کند که توسعه شما کنترل‌پذیر است.

سرویس‌های ابری (اگر دارید)

در کلود، ممیز معمولاً روی دو موضوع حساس است: Shared Responsibility (مسئولیت مشترک) و پیکربندی امن. خیلی از رخدادهای کلودی از IAM ضعیف، دسترسی عمومی اشتباه، کلیدهای مدیریت‌نشده، یا لاگینگ خاموش می‌آید. بنابراین ممیزی کلود باید نشان دهد شما “کلود را رها نکرده‌اید”.

در ممیزی داخلی، حداقل این‌ها را بررسی کن:

• موجودی حساب‌ها/پروژه‌ها و سرویس‌های کلودی: دقیقاً چه چیزی دارید و مالک هرکدام کیست؟
• IAM در کلود: MFA برای حساب‌های حساس، نقش‌ها/Policyها، اصل حداقل دسترسی، و مدیریت دسترسی پیمانکاران
• تنظیمات امنیتی پایه (Baseline): دسترسی عمومی به ذخیره‌سازی‌ها، تنظیمات شبکه/Firewall/Security Groupها، و جداسازی محیط‌ها
• لاگینگ و مانیتورینگ: فعال بودن لاگ‌های حیاتی، نگهداری (Retention) مناسب، و حداقل یک روال بازبینی/هشدار
• رمزنگاری و کلیدها: وضعیت encryption at rest/in transit، مدیریت کلیدها (KMS/keys)، و چرخش کلیدها
• بکاپ/بازیابی: برای داده‌های حیاتی در کلود هم “تست بازیابی” را فراموش نکن

شواهد مورد انتظار: سیاست استفاده از کلود، inventory سرویس‌ها، خروجی تنظیمات IAM و MFA، گزارش یا اسکرین‌شات baselineهای امنیتی، لاگ‌های فعال و رکورد بازبینی، و نمونه گزارش/تیکت اصلاح یک misconfiguration.

نمونه‌برداری پیشنهادی: ۱–۲ حساب/پروژه حیاتی را انتخاب کن و روی همان‌ها عمیق برو. ممیزی کلود اگر سطحی و گسترده شود، معمولاً چیزی کشف نمی‌کند؛ اما اگر روی یک نمونه حیاتی دقیق شوی، شکاف‌های واقعی سریع بیرون می‌آید.

دانلودها و قالب‌های قابل کپی/استفاده

اگر می‌خواهی چک‌لیست ممیزی ISO 27001 فقط یک «لیست تیک‌زدنی» نباشد و واقعاً Stage 2 را برایت قابل پیش‌بینی کند، این قالب‌ها کمک می‌کنند ممیزی را فرآیندمحور + شواهد‌محور جلو ببری. ما همه قالب‌ها را طوری چیده‌ایم که یک مسیر واحد داشته باشند: برنامه ممیزی → چک‌لیست بندها و Annex A → گزارش و NCR → CAPA و اثربخشی → ردیابی شواهد.

دانلود فایل‌ها

ISO27001_Audit_Templates.xlsx

دانلود قالب گزارش ممیزی (Word)

قالب برنامه ممیزی (Audit Plan)

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

داخل فایل اکسل: شیت Audit Plan
پیشنهاد اجرایی ما: برای هر فرآیند کلیدی (Access، Change، Incident، Supplier، Backup، Vulnerability) یک ردیف بساز و همان‌جا «نمونه‌برداری پیشنهادی» را مشخص کن (مثلاً ۳ تیکت اخیر + ۱ مورد خروج + ۱ بازبینی دسترسی).

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

این قالب برای ممیزی بندهای مدیریتی ISO 27001 است (Context تا Improvement). تفاوتش با چک‌لیست‌های کلیشه‌ای این است که ستون‌ها طوری طراحی شده‌اند که تو را مجبور کند کنار هر سؤال، Evidence واقعی (رکورد/لاگ/تیکت/صورتجلسه) معرفی کنی و وضعیت را صریح ثبت کنی (Conform/NC/OFI).

داخل فایل اکسل: شیت‌های Clause 4 تا Clause 10
روش استفاده پیشنهادی: برای هر بند، ۵ تا ۱۲ سؤال «واقعی» بنویس (نه کپیِ متن استاندارد) و برای هر سؤال حداقل یک شاهد قابل ارائه معرفی کن. اگر فقط “سند” داری ولی “رکورد” نداری، همان‌جا ریسک Stage 2 را می‌بینی.

قالب چک‌لیست Annex A بر اساس 4 تم

اینجا Annex A را به‌جای اینکه ۹۳ کنترل را یک‌جا ردیف کنی، بر اساس ۴ تم کاربردی می‌بری جلو: سازمانی، افراد، فیزیکی، فناورانه. این مدل برای سایت و برای ممیزی داخلی، قابل فهم‌تر است و سریع‌تر شکاف‌ها را نشان می‌دهد.

داخل فایل اکسل:

• AnnexA - Organizational
• AnnexA - People
• AnnexA - Physical
• AnnexA - Technological

روش استفاده پیشنهادی: ستون‌های Applicable / Justification / Implementation status / Evidence را جدی بگیر. اگر کنترل را “Implemented” می‌زنی اما شاهدش مشخص نیست، یعنی همان کنترل در Stage 2 می‌تواند تبدیل به عدم‌انطباق شود.

قالب گزارش ممیزی + ثبت عدم انطباق

این بخش برای جمع‌بندی حرفه‌ای ممیزی است: هم برای مدیریت، هم برای تیم اجرا. گزارش خوب، باید هم «تصویر کلی» بدهد، هم مسیر اقدام را روشن کند. ما قالب Word را طوری آماده کرده‌ایم که بتوانی سریع گزارش را کامل کنی و در عین حال بخش NCR/Observation را استاندارد ثبت کنی.

داخل فایل Word: ISO27001_Audit_Report_Template.docx
داخل فایل اکسل (برای ثبت و پیگیری): شیت Audit Report Summary و NCR Log

پیشنهاد اجرایی ما: گزارش Word را برای خروجی رسمی نگه دار، اما ثبت NCRها و پیگیری وضعیت را حتماً در NCR Log انجام بده تا هیچ موردی گم نشود و بتوانی CAPA را به هر NCR لینک کنی.

قالب CAPA و پیگیری اثربخشی

در ISO 27001، «بستن عدم‌انطباق» با نوشتن یک اقدام تمام نمی‌شود؛ باید بتوانی نشان بدهی Root Cause را پیدا کرده‌ای، اقدام اصلاحی گذاشته‌ای، و مهم‌تر از همه اثربخشی را بررسی کرده‌ای. این قالب دقیقاً برای همین طراحی شده است.

داخل فایل اکسل: شیت CAPA Tracker
روش استفاده پیشنهادی: برای هر NCR، Correction را سریع ثبت کن (اقدام فوری)، بعد Root Cause را با یک روش ساده (۵ چرا، Fishbone، یا تحلیل فرآیندی) مشخص کن. ستون «معیار اثربخشی» را شفاف بنویس (مثلاً: کاهش تکرار خطا، تکمیل ۱۰۰٪ آموزش، فعال شدن MFA برای همه اکانت‌های حساس، بسته شدن High vulns طبق SLA).

جدول ردیابی شواهد (Evidence Tracker)

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

داخل فایل اکسل: شیت Evidence Tracker
پیشنهاد اجرایی ما: برای هر فرآیند یک “Evidence Pack” درست کن (یک فولدر با ساختار ثابت مثل 01-Documents / 02-Records / 03-Samples) و مسیرش را همین‌جا ثبت کن. این کار زمان ممیزی را کم می‌کند و حس بلوغ ISMS را بالا می‌برد.

جمع‌بندی: اگر فقط ۳ کار انجام بدهی، ممیزی داخلی‌ات “واقعی” می‌شود

واقعیت این است که خیلی از ممیزی‌های داخلی ISO 27001 فقط یک «تیک‌زدن فرم» می‌شوند؛ نه به Stage 2 کمک می‌کنند، نه ریسک‌ها را کم می‌کنند. اگر بخواهم همین امروز، با کمترین انرژی و بیشترین اثر، ممیزی داخلی‌ات را واقعی کنم، روی این سه کار تمرکز می‌دهم—چون مستقیم به جایی وصل می‌شود که ممیز بیرونی در Stage 2 سراغش می‌رود: شاهد اجرایی، ردیابی، و بهبود.

کار اول: برای ۶ فرآیند کلیدی Evidence Pack بساز (نه برای همه ۹۳ کنترل).
به‌جای اینکه از Annex A شروع کنی و در لیست کنترل‌ها گم شوی، از فرآیندهای واقعی سازمان شروع کن: مدیریت دسترسی‌ها، مدیریت تغییرات، رخدادها، آسیب‌پذیری و Patch، بکاپ و بازیابی، و تامین‌کنندگان. برای هر فرآیند یک بسته شواهد بساز که داخلش جدا باشد: سند مرجع (Procedure/Policy)، رکوردهای واقعی (تیکت/لاگ/گزارش)، و نمونه‌ها (۳ تا ۵ مورد از ۳ ماه اخیر). وقتی این ۶ بسته آماده باشد، حتی اگر همه کنترل‌ها را خط‌به‌خط نخوانده باشی، Stage 2 دیگر ترسناک نیست؛ چون ممیز بالاخره دنبال همین شواهد واقعی است.

کار دوم: زنجیره ردیابی Risk → RTP → SoA → Evidence را با ۳ ریسک High تست کن.
Stage 1 و Stage 2 هر دو روی یک نقطه حساس‌اند: آیا کنترل‌هایی که گفتی “Applicable و Implemented” هستند، واقعاً از دل ریسک بیرون آمده‌اند و شواهد دارند؟ برای اینکه خودت قبل از ممیز مطمئن شوی، فقط ۳ ریسک High/Critical را انتخاب کن و مسیر را کامل برو: در Risk Register ریسک را ببین، در RTP اقدام/مالک/موعدش را پیدا کن، در SoA کنترل(های) مرتبط را چک کن، و بعد یک شاهد واقعی برای هر کنترل نشان بده. اگر در این مسیر حتی یک حلقه مبهم بود (مثلاً کنترل Implemented است اما Evidence معلوم نیست)، همان‌جا گپ Stage 2 را پیدا کرده‌ای.

کار سوم: هر یافته را به CAPA وصل کن و “اثربخشی” را قابل اندازه‌گیری کن.
ممیزی داخلی وقتی واقعی می‌شود که خروجی‌اش صرفاً یک گزارش نباشد، بلکه تبدیل به تغییر پایدار شود. برای هر عدم‌انطباق یا OFI، حداقل این چهار مورد را ثبت کن: Correction (اقدام فوری)، Root Cause (علت ریشه‌ای)، Corrective Action (اقدام اصلاحی)، و معیار اثربخشی (مثلاً: تکمیل آموزش ≥۹۵٪، قبولی آزمون ≥۸۰٪، کاهش کلیک فیشینگ ۲۰٪ در ۶۰ روز، بسته شدن High vuln طبق SLA). اگر معیار اثربخشی را مشخص نکنی، در عمل فقط «اقدام نوشته‌ای» نه «بهبود اثبات‌شده».

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

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

منابع معتبر برای تدوین چک‌لیست ممیزی ISO 27001

1. ISO — ISO/IEC 27001:2022 (Requirements): مرجع اصلی الزامات ISMS و ستون فقرات ممیزی (Clauseها + الزام‌های SoA/ریسک/بهبود). (iso.org)
2. ISO/IEC 27001:2022/Amd 1:2024: اصلاحیه مرتبط با «Climate action changes» که ممکن است روی متن‌های به‌روزرسانی‌شده و هم‌راستایی سیستم مدیریتی اثر بگذارد (برای رفرنس‌دهی به نسخه‌های جدید). (iso.org)
3. IEC — ISO/IEC 27002:2022 (Controls + implementation guidance): مرجع رسمی کنترل‌ها و راهنمای پیاده‌سازی؛ برای ساخت چک‌لیست Annex A و Evidenceها. (iso.org)
4. ISO/IEC 27005:2022 (Information security risk management): برای اینکه چک‌لیست ممیزی‌ات به ریسک واقعی وصل باشد (Risk → RTP → SoA → Evidence). (iso.org)
5. ISO 19011:2018 (Guidelines for auditing management systems): اصول ممیزی، برنامه ممیزی، روش نمونه‌برداری، گزارش‌دهی و صلاحیت ممیز (پایه روش‌شناسی ممیزی داخلی). (iso.org)
6. ISO/IEC 27007:2020 (Guidelines for ISMS auditing): راهنمای تخصصی ممیزی ISMS (در کنار ISO 19011)؛ کمک می‌کند چک‌لیست از حالت کلی خارج شود و ممیزی «ISMS-محور» شود. (iso.org)
7. ISO/IEC 27006-1:2024: الزامات و راهنمایی برای نهادهای ممیزی و صدور گواهی ISMS (درک اینکه ممیز بیرونی دقیقاً دنبال چه شواهد/رویکردی است). (iso.org)
8. ISO/IEC TR 27008:2011: راهنمای بازبینی و ارزیابی کنترل‌های امنیت اطلاعات (به‌درد «چطور کنترل را بررسی کنیم؟» و طراحی تست‌های ممیزی می‌خورد). (iso.org)
9. IAF — IAF MD 26:2023: سند الزامی برای الزامات انتقال/Transition مرتبط با ISO/IEC 27001:2022 برای نهادهای گواهی‌دهنده؛ برای هم‌راستایی با انتظارات اکردیتیشن در بازه انتقال مفید است. (iaf.nu)
10. NIST — NIST Cybersecurity Framework (CSF) 2.0 (2024): یک فریم‌ورک مکمل معتبر برای مپ‌کردن کنترل‌ها/خروجی‌ها و صحبت با ذی‌نفعان غیر ISO (خصوصاً مدیران و مشتریان بین‌المللی). (NIST Publications)
11. Center for Internet Security — CIS Controls v8.1: مجموعه کنترل‌های اولویت‌بندی‌شده و اجرایی؛ اگر می‌خواهی چک‌لیست ممیزی‌ات “پراتیکال” و روی «اقدام‌های با اثر بالا» تمرکز کند، این مرجع مکمل خوبی است. (CIS)
12. ISO/IEC 27000 family overview: نمای کلی خانواده 27000 برای معرفی مسیر استانداردها و اینکه هر کدام در چک‌لیست ممیزی چه نقشی دارند. (iso.org)