لم تعد معلومات المؤسسة موجودة فقط داخل غرفة الخوادم.

قد توجد في:

البريد الإلكتروني.

أنظمة ERP وCRM.

الأجهزة المحمولة.

الخدمات السحابية.

ملفات الموارد البشرية.

قواعد بيانات العملاء.

العقود.

المعلومات المالية.

الأكواد البرمجية.

نسخ الاحتياط.

وأجهزة الموظفين والموردين.

ولهذا فإن أمن المعلومات لا يمكن اختزاله في:

Firewall + Antivirus + قسم IT.

المشكلة أوسع.

من يستطيع الوصول إلى المعلومات؟

كيف يتم تحديد الصلاحيات؟

ماذا يحدث عند مغادرة موظف؟

كيف تُدار البيانات الموجودة لدى مزود خدمة سحابي؟

هل يمكن استعادة المعلومات بعد حادث؟

من يبلغ عن الحادث؟

ما المعلومات الأكثر حساسية؟

وما المخاطر التي تقبلها الإدارة وما الذي يجب معالجته؟

هنا يأتي دور ISO/IEC 27001.

فهو معيار دولي يحدد متطلبات إنشاء وتطبيق والمحافظة على والتحسين المستمر لـنظام إدارة أمن المعلومات Information Security Management System – ISMS، ويعتمد على منهج إدارة مخاطر يتناسب مع حجم المؤسسة وسياقها.

ما الإصدار الحالي من ISO/IEC 27001؟

حتى 17 أغسطس 2026، الإصدار المنشور الحالي هو:

ISO/IEC 27001:2022

وقد نشر في أكتوبر 2022، وله تعديل ISO/IEC 27001:2022/Amd 1:2024 المتعلق بتغييرات العمل المناخي.

لذلك فإن أي مشروع جديد يجب ألا يُبنى على:

ISO/IEC 27001:2013

باعتبارها النسخة الحالية.

وعند ذكر الشهادة بصورة رسمية، تستخدم ISO نفسها الصياغة الكاملة مثل:

Certified to ISO/IEC 27001:2022.

ما الذي يحميه ISO/IEC 27001؟

الهدف ليس حماية الملفات الرقمية فقط.

ينظر نظام أمن المعلومات إلى ثلاث خصائص أساسية:

السرية Confidentiality

أن تصل المعلومات فقط إلى الأشخاص المصرح لهم.

سلامة المعلومات Integrity

أن تبقى المعلومات صحيحة ومحفوظة من التغيير أو الإتلاف غير المصرح به.

الإتاحة Availability

أن تكون المعلومات والأنظمة متاحة عندما تحتاجها المؤسسة والأطراف المخولة.

وتعرض ISO هذه العناصر الثلاثة باعتبارها المبادئ الأساسية المعروفة باسم CIA Triad.

ولهذا قد يكون خطر أمن المعلومات:

تسريب قاعدة بيانات.

أو تعديل سجل مالي.

أو حذف ملف.

أو توقف نظام.

أو فقد جهاز.

أو صلاحية وصول غير مناسبة.

أو خطأ بشري.

أو مورد خارجي لا يدير المعلومات بطريقة آمنة.

ISO/IEC 27001 ليس مشروع تقنية معلومات فقط

هذه من أهم النقاط.

إذا أُسند المشروع بالكامل إلى IT، فقد يتحول إلى مشروع تقني ويضيع منه الجانب المؤسسي.

ISO توضح أن النهج شامل ويجمع الأشخاص والسياسات والتقنية، وأن أمن المعلومات يجب أن يندمج في العمليات وأنظمة المعلومات والضوابط الإدارية للمؤسسة.

لذلك يحتاج المشروع عادة إلى مشاركة:

الإدارة العليا.

تقنية المعلومات.

الأمن السيبراني عند وجوده.

الموارد البشرية.

الشؤون القانونية والامتثال.

المشتريات.

العمليات.

إدارة المخاطر.

ومالكي العمليات والمعلومات.

حسب طبيعة المؤسسة.

الخطوة الأولى: حدد لماذا تريد تطبيق ISO/IEC 27001

لا تبدأ بالشهادة.

حدد الدافع.

قد يكون:

تقليل مخاطر أمن المعلومات.

متطلب عميل.

تأهيل كمورد.

متطلب تعاقدي.

تعزيز الحوكمة.

حماية معلومات حساسة.

دعم الامتثال.

أو تطوير مستوى النضج المؤسسي.

وضوح الدافع يساعد على تحديد نطاق ISMS.

فالنظام الذي يغطي شركة تقنية كاملة يختلف عن نظام يغطي خدمة سحابية محددة أو مركز بيانات أو مجموعة عمليات معينة.

الخطوة الثانية: نفذ Gap Analysis

قبل كتابة السياسات، اعرف ما لديك.

قارن الوضع الحالي بمتطلبات ISO/IEC 27001.

راجع:

الحوكمة.

إدارة المخاطر.

إدارة الصلاحيات.

الأصول والمعلومات.

الموارد البشرية.

الأمن الفيزيائي.

إدارة الموردين.

الحوادث.

الاستمرارية.

التقنية.

المراقبة.

التدقيق.

والامتثال.

لكن لا تجعل Gap Analysis مجرد:

Document Checklist.

اسأل أيضًا:

هل الإجراء مطبق؟

هل الناس يعرفونه؟

هل توجد أدلة؟

وهل الضابط يعمل؟

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

الخطوة الثالثة: حدد نطاق ISMS بدقة

من أخطر الأخطاء كتابة:

«جميع أعمال الشركة».

دون تحليل.

يجب فهم:

المنتجات والخدمات.

العمليات.

المواقع.

الأنظمة.

الواجهات.

الأطراف الخارجية.

والمعلومات التي يجب حمايتها.

ISO/IEC 27001 يسمح بتصميم ISMS يتناسب مع حجم المؤسسة واحتياجاتها وسياقها، لكن النطاق يجب أن يكون واضحًا ومفهومًا.

لماذا النطاق مهم؟

لأنه سيحدد:

ما الذي يدخل تقييم المخاطر؟

ما الأنظمة؟

ما الأشخاص؟

ما المواقع؟

ما الموردون؟

وما الذي ستغطيه الشهادة إذا قررت المؤسسة الحصول عليها؟

لذلك لا تستخدم نطاقًا ضيقًا فقط لجعل الشهادة أسهل إذا كان لا يعكس الخدمة التي تريد المؤسسة أو العميل الاعتماد عليها.

الخطوة الرابعة: افهم سياق المؤسسة وأصحاب المصلحة

أمن المعلومات مرتبط بالأعمال.

اسأل:

ما الخدمات الحرجة؟

ما المعلومات التي يعتمد عليها العملاء؟

ما الالتزامات التعاقدية؟

ما المتطلبات القانونية؟

ما الجهات التنظيمية؟

ما اعتماد المؤسسة على السحابة؟

ما الموردون الحرجون؟

وما أثر توقف نظام معين؟

ثم حدد احتياجات الأطراف ذات العلاقة.

قد يكون العميل مهتمًا بسرية بياناته.

الإدارة مهتمة باستمرار الأعمال.

الجهة التنظيمية لديها متطلبات إلزامية.

ومورد سحابي قد يفرض نموذج تشغيل مختلفًا.

هذا التحليل يمنع بناء ISMS منفصل عن واقع المؤسسة.

الخطوة الخامسة: أنشئ حوكمة واضحة لأمن المعلومات

حدد:

من يملك ISMS؟

من يعتمد سياسة أمن المعلومات؟

من يملك المخاطر؟

من يعتمد قبول الخطر؟

من يدير الحوادث؟

من يعتمد الصلاحيات؟

ومن يتابع مؤشرات النظام؟

المشكلة الشائعة هي أن يسمى شخص:

Information Security Officer

ثم تُحال إليه جميع المخاطر.

لكن الخطر المرتبط بنظام الموارد البشرية مثلًا يجب ألا يصبح خطر مسؤول الأمن وحده.

مالك العملية أو الأصل يجب أن يشارك في القرار.

الخطوة السادسة: احصر المعلومات والأصول ذات العلاقة

لا يمكنك إدارة مخاطر شيء لا تعرف بوجوده.

لكن لا تجعل Asset Register مشروعًا بيروقراطيًا ضخمًا.

حدد ما تحتاجه المؤسسة لفهم:

المعلومات.

الأنظمة.

الأجهزة.

التطبيقات.

الخدمات السحابية.

المرافق.

الموردين.

والأصول الداعمة.

ثم حدد المالك أو الجهة المسؤولة عن الأصل عند الحاجة.

الأهم:

ما المعلومات التي تعتمد عليها المؤسسة، وأين توجد، ومن يستطيع الوصول إليها؟

الخطوة السابعة: صنّف المعلومات

ليس كل ملف يحتاج مستوى الحماية نفسه.

يمكن للمؤسسة تصميم تصنيف مناسب مثل:

عام.

داخلي.

سري.

شديد الحساسية.

هذا مثال فقط وليس تصنيفًا مفروضًا بواسطة ISO.

المطلوب أن يكون التصنيف:

واضحًا.

قابلًا للتطبيق.

ومرتبطًا بضوابط حقيقية.

إذا وصفت ملفًا بأنه «سري» ثم أُرسل بنفس الطريقة التي يُرسل بها المنشور التسويقي، فإن التصنيف لم يحقق شيئًا.

الخطوة الثامنة: نفذ تقييم مخاطر أمن المعلومات

هذه هي نقطة الارتكاز في ISO/IEC 27001.

ISO توضح أن المعيار يطبق عملية إدارة مخاطر تتكيف مع حجم المؤسسة واحتياجاتها. كما توفر ISO/IEC 27005:2022 إرشادات متخصصة لإدارة مخاطر أمن المعلومات دعمًا لتطبيق ISMS وفق ISO/IEC 27001.

يمكن التفكير في السيناريو بهذه الصورة:

أصل أو عملية → تهديد/حدث → ضعف أو ظروف مساعدة → أثر → احتمال → مستوى خطر → معالجة.

مثال:

الأصل: البريد الإلكتروني.

السيناريو: اختراق حساب موظف.

الأثر المحتمل: الوصول إلى معلومات ومراسلات حساسة أو استخدام الحساب في الاحتيال.

ثم تراجع:

ما الضوابط الحالية؟

هل المصادقة متعددة العوامل مستخدمة؟

هل التدريب مناسب؟

هل توجد مراقبة؟

ما مستوى الخطر المتبقي؟

الخطوة التاسعة: لا تحول Risk Assessment إلى قائمة هجمات فقط

مخاطر المعلومات ليست كلها Hacker.

يمكن أن يكون الخطر:

موظفًا أرسل ملفًا للشخص الخطأ.

جهازًا فُقد.

موردًا أنهى الخدمة.

نسخة احتياط لم تعمل.

صلاحيات بقيت بعد مغادرة موظف.

مركز بيانات تعرض لانقطاع.

خطأ في إعداد Cloud Storage.

أو عدم القدرة على الوصول إلى معلومات حرجة.

وهذا يعكس فلسفة ISO/IEC 27001 في حماية السرية والسلامة والإتاحة، وليس التعامل مع الأمن بوصفه منع الاختراق فقط.

الخطوة العاشرة: قرر كيف ستعالج المخاطر

بعد التقييم، لا يكفي تسجيل:

Risk = High.

يجب اتخاذ قرار.

قد تتضمن خيارات المعالجة:

تقليل الخطر بضابط.

تجنب النشاط الذي يخلق الخطر.

تغيير طريقة العمل.

نقل أو مشاركة جزء من الخطر تعاقديًا أو تأمينيًا عندما يكون ذلك مناسبًا.

أو قبول الخطر ضمن صلاحية واضحة.

القرار يجب أن يكون مبررًا ومملوكًا من الشخص المناسب.

ما هو Annex A؟

يتضمن ISO/IEC 27001 مجموعة مرجعية من ضوابط أمن المعلومات، بينما تقدم ISO/IEC 27002:2022 إرشادات أكثر تفصيلًا حول ضوابط أمن المعلومات المستخدمة لدعم ISMS. ISO توضح أن ISO/IEC 27001 يحدد متطلبات النظام، بينما ISO/IEC 27002 يقدم الممارسات والإرشادات التفصيلية للضوابط.

النسخة الحالية من مجموعة الضوابط تتضمن 93 ضابطًا موزعة على أربع فئات رئيسية:

Organizational.

People.

Physical.

Technological.

لكن الخطأ هو التعامل معها بهذه الطريقة:

لدينا 93 Control، فلنطبق 93 Control بالترتيب.

ISO/IEC 27001 نظام قائم على المخاطر.

الضوابط يجب أن ترتبط بمخاطر المؤسسة واحتياجاتها القانونية والتعاقدية والتشغيلية، وليس بمجرد إكمال قائمة.

ما هي Statement of Applicability – SoA؟

الـStatement of Applicability من أهم وثائق النظام.

وظيفتها، بصورة عملية، توثيق قرارات المؤسسة المتعلقة بالضوابط الأمنية اللازمة، وبيان حالة تطبيقها ومبررات قرارات التطبيق أو عدم الحاجة إلى بعض الضوابط المرجعية.

لذلك لا ينبغي أن تكون SoA:

نسخة من Annex A مع كلمة Yes أمام كل بند.

بل يجب أن يمكن تتبع العلاقة بين:

Risk Assessment → Risk Treatment → Controls → SoA.

إذا لم تستطع المؤسسة تفسير لماذا اختارت الضابط، فالنظام يتحول إلى تطبيق ميكانيكي بدل إدارة مخاطر.

الخطوة الحادية عشرة: لا تبدأ بكتابة 40 سياسة

الوثائق يجب أن تخدم النظام.

يمكن أن تحتاج المؤسسة، بحسب واقعها، إلى سياسات أو إجراءات تتعلق مثلًا بـ:

التحكم في الوصول.

إدارة الحسابات والصلاحيات.

التعامل مع الحوادث.

النسخ الاحتياطي.

إدارة الموردين.

استخدام الأجهزة.

العمل عن بعد.

التشفير.

التغيير.

التطوير الآمن.

التخلص من المعلومات والأجهزة.

لكن عدد السياسات ليس مؤشرًا على النضج.

شركة صغيرة قد تحتاج هيكلًا وثائقيًا أبسط من مؤسسة مالية أو تقنية كبيرة.

والقاعدة المتسقة مع منهجية IAC هي:

وثائق قابلة للتطبيق، لا بيروقراطية أُنشئت للشهادة فقط.

الخطوة الثانية عشرة: اضبط إدارة الوصول والصلاحيات

هذا أحد أكثر مجالات أمن المعلومات ارتباطًا بالإدارة اليومية.

اسأل:

من يستطيع طلب صلاحية؟

من يعتمدها؟

كيف نتحقق من الحاجة؟

ما صلاحيات المستخدم المميز Privileged Access؟

متى تتم مراجعة الصلاحيات؟

وماذا يحدث عند:

تغيير الوظيفة؟

الانتقال لإدارة أخرى؟

الإجازة الطويلة؟

أو انتهاء علاقة الموظف بالمؤسسة؟

لا يكفي أن يتم إنشاء المستخدم.

يجب إدارة دورة حياة الهوية والصلاحية.

الخطوة الثالثة عشرة: اربط الموارد البشرية بأمن المعلومات

الموظف جزء أساسي من النظام.

قبل التوظيف، أثناء العمل، وعند انتهاء العلاقة.

قد تشمل الضوابط وفق السياق:

التزامات السرية.

التوعية.

المسؤوليات.

إدارة الصلاحيات.

الإبلاغ عن الحوادث.

وإلغاء الوصول عند المغادرة.

ISO/IEC 27002 تتناول صراحة الأمن المرتبط بالموارد البشرية إلى جانب التحكم بالوصول والتشفير والاستجابة للحوادث.

الخطوة الرابعة عشرة: أدر الموردين والخدمات السحابية

قد تكون معلومات المؤسسة خارج بنيتها التقنية المباشرة.

عند استخدام:

Cloud Provider.

SaaS.

مزود رواتب.

شركة تطوير برمجيات.

مزود دعم.

مركز بيانات.

أو طرف يعالج بيانات نيابة عن المؤسسة.

اسأل:

ما المعلومات التي يصل إليها؟

ما المخاطر؟

ما الالتزامات التعاقدية؟

كيف يتم الإبلاغ عن الحوادث؟

ما متطلبات إنهاء العقد؟

كيف تسترد المؤسسة بياناتها؟

وماذا عن الموردين الفرعيين؟

المورد لا يخرج الخطر من نظام المؤسسة لمجرد توقيع العقد.

الخطوة الخامسة عشرة: صمم عملية لإدارة الحوادث

الحادث الأمني لا ينبغي أن يبدأ عند اكتشاف المشكلة بالتساؤل:

من نتصل به؟

حدد مسبقًا:

كيف يتم الإبلاغ؟

من يصنف الحادث؟

من يقود الاستجابة؟

من يقرر التصعيد؟

متى يدخل الشؤون القانونية أو الإدارة العليا؟

كيف يتم حفظ الأدلة؟

كيف يتم التواصل؟

وكيف تُستخلص الدروس بعد الحادث؟

ISO/IEC 27002 يتضمن إدارة والاستجابة لحوادث أمن المعلومات ضمن مجالات الضوابط التي يدعم بها ISMS.

الخطوة السادسة عشرة: اربط أمن المعلومات باستمرارية الأعمال

Backup ليس Business Continuity.

قد تكون النسخة الاحتياطية سليمة لكن استعادة النظام تستغرق وقتًا لا تستطيع المؤسسة تحمله.

لذلك اسأل:

ما الخدمات الحرجة؟

ما الأنظمة التي تدعمها؟

ما الاعتماديات؟

هل اختُبرت الاستعادة؟

من يقرر تشغيل البديل؟

وهل سيناريو الهجوم السيبراني موجود ضمن خطط الانقطاع؟

يمكن كذلك مواءمة ISO/IEC 27001 مع نظام استمرارية الأعمال ISO 22301 عندما يكون ذلك مناسبًا لنطاق المؤسسة.

الخطوة السابعة عشرة: اختبر النسخ الاحتياطي

الجملة:

«لدينا Backup».

غير كافية.

السؤال:

هل استعدناه بنجاح؟

راجع:

ما الذي يُنسخ؟

التكرار.

الفشل.

الحماية.

من يستطيع الوصول للنسخ؟

والاختبارات الفعلية للاستعادة.

الضابط الذي لم يُختبر قد يعطي شعورًا بالأمان أكبر من الحماية الفعلية.

الخطوة الثامنة عشرة: ابنِ الوعي بدل دورة سنوية شكلية

Security Awareness ليست عرض PowerPoint مرة واحدة.

يجب أن يعرف الموظف:

كيف يتعامل مع المعلومات؟

كيف يتعرف على رسالة مشبوهة؟

كيف يبلغ؟

ما قواعد استخدام الحسابات؟

ماذا يفعل إذا فقد جهازًا؟

وما مسؤوليته في حماية البيانات؟

وقد تختلف برامج الوعي بحسب الوظيفة.

المطور يحتاج وعيًا مختلفًا عن موظف الموارد البشرية أو المالية أو خدمة العملاء.

الخطوة التاسعة عشرة: حدد متطلبات الامتثال الأردنية

هنا يجب الفصل بوضوح:

ISO/IEC 27001 معيار دولي اختياري من حيث قرار الحصول على الشهادة.

بينما:

القوانين والضوابط الملزمة في الأردن يجب تطبيقها عندما تنطبق على المؤسسة.

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

كما ينشر المركز الإطار الوطني الأردني للأمن السيبراني ومكوناته وخرائط الأنشطة والضوابط.

وتوضح مادة منشورة رسميًا لدى المركز أن المادة 8 من قانون الأمن السيبراني رقم 16 لسنة 2019 ترتبط بالتزام الجهات باتباع السياسات والمعايير والضوابط التي يصدرها المركز لكل قطاع.

لذلك يجب أن يحتوي ISMS الأردني على Legal and Regulatory Register يعكس المتطلبات التي تنطبق فعليًا على المؤسسة والقطاع.

وما علاقة قانون حماية البيانات الشخصية بـISO/IEC 27001؟

قانون حماية البيانات الشخصية الأردني رقم 24 لسنة 2023 دخل حيز التنفيذ في 17 مارس 2024، وتوضح وزارة الاقتصاد الرقمي والريادة أن القطاعات التي تتعامل مع البيانات الشخصية ملزمة بالامتثال لأحكامه.

لكن:

ISO/IEC 27001 ≠ قانون حماية البيانات الشخصية.

ISO/IEC 27001 يساعد المؤسسة على إدارة أمن المعلومات والمخاطر والضوابط.

أما قانون حماية البيانات فينظم حقوق والتزامات ومعالجة البيانات الشخصية وفق القانون والأنظمة والتعليمات الصادرة بموجبه.

قد يوجد تداخل كبير بين الاثنين، لكن أحدهما لا يستبدل الآخر.

وللمؤسسات التي تحتاج إطارًا أكثر تخصصًا في إدارة الخصوصية، يوجد حاليًا أيضًا ISO/IEC 27701:2025 لنظام إدارة معلومات الخصوصية.

الخطوة العشرون: راقب الأداء

لا يكفي القول:

«طبقنا الضوابط».

حدد كيف ستعرف أنها تعمل.

يمكن أن تستخدم المؤسسة، بحسب احتياجها، مؤشرات مثل:

زمن إغلاق الحوادث.

نسبة مراجعات الصلاحيات المكتملة.

حالة معالجة المخاطر.

نسبة إغلاق الإجراءات التصحيحية.

نجاح اختبارات الاستعادة.

نتائج برامج الوعي.

أو مؤشرات أخرى مرتبطة بمخاطر النظام.

لكن لا تجعل عدد المؤشرات هدفًا.

اختر ما يساعد الإدارة على قراءة أداء ISMS واتخاذ القرار.

الخطوة الحادية والعشرون: نفذ التدقيق الداخلي

قبل التقييم الخارجي، اختبر النظام داخليًا.

لا تدقق على السياسات فقط.

اختر سيناريو.

مثلًا:

موظف غادر الشركة.

ثم تتبع:

هل أُبلغت الجهات؟

هل أُلغي الحساب؟

هل سُحبت الصلاحيات السحابية؟

هل أُعيد الجهاز؟

هل أُغلقت صلاحيات الأنظمة الخارجية؟

وهل توجد أدلة؟

أو ابدأ من حادث أمني:

كيف أُبلغ؟

كيف صُنف؟

من تعامل معه؟

ما الإجراء التصحيحي؟

وهل أدى إلى تحديث المخاطر؟

هذه الطريقة تكشف النظام الحقيقي.

وملفات IAC تثبت التدقيق الداخلي ومراجعات الامتثال ضمن خدمات أنظمة الإدارة التي تشمل ISO/IEC 27001.

الخطوة الثانية والعشرون: نفذ مراجعة الإدارة

أمن المعلومات ليس تقريرًا يرفعه IT.

يجب أن تصل للإدارة معلومات تساعدها على القرار:

المخاطر الرئيسية.

الحوادث.

أداء الضوابط.

حالة المعالجات.

التغيرات المهمة.

نتائج التدقيق.

الالتزامات.

الموارد.

والمشكلات التي تحتاج قرارًا قياديًا.

إذا كانت الإدارة لا ترى مخاطر المعلومات إلا بعد حادث كبير، فـISMS لم يصل إلى الحوكمة بعد.

الخطوة الثالثة والعشرون: عالج حالات عدم المطابقة

إذا اكتشف التدقيق أن مراجعة الصلاحيات لم تتم:

لا تكتفِ بعمل المراجعة المتأخرة.

اسأل:

لماذا لم تتم؟

هل المالك غير واضح؟

هل النظام لا يرسل تنبيهًا؟

هل الدورية غير واقعية؟

هل المسؤولية غير مدرجة؟

ثم:

صحح الحالة → عالج السبب → تحقق من الفعالية.

هذه هي طريقة بناء نظام يتعلم.

متى تصبح المؤسسة جاهزة للشهادة؟

لا توجد نسبة سحرية مثل:

«جاهزية 90%».

الأقرب إلى الجاهزية عندما تستطيع المؤسسة إثبات أن:

النطاق واضح.

المخاطر محددة ومحدثة.

قرارات المعالجة موثقة.

الضوابط اللازمة تعمل.

SoA تعكس قرارات النظام.

السياسات والإجراءات مستخدمة.

الأشخاص يعرفون مسؤولياتهم.

الأداء تتم مراقبته.

التدقيق الداخلي نُفذ.

الإدارة راجعت النظام.

وحالات عدم المطابقة المهمة عولجت.

ثم تستطيع المؤسسة، إذا رغبت، التعاقد مع جهة منح شهادة مستقلة.

ISO نفسها لا تمنح شهادات المؤسسات، والحصول على الشهادة قرار اختياري للمؤسسة؛ ويمكن استخدام الشهادة لإعطاء الأطراف المعنية مستوى إضافيًا من الثقة في نظام إدارة أمن المعلومات.

هل الحصول على ISO/IEC 27001 يعني أن المؤسسة لن تتعرض للاختراق؟

لا.

لا يوجد نظام يستطيع ضمان عدم حدوث حادث أمني.

وظيفة ISO/IEC 27001 هي بناء طريقة منهجية لإدارة المخاطر وتطوير قدرة المؤسسة على حماية المعلومات والتعامل مع التغيرات والتهديدات بصورة أكثر تنظيمًا.

العبارة الصحيحة ليست:

«ISO 27001 تمنع الاختراقات».

بل:

«ISO/IEC 27001 تساعد المؤسسة على إدارة مخاطر أمن المعلومات ضمن نظام مؤسسي قائم على المخاطر والتحسين المستمر».

هل ISO/IEC 27002 شهادة أخرى؟

لا.

ISO/IEC 27001 يحدد متطلبات ISMS ويمكن الحصول على شهادة عليه.

أما ISO/IEC 27002:2022 فيقدم إرشادات وممارسات للضوابط الأمنية ولا يؤدي بذاته إلى شهادة ISO/IEC 27002.

أخطاء شائعة عند تطبيق ISO/IEC 27001

شراء أدوات أمنية قبل تقييم المخاطر

المشكلة قد تكون في الحوكمة أو الصلاحيات أو الموردين، لا في نقص برنامج جديد.

تطبيق Annex A كـChecklist

الضوابط يجب أن تخدم معالجة المخاطر، لا أن تصبح قائمة شراء.

اعتبار IT مالك كل المخاطر

مخاطر المعلومات مسؤولية مؤسسية.

توثيق سياسات لا يعرفها الموظفون

السياسة غير المطبقة لا تحمي المعلومات.

عدم ضبط الموردين

جزء مهم من البيانات قد يكون خارج المؤسسة.

إهمال Physical Security

المعلومات ليست رقمية فقط.

التركيز على الشهادة قبل النظام

فتظهر الأدلة مؤقتًا قبل التدقيق ثم تختفي بعده.

تجاهل القانون

الشهادة لا تعفي من المتطلبات الأردنية.

عدم اختبار الاستعادة والطوارئ

الخطة غير المختبرة مجرد افتراض.

ما دور IAC؟

الملف التعريفي الرسمي لـIAC يثبت ISO/IEC 27001 لأمن المعلومات ضمن منظومة خدمات أنظمة الإدارة، ويثبت أن هذه المنظومة تشمل:

تصميم وتطوير وتطبيق أنظمة الإدارة.

التدقيق الداخلي.

مراجعات الامتثال.

تطوير السياسات والإجراءات.

مواءمة الأنظمة مع السياق التشريعي والتنظيمي.

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

ويُدار تدخل IAC وفق المنهجية المثبتة:

تشخيص موضوعي → تصميم مخصص → تنفيذ مرحلي → تمكين داخلي → قياس أثر.

لذلك فإن البداية الصحيحة ليست:

كم وثيقة نحتاج للشهادة؟

لطلب جلسة تشخيص أولية لنظام إدارة أمن المعلومات، يمكن التواصل مع IAC لتقييم الوضع الحالي وتحديد فجوات النظام ونطاق التطوير والمواءمة التنظيمية المناسبة للمؤسسة.