> ## Content Index
> Fetch the complete content index at: https://arabroot.io/llms.txt
> Use this file to discover other available public pages before exploring further.

# سجل المخاطر Risk Register مع SimpleRisk على سيرفرك
- URL: https://arabroot.io/articles/سجل-المخاطر-risk-register-مع-simplerisk/
- Published: 2026-10-26T04:48:31.000Z
- Updated: 2026-10-26T08:29:41.000Z
- Description: نبني سجل مخاطر حقيقياً بنموذج الهيئة ثم بأداة SimpleRisk، ونرى لماذا أعطت الأداة كل المخاطر مستوى واحداً، وكيف تكتب منهجية تعطي الأرقام معناها.
- Author: فريق عرب رووت
- Tags: الأدلة التقنية, الأمن السيبراني, السيادة الرقمية والامتثال, الاستضافة الذاتية, SimpleRisk

في مقال [إدارة الامتثال مع CISO Assistant](https://arabroot.io/articles/%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%A7%D9%84%D8%A7%D9%85%D8%AA%D8%AB%D8%A7%D9%84-%D9%85%D8%B9-ciso-assistant/) تابعنا شركة ناشئة في الرياض من اثني عشر موظفاً تبني منصة لحجز مواعيد العيادات، وهي تقيم نفسها على الضوابط الأساسية ECC-2:2024 لأن مستشفى حكومياً يطلب ذلك. وبعد شهر جاء عميل ثان من القطاع الخاص، وفي استبيان المورد Vendor Questionnaire الذي أرسله سؤال واحد أوقف الفريق: «أرفقوا سجل المخاطر Risk Register المعتمد، مع تاريخ آخر مراجعة وخطة معالجة كل مخاطرة مرتفعة». لم يكن لدى الشركة سجل، وإنما قائمة في رأس مدير التقنية بما يقلقه: مديران يدخلان بكلمة مرور فقط، ونسخ احتياطية لم يجرب أحد استعادتها، وواجهة API عامة تعمل بإصدار PHP قديم. وعندما جلس ليكتب السجل اكتشف أن السؤال ليس «ما الذي يقلقنا؟»، وإنما «من قرر ماذا بشأن كل واحدة، وعلى أي أساس، ومتى سنراجع القرار؟».

وهذا هو الفرق بين قائمة المخاوف وسجل المخاطر: القائمة تصف، والسجل يقرر. وقد شرحنا مصطلحات المخاطرة، أي الاحتمال Likelihood والأثر Impact والمخاطرة الأصلية Inherent والمتبقية Residual وشهية المخاطر Risk Appetite، في [مصطلحات GRC](https://arabroot.io/articles/%D9%85%D8%B5%D8%B7%D9%84%D8%AD%D8%A7%D8%AA-grc-%D8%A7%D9%84%D8%AD%D9%88%D9%83%D9%85%D8%A9-%D9%88%D8%A7%D9%84%D9%85%D8%AE%D8%A7%D8%B7%D8%B1-%D9%88%D8%A7%D9%84%D8%A7%D9%85%D8%AA%D8%AB%D8%A7%D9%84/#risk)، فلن نعيد تعريفها. وفي هذا المقال سوف نبني سجل الشركة فعلاً: نقرأ ما تطلبه الضوابط وما يحتويه نموذج سجل المخاطر الذي تنشره الهيئة الوطنية للأمن السيبراني، ثم نختار أداة مفتوحة المصدر، ونشغلها، وندخل فيها المخاطر الخمس، ونرى كيف أعطتنا الأداة نفسها في المحاولة الأولى تقييماً خاطئاً لكل المخاطر، ولماذا.

[![](https://arabroot.io/content/images/2026/10/grc-terms-cover-cover.webp)دليلمصطلحات GRC للمبتدئين بمثال من شركة صغيرةما الذي يعنيه GRC فعلاً، وما الكلمات التي يستخدمها المدقق، وكيف تثبت له أن ضوابطك تعمل كما تقول.](https://arabroot.io/articles/%D9%85%D8%B5%D8%B7%D9%84%D8%AD%D8%A7%D8%AA-grc-%D8%A7%D9%84%D8%AD%D9%88%D9%83%D9%85%D8%A9-%D9%88%D8%A7%D9%84%D9%85%D8%AE%D8%A7%D8%B7%D8%B1-%D9%88%D8%A7%D9%84%D8%A7%D9%85%D8%AA%D8%AB%D8%A7%D9%84/)[![](https://arabroot.io/content/images/2026/10/ciso-assistant-cover-cover.webp)دليلإدارة الامتثال Compliance مع CISO Assistant على سيرفركنشغل CISO Assistant ونحمل فيه ضوابط ECC-2:2024 ونقيم منصة حقيقية ونربطها بالضوابط والأدلة ونصدر التقرير، مع كل مشكلة واجهناها في الطريق.](https://arabroot.io/articles/%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%A7%D9%84%D8%A7%D9%85%D8%AA%D8%AB%D8%A7%D9%84-%D9%85%D8%B9-ciso-assistant/)[![](https://arabroot.io/content/images/2026/10/security-frameworks-cover-cover.webp)دليلأطر الأمن السيبراني Frameworks: أيها تحتاج مؤسستك؟الفرق بين ECC وISO 27001 وNIST CSF وSOC 2 في الإلزام وطريقة الإثبات وما تحصل عليه، وأربعة أسئلة تحدد بها ما تحتاجه مؤسستك.](https://arabroot.io/articles/%D8%A7%D8%B7%D8%B1-%D8%A7%D9%84%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%B3%D9%8A%D8%A8%D8%B1%D8%A7%D9%86%D9%8A-ecc-%D9%88-iso-27001-%D9%88-nist-csf-%D9%88-soc-2/)

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

- ما الذي يطلبه المكون الفرعي 1-5 في ECC من إدارة المخاطر، وأين يقع سجل المخاطر في ISO/IEC 27001.
- نموذج سجل المخاطر الرسمي من الهيئة: أوراقه وأعمدته والمعادلة التي يحسب بها المستوى.
- متى يكفي ملف Excel، ومتى تحتاج أداة.
- SimpleRisk أم eramba: أيهما تشغل، ولماذا اخترنا SimpleRisk، وما الذي يمنع eramba من أن يكون مفتوح المصدر رغم أن نسخته المجتمعية مجانية.
- تشغيل SimpleRisk بـ Docker، ولماذا فشلت الصورة الكاملة وعملت الصورة المصغرة مع MySQL منفصل.
- إدخال المخاطر الخمس، والخطأ الذي جعل كل المخاطر «High»، وطريقة Classic في الحساب.
- كيف تكتب مقياساً للاحتمال والأثر لا يعتمد على التخمين، ومن أين تدخل المخاطر الجديدة إلى السجل.
- المخاطرة نفسها بمستويين مختلفين في أداتين، مع سكربت صغير يبين السبب.
- المعالجة والمخاطرة المتبقية، والمراجعة، والواجهة العربية، وقائمة تحقق للسجل.

## ما الذي تطلبه الضوابط من إدارة المخاطر؟

المكون الفرعي 1-5 في [ECC-2:2024](https://cdn.nca.gov.sa/api/files/public/upload/86e09090-44e4-481f-bc28-355673607654%5FECC--2024-EN.pdf?ref=arabroot.io) عنوانه إدارة مخاطر الأمن السيبراني، وهدفه إدارة المخاطر بأسلوب منهجي لحماية أصول الجهة، وفيه أربعة ضوابط:

- **1-5-1:** أن تحدد إدارة الأمن السيبراني منهجية إدارة المخاطر وإجراءاتها وتوثقها وتعتمدها، مع مراعاة السرية والسلامة والتوافر.
- **1-5-2:** أن تطبق المنهجية والإجراءات.
- **1-5-3:** أن تنفذ إجراءات تقييم المخاطر على الأقل في أربع حالات: في المراحل الأولى من المشاريع التقنية، وقبل إجراء تغيير جوهري في البنية التقنية، وعند التخطيط للحصول على خدمات طرف خارجي، وعند التخطيط لخدمات ومنتجات تقنية جديدة وقبل إطلاقها.
- **1-5-4:** أن تراجع المنهجية وتحدث على فترات مخططة، أو عند تغير المتطلبات التشريعية والتنظيمية، وأن توثق التغييرات وتعتمد.

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

أما في ISO/IEC 27001:2022 فالمخاطر في قلب نظام الإدارة نفسه، وجدول الربط الرسمي الذي تنشره NIST بين إطارها CSF 2.0 والمعيار، والذي حللناه في [مقال الأطر](https://arabroot.io/articles/%D8%A7%D8%B7%D8%B1-%D8%A7%D9%84%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%B3%D9%8A%D8%A8%D8%B1%D8%A7%D9%86%D9%8A-ecc-%D9%88-iso-27001-%D9%88-nist-csf-%D9%88-soc-2/#lab)، يربط البند 6.1.2 بتقييم المخاطر والبند 6.1.3 بمعالجتها، ويقابلهما في CSF نتائج مثل GV.RM-02 الخاصة بتحديد شهية المخاطر وتحملها. والنتيجة أن سجل المخاطر الواحد، إذا بني جيداً، يخدم ECC وISO معاً، وهذا ما سوف نفعله.

![ست خطوات لحياة مخاطرة في السجل: تحديد، ثم تحليل المخاطرة الأصلية، ثم قرار المعالجة، ثم تنفيذ بمالك وموعد، ثم المخاطرة المتبقية، ثم المراجعة، وتحتها أربع حالات يجب فيها تقييم المخاطر بحسب الضابط 1-5-3](https://arabroot.io/content/images/2026/10/risk-register-01-lifecycle.webp)

كل سطر في السجل قرار له مالك وموعد ومراجعة، وليس وصفاً لمخاوف

## نموذج سجل المخاطر من الهيئة الوطنية للأمن السيبراني

قبل أن نبحث عن أداة، نفتح ما تنشره الهيئة نفسها، ففي صفحة [أدوات الأمن السيبراني](https://nca.gov.sa/ar/regulatory-documents/guidelines-list/cybersecurity-toolkits/?ref=arabroot.io) نموذج Excel باسم «سجل مخاطر الأمن السيبراني»، ومعه «إجراء إدارة مخاطر الأمن السيبراني» و«سياسة إدارة مخاطر الأمن السيبراني». ونزلنا ملف السجل وقرأناه بمكتبة openpyxl، فوجدنا فيه ثماني أوراق: صفحة الغلاف، وورقة للتحقق من البيانات فيها القوائم المنسدلة، وضبط النسخة، ومفتاح يشرح كل عمود، والسجل نفسه، وورقة فيها مخطط حراري Heat Map للمخاطر الأصلية وآخر للمتبقية، والمخاطر الكلية، وملخص يعد المخاطر في كل مستوى.

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

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

```text
=IF(K12*L12<=3,"منخفض جدًا",IF(K12*L12<=6,"منخفض",IF(K12*L12<=10,"متوسط",IF(K12*L12<=16,"مرتفع","حرج"))))
```

أي أن النموذج يضرب الاحتمال في الأثر، فيعطي رقماً من 1 إلى 25، ثم يصنفه بخمسة مستويات: حتى 3 منخفض جداً، وحتى 6 منخفض، وحتى 10 متوسط، وحتى 16 مرتفع، وما فوق ذلك حرج. والعمود V يطبق المعادلة نفسها على المخاطرة المتبقية. وهذه المعادلة هي منهجية كاملة مصغرة، وإذا اعتمدتها جهتك فقد كتبت نصف ما يطلبه 1-5-1، وسوف نعود إليها عندما نقارن بها الأداة.

ولاحظ أن الملف وحده لا يكفي، فالسجل هو المخرج، أما المنهجية فمكانها وثيقتان أخريان في الصفحة نفسها: سياسة إدارة مخاطر الأمن السيبراني التي تقول من يملك ماذا ومتى يقيم، وإجراء إدارة المخاطر الذي يصف الخطوات بالتفصيل. وقد شرحنا في [مقال السياسات](https://arabroot.io/articles/%D8%B3%D9%8A%D8%A7%D8%B3%D8%A7%D8%AA-%D8%A7%D9%84%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%B3%D9%8A%D8%A8%D8%B1%D8%A7%D9%86%D9%8A-%D9%82%D9%88%D8%A7%D9%84%D8%A8-%D9%88%D9%83%D9%8A%D9%81-%D8%AA%D9%83%D8%AA%D8%A8-%D8%B3%D9%8A%D8%A7%D8%B3%D8%A9-%D8%AA%D8%B7%D8%A8%D9%82/) كيف تحول نموذج الهيئة من وثيقة عامة بخانات فارغة إلى صفحة تطبقها جهتك، والطريقة نفسها تنطبق هنا: احذف ما لا ينطبق، واكتب الحدود والمدد بأرقامك، وضع اسم المالك، ثم اعتمدها قبل أن تملأ أول سطر في السجل، لأن السجل الذي يسبق المنهجية سوف تعيد تقييمه كله عندما تكتبها.

💡

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

## متى يكفي Excel، ومتى تحتاج أداة؟

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

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

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

## SimpleRisk أم eramba؟

الطلب في عنوان هذه المرحلة كان أن نشغل الأداة التي لها نسخة مجتمعية تعمل فعلاً، ونقول لماذا. فقرأنا صفحات الأداتين الرسمية قبل أن نسحب أي Image، وكانت النتيجة كما في الجدول التالي، بتاريخ 25 أكتوبر 2026:

|                       | SimpleRisk Core                                             | eramba Community                                                                 |
| --------------------- | ----------------------------------------------------------- | -------------------------------------------------------------------------------- |
| الترخيص               | Mozilla Public License 2.0، أي مفتوح المصدر                 | كود مفتوح للقراءة لكنه ليس مفتوح المصدر، ولا يسمح بالتعديل ولا إعادة التوزيع     |
| السعر                 | Core مجاني بمستخدمين بلا حد، والإضافات Extras بأسعار منشورة | Community مجانية، وEnterprise بـ 2,500 يورو سنوياً على سيرفرك أو 5,000 يورو SaaS |
| ما في النسخة المجانية | الحوكمة والمخاطر والامتثال وإدارة الأصول والتقارير          | أربع حالات استخدام من سبع: المخاطر والامتثال وخصوصية البيانات والحوادث           |
| العمل دون إنترنت      | يعمل على شبكتك                                              | يحتاج اتصالاً صادراً إلى خادم دعم الشركة، ولا يعمل دون إنترنت بالكامل            |
| آخر إصدار             | 20261020-001                                                | 3.31.2 بتاريخ 21 أكتوبر 2026                                                     |
| الواجهة العربية       | ملف ترجمة عربي ضمن اللغات                                   | لم نجربها                                                                        |

والسطر الأول هو الذي حسم القرار. فصفحة [الأسئلة الشائعة في eramba](https://www.eramba.org/faqs?ref=arabroot.io) تقول بوضوح إن النسختين Community وEnterprise متاحتان بكود مفتوح لكنهما ليستا مفتوحتي المصدر، وإن اتفاقية الترخيص تمنع تعديل الكود أو الهندسة العكسية أو إعادة التوزيع، وصفحة [تحميل النسخة المجتمعية](https://www.eramba.org/get-community?ref=arabroot.io) تقول إنها تحتاج وصولاً صادراً إلى `support-v3.eramba.org` ولا تعمل دون اتصال بالكامل. والشرط الثاني وحده مشكلة لجهة تريد أن تكون أداة المخاطر، وهي من أكثر الأدوات حساسية، على شبكة معزولة. أما SimpleRisk فملف الترخيص في [مستودع الكود المنشور](https://github.com/simplerisk/code?ref=arabroot.io) هو MPL 2.0، وصفحة [الأسعار](https://www.simplerisk.com/pricing?ref=arabroot.io) تقول إن Core مجاني ومفتوح المصدر بمستخدمين بلا حد.

ولكل اختيار ثمن، وثمن SimpleRisk يظهر في الصفحة نفسها: الإضافات Extras بسعر ثابت 5,000 دولار سنوياً لكل إضافة قياسية، ومنها الـ API وتكامل Jira وتقييم المخاطر بالاستبيانات وإدارة الثغرات والفصل بين الفرق، و10,000 دولار للإضافات المميزة مثل إدارة الحوادث. وهذا يعني أن الـ API ليست في النسخة المجانية، فإذا أردت أن تدخل المخاطر آلياً من أدوات الفحص فسوف تدفع، أو تفعل ما فعلناه في التجربة وتستخدم الواجهة. ولاحظ أن مستودع GitHub المنشور للكود نسخة للقراءة فقط تنشر عند كل إصدار، والتطوير نفسه في مستودع خاص، كما يقول ملف README فيه، وهذا لا يغير الترخيص، لكنه يعني أن مساهمتك تمر عبر دعم الشركة وليس عبر Pull Request.

## تشغيل SimpleRisk بـ Docker

تنشر الشركة صورتين في Docker Hub: صورة `simplerisk/simplerisk` فيها كل شيء، أي Apache وPHP وMySQL في Container واحد، وصورة `simplerisk/simplerisk-minimal` فيها التطبيق فقط وتحتاج قاعدة بيانات منفصلة، كما يشرح [مستودع الـ Docker الرسمي](https://github.com/simplerisk/docker?ref=arabroot.io). وبدأنا بالصورة الكاملة لأنها الأبسط:

```bash
docker run -d --name simplerisk -p 127.0.0.1:8443:443 simplerisk/simplerisk:20261020-001
```

وبعد دقيقة توقف الـ Container، وكانت آخر أسطر سجله كما يلي:

```text
[initial_setup:mysql] Setting up MySQL
 * Starting MySQL database server mysqld
su: warning: cannot change directory to /nonexistent: No such file or directory
   ...fail!
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
```

وحالته `exited` برمز خروج 1\. والسبب أن سكربت التشغيل يبدأ خدمة MySQL داخل الـ Container وينتظرها مدة محددة، والجهاز كان مشغولاً بمختبرات أخرى، فلم يكتمل تشغيل MySQL في المهلة، ففشل السكربت كله. وقد يتساءل البعض: لماذا لا نعيد المحاولة على جهاز أهدأ؟ والإجابة أن الصورة الكاملة غير مناسبة للاستخدام الحقيقي أصلاً، فهي تجمع قاعدة البيانات والتطبيق في Container واحد، فلا تستطيع تحديث أحدهما دون الآخر، ولا أخذ نسخة احتياطية لقاعدة البيانات بأدواتها المعتادة، ولذلك انتقلنا مباشرة إلى الطريقة الموصى بها: الصورة المصغرة مع MySQL منفصل، وهي الطريقة التي يستخدمها ملف `stack.yml` في المستودع.

ننشئ أولاً ملف `.env` بثلاث كلمات مرور مولدة، واحدة لمستخدم root في MySQL تستخدم مرة واحدة في الإعداد، وواحدة لمستخدم التطبيق، وواحدة للمدير الأول:

```bash
printf "SETUP_PASS=%s\nAPP_PASS=%s\nADMIN_PASS=%s\n" \
  "$(openssl rand -hex 16)" "$(openssl rand -hex 16)" "$(openssl rand -base64 18 | tr -d '/+=')" > .env
```

ثم ملف `docker-compose.yml`:

```yaml
services:
  mysql:
    image: mysql:8.4.11
    command: mysqld --sql_mode="NO_ENGINE_SUBSTITUTION"
    environment:
      MYSQL_ROOT_PASSWORD: ${SETUP_PASS}
    volumes:
      - risk-db:/var/lib/mysql
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-p${SETUP_PASS}"]
      interval: 10s
      retries: 30
  simplerisk:
    image: simplerisk/simplerisk-minimal:20261020-001
    depends_on:
      mysql:
        condition: service_healthy
    environment:
      DB_SETUP: automatic
      DB_SETUP_PASS: ${SETUP_PASS}
      SIMPLERISK_DB_HOSTNAME: mysql
      SIMPLERISK_DB_PASSWORD: ${APP_PASS}
      ADMIN_USERNAME: admin
      ADMIN_PASSWORD: ${ADMIN_PASS}
      ADMIN_EMAIL: admin@example.com
    ports:
      - "127.0.0.1:8443:443"
volumes:
  risk-db:
```

في الإعداد أعلاه لاحظ التالي:

- `DB_SETUP: automatic` يطلب من الـ Container أن ينشئ قاعدة البيانات ومستخدم التطبيق بنفسه في أول تشغيل، بصلاحيات root التي في `DB_SETUP_PASS`، وبعدها يستخدم التطبيق مستخدمه المحدود فقط. وإذا لم تعط `SIMPLERISK_DB_PASSWORD` فسوف يولد كلمة مرور ويطبعها في السجل، وهذا ما لا تريده في سجل يذهب إلى منصة سجلات مركزية.
- `ADMIN_USERNAME` وأخواه ينشئون المدير الأول مرة واحدة، بحسب ملف README للصورة المصغرة.
- `--sql_mode="NO_ENGINE_SUBSTITUTION"` منقول من ملف `stack.yml` الرسمي، والسبب أن مخطط قاعدة بيانات SimpleRisk قديم ويتوقع سلوك MySQL المتساهل في بعض القيم الافتراضية.
- الملف الرسمي يستخدم `mysql:8.0`، واستخدمنا `mysql:8.4.11` لأنه الإصدار طويل الدعم الأحدث، وعمل الإعداد دون أخطاء، لكن إذا أردت السير على المسار الذي تختبره الشركة فالتزم بما في ملفها.
- فحص الصحة على MySQL مع `condition: service_healthy` يمنع التطبيق من البدء قبل أن تقبل قاعدة البيانات الاتصالات.

وبعد `docker compose up -d` قرأنا السجل حتى نعرف أين يقضي الوقت:

```text
[Sun Oct 25 21:07:56.129303 2026] [initial_setup:info] First time setup. Will wait...
[Sun Oct 25 21:08:16.152495 2026] [initial_setup:info] Starting database set up
[Sun Oct 25 21:08:16.154225 2026] [initial_setup:info] Downloading schema...
[Sun Oct 25 21:08:20.012100 2026] [initial_setup:info] Applying changes to MySQL database... (MySQL error will be printed to console as guidance)
[Sun Oct 25 21:15:13.814558 2026] [initial_setup:info] Setup has been applied successfully!
Admin user 'admin' created with ID 1.
```

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

- السطر الأول والثاني يبينان أن الـ Container ينتظر 20 ثانية قبل أن يبدأ، وهذا هو المتغير `DB_SETUP_WAIT` بقيمته الافتراضية، وفائدته حين تشغل قاعدة البيانات والتطبيق معاً دون فحص صحة.
- السطر الثالث «Downloading schema» يعني أن الـ Container ينزل مخطط قاعدة البيانات من الإنترنت عند أول تشغيل، فإذا كان سيرفرك معزولاً فسوف يفشل هذا السطر، وخطط لذلك.
- تطبيق المخطط استغرق من 21:08:20 إلى 21:15:13، أي نحو سبع دقائق، وبعدها أنشئ المدير وبدأ Apache.

وقسنا الموارد بعد التشغيل: الـ Image المصغرة 1.97 GB، وتستهلك نحو 107 إلى 143 MiB من الذاكرة، وMySQL بين 408 و522 MiB، أي أن الأداة كلها أقل من ثلث ما احتاجه CISO Assistant. وداخل الـ Container يعمل PHP 8.5.12 مع Apache 2.4.69 على Debian.

## أول مخاطرة، وخطأ جعل كل شيء «High»

من قائمة Risk Management نختار Submit Risk، والنموذج فيه الموضوع Subject، ووصف التقييم، ثم قسم التقييم Scoring الذي يبدأ بحقل «أسلوب تسجيل المخاطر» Risk Scoring Method، والشكل التالي يبين النموذج كما يظهر:

![نموذج تقديم مخاطرة في SimpleRisk بالواجهة العربية: حقل الموضوع، ومحرر نص لتقييم المخاطر، وقسم التقييم وفيه أسلوب تسجيل المخاطر بقيمة فارغة](https://arabroot.io/content/images/2026/10/risk-register-03-submit.webp)

حقل «أسلوب تسجيل المخاطر» يظهر فارغاً، وهنا بدأت مشكلتنا

وفي المحاولة الأولى أدخلنا المخاطر الخمس باحتمال وأثر لكل منها، دون أن ننتبه إلى أن حقل أسلوب التسجيل ما زال فارغاً، فقبلت الأداة الإدخال، وظهرت القائمة كما في الشكل التالي:

![صفحة Review Risk في SimpleRisk فيها خمس مخاطر بأرقام 1001 إلى 1005 وكلها بمستوى High وحالة Unreviewed، وعدادات Needs Mitigation وNeeds Review بقيمة 5](https://arabroot.io/content/images/2026/10/risk-register-04-review.webp)

خمس مخاطر بمستوى High واحد، وهي ليست متساوية أبداً

كل المخاطر «High»، من مزود البريد إلى الـ API المكشوفة، وهذا مستحيل منطقياً. وعندما فتحنا المخاطرة 1005 وجدنا السبب في قسم التقييم: «Risk Scoring Method: Custom» و«Custom Score: 10»، أي أن الأداة عندما لم تجد أسلوباً محدداً اعتمدت الأسلوب المخصص بدرجته القصوى، وتجاهلت الاحتمال والأثر اللذين اخترناهما. وهذا الخطأ مهم لأنه لا يعطي رسالة خطأ، فالسجل يبدو مكتملاً، والمدير الذي يقرأ القائمة يرى خمس مخاطر عالية فيقرر بناء على ذلك. والحل أن تختار Classic صراحة قبل الاحتمال والأثر، فأعدنا الإدخال بأرقام جديدة من 1006 إلى 1010، وتركنا المحاولة الأولى في السجل لأن هذا ما يحدث في الواقع: الخطأ يبقى في التاريخ، والقرار الصحيح أن تغلقه بسبب مكتوب لا أن تحذفه.

⚠️

في SimpleRisk اختر أسلوب التسجيل Classic أو غيره قبل أن تختار الاحتمال والأثر، وإلا سجلت المخاطرة بأسلوب Custom بدرجة 10، وظهرت «High» مهما كانت. وراجع قسم Scoring في أول مخاطرة تدخلها قبل أن تكمل البقية.

## كيف تحسب طريقة Classic المخاطرة؟

بعد التصحيح فتحنا المخاطرة 1008، وهي الـ API العامة بإصدار PHP قديم، فظهرت كما يلي:

![صفحة المخاطرة 1008 في SimpleRisk: المخاطرة الأصلية 8 High والمتبقية 8 High، وطريقة Classic مع المعادلة RISK = (Likelihood x Impact) x (10/25)، والاحتمال Likely والأثر Extreme/Catastrophic](https://arabroot.io/content/images/2026/10/risk-register-05-view.webp)

طريقة Classic تكتب معادلتها تحت الدرجة: (الاحتمال × الأثر) × (10/25)

والأداة تكتب المعادلة تحت الدرجة: `RISK = ( Likelihood x Impact ) x (10/25)`. أي أنها تضرب الاحتمال من 1 إلى 5 في الأثر من 1 إلى 5 كما يفعل نموذج الهيئة تماماً، ثم تحول الناتج من مقياس 25 إلى مقياس 10\. فالمخاطرة 1008 احتمالها 4 Likely وأثرها 5 Extreme، والناتج 20، وبالتحويل 8، وظهرت «High». ولاحظ أيضاً أن المخاطرة الأصلية والمتبقية في أعلى الصفحة متساويتان، 8 و8، لأننا لم نخطط أي معالجة بعد. وكانت الدرجات للمخاطر الخمس كما يلي: 6.4 Medium لحسابات المديرين، و6 Medium للنسخ الاحتياطية، و8 High للـ API، و3.6 Low للسجلات، و2.4 Low لمزود البريد.

## المخاطرة نفسها بمستويين مختلفين

هنا ظهر سؤال لم يتوقعه الفريق: حسابات المديرين احتمالها 4 وأثرها 4، أي 16، وهذا في نموذج الهيئة «مرتفع»، لكنه في SimpleRisk «Medium». والـ API ناتجها 20، وهي في نموذج الهيئة «حرج»، وفي SimpleRisk «High». فأي المستويين صحيح؟ والإجابة أن كليهما صحيح بمنهجيته، والمشكلة أن الشركة لم تكتب منهجيتها بعد. ولنرى الفرق بالأرقام كتبنا سكربتاً صغيراً يطبق المنهجيتين على المخاطر نفسها، ونحفظ المخاطر أولاً في `risks.csv`:

```text
id,risk,likelihood,impact,mitigation_percent
A,Administrator accounts sign in with a password only,4,4,0
B,Backups in the same data center and never restored,3,5,0
C,Public booking API runs an outdated PHP build,4,5,75
D,Security logs kept 30 days only,3,3,0
E,Transactional email provider outside the Kingdom,2,3,0
```

ثم السكربت باسم `levels.py`:

```python
# Same register, two methodologies: the NCA template thresholds on L x I, and the SimpleRisk Classic score
import csv, sys

def nca_level(product):            # thresholds from the NCA risk register template formula
    if product <= 3: return "very low"
    if product <= 6: return "low"
    if product <= 10: return "medium"
    if product <= 16: return "high"
    return "critical"

for r in csv.DictReader(open(sys.argv[1], encoding="utf-8")):
    l, i, m = int(r["likelihood"]), int(r["impact"]), int(r["mitigation_percent"])
    product = l * i
    classic = product * 10 / 25                     # SimpleRisk: (Likelihood x Impact) x (10/25)
    residual = round(classic * (1 - m / 100), 2)    # SimpleRisk residual after the mitigation percent
    print(f"{r['id']}  L{l} x I{i} = {product:2d}  NCA: {nca_level(product):9s}  Classic: {classic:4.1f}  residual: {residual}")
```

ونشغله دون أن نثبت Python على الجهاز:

```bash
docker run --rm -v "$PWD:/w" -w /w python:3.13.17-slim python levels.py risks.csv
```

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

```text
A  L4 x I4 = 16  NCA: high       Classic:  6.4  residual: 6.4
B  L3 x I5 = 15  NCA: high       Classic:  6.0  residual: 6.0
C  L4 x I5 = 20  NCA: critical   Classic:  8.0  residual: 2.0
D  L3 x I3 =  9  NCA: medium     Classic:  3.6  residual: 3.6
E  L2 x I3 =  6  NCA: low        Classic:  2.4  residual: 2.4
```

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

- عمود الحاصل L × I واحد في المنهجيتين، فالترتيب من الأخطر إلى الأقل خطراً واحد: C ثم A ثم B ثم D ثم E. وهذا جيد، فالمنهجيتان تتفقان على أي المخاطر يعالج أولاً.
- عمود Classic يطابق ما ظهر في الأداة بالضبط، 6.4 و6 و8 و3.6 و2.4، أي أننا فهمنا المعادلة.
- الاختلاف في الكلمة: A وB «high» في نموذج الهيئة، و«Medium» في الأداة. والكلمة ليست تفصيلاً، لأن المنهجية عادة تقول «المخاطر المرتفعة يقبلها الرئيس التنفيذي فقط، وتعالج خلال 30 يوماً»، فإذا قرأ المدير «Medium» فقد يقبلها مسؤول أقل، وبموعد أبعد.
- العمود الأخير يحسب المخاطرة المتبقية للمخاطرة C بعد معالجة فعاليتها 75%، وهي 2، وسوف نراها في الأداة في القسم التالي.

والشكل التالي يضع المخاطر الخمس على مصفوفة 5×5 ملونة بحدود نموذج الهيئة، وبجانبها درجات الأداة:

![مصفوفة حرارية 5 في 5 بحدود نموذج الهيئة عليها المخاطر A وB وC وD وE، وجدول يقارن مستوى كل مخاطرة في نموذج الهيئة ودرجتها ومستواها في SimpleRisk Classic](https://arabroot.io/content/images/2026/10/risk-register-02-two-scales.webp)

الترتيب واحد، والمستوى الذي يقرأه المدير مختلف

والقرار الذي اتخذته الشركة: اعتماد منهجية نموذج الهيئة، لأن المستشفى الحكومي يعرفها، ولأن حدودها مكتوبة في معادلة يقرؤها أي شخص، ثم ضبط مستويات الخطر في الأداة لتطابقها، أو على الأقل كتابة جدول مقابلة في وثيقة المنهجية يقول إن درجة Classic من 6 إلى 6.4 تقابل «مرتفع». وهذا هو جوهر الضابط 1-5-1: الأداة تحسب، والمنهجية المكتوبة هي التي تعطي الأرقام معناها.

## كيف تقدر الاحتمال والأثر دون أن تخمن؟

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

- **1 بعيد Remote:** لا نعرف حالة حدثت في قطاعنا، والاستغلال يحتاج وصولاً داخلياً ومهارة عالية.
- **2 غير مرجح Unlikely:** حدث في قطاعنا خلال السنوات الماضية، لكن عندنا ضابط يمنعه في الغالب.
- **3 ممكن Credible:** حدث في قطاعنا، والضابط عندنا جزئي أو لم يختبر.
- **4 مرجح Likely:** الثغرة أو الضعف معروف علناً، والأصل مكشوف على الإنترنت أو يستخدمه عدد كبير من الموظفين.
- **5 شبه مؤكد Almost Certain:** يوجد استغلال منشور أو حملة نشطة تستهدفه الآن، أو حدث عندنا من قبل.

وبهذه الصياغة أصبح تقدير ثغرة PHP سهلاً: الـ API مكشوفة على الإنترنت، والثغرة منشورة في نشرة المشروع، فهي 4 على الأقل، وإذا ظهر استغلال منشور تصبح 5، وقد شرحنا كيف تعرف أن ثغرة اليوم تمس سيرفراتك في [إدارة الثغرات](https://arabroot.io/articles/%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%A7%D9%84%D8%AB%D8%BA%D8%B1%D8%A7%D8%AA-vulnerability-management-%D9%84%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D8%A7%D8%AA%D9%83/). أما مقياس الأثر فكتبته الشركة بأبعاد عملها، لأن الأثر في عيادة يختلف عنه في متجر:

- **1 ضئيل Insignificant:** لا تتأثر بيانات المرضى، وتوقف أقل من ساعة خارج أوقات العمل.
- **2 بسيط Minor:** توقف حتى أربع ساعات، أو تسرب بيانات غير شخصية.
- **3 متوسط Moderate:** توقف يوم عمل، أو تسرب بيانات شخصية لعدد محدود يستوجب تقييم الإشعار.
- **4 كبير Major:** توقف أكثر من يوم، أو تسرب بيانات صحية، أو مخالفة لشرط في عقد حكومي.
- **5 حرج Extreme:** تسرب واسع لبيانات صحية، أو فقدان بيانات لا يمكن استعادته، أو إنهاء عقد رئيسي.

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

## من أين تأتي المخاطر؟

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

- **فحص الثغرات:** كل ثغرة مرتفعة على أصل مكشوف لا تعالج في مدتها تصبح مخاطرة في السجل بقرار، وليس فقط تذكرة في نظام التذاكر.
- **الحوادث:** كل حادث، حتى لو كان صغيراً، يسأل بعده: هل هذا يكشف مخاطرة لم نسجلها؟ وقد شرحنا مراجعة ما بعد الحادث في [التحقيق الرقمي DFIR](https://arabroot.io/articles/%D8%A7%D9%84%D8%AA%D8%AD%D9%82%D9%8A%D9%82-%D8%A7%D9%84%D8%B1%D9%82%D9%85%D9%8A-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-dfir/).
- **نمذجة التهديدات:** عند تصميم ميزة جديدة، مثل ربط المنصة بنظام مستشفى، تخرج من جلسة [نمذجة التهديدات](https://arabroot.io/articles/%D9%86%D9%85%D8%B0%D8%AC%D8%A9-%D8%A7%D9%84%D8%AA%D9%87%D8%AF%D9%8A%D8%AF%D8%A7%D8%AA-threat-modeling-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/) مخاطر تدخل السجل قبل الإطلاق، وهذا هو 1-5-3 نفسه.
- **المزودون الجدد:** كل مزود تصل إليه بيانات أو وصول يقيم قبل التعاقد.
- **نتائج التدقيق والتقييم الذاتي:** كل متطلب «غير ملتزم» في تدقيق ECC لا يعالج فوراً يسجل مخاطرة بمالك، كما فعلنا مع 2-2-3-2 و2-9-3-3.
- **الموظفون:** نموذج بسيط في البوابة الداخلية لأي موظف يرى شيئاً يقلقه، لأن أفضل المخاطر يعرفها من يعمل على النظام كل يوم.

## المعالجة والمخاطرة المتبقية

لكل مخاطرة أربعة خيارات في نموذج الهيئة: الحد منها، وتجنبها، ونقلها، وقبولها. وفي SimpleRisk خمسة: Mitigate للحد منها، وAccept للقبول، وTransfer للنقل، وResearch عندما تحتاج دراسة قبل القرار، وWatch للمراقبة دون إجراء الآن. وقد خططنا معالجة للمخاطرة 1008 من صفحتها، باختيار Plan a Mitigation، ثم الاستراتيجية Mitigate، والجهد Minor، والتكلفة من صفر إلى 100,000 دولار وهي أصغر فئة في القائمة، ونسبة فعالية المعالجة Mitigation Percent بقيمة 75، والمالك Administrator، فتغيرت الصفحة كما يلي:

![صفحة المخاطرة 1008 بالواجهة العربية بعد تخطيط المعالجة: المخاطرة الأصلية 8 High والمتبقية 2 Low والحالة Mitigation Planned](https://arabroot.io/content/images/2026/10/risk-register-06-mitigation.webp)

بعد معالجة بفعالية 75%: الأصلية 8 والمتبقية 2، والحالة Mitigation Planned

المخاطرة المتبقية أصبحت 2 Low، أي 8 × (1 − 0.75)، وهي القيمة نفسها التي حسبها السكربت. لكن انتبه هنا لأخطر خطأ في سجلات المخاطر كلها: نسبة 75% رقم كتبناه نحن، ولم يقسه أحد. ولو كتبنا 95% لأصبحت المخاطرة المتبقية 0.4، وبدت المشكلة محلولة قبل أن يحدث المطور PHP أصلاً. لذلك ضع في منهجيتك قاعدتين:

- **المتبقية تقدر بعد التنفيذ وليس بعد التخطيط:** الحالة في الأداة «Mitigation Planned»، والمخاطرة المتبقية التي تحسبها الأداة هي ما تتوقعه بعد التنفيذ، فلا تعرضها على العميل كأنها الوضع الحالي.
- **الفعالية تحتاج دليلاً:** «حدثنا PHP وأعدنا فحص الـ API بأداة الثغرات فلم تظهر الثغرات المعروفة» دليل، أما «سوف نحدث» فليس دليلاً. وهنا يأتي دور الضابط المطبق والدليل في [CISO Assistant](https://arabroot.io/articles/%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%A7%D9%84%D8%A7%D9%85%D8%AA%D8%AB%D8%A7%D9%84-%D9%85%D8%B9-ciso-assistant/#controls)، وفي مقال جمع الأدلة تلقائياً.

أما المخاطرة B، النسخ الاحتياطية في المركز نفسه دون اختبار استعادة، فهي التي تذكر الفريق دائماً بأن المخاطرة ليست نظرية، فقد شرحنا في [حريق OVHcloud في ستراسبورغ](https://arabroot.io/articles/%D8%AD%D8%B1%D9%8A%D9%82-%D9%85%D8%B1%D9%83%D8%B2-%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA-ovhcloud-%D9%81%D9%8A-%D8%B3%D8%AA%D8%B1%D8%A7%D8%B3%D8%A8%D9%88%D8%B1%D8%BA/) كيف احترقت نسخ احتياطية لعملاء كانت في المبنى نفسه مع البيانات. والمعالجة هنا ليست شراء أداة، وإنما نسخة خارج الموقع واختبار استعادة له محضر، كما في [قاعدة 3-2-1](https://arabroot.io/articles/%D8%A7%D9%84%D9%86%D8%B3%D8%AE-%D8%A7%D9%84%D8%A7%D8%AD%D8%AA%D9%8A%D8%A7%D8%B7%D9%8A-%D8%A8%D9%82%D8%A7%D8%B9%D8%AF%D8%A9-3-2-1-%D9%88%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%B9%D8%A7%D8%AF%D8%A9/)، وبعدها فقط تنخفض المخاطرة المتبقية.

وأما المخاطرة E، مزود البريد خارج المملكة، فمستواها منخفض في المنهجيتين، لكن هذا لا يعني أن تتركها، لأن جزءاً منها التزام نظامي وليس مخاطرة فقط: نقل البيانات الشخصية خارج المملكة يحتاج غرضاً وشروطاً وتوثيقاً بحسب نظام حماية البيانات الشخصية، كما شرحنا في [حماية البيانات الشخصية للخدمات المستضافة](https://arabroot.io/articles/%D8%AD%D9%85%D8%A7%D9%8A%D8%A9-%D8%A7%D9%84%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA-%D8%A7%D9%84%D8%B4%D8%AE%D8%B5%D9%8A%D8%A9-pdpl-%D9%84%D9%84%D8%AE%D8%AF%D9%85%D8%A7%D8%AA-%D8%A7%D9%84%D9%85%D8%B3%D8%AA%D8%B6%D8%A7%D9%81%D8%A9/#transfer). والقاعدة: المخاطرة المنخفضة يمكن قبولها، والمخالفة النظامية لا تقبل، فافصل بين الاثنين في السجل.

## ما الذي يقرؤه المديرون كل شهر؟

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

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

## قبول المخاطرة: من يوقع؟

في مفتاح أعمدة نموذج الهيئة عمود يسأل: «هل التصنيف الكلي للمخاطر الكامنة مقبول؟ إذا لم يكن كذلك، فيرجى تقديم السبب»، وعمود يسمح لمالك المخاطرة بتجاوز التصنيف يدوياً. وهذان العمودان يجيبان عن سؤال يتجاهله كثيرون: من يملك قرار المخاطرة؟ والإجابة في أغلب المنهجيات أن المالك هو صاحب الأصل أو العملية، وليس فريق الأمن السيبراني، فالفريق يحلل ويقترح، والمالك يقرر ويتحمل. وفي قصة منصة الحجز كانت المخاطرة D، السجلات 30 يوماً فقط، مثالاً جيداً: فريق الأمن قدرها متوسطة، والرئيس التنفيذي سأل: «كم يكلف الاحتفاظ سنة؟» فلما عرف أنها مساحة قرص إضافية بسيطة قرر المعالجة فوراً، لأن الضابط 2-12-3-5 يطلب 12 شهراً أصلاً، وقد أثبتنا الإعداد في [مقال ضوابط ECC بأدوات مفتوحة](https://arabroot.io/articles/%D8%AA%D8%AD%D9%82%D9%8A%D9%82-%D8%B6%D9%88%D8%A7%D8%A8%D8%B7-ecc-%D8%A8%D8%A7%D8%AF%D9%88%D8%A7%D8%AA-%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D8%A7%D9%84%D9%85%D8%B5%D8%AF%D8%B1/#lab-retention).

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

## المراجعة: السجل الذي لا يراجع يكذب

كل المخاطر في القائمة السابقة بحالة «Unreviewed»، أي لم يراجعها أحد بعد الإدخال، والأداة تعد في أعلى الصفحة المخاطر التي تحتاج معالجة والتي تحتاج مراجعة والتي تأخرت. والمراجعة في SimpleRisk خطوة مستقلة من قائمة Actions في صفحة المخاطرة، باسم Perform a Review، وفي القائمة نفسها View All Reviews لعرض المراجعات السابقة للمخاطرة، وهذا التاريخ هو ما يحتاجه المدقق عندما يسأل «متى قيمتم هذه المخاطرة آخر مرة؟».

وإيقاع المراجعة الذي اعتمدته الشركة مبني على 1-5-3 أكثر منه على التقويم: مراجعة شاملة كل ربع سنة مع التقييم الذاتي على ECC، ومراجعة فورية لأي مخاطرة يتأثر بها مشروع جديد أو تغيير جوهري أو مزود جديد. ولكي لا يعتمد هذا على الذاكرة أضاف الفريق سؤالاً إلى قالب طلب التغيير في أداة إدارة المشاريع: «هل يضيف هذا التغيير مزوداً أو يغير البنية؟ إذا نعم، أضف تقييم مخاطر قبل الموافقة».

## الواجهة العربية

في صفحة الملف الشخصي My Profile قائمة للغة، واخترنا العربية، فظهرت قائمة المخاطر كما يلي:

![صفحة مراجعة المخاطر في SimpleRisk بالواجهة العربية: القائمة الجانبية والأزرار وعناوين الأعمدة بالعربية، وبطاقات العدادات في الأعلى ما زالت بالإنجليزية، والقائمة الجانبية على اليسار](https://arabroot.io/content/images/2026/10/risk-register-07-arabic.webp)

الترجمة تشمل أغلب الواجهة، والتخطيط لا ينعكس من اليمين إلى اليسار

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

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

- **ماذا يحدث إذا نسيت أسلوب التسجيل؟** تسجل المخاطرة بأسلوب Custom بدرجة 10 وتظهر High، كما حدث لنا في المحاولة الأولى، دون أي رسالة خطأ.
- **ماذا يحدث إذا كان سيرفرك معزولاً عن الإنترنت؟** الإعداد الآلي في الصورة المصغرة ينزل مخطط قاعدة البيانات من الإنترنت في أول تشغيل، فجهز المخطط مسبقاً أو شغل الإعداد الأول على شبكة متصلة ثم انقل الـ Volume.
- **ماذا يحدث إذا كتبت فعالية المعالجة 100%؟** تصبح المخاطرة المتبقية صفراً، وتختفي من التقارير، وهي ما زالت موجودة في الواقع، لذلك اجعل منهجيتك تمنع أي فعالية أعلى من نسبة محددة دون دليل.
- **ماذا يحدث إذا حذفت المخاطرة بدل إغلاقها؟** تفقد تاريخها، والمدقق يسأل عن المخاطر المغلقة ولماذا أغلقت، فأغلق ولا تحذف.

## النسخ الاحتياطي والتحديث

كل بيانات الأداة في قاعدة MySQL، والنسخة الاحتياطية الصحيحة هي `mysqldump` من Container قاعدة البيانات بنسخة متسقة، وليس نسخ مجلد البيانات أثناء العمل. والسجل نفسه وثيقة قد تحتوي معلومات حساسة عن نقاط ضعف الشركة، فطبق على النسخ ما تطبقه على بقية النسخ، كما في [أدوات النسخ الاحتياطي](https://arabroot.io/articles/restic-%D8%A3%D9%85-borg-%D8%A3%D9%85-kopia/). أما التحديث فالشركة تصدر نسخة كل بضعة أسابيع بأرقام تاريخية مثل 20261020-001، وفي الصورة المصغرة متغير `DB_UPGRADE` يطبق ترقية مخطط قاعدة البيانات عند تغيير رقم الـ Image، فخذ نسخة احتياطية أولاً، ثم غير الرقم، ثم شغل الترقية واقرأ نتيجتها في السجل قبل أن تفتح الواجهة للمستخدمين.

## أداة واحدة للامتثال والمخاطر، أم أداتان؟

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

أما إذا كان مالكو المخاطر مديرين من الأعمال، يدخلون ليقرؤوا مخاطرهم ويوافقوا على المعالجة ويراجعوا كل ربع سنة، فالأداة المتخصصة أسهل عليهم، لأن واجهتها مبنية حول دورة حياة المخاطرة: تقديم، ثم معالجة، ثم مراجعة، وفيها عدادات واضحة لما تأخر. وهذا ما رأيناه في SimpleRisk. والثمن أنك تربط بين الأداتين يدوياً، أو بالـ API المدفوعة في SimpleRisk. وقد قررت الشركة في النهاية أن تبدأ بنموذج الهيئة في Excel لمدة ربع سنة، ثم تنقل السجل إلى وحدة المخاطر في CISO Assistant لأنها تربطه بالتدقيق مباشرة، وأبقت تجربة SimpleRisk مرجعاً لما يجب أن تفعله دورة المراجعة، وهذا قرار معقول لشركة من اثني عشر شخصاً، وقد يختلف لجهة فيها عشرات مالكي المخاطر.

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

## قائمة تحقق لسجل المخاطر

| السؤال                                           | الإجابة في قصة منصة الحجز                             |
| ------------------------------------------------ | ----------------------------------------------------- |
| هل المنهجية مكتوبة ومعتمدة قبل السجل؟            | نعم، بحدود نموذج الهيئة، مع جدول مقابلة لدرجات الأداة |
| هل لكل مخاطرة مالك من الأعمال وليس من الأمن فقط؟ | نعم، والمالك هو من يقبل أو يعالج                      |
| هل المخاطرة الأصلية والمتبقية مسجلتان معاً؟      | نعم، مع التنبيه أن المتبقية متوقعة حتى التنفيذ        |
| هل لكل معالجة مالك وموعد نهائي؟                  | نعم، وتظهر في الأداة مع حالتها                        |
| هل فعالية المعالجة مبنية على دليل؟               | تقدير حتى يصل الدليل، ثم تحدث                         |
| هل التقييم مرتبط بأحداث 1-5-3؟                   | سؤال في قالب طلب التغيير                              |
| هل شهية المخاطر مكتوبة بجمل؟                     | نعم، بالمستويات والمدد ومن يقبل                       |
| هل المخاطر المغلقة محفوظة بسبب إغلاقها؟          | نعم، بما فيها محاولة الإدخال الخاطئة                  |
| هل الالتزامات النظامية مفصولة عن المخاطر؟        | نقل البيانات للخارج التزام يعالج، وليس مخاطرة تقبل    |
| هل الأداة نفسها محمية ولها نسخة احتياطية؟        | على الشبكة الداخلية، مع mysqldump                     |

## الخلاصة

- سجل المخاطر سجل قرارات، والضابط 1-5-1 في ECC يطلب منهجية مكتوبة قبل أي سجل، و1-5-3 يربط التقييم بالمشاريع والتغييرات والمزودين الجدد.
- نموذج الهيئة في Excel بداية ممتازة، وفيه منهجية جاهزة: الاحتمال × الأثر بخمسة مستويات حدودها 3 و6 و10 و16.
- اخترنا SimpleRisk لأنه مفتوح المصدر بترخيص MPL 2.0 ويعمل على شبكتك، بينما eramba كود مفتوح للقراءة فقط ويحتاج اتصالاً بخادم الشركة، والـ API في SimpleRisk إضافة مدفوعة.
- الصورة الكاملة فشلت لأن MySQL الداخلي لم يبدأ في مهلته، والصورة المصغرة مع MySQL منفصل عملت واستغرق إعدادها نحو سبع دقائق.
- نسيان أسلوب التسجيل جعل كل المخاطر High، وطريقة Classic تساوي (الاحتمال × الأثر) × 10/25.
- المخاطرة نفسها كانت «مرتفعة» في نموذج الهيئة و«Medium» في الأداة، فاكتب منهجيتك واجعل الأداة تطابقها.

وفي المقالات التالية من القصة نصل بالضوابط والأدلة إلى التدقيق:

[![](https://arabroot.io/content/images/2026/10/evidence-collection-cover-cover.webp)دليلجمع أدلة الامتثال Evidence تلقائياً بدل لقطات الشاشةنبني جامع أدلة صغيراً يقرأ إعدادات السيرفرات عبر SSH ويحفظها بالهاش، ثم نجربه على تغيير مفاجئ ودليل معدل وجامع فقد صلاحيته بصمت.](https://arabroot.io/articles/%D8%AC%D9%85%D8%B9-%D8%A7%D8%AF%D9%84%D8%A9-%D8%A7%D9%84%D8%A7%D9%85%D8%AA%D8%AB%D8%A7%D9%84-%D8%AA%D9%84%D9%82%D8%A7%D8%A6%D9%8A%D8%A7/)[![](https://arabroot.io/content/images/2026/10/iso27001-open-source-cover-cover.webp)دليلISO 27001 بأدوات مفتوحة المصدر من المخاطر إلى التدقيقكيف تبني شركة صغيرة نظام ISO/IEC 27001 على ما بنته لضوابط ECC، من النطاق وسجل المخاطر إلى بيان قابلية التطبيق والتدقيق الداخلي.](https://arabroot.io/articles/iso-27001-%D8%A8%D8%A7%D8%AF%D9%88%D8%A7%D8%AA-%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D8%A7%D9%84%D9%85%D8%B5%D8%AF%D8%B1-%D9%85%D9%86-%D8%A7%D9%84%D9%85%D8%AE%D8%A7%D8%B7%D8%B1-%D8%A7%D9%84%D9%89-%D8%A7%D9%84%D8%AA%D8%AF%D9%82%D9%8A%D9%82/)

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

أكتوبر 2026: كتابة المقال وتجربة SimpleRisk 20261020-001 بالصورة المصغرة مع MySQL 8.4.11، وقراءة نموذج سجل المخاطر من صفحة أدوات الهيئة الوطنية للأمن السيبراني.