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

جدول المحتويات

جدول المحتويات

كيف تعيد السحابة تشكيل فهم تقنية المعلومات

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

الطبقات المتعددة للمسؤولية


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

تحدي الوضوح


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

  • طبقة التطبيق: برامج المحاسبة (مثل NetSuite أو Xero) التي يديرها موفر البرنامج
  • طبقة المنصة: خدمات قواعد البيانات والتطبيقات (مثل AWS RDS) التي يديرها موفر السحابة
  • طبقة البنية التحتية: الخوادم الافتراضية والشبكات (مثل EC2) تحت سيطرة موفر السحابة
  • طبقة الأمان: هوية المستخدمين وإدارة الوصول قد تكون مع موفر ثالث (مثل Active Directory)
  • طبقة البيانات: قد تكون البيانات مخزنة في مناطق جغرافية متعددة لأغراض النسخ الاحتياطي والأداء

تقييم مخاطر نظام تقنية المعلومات المعقد

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

مخاطر جديدة خاصة بالسحابة


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

إطار تقييم المخاطر


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

استراتيجية فحص الضوابط السحابية

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

تطبيق معيار المراجعة 402


معيار المراجعة 402 (اعتبارات المراجعة المتعلقة بالكيان الذي يستخدم منظمة خدمة) يصبح حاسماً في البيئة السحابية. الفقرة 402.09 تتطلب من المراجع الحصول على فهم لطبيعة الخدمات المقدمة من منظمة الخدمة وأهميتها للكيان.
تحديد منظمات الخدمة الحاسمة: ليست كل الخدمات السحابية لها نفس الأهمية للتقارير المالية. موفر استضافة البريد الإلكتروني ليس منظمة خدمة من منظور معيار المراجعة 402، لكن موفر برنامج المحاسبة السحابية هو كذلك.
الحصول على تقارير منظمة الخدمة: معيار المراجعة 402.17 ينص على أنه عندما يستخدم المراجع تقرير Type II لمنظمة خدمة، يجب تقييم ما إذا كان التقرير يوفر أدلة مراجعة كافية ومناسبة.
المشكلة العملية هي أن العديد من موفري الخدمات السحابية يقدمون تقارير SOC 2 لكن ليس تقارير SOC 1. تقارير SOC 2 تركز على الأمان والتوفر، بينما تقارير SOC 1 تركز على الضوابط ذات الصلة بالتقارير المالية. للمراجعة المالية، تحتاج تقارير SOC 1.

استراتيجية الضوابط المختلطة


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

مثال عملي: مراجعة نظام ERP سحابي

شركة الخليج للتوزيع ذ.م.م. هي شركة توزيع إماراتية بإيرادات سنوية 85 مليون درهم. انتقلت الشركة من نظام SAP محلي إلى NetSuite السحابي في يناير 2024. النظام الجديد يتضمن:

الخطوة 1: تحديد تدفق المعاملات


توثيق ورقة العمل: "خريطة تدفق البيانات - النظام السحابي"

الخطوة 2: تقييم مخاطر كل تكامل


توثيق ورقة العمل: "تقييم مخاطر التكامل"
تكامل Shopify-NetSuite: مخاطر عالية. إذا فشلت المزامنة، المبيعات قد لا تُسجل. لا يوجد ضوابط تحقق تلقائية.
تكامل نظام المستودعات: مخاطر متوسطة. التأخير في التحديث قد يؤثر على دقة المخزون، لكن التأثير على الإيرادات محدود.
Azure AD: مخاطر عالية. إذا تعطل، لا أحد يمكنه الوصول إلى النظام. ضوابط الوصول حاسمة لمنع التلاعب.

الخطوة 3: تصميم إجراءات المراجعة


توثيق ورقة العمل: "إجراءات مراجعة النظام السحابي"
للتكاملات عالية المخاطر:
للوصول والأمان:

الخطوة 4: تنفيذ الاختبارات


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

  • NetSuite ERP (مستضاف على Oracle Cloud Infrastructure)
  • تكامل مع Shopify للمبيعات عبر الإنترنت
  • تكامل مع نظام إدارة المستودعات من طرف ثالث
  • Azure Active Directory لإدارة هوية المستخدمين
  • المبيعات عبر الإنترنت: الطلبات تُسجل في Shopify → تتزامن تلقائياً مع NetSuite كل 15 دقيقة → تُرسل للمستودع عبر API
  • المبيعات المباشرة: تُسجل مباشرة في NetSuite من قبل فريق المبيعات
  • المشتريات: طلبات الشراء تُنشأ في NetSuite → تُرسل عبر البريد الإلكتروني للموردين → الفواتير تُسجل يدوياً في NetSuite
  • المخزون: التحديثات تأتي من نظام إدارة المستودعات كل ساعة → تُطبق على NetSuite تلقائياً
  • طلب تقرير SOC 1 Type II من NetSuite وShopify
  • فحص سجلات المزامنة لشهر عينة كامل
  • مقارنة عينة من طلبات Shopify مع السجلات في NetSuite
  • اختبار ضوابط استثناء المزامنة: ماذا يحدث عندما تفشل؟
  • طلب تقرير SOC 2 Type II من Oracle Cloud Infrastructure
  • مراجعة إعدادات المستخدمين في Azure AD
  • اختبار إجراءات إضافة/حذف المستخدمين
  • فحص سجلات الوصول للمستخدمين المميزين
  • NetSuite قدمت تقرير SOC 1، لكنه لا يغطي التكاملات مع أنظمة خارجية
  • Shopify لا تقدم تقارير SOC 1، فقط SOC 2
  • وُجدت 3 حالات فشل مزامنة في شهر سبتمبر، لم تُكتشف لمدة 48 ساعة
  • 2 مستخدم لديهم وصول إداري لا يحتاجونه حسب أوصاف وظائفهم

قائمة مراجعة عملية للمراجعة السحابية

  • حدد كل موفري الخدمة السحابية الذين يتعاملون مع البيانات المالية، ليس فقط موفر المحاسبة الرئيسي.
  • اطلب تقارير SOC 1 Type II من كل موفر خدمة حاسم. إذا لم تكن متاحة، وثّق هذا كقيد على نطاق المراجعة.
  • ارسم خريطة تدفق البيانات من المصدر إلى البيانات المالية النهائية، مع تحديد كل نقطة يمكن أن تحدث فيها أخطاء.
  • اختبر ضوابط التكامل بين الأنظمة، ليس فقط الضوابط داخل كل نظام منفرد.
  • راجع ضوابط الوصول عبر كل المنصات، مع التركيز الخاص على المستخدمين الذين لديهم وصول إداري.
  • أنشئ خطة طوارئ للوصول للبيانات إذا توقف موفر خدمة رئيسي عن العمل أثناء المراجعة.

الأخطاء الشائعة في مراجعة الأنظمة السحابية

  • افتراض أن تقرير SOC 2 كافٍ لأغراض المراجعة المالية: تقارير SOC 2 تركز على الأمان، ليس على الضوابط المالية. تحتاج تقارير SOC 1 للمراجعة.
  • عدم اختبار التكاملات بين الأنظمة: الأخطاء غالباً ما تحدث عند نقاط التكامل، ليس داخل الأنظمة الفردية نفسها.
  • الاعتماد كلياً على ضوابط موفر الخدمة دون التحقق: حتى مع تقارير SOC 1، يجب فهم كيف تطبق هذه الضوابط على وضع العميل المحدد.
  • إغفال ضوابط المستخدم التكميلية (CUEC) المذكورة في تقرير منظمة الخدمة بموجب معيار المراجعة 402.16: تقرير SOC 1 لـ NetSuite قد يفترض أن العميل ينفذ ضوابط معينة مثل مراجعة سجل الدخول الإداري شهرياً أو إلغاء حسابات الموظفين المغادرين خلال 24 ساعة. إذا لم ينفذ شركة الخليج للتوزيع ذ.م.م. هذه الضوابط التكميلية، فإن الاعتماد على ضوابط موفر الخدمة غير مبرر، حتى لو كان التقرير نظيفاً.

محتوى ذات صلة

---

احصل على رؤى تدقيق عملية أسبوعياً.

ليست نظريات امتحانات. فقط ما يجعل عمليات التدقيق أسرع.

أكثر من 290 دليلاً منشوراً20 أداة مجانيةصُمم بواسطة مراجع حسابات ممارس

بدون إزعاج. نحن مراجعون، لا مسوّقون.