پیاده‌سازی ISO 27001 (ISMS) قدم‌به‌قدم: از Scope تا Evidence قابل ممیزی

اگر دنبال «پیاده‌سازی واقعی ISO 27001» هستی—یعنی نه صرفاً چند سند آماده، بلکه یک ISMS که داخل سازمان کار کند و در نهایت هم Evidence قابل دفاع برای ممیزی داشته باشد—این صفحه دقیقاً برای همین ساخته شده. اینجا قدم‌به‌قدم جلو می‌رویم: از تعیین Scope و مرزبندی سیستم، تا ساخت رجیستر دارایی‌ها، تعریف روش ریسک، تهیه Risk Register و RTP، ساخت SoA، و در نهایت اجرای کنترل‌ها به شکلی که خروجی‌اش “رکورد و شواهد” باشد، نه متن‌های صوری.

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

اگر تازه شروع می‌کنی، پیشنهاد من این است: یک بار کل صفحه را سریع مرور کن تا مسیر دستت بیاید، بعد از فاز 0 شروع کن و مرحله‌به‌مرحله جلو برو. هرجا لازم شد عمیق‌تر شوی، لینک‌های جزئیات را باز می‌کنی؛ اما اسکلت اصلی پروژه و ترتیب اجرا را همین‌جا نگه می‌داریم تا وسط راه گم نشوی و در نهایت، برای Stage 1 و Stage 2 با یک بسته شواهد مرتب و قابل ارائه وارد ممیزی شوی.

این راهنما دقیقاً چه کاری برایت انجام می‌دهد (و چه کاری نمی‌کند)

این صفحه یک «نقشه اجرای پروژه پیاده‌سازی ISO 27001» است؛ یعنی به جای کلی‌گویی یا متن‌های تئوریک، مرحله‌به‌مرحله به تو می‌گوید چه خروجی‌هایی باید بسازی (Deliverable)، چه شواهدی باید تولید کنی (Evidence/Record) و از کجا بفهمی درست جلو رفته‌ای. هدف این است که اگر یک نفر داخل سازمان مسئول اجرا باشد، بتواند با همین مسیر، پروژه را جلو ببرد و در انتها یک بسته مستندات و رکوردهای قابل دفاع داشته باشد—نه فقط چند فایل Word که در ممیزی گیر کند.

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

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

همین‌طور اگر می‌خواهی قبل از اجرا، Gap Analysis را با روش کامل انجام بدهی (امتیازدهی، اولویت‌بندی، برنامه اقدام و نقشه پر کردن فاصله‌ها)، این بخش را در صفحه «تجزیه و تحلیل شکاف ISO 27001» کامل کرده‌ایم و اینجا فقط به اندازه لازم از آن استفاده می‌کنیم:

تجزیه‌وتحلیل شکاف ISO 27001

برای «روش ریسک» هم همین منطق را داریم: اینجا به تو می‌گوییم چه خروجی‌هایی لازم است (Risk Method، Risk Register، RTP، SoA) و چطور به شکل ممیزی‌پذیر تولیدشان کنی؛ اما جزئیات تعیین پارامترها و طراحی مقیاس‌ها را در صفحه پارامترهای ارزیابی ریسک گذاشته‌ایم:

پارامترهای ارزیابی ریسک موثر برای ISO 27001

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

جدول Annex A استاندارد ایزو 27001

این صفحه برای چه کسی است؟

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

سناریو ۱: سازمان کوچک (کم‌ریسک، تک‌سایت، تیم محدود)

اگر یک سایت داری، تعداد نفرات کم است و سرویس‌های دیجیتال پیچیده یا داده‌های خیلی حساس نداری، پیاده‌سازی می‌تواند «سبک ولی واقعی» باشد. حداقلِ قابل قبول اینجا این است که Scope را دقیق و محدود تعریف کنی، یک Asset Register عملی (حتی کوچک) داشته باشی، روش ریسک را ساده ولی قابل دفاع تعیین کنی، و چند Evidence Pack کلیدی را اجرا کنی (مثل مدیریت دسترسی‌ها، بکاپ/بازیابی، مدیریت رخداد و تامین‌کننده). در این سناریو، کیفیت Evidence مهم‌تر از تعداد مستندات است؛ یعنی بهتر است ۶–۸ خروجی درست و اجراشده داشته باشی تا ۳۰ فایل صوری.

سناریو ۲: سازمان متوسط یا چندسایت (چند واحد، چند فرآیند، سرویس‌های بیشتر)

اینجا معمولاً مشکل اصلی «پراکندگی» است: چند واحد درگیرند، چند سامانه و چند مالک دارایی وجود دارد، و کنترل‌ها باید بین تیم‌ها هماهنگ شود. حداقلِ قابل دفاع در این سناریو این است که علاوه بر Deliverableهای پایه، نقش‌ها و مسئولیت‌ها را دقیق‌تر تعریف کنی (مالک دارایی، مالک ریسک، مالک فرآیند)، یک چرخه پایش و گزارش‌دهی دوره‌ای داشته باشی، و Evidenceها را قابل ردیابی کنی (چه کسی، چه زمانی، با چه نتیجه‌ای). معمولاً لازم می‌شود Evidence Packها را «فرآیندی‌تر» کنی: مثلاً دسترسی‌ها فقط سیاست نباشد، بلکه Joiner/Mover/Leaver و بازبینی‌های دوره‌ای و ثبت استثناها هم رکورد داشته باشد.

سناریو ۳: سازمان حساس (مالی/سلامت/داده‌محور، یا وابسته به الزامات سخت‌گیرانه)

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

اینجا معمولاً ممیز روی Evidenceهای عملیاتی حساس‌تر است؛ یعنی اگر فرآیند اجرا نشود، حتی مستندات مرتب هم نجاتت نمی‌دهد.

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

چطور از این صفحه استفاده کنی

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

اگر در یک مرحله احساس کردی نیاز به جزئیات بیشتری داری—مثلاً برای روش کامل Gap، طراحی روش ریسک، چک‌کردن آمادگی ممیزی، یا فهم دقیق ساختار Annex A—آن وقت از لینک‌های «جزئیات بیشتر» استفاده کن و برگرد به همین مسیر اصلی. این صفحه عمداً طوری طراحی شده که تو را از “گم شدن بین سندها” نجات بدهد: مسیر را اینجا نگه می‌داریم، عمق را فقط وقتی لازم شد در صفحات تخصصی دنبال می‌کنی.

نقشه راه پیاده‌سازی ISO 27001 در یک نگاه

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

اگر بخواهم یک معیار خیلی عملی بدهم: فاز 1 تا 3 اسکلت سیستم را می‌سازد، اما فاز 4 پروژه را “واقعی” می‌کند؛ یعنی اگر Evidence Packها راه نیفتد، حتی با سندهای مرتب هم احتمال گیرکردن در ممیزی بالا می‌رود.

فاز 0) شروع پروژه ISMS (قبل از هر سندنویسی)

هدف فاز

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

خروجی‌ها (Deliverables)

در پایان فاز 0 باید سه خروجی ساده ولی تعیین‌کننده داشته باشی:

1. Project Charter (منشور پروژه ISMS)
   یک سند کوتاه که هدف پروژه، Scope سطح بالا، محدوده مسئولیت‌ها، خروجی‌های اصلی و معیار موفقیت را مشخص می‌کند. منشور پروژه لازم نیست طولانی باشد، اما باید دقیق باشد: مثلاً «هدف ما تولید Evidence قابل ممیزی و اجرای فرآیندهای امنیت اطلاعات در محدوده X است» نه «پیاده‌سازی استاندارد».
2. تعریف نقش‌ها و مسئولیت‌ها (RACI یا حداقل یک جدول مسئولیت)
   حداقل نقش‌های ضروری را مشخص کن: Sponsor (حامی مدیریت)، ISMS Manager/Coordinator، مالکان دارایی (Asset Owners)، مالکان ریسک (Risk Owners)، و نماینده واحد IT/Operations. اگر سازمان کوچک است، ممکن است چند نقش روی یک نفر بیفتد؛ مهم این است که «صاحب کار» و «تصمیم‌گیر» معلوم باشد.
3. برنامه زمان‌بندی سطح‌بالا (High-level Plan)
   یک برنامه ۶ تا ۱۰ هفته‌ای/۱۲ هفته‌ای (بسته به سناریوی سازمان) که فازها را نشان بدهد: Scope، دارایی‌ها، ریسک و SoA، Evidence Packها، پایش، ممیزی داخلی و بازنگری مدیریت، و آماده‌سازی Stageها. این برنامه باید مالک هر فاز را هم مشخص کند تا بعداً مسئولیت‌ها مبهم نشود.

شواهد (Evidence)

در همین فاز اول، چند Evidence ساده لازم است تا نشان دهد پروژه واقعاً شروع شده و فقط «یک تصمیم شفاهی» نیست:

• صورتجلسه Kickoff با حضور افراد کلیدی (حداقل: Sponsor، ISMS Manager، نماینده IT/Operations و یکی از واحدهای کسب‌وکاری اصلی).
• ابلاغ رسمی نقش‌ها (ایمیل/نامه داخلی/ابلاغیه) که در آن ISMS Manager و مسئولیت‌ها مشخص شده باشد.
• تخصیص منابع: حتی اگر بودجه عددی ندارد، حداقل زمان درگیر بودن افراد (مثلاً هفته‌ای X ساعت از IT یا واحدهای مرتبط) و ابزارهای لازم یا دسترسی‌ها باید روشن باشد.

معیار قبولی

فاز 0 وقتی “قبول” است که این 4 شرط برقرار باشد:

• مالک پروژه و حامی مدیریت مشخص است و اگر اختلافی پیش آمد، مسیر تصمیم‌گیری معلوم است.
• ISMS Manager (یا هماهنگ‌کننده ISMS) رسماً تعیین شده و اختیار هماهنگی بین واحدها را دارد.
• برنامه زمان‌بندی سطح‌بالا نوشته شده و هر فاز یک مسئول/Owner دارد.
• هدف پروژه اجرایی تعریف شده (تمرکز روی Evidence و اجرای فرآیندها)، نه صرفاً تولید سند.

فاز 1) تعیین Scope و مرزبندی ISMS (Clause 4 در عمل)

هدف فاز

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

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

خروجی‌ها (Deliverables)

1) Scope Statement قابل دفاع
یک پاراگراف/چند خط که به زبان ساده و دقیق می‌گوید ISMS شامل چه چیزی است. Scope خوب معمولاً این اجزا را دارد:

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

2) Context + Interested Parties (زمینه سازمان و ذی‌نفعان)
یک خروجی کوتاه اما کاربردی که این سه بخش را پوشش بدهد:

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

3) لیست الزامات (Requirements Register)
یک لیست کوتاه (نه کتاب) از الزاماتی که Scope را “اجباری” می‌کنند. حداقل این دسته‌ها:

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

شواهد (Evidence)

در فاز 1، شواهد قرار نیست پیچیده باشند؛ اما باید نشان دهند Scope «واقعی» است و از روی حدس نوشته نشده:

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

معیار قبولی

این فاز وقتی “قبول” است که بتوانی به این 6 سؤال، بدون تناقض جواب بدهی و شواهدش را داشته باشی:

1. دقیقاً چه خدمات/فرآیندهایی داخل Scope هستند؟
2. کدام سایت‌ها/لوکیشن‌ها و کدام واحدها داخل‌اند؟
3. کدام سامانه‌ها و سرویس‌های حیاتی داخل Scope هستند؟
4. مهم‌ترین اینترفیس‌ها با بیرون کجاست؟ (ابر، پیمانکار IT، سرویس‌های SaaS، درگاه‌های تبادل داده، …)
5. چه الزام قانونی/قراردادی Scope را شکل داده است؟
6. اگر استثنا داری، دلیل و کنترل جبرانی‌اش چیست و ریسکش کجا ثبت شده؟

اگر جواب‌ها شفاف است و یک نفر از بیرون (یا ممیز) بتواند Scope را “تصور” کند و مرزها را بفهمد، Scope قابل دفاع است. اگر Scope با چند سؤال ساده تبدیل شود به بحث‌های «نه، منظورم این نبود»، یعنی هنوز مبهم است و نباید وارد فاز دارایی‌ها و ریسک شوی.

فاز 2) ساخت Asset Register و مدل طبقه‌بندی (حداقلی اما واقعی)

هدف فاز

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

خروجی‌ها (Deliverables)

1) Asset Register (رجیستر دارایی‌ها) – نسخه حداقلی اما کافی
رجیستر دارایی لازم نیست از روز اول کامل و صددرصدی باشد، اما باید «قابل استفاده» باشد. حداقل فیلدهایی که پیشنهاد می‌کنم نگه داری:

• نام دارایی (سیستم/سرویس/داده/زیرساخت)
• نوع دارایی (اطلاعات/نرم‌افزار/سخت‌افزار/زیرساخت/خدمات ابری/خدمات برون‌سپاری)
• مالک دارایی (Asset Owner) و در صورت نیاز Custodian/مسئول نگهداری
• محل/بستر (On-prem / Cloud / SaaS / دیتاسنتر / لوکیشن)
• کاربری/فرآیند مرتبط (این دارایی به کدام خدمت/فرآیند Scope وصل است)
• طبقه‌بندی اطلاعات/حساسیت (بعد از تعریف مدل طبقه‌بندی)
• نیازهای CIA به صورت ساده (اهمیت محرمانگی/یکپارچگی/دسترس‌پذیری در حد “کم/متوسط/زیاد”)
• وابستگی‌ها و اینترفیس‌ها (ارتباط با سرویس/تأمین‌کننده/سیستم دیگر)
• وضعیت کنترل‌های کلیدی (حداقلی: کنترل دسترسی، بکاپ، لاگ، مالکیت)

2) تعیین مالکان دارایی (Asset Ownership)
این قسمت حیاتی است: هر دارایی باید یک Owner داشته باشد که بتواند درباره دسترسی‌ها، تغییرات، اولویت اصلاح ریسک و پذیرش ریسک تصمیم بدهد. اگر Owner مشخص نباشد، در فاز ریسک و SoA گیر می‌کنی چون تصمیم‌ها “صاحب” ندارند.

3) مدل طبقه‌بندی اطلاعات (Data Classification Model)
یک مدل ساده ۳ یا ۴ سطحی کافی است (مثلاً عمومی / داخلی / محرمانه / خیلی محرمانه). نکته این است که سطح‌ها باید قابل اجرا باشند، نه تعاریف زیبا. برای هر سطح، یک تعریف یک‌خطی و یک مثال واقعی از سازمان خودتان بده تا برداشت‌ها یکسان شود.

4) قواعد حداقلیِ کار با داده (Data Handling Rules)
برای اینکه طبقه‌بندی فقط روی کاغذ نماند، باید حداقل چند قاعده اجرایی داشته باشی. این قواعد را کوتاه نگه دار و روی نقاط پرتکرار تمرکز کن:

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

شواهد (Evidence)

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

• نسخه قابل ارائه Asset Register (حتی اگر کامل نیست، باید منطقی و قابل دفاع باشد)
• فهرست رسمی Asset Ownerها یا ایمیل/ابلاغیه‌ای که مالکیت را تأیید می‌کند
• نمونه برچسب‌گذاری یا اعمال طبقه‌بندی (مثلاً روی چند سند/پوشه/سیستم)
• نمونه کنترل دسترسی مرتبط با طبقه‌بندی (مثلاً دسترسی محدودتر برای داده‌های محرمانه)
• نمونه قواعد Data Handling در عمل (مثلاً الگوی نام‌گذاری پوشه‌ها، مسیر ذخیره‌سازی مجاز، یا دستورالعمل اشتراک‌گذاری)

معیار قبولی

فاز 2 وقتی “قبول” است که این شرایط را داشته باشی:

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

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

فاز 3) ریسک: از روش تا خروجی‌های ممیزی‌پذیر

در ISO 27001، ریسک فقط یک جدول نیست؛ ستون فقرات کل سیستم است. اگر روش ریسک و خروجی‌هایش درست ساخته نشود، SoA صوری می‌شود، کنترل‌ها بی‌ربط انتخاب می‌شوند، و در نهایت Evidenceها قابل دفاع نیستند. در این فاز ما چهار خروجی اصلی را می‌سازیم که بعداً تقریباً همه چیز به آن‌ها وصل می‌شود: Risk Method، Risk Register، Risk Treatment Plan (RTP)، و SoA. نکته مهم این است که در این صفحه مادر، مسیر اجرا را دقیق می‌گویم اما وارد طراحی جزئیات پارامترها و مدل‌های پیشرفته نمی‌شوم؛ جزئیات روش‌شناسی را در مقاله تخصصی «پارامترهای ارزیابی ریسک» دنبال کن.

3-1) تعریف روش ارزیابی ریسک (Risk Method)

هدف این بخش

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

خروجی‌ها (Deliverables)

در پایان 3-1 باید این موارد را داشته باشی:

1. مقیاس احتمال و اثر (Likelihood/Impact)
   مقیاس می‌تواند ۳ سطحی یا ۵ سطحی باشد، اما باید دو ویژگی داشته باشد:

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

2. معیار پذیرش ریسک (Risk Acceptance Criteria)
   این بخش مشخص می‌کند از چه سطحی به بعد «باید درمان شود» و چه سطحی را می‌توان با تأیید Owner پذیرفت. بدون معیار پذیرش، درمان ریسک تبدیل می‌شود به سلیقه یا فشار زمان ممیزی.
3. تعریف ریسک باقیمانده (Residual Risk) و منطق تصمیم‌گیری
   باید روشن کنی بعد از اعمال کنترل‌ها، ریسک باقیمانده چطور سنجیده می‌شود و چه زمانی “قابل قبول” است. همین نقطه است که بعداً در ممیزی از تو دفاع می‌کند.
4. الزام ثبت مالک ریسک و منابع ریسک
   در روش ریسک، مشخص کن هر ریسک باید یک Risk Owner داشته باشد و منبع/سناریوی ریسک شفاف نوشته شود (تهدید/آسیب‌پذیری/اثر).

شواهد (Evidence)

• نسخه مصوب Risk Method (تاریخ/نسخه/تأیید مدیریت یا کمیته مربوط)
• صورتجلسه یا تأیید رسمی معیار پذیرش ریسک
• نمونه امتیازدهی آزمایشی روی ۳–۵ ریسک برای یکسان‌سازی برداشت‌ها

معیار قبولی

وقتی ۵ نفر مختلف اگر یک ریسک نمونه را با این روش بسنجند، اختلافشان «جزئی» باشد، نه اینکه یکی کم و یکی بسیار بالا بدهد. اگر هنوز برداشت‌ها متضاد است، قبل از رفتن به Risk Register، روش را ساده‌تر و شفاف‌تر کن.

برای طراحی دقیق پارامترها و انتخاب مقیاس‌ها، این صفحه را مرجع قرار بده:
پارامترهای ارزیابی ریسک موثر برای ISO 27001

3-2) Risk Assessment و ساخت Risk Register

هدف این بخش

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

خروجی‌ها (Deliverables)

Risk Register که حداقل این فیلدها را داشته باشد:

• شناسه ریسک (Risk ID)
• دارایی/فرآیند مرتبط (از فاز 2)
• سناریوی ریسک (تهدید + آسیب‌پذیری + رخداد)
• اثر/پیامد (Impact) و دلیل
• احتمال (Likelihood) و دلیل
• امتیاز ریسک ذاتی (Inherent Risk)
• کنترل‌های موجود (Existing controls) و وضعیتشان
• امتیاز ریسک باقیمانده (Residual Risk) (اگر در همین مرحله محاسبه می‌کنی)
• مالک ریسک (Risk Owner)
• تصمیم اولیه: درمان/پذیرش/انتقال/اجتناب

روش اجرای عملی (بدون ورود به جزئیات اضافی)

• ورودی‌ها را آماده کن: Scope (فاز 1)، دارایی‌ها و طبقه‌بندی (فاز 2)، الزامات (قراردادی/قانونی)، رخدادهای گذشته (اگر دارید)، نتایج پایش/لاگ/تیکت‌ها.
• کارگاه ارزیابی ریسک برگزار کن: بهتر است کوتاه و چند جلسه‌ای باشد تا خسته‌کننده نشود و خروجی واقعی بدهد.
• ریسک‌ها را سناریو-محور بنویس: به جای جمله‌های کلی مثل “حمله سایبری”، سناریو بنویس: «دسترسی غیرمجاز به سامانه X به دلیل حساب‌های مشترک/عدم MFA → افشای داده Y → پیامد Z».
• اولویت‌بندی کن: خروجی این بخش باید نشان بدهد کدام ریسک‌ها واقعاً در صدر هستند و چرا.

شواهد (Evidence)

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

معیار قبولی

• ریسک‌ها به دارایی‌ها و Scope وصل‌اند (ریسک شناور و بی‌صاحب نداریم)
• برای ریسک‌های مهم، “دلیل” امتیازدهی ثبت شده (نه فقط عدد)
• مالک ریسک مشخص است و تصمیم‌ها قابل پیگیری‌اند

3-3) Risk Treatment Plan و ساخت SoA

هدف این بخش

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

خروجی‌ها (Deliverables)

1) Risk Treatment Plan (RTP)
RTP باید برای ریسک‌های اولویت‌دار مشخص کند:

• تصمیم درمان (Reduce/Avoid/Transfer/Accept)
• کنترل(ها) یا اقدام(ها)ی درمان ریسک
• مالک اقدام (Action Owner)
• زمان‌بندی/Deadline
• منابع موردنیاز
• معیار تکمیل و شواهد مورد انتظار (Evidence to prove implementation)
• ریسک باقیمانده هدف (Target residual risk)

2) SoA (Statement of Applicability)
SoA باید حداقل این ستون‌ها را داشته باشد:

• کنترل Annex A (یا دسته کنترل)
• وضعیت: Implemented / Planned / Not applicable
• توجیه (Justification): چرا انتخاب شده/چرا حذف شده
• ارتباط با ریسک (Link to Risk IDs) یا الزامات
• شواهد/مرجع مستندات (Policies/Procedures/Records) در حد لینک/نام سند

3) وضعیت اجرا و نقشه ردیابی (Traceability)
این یکی را خیلی جدی بگیر: باید بتوانی مسیر «ریسک → تصمیم درمان → کنترل → Evidence» را نشان بدهی. همین مسیر است که در ممیزی Stage 2 از تو دفاع می‌کند.

شواهد (Evidence)

• RTP مصوب (با مالک و زمان)
• SoA نسخه‌دار و به‌روز
• شواهد شروع اجرا: تیکت‌های تغییر، صورتجلسه‌ها، روال‌های اجرایی، گزارش‌های پایش/لاگ، نمونه رکوردها (بسته به کنترل)
• تأیید پذیرش ریسک برای ریسک‌هایی که Accept شده‌اند (Risk Acceptance Record)

معیار قبولی

• هیچ کنترل “بی‌دلیل” در SoA نداریم؛ یا به ریسک وصل است یا به الزام مشخص
• برای کنترل‌های Planned، زمان‌بندی و مالک و شواهد مورد انتظار مشخص است
• برای Not applicable، توجیه قابل دفاع است (نه جمله‌های کلی)
• مسیر ردیابی (Traceability) برقرار است: با چند کلیک/ارجاع می‌توانی نشان بدهی هر کنترل چرا آمده و Evidence آن چیست

نکته: «سوالات ممیز درباره ریسک، RTP و SoA» و چک‌کردن آمادگی ممیزی را اینجا باز نمی‌کنیم. برای خودارزیابی و ممیزی داخلی، از صفحه چک‌لیست ممیزی استفاده کن:
چک‌لیست ممیزی ISO 27001 (نسخه 2022)

فاز 4) اجرای کنترل‌ها با Evidence Pack (نه کنترل‌به‌کنترل)

هدف فاز

تا اینجا اسکلت ISMS را ساخته‌ای: Scope، دارایی‌ها، روش ریسک، Risk Register، RTP و SoA. اما چیزی که پروژه را «واقعی» می‌کند همین فاز است؛ چون اینجا کنترل‌ها از روی کاغذ وارد عملیات می‌شوند و خروجی‌شان تبدیل می‌شود به رکوردها و شواهد قابل ارائه. اگر این فاز را جدی نگیری، معمولاً نتیجه این می‌شود که سیاست‌ها و روش‌ها مرتب‌اند، ولی وقتی ممیز Evidence می‌خواهد، یا چیزی ندارید یا هر واحد یک مدل متفاوت اجرا کرده است.

تعریف Evidence Pack چیست و چرا سریع‌تر نتیجه می‌دهد؟

Evidence Pack یعنی به‌جای اینکه تک‌تک کنترل‌های Annex A را جداگانه توضیح بدهی و بعد هم برای هرکدام دنبال مدرک بگردی، کنترل‌ها را فرآیندمحور اجرا می‌کنی: برای چند فرآیند کلیدی امنیت اطلاعات (مثل دسترسی‌ها، رخداد، بکاپ، تامین‌کننده…) یک «بسته شواهد» می‌سازی که شامل سیاست/رویه حداقلی + فرم‌ها/لاگ‌ها + گزارش دوره‌ای + نمونه رکوردهای واقعی است. مزیتش این است که هم برای تیم اجرایی قابل فهم‌تر است، هم تولید Evidence را منظم می‌کند، و هم در ممیزی می‌توانی سریع و مرتب نشان بدهی «کنترل اجرا شده و نتیجه دارد» بدون اینکه وارد بحث‌های پراکنده و طولانی شوی.

Evidence Packهای پیشنهادی (حداقلی اما کافی)

1) Access Management Pack (مدیریت دسترسی‌ها)

هدف: کنترل دسترسی به سیستم‌ها و داده‌ها بر اساس نقش و نیاز کاری، و جلوگیری از دسترسی‌های رهاشده یا بیش‌ازحد.
اجزای اصلی رکورد/شواهد: فرآیند Joiner/Mover/Leaver، فرم/تیکت درخواست دسترسی، تایید Owner، لیست دسترسی‌های ویژه (Privileged Accounts)، اجرای MFA (حداقل برای ادمین‌ها و دسترسی‌های حساس)، بازبینی دوره‌ای دسترسی‌ها، ثبت استثناها و پذیرش ریسک.
خروجی قابل ارائه به ممیز: چند نمونه واقعی از ایجاد/تغییر/لغو دسترسی، گزارش بازبینی دسترسی‌ها، و شواهد کنترل حساب‌های ویژه.
معیار قبولی: هیچ دسترسی «بدون درخواست و تایید» ندارید و خروج کار قابل ردیابی است (چه کسی درخواست داد، چه کسی تایید کرد، چه زمانی اعمال شد، و چه زمانی بازبینی شد).

2) Incident Management Pack (مدیریت رخداد امنیت اطلاعات)

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

3) Backup/Recovery & DR Pack (بکاپ، بازیابی و تداوم/DR)

هدف: اطمینان از اینکه داده‌ها و سرویس‌های حیاتی در خرابی/حمله/خطا قابل بازیابی‌اند.
اجزای اصلی رکورد/شواهد: لیست دارایی‌های حیاتی و اولویت بکاپ، تعریف RTO/RPO (حداقلی اما روشن)، سیاست بکاپ و نگهداری، گزارش موفق/ناموفق بکاپ، تست دوره‌ای بازیابی (Restore Test)، نتایج تست و اقدامات اصلاحی، و اگر نیاز است سناریوی DR سطح‌بالا.
خروجی قابل ارائه به ممیز: گزارش‌های بکاپ، حداقل ۱–۲ گزارش تست بازیابی با نتیجه و زمان واقعی، و تصمیم‌های اصلاحی برای خطاها.
معیار قبولی: فقط «بکاپ گرفتن» کافی نیست؛ باید تست بازیابی داشته باشی و بتوانی نشان بدهی RTO/RPO برای سرویس‌های حیاتی قابل دستیابی است.

4) Vulnerability & Patch Management Pack (آسیب‌پذیری و به‌روزرسانی)

هدف: کاهش سطح حمله با شناسایی آسیب‌پذیری‌ها و رفع/کاهش آن‌ها طبق اولویت.
اجزای اصلی رکورد/شواهد: روش شناسایی (اسکن/چک‌لیست/گزارش فروشنده)، طبقه‌بندی و اولویت‌بندی، SLA اصلاح (مثلاً بحرانی/بالا/متوسط)، ثبت اقدامات (Patch/Config/Compensating control)، مدیریت استثناها (Exception Register) با دلیل و تاریخ بازنگری، گزارش ماهانه/فصلی وضعیت.
خروجی قابل ارائه به ممیز: گزارش اسکن یا لیست آسیب‌پذیری‌ها، نمونه تیکت‌های اصلاح، گزارش وضعیت رفع، و استثناهای تاییدشده.
معیار قبولی: برای آسیب‌پذیری‌های بحرانی، زمان پاسخ و تصمیم مشخص است و استثناها بدون مالک و تاریخ بازنگری رها نمی‌شوند.

5) Supplier Security Pack (امنیت تامین‌کنندگان و پیمانکاران)

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

6) Change Management / SDLC Pack (مدیریت تغییر/توسعه امن) — فقط اگر توسعه نرم‌افزار دارید

هدف: جلوگیری از ایجاد آسیب‌پذیری و قطعی سرویس به خاطر تغییرات کنترل‌نشده.
اجزای اصلی رکورد/شواهد: ثبت درخواست تغییر، ارزیابی ریسک تغییر، تایید قبل از اجرا، برنامه Rollback، محیط‌های تفکیک‌شده (Dev/Test/Prod)، مدیریت دسترسی به کد/ریپازیتوری، و در صورت امکان حداقل کنترل‌های Secure Coding (بازبینی کد/اسکن وابستگی‌ها).
خروجی قابل ارائه به ممیز: نمونه Change Requestها، تاییدها، گزارش انتشار/Release Note، و شواهد تفکیک محیط‌ها یا کنترل دسترسی به مخزن کد.
معیار قبولی: هیچ تغییر مهمی بدون ثبت، تایید و امکان برگشت انجام نمی‌شود.

7) Logging/Monitoring Pack (لاگ، مانیتورینگ و هشداردهی)

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

معیار قبولی فاز 4 (جمع‌بندی)

فاز 4 وقتی “قبول” است که برای هر Evidence Pack:

1. یک روال اجرایی روشن داشته باشی (حتی کوتاه)،
2. چند نمونه رکورد واقعی تولید شده باشد،
3. گزارش/بازبینی دوره‌ای وجود داشته باشد،
4. و بتوانی مسیر ردیابی را نشان بدهی: ریسک/الزام → کنترل → Evidence.

فاز 5) پایش عملکرد ISMS (Clause 9 در عمل)

هدف فاز

هدف این فاز این است که ISMS از حالت «پروژه‌ای که یک‌بار اجرا شد» خارج شود و تبدیل شود به یک سیستم زنده که اندازه‌گیری می‌شود، گزارش می‌دهد، و بهبود پیدا می‌کند. خیلی از سازمان‌ها تا فاز 4 خوب جلو می‌آیند، اما چون پایش و آموزش را جدی نمی‌گیرند، بعد از چند هفته Evidenceها قطع می‌شود و در ممیزی مراقبتی یا حتی Stage 2 مشکل ایجاد می‌شود. در فاز 5 تو باید یک چرخه ساده اما منظم بسازی: چه چیزهایی را پایش می‌کنی، هر چند وقت یک‌بار، با چه مسئولیتی، و خروجی‌اش دقیقاً چه گزارشی است.

خروجی‌ها (Deliverables)

1) برنامه پایش و اندازه‌گیری (Monitoring & Measurement Plan)
این برنامه لازم نیست طولانی باشد؛ اما باید شفاف بگوید:

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

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

• Access Management
  • درصد/تعداد دسترسی‌هایی که بدون تایید Owner ثبت نشده‌اند (هدف: نزدیک صفر)
  • تعداد بازبینی‌های دوره‌ای دسترسی انجام‌شده (طبق برنامه)
• Incident Management
  • تعداد رخدادهای ثبت‌شده + درصد رخدادهایی که ظرف SLA تریاژ شده‌اند
  • تعداد رخدادهایی که Lessons Learned و اقدام اصلاحی داشته‌اند
• Backup/Recovery
  • نرخ موفقیت بکاپ‌ها
  • تعداد تست بازیابی انجام‌شده + نتیجه (موفق/ناموفق) + اقدام اصلاحی
• Vulnerability/Patch
  • تعداد آسیب‌پذیری‌های بحرانی باز مانده خارج از SLA
  • تعداد استثناهای تاییدشده و تاریخ بازنگری آن‌ها
• Supplier Security
  • درصد تامین‌کنندگان پرریسک که ارزیابی امنیتی/بند قراردادی دارند
• آموزش و آگاهی
  • درصد افراد کلیدی که آموزش پایه را گذرانده‌اند
  • نتیجه یک ارزیابی ساده (کوییز کوتاه/تمرین) برای اثربخشی

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

3) برنامه آموزش و آگاهی (Awareness & Training Plan)
در ISO 27001، آموزش فقط “لیست حضور و غیاب” نیست. باید مشخص کنی:

• چه کسانی آموزش می‌بینند (عمومی/نقش‌های کلیدی مثل IT, HR, Procurement, Service Desk)
• چه موضوعاتی (حداقل: طبقه‌بندی اطلاعات، فیشینگ/مهندسی اجتماعی، گزارش رخداد، سیاست‌های دسترسی و رمز عبور، کار با داده‌های محرمانه)
• چه زمانی و با چه روش (جلسه کوتاه، ویدئو، آزمون کوتاه، پوستر/یادآوری)
• چطور اثربخشی را می‌سنجی (کوییز، تمرین سناریو، نرخ کلیک فیشینگ شبیه‌سازی—اگر دارید)

شواهد (Evidence)

برای پایش و KPIها

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

برای آموزش و آگاهی

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

معیار قبولی

فاز 5 وقتی “قبول” است که این 5 شرط برقرار باشد:

1. پایش، منظم و قابل تکرار است: یعنی اگر کسی دیگر هم جای تو بیاید، با همان برنامه بتواند داده‌ها را جمع کند و همان گزارش را تولید کند.
2. KPIها به ریسک و کنترل‌ها وصل‌اند: شاخص‌هایی انتخاب شده‌اند که نشان می‌دهند کنترل‌ها واقعاً کار می‌کنند، نه شاخص‌های تزئینی.
3. خروجی پایش منجر به تصمیم/اقدام می‌شود: فقط گزارش تولید نمی‌شود؛ موارد خارج از آستانه پیگیری و بسته می‌شوند.
4. آموزش اثربخشی دارد: صرفاً حضور ثبت نشده؛ یک معیار ساده برای “فهم و رفتار” وجود دارد.
5. Evidenceها قابل ارائه و قابل ردیابی‌اند: گزارش‌ها، رکوردها، و منابع داده مشخص‌اند و گم نمی‌شوند.

فاز 6) بستن حلقه کنترل: Audit داخلی + Management Review + CAPA

هدف فاز

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

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

6-1) ممیزی داخلی (Internal Audit) — چه زمانی و با چه ورودی‌هایی؟

چه زمانی انجام شود؟

ممیزی داخلی را زمانی انجام بده که دو شرط برقرار باشد:

1. خروجی‌های فاز 1 تا 3 تثبیت شده باشند (Scope، دارایی‌ها، روش ریسک، Risk Register، RTP، SoA).
2. حداقل چند Evidence Pack از فاز 4 واقعاً رکورد تولید کرده باشند (مثلاً دسترسی‌ها، بکاپ/بازیابی، رخداد، تامین‌کننده…).

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

ورودی‌های ممیزی داخلی (Inputs)

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

• Scope و مرزبندی ISMS (فاز 1)
• Asset Register و طبقه‌بندی (فاز 2)
• Risk Method + Risk Register + RTP + SoA (فاز 3)
• سیاست‌ها و رویه‌های کلیدی ISMS (نسخه‌های جاری)
• Evidence Packها و رکوردهای واقعی (نمونه‌ها و گزارش‌های دوره‌ای)
• نتایج پایش و KPIها (فاز 5)
• لیست الزامات قانونی/قراردادی مرتبط (اگر Scope به آن‌ها وابسته است)

خروجی‌های ممیزی داخلی (Deliverables)

در سطح صفحه پیاده‌سازی، کافی است خروجی‌ها را این‌گونه تعریف کنی:

• برنامه ممیزی داخلی (Audit Program/Plan): محدوده ممیزی، زمان‌بندی، تیم/ممیز، معیارها، و واحدهای تحت ممیزی.
• گزارش ممیزی داخلی: یافته‌ها (Conformity/Observation/Nonconformity)، شواهد مشاهده‌شده، و نتیجه کلی.
• ثبت عدم‌انطباق‌ها و اقدامات اصلاحی مرتبط (CAPA tickets/records): هر مورد با مالک و زمان‌بندی.

برای چک‌لیست سوالات ممیز، نحوه دقیق ثبت عدم‌انطباق، و نمونه سوالات/شواهد بندبه‌بند، از صفحه چک‌لیست ممیزی ISO 27001 استفاده کن:
چک‌لیست ممیزی ISO 27001 (نسخه 2022)

6-2) بازنگری مدیریت (Management Review) — چه چیزی باید روی میز مدیریت بیاید؟

هدف MR

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

• وضعیت امنیت اطلاعات را می‌فهمد،
• درباره ریسک‌ها و منابع تصمیم می‌گیرد،
• و خروجی‌اش بهبود واقعی است.

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

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

• وضعیت تحقق اهداف ISMS و KPIها (فاز 5)
• نتایج ممیزی داخلی (یافته‌ها و روند عدم‌انطباق‌ها)
• وضعیت ریسک‌های سطح بالا و تصمیم‌های پذیرش ریسک (High risks + Risk Acceptance)
• وضعیت اجرای RTP “طبق برنامه/عقب‌افتاده”
• رخدادهای امنیتی مهم و درس‌آموخته‌ها
• مسائل تامین‌کنندگان مهم (اگر در Scope اثرگذارند)
• نیاز به منابع/تغییرات کلیدی (نیروی انسانی، ابزار، آموزش، بودجه)
• فرصت‌های بهبود و تغییرات زمینه سازمان/Scope (اگر اتفاق افتاده)

خروجی‌های MR (Deliverables)

• صورتجلسه بازنگری مدیریت با تصمیم‌های روشن (چه چیزی تصویب شد/چه تغییری لازم است)
• اقدامات (Action Items) با مالک و زمان (بهبود کنترل، تکمیل RTP، تغییر KPI، آموزش، منابع)
• تصمیم درباره ریسک‌های باقیمانده (قبول/ادامه درمان/تغییر رویکرد)

6-3) CAPA (اقدام اصلاحی) — چطور از “رفع موردی” به “رفع علت” برسیم؟

هدف CAPA

CAPA یعنی عدم‌انطباق را فقط «جمع‌وجور» نکنی، بلکه علتش را پیدا کنی تا دوباره تکرار نشود. خروجی CAPA باید قابل پیگیری باشد و بعداً بتوانی اثرش را نشان بدهی.

حداقل خروجی‌های CAPA

برای هر عدم‌انطباق/مشاهده مهم، حداقل این چهار مورد را داشته باش:

• Correction (رفع فوری مشکل)
• Root Cause (علت ریشه‌ای)
• Corrective Action (اقدام اصلاحی برای جلوگیری از تکرار)
• Effectiveness Check (چطور بررسی می‌کنی اثر کرده؟)

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

معیار قبولی فاز 6 (جمع‌بندی)

این فاز وقتی “قبول” است که:

1. ممیزی داخلی اجرا شده و گزارش دارد (نه صرفاً برنامه روی کاغذ).
2. عدم‌انطباق‌ها به CAPA تبدیل شده‌اند و مالک/زمان دارند.
3. Management Review برگزار شده و تصمیم‌های قابل ردیابی دارد (منابع/اقدامات/تصمیم ریسک).
4. اثر حداقل بخشی از CAPAها بررسی شده یا حداقل روش اثربخشی تعریف شده است.
5. خروجی‌ها قابل ارائه‌اند و مسیر ردیابی برقرار است: یافته ممیزی → CAPA → اقدام → شواهد تکمیل/اثربخشی.

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

فاز 7) Certification Readiness (پیش از Stage 1/2)

هدف فاز

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

خروجی‌ها (Deliverables)

1) بسته نهایی Evidence (Evidence Pack Bundle)
یک ساختار پوشه‌ای/فهرست‌شده بساز که ممیز بتواند سریع پیدا کند:

• Scope و مرزبندی ISMS + زمینه سازمان و ذی‌نفعان
• Asset Register + طبقه‌بندی اطلاعات
• Risk Method + Risk Register (نسخه جاری)
• RTP + وضعیت اجرای اقدامات (On track / Delayed / Completed)
• SoA (نسخه جاری) + ارجاع به شواهد/مستندات
• سیاست‌ها و رویه‌های کلیدی ISMS (با کنترل نسخه)
• Evidence Packهای عملیاتی (دسترسی‌ها، رخداد، بکاپ/بازیابی، تامین‌کننده، آسیب‌پذیری/پچ، لاگ/مانیتورینگ…)
• خروجی‌های پایش و KPIها (گزارش‌های دوره‌ای)
• نتایج ممیزی داخلی + CAPAها + اثربخشی (هرجا بررسی شده)
• صورتجلسه/خروجی Management Review

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

2) ماتریس ردیابی (Traceability Matrix)
این خروجی، یک ابزار دفاعی فوق‌العاده است و کمک می‌کند ممیز را “سریع” جلو ببری:

• هر ریسک کلیدی → به کدام کنترل‌ها/اقدامات درمان وصل است → کدام Evidence آن را ثابت می‌کند.
• یا از سمت دیگر: هر کنترل کلیدی در SoA → چرا انتخاب شده → Evidence اجرا و پایش آن کجاست.

ماتریس لازم نیست طولانی باشد؛ کافی است ریسک‌ها و کنترل‌های مهم را پوشش دهد و برای بقیه به ارجاعات SoA اکتفا کند.

3) لیست نقاط ریسک و شکاف‌های باز (Open Issues / Residual Risk List)
یک لیست کوتاه اما شفاف از مواردی که:

• هنوز کامل نشده‌اند،
• یا استثنا دارند،
• یا ریسک باقیمانده‌شان بالاست،
  همراه با تصمیم روشن:
• درمان تا قبل از Stage 2
• پذیرش ریسک (با تایید مالک ریسک/مدیریت)
• کنترل جبرانی موقت (Compensating control)

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

4) برنامه جمع‌بندی و رفع نهایی (Close-out Plan)
برای ۱ تا ۳ هفته آخر قبل از ممیزی، یک برنامه کوتاه بساز که شامل باشد:

• چه اقداماتی باید بسته شود (از RTP/CAPA/Open Issues)
• مالک هر اقدام
• تاریخ تکمیل
• Evidence مورد انتظار (دقیقاً چه مدرکی باید تولید شود)
• نقطه کنترل نهایی (کی تایید می‌کند تمام شده)

5) بسته ارائه Stage 1 (Stage 1 Package)
Stage 1 معمولاً روی «آمادگی سیستم و مستندات کلیدی و طراحی ISMS» تمرکز دارد. بنابراین یک بسته خلاصه آماده کن:

• Scope + Context + Interested Parties
• Risk Method + SoA (نسخه جاری) + Risk Register در سطح کلی
• سیاست‌ها/رویه‌های کلیدی و ساختار کنترل مستندات
• برنامه ممیزی داخلی/پایش + شواهد اولیه اجرا (اگر ممیز درخواست کرد)

جزئیات Stage 1/Stage 2 را در صفحه اصلی ISO 27001 نگه دار تا هم‌پوشانی ایجاد نشود؛ اینجا فقط “چه چیزی آماده باشد” را می‌گوییم.

معیار قبولی (Acceptance Criteria)

فاز 7 وقتی “قبول” است که این شرط‌ها برقرار باشد:

1. Evidenceها کامل و قابل ارائه‌اند
   یعنی برای کنترل‌های کلیدی، فقط سند ندارید؛ رکوردهای واقعی و گزارش‌های دوره‌ای هم دارید و مسیر دسترسی به آن‌ها سریع است.
2. SoA قابل دفاع و به ریسک وصل است
   برای کنترل‌های مهم، دلیل انتخاب/حذف روشن است و به Risk ID یا الزام مشخص اشاره می‌کند؛ کنترل‌های Planned هم مالک/زمان دارند.
3. ریسک‌های باز مدیریت شده‌اند
   هر ریسک مهم یا درمان شده، یا برنامه درمان روشن دارد، یا به صورت رسمی پذیرفته شده و ثبت دارد. مورد “معلوم نیست” ندارید.
4. ممیزی داخلی و Management Review انجام شده
   گزارش ممیزی داخلی وجود دارد، CAPAها تعریف شده‌اند، و مدیریت روی خروجی‌ها تصمیم گرفته است (منابع/اقدامات/ریسک).
5. Traceability برقرار است
   اگر ممیز یک ریسک یا کنترل را انتخاب کند، شما می‌توانی در چند دقیقه نشان بدهی:

• چرا این کنترل انتخاب شده
• کجا اجرا شده
• چه Evidence عملیاتی آن را ثابت می‌کند
• و پایش/بازبینی آن چگونه انجام می‌شود

6. یک برنامه جمع‌بندی کوتاه برای موارد باقی‌مانده دارید
   حتی اگر ۱۰۰٪ همه چیز تکمیل نشده باشد، باید بتوانی نشان بدهی موارد باز را می‌شناسی و برایشان زمان و مالک و Evidence تعیین کرده‌ای.

چک‌لیست «حداقل لازم برای قابل دفاع بودن» (Deliverable/Evidence محور)

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

1. Scope Statement قابل دفاع داری (مرزها، واحدها/سایت‌ها، سیستم‌های کلیدی و استثناهای مستدل) و یک نسخه مشخص و تاریخ‌دار از آن موجود است.
2. Context و ذی‌نفعان و الزامات (قانونی/قراردادی/داخلی) را به شکل قابل ارائه ثبت کرده‌ای و اثرشان روی Scope مشخص است.
3. Asset Register حداقلی اما واقعی ساخته‌ای: دارایی‌های حیاتی، مالک دارایی، محل نگهداری/بستر، طبقه‌بندی و اهمیت CIA مشخص است.
4. مدل طبقه‌بندی اطلاعات (۳ یا ۴ سطح) نوشته شده و حداقل چند نمونه “اعمال‌شده” از طبقه‌بندی/قواعد کار با داده وجود دارد.
5. Risk Method مصوب داری (مقیاس احتمال/اثر + معیار پذیرش ریسک + تعریف ریسک باقیمانده) و نشان می‌دهی تیم‌ها برداشت مشترک دارند.
6. Risk Register نسخه‌دار داری که ریسک‌ها را به دارایی‌ها وصل کرده، دلیل امتیازدهی را ثبت کرده و برای ریسک‌های مهم مالک ریسک مشخص است.
7. RTP (برنامه درمان ریسک) داری که برای ریسک‌های اولویت‌دار: اقدام، مالک، زمان، و Evidence مورد انتظار را مشخص کرده است.
8. SoA نسخه‌دار و قابل ردیابی داری: وضعیت هر کنترل (Implemented/Planned/Not applicable) + توجیه + اتصال به Risk ID/الزام + ارجاع به شواهد/مستندات.
9. حداقل ۳ Evidence Pack عملیاتی واقعاً راه افتاده و رکورد واقعی تولید کرده است (مثلاً دسترسی‌ها، بکاپ/بازیابی، رخداد، تامین‌کننده، پچ/آسیب‌پذیری، لاگ/مانیتورینگ).
10. برای هر Evidence Pack، نمونه رکورد واقعی + یک گزارش/بازبینی دوره‌ای داری (یعنی فقط روال نیست؛ خروجی جاری هم هست).
11. برنامه پایش و اندازه‌گیری نوشته شده و حداقل یک دوره گزارش KPI/پایش تولید شده (حتی اگر کوتاه باشد).
12. آموزش/آگاهی حداقلی انجام شده و فقط لیست حضور نیست؛ یک سنجه ساده اثربخشی (کوییز/تمرین/بازخورد) داری.
13. ممیزی داخلی انجام شده و خروجی‌اش فقط “نظر” نیست: گزارش + یافته‌ها + شواهد مشاهده‌شده ثبت شده است.
14. برای یافته‌های مهم، CAPA ثبت شده (Correction، Root Cause، Corrective Action، Effectiveness Check) و حداقل بخشی از اقدامات بسته/در حال پیگیری است.
15. Management Review برگزار شده و صورتجلسه دارد: تصمیم‌های مدیریتی، اقدام‌های مصوب، و تصمیم درباره ریسک‌های باقیمانده ثبت شده است.

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

دانلودها و الگوهای اجرایی (DIY Kit)

ISO27001_Implementation_DIY_Kit.xlsx

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

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

2) Asset Register Template (تب: Asset_Register)
رجیستر دارایی‌ها برای شروع کار. پیشنهاد اجرایی: از دارایی‌های حیاتی شروع کن و بعد کاملش کن. ستون‌های نوع دارایی، طبقه‌بندی اطلاعات و CIA دارای لیست انتخابی هستند تا داده‌ها یکدست بمانند.

3) Risk Method + Risk Register (تب‌ها: Risk_Method و Risk_Register)

• در Risk_Method مقیاس احتمال/اثر و آستانه‌های پذیرش ریسک را یک‌بار تعریف می‌کنی.
• در Risk_Register سناریوی ریسک را می‌نویسی و امتیاز Inherent/Residual به‌صورت خودکار از ضرب Likelihood×Impact محاسبه می‌شود. تصمیم (Treat/Accept/Transfer/Avoid) و ارتباط با RTP هم همین‌جا ثبت می‌شود.

4) RTP Template (تب: RTP)
برای اینکه «درمان ریسک» از حالت توضیحی خارج شود و واقعاً تبدیل به برنامه اجرایی شود: اقدام‌ها، مسئول، تاریخ‌ها، شواهد مورد انتظار و روش سنجش اثربخشی را ثبت می‌کنی. این تب عملاً پل بین Risk Register و Evidence است.

5) SoA Template (تب: SoA)
قالب SoA آماده است، اما برای جلوگیری از خطا و همپوشانی، لیست کنترل‌های Annex A را از جدول Annex A خودتان (یا منبع رسمی که استفاده می‌کنید) داخل این تب Paste می‌کنی و بعد وضعیت (Implemented/Planned/Not applicable)، توجیه و لینک شواهد را تکمیل می‌کنی.

6) Evidence Tracker (تب: Evidence_Tracker)
ردیابی شواهد به‌صورت «بسته‌های شواهد» (Evidence Pack): هر مدرک/رکورد، مالک، تناوب، محل نگهداری و وضعیت (OK/Needs update/Missing) مشخص می‌شود تا در ممیزی دنبال فایل‌ها نگردی.

7) KPI / Monitoring Log (تب: KPI_Monitoring_Log)
دو بخش دارد: تعریف KPIها و سپس لاگ اندازه‌گیری. چند KPI نمونه هم گذاشته شده تا سریع راه بیفتد. بخش لاگ یک ستون وضعیت خودکار دارد (برای شروع کافی است؛ اگر خواستی بعداً دقیق‌ترش می‌کنیم).

8) Internal Audit Plan (تب: Internal_Audit_Plan)
این تب فقط «برنامه ممیزی داخلی» است (زمان‌بندی/دامنه/فرآیندها/ممیز/نمونه شواهد). عمداً وارد سوالات و چک‌لیست تفصیلی نمی‌شود تا با صفحه Audit Checklist شما همپوشانی نداشته باشد.

سوالات متداول پیاده‌سازی ISO 27001

منابع معتبر برای مقاله «پیاده‌سازی ISO 27001»

استانداردهای هسته (پایه ISMS)

• ISO/IEC 27001:2022 — Requirements (مرجع اصلی الزامات ISMS و مبنای پیاده‌سازی). (ISO)
• ISO/IEC 27002:2022 — Information security controls (کنترل‌ها + راهنمای پیاده‌سازی کنترل‌ها). (ISO)
• ISO/IEC 27000:2018 — Overview & vocabulary (تعاریف رسمی و واژگان مشترک خانواده 27000). (ISO)

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

• ISO/IEC 27003:2017 — ISMS guidance (راهنمای عملی برای تبدیل الزامات 27001 به گام‌های اجرایی). (ISO)
• ISO/IEC 27005:2018 — Information security risk management (راهنمای مدیریت ریسک امنیت اطلاعات، مکمل Risk Method/Risk Register). (ISO)
• ISO/IEC 27004:2016 — Monitoring, measurement, analysis & evaluation (پایه طراحی KPI و پایش اثربخشی). (ISO)
• ISO 31000:2018 — Risk management guidelines (مرجع عمومی اصول ریسک؛ برای هم‌راستاسازی روش ریسک در کل سازمان). (ISO)

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

• ISO 19011:2018 — Guidelines for auditing management systems (اصول ممیزی، برنامه ممیزی و شایستگی ممیز). (ISO)
• ISO/IEC 27007:2020 — ISMS auditing guidelines (راهنمای ممیزی ISMS در کنار 19011). (ISO)
• ISO/IEC TS 27008:2019 — Assessment of information security controls (راهنمای ارزیابی کنترل‌ها و سنجش اینکه کنترل واقعاً “کار می‌کند”). (ISO)

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

• ISO/IEC 27035-1:2016 — Incident management principles (چارچوب مدیریت رخداد برای Evidence Pack رخداد). (ISO)
• ISO/IEC 27036-1:2021 — Supplier relationships overview (پایه کنترل‌های امنیت تأمین‌کننده و پیمانکار). (ISO)
• ISO/IEC 27701:2019 — Privacy Information Management (Extension) (اگر داده شخصی/PII دارید و می‌خواهید PIMS را کنار ISMS توسعه دهید). (ISO)

چارچوب‌ها و راهنماهای رایگان و معتبر برای تکمیل پیاده‌سازی

• CSF 2.0 (Feb 26, 2024) (چارچوب حکمرانی و مدیریت ریسک سایبری برای هم‌راستاسازی مدیران و تیم‌ها). (NIST Publications)
• SP 800-53 Rev. 5 (با به‌روزرسانی‌های جزئی منتشرشده) (کتابخانه کنترل‌های امنیت/حریم خصوصی برای عمق‌دهی به کنترل‌ها و نگاشت به ISO). (NIST Computer Security Resource Center)
• SP 800-30 Rev.1 — Guide for Conducting Risk Assessments (روش‌شناسی ارزیابی ریسک برای تقویت Risk Method و یکدست‌سازی ارزیابی‌ها). (NIST Computer Security Resource Center)
• CIS Controls v8.1 (اولویت‌بندی کنترل‌ها و شروع سریع برای سازمان‌هایی که می‌خواهند اجرای عملی را تسریع کنند). (CIS)
• ASVS 4.0.3 (اگر نرم‌افزار/وب‌اپ دارید: معیارهای فنی امنیت برنامه برای Evidence قابل تست). (OWASP)