ISO 27001 بأدوات مفتوحة المصدر من المخاطر إلى التدقيق

بعد أن أنهت شركة منصة حجز مواعيد العيادات تقييمها الذاتي الأول على الضوابط الأساسية ECC-2:2024، وبنت سجل مخاطرها وجامع أدلتها في المقالات السابقة من هذه المرحلة، وصلها عرض من مجموعة مستشفيات خاصة كبيرة، وفي شروط المنافسة سطر واحد: «شهادة ISO/IEC 27001:2022 سارية لنطاق يشمل الخدمة المقدمة، أو خطة معتمدة للحصول عليها خلال اثني عشر شهراً». واجتمع الفريق ليقرر، وكان السؤال الأول للمدير: «هل نشتري برنامجاً تجارياً للامتثال كما تفعل الشركات الكبيرة؟»، والسؤال الثاني: «هل ما بنيناه لـ ECC يذهب هدراً، أم نبني عليه؟».

والإجابة التي يحاول هذا المقال إثباتها أن أغلب ما تحتاجه شهادة ISO/IEC 27001 في شركة بهذا الحجم تستطيع بناءه بأدوات مفتوحة المصدر، وأن نصف العمل منجز إذا كنت بنيت برنامج ECC بالطريقة الصحيحة، وأن ما يبقى ليس أدوات، وإنما نظام إدارة: نطاق مكتوب، وقرار لكل ضابط من الضوابط الـ 93، وتدقيق داخلي، ومراجعة إدارة. وقد شرحنا الفرق بين ISO/IEC 27001 والأطر الأخرى ومن يحتاج أياً منها في مقال الأطر، فلن نعيد المقارنة، وسوف نمشي على المعيار بنداً بنداً من النطاق إلى تدقيق الشهادة، ونضع أمام كل بند الأداة التي استخدمتها الشركة والمقال الذي شرحها، ثم نبني أهم وثيقة في المشروع كله، بيان قابلية التطبيق Statement of Applicability، بسكربت حقيقي على قائمة الضوابط الحقيقية.

دليلأطر الأمن السيبراني Frameworks: أيها تحتاج مؤسستك؟الفرق بين ECC وISO 27001 وNIST CSF وSOC 2 في الإلزام وطريقة الإثبات وما تحصل عليه، وأربعة أسئلة تحدد بها ما تحتاجه مؤسستك.دليلسجل المخاطر Risk Register مع SimpleRisk على سيرفركنبني سجل مخاطر حقيقياً بنموذج الهيئة ثم بأداة SimpleRisk، ونرى لماذا أعطت الأداة كل المخاطر مستوى واحداً، وكيف تكتب منهجية تعطي الأرقام معناها.دليلإدارة الامتثال Compliance مع CISO Assistant على سيرفركنشغل CISO Assistant ونحمل فيه ضوابط ECC-2:2024 ونقيم منصة حقيقية ونربطها بالضوابط والأدلة ونصدر التقرير، مع كل مشكلة واجهناها في الطريق.دليلجمع أدلة الامتثال Evidence تلقائياً بدل لقطات الشاشةنبني جامع أدلة صغيراً يقرأ إعدادات السيرفرات عبر SSH ويحفظها بالهاش، ثم نجربه على تغيير مفاجئ ودليل معدل وجامع فقد صلاحيته بصمت.

وسوف نناقش في هذا المقال ما يلي:

• ما الذي يطلبه المعيار فعلاً: البنود الإلزامية من 4 إلى 10، والملحق Annex A بضوابطه الـ 93، ولماذا لا تبدأ بالملحق.
• النطاق Scope: كيف رسمت الشركة حدود نظامها، ولماذا كان النطاق الضيق قراراً صحيحاً.
• المخاطر ومعالجتها: كيف يعاد استخدام سجل المخاطر الذي بنيناه لـ ECC.
• بيان قابلية التطبيق: تجربة عملية تولد البيان من قائمة الضوابط وتكشف أخطاء المسودة الأولى.
• الدعم والتشغيل: السياسات والكفاءات والتوعية والوثائق، والضوابط بأدواتها.
• تقييم الأداء: القياس، والتدقيق الداخلي، ومراجعة الإدارة، وهي الخطوات التي تتخطاها أغلب الجهات.
• التحسين وعدم المطابقة، ثم تدقيق الشهادة: من يمنحها، وكيف تتحقق منها، وكم تكلف الوثيقة نفسها.
• ما الذي تضيفه ECC وما الذي يضيفه ISO، وقائمة تحقق قبل أن تطلب التدقيق.

ما الذي يطلبه المعيار فعلاً؟

المعيار ISO/IEC 27001:2022 وثيقة قصيرة، 19 صفحة بحسب صفحته الرسمية، وسعرها 155 فرنكاً سويسرياً، ومعه تعديل صدر في 2024 يخص تغير المناخ ويوزع مجاناً. وهو يتكون من جزأين يخلط بينهما كثيرون: بنود إلزامية مرقمة من 4 إلى 10 تصف نظام إدارة أمن المعلومات ISMS، وملحق Annex A فيه قائمة ضوابط. والعناوين كما في مخطط المعيار المنشور في مكتبة CISO Assistant، والتي تذكر صراحة أنها مخطط للمعيار وأن النص الكامل يشترى من ISO: سياق المنظمة، والقيادة، والتخطيط، والدعم، والتشغيل، وتقييم الأداء، والتحسين. والشكل التالي يضعها مع ما استخدمته الشركة لكل منها:

والخطأ الأشهر أن تفتح الملحق أولاً، فتجد 93 ضابطاً، فتبدأ بتطبيقها واحداً واحداً كأنها قائمة مهام. والسبب الذي يجعل هذا خطأ أن المعيار لا يطلب منك تطبيق الضوابط كلها، وإنما يطلب أن تقيم مخاطرك، ثم تختار الضوابط التي تعالجها، ثم تقارن اختيارك بالملحق حتى لا تنسى شيئاً، ثم تكتب قرارك في كل ضابط مع سببه. أي أن الملحق أداة فحص للنسيان وليس خطة عمل، وأن الوثيقة التي تجمع القرارات، بيان قابلية التطبيق، تأتي بعد تقييم المخاطر وليس قبله. وهذا بالضبط ما يجعل المعيار مختلفاً عن ECC، فالضوابط الأساسية تقول لك ماذا تطبق، والمعيار يقول لك كيف تقرر ماذا تطبق، ثم يحاسبك على قرارك.

وقد حللنا في مقال الأطر جدول الربط الرسمي الذي تنشره NIST بين إطارها CSF 2.0 والمعيار، فوجدنا أن الجدول يشير إلى 93 ضابطاً مختلفاً من الملحق بأرقام محاورها: 37 تنظيمية في البند 5، و8 للأفراد في البند 6، و14 مادية في البند 7، و34 تقنية في البند 8. ونفس الأعداد تظهر في مكتبة CISO Assistant التي سوف نستخدمها في التجربة، وهذا التطابق بين مصدرين مستقلين يطمئنك إلى أن القائمة كاملة.

وإذا احتجت شرحاً لكل ضابط في الملحق، فالمعيار المصاحب ISO/IEC 27002:2022 هو الإرشاد التفصيلي للضوابط نفسها، وصفحته الرسمية تذكر أنه في 152 صفحة بسعر 227 فرنكاً سويسرياً، أي أنه أطول من المعيار الأساسي بكثير لأنه يشرح الغرض من كل ضابط وطرق تطبيقه. وهو ليس شرطاً للشهادة، لكن أغلب فرق التطبيق تشتريه مع المعيار، لأن أسماء الضوابط القصيرة وحدها لا تكفي لتقرير ما يكفي وما لا يكفي، والقرار في البيان يحتاج فهم الغرض قبل الحكم على الانطباق.

من إصدار 2013 إلى 2022: ماذا تغير في الملحق؟

إذا كانت لديك وثائق قديمة، أو نموذج بيان قابلية تطبيق وجدته على الإنترنت، فالأرجح أنه مكتوب على الإصدار السابق ISO/IEC 27001:2013، الذي سحبته ISO بعد صدور إصدار 2022 كما تبين صفحة المعيار في دورة حياته. والفرق في الملحق كبير: مكتبة CISO Assistant لإصدار 2013 فيها 114 ضابطاً قابلاً للتقييم في الملحق، مقابل 93 في 2022، والترقيم تغير كله، من محاور مثل A.9 للتحكم في الوصول وA.12 لأمن العمليات إلى أربعة محاور فقط. وحتى لا نعتمد على ما يقال، كتبنا سكربتاً صغيراً يقرأ ملف الربط بين الإصدارين في المكتبة نفسها، ويحسب أي ضوابط 2022 ليس لها مقابل في 2013، ونحفظه باسم transition.py:

# Which ISO/IEC 27001:2022 Annex A controls have no counterpart in the 2013 edition, per the mapping in the CISO Assistant library
import yaml, collections

lib = yaml.safe_load(open("iso27001-2022.yaml", encoding="utf-8"))
names = {c["ref_id"]: c["name"] for c in lib["objects"]["reference_controls"]}
m = yaml.safe_load(open("mapping-iso27001-2013-and-iso27001-2022.yaml", encoding="utf-8"))
forward = m["objects"]["requirement_mapping_sets"][0]["requirement_mappings"]   # 2013 -> 2022

mapped = collections.defaultdict(set)
for r in forward:
    src = r["source_requirement_urn"].rsplit(":", 1)[1].upper()   # urns use lower case: a.5.1
    dst = r["target_requirement_urn"].rsplit(":", 1)[1].upper()
    if dst.startswith("A."):
        mapped[dst].add(src)

new = [ref for ref in names if ref not in mapped]
merged = {ref: srcs for ref, srcs in mapped.items() if len(srcs) > 1}
print("2022 Annex A controls:", len(names))
print("with a 2013 counterpart:", len(mapped), " merged from several 2013 controls:", len(merged))
print("new in 2022:", len(new))
for ref in new:
    print(" ", ref, names[ref])
top = sorted(merged.items(), key=lambda kv: -len(kv[1]))[:3]
for ref, srcs in top:
    print("merged:", ref, names[ref], "<-", ", ".join(sorted(srcs)))

ونشغله بعد تنزيل ملف الربط mapping-iso27001-2013-and-iso27001-2022.yaml من المكتبة بالطريقة نفسها التي نزلنا بها ملف المعيار:

2022 Annex A controls: 93
with a 2013 counterpart: 78  merged from several 2013 controls: 20
new in 2022: 15
  A.5.5 Contact with authorities
  A.5.6 Contact with special interest groups
  A.5.7 Threat intelligence
  A.5.14 Information transfer
  A.5.23 Information security for use of cloud services
  A.5.30 ICT readiness for business continuity
  A.7.4 Physical security monitoring
  A.8.9 Configuration management
  A.8.10 Information deletion
  A.8.11 Data masking
  A.8.12 Data leakage prevention
  A.8.16 Monitoring activities
  A.8.23 Web filtering
  A.8.28 Secure coding
  A.8.34 Protection of information systems during audit testing
merged: A.7.10 Storage media <- A.11.2.5, A.8.3.1, A.8.3.2, A.8.3.3
merged: A.8.14 Redundancy of information processing facilities <- A.13.2.1, A.13.2.2, A.13.2.3, A.17.2.1
merged: A.5.17 Authentication information <- A.9.2.4, A.9.3.1, A.9.4.3

في المخرج أعلاه لاحظ التالي:

• عشرون ضابطاً في 2022 دمجت من أكثر من ضابط في 2013، مثل وسائط التخزين A.7.10 التي جمعت أربعة ضوابط، وهذا سبب أن العدد نقص من 114 إلى 93 دون أن يختفي شيء مهم.
• القائمة الجديدة تضم ضوابط تخص ما تغير في العالم منذ 2013، مثل الخدمات السحابية A.5.23 ومعلومات التهديدات A.5.7 وإدارة الإعدادات A.8.9 ومراقبة الأنشطة A.8.16 والبرمجة الآمنة A.8.28، ومنها ضابطان كشف السكربت السابق مشكلتين فيهما في مسودة الشركة.
• لكن انتبه: السكربت يقول إن 15 ضابطاً جديد، وأربعة منها لها مقابل واضح في 2013 بأسماء متقاربة في المكتبة القديمة، فـ A.5.5 «الاتصال بالسلطات» يقابله A.6.1.3 بالاسم نفسه، وA.5.6 يقابله A.6.1.4، وA.5.14 «نقل المعلومات» يقابله A.13.2.1 «سياسات وإجراءات نقل المعلومات»، وA.8.34 يقابله A.12.7.1 «ضوابط تدقيق أنظمة المعلومات». أي أن ملف الربط نفسه ناقص في هذه المواضع.

والدرس من النقطة الأخيرة أهم من الأرقام: ملفات الربط بين الأطر، حتى في أداة جيدة، يكتبها أشخاص وتحتوي أخطاء، فاستخدمها لتسريع العمل، ولا تستخدمها دليلاً دون أن تراجع ما يخص ضوابطك. وهذا ينطبق على كل جداول الربط التي سوف تقابلها، بما فيها الربط بين ECC وISO الذي تبنيه بنفسك.

البند 4: السياق والنطاق

أول قرار، وأهمه، أين تنتهي حدود النظام. والمعيار يطلب أن تفهم سياق مؤسستك والأطراف المهتمة ومتطلباتها، ثم تحدد النطاق بحدوده وواجهاته، وأن يكون النطاق وثيقة مكتوبة. وفي قصة الشركة كان الإغراء أن يكون النطاق «الشركة كلها» لأن العميل سوف يحبه، لكن الفريق عد ما يعنيه ذلك: المكتب المالي وأجهزته، وحسابات التواصل الاجتماعي، وفريق المبيعات وأدواته، وكلها تحتاج ضوابط وأدلة وتدقيقاً. فقرر نطاقاً يغطي ما يطلبه العميل فعلاً، وهو الخدمة المقدمة له ومن يشغلها، والشكل التالي يبينه:

وفي الشكل لاحظ ثلاثة أنواع من العلاقات عبر الحدود، ولكل نوع معاملة في الوثيقة:

• ما يعبر الحدود ويحمل بيانات: مزود البريد خارج النطاق لكنه يعالج بيانات المرضى، فهو مورد يجب أن يغطيه ضابط الموردين والخدمات السحابية في الملحق، وقد رأينا في مقال PDPL أنه أيضاً نقل للبيانات خارج المملكة يحتاج توثيقاً.
• ما تورث ضوابطه: السيرفرات في مركز استضافة في الرياض، والضوابط المادية مثل حراسة المبنى وكاميراته مسؤولية المزود، فتكتب في الوثيقة أنها موروثة، ودليلها شهادة المزود ونطاقها، وبند في العقد.
• ما يستثنى صراحة: المكتب المالي خارج النطاق، ويذكر بالاسم، لأن المدقق يسأل عما ليس في النطاق كما يسأل عما فيه، والسكوت عنه يفتح سؤالاً لا تريده.

وقد يتساءل البعض: ألا يقلل النطاق الضيق من قيمة الشهادة؟ والإجابة أن العميل الواعي يقرأ النطاق المكتوب في الشهادة قبل أن يقرأ اسم الشركة، وقد ذكرنا في مقال الأطر أن الشهادة لنطاق محدد وأن هذا أول ما تتحقق منه في شهادة أي مورد، فإذا كان النطاق يغطي الخدمة التي يشتريها فهو ما يحتاجه، وإذا كان أوسع بكثير مما تستطيع الشركة إثباته فهو مخاطرة على الشهادة نفسها في أول تدقيق متابعة.

البند 5: القيادة والسياسة

المعيار يطلب التزاماً واضحاً من الإدارة العليا، وسياسة لأمن المعلومات، وأدواراً ومسؤوليات محددة، وهذه ليست شكليات، فمدقق الشهادة يقابل المدير التنفيذي عادة ويسأله عن الأهداف والموارد، والمدير الذي لا يعرف ماذا وقع عليه هو أوضح دليل على أن النظام ورقي. وفي القصة استخدمت الشركة ما بنته في مقال السياسات: السياسة العامة مأخوذة من نموذج الهيئة الوطنية للأمن السيبراني بعد تكييفه، ومعها سياسات قصيرة للموضوعات الأخطر، كلها نصوص في مستودع Git بفحص آلي لتاريخ المراجعة والخانات الفارغة. والجديد لـ ISO أن السياسة يجب أن تتضمن التزاماً بالتحسين المستمر وإطاراً للأهداف، فأضاف الفريق فقرة واحدة تربط السياسة بأهداف قابلة للقياس، مثل «لا حساب مدير دون MFA» و«اختبار استعادة ناجح كل ربع سنة»، وهي الأهداف نفسها التي يقيسها جامع الأدلة.

والأدوار وثيقة بسيطة لكنها مهمة: من يملك النظام، ومن يملك كل مخاطرة، ومن يملك كل ضابط، ومن يدقق داخلياً. وفي شركة من اثني عشر شخصاً يجمع الشخص الواحد أكثر من دور، وهذا مقبول، بشرط ألا يدقق الشخص على عمله، وسوف نعود إلى ذلك في قسم التدقيق الداخلي.

البند 6: المخاطر ومعالجتها

هنا تظهر قيمة ما بني لـ ECC. فالبند 6.1.2 يطلب عملية لتقييم المخاطر بمعايير قبول ومعايير تقييم ثابتة، تعطي نتائج متسقة قابلة للمقارنة إذا تكررت، والبند 6.1.3 يطلب عملية للمعالجة، تنتج قرار معالجة لكل مخاطرة، وتقارن الضوابط المختارة بالملحق، وتنتج بيان قابلية التطبيق وخطة معالجة يوافق عليها مالكو المخاطر. وقد بنينا في مقال سجل المخاطر منهجية مكتوبة بحدود نموذج الهيئة، ومقاييس للاحتمال والأثر بلغة قابلة للتحقق، وسجلاً بمالكين وقرارات، ورأينا كيف أن المخاطرة نفسها تأخذ مستويين مختلفين في أداتين إذا لم تكتب المنهجية، وهذا تحديداً ما يقصده المعيار بنتائج متسقة.

والإضافة الوحيدة التي احتاجتها الشركة أن تربط كل مخاطرة بالضوابط التي تعالجها بأرقام الملحق، بجانب أرقام ECC التي كانت موجودة. فالمخاطرة «حسابات المديرين بكلمة مرور فقط» تعالجها ضوابط المصادقة الآمنة والصلاحيات المميزة في الملحق، كما يعالجها 2-2-3-2 في ECC، والضابط المطبق «MFA لكل مدير في مزود الهوية» واحد في الحالتين. وبعد هذا الربط تصبح الخطوة التالية آلية تقريباً: كل ضابط في الملحق إما مختار لأنه يعالج مخاطرة، أو مختار لأن نظاماً أو عقداً يطلبه، أو مستبعد بسبب مكتوب.

تجربة عملية: بيان قابلية التطبيق من قائمة الضوابط

بيان قابلية التطبيق هو الوثيقة التي يفتحها مدقق الشهادة أولاً في أغلب الأحيان، لأنه يلخص النظام كله: لكل ضابط من الضوابط الـ 93 هل هو مطبق أم مستبعد، ولماذا، وما حالة تطبيقه، وأين دليله. وكثير من الجهات تكتبه في Excel باليد فتظهر فيه أخطاء من نوعين: ضابط مستبعد بلا سبب، وضابط مكتوب «مطبق» بلا دليل. فكتبنا سكربتاً يبني البيان من قائمة الضوابط الحقيقية، ويكشف هذين النوعين قبل أن يكتشفهما المدقق.

وقائمة الضوابط نأخذها من ملف مكتبة CISO Assistant للمعيار، وفيه رقم كل ضابط واسمه القصير وفئته، دون نص المعيار نفسه. ننزله من الإصدار المحدد:

curl -sL -o iso27001-2022.yaml \
  https://raw.githubusercontent.com/intuitem/ciso-assistant-community/v4.1.5/backend/library/libraries/iso27001-2022.yaml

ثم نكتب قرارات الشركة في ملف decisions.json، وهو المسودة الأولى كما كتبها الفريق في أول جلسة، بقرار لتسعة عشر ضابطاً فقط حتى الآن:

{
  "scope": "Booking platform, its servers in a Riyadh colocation facility, and the team that runs them",
  "decisions": {
    "A.5.1":  {"status": "implemented", "evidence": "policies/ (Git, policy_lint pass)", "ecc": "1-3-1"},
    "A.5.9":  {"status": "implemented", "evidence": "Snipe-IT export, monthly", "ecc": "2-1"},
    "A.5.15": {"status": "implemented", "evidence": "authentik groups export", "ecc": "2-2-3-3"},
    "A.5.17": {"status": "implemented", "evidence": "Vaultwarden policy screenshot replaced by API export", "ecc": "2-2"},
    "A.5.23": {"status": "excluded", "justification": ""},
    "A.5.24": {"status": "planned", "evidence": "", "ecc": "2-13-3-1"},
    "A.5.34": {"status": "implemented", "evidence": "records of processing (PDPL Art. 31)", "ecc": ""},
    "A.6.3":  {"status": "implemented", "evidence": "GoPhish campaign report Q3", "ecc": "1-10"},
    "A.7.1":  {"status": "inherited", "evidence": "colocation provider ISO/IEC 27001 certificate, scope checked", "ecc": "2-14"},
    "A.7.4":  {"status": "inherited", "evidence": "colocation provider CCTV clause in contract", "ecc": "2-14-3-2"},
    "A.7.7":  {"status": "implemented", "evidence": "office clean desk check, quarterly", "ecc": ""},
    "A.8.5":  {"status": "planned", "evidence": "", "ecc": "2-2-3-2"},
    "A.8.8":  {"status": "implemented", "evidence": "Trivy reports, weekly", "ecc": "2-10-3-1"},
    "A.8.9":  {"status": "implemented", "evidence": "collect.py runs (sshd -T, nginx -T)", "ecc": "2-3-2"},
    "A.8.13": {"status": "planned", "evidence": "", "ecc": "2-9-3-3"},
    "A.8.15": {"status": "implemented", "evidence": "Loki /config retention_period: 1y", "ecc": "2-12-3-5"},
    "A.8.16": {"status": "implemented", "evidence": "", "ecc": "2-12-3-4"},
    "A.8.17": {"status": "implemented", "evidence": "chronyc sources, time.saso.gov.sa", "ecc": "2-3-3-4"},
    "A.8.30": {"status": "excluded", "justification": "No development is outsourced; all code is written by employees (HR contracts)."}
  }
}

في الملف أعلاه لاحظ التالي:

• الحالات خمس: implemented للمطبق، وplanned للمختار الذي لم يكتمل بعد، وinherited للموروث من مورد، وexcluded للمستبعد، وكل ضابط لا يظهر في الملف يعد بلا قرار.
• عمود evidence يشير إلى الأدلة التي بنيناها في المقالات السابقة، مثل مخرج /config في Loki لضابط السجلات، ومخرجات الجامع لضابط إدارة الإعدادات.
• عمود ecc يربط كل قرار برقم الضابط المقابل في ECC، فالبيان نفسه يصبح جدول ربط بين الوثيقتين.

والسكربت التالي، ونحفظه باسم soa.py، يمر على الضوابط الـ 93، ويضع لكل منها قرارها، ويكتب البيان في ملف CSV، ويطبع ملخصاً بالمحاور، ويعد المشكلات:

# Builds a Statement of Applicability (SoA) from the ISO/IEC 27001:2022 Annex A outline in the CISO Assistant
# library and the organisation's decisions, then reports what an auditor would question first.
import csv, json, sys, collections, yaml

lib = yaml.safe_load(open("iso27001-2022.yaml", encoding="utf-8"))
controls = lib["objects"]["reference_controls"]                  # 93 Annex A controls: ref_id + short name
plan = json.load(open(sys.argv[1] if len(sys.argv) > 1 else "decisions.json", encoding="utf-8"))
decisions = plan["decisions"]
THEMES = {"5": "organizational", "6": "people", "7": "physical", "8": "technological"}

rows, problems = [], []
count = collections.Counter()
for c in controls:
    ref = c["ref_id"]
    theme = THEMES[ref.split(".")[1]]
    d = decisions.get(ref, {"status": "undecided"})
    status = d["status"]
    count[(theme, status)] += 1
    if status == "excluded" and not d.get("justification"):
        problems.append(f"{ref} excluded without a justification")
    if status in ("implemented", "inherited") and not d.get("evidence"):
        problems.append(f"{ref} marked {status} but no evidence")
    rows.append({"control": ref, "name": c["name"], "theme": theme, "applicable": status != "excluded",
                 "status": status, "justification": d.get("justification", ""), "evidence": d.get("evidence", ""),
                 "ecc": d.get("ecc", "")})

with open("soa.csv", "w", newline="", encoding="utf-8-sig") as f:
    w = csv.DictWriter(f, fieldnames=list(rows[0]))
    w.writeheader(); w.writerows(rows)

print(f"scope: {plan['scope']}")
print(f"{'theme':14} {'total':>5} {'impl':>5} {'inher':>5} {'plan':>5} {'excl':>5} {'undec':>5}")
for t in THEMES.values():
    tot = sum(v for (th, s), v in count.items() if th == t)
    print(f"{t:14} {tot:5} {count[(t,'implemented')]:5} {count[(t,'inherited')]:5} {count[(t,'planned')]:5} "
          f"{count[(t,'excluded')]:5} {count[(t,'undecided')]:5}")
print(f"{'all':14} {len(rows):5}")
for p in problems:
    print("PROBLEM", p)
sys.exit(1 if problems or count and any(s == "undecided" for (_, s) in count) else 0)

ونشغله في Container مع مكتبة PyYAML لقراءة ملف المكتبة:

docker run --rm -v "$PWD:/w" -w /w python:3.13.17-slim \
  sh -c "pip install -q --root-user-action=ignore pyyaml==6.0.3 && python soa.py decisions.json"

والمخرج سوف يكون كما يلي:

scope: Booking platform, its servers in a Riyadh colocation facility, and the team that runs them
theme          total  impl inher  plan  excl undec
organizational    37     5     0     1     1    30
people             8     1     0     0     0     7
physical          14     1     2     0     0    11
technological     34     5     0     2     1    26
all               93
PROBLEM A.5.23 excluded without a justification
PROBLEM A.8.16 marked implemented but no evidence

في المخرج أعلاه لاحظ التالي:

• الأعداد في عمود total هي 37 و8 و14 و34، ومجموعها 93، أي أن السكربت قرأ الملحق كاملاً بالتقسيم الذي رأيناه في جدول NIST.
• عمود undec هو الأهم: 74 ضابطاً بلا قرار، أي أن المسودة الأولى بعيدة جداً عن الاكتمال، وهذا طبيعي في الأسبوع الأول، لكن البيان الذي يسلم للمدقق يجب أن يكون هذا العمود فيه أصفاراً.
• المحور المادي فيه ضابطان موروثان من مركز الاستضافة، وواحد مطبق، وهو مكتب الفريق نفسه.

والمشكلتان في آخر المخرج هما ما كان المدقق سوف يجده في دقائق. فالضابط A.5.23 الخاص بأمن المعلومات عند استخدام الخدمات السحابية استبعده الفريق لأن «المنصة على سيرفراتنا»، ونسي أن البريد يرسل عبر خدمة سحابية، فالضابط ينطبق أصلاً، والاستبعاد بلا سبب كشف أن القرار لم يناقش. والضابط A.8.16 الخاص بأنشطة المراقبة مكتوب «مطبق» بلا دليل، والحقيقة كما رأينا في تقييم ECC أن المراقبة تعمل على بعض السيرفرات فقط. فصحح الفريق القرارين: A.5.23 مخطط ومربوط بالمكون الفرعي 4-2 في ECC، وA.8.16 مخطط حتى تكتمل المراقبة، وأعاد التشغيل بالملف المصحح:

scope: Booking platform, its servers in a Riyadh colocation facility, and the team that runs them
theme          total  impl inher  plan  excl undec
organizational    37     5     0     2     0    30
people             8     1     0     0     0     7
physical          14     1     2     0     0    11
technological     34     4     0     3     1    26
all               93

اختفت المشكلتان، وبقي الضابط المستبعد الوحيد A.8.30 الخاص بالتطوير الخارجي، وسببه مكتوب: كل الكود يكتبه موظفون. والسكربت ما زال يخرج برمز 1 لأن هناك 74 ضابطاً بلا قرار، وهذا مقصود، فإذا وضعته في خط CI على مستودع الوثائق فلن يمر حتى يكتمل البيان. والشكل التالي يبين المسودة الأولى بالمحاور:

ولاحظ أن الملف الناتج soa.csv يكتب بترميز UTF-8 مع علامة الترتيب، فيفتح في Excel مباشرة إذا أراد المدير أن يقرأه، لكن مصدره الوحيد ملف القرارات في المستودع، فكل تعديل عليه يمر بمراجعة ويبقى في تاريخ Git، وهذا يجيب عن سؤال المدقق المعتاد: «من غير قرار هذا الضابط، ومتى؟».

الموردون والخدمات السحابية داخل النظام

الشركة الصغيرة تعتمد على موردين أكثر مما تظن، وكل مورد يصل إلى بيانات أو أنظمة في النطاق جزء من النظام بحكم الملحق، الذي يخصص سلسلة ضوابط للموردين، من أمن المعلومات في العلاقة مع الموردين A.5.19، إلى تضمين متطلبات الأمن في اتفاقيات الموردين A.5.20، وسلسلة إمداد تقنية المعلومات A.5.21، ومراقبة خدمات الموردين ومراجعتها A.5.22، والخدمات السحابية A.5.23. وفي القصة عد الفريق موردي النطاق فوجد خمسة: مركز الاستضافة، ومزود البريد التفاعلي، ومزود الرسائل النصية، ومستودع الحزم الذي تبنى منه الـ Images، ومزود النطاقات وDNS.

ولكل مورد سطر في سجل بسيط: ماذا يصل إليه، وما الضوابط التي نعتمد عليه فيها، وما الدليل على أنه يطبقها، ومتى نراجعه. فمركز الاستضافة دليله شهادته ونطاقها وبنود العقد، ومزود البريد دليله تقريره الأمني إن وجد، ومنطقة المعالجة، والبنود التي يطلبها نظام حماية البيانات الشخصية في اتفاق المعالجة، وقد شرحنا في مقال PDPL العناصر التي تطلبها المادة 17 من اللائحة التنفيذية في الاتفاق مع جهة المعالجة، وهي قريبة جداً مما يحتاجه ضابط اتفاقيات الموردين. ولاحظ أن ECC تطلب الشيء نفسه بلغتها في المكون الفرعي 4-1 للأطراف الخارجية، فالسجل الواحد يخدم الثلاثة: ISO وECC وPDPL.

والخطأ الذي وقعت فيه الشركة في المسودة الأولى، استبعاد ضابط الخدمات السحابية لأن «المنصة على سيرفراتنا»، خطأ شائع جداً، والسبب أن الفريق التقني يفكر في البنية الأساسية فقط، وينسى البرمجيات كخدمة SaaS التي يستخدمها كل يوم. والقاعدة: أي خدمة تصل إليها بمتصفح أو API ولا تديرها بنفسك، وتحمل بيانات في النطاق، هي خدمة سحابية بالمعنى الذي يهم الضابط.

الأهداف 6.2: ماذا تقيس بالضبط؟

البند 6.2 في مخطط المعيار عنوانه أهداف أمن المعلومات والتخطيط لتحقيقها، وأكثر الأهداف التي تراها في الوثائق عامة لا تقاس، مثل «رفع مستوى الوعي الأمني»، والمدقق يسأل فوراً: كيف تعرف أنك حققته؟ ومن المسؤول عنه؟ وبأي موارد؟ ومتى؟ فكتبت الشركة خمسة أهداف لكل منها رقم ومصدر ومالك وموعد:

• لا حساب مدير دون MFA: المصدر تقرير مزود الهوية، والهدف صفر، والموعد نهاية الربع.
• اختبار استعادة ناجح كل ربع سنة: المصدر محضر الاختبار الذي يكتبه سكربت الاستعادة، والهدف أربعة محاضر في السنة.
• الثغرات المرتفعة على الأصول المكشوفة تعالج خلال 14 يوماً: المصدر تقارير الفحص والتذاكر، والهدف 95% في المدة.
• نسبة فحوص الجامع الناجحة فوق 98%: المصدر مخرج الجامع اليومي، وأي تغير غير معتمد يحقق فيه.
• معدل النقر في محاكاة التصيد ينخفض من ربع لربع: المصدر تقارير GoPhish.

ولاحظ أن كل هدف منها مرتبط بضابط في البيان وبمخاطرة في السجل، فإذا لم يتحقق الهدف ظهر ذلك في مراجعة الإدارة، وتحول إلى قرار: موارد إضافية، أو تعديل الهدف، أو قبول المخاطرة مؤقتاً بموافقة المالك. وهذا الربط هو ما يجعل النظام دورة وليس مجموعة وثائق، وهو أيضاً ما يجعل مراجعة الإدارة اجتماعاً له جدول أعمال حقيقي بدل أن يكون توقيعاً على عرض.

البند 7: الموارد والكفاءة والتوعية والوثائق

البند السابع يغطي ما يحتاجه النظام ليعمل: موارد كافية، وكفاءة الأشخاص في أدوارهم، والتوعية، والتواصل، والمعلومات الموثقة Documented Information، أي الوثائق والسجلات وكيف تنشأ وتحدث وتحفظ. وهذه هي الأدوات التي استخدمتها الشركة لكل جزء:

• الكفاءة: سجل بسيط لكل دور بالمهارات المطلوبة والدورات أو الشهادات التي يحملها شاغله، ويكفي جدول في الموقع الداخلي، والمهم أن يحدث وأن يثبت أن الثغرة في المهارات لها خطة.
• التوعية: برنامج سنوي بمحتوى وجدول وقياس، كما شرحنا في برنامج التوعية بالأمن السيبراني، وحملات محاكاة تصيد مصرح بها بـ GoPhish تعطي رقماً يقاس من ربع لربع.
• المعلومات الموثقة: السياسات والإجراءات والنطاق وبيان قابلية التطبيق نصوص في Git، تنشر للقراءة في BookStack، والسجلات، مثل الأدلة ومحاضر المراجعة، في مخزن بتاريخ واحتفاظ محدد. والمعيار يهتم بضبط الوثائق، أي النسخة المعتمدة الحالية واضحة، والقديمة لا تستخدم بالخطأ، وهذا ما يعطيه Git بطبيعته.

البند 8 والملحق: الضوابط بأدواتها

البند الثامن يطلب أن تنفذ ما خططت له، وأن تعيد تقييم المخاطر عند التغييرات الجوهرية، وأن تنفذ خطة المعالجة. وهنا يأتي الجزء التقني الذي يحبه المهندسون، والخبر الجيد أن الشركة لم تحتج أداة واحدة جديدة، لأن الضوابط التقنية في الملحق تقابل الحد الأدنى في المكون الثاني من ECC، وقد ربطنا كل ضابط فرعي في ECC بأداته مفتوحة المصدر والمقال الذي شرحها في مقال ضوابط ECC بأدوات مفتوحة. والجدول التالي يبين أمثلة من كل محور، بأرقام الملحق وأسمائها القصيرة كما في المكتبة:

ولاحظ أن الضوابط التنظيمية، وهي الأكبر عدداً بـ 37 ضابطاً، أغلبها إجراءات وقرارات وليست أدوات، مثل فصل المهام وإدارة الموردين والمتطلبات القانونية، وهذا ما يفسر لماذا يبدو الملحق أصعب على الفرق التقنية مما هو فعلاً: الجزء التقني الذي يخافونه هو الأسهل لأنهم يعرفونه، والجزء الذي يبدو سهلاً هو الذي يحتاج أشخاصاً يكتبون ويقررون ويراجعون.

ضوابط الأفراد: من التوظيف إلى المغادرة

محور الأفراد في الملحق ثمانية ضوابط فقط، لكنه المحور الذي تفاجأ به الشركة في المسودة الأولى، لأن سبعة منها كانت بلا قرار. وأسماؤها في المكتبة تحكي دورة حياة الموظف كاملة: الفحص قبل التوظيف Screening، وشروط العمل، والتوعية والتدريب، والإجراء التأديبي، والمسؤوليات بعد انتهاء العمل أو تغيره، واتفاقيات السرية، والعمل عن بعد، والإبلاغ عن الأحداث الأمنية. وأغلبها ليس عند الفريق التقني أصلاً، وإنما عند الموارد البشرية والإدارة القانونية، ولذلك فأول قرار في هذا المحور هو من يملكه.

والجزء التقني فيه نقطة واحدة لكنها الأخطر: مسؤوليات ما بعد انتهاء العمل، ومعها سحب الصلاحيات في اليوم نفسه. وقد شرحنا في دورة حياة حسابات الموظف JML كيف تربط نظام الموارد البشرية بمزود الهوية حتى يغلق الحساب في كل التطبيقات معاً، وفي SCIM كيف يتم ذلك آلياً. وهذا هو نفسه الضابط 1-9-5 في ECC الذي يطلب مراجعة الصلاحيات وسحبها فوراً عند انتهاء العلاقة الوظيفية، والدليل عليه واحد في الحالتين: تقرير يقارن قائمة الموظفين المغادرين بتاريخ إغلاق حساباتهم. أما الإبلاغ عن الأحداث الأمنية فأبسط دليل عليه قناة واضحة يعرفها كل موظف، وعدد البلاغات التي وصلت منها، فالقناة التي لم يصلها بلاغ واحد في سنة كاملة تقول للمدقق إن أحداً لا يعرفها، وليس إن الشركة بلا أحداث.

التغيير والتطوير: حيث يلتقي النظام بالمهندسين

الشركة تطور منصتها بنفسها، ولذلك كانت الضوابط التي تخص التطوير والتغيير في الملحق من الأهم لها: دورة حياة التطوير الآمن، ومتطلبات أمن التطبيقات، والبرمجة الآمنة، والاختبار الأمني، وفصل بيئات التطوير والاختبار والإنتاج، وإدارة التغيير، وبيانات الاختبار. والخبر الجيد أن الفريق كان يطبق أغلبها فعلاً دون أن يسميها، فخط CI/CD يشغل فحص الكود الثابت SAST وفحص المكتبات SCA وفحص الأسرار، كما في خط CI/CD آمن، وكل تغيير يمر بـ Pull Request ومراجعة، والإنتاج منفصل عن بيئة الاختبار كما في البيئات وGitOps.

والذي كان ينقص هو الدليل، لا التطبيق. فالمدقق يسأل عن عينة من التغييرات في الإنتاج خلال الفترة: أين طلب التغيير، ومن راجعه، وهل نجحت فحوص الأمان، ومن وافق على النشر. والإجابة موجودة كلها في Git وأداة CI، لكنها تحتاج أن تكون قابلة للاستخراج: كل نشر للإنتاج مربوط بـ Pull Request مدموج، وكل Pull Request فيه مراجع غير الكاتب، وسجل الخط محفوظ المدة المطلوبة. وأضافت الشركة فحصاً واحداً لجامع الأدلة يستخرج آخر النشرات ورقم الطلب المرتبط بكل منها، فأصبح الدليل على ضابط إدارة التغيير يتجدد كل يوم بدل أن يجمع في أسبوع التدقيق. ولاحظ أن ECC تطلب الشيء نفسه بلغتها في المكون الفرعي 1-6 لمشاريع تقنية المعلومات وتطوير البرمجيات، ومنه 1-6-3-1 لمعايير البرمجة الآمنة، فالدليل هنا أيضاً يخدم الوثيقتين.

ما المشترك مع ECC، وما الذي ينفرد به كل منهما؟

بعد أن ربط الفريق البيان بأرقام ECC ظهر الشكل التالي بوضوح:

والعمود الأيمن مهم لمن يظن أن شهادة ISO تكفي جهة حكومية: ECC تطلب أشياء بالاسم لا يذكرها المعيار، مثل أن تشغل وظائف الأمن السيبراني كفاءات سعودية بدوام كامل في 1-2-2، وأن تكون مراكز الخدمات المدارة للمراقبة داخل المملكة في 4-1-3-2، وأن تبلغ الهيئة بالحوادث في 2-13-3-3. والعمود الأيسر مهم لمن يظن العكس: ECC لا تطلب بيان قابلية تطبيق بالمعنى الذي في المعيار، ولا برنامج تدقيق داخلي بالتفصيل نفسه، ولا مراجعة إدارة بمدخلات ومخرجات محددة، وإن كانت تطلب المراجعة الدورية والتدقيق المستقل في المكون الفرعي 1-8. لذلك فالجهة التي تبدأ بـ ECC وتريد ISO تحتاج أساساً العمود الأيسر، وهو عمل وثائق وعمليات، وليس أدوات.

البند 9: القياس، والتدقيق الداخلي، ومراجعة الإدارة

هذا هو البند الذي تتخطاه أغلب الجهات، ويقابل الخطوة الخامسة في الشكل الذي سوف تراه في آخر المقال، وهو أول ما يطلبه مدقق الشهادة، لأنه الدليل على أن النظام يعمل وليس مجرد وثائق. وفيه ثلاثة أجزاء:

• القياس والمراقبة 9.1: ماذا تقيس، وكيف، ومتى، ومن يحلل النتائج. والشركة عندها هنا ميزة لأن جامع الأدلة الذي بنيناه في مقال جمع الأدلة يعطي يومياً نسبة الفحوص الناجحة والتغيرات غير المعتمدة، وهذه مقاييس جاهزة للأهداف التي في السياسة.
• التدقيق الداخلي 9.2: برنامج تدقيق على فترات مخططة، بمعايير ونطاق لكل تدقيق، ومدققين موضوعيين لا يدققون عملهم. وفي شركة صغيرة هذا هو التحدي الحقيقي، فإذا كان مسؤول الأمن هو من بنى النظام فلا يدققه وحده، والحلول المعتادة أن يتبادل شخصان التدقيق على أجزاء لم يبنياها، أو أن يستعان بمدقق داخلي خارجي لأيام محددة. والأداة تساعد هنا أيضاً، فتدقيق في CISO Assistant على إطار ISO 27001 نفسه، كما فعلنا مع ECC في مقال CISO Assistant، يعطي قائمة المتطلبات ونتائجها وأدلتها في مكان واحد.
• مراجعة الإدارة 9.3: اجتماع موثق للإدارة العليا يراجع النظام بمدخلات محددة، مثل حالة الإجراءات من المراجعات السابقة، والتغيرات في القضايا الداخلية والخارجية، ونتائج القياس والتدقيق، وتغذية الأطراف المهتمة، ونتائج تقييم المخاطر وفرص التحسين، ثم يخرج بقرارات. وأبسط شكل لها قالب محضر بهذه المدخلات كعناوين، يعبأ من تقارير الأدوات، ويوقعه المدير، ويحفظ في المستودع.

وسوف نتكلم بالتفصيل عما يطلبه المدقق في كل هذه الأجزاء في المقال التالي عن الاستعداد للتدقيق، لكن القاعدة التي تكفي الآن: لا تطلب تدقيق الشهادة قبل أن تكمل دورة واحدة على الأقل من التدقيق الداخلي ومراجعة الإدارة، لأن مدقق الشهادة يريد أن يرى أن النظام دار دورة كاملة، لا أنه كتب.

البند 10: عدم المطابقة والتحسين

كل ملاحظة من التدقيق الداخلي، وكل fail متكرر في الجامع، وكل حادث، مدخل للبند العاشر. والمعيار يطلب عند عدم المطابقة أن تتصرف لتصحيحها، وأن تقيم الحاجة إلى معالجة السبب حتى لا تتكرر، وأن تتأكد من فعالية الإجراء التصحيحي، وأن توثق ذلك. والأداة البسيطة لهذا هي نظام التذاكر نفسه الذي يستخدمه الفريق، بشرط أن يكون لكل تذكرة من هذا النوع ثلاثة حقول: التصحيح الفوري، والسبب الجذري، والإجراء الذي يمنع التكرار مع تاريخ التحقق من فعاليته. وفي القصة كان أول مثال حقيقي هو فتح دخول root على أحد السيرفرات، الذي كشفه الجامع: التصحيح إعادة الإعداد، والسبب الجذري أن المطور لم يكن لديه طريق معتمد للوصول الطارئ، والإجراء الذي يمنع التكرار حساب طوارئ موثق بإجراء استثناء، كما في سياسة الوصول الإداري.

كم يكلف كل هذا؟

التكلفة المنشورة الوحيدة هي سعر المعيار، 155 فرنكاً سويسرياً، وإذا أردت إرشادات الضوابط بالتفصيل فالمعيار المصاحب ISO/IEC 27002 يشرح كل ضابط في الملحق. أما الأدوات في هذه القصة فكلها مفتوحة المصدر ومستضافة ذاتياً، وتكلفتها سيرفر صغير ووقت تشغيله. والتكلفة الحقيقية في بندين لا توجد لهما أسعار رسمية منشورة: وقت الفريق في كتابة الوثائق وجمع القرارات وإجراء التدقيق الداخلي، وأتعاب الجهة المانحة التي تعتمد على حجم النطاق وعدد أيام التدقيق. ولذلك فالنطاق الضيق ليس قراراً أمنياً فقط، وإنما قرار مالي أيضاً، فكل نظام وفريق تضيفه إلى النطاق يضيف وقتاً في التدقيق الداخلي والخارجي كل سنة. وإذا قارنت بأدوات الامتثال التجارية فتذكر أنها تختصر جمع الأدلة وتنظيمها، ولا تختصر القرارات، وقد رأينا في مقال CISO Assistant أن النسخة التجارية من أداة مفتوحة المصدر تبدأ من 39 يورو للمساهم شهرياً، فقارن هذا بوقت فريقك قبل أن تقرر.

تدقيق الشهادة: من يمنحها، وكيف تتحقق منها؟

الشهادة لا تمنحها ISO، وإنما جهة مانحة Certification Body تدقق نظامك، والجهة المانحة الموثوقة معتمدة من جهة اعتماد Accreditation Body. وفي المملكة يعتمد المركز السعودي للاعتماد SAAC الجهات المانحة لشهادات أنظمة إدارة أمن المعلومات وفق المعيار ISO/IEC 17021-1، وتستطيع أن تتحقق من أي شهادة معتمدة في IAF CertSearch، وهي قاعدة البيانات العالمية التي تجمع بيانات جهات الاعتماد والجهات المانحة. والقاعدة عند اختيار الجهة المانحة أن تتحقق من اعتمادها لهذا المعيار تحديداً، وأن تسأل عن خبرتها في قطاعك، وأن تطلب عرضاً مكتوباً بعدد أيام التدقيق ومراحله، فالأسعار تتفاوض عليها ولا توجد قائمة رسمية منشورة.

وعند المقارنة بين الجهات تذكر ما ذكرناه في مقال الأطر عن تحذير المعهد الأمريكي للمحاسبين القانونيين من تقارير SOC 2 السريعة والرخيصة، فالمنطق نفسه ينطبق على الشهادات: الشهادة التي تصدر بعد تدقيق شكلي لا تصمد أمام عميل يقرأ، والأسوأ أنها لا تكشف لك ما تحتاج إصلاحه.

الترتيب الذي سارت عليه الشركة

والشكل التالي يلخص الترتيب ومخرج كل خطوة، وهو ترتيب البنود نفسه تقريباً، لأن كل خطوة تحتاج مخرج التي قبلها:

ولاحظ أن الأدوات مفتوحة المصدر ظهرت في كل خطوة، لكن ولا خطوة منها كانت «تثبيت أداة». فالأداة تحفظ القرار وتجمع الدليل وتذكر بالموعد، والنظام هو القرارات نفسها ومن يتخذها. وهذا هو سبب أن الشركات التي تشتري منتجاً تجارياً للامتثال قبل أن تكتب نطاقها ومنهجيتها تكتشف بعد أشهر أن المنتج ممتلئ بالمهام ولا أحد يعرف لماذا.

ماذا يحدث إذا...؟

• ماذا يحدث إذا أضافت الشركة خدمة جديدة بعد الشهادة؟ الخدمة الجديدة خارج النطاق المكتوب في الشهادة حتى يوسع النطاق في تدقيق لاحق، فلا تقم بتسويقها للعملاء على أنها «معتمدة»، واجعل توسيع النطاق قراراً في مراجعة الإدارة قبل الإطلاق، وهذا أيضاً من حالات تقييم المخاطر التي يذكرها الضابط 1-5-3 في ECC.
• ماذا يحدث إذا فقد مورد شهادته؟ الضوابط المادية التي ورثتها الشركة من مركز الاستضافة دليلها شهادته، فإذا انتهت أو لم تجدد فقد سقط الدليل، ولذلك فمراجعة الموردين في السجل تتضمن تاريخ انتهاء شهاداتهم والتحقق منها في IAF CertSearch، وليس فقط نسخة PDF قديمة في المجلد.
• ماذا يحدث إذا تغير المعيار نفسه؟ الإصدار القادم سوف يأتي يوماً كما جاء إصدار 2022 بعد 2013، وتجربة التحويل التي أجريناها تبين حجم العمل: ترقيم جديد ودمج وضوابط جديدة، والجهة التي تربط كل قرار بضابط مطبق ودليل في أداة، وليس برقم في جدول، تنقل الربط ولا تعيد البناء.
• ماذا يحدث إذا رفض المدقق استبعاداً؟ يسجله ملاحظة، وتعالجه بالإجراء التصحيحي في البند العاشر: إما أن تطبق الضابط، وإما أن تكتب سبباً مقنعاً مبنياً على تقييم المخاطر، وهذا سبب إضافي لأن يكون لكل استبعاد سبب مكتوب منذ المسودة الأولى.

أخطاء شائعة

• البدء بالملحق: تطبيق الضوابط الـ 93 كقائمة مهام قبل تقييم المخاطر، فتطبق ما لا تحتاجه وتنسى ما يهمك.
• نطاق واسع لا يثبت: «الشركة كلها» في الوثيقة، وأدلة لجزء منها فقط.
• استبعاد بلا سبب: كما حدث مع A.5.23 في التجربة، والمدقق يبدأ عادة بالمستبعد.
• «مطبق» بلا دليل: كما حدث مع A.8.16، والصحيح «مخطط» حتى يصل الدليل.
• تدقيق داخلي يجريه من بنى النظام: يفقد الموضوعية التي يطلبها المعيار.
• مراجعة إدارة بلا محضر: اجتماع حدث فعلاً، لكن لا شيء يثبته.
• ظن أن الشهادة تكفي ECC: العمود الأيمن في شكل التداخل لا يغطيه المعيار.

قائمة تحقق قبل أن تطلب تدقيق الشهادة

الخلاصة

• ISO/IEC 27001 نظام إدارة في البنود من 4 إلى 10، وملحق بـ 93 ضابطاً تختار منها بعد تقييم المخاطر، وليس قائمة مهام.
• النطاق الضيق الواضح الذي يغطي ما يشتريه العميل أفضل من نطاق واسع لا تستطيع إثباته.
• سجل المخاطر وجامع الأدلة والسياسات التي بنيت لـ ECC تعاد كما هي، ويضاف إليها ربط أرقام الملحق.
• بيان قابلية التطبيق يبنى من القائمة الحقيقية ويفحص آلياً، وكشف السكربت في المسودة الأولى استبعاداً بلا سبب وضابطاً «مطبقاً» بلا دليل.
• ما ينفرد به المعيار عمل وثائق وعمليات: النطاق، والبيان، والتدقيق الداخلي، ومراجعة الإدارة، والإجراء التصحيحي.
• الشهادة تمنحها جهة معتمدة، وتتحقق منها في IAF CertSearch، والمعيار نفسه بـ 155 فرنكاً، والباقي وقت الفريق وأتعاب التدقيق.

وفي المقال الأخير من هذه المرحلة نجلس مع المدقق: ماذا يطلب، وكيف تجهز له:

سجل التحديثات

أكتوبر 2026: كتابة المقال، وتجربة بناء بيان قابلية التطبيق من مكتبة ISO/IEC 27001:2022 في CISO Assistant v4.1.5 على Python 3.13.17 مع PyYAML 6.0.3.