ما هي أهم ضوابط تقنية المعلومات العامة؟

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

ما الأدلة التي يطلبها المراجع في تدقيق ITGC؟

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

هل تُعد ملاحظة ITGC ضعفًا جوهريًا؟

ليس في الغالب إذا كانت منفردة. فالمراجع ينظر في حجم الفجوة ووجود ضوابط تعويضية ومدى تأثيرها في الاعتماد على التقارير والضوابط الآلية. لكن قد تُجمع عدة إخفاقات مترابطة فتُصنَّف قصورًا جوهريًا، أو ضعفًا جوهريًا وفق معايير PCAOB الأمريكية.

كم مرة يجب مراجعة صلاحيات المستخدمين؟

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

هل تنطبق ضوابط ITGC على الأنظمة السحابية وSaaS؟

نعم. فالمزوّد يطبّق جزءًا من الضوابط، وهي عادة مشمولة في تقرير SOC 1 أو SOC 2 الخاص به، لكنك تبقى مسؤولًا عن صلاحيات المستخدمين والإعدادات والواجهات وضوابط الجهة المستفيدة التكميلية الواردة في التقرير.

هل اختبار ITGC مقتصر على الشركات الخاضعة لقانون SOX؟

لا. فالمراجعون الذين يطبّقون معايير المراجعة الدولية مطالبون أيضًا بفهم بيئة تقنية المعلومات وضوابطها العامة وفق المعيار ISA 315 (Revised 2019). ويختلف عمق الاختبار بحسب نية المراجع في الاعتماد على الضوابط، لكن أي منشأة تخضع لمراجعة نظامية في المملكة أو غيرها يمكن أن تتوقع أسئلة عن ITGC.

تقنية المعلومات والاستشارات

تدقيق ضوابط تقنية المعلومات العامة (ITGC): قائمة التحقق والأدلة وخطة الاستعداد

بقلم فريق ITCM · آخر تحديث أكتوبر 2026

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

أبرز النقاط

يختبر المراجع ضوابط ITGC ليعتمد على التقارير التي يولّدها النظام والضوابط الآلية؛ وضعفها يعني اختبارات يدوية أكثر وملاحظات محتملة في خطاب الإدارة.
المجالات الأربعة الكلاسيكية: الوصول إلى البرامج والبيانات، وإدارة التغييرات، وتطوير الأنظمة أو اقتناؤها، والتشغيل.
يجب أن تغطي الأدلة فترة المراجعة كاملة، وأن تكون مستخرجة من النظام قدر الإمكان، وتوضّح من فعل ماذا ومتى.
أغلب الملاحظات سببها تأخر إلغاء صلاحيات المغادرين، وغياب مراجعات الصلاحيات، وتغييرات بلا اختبار أو اعتماد، ومطورون يملكون وصولًا مباشرًا إلى الإنتاج.
في الأنظمة السحابية وSaaS اطلب تقرير SOC 1 أو SOC 2 من المزوّد، وتحقق من الفترة والاستثناءات، وطبّق ضوابط الجهة المستفيدة التكميلية (CUECs) الواردة فيه.
ابدأ التحضير قبل نهاية السنة المالية بستة أشهر على الأقل، حتى تعالج الفجوات ويثبت تشغيل الضوابط لفترة كافية قبل الاختبار.

ما هي ضوابط تقنية المعلومات العامة ولماذا يختبرها المراجع المالي؟

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

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

وفق معايير المراجعة الدولية، يُلزم المعيار ISA 315 (Revised 2019) المراجع بفهم بيئة تقنية المعلومات، وتحديد المخاطر الناشئة عن استخدامها، والضوابط العامة التي تعالجها. ويسري المعيار على مراجعة الفترات التي تبدأ في 15 ديسمبر 2021 أو بعده، وفي المملكة تُلزم الهيئة السعودية للمراجعين والمحاسبين (SOCPA) بتطبيق معايير المراجعة الدولية في المراجعة النظامية. أما الشركات المدرجة في الولايات المتحدة فيُلزمها القسم 404 من قانون Sarbanes-Oxley بتقييم الرقابة الداخلية على التقارير المالية (ICFR)، وتحتاج الشركات الأكبر أيضًا إلى رأي المراجع وفق معيار PCAOB AS 2201، وتُعد ضوابط ITGC جزءًا أساسيًا من هذا الاختبار.

الفرق بين تدقيق ITGC وتدقيق ERP ومراجعة حوكمة تقنية المعلومات

كثيرًا ما يحدث خلط بين هذه المراجعات الثلاث. فتدقيق ITGC يتحدد نطاقه بمخاطر التقارير المالية، ويقوم به المراجع الخارجي أو يُنفَّذ لصالحه، ويشمل كل الأنظمة ضمن النطاق بما فيها البنية التحتية والهوية، ويسأل: هل عملت الضوابط طوال السنة؟ أما تدقيق نظام ERP فيتعمق في نظام أعمال واحد: تصميم الأدوار، والفصل بين المهام داخل الوحدات، والبيانات الرئيسية، ومسارات الاعتماد. وإن كان هذا ما تحتاجه فراجع قائمة تدقيق نظام ERP.

مراجعة حوكمة تقنية المعلومات أو ISO/IEC 27001 أوسع نطاقًا، إذ تشمل الاستراتيجية وإدارة المخاطر والأمن والسياسات بعيدًا عن التقارير المالية وحدها. والجيد أن الأدلة متداخلة بدرجة كبيرة، فمراجعة الصلاحيات أو إجراءات التغيير المنضبطة تخدم المراجعات الثلاث معًا.

نوع المراجعة	السؤال الرئيسي	النطاق المعتاد
تدقيق ITGC	هل يمكن للمراجع الاعتماد على الأنظمة خلف القوائم المالية؟	نظام ERP أو المحاسبة، قاعدة البيانات، نظام التشغيل، الهوية، النسخ الاحتياطي، الواجهات
تدقيق ERP	هل النظام مُعدّ ومؤمَّن ومستخدم بشكل صحيح؟	الأدوار، الفصل بين المهام، البيانات الرئيسية، مسارات العمل، الإعدادات
حوكمة تقنية المعلومات / ISO 27001	هل تُدار التقنية وتؤمَّن بما يخدم أهداف المنشأة؟	السياسات، المخاطر، الأمن، الموردون، استمرارية الأعمال

مجالات ITGC الأربعة التي يختبرها المراجع

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

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

قائمة الأدلة (PBC): الوصول إلى البرامج والبيانات

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

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

قائمة الأدلة (PBC): إدارة التغييرات

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

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

قائمة الأدلة (PBC): تطوير الأنظمة واقتناؤها

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

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

قائمة الأدلة (PBC): التشغيل والنسخ الاحتياطي وجدولة المهام والحوادث

تُظهر أدلة التشغيل أن البيانات محمية وأن المعالجة الآلية اكتملت بشكل صحيح. والمراجع يريد سجلات ونتائج، لا مجرد أداة نسخ احتياطي أُعدّت مرة واحدة.

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

الأنظمة السحابية وSaaS: تقارير SOC وضوابط الجهة المستفيدة التكميلية

الانتقال إلى السحابة لا يُلغي ضوابط ITGC، بل يوزّعها. فالمزوّد يدير مركز البيانات والبنية التحتية، وغالبًا عملية التغيير في البرنامج، بينما تبقى أنت مسؤولًا عن الصلاحيات وطريقة إعداد النظام والتحقق من البيانات. ولذلك يطلب المراجع في العادة تقرير SOC الخاص بالمزوّد بدلًا من اختباره مباشرة.

يغطي تقرير SOC 1 ضوابط مقدّم الخدمة ذات الصلة بالرقابة الداخلية على التقارير المالية لدى عملائه، ولذلك هو التقرير الذي يطلبه المراجع المالي غالبًا. أما SOC 2 فيغطي الأمن، وبحسب النطاق قد يشمل التوافر وسلامة المعالجة والسرية والخصوصية. ويختبر تقرير Type 2 فعالية التشغيل على مدى فترة زمنية، بينما يصف Type 1 التصميم في تاريخ محدد فقط، فاطلب Type 2 متى توفر.

عند استلام التقرير تحقق من أن فترته تتداخل مع سنتك المالية، واقرأ الاستثناءات ورأي المراجع، وحدد مقدّمي الخدمات الفرعيين المستثنين من النطاق، ثم راجع قائمة ضوابط الجهة المستفيدة التكميلية (CUECs). وهي ضوابط يتوقع المزوّد أن تطبّقها أنت، مثل مراجعة مستخدميك وحماية بيانات دخول المسؤولين. وإن انتهت فترة التقرير قبل نهاية سنتك بأشهر فاطلب خطاب تغطية (Bridge Letter) للفترة المتبقية. ويُستحسن كذلك أن تتأكد من متطلبات توطين البيانات التي تنطبق على قطاعك في المملكة عند اختيار المزوّد.

الملاحظات الشائعة في ITGC وكيف يصنّفها المراجع

وفق معايير PCAOB الأمريكية هناك ثلاثة مستويات. القصور الرقابي يوجد عندما لا يسمح تصميم الضابط أو تشغيله بمنع التحريفات أو اكتشافها في الوقت المناسب. والقصور الجوهري أقل خطورة من الضعف الجوهري لكنه مهم بما يكفي لاستحقاق اهتمام المسؤولين عن الإشراف على التقارير المالية. أما الضعف الجوهري (Material Weakness) فهو قصور أو مجموعة أوجه قصور تجعل هناك احتمالًا معقولًا لعدم منع تحريف جوهري أو اكتشافه في الوقت المناسب، وعند وجوده لا يمكن اعتبار الرقابة الداخلية على التقارير المالية فعّالة.

أما وفق معايير المراجعة الدولية المطبّقة في المملكة ودول كثيرة، فيعتمد المعيار ISA 265 مستويين: القصور في الرقابة الداخلية، والقصور الجوهري (Significant Deficiency)، ويجب على المراجع إبلاغ أوجه القصور الجوهرية كتابيًا للمكلفين بالحوكمة وللإدارة. وغالبًا ما تُصنَّف ملاحظة ITGC منفردة على أنها قصور، لكن المراجع ينظر في وجود ضوابط تعويضية، وفي مدى تأثيرها على الاعتماد على التقارير والضوابط الآلية. وقد تُجمع عدة ملاحظات مترابطة في نظام واحد لتصل إلى تصنيف أشد.

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

كيف تستعد في الأشهر السابقة لمراجعة نهاية السنة

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

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

التوقيت	الإجراء
قبل نهاية السنة بـ 6 أشهر	تأكيد الأنظمة ضمن النطاق مع المراجع، وربط الضوابط بالمجالات الأربعة، وتنفيذ تقييم الفجوات
قبلها بـ 5 أشهر	معالجة فجوات التصميم: إجراء المغادرة، الحسابات المميزة، مسار التغيير، تنبيهات النسخ الاحتياطي
قبلها بـ 4 أشهر	تنفيذ مراجعة صلاحيات واختبار استعادة، وطلب تقارير SOC من المزوّدين الرئيسيين
قبلها بـ 3 أشهر	تجربة سحب أدلة PBC لعينة من المنضمين والمغادرين والتغييرات، والتأكد من تطابق التواريخ
قبلها بشهر إلى شهرين	الاختبار المرحلي من المراجع، والرد على الاستفسارات، ومراجعة صلاحيات ثانية إن كانت ربع سنوية
عند نهاية السنة وبعدها	اختبارات استكمال الفترة، خطابات التغطية، القوائم النهائية، الرد على الملاحظات والاتفاق على خطة المعالجة

بناء خطة معالجة الملاحظات

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

تحقق أولًا من أن المشكلة لم تُحدث ضررًا فعليًا، كأن تراجع ما فعله حساب موظف بعد مغادرته. ثم عالج الإجراء نفسه لا الحالة وحدها، واترك الضابط يعمل لعدة دورات قبل إعلان إغلاق الملاحظة. وإن احتجت إلى دعم خارجي في تصميم الضوابط أو إدارة الأدلة، فإن خدمة استشارات تقنية المعلومات لدى ITCM تبدأ من 100 دولار (375 ريالًا)، ويُتفق على السعر مسبقًا ولا تدفع إلا بعد مراجعة العمل. ولجانب السياسات والأطر الأوسع راجع دليل حوكمة تقنية المعلومات والامتثال.

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

الأسئلة الشائعة

ما هي أهم ضوابط تقنية المعلومات العامة؟: تنقسم ضوابط ITGC إلى أربعة مجالات: الوصول إلى البرامج والبيانات، وإدارة التغييرات، وتطوير الأنظمة أو اقتناؤها، والتشغيل مثل النسخ الاحتياطي وجدولة المهام وإدارة الحوادث. وأكثر ما يختبره المراجع داخلها: منح الصلاحيات وإلغاؤها، ومراجعات الصلاحيات، والصلاحيات المميزة، واعتماد التغييرات واختبارها، ومراقبة النسخ الاحتياطي.
ما الأدلة التي يطلبها المراجع في تدقيق ITGC؟: من الطلبات المعتادة: قوائم المستخدمين من النظام، وتقارير الموارد البشرية عن المنضمين والمغادرين، وتذاكر طلب الصلاحيات وإلغائها، ومراجعات الصلاحيات المعتمدة، وقائمة كاملة بتغييرات الإنتاج مع الاعتمادات وأدلة الاختبار، وسجلات النسخ الاحتياطي، وسجل اختبار الاستعادة، وسجلات فشل المهام المجدولة، وتقارير SOC للمزوّدين السحابيين.
هل تُعد ملاحظة ITGC ضعفًا جوهريًا؟: ليس في الغالب إذا كانت منفردة. فالمراجع ينظر في حجم الفجوة ووجود ضوابط تعويضية ومدى تأثيرها في الاعتماد على التقارير والضوابط الآلية. لكن قد تُجمع عدة إخفاقات مترابطة فتُصنَّف قصورًا جوهريًا، أو ضعفًا جوهريًا وفق معايير PCAOB الأمريكية.
كم مرة يجب مراجعة صلاحيات المستخدمين؟: لا يوجد تكرار موحد مفروض. كثير من الشركات تراجع صلاحيات الأنظمة المالية ربع سنويًا والصلاحيات المميزة بوتيرة أعلى، بينما قد تكتفي المنشآت الصغيرة ذات الفرق المستقرة بمراجعة نصف سنوية. المهم أن تحدد تكرارًا يناسب المخاطر وتلتزم بكل مراجعة في وقتها مع توثيقها.
هل تنطبق ضوابط ITGC على الأنظمة السحابية وSaaS؟: نعم. فالمزوّد يطبّق جزءًا من الضوابط، وهي عادة مشمولة في تقرير SOC 1 أو SOC 2 الخاص به، لكنك تبقى مسؤولًا عن صلاحيات المستخدمين والإعدادات والواجهات وضوابط الجهة المستفيدة التكميلية الواردة في التقرير.
هل اختبار ITGC مقتصر على الشركات الخاضعة لقانون SOX؟: لا. فالمراجعون الذين يطبّقون معايير المراجعة الدولية مطالبون أيضًا بفهم بيئة تقنية المعلومات وضوابطها العامة وفق المعيار ISA 315 (Revised 2019). ويختلف عمق الاختبار بحسب نية المراجع في الاعتماد على الضوابط، لكن أي منشأة تخضع لمراجعة نظامية في المملكة أو غيرها يمكن أن تتوقع أسئلة عن ITGC.

مقالات وخدمات ذات صلة

تريد أن نتولى ذلك عنك؟

ننفّذ كل ذلك عن بُعد — اطلب عرض سعر أو ابدأ بتدقيق مجاني لموقعك.

اطلب عرض سعر تدقيق مجاني

→ جميع المقالات