كتابة بيان قابلية التطبيق بما يصمد أمام التدقيق
بيان قابلية التطبيق هو الوثيقة الأكثر تدقيقًا في تدقيق ISO 27001، وأحد أكثر الوثائق التي يُعتمد فيها على القوالب الجاهزة. إليك كيفية كتابة وثيقة تصمد أمام التدقيق.
يشير البند 6.1.3(d) من ISO/IEC 27001 إلى إعداد بيان قابلية التطبيق: وثيقة تسرد الضوابط التي تحتاجها، وسبب إدراجها، وما إذا كانت منفذة، وسبب استبعاد أي ضابط من الضوابط الـ 93 الواردة في الملحق A. قد يبدو هذا إجرائيًا، لكنه عمليًا الجسر بين تقييم المخاطر والضوابط، ويقرأ مدققو الشهادة هذه الوثيقة بعناية، لأن بيان قابلية تطبيق ضعيفًا يعني غالبًا وجود عملية مخاطر ضعيفة خلفه.
ما الذي يجب أن يتضمنه
بالنسبة إلى كل ضابط في الملحق A، وأي ضوابط خاصة بمؤسستك:
- قابل للتطبيق أو غير قابل للتطبيق.
- مبرر الإدراج: عادةً المخاطر التي يعالجها، أو متطلب قانوني أو تعاقدي، أو قرار عمل.
- حالة التنفيذ: منفّذ، أو منفّذ جزئيًا، أو مخطط له.
- مبرر الاستبعاد، إذا كان الضابط مستبعدًا.
تضيف معظم بيانات قابلية التطبيق وصفًا موجزًا لكيفية تنفيذ كل ضابط، مع إشارة إلى السياسة أو الإجراء ذي الصلة. هذا غير مطلوب حرفيًا، لكنه يسرّع التدقيق كثيرًا.
تبرير الإدراج
اربط كل ضابط بأمر ملموس: خطر في سجل المخاطر، أو متطلب قانوني (المادة 32 من اللائحة العامة لحماية البيانات (GDPR)، وNIS2، أو لائحة قطاعية)، أو عقد، أو متطلب عميل. عبارة «أفضل الممارسات» مبرر ضعيف، أما «يعالج المخاطر R-12 وR-17 ومطلوب بموجب التزامات NIS2 لدينا» فمبرر قوي. كما يساعد ربط الضوابط بالمتطلبات القانونية عندما تُجيب عن عدة أطر في آن واحد: تُظهر صفحات المتطلبات لدينا الأطر الأخرى التي يُربط بها كل ضابط من الملحق A، على سبيل المثال A.8.24 استخدام التشفير.
تبرير الاستبعاد
الاستبعاد مسموح به، لكن كل استبعاد يحتاج إلى سبب يمكن للمدققين اختباره. من الأسباب الوجيهة:
- لا يحدث النشاط ضمن النطاق. لا يوجد تطوير خارجي: تم استبعاد A.8.30.
- الخطر غير موجود ضمن النطاق. قد تستبعد مؤسسة تعمل عن بُعد بالكامل دون مكاتب بعض ضوابط A.7 المادية، لكن ليس الضوابط التي تغطي الأجهزة ووسائط التخزين أينما وُجدت.
الأسباب الضعيفة: «غير ذي صلة»، و«تتولاه تقنية المعلومات»، و«مزود السحابة يقوم بذلك». إذا كان المورد هو من ينفذ الضابط فهو لا يزال قابلًا للتطبيق، وتديره عبر ضوابط الموردين.
نتائج التدقيق الشائعة
- لا يتطابق بيان قابلية التطبيق مع خطة معالجة المخاطر. يجب أن تظهر الضوابط المختارة في معالجة المخاطر في بيان قابلية التطبيق، والعكس صحيح.
- ضوابط منفذة بلا أدلة. وضع علامة «منفذ» على ضابط يستدعي طلب الإثبات.
- لغة القالب. أوصاف منسوخة من قالب لا تطابق ما تفعله فعليًا.
- نسخ قديمة. بيان قابلية تطبيق ما زال يسرد ترقيم الملحق A لعام 2013، أو لم يُحدَّث بعد تغيير جوهري.
هيكل عملي
صف واحد لكل ضابط: المعرّف والعنوان، وقابلية التطبيق (نعم/لا)، والسبب (المخاطر، والمتطلبات القانونية والتعاقدية)، والحالة، ووصف من سطر واحد لكيفية تنفيذه، والمالك، والإشارة إلى الدليل. احتفظ به في جدول بيانات أو في أداة GRC ضمن ضبط الوثائق، وراجعه مع كل تقييم للمخاطر.
الحفاظ على حيوية بيان قابلية التطبيق
بيان كُتب للشهادة الأولى ولم يُمسّ بعد ذلك يتحول إلى نتيجة تدقيق في التدقيق التالي. حافظ على حداثته بتحديثه كلما:
- غيّر تقييم المخاطر الضوابط المختارة؛
- تغيّر النطاق (منتج جديد، أو مكتب جديد، أو مزود سحابة جديد)؛
- تغيّرت حالة تنفيذ أحد الضوابط؛
- ينطبق متطلب قانوني أو تعاقدي جديد (مثل NIS2 أو عقد أحد العملاء).
سجّل الإصدار والتاريخ والمعتمِد في كل مرة.
أبرز النقاط
- كل ضابط في الملحق A يحتاج إلى قرار وسبب، بما في ذلك الاستثناءات.
- اربط الإدراجات بمخاطر محددة ومتطلبات قانونية أو تعاقدية محددة.
- حافظ على اتساق بيان قابلية التطبيق مع خطة معالجة المخاطر، وعلى حداثته.
إدارة عدة أطر في آن واحد
إذا كنت تُجيب أيضًا عن SOC 2 أو NIS2 أو PCI DSS، فأضف عمودًا للمتطلبات المقابلة في كل منها. يصبح بيان قابلية التطبيق عندها العمود الفقري لمجموعة ضوابط مشتركة؛ ويوضح منشورنا حول مجموعة ضوابط واحدة لـ SOC 2 وISO 27001 النهج، بينما يسرد تحليل الفجوات كل ضابط من الملحق A مقابل أي إطار آخر. ويغطي دليل ISO 27001 بقية جوانب الشهادة.
الأسئلة
هل يمكن استبعاد ضوابط الملحق A في ISO 27001؟
نعم، إذا كان الاستبعاد مبررًا، وغالبًا لأن الخطر غير موجود ضمن نطاقك (على سبيل المثال التطوير الخارجي عندما لا تستعين بمصادر خارجية للتطوير). يجب تبرير الاستثناءات في بيان قابلية التطبيق.
ماذا يجب أن يتضمن بيان قابلية التطبيق؟
يتطلب البند 6.1.3(d) من ISO 27001 الضوابط اللازمة، ومبرر إدراجها، وما إذا كانت منفذة، ومبرر استبعاد أي ضوابط من الملحق A.
هل يُشارك بيان قابلية التطبيق مع العملاء؟
عادةً لا يُشارك كاملًا؛ فهو وثيقة داخلية تراجعها جهة الشهادة. بعض المؤسسات تشارك ملخصًا مع العملاء بموجب اتفاقية عدم إفصاح لإظهار الضوابط المطبقة.
البيانات حتى تاريخ 2026-10-27: الأرقام الواردة في هذه المقالة محسوبة من جدول المطابقة الحالي وتُحدَّث عند تغييره. جدول المطابقة جدول مطابقة منشور (NIST، ENISA، CIS، PCI SSC) هو ما ينشئ الربط · تحريري حكم ControlMapping في الحالات التي لا يوجد فيها جدول مطابقة، مع عرض السبب · يشترك فقط في نتيجة CSF 2.0 واحدة: يستحق المراجعة، وليس ربطاً · لا يوجد ربط في بياناتنا لا يوجد ربط في بياناتنا؛ غالباً عمل جديد، لكن راجع ملاحظات التغطية. ليست نصيحة امتثال.
مقالات ذات صلة
التحليل · 2026-10-27APRA CPS 234 وISO 27001: ما الذي يغطيه ISMS وما الذي تضيفه APRAيغطي نظام ISMS وفق ISO 27001 تقريباً كل فقرة من CPS 234 الصادر عن APRA، ومع ذلك تضيف APRA واجبات على مجلس الإدارة، وتأكيداً من أطراف ثالثة، ومواعيد إخطار صارمة.
التحليل · 2026-10-13متطلبات MFA مقارنةً عبر 11 إطارًا أمنيًاأي الأطر تتطلب MFA، ولمن، وبأي درجة من الصرامة: مقارنة جنبًا إلى جنب لـ PCI DSS وCMMC وNIS2 وEssential Eight وISO 27001 وSOC 2 وHIPAA.
التحليل · 2026-09-15مقارنة متطلبات التشفير: ما تحدده الأطر وما تتركه لتقديرككيف تعالج ISO 27001 وPCI DSS وCMMC وHIPAA وGDPR وNIS2 التشفير أثناء التخزين وأثناء النقل وإدارة المفاتيح، مع معرّفات المتطلبات.