عندما تتقدم شركة تقنية مالية سعودية للحصول على ترخيص من البنك المركزي السعودي أو تخضع لأول تقييم للأمن السيبراني وفق إطار ساما، تظهر فجوة متكررة: مكتبة السياسات خفيفة ومرنة ومتوافقة مع ثقافة التطوير السريع، لكنها تفتقر إلى بنود التحكم في التغيير والاختبار والموافقة التي يتوقعها الإطار التنظيمي في دورة حياة تطوير سياسات شركات التقنية المالية إطار ساما. البنوك التقليدية، رغم ثقل إجراءاتها، نادراً ما تواجه هذه الفجوة لأن سياساتها بُنيت أصلاً على افتراض الضوابط الصارمة. شركات التقنية المالية، على النقيض، تبني سياساتها على افتراض السرعة والاستقلالية، وتكتشف متأخرة أن الإطار التنظيمي يطلب ضوابط محددة لا يمكن تجاهلها.
هذا المقال يحدد البنود الخمسة الأكثر غياباً في سياسات شركات التقنية المالية السعودية، ويوضح كيفية دمجها في بيئة تطوير مرنة دون التضحية بالسرعة أو الابتكار.
الفجوة الأساسية: سياسات مرنة في بيئة تنظيمية صارمة
شركات التقنية المالية السعودية تتبنى منهجيات Agile وDevOps وتطوير مستمر، وتكتب سياساتها لتعكس هذه الثقافة: مبادئ عامة، مسؤوليات واسعة، ثقة في الفرق الهندسية. هذا النهج يعمل جيداً في بيئات الشركات الناشئة، لكنه يصطدم بتوقعات البنك المركزي السعودي عندما يراجع الإطار التنظيمي للأمن السيبراني.
الإطار يتوقع ضوابط قابلة للقياس والتدقيق في كل مرحلة من مراحل التطوير: من يوافق على ماذا، متى يتم الاختبار الأمني، كيف يتم التراجع عن التغييرات الفاشلة، وما هي العتبات الزمنية لمعالجة الثغرات. البنوك التقليدية تملك هذه البنود لأنها ورثت ثقافة الضوابط من عقود من التنظيم المصرفي. شركات التقنية المالية، التي بُنيت على السرعة، غالباً ما تفتقدها تماماً.
النتيجة: في أول مراجعة، يطلب المقيّم أو الجهة التنظيمية رؤية سياسة التطوير الآمن، ويجد مبادئ عامة عن "الأمان في كل مرحلة" و"المسؤولية المشتركة"، لكن لا يجد إجابات محددة على أسئلة مثل: من يوافق على نشر كود إلى الإنتاج؟ ما هي عتبة التغطية في مراجعة الكود؟ كم من الوقت لديكم لمعالجة ثغرة حرجة؟
البنود الخمسة المفقودة
بناءً على مراجعات متكررة لسياسات شركات التقنية المالية السعودية، تظهر خمسة بنود بشكل ثابت كنقاط ضعف في مراجعات إطار ساما:
1. بوابات الأمان في دورة السبرينت
المشكلة: سياسات شركات التقنية المالية تذكر أن "الأمان جزء من كل سبرينت"، لكنها لا تحدد متى وكيف يتم التحقق من الأمان قبل إغلاق السبرينت أو نقل الميزة إلى المرحلة التالية.
ما يتوقعه الإطار: بوابة أمنية واضحة—نقطة توقف إلزامية—قبل الانتقال من التطوير إلى الاختبار، ومن الاختبار إلى الإنتاج. يجب أن تحدد السياسة: من يقوم بالمراجعة الأمنية، ما هي المعايير (مثلاً: لا ثغرات حرجة مفتوحة، اكتمال فحص SAST وSAST)، ومن يملك صلاحية المنع.
كيفية الدمج دون كسر السرعة: دمج فحوصات آلية في خط الأنابيب (pipeline): فحص ثابت للكود عند كل دفع، فحص ديناميكي في بيئة التجهيز، ومراجعة بشرية خفيفة (checklist) قبل النشر. البوابة لا تعني لجنة تجتمع لأسبوع؛ تعني معايير واضحة وأدوات آلية توقف النشر إذا لم تُستوفَ.
2. عتبات مراجعة الكود وتغطية الفحص
المشكلة: السياسة تقول "يجب مراجعة الكود قبل الدمج"، لكنها لا تحدد كم من المراجعين مطلوب، ما هي نسبة التغطية المطلوبة، أو ما إذا كانت المراجعة إلزامية لكل تغيير أم فقط للتغييرات الكبيرة.
ما يتوقعه الإطار: عتبات قابلة للقياس: على الأقل مراجع واحد لكل طلب دمج، تغطية اختبار لا تقل عن نسبة محددة للكود الحرج (مثلاً: وحدات المصادقة والدفع)، وتوثيق للمراجعة في نظام إدارة النسخ.
كيفية الدمج دون كسر السرعة: استخدام أدوات مراجعة الكود المدمجة في Git (مثل GitHub أو GitLab) مع قواعد فرع محمية: لا دمج بدون موافقة مراجع واحد على الأقل، ولا دمج إذا فشلت الاختبارات الآلية. هذا لا يبطئ التطوير؛ بل يجعل المراجعة جزءاً من سير العمل اليومي.
3. موافقة النشر إلى الإنتاج وفصل الصلاحيات
المشكلة: في بيئات DevOps الحديثة، المطورون غالباً يملكون صلاحية النشر المباشر إلى الإنتاج. السياسة لا تذكر من يوافق، أو تفترض أن الموافقة ضمنية إذا نجحت الاختبارات الآلية.
ما يتوقعه الإطار: فصل واضح بين من يطور ومن يوافق على النشر إلى الإنتاج، خاصة للتغييرات التي تمس البيانات الحساسة أو الوظائف المالية الحرجة. يجب أن تحدد السياسة دور الموافق (مثلاً: مدير هندسي أو فريق أمن المعلومات) وتوثيق الموافقة.
كيفية الدمج دون كسر السرعة: استخدام سير عمل موافقة آلي في أداة CI/CD: التغييرات الصغيرة (مثل إصلاحات الأخطاء) تُنشر تلقائياً بعد اجتياز الاختبارات؛ التغييرات الكبيرة (ميزات جديدة، تعديلات على قاعدة البيانات) تتطلب موافقة يدوية بنقرة واحدة من شخص معتمد. هذا يضيف ثوانٍ، لا ساعات.
4. إجراءات التراجع وخطط الاستعادة
المشكلة: السياسة تذكر أن "يجب اختبار التراجع"، لكنها لا تحدد متى يتم التراجع، من يقرر، وكم من الوقت يجب أن يستغرق.
ما يتوقعه الإطار: إجراء واضح للتراجع عن النشر الفاشل: معايير التراجع (مثلاً: زيادة معدل الأخطاء بنسبة معينة، فشل فحص صحة الإنتاج)، من يملك صلاحية القرار، والحد الأقصى للوقت المسموح لاستعادة الخدمة.
كيفية الدمج دون كسر السرعة: اعتماد استراتيجيات نشر حديثة مثل blue-green deployment أو canary releases، حيث يمكن التراجع الفوري بتحويل حركة المرور. توثيق هذه الاستراتيجيات في السياسة، وتحديد عتبات آلية للتراجع (مثلاً: إذا تجاوز معدل الأخطاء 5% في أول دقيقتين، تراجع تلقائياً).
5. اتفاقيات مستوى الخدمة لمعالجة الثغرات
المشكلة: السياسة تقول "يجب معالجة الثغرات بسرعة" أو "حسب الخطورة"، لكنها لا تحدد أرقاماً: كم يوماً لمعالجة ثغرة حرجة؟ من يوافق على التأجيل؟
ما يتوقعه الإطار: جدول زمني واضح لمعالجة الثغرات حسب التصنيف (مثلاً: حرجة خلال 7 أيام، عالية خلال 30 يوماً، متوسطة خلال 90 يوماً)، وإجراء لتصعيد الثغرات التي تتجاوز المهلة.
كيفية الدمج دون كسر السرعة: دمج إدارة الثغرات في نظام تتبع المهام (مثل Jira)، مع حقول إلزامية للخطورة والمهلة. إعداد تنبيهات آلية قبل انتهاء المهلة، وتقرير شهري للإدارة عن الثغرات المتأخرة. هذا لا يبطئ التطوير؛ بل يضمن أن الثغرات لا تُنسى.
لماذا البنوك لا تواجه هذه الفجوة
البنوك التقليدية السعودية نادراً ما تفتقد هذه البنود لأن سياساتها بُنيت على افتراض الضوابط الصارمة منذ البداية. لديها لجان تغيير، وإجراءات موافقة متعددة المستويات، وجداول زمنية محددة لكل شيء. هذه الضوابط قد تكون ثقيلة وبطيئة، لكنها تغطي تماماً ما يتوقعه إطار ساما.
شركات التقنية المالية، على النقيض، بُنيت على ثقافة مختلفة: الثقة في الفرق، الاستقلالية، السرعة. هذه ثقافة قيّمة، لكنها تحتاج إلى ترجمة إلى لغة الضوابط القابلة للتدقيق عندما يتعلق الأمر بالامتثال التنظيمي.
الخبر الجيد: يمكن دمج هذه البنود دون التضحية بالسرعة. الضوابط الحديثة آلية، مدمجة في الأدوات، وشفافة. لا تحتاج إلى لجان أو اجتماعات؛ تحتاج إلى قواعد واضحة وأدوات تطبقها.
كيفية سد الفجوة: من المبادئ إلى الإجراءات
لسد هذه الفجوة، تحتاج شركات التقنية المالية إلى إعادة كتابة أقسام محددة من سياسة التطوير الآمن، مع التركيز على التحول من المبادئ العامة إلى الإجراءات القابلة للقياس:
قبل: "يجب مراجعة الكود قبل الدمج لضمان الجودة والأمان."
بعد: "كل طلب دمج يتطلب موافقة مراجع واحد على الأقل من فريق هندسي آخر. لا يُسمح بالدمج إذا فشلت الاختبارات الآلية أو إذا كانت تغطية الاختبار للكود الحرج أقل من 80%. يتم توثيق المراجعة في نظام إدارة النسخ."
قبل: "يجب معالجة الثغرات الأمنية بسرعة حسب خطورتها."
بعد: "الثغرات الحرجة (CVSS 9.0 أو أعلى) يجب معالجتها خلال 7 أيام من الاكتشاف. الثغرات العالية (CVSS 7.0-8.9) خلال 30 يوماً. أي تأخير يتطلب موافقة كتابية من مدير أمن المعلومات وتوثيق المبرر وخطة المعالجة البديلة."
هذا التحول من "يجب" إلى "كيف ومتى ومن" هو ما يحول السياسة من وثيقة مبادئ إلى أداة امتثال قابلة للتدقيق.
الخطوات العملية لتحديث السياسات
- مراجعة السياسات الحالية مقابل إطار ساما: قراءة متطلبات الإطار التنظيمي للأمن السيبراني الصادر عن البنك المركزي السعودي، وتحديد كل متطلب يتعلق بدورة حياة التطوير، وفحص ما إذا كانت السياسة الحالية تجيب عليه بوضوح.
- تحديد الفجوات في البنود الخمسة: فحص كل بند من البنود الخمسة المذكورة أعلاه، وتحديد ما إذا كانت السياسة تحتوي على إجراءات محددة أم مجرد مبادئ عامة.
- كتابة إجراءات قابلة للقياس: لكل فجوة، كتابة إجراء يحدد: من المسؤول، ما هي المعايير القابلة للقياس، متى يتم التنفيذ، وكيف يتم التوثيق.
- دمج الإجراءات في الأدوات: التأكد من أن كل إجراء مدعوم بأداة أو سير عمل آلي: قواعد في Git، بوابات في CI/CD، تنبيهات في نظام إدارة الثغرات.
- مراجعة مع فريق الهندسة: التأكد من أن الإجراءات الجديدة واقعية وقابلة للتطبيق، وأنها لا تتعارض مع سير العمل اليومي. إذا كان الإجراء يبطئ التطوير بشكل ملحوظ، إعادة تصميمه ليكون أكثر آلية.
- توثيق الأدلة: إعداد سجلات وتقارير تثبت الامتثال: سجلات مراجعة الكود، تقارير تغطية الاختبار، سجلات الموافقة على النشر، تقارير معالجة الثغرات. هذه الأدلة ستكون مطلوبة في أول مراجعة تنظيمية.
الانتقال من الفجوة إلى الامتثال
سد هذه الفجوة لا يعني التخلي عن المنهجيات المرنة أو التحول إلى بيروقراطية بنكية. يعني ترجمة ثقافة السرعة والاستقلالية إلى لغة الضوابط القابلة للتدقيق. الضوابط الحديثة آلية، مدمجة، وشفافة؛ لا تبطئ التطوير، بل تجعله أكثر أماناً وقابلية للتدقيق.
شركات التقنية المالية السعودية التي تسد هذه الفجوة مبكراً—قبل أول مراجعة تنظيمية—تتجنب التأخيرات المكلفة في الحصول على الترخيص، وتبني أساساً قوياً للنمو المستقبلي. تلك التي تتجاهلها تكتشف الفجوة في أسوأ وقت ممكن: عندما يطلب المقيّم أدلة لا تملكها.
كيف يمكن لسيزو للاستشارات المساعدة
سيزو للاستشارات تقدم خدمة تطوير السياسات، وهي تطوير شامل لسياسات وإجراءات الأمن السيبراني وفق الأطر التنظيمية السعودية. الخدمة تشمل مراجعة السياسات الحالية مقابل متطلبات إطار ساما، تحديد الفجوات في البنود الحرجة مثل التطوير الآمن وإدارة التغيير، وكتابة إجراءات محددة وقابلة للقياس تتوافق مع بيئة العمل الفعلية للشركة.
إذا كنت تستعد للحصول على ترخيص من البنك المركزي السعودي أو لأول تقييم للأمن السيبراني، وتريد التأكد من أن سياساتك تغطي البنود الحرجة التي يتوقعها الإطار التنظيمي دون التضحية بسرعة التطوير، تواصل مع سيزو للاستشارات لمناقشة كيفية بناء مكتبة سياسات قابلة للتدقيق ومتوافقة مع ثقافة الابتكار.
