در بسیاری از پروژههای ISMS، تیم امنیت فهرستی از کنترلهای Annex A را میگیرد و کنار هر کنترل مینویسد «اجرا شد» یا «اجرا نشد». این کار بهتنهایی Statement of Applicability یا بیانیه کاربردپذیری نیست. SoA باید نشان دهد سازمان بر اساس ریسک و الزامات خود چه کنترلهایی را لازم دانسته، چرا آنها را انتخاب کرده، وضعیت اجرای آنها چیست و اگر کنترلی از Annex A لازم تشخیص داده نشده، دلیل این تصمیم چیست.
این مقاله بر اساس ISO/IEC 27001:2022 و یادداشت تخصصی ISO/IEC JTC 1/SC 27 درباره SoA نوشته شده است و هدف آن ارائه یک روش عملی برای ساخت سندی قابل دفاع در ممیزی است.
SoA چه مسئلهای را حل میکند؟
ارزیابی ریسک میگوید چه ریسکهایی نیازمند درماناند. برنامه درمان ریسک میگوید چه اقدامهایی باید انجام شوند. بیانیه کاربردپذیری نشان میدهد کنترلهای لازم سازمان کداماند و ارتباط آنها با Annex A چگونه برقرار شده است.
| سند | پرسش اصلی | خروجی |
|---|---|---|
| Risk Assessment | چه ریسکهایی داریم؟ | ریسک، احتمال، اثر و سطح ریسک |
| Risk Treatment Plan | با ریسک چه میکنیم؟ | اقدام، مالک، زمان و وضعیت |
| Statement of Applicability | کدام کنترلها برای ISMS لازماند؟ | کنترل، توجیه، وضعیت و نگاشت |
همه بندهای ۴ تا ۱۰ قابل حذف نیستند
یادداشت رسمی SC 27 تأکید میکند که الزامات اصلی ISO/IEC 27001 در بندهای ۴ تا ۱۰ الزامات سیستم مدیریت هستند و نمیتوان آنها را مانند یک کنترل Annex A کنار گذاشت. Annex A مجموعهای از کنترلهای مرجع است که برای بررسی کفایت کنترلهای لازم سازمان استفاده میشود.
بنابراین عبارت «این بند ISO برای ما Applicable نیست» را نباید درباره الزامات اصلی سیستم مدیریت بهسادگی به کار برد. موضوع Applicability در SoA اساساً درباره کنترلها و نحوه انتخاب آنهاست.
کنترل لازم میتواند خارج از Annex A باشد
طبق یادداشت ISO/IEC JTC 1/SC 27، اگر سازمان کنترلی را برای درمان ریسک لازم بداند که متن آن در Annex A وجود ندارد، آن کنترل نیز باید در SoA منعکس شود. SoA صرفاً کپی جدول Annex A نیست؛ فهرست کنترلهای لازم ISMS سازمان است که باید با Annex A مقایسه و نگاشت شود.
برای نمونه، سازمان ممکن است یک کنترل فنی اختصاصی برای محیط صنعتی، سامانه قدیمی یا الزام قراردادی خود داشته باشد. اگر این کنترل برای درمان ریسک لازم است، حذف آن از SoA فقط به این دلیل که نامش در Annex A نیست منطقی نیست.
ستونهای پیشنهادی SoA
ISO قالب اجباری واحدی برای ظاهر SoA تعیین نمیکند. در عمل، یک جدول روشن میتواند کار ممیزی و نگهداری را ساده کند.
| ستون | کاربرد |
|---|---|
| شناسه کنترل | شناسه داخلی یا مرجع Annex A |
| عنوان کنترل | نام قابل فهم کنترل |
| لازم است؟ | بله/خیر بر اساس نتیجه تحلیل |
| توجیه | دلیل انتخاب یا عدم نیاز |
| منبع نیاز | ریسک، قانون، قرارداد یا الزام ذینفع |
| وضعیت اجرا | برنامهریزیشده، جزئی، اجراشده یا نیازمند بهبود |
| مالک کنترل | مسئول پاسخگو برای اجرای کنترل |
| شواهد | سیاست، گزارش، تنظیم، تیکت یا رکورد ممیزی |
مرحله ۱: ریسکها و الزامات را جمع کنید
ساخت SoA را از Annex A شروع نکنید. ابتدا خروجی ارزیابی ریسک، الزامات قانونی و قراردادی، نیازهای مشتری، الزامات گروه شرکت و سایر تعهدهای مرتبط با ISMS را جمع کنید. کنترل باید پاسخی به یک نیاز واقعی باشد.
مرحله ۲: کنترلهای لازم را تعیین کنید
برای هر ریسک یا الزام، مشخص کنید چه کنترل یا مجموعه کنترلی برای رسیدن به سطح ریسک پذیرفتنی لازم است. سپس این کنترلها را با Annex A مقایسه کنید تا مطمئن شوید کنترل مرجع مرتبطی از قلم نیفتاده است.
مرحله ۳: عدم کاربرد را توضیح دهید
نوشتن «Not Applicable» بدون دلیل کافی نیست. اگر کنترل مرجع Annex A لازم نیست، توجیه باید با دامنه، معماری، ریسک یا مدل کسبوکار سازمان مرتبط باشد. برای مثال، اگر سازمان توسعه نرمافزار انجام نمیدهد، باید روشن باشد کدام فعالیت واقعاً خارج از دامنه است؛ نه اینکه صرفاً عنوان کنترل برای تیم ناآشنا باشد.
مرحله ۴: وضعیت اجرا را با Applicability قاطی نکنید
کنترلی ممکن است «لازم» باشد اما هنوز کامل اجرا نشده باشد. این کنترل همچنان Applicable است. وضعیت اجرا باید جدا ثبت شود تا SoA به ابزار پنهان کردن Gap تبدیل نشود.
مرحله ۵: مالک و شاهد تعیین کنید
کنترل بدون مالک در عمل به فعالیتی بیسرپرست تبدیل میشود. برای هر کنترل لازم، یک مالک پاسخگو، نوع شواهد و دوره بازبینی تعیین کنید. مالک کنترل لزوماً مجری همه فعالیتها نیست، اما باید بداند کنترل چگونه اثبات میشود.
SoA چه زمانی باید بازبینی شود؟
- پس از تغییر مهم در دامنه ISMS؛
- پس از ارزیابی ریسک جدید یا تغییر سطح ریسک؛
- پس از الزام قانونی یا قراردادی جدید؛
- پس از تغییر معماری، فناوری یا تأمینکننده مهم؛
- پس از رخداد امنیتی که کفایت کنترل را زیر سؤال ببرد؛
- پیش از ممیزیهای مهم و بازنگری مدیریت.
اشتباههای رایج
- کپی Annex A بدون ارتباط با ریسک؛
- علامت زدن «Not Applicable» برای کنترل اجرا نشده؛
- نداشتن توجیه برای کنترلهای حذفشده؛
- ندیدن کنترلهای خارج از Annex A؛
- نداشتن مالک و شواهد؛
- بهروزرسانی SoA فقط نزدیک ممیزی.
پیوند SoA با ابزارهای عملیاتی
برای کنترلهای فنی، شواهد میتوانند از سامانههای عملیاتی مانند SIEM، PAM، مدیریت پچ، سرویس دسک و مدیریت دارایی تولید شوند. این ابزارها خودبهخود «انطباق ISO» ایجاد نمیکنند؛ اما اگر کنترل، مالک، معیار و شواهد مشخص باشند، میتوانند اجرای کنترل را قابل اثبات کنند.
برای نمونه، کنترل مدیریت دسترسی ممتاز میتواند با PAM360 و کنترل مدیریت رخداد یا درخواست تغییر با ServiceDesk Plus شواهد عملیاتی تولید کند.
نکات کلیدی
- SoA کپی Annex A نیست؛ فهرست کنترلهای لازم سازمان است.
- کنترل لازم خارج از Annex A نیز باید در SoA دیده شود.
- Applicable بودن با اجرا شدن کامل یکسان نیست.
- توجیه عدم کاربرد باید قابل دفاع باشد.
- مالک و شواهد باید بخشی از نگهداری کنترل باشند.
سخن پایانی
بیانیه کاربردپذیری زمانی ارزش دارد که بتوان از روی آن فهمید چرا هر کنترل وجود دارد، چه ریسکی را پوشش میدهد، چه کسی مسئول آن است و وضعیت واقعی اجرای آن چیست. یک SoA زنده، حلقه اتصال ریسک، کنترل، عملیات و ممیزی است؛ نه فایل اکسل ثابتی که فقط قبل از ممیزی باز شود.
مدانت در طراحی ISMS، نگاشت کنترلها به ابزارهای عملیاتی، مدیریت ریسک و ایجاد شواهد فنی برای ممیزی سازمانها خدمات مشاوره و پیادهسازی ارائه میدهد.
