در بسیاری از دورههای ISMS و ISO/IEC 27001، تمرکز اصلی بر بندهای استاندارد، Annex A، مستندسازی و آمادگی ممیزی است. دانشجویان با ساختار کنترلها آشنا میشوند، ریسکارزیابی را یاد میگیرند و حتی توانایی تدوین سیاستها را پیدا میکنند. اما زمانی که وارد میدان واقعی، بهویژه در محیط پیچیدهای مانند بانک، میشوند با چالشی جدی روبهرو میگردند: فقدان نگاه فرآیندی و ضعف در مدیریت جلسات و تعامل مدیریتی.
این شکاف معمولاً برای متخصصانی که پیشینه فنی و «دست به آچار» دارند عمیقتر است. آنها سرورها را بهخوبی Harden میکنند، فایروال را تنظیم میکنند و لاگها را تحلیل میکنند؛ اما وقتی باید درباره «فرآیند Patch Management» یا «حاکمیت ریسک» با مدیران ارشد صحبت کنند، دچار تردید یا پراکندگی میشوند. مسئله دانش فنی نیست؛ مسئله تغییر زاویه نگاه است.
در ذهن فنی، سؤال این است: «آیا این سرور Patch شده است؟»
در ذهن فرآیندی، سؤال این است: «چه سازوکاری تضمین میکند تمام سرورها بهموقع Patch شوند و شواهد آن قابل ارائه باشد؟»
ISO 27001 به دنبال کنترلهای پایدار، تکرارپذیر و قابل ممیزی است. بنابراین تمرکز آن بر «سیستم» است نه «مهارت فرد». دانشجویانی که صرفاً چکلیستها را حفظ میکنند، در تبدیل فعالیتهای IT به جریانهای فرآیندی (Process Flow) ضعف دارند. آنها به جای تعریف ورودی، خروجی، مالک فرآیند، شاخص عملکرد و نقاط کنترل، در جزئیات فنی غرق میشوند.
اینجاست که ابزارهایی مانند Process Mapping و SIPOC اهمیت پیدا میکنند. وقتی یک فعالیت مانند Incident Management را بهصورت Supplier–Input–Process–Output–Customer تحلیل میکنیم، ناگهان از سطح تکنیکی به سطح مدیریتی ارتقا مییابیم. در بانک، مدیرعامل نمیپرسد چه پورتهایی بسته شدهاند؛ او میپرسد چه تضمینی وجود دارد که در صورت قطعی Core Banking، خدمت در زمان توافقشده بازگردد.
یکی از ضعفهای رایج دانشجویان ISMS، ناتوانی در ترسیم فرآیندهاست. آنها میدانند Change Management چیست، اما نمیتوانند آن را در قالب یک Flowchart استاندارد ارائه دهند. این ضعف فقط ظاهری نیست؛ نشانه عدم درک ساختاری است. نمودار فرآیند، زبان مشترک بین IT و مدیریت است. وقتی درخواست دسترسی کاربر از «درخواست» تا «تأیید» تا «ثبت در لاگ» بهصورت تصویری نمایش داده میشود، هم کنترلها شفاف میشوند و هم مسئولیتها.
در بانکها که محیطی تحت نظارت شدید رگولاتوری هستند، این شفافیت حیاتی است. ممیز به دنبال Evidence است، نه توضیح شفاهی. فرآیندی که رسم نشده، مالک ندارد و شاخص ندارد، در عمل کنترل محسوب نمیشود.
بخش دوم شکاف، مهارت اداره جلسات است. بسیاری از دورههای ISMS درباره چگونگی تدوین سیاست صحبت میکنند، اما کمتر به این میپردازند که چگونه آن سیاست را در کمیته راهبری تصویب کنیم. دانشجویان اغلب نمیدانند جلسه با هیئتمدیره باید با «ریسک» آغاز شود نه با «کنترل».
اشتباه رایج متخصصان فنی در جلسات عبارت است از:
ورود به جزئیات فنی غیرضروری
دفاع احساسی از راهکار پیشنهادی
نداشتن خلاصه مدیریتی
عدم تعیین خروجی مشخص برای جلسه
در فضای بانکی، زمان مدیران محدود است و زبان آنها زبان ریسک، هزینه، اثر عملیاتی و مسئولیت قانونی است. اگر مجری ISO نتواند Hardening را به «کاهش احتمال نقض داده و جریمه رگولاتوری» ترجمه کند، پیام او شنیده نخواهد شد.
چند دلیل اصلی وجود دارد:
تمرکز بیش از حد بر قبولی در آزمون
بسیاری از دانشجویان به دنبال اخذ گواهی هستند، نه اجرای واقعی. بنابراین به حفظ بندها بسنده میکنند.
سابقه فنی غالب
اکثر شرکتکنندگان در دورههای ISMS از واحد IT میآیند. ذهن آنها عملیاتی است و کمتر در معرض مفاهیم مهندسی صنایع یا مدیریت فرآیند بودهاند.
کمبود تمرین عملی
کمتر دورهای دانشجویان را مجبور میکند یک فرآیند بانکی واقعی را Map کنند یا جلسه شبیهسازی مدیریتی برگزار کنند.
راهکار: آموزش مبتنی بر تبدیل زاویه دید
برای رفع این ضعفها، آموزش ISMS باید سه محور داشته باشد:
تمرین سیستماتیک Process Mapping
هر دانشجو باید حداقل چند فرآیند کلیدی مانند Patch Management، Access Provisioning و Backup & Restore را رسم کند و مالک، ورودی، خروجی و KPI تعریف نماید.
تمرین ارائه مدیریتی
دانشجویان باید یاد بگیرند یک موضوع فنی را در سه دقیقه به زبان ریسک بیان کنند. مثلاً به جای «SMBv1 فعال است»، بگویند «این وضعیت احتمال سوءاستفاده باجافزار را افزایش میدهد و میتواند منجر به توقف عملیات شعب شود.»
شبیهسازی جلسه
برگزاری جلسات تمرینی با نقشهای مشخص (CIO، مدیر ریسک، مدیر شعب) کمک میکند دانشجو مهارت هدایت جلسه، مدیریت زمان و جمعبندی تصمیم را بیاموزد.
تغییر هویت حرفهای
در نهایت، اجرای موفق ISO 27001 نیازمند تغییر هویت از «کارشناس فنی» به «طراح سیستم کنترلی» است. این تغییر مستلزم درک این حقیقت است که استاندارد به دنبال قهرمانان فنی نیست؛ به دنبال فرآیندهای پایدار است.
در بانک، موفقیت ISMS زمانی رخ میدهد که:
فرآیندها مستند و تصویری باشند
مالک مشخص داشته باشند
شاخص عملکرد تعریف شده باشد
Evidence بهصورت مستمر تولید شود
مدیریت ارشد درگیر و متعهد باشد
متخصص فنی اگر بتواند این پنج عنصر را درک و پیاده کند، نهتنها مجری ISO خواهد بود، بلکه رهبر حاکمیت امنیت اطلاعات خواهد شد.
ضعف دانشجویان ISMS در نگاه فرآیندی و مهارت جلسات، یک نقص شخصی نیست؛ نتیجه ساختار آموزشی ناقص است. اما این ضعف قابل جبران است. با تمرین Process Mapping، استفاده از ابزارهایی مانند SIPOC، و یادگیری زبان مدیریتی، متخصص فنی میتواند به مجری موفق ISMS در محیطی حساس مانند بانک تبدیل شود.
در نهایت، ISO 27001 بیش از آنکه یک پروژه فنی باشد، یک پروژه حکمرانی است. و حکمرانی بدون فرآیند و بدون ارتباط مؤثر با مدیریت، محقق نخواهد شد.
