ما تغيره DORA في تقييم المراجع لمخاطر تكنولوجيا المعلومات
تنطبق DORA على أكثر من 22,000 كيان مالي في الاتحاد الأوروبي: بنوك، شركات تأمين، شركات استثمار، مقدمو خدمات دفع. اللائحة تفرض خمس ركائز أساسية.
إدارة مخاطر ICT بموجب المواد 5 إلى 15 تشكّل العمود الفقري. ثم الحوكمة والتنظيم (المواد 16 إلى 20)، والحماية والوقاية (المواد 21 إلى 23). تضيف DORA ركيزتين تُحدثان الأثر الأكبر على عمل المراجع: إدارة الحوادث والإبلاغ عنها (المواد 24 إلى 27)، واختبار المرونة التشغيلية (المواد 28 إلى 35).
ما يحدث فعلياً في الميدان مختلف تماماً. أغلب الكيانات التي تعاملت معها تعامل DORA كمشروع امتثال لمرة واحدة: تُعد الوثائق، تعتمدها الإدارة، ثم تُركن في خزانة رقمية. من وجهة نظري المتواضعة، هذا يخلق مخاطر رقابة أعلى وليس أقل، لأن المراجع قد يقبل إطاراً مكتوباً دون أن يختبر ما إذا كان يعمل فعلياً.
كيف تؤثر DORA على إجراءات المراجعة بموجب معيار المراجعة 315
يتطلب معيار المراجعة الدولي (ISA) 315.13 تقييم أنظمة الرقابة الداخلية للعميل بما يشمل ضوابط تكنولوجيا المعلومات. مع DORA، تصبح هذه الضوابط أكثر تعقيداً وأكثر قابلية للاختبار في الوقت ذاته.
المادة 8 من DORA تُلزم الكيان المالي بإطار لإدارة مخاطر ICT يتضمن استراتيجيات وسياسات وإجراءات وبروتوكولات حماية. يفترض أن يكون هذا الإطار متناسباً مع حجم الكيان وطبيعة أنشطته. لكن ماذا يعني "متناسب" عملياً؟ هنا تبدأ المنطقة الرمادية.
شركة استثمار تدير 300 مليون يورو ليست بنكاً نظامياً. لكنها ليست مكتب صرافة أيضاً. لاحظت أن كثيراً من الكيانات المتوسطة تستورد إطار مخاطر ICT من كيان أكبر حجماً دون تعديل. النتيجة: مستندات ضخمة لا تعكس الواقع التشغيلي. إجراءات صورية لا تصمد أمام سؤال واحد محدد عن كيفية التعامل مع حادث أمني فعلي.
تحديد مخاطر الأخطاء الجوهرية في ظل DORA
ISA 315.25 يتطلب تحديد مخاطر الأخطاء الجوهرية على مستوى القوائم المالية ومستوى التأكيدات. DORA تضيف بُعداً جديداً لهذا التقييم في منطقتين تحديداً.
الأولى: الأنظمة الحرجة. المادة 10 تُلزم الكيان بتحديد أنظمة ICT الحرجة وتصنيفها. يحتاج المراجع لفهم هذا التصنيف لأنه يحدد أي الأنظمة تتطلب ضوابط إضافية. إذا صنّف العميل نظام إعداد التقارير المالية كغير حرج، فهذا في حد ذاته مؤشر خطر. هل يبرر العميل هذا التصنيف أم يتبنّاه فقط لتخفيف عبء الامتثال؟
الثانية: مخاطر مقدمي الخدمات الخارجية. المواد 30 إلى 34 تضع قواعد صارمة لإدارة هذه المخاطر. ما رأيته كثيراً هو التالي: العميل يعتمد على مقدم خدمة خارجي لاستضافة البيانات أو معالجة المدفوعات، ويحتفظ بنسخة من العقد، لكنه لا يملك آلية مراقبة مستمرة. العقد يبقى حبراً على ورق ما لم يقترن بمراقبة فعلية.
اختبار الضوابط: ما يتطلبه ISA 330 بعد DORA
ISA 330.8 يتطلب تصميم اختبارات ضوابط عندما يعتمد المراجع على فعاليتها. بعد دخول DORA حيز التنفيذ، يحتاج المراجع لتوسيع نطاق هذه الاختبارات لتشمل أربعة محاور:
- فعالية إطار إدارة مخاطر ICT (ليس وجوده فحسب بل تشغيله الفعلي) - كفاية إجراءات إدارة الحوادث والإبلاغ بموجب المواد 17 إلى 19 - منطق تصنيف الأنظمة الحرجة ومدى اتساقه مع الواقع التشغيلي - ضوابط مراقبة مقدمي الخدمات الخارجية (وليس العقود فقط)
أرى أن أكبر خطأ يقع فيه المراجع هو قبول وجود الإطار كدليل على فعاليته. DORA تفرض اختبارات مرونة تشغيلية (المواد 25 و26) وتقييمات لمقدمي الخدمات. هذه المستندات متاحة الآن للمراجع. اطلبها.
تطبيق عملي: شركة النخبة للاستثمار
شركة النخبة للاستثمار مقرها الرياض وتدير أصولاً بقيمة 380 مليون يورو لعملاء أوروبيين. تخضع لمتطلبات DORA. سأعرض كيف دمجت هذه المتطلبات في تقييم المخاطر.
بدأت بطلب إطار إدارة مخاطر ICT المحدّث وفقاً للمادة 8. أرسلت الشركة مستنداً من 47 صفحة. مشكلته: كان نسخة معدّلة من إطار بنك إقليمي كبير، مع حذف الأقسام الخاصة بالعمليات المصرفية. الاستراتيجيات المذكورة لم تكن متسقة مع البنية التقنية الفعلية للشركة. وثّقت هذا كنقطة ضعف في تصميم الرقابة.
ثم طلبت قائمة الأنظمة المصنفة كحرجة بموجب المادة 10. الشركة حددت نظامين: إدارة الاستثمارات وإعداد التقارير التنظيمية. لم تُدرج نظام إدارة المخاطر. سألت لماذا. الإجابة: "لأنه يعمل على خادم داخلي وليس سحابياً." هذا المبرر لا يتوافق مع معايير التصنيف في المادة 10 التي تعتمد على الأهمية التشغيلية وليس على موقع الاستضافة. أضفت النظام الثالث وعدّلت تقييم مخاطر الرقابة.
الخطوة الثالثة كانت مراجعة إدارة مخاطر مقدم خدمة استضافة البيانات. وجدت عقداً يتضمن بنود DORA الأساسية. لكن عند السؤال عن آخر تقييم مخاطر أجرته الشركة لمقدم الخدمة، لم يكن هناك تقييم منذ توقيع العقد قبل 14 شهراً. العقد وحده لا يكفي بموجب المواد 30 إلى 34 التي تتطلب مراقبة مستمرة.
راجعت بعد ذلك سجلات الحوادث الأمنية. لم تحدث حوادث جوهرية خلال الفترة. لكن إجراءات الإبلاغ المعتمدة من الإدارة لم تحدد مهلاً زمنية واضحة للإبلاغ عن الحوادث الجوهرية كما تتطلب المادة 19. هذا خلل في التصميم وليس في التشغيل.
أخيراً، طلبت نتائج اختبار المرونة التشغيلية. الشركة نفّذت اختباراً في ديسمبر 2024. النتائج لم تحدد نقاط ضعف جوهرية في الأنظمة. لكن الاختبار اقتصر على سيناريو واحد (انقطاع الخادم الرئيسي) ولم يشمل سيناريو اختراق من طرف ثالث. بالنسبة لكيان يعتمد على مقدم خدمة خارجي رئيسي، هذا قصور في نطاق الاختبار.
المحصلة: قدّرت مخاطر الرقابة لأنظمة ICT بمستوى "متوسط" وليس "منخفض" رغم وجود إطار DORA مكتوب. لو قبلت الوثائق كما وردت دون اختبار، لكان التقدير "منخفض" وهو تقدير لا يعكس الواقع.
ست خطوات لدمج DORA في تقييم المخاطر
1. اطلب إطار إدارة مخاطر ICT المحدّث وتأكد من اعتماد مجلس الإدارة له بموجب المادة 6 (الاعتماد الشكلي دون مناقشة فعلية يستحق التوثيق كملاحظة)
2. احصل على قائمة الأنظمة المصنفة كحرجة بموجب المادة 10 واسأل عن منطق التصنيف (إذا استُبعد نظام يؤثر على التقارير المالية، وثّق السبب)
3. راجع عقود مقدمي الخدمات الخارجية وآليات المراقبة المستمرة بموجب المواد 30 إلى 34 (وجود العقد لا يعني وجود مراقبة)
4. اختبر إجراءات إدارة الحوادث والإبلاغ بموجب المواد 17 إلى 19 وتأكد من تحديد مهل زمنية واضحة
5. اطلب نتائج اختبارات المرونة التشغيلية وقيّم مدى كفاية السيناريوهات المختبرة
6. وثّق أثر كل نتيجة على تقدير مخاطر الرقابة لكل دورة جوهرية مرتبطة بأنظمة ICT
أربعة أخطاء يرتكبها المراجعون في تقييم امتثال DORA
قبول الإطار المكتوب كدليل على الامتثال دون اختبار تشغيلي هو الخطأ الأول والأخطر. DORA ليست مجرد سياسة مكتوبة. هي التزام تشغيلي يتطلب أدلة قابلة للاختبار.
الخطأ الثاني: التعامل مع مخاطر مقدمي الخدمات الخارجية كموضوع ثانوي. في كيان مالي يعتمد على مقدم خدمة خارجي لاستضافة بياناته أو معالجة مدفوعاته، هذا المقدم جزء من بيئة الرقابة الداخلية وليس خارجها.
ثالثاً: عدم تحديث إجراءات اختبار الضوابط لتعكس متطلبات DORA. الإجراءات القديمة تختبر وجود الضوابط. DORA تتطلب اختبار فعاليتها واختبار مرونتها أمام سيناريوهات محددة.
الخطأ الرابع (وهنا أختلف مع الممارسة السائدة): كثير من المراجعين يعتبرون DORA مسؤولية فريق تكنولوجيا المعلومات حصرياً ولا يدمجونها في تقييم المخاطر العام. لكن عندما يؤثر خلل في نظام ICT حرج على دقة القوائم المالية، يصبح الموضوع مرتبطاً مباشرة بمخاطر الأخطاء الجوهرية بموجب ISA 315.25. فصل المسارين ليس تخصصاً بل ثغرة.
هناك وجهة نظر معاكسة يطرحها بعض الزملاء في المكاتب الكبيرة: أن المراجع المالي لا يملك الكفاءة التقنية لتقييم ضوابط ICT وأن هذا العمل يجب أن يُترك لخبير تكنولوجيا المعلومات بالكامل. ISA 620 يسمح بالاعتماد على خبير. لكنه لا يعفي المراجع من فهم طبيعة العمل الذي يؤديه الخبير ومن تقييم مدى كفايته. المراجع الذي يقبل تقرير خبير ICT دون أن يفهم ما يعنيه تصنيف نظام كحرج بموجب المادة 10 يتعامل مع التقرير كصندوق أسود. وهذا لا يتوافق مع متطلبات ISA 620.12.
المحتوى ذو الصلة
- مسرد: إدارة مخاطر تكنولوجيا المعلومات - أداة: حاسبة تقييم المخاطر - مقال: معيار المراجعة 315 وتقييم أنظمة الرقابة الداخلية