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

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

لماذا تحتاج CUECs لاختبار الفترة الكاملة {#why-full-period}

تختلف الضوابط المحوسبة العامة عن ضوابط التطبيق التلقائية. ضابط التطبيق التلقائي (مثل فحص الائتمان التلقائي) يعمل بنفس الطريقة في كل مرة يُستدعى فيها. إذا عمل في مارس ونوفمبر، فهو عمل طوال السنة.
الضوابط المحوسبة العامة تحكم البيئة التي تعمل فيها تلك الضوابط التلقائية. إدارة كلمات المرور، ضوابط الوصول للمستخدمين، أمان قاعدة البيانات، النسخ الاحتياطية، إعدادات الشبكة - هذه كلها قد تتغير خلال السنة. التغيير في CUEC قد يعني أن ضابط التطبيق الذي عمل في يناير لم يعد فعّالاً في سبتمبر.
يحدد معيار المراجعة 315.26 أن المراجع يجب أن يفهم كيف عملت الضوابط "خلال الفترة." ليس في نقطة زمنية واحدة. خلال الفترة بأكملها. هذا يعني أن اختبار CUECs في 31 ديسمبر فقط لا يكفي للاعتماد على الضوابط التي تأثرت بتلك CUECs طوال يناير حتى نوفمبر.

ما يتطلبه معيار المراجعة 330.8 فعلياً


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

  • الاستمرارية: هل بقي الضابط في مكانه طوال الفترة؟
  • الاتساق: هل عمل بنفس الطريقة طوال الفترة؟
  • التوقيت: متى حدثت أي تغييرات، وكيف تؤثر على فترة الاعتماد؟

كيف تعمل CUECs عبر الوقت {#how-cuecs-work}

الضوابط المحوسبة العامة تعمل بطرق مختلفة عبر الوقت. فهم هذه الطرق يحدد كيفية اختبارها.

الضوابط المستمرة


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

الضوابط الدورية


CUECs أخرى تعمل في دورات:
هذه تحتاج اختبار عبر دورات متعددة. إذا كان النظام يراجع كلمات المرور كل 90 يوماً، اختبر مراجعات من Q1 وQ2 وQ3 وQ4. اختبار مراجعة Q4 فقط لا يخبرك شيئاً عن كيف عملت المراجعات في بقية السنة.

الضوابط المتجاوبة


بعض CUECs تتفاعل مع الأحداث:
هذه تحتاج اختبار الاستجابة والتوقيت. كم يستغرق قفل الحساب؟ هل التنبيه يصل للشخص الصحيح؟ هل التوقيت التلقائي يحدث في الوقت المحدد؟

  • تشفير قاعدة البيانات
  • بنية الشبكة الأساسية
  • إعدادات النظام الرئيسية
  • مراجعة كلمات المرور (كل 90 يوماً)
  • مراجعة وصول المستخدمين (شهرياً)
  • اختبار النسخ الاحتياطية (أسبوعياً)
  • مراجعة سجلات النظام (يومياً)
  • قفل الحسابات بعد محاولات تسجيل دخول فاشلة
  • تنبيهات عندما يحاول شخص الوصول لبيانات حساسة
  • إيقاف المستخدمين المنتهيي الصلاحية تلقائياً

تصميم اختبارات الفترة الكاملة {#designing-tests}

تصميم اختبارات CUECs للفترة الكاملة يتطلب التفكير في ثلاثة أبعاد: التوقيت والتكرار والوثائق.

اختيار نقاط الاختبار


بدلاً من اختبار في نقطة واحدة في نهاية السنة، اختر نقاط اختبار تغطي السنة كاملة:
للضوابط المستمرة:
للضوابط الدورية:
للضوابط المتجاوبة:

طرق الاختبار


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

التوثيق للفترة الكاملة


معيار المراجعة 230.8 يتطلب توثيق كافٍ لفهم طبيعة وتوقيت ونطاق إجراءات المراجعة. للضوابط المحوسبة العامة، هذا يعني:
توثيق التوقيت:
توثيق النطاق:
توثيق الطبيعة:
  • نقطة بداية (يناير أو فبراير)
  • نقطة وسط (يونيو أو يوليو)
  • نقطة نهاية (نوفمبر أو ديسمبر)
  • أي توقيت معروف للتغييرات الرئيسية
  • مثال واحد من كل دورة (إذا كانت شهرية، اختبر 12 مثال)
  • أو عينة تمثيلية إذا كانت الدورات كثيرة (اختبر 4 من أصل 52 نسخة احتياطية أسبوعية)
  • اختبر الاستجابة في فترات مختلفة
  • تأكد من أن الضابط يعمل تحت ضغوط مختلفة (بداية السنة، موسم التدقيق، فترات الذروة)
  • سجلات النشاط
  • تقارير الاستثناءات
  • سجلات التغيير
  • محاضر اجتماعات المراجعة
  • متى اختُبر كل ضابط
  • أي تغييرات حدثت خلال السنة ومتى
  • فترات الاعتماد لكل ضابط
  • أي إجراءات اختُبرت لكل ضابط
  • عدد العينات من كل فترة
  • أي استثناءات وكيف تم التعامل معها
  • كيف يعمل كل ضابط
  • كيف يدعم ضوابط التطبيق الأخرى
  • ما النتائج إذا فشل

مثال عملي: شركة الأندلس للمعادن {#worked-example}

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

اختبار مراجعة وصول المستخدمين


الخطوة 1. حصلنا على تقارير مراجعة الوصول من يناير، أبريل، يوليو، وأكتوبر 2024. ملاحظة توثيق: أربعة أشهر تمثيلية تغطي السنة كاملة، حفظت في ملف W-IT-02.
الخطوة 2. راجعنا كل تقرير للتأكد أنه يتضمن جميع المستخدمين النشطين. قارنا القوائم مع سجلات الموارد البشرية. ملاحظة توثيق: تطابق تام في يناير وأبريل ويوليو. في أكتوبر، تأخر إلغاء وصول لموظف استقال في 15 سبتمبر حتى 31 أكتوبر - تأخر 16 يوم.
الخطوة 3. تحققنا أن الموظفين الملغيين فعلاً لا يستطيعون الوصول للنظام. جربنا تسجيل دخول بحسابات ملغية من كل شهر. ملاحظة توثيق: جميع الحسابات الملغية في يناير وأبريل ويوليو ترفض الوصول. حساب الموظف المستقيل في سبتمبر سمح بالوصول حتى 31 أكتوبر.
النتيجة: الضابط عمل بفعالية خلال يناير-سبتمبر 2024. تأخر في أكتوبر أثر على 16 يوماً فقط. الفترة الاعتمادية: يناير-سبتمبر 2024.

اختبار تغيير كلمات المرور


الخطوة 1. حصلنا على سجلات النظام التي تظهر متى جُبر المستخدمون على تغيير كلمات المرور. الفترات: يناير، أبريل، يوليو، أكتوبر. ملاحظة توثيق: سجلات النظام محفوظة في W-IT-03، تظهر 94 مستخدم في يناير، 91 في أبريل، 88 في يوليو، 85 في أكتوبر.
الخطوة 2. اختبرنا عشوائياً 12 مستخدم من كل فترة للتأكد أنهم غيّروا كلمات المرور فعلاً. راجعنا تواريخ آخر تغيير في ملف تعريف كل مستخدم. ملاحظة توثيق: جميع المستخدمين المختبرين غيّروا كلمات المرور في غضون 3 أيام من الإجبار، باستثناء مستخدم واحد في يوليو تأخر 8 أيام.
الخطوة 3. تحققنا من سياسة كلمات المرور (8 أحرف أدنى، مزيج من أحرف وأرقام ورموز) وأن النظام يرفض كلمات المرور الضعيفة. ملاحظة توثيق: جربنا كلمات مرور ضعيفة في مارس وسبتمبر، النظام رفضها في كلا المرتين.
النتيجة: الضابط عمل بفعالية طوال 2024. التأخر لمستخدم واحد لم يؤثر على البيئة العامة. الفترة الاعتمادية: السنة كاملة 2024.

اختبار النسخ الاحتياطية


الخطوة 1. حصلنا على سجلات النسخ الاحتياطية من يناير حتى ديسمبر 2024. راجعنا أن النسخة حدثت كل أحد كما مخطط لها. ملاحظة توثيق: 52 أحد في السنة، 49 نسخة احتياطية ناجحة. فشل في 3 أحد بسبب انقطاع كهرباء.
الخطوة 2. اختبرنا استعادة البيانات من 6 نسخ احتياطية موزعة عبر السنة (فبراير، أبريل، يونيو، أغسطس، أكتوبر، ديسمبر). أجرينا استعادة كاملة لقاعدة بيانات تجريبية. ملاحظة توثيق: جميع عمليات الاستعادة نجحت في غضون 4 ساعات. البيانات المستعادة مطابقة للأصل.
الخطوة 3. راجعنا إجراءات التعامل مع فشل النسخ الاحتياطية. ماذا يحدث عندما تفشل النسخة يوم الأحد؟ ملاحظة توثيق: السياسة تتطلب إعادة المحاولة يوم الاثنين. في الحالات الثلاث التي فشلت، تمت إعادة المحاولة وانجحت في غضون 24 ساعة.
النتيجة: الضابط عمل بفعالية طوال 2024. الفشل في 3 أحد لم يترك فجوات في التغطية لأن الإعادة حدثت خلال 24 ساعة. الفترة الاعتمادية: السنة كاملة 2024.

الخلاصة للشركة


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

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

قائمة مراجعة عملية {#practical-checklist}

استخدم هذه القائمة على ملفك الحالي غداً:

  • حدد جميع CUECs التي تعتمد عليها - راجع ملف تقنية المعلومات وحدد أي ضابط محوسب عام يدعم ضوابط التطبيق التي تختبرها. لا تنس ضوابط الوصول وإدارة التغيير والنسخ الاحتياطية.
  • صنّف كل CUEC حسب طبيعته - مستمر (يعمل طوال الوقت)، دوري (يعمل في دورات منتظمة)، أو متجاوب (يعمل عند حدث معين). هذا يحدد استراتيجية الاختبار.
  • خطط نقاط الاختبار عبر السنة - بدلاً من اختبار في ديسمبر فقط، اختر 3-4 نقاط تغطي السنة كاملة. للضوابط الدورية، اختبر مثال من كل دورة أو عينة تمثيلية.
  • وثق أي تغييرات في CUECs خلال السنة - اسأل مدير تقنية المعلومات عن أي تحديثات أو تغييرات في الأنظمة. تواريخ التغيير تحدد فترات الاعتماد المختلفة.
  • اختبر الاستمرارية والاتساق - لا تختبر فقط أن الضابط يعمل، بل أنه يعمل بنفس الطريقة عبر نقاط الاختبار المختلفة. التغيير في الطريقة قد يعني تغيير في الفعالية.
  • الأهم من الكل: اربط اختبارات CUECs بضوابط التطبيق - كل CUEC تختبرها يجب أن تدعم ضابط تطبيق تعتمد عليه. إذا فشلت CUEC في فترة معينة، تحتاج إجراءات تفصيلية إضافية لتلك الفترة وفقاً لمعيار المراجعة 330.15.

الأخطاء الشائعة {#common-mistakes}

  • اختبار CUECs في نقطة زمنية واحدة فقط - الأكثر شيوعاً. فرق كثيرة تختبر في ديسمبر وتفترض أن النتائج تنطبق على السنة كاملة. البحوث الدولية تظهر أن هذا النهج يفوّت تغييرات مهمة في 60% من الحالات.
  • عدم توثيق فترات الاعتماد - توثيق أن الضابط "يعمل بفعالية" بدون تحديد الفترة التي يغطيها هذا الاستنتاج. معيار المراجعة 230.8 يتطلب وضوح في التوقيت.
  • تجاهل التغييرات الصغيرة - افتراض أن التحديثات البسيطة أو إعادة تعيين كلمات المرور لا تؤثر على فعالية الضابط. التغييرات الصغيرة قد تخل بالضوابط بطرق غير متوقعة.
  • عدم توسيع نطاق الإجراءات الجوهرية للفترات غير المختبرة - عند وجود فجوة في فعالية CUEC، يتطلب معيار المراجعة 330.17 إجراءات جوهرية موسعة لتلك الفترة. فريق راجع شركة طاقة في الرياض اختبر CUECs في أكتوبر فقط، واكتشف فجوة في يونيو، لكنه لم يوسع اختبار المعاملات للفترة يناير-يونيو، مما أدى إلى تحفظ في تقرير المراجعة.

محتوى ذو صلة {#related-content}

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

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

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

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