> ## Content Index > Fetch the complete content index at: https://arabroot.io/llms.txt > Use this file to discover other available public pages before exploring further. # الاستعداد للتدقيق Audit: ماذا يطلب المدقق وكيف تجهز - URL: https://arabroot.io/articles/الاستعداد-للتدقيق-ماذا-يطلب-المدقق/ - Published: 2026-10-26T12:04:21.000Z - Updated: 2026-10-26T17:54:35.000Z - Description: ماذا يطلب المدقق ولماذا وكيف يختار العينة، مع سكربت يفحص جاهزية الأدلة قبل ثلاثة أسابيع ويكشف ما لم يتوقعه الفريق. - Author: فريق عرب رووت - Tags: الأدلة التقنية, الأمن السيبراني, السيادة الرقمية والامتثال, القطاع الحكومي وصلت رسالة إلى مدير التقنية في شركة منصة حجز مواعيد العيادات صباح يوم أحد: فريق المراجعة في المستشفى الحكومي، الذي تعاقد مع الشركة على أساس الضوابط الأساسية ECC-2:2024، سوف يجري تدقيقاً على الخدمة بعد ثلاثة أسابيع، ومرفق بالرسالة جدول من أربعين سطراً عنوانه «قائمة الأدلة المطلوبة»، أوله «السياسات المعتمدة مع ما يثبت اعتمادها»، ووسطه «إعداد SSH الفعلي على كل سيرفر في النطاق»، وآخره «تقرير آخر مراجعة داخلية وما يثبت عرضه على اللجنة الإشرافية». وكانت الشركة قد بنت خلال الأشهر الماضية كل ما شرحناه في هذه المرحلة: سياسات في Git، وسجل مخاطر، وتقييماً ذاتياً في CISO Assistant، وجامع أدلة يعمل يومياً، وبدأت تبني نظام ISO/IEC 27001 فوقها. ومع ذلك كان أول سؤال للمدير: «هل نحن جاهزون؟ وكيف أعرف قبل أن يعرف المدقق؟». وهذا المقال هو الأخير في [مرحلة الحوكمة والمخاطر والامتثال](https://arabroot.io/start/#stage-grc)، وفيه نجلس على الجهة الأخرى من الطاولة: ماذا يطلب المدقق، ولماذا يطلبه، وكيف يختار العينات، وما الأسلوب الذي يثق به أكثر، وكيف تكتب الرد على ملاحظاته. وقد شرحنا معنى التدقيق الداخلي والخارجي والملاحظة وخطة التصحيح في [مصطلحات GRC](https://arabroot.io/articles/%D9%85%D8%B5%D8%B7%D9%84%D8%AD%D8%A7%D8%AA-grc-%D8%A7%D9%84%D8%AD%D9%88%D9%83%D9%85%D8%A9-%D9%88%D8%A7%D9%84%D9%85%D8%AE%D8%A7%D8%B7%D8%B1-%D9%88%D8%A7%D9%84%D8%A7%D9%85%D8%AA%D8%AB%D8%A7%D9%84/#audit)، فلن نعيد التعريفات، وإنما نأخذ القصة إلى يوم التدقيق نفسه، ونبني سكربتاً يفحص الجاهزية قبل ثلاثة أسابيع، ونرى ما كشفه، ومنه شيء لم يتوقعه أحد في الفريق. [![](https://arabroot.io/content/images/2026/10/grc-terms-cover-cover.webp)دليلمصطلحات GRC للمبتدئين بمثال من شركة صغيرةما الذي يعنيه GRC فعلاً، وما الكلمات التي يستخدمها المدقق، وكيف تثبت له أن ضوابطك تعمل كما تقول.](https://arabroot.io/articles/%D9%85%D8%B5%D8%B7%D9%84%D8%AD%D8%A7%D8%AA-grc-%D8%A7%D9%84%D8%AD%D9%88%D9%83%D9%85%D8%A9-%D9%88%D8%A7%D9%84%D9%85%D8%AE%D8%A7%D8%B7%D8%B1-%D9%88%D8%A7%D9%84%D8%A7%D9%85%D8%AA%D8%AB%D8%A7%D9%84/)[![](https://arabroot.io/content/images/2026/10/evidence-collection-cover-cover.webp)دليلجمع أدلة الامتثال Evidence تلقائياً بدل لقطات الشاشةنبني جامع أدلة صغيراً يقرأ إعدادات السيرفرات عبر SSH ويحفظها بالهاش، ثم نجربه على تغيير مفاجئ ودليل معدل وجامع فقد صلاحيته بصمت.](https://arabroot.io/articles/%D8%AC%D9%85%D8%B9-%D8%A7%D8%AF%D9%84%D8%A9-%D8%A7%D9%84%D8%A7%D9%85%D8%AA%D8%AB%D8%A7%D9%84-%D8%AA%D9%84%D9%82%D8%A7%D8%A6%D9%8A%D8%A7/)[![](https://arabroot.io/content/images/2026/10/ciso-assistant-cover-cover.webp)دليلإدارة الامتثال Compliance مع CISO Assistant على سيرفركنشغل CISO Assistant ونحمل فيه ضوابط ECC-2:2024 ونقيم منصة حقيقية ونربطها بالضوابط والأدلة ونصدر التقرير، مع كل مشكلة واجهناها في الطريق.](https://arabroot.io/articles/%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%A7%D9%84%D8%A7%D9%85%D8%AA%D8%AB%D8%A7%D9%84-%D9%85%D8%B9-ciso-assistant/)[![](https://arabroot.io/content/images/2026/10/iso27001-open-source-cover-cover.webp)دليلISO 27001 بأدوات مفتوحة المصدر من المخاطر إلى التدقيقكيف تبني شركة صغيرة نظام ISO/IEC 27001 على ما بنته لضوابط ECC، من النطاق وسجل المخاطر إلى بيان قابلية التطبيق والتدقيق الداخلي.](https://arabroot.io/articles/iso-27001-%D8%A8%D8%A7%D8%AF%D9%88%D8%A7%D8%AA-%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D8%A7%D9%84%D9%85%D8%B5%D8%AF%D8%B1-%D9%85%D9%86-%D8%A7%D9%84%D9%85%D8%AE%D8%A7%D8%B7%D8%B1-%D8%A7%D9%84%D9%89-%D8%A7%D9%84%D8%AA%D8%AF%D9%82%D9%8A%D9%82/) ⚠️ هذا المقال شرح تقني لما في الضوابط الأساسية ونماذج الهيئة بحسب ما نشرته عند كتابته، وليس استشارة قانونية أو رأياً في عقد بعينه، فما يلزمك في التدقيق يحدده عقدك ونص الضوابط المعمول به، والرجوع فيه إلى الجهة المتعاقدة معك ومستشارك. وسوف نناقش في هذا المقال ما يلي: - ما الفرق بين المراجعة والتدقيق في الضوابط، ولماذا يطلب 1-8-2 أن يدقق غير إدارة الأمن السيبراني. - لماذا يدقق المستشفى شركة ليست جهة حكومية، وما علاقة ذلك بضوابط الأطراف الخارجية. - مراحل التدقيق الست كما في نموذج إجراء التدقيق الذي تنشره الهيئة، وما تفعله أنت في كل مرحلة. - الأساليب الأربعة التي يدقق بها المدقق، ولماذا لا يكفي الاستفسار وحده. - الفرق بين فعالية التصميم والفعالية التشغيلية، ولماذا يغير هذا كل شيء في إعداد الأدلة. - قائمة الطلبات: كيف تقرؤها وتنظم الرد عليها. - تجربة عملية: سكربت يفحص الجاهزية على قائمة الطلبات ومخزن الأدلة، ويختار عينة كما يختارها المدقق. - مثال كامل لعينة المغادرين، وكيف تسلم الأدلة دون أن تصنع مخاطرة جديدة. - يوم التدقيق نفسه، وقراءة نموذج تقرير التدقيق، وكتابة الرد على الملاحظات، وما بعد التدقيق. - أخطاء شائعة، وقائمة تحقق قبل التدقيق بثلاثة أسابيع. ## المراجعة والتدقيق: من يفحص من؟ المكون الفرعي 1-8 في [ECC-2:2024](https://cdn.nca.gov.sa/api/files/public/upload/86e09090-44e4-481f-bc28-355673607654%5FECC--2024-EN.pdf?ref=arabroot.io) عنوانه المراجعة والتدقيق الدوري للأمن السيبراني، وفيه ثلاثة ضوابط تفرق بين أمرين يخلط بينهما كثيرون. فالضابط 1-8-1 يطلب أن تراجع إدارة الأمن السيبراني تطبيق الضوابط دورياً، وهذه مراجعة يقوم بها من بنى الضوابط نفسه، وهي ما فعلته الشركة في تقييمها الذاتي. أما الضابط 1-8-2 فيطلب أن يراجع التطبيق ويدقق من أطراف غير إدارة الأمن السيبراني، بشكل مستقل يراعي مبدأ تعارض المصالح، ووفق معايير التدقيق المقبولة عموماً GAAS والمتطلبات التنظيمية. والضابط 1-8-3 يطلب أن توثق نتائج التدقيق والمراجعة وتعرض على اللجنة الإشرافية للأمن السيبراني والمسؤول الأول، وأن تشمل النتائج نطاق التدقيق والملاحظات والتوصيات والإجراءات التصحيحية وخطط المعالجة. والسبب في هذا الفصل بسيط: من بنى الشيء لا يرى أخطاءه بسهولة، وله مصلحة في ألا يراها. ولذلك فإن نموذج «إجراء تدقيق الأمن السيبراني» الذي تنشره الهيئة في صفحة [أدوات الأمن السيبراني](https://nca.gov.sa/ar/regulatory-documents/guidelines-list/cybersecurity-toolkits/?ref=arabroot.io) يفرق بالكلمات نفسها: التدقيقات تجريها الإدارة المعنية بالتدقيق الداخلي، والمراجعات تجريها الإدارة المعنية بالأمن السيبراني، ويجوز أن يجري الاثنين مدقق خارجي مستقل. وفي شركة من اثني عشر شخصاً لا توجد إدارة تدقيق داخلي، وهذا ما يجعل تدقيق المستشفى، وتدقيق الجهة المانحة لشهادة ISO لاحقاً، فرصة وليس تهديداً: هو التدقيق المستقل الذي لا تستطيع الشركة أن تجريه على نفسها. ## لماذا يدقق المستشفى شركة صغيرة أصلاً؟ قبل أن يبدأ الفريق في جمع أي شيء، سأل مدير التقنية سؤالاً يستحق الإجابة: الشركة ليست جهة حكومية، فلماذا تخضع لتدقيق على ECC؟ والإجابة في قسم النطاق من وثيقة الضوابط نفسها، فالضوابط تنطبق على الجهات الحكومية في المملكة والشركات والجهات التابعة لها، وعلى جهات القطاع الخاص التي تملك بنى تحتية وطنية حساسة Critical National Infrastructure أو تشغلها أو تستضيفها. أي أن الجهة الملزمة هنا هي المستشفى، والشركة طرف ثالث Third Party يقدم له خدمة. لكن المكون الفرعي 4-1 في الضوابط، وهو الأمن السيبراني المتعلق بالأطراف الخارجية، ينقل جزءاً من الالتزام إلى العقد. فالضابط 4-1-2 يطلب أن تشمل عقود الأطراف الخارجية التي قد يؤثر خللها في بيانات الجهة أو خدماتها، كحد أدنى، بنود عدم الإفصاح والحذف الآمن لبيانات الجهة عند انتهاء الخدمة، وإجراءات التواصل عند وقوع حادثة، وإلزام الطرف الخارجي بتطبيق متطلبات الجهة وسياساتها والمتطلبات التشريعية والتنظيمية ذات العلاقة. والضابط 4-1-4 يطلب أن تراجع متطلبات الأمن السيبراني للأطراف الخارجية دورياً. وهذا التدقيق هو المراجعة الدورية التي يطلبها 4-1-4 من المستشفى، والبند الذي يلزم الشركة به هو البند الذي يطلبه 4-1-2 في العقد. ومن الجهة الأخرى، تقول الوثيقة في قسم التطبيق والالتزام إن الهيئة تقيم التزام الجهات بالضوابط بوسائل متعددة، منها التقييم الذاتي من الجهة، والتقارير الدورية من أداة الالتزام، والزيارات الميدانية للتدقيق، بحسب الآلية التي تراها الهيئة مناسبة. فالمستشفى نفسه قد يسأل يوماً عن أطرافه الخارجية، وتقرير تدقيقه على الشركة هو الدليل الذي سوف يعرضه. وفهم هذا يغير طريقة تعامل الفريق مع المدقق: هو لا يبحث عن سبب لإلغاء العقد، وإنما يحتاج دليلاً يكفي لأن يقول لجهته إن هذا الطرف الخارجي يلتزم بما في العقد، والفريق الذي يسهل عليه ذلك يسهل على نفسه التدقيق. ## مراحل التدقيق الست، وما تفعله في كل منها نزلنا نموذج إجراء التدقيق من صفحة الأدوات وحولناه إلى نص بـ Pandoc كما فعلنا في [مقال السياسات](https://arabroot.io/articles/%D8%B3%D9%8A%D8%A7%D8%B3%D8%A7%D8%AA-%D8%A7%D9%84%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%B3%D9%8A%D8%A8%D8%B1%D8%A7%D9%86%D9%8A-%D9%82%D9%88%D8%A7%D9%84%D8%A8-%D9%88%D9%83%D9%8A%D9%81-%D8%AA%D9%83%D8%AA%D8%A8-%D8%B3%D9%8A%D8%A7%D8%B3%D8%A9-%D8%AA%D8%B7%D8%A8%D9%82/#lab)، فوجدناه يقسم التدقيق إلى ست مراحل، ولكل مرحلة جدول خطوات بالمالك والمدخلات والمخرجات. والشكل التالي يلخصها، ويضيف في كل مرحلة ما يفعله الطرف الخاضع للتدقيق، وهو أنت: ![ست مراحل مرقمة: خطة التدقيق، والتجهيز، والتنفيذ، وتوثيق النتائج، والعرض على اللجنة، والمراقبة والمراجعة، وتحت كل مرحلة ما يفعله الطرف الخاضع للتدقيق](https://arabroot.io/content/images/2026/10/audit-readiness-01-phases.webp) مراحل نموذج إجراء التدقيق من الهيئة، والخانات الرمادية دورك أنت 1. **إعداد خطة التدقيق:** يحدد المدقق المعايير والنطاق والأساليب والمدة والعينات والأدلة المطلوبة، ويسجلها في سجل خطط التدقيق، وفي نموذج الهيئة لهذا السجل أعمدة واضحة منها نوع التدقيق ونطاقه والمنهجيات والمعايير والعينات والأدلة المطلوبة والتكلفة. والذي يفيدك هنا أن تطلب الخطة مبكراً، فالخطة تقول لك بالضبط ماذا سوف يفحص، ولا يوجد سبب لأن تخمن. 2. **التجهيز:** يحدد المدقق الموارد، ويعد قائمة الاجتماعات والأدلة المطلوبة، ويبلغ الفريق الخاضع للتدقيق، ويطلب تأكيداً من رئيسه. وهذه هي القائمة ذات الأربعين سطراً التي وصلت إلى الشركة. 3. **التنفيذ:** وأول خطوة فيه بحسب النموذج أن يتحقق المدقق من معالجة ملاحظات التدقيق أو المراجعة السابقة، ثم تعقد الاجتماعات وتفحص الأدلة. وهذا يعني أن أول ما سوف يسأل عنه في تدقيقك القادم هو ما وعدت به في هذا التدقيق. 4. **توثيق النتائج والإبلاغ عنها:** يكتب المدقق الملاحظات والتوصيات، ونموذج تقرير التدقيق من الهيئة فيه رقم فريد لكل ملاحظة مرتبط برقم التدقيق، وملحقات بإرشادات كتابة الملاحظات والتوصيات. 5. **العرض على اللجنة التوجيهية ورئيس الجهة:** وهو ما يطلبه الضابط 1-8-3. 6. **المراقبة والمراجعة:** متابعة الإجراءات التصحيحية حتى تغلق. ### مواعيد يحددها النموذج في جداول خطوات [نموذج إجراء التدقيق](https://cdn.nca.gov.sa/api/files/public/upload/f7deadb8-cb86-42a2-bc2c-eb9510e16eba%5FProcedure%5FCybersecurity-Audit%5FTemplate%5Far%5Fv0.4.pdf?ref=arabroot.io) مواعيد محددة، وهي مواعيد يلتزم بها من يتبنى النموذج وليست نصاً في الضوابط، لكن معرفتها تقول لك متى تنتظر ماذا: - **تقرير التدقيق خلال أسبوعين من انتهاء التدقيق:** فإذا انتهت الجلسات ولم يصلك شيء بعد أسبوعين فمن حقك أن تسأل. - **العرض على اللجنة في اجتماعها التالي، وعلى رئيس الجهة خلال ثلاثة أسابيع:** وهذا في جهة المدقق، أي المستشفى، وفي جهتك أنت حين تجري مراجعتك الداخلية. - **مراجعة سنوية على الأقل لخطة معالجة الملاحظات:** فالملاحظة التي وعدت بإغلاقها لا تنسى، وسوف تراجع في السنة نفسها. - **تحليل التزام التدقيق بخطته خلال شهر:** وهذه خطوة داخلية في جهة المدقق تتحقق أنه دقق ما خطط له. وفي مرحلة التنفيذ خطوة رابعة يغفل عنها كثيرون، وهي التشاور مع الفريق الخاضع للتدقيق في كل مسألة غير واضحة. وفي مرحلة الإبلاغ يقول النموذج إن نتائج التدقيق يتفق عليها مع رئيس الإدارة الخاضعة للتدقيق، بما فيها الاستنتاجات والتوصيات وخطة المعالجة. وهذا يعني أن الملاحظة لا يجب أن تفاجئك في التقرير النهائي، وأن من حقك أن تطلب مسودة النتائج وتصحح فيها الوقائع، مثل تاريخ خاطئ أو سيرفر ليس في النطاق. أما الحكم نفسه فللمدقق، والنقاش فيه يكون بالدليل وليس بالإلحاح. ## كيف يدقق المدقق؟ أربعة أساليب في المرحلة الأولى من النموذج نفسه خطوة اسمها «تحديد أساليب إجراء التدقيقات والمراجعات المخططة»، وفيها أربعة أساليب، ويقول النموذج إنه يمكن الجمع بينها: الاستفسار، أي جمع المعلومات من العاملين أصحاب الدراية، والملاحظة، أي دراسة عملية ينفذها آخرون وهي تحدث، والتفتيش، أي فحص السجلات أو الوثائق الورقية أو الإلكترونية أو الفحص المادي للأصول، وإعادة الأداء، أي أن ينفذ المدقق بنفسه وبشكل مستقل الإجراءات أو الضوابط التي نفذت أصلاً. والشكل التالي يرتبها من أضعف دليل إلى أقواه، مع مثال من القصة لكل منها: ![أربع بطاقات: الاستفسار يسأل من يعرف العمل، والملاحظة يرى العملية تنفذ، والتفتيش يفحص السجلات، وإعادة الأداء ينفذ الضابط بنفسه، مع مثال لكل منها عن سحب صلاحيات المغادرين وإعداد SSH](https://arabroot.io/content/images/2026/10/audit-readiness-02-methods.webp) كلما اقترب الأسلوب من إعادة الأداء، قل ما تحتاج أن تشرحه والاستفسار وحده لا يكفي لأي ضابط مهم، فالإجابة «نسحب صلاحيات المغادر في اليوم نفسه» تقول ما يعتقده الشخص، لا ما يحدث. وقد حذرت [مجلة المحاسبة Journal of Accountancy](https://www.journalofaccountancy.com/issues/2026/feb/promises-of-fast-and-easy-threaten-soc-credibility/?ref=arabroot.io) من تقارير SOC 2 المستعجلة التي تعتمد كثيراً على الاستفسار، أي أن المدقق يأخذ كلام العميل في مواضع تحتاج إجراءات أعمق. وهذا التحذير يقرؤه الطرف الخاضع للتدقيق بطريقة أخرى: إذا كان مدققك يكتفي بسؤالك عن كل شيء، فتقريره ضعيف، وعميلك الذي سوف يقرأ التقرير قد يرفضه. فرحب بالتفتيش وإعادة الأداء، بل اعرضها أنت قبل أن يطلبها. وفي القصة جهز الفريق لكل ضابط في القائمة أقوى أسلوب ممكن. فبدل أن يقول «إعداد SSH يمنع دخول root» يعرض مخرج الجامع، وبدل أن يعرض المخرج فقط يقترح على المدقق أن يشغل `sshd -T` بنفسه على سيرفر يختاره، أي إعادة الأداء. وقد بينا في [مقال جمع الأدلة](https://arabroot.io/articles/%D8%AC%D9%85%D8%B9-%D8%A7%D8%AF%D9%84%D8%A9-%D8%A7%D9%84%D8%A7%D9%85%D8%AA%D8%AB%D8%A7%D9%84-%D8%AA%D9%84%D9%82%D8%A7%D8%A6%D9%8A%D8%A7/#file-vs-running) أن `sshd -T` يثبت الإعداد في الملف، وأن محاولة دخول root من الخارج تثبت سلوك البرنامج الذي يعمل، والمدقق الذي يرى الاثنين لا يبقى عنده سؤال. ## فعالية التصميم أم الفعالية التشغيلية؟ في ورقة القوائم المنسدلة في نموذج «سجل خطة تدقيق الأمن السيبراني» من الهيئة، عمود «نوع التدقيق» له ثلاث قيم: فعالية التصميم، والكفاءة التشغيلية، وفعالية التصميم والفعالية التشغيلية معاً. وهذا العمود وحده يحدد نصف عملك في التجهيز، والشكل التالي يبين الفرق: ![مقارنة: فعالية التصميم بنقطة واحدة يوم التدقيق والسؤال هل إعداد SSH يمنع دخول root، والفعالية التشغيلية بخمس نقاط على فترة إحداها مخالفة والسؤال أعطني الإعداد في كل تاريخ من هذه التواريخ](https://arabroot.io/content/images/2026/10/audit-readiness-03-design-operating.webp) التصميم يكفيه دليل في يوم، والتشغيل يحتاج دليلاً لكل عينة في الفترة - **فعالية التصميم Design Effectiveness:** هل الضابط مصمم بحيث يحقق المتطلب لو عمل كما هو مكتوب؟ والدليل وثيقة وإعداد وإجراء في تاريخ واحد. وهذا ما يفحصه التدقيق الأول عادة لضابط جديد. - **الفعالية التشغيلية Operating Effectiveness:** هل عمل الضابط كل مرة خلال الفترة؟ وهنا يختار المدقق عينة من تواريخ أو حالات، مثل خمسة موظفين غادروا خلال الربع، أو خمسة أيام من الفترة، ويطلب الدليل لكل منها. وهذا هو الاختبار الذي تفشل فيه الجهات التي تجمع أدلتها في أسبوع التدقيق، لأنها تملك دليلاً على الحاضر فقط. والسؤال الأول الذي سأله الفريق للمستشفى كان: «ما نوع التدقيق؟»، فجاء الرد أن التدقيق تصميم وتشغيل معاً عن الفترة منذ توقيع العقد. وهذا يعني أن قائمة الطلبات سوف يتبعها في يوم التدقيق طلب عينات بتواريخ، وأن السؤال الحقيقي ليس «هل عندنا دليل؟» وإنما «هل عندنا دليل لكل تاريخ قد يختاره؟». ## قائمة الطلبات: كيف تقرؤها وتنظمها؟ قائمة الأدلة المطلوبة، التي يسميها المدققون بالإنجليزية PBC أي Provided By Client، تبدو قائمة مهام، لكنها في الحقيقة خريطة للتدقيق كله، فكل سطر فيها ضابط سوف يفحص، وصياغته تقول لك الأسلوب. فـ «السياسات المعتمدة مع ما يثبت اعتمادها» تفتيش لوثيقة وتوقيع، و«إعداد SSH الفعلي على كل سيرفر في النطاق» تفتيش لكل أصل في سجل الأصول، و«قائمة الموظفين الذين غادروا خلال الفترة» مقدمة لعينة. وقد نظم الفريق الرد بأربع قواعد: - **رقم لكل طلب ومالك واحد:** كل سطر في القائمة له رقم كما أرسله المدقق، ومالك من الفريق يجهزه، وتاريخ داخلي قبل الموعد بأسبوع. - **الدليل يحمل تاريخه في اسمه أو محتواه:** ملف باسم `2026-10-26-risk-register.csv` يجيب عن سؤال «متى؟» قبل أن يفتح، والسياسة تحمل تاريخ اعتمادها في رأسها كما في مستودع السياسات، ومخرجات الجامع تحمل تاريخ التشغيل في اسم المجلد. - **لا ترسل أكثر مما طلب:** كل ملف إضافي يفتح سؤالاً جديداً، وإذا لم يكن المدقق قد طلبه فاحتفظ به جاهزاً ولا ترسله. - **اقرأ الطلب قبل أن تجمعه:** «تقرير آخر مراجعة داخلية وما يثبت عرضه على اللجنة» طلبان في سطر واحد: التقرير، ومحضر اللجنة. والفريق الذي يرسل التقرير وحده يعود إليه الطلب. ## تجربة عملية: فحص الجاهزية قبل ثلاثة أسابيع بدل أن يفتح الفريق المجلدات ويحكم بالعين، كتب سكربتاً يأخذ قائمة الطلبات مكتوبة كملف، ومخزن الأدلة كما هو، وتاريخ التدقيق، ويقول لكل طلب: هل الدليل موجود، وما عمره، وهل هو أحدث من الحد المقبول، وما حكم الجامع عليه. ومخزن الأدلة في التجربة هو ما أنتجته المقالات السابقة فعلاً: تشغيلات الجامع الثلاثة من [مقال جمع الأدلة](https://arabroot.io/articles/%D8%AC%D9%85%D8%B9-%D8%A7%D8%AF%D9%84%D8%A9-%D8%A7%D9%84%D8%A7%D9%85%D8%AA%D8%AB%D8%A7%D9%84-%D8%AA%D9%84%D9%82%D8%A7%D8%A6%D9%8A%D8%A7/)، وسياسة الوصول الإداري من [مقال السياسات](https://arabroot.io/articles/%D8%B3%D9%8A%D8%A7%D8%B3%D8%A7%D8%AA-%D8%A7%D9%84%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%B3%D9%8A%D8%A8%D8%B1%D8%A7%D9%86%D9%8A-%D9%82%D9%88%D8%A7%D9%84%D8%A8-%D9%88%D9%83%D9%8A%D9%81-%D8%AA%D9%83%D8%AA%D8%A8-%D8%B3%D9%8A%D8%A7%D8%B3%D8%A9-%D8%AA%D8%B7%D8%A8%D9%82/)، وسجل المخاطر من [مقال سجل المخاطر](https://arabroot.io/articles/%D8%B3%D8%AC%D9%84-%D8%A7%D9%84%D9%85%D8%AE%D8%A7%D8%B7%D8%B1-risk-register-%D9%85%D8%B9-simplerisk/)، وخطة العمل المصدرة من [CISO Assistant](https://arabroot.io/articles/%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%A7%D9%84%D8%A7%D9%85%D8%AA%D8%AB%D8%A7%D9%84-%D9%85%D8%B9-ciso-assistant/). أي أننا لم نصنع أدلة للتجربة، وإنما فحصنا ما هو موجود. وقائمة الطلبات نكتبها في `pbc.json`، ونختصرها هنا إلى ثمانية طلبات من القائمة الأصلية: ```json { "audit_date": "2026-11-15", "requests": [ {"id": "R01", "control": "ECC 1-3-1", "ask": "Approved cybersecurity policies", "glob": "policies/*.md", "date": "front_matter", "max_age_days": 365}, {"id": "R02", "control": "ECC 1-5-2", "ask": "Current risk register with owners and treatment", "glob": "registers/*-risk-register.csv", "date": "file_name", "max_age_days": 90}, {"id": "R03", "control": "ECC 2-2-3-2", "ask": "MFA status of every administrator account", "glob": "evidence/*/*/mfa-admins.txt", "date": "run", "max_age_days": 30}, {"id": "R04", "control": "ECC 2-3-3-4", "ask": "Time sources on every server", "glob": "evidence/*/*/time-sources.txt", "date": "run", "max_age_days": 7}, {"id": "R05", "control": "ECC 2-3-2", "ask": "Effective SSH configuration on every server", "glob": "evidence/*/*/ssh-effective-config.txt", "date": "run", "max_age_days": 7}, {"id": "R06", "control": "ECC 2-9-3-3", "ask": "Last restore test record", "glob": "records/*-restore-test.md", "date": "file_name", "max_age_days": 92}, {"id": "R07", "control": "ECC 1-8-3", "ask": "Last internal review report presented to the committee", "glob": "records/*-internal-review.md", "date": "file_name", "max_age_days": 365}, {"id": "R08", "control": "ECC 1-8-1", "ask": "Self-assessment action plan export", "glob": "exports/*-ecc-action-plan.csv", "date": "file_name", "max_age_days": 92} ] } ``` في الملف أعلاه لاحظ التالي: - لكل طلب نمط يحدد مكان أدلته في المخزن، وطريقة لمعرفة تاريخ الدليل: من اسم مجلد التشغيل `run`، أو من بداية اسم الملف `file_name`، أو من حقل `approved_on` في رأس الوثيقة `front_matter`. - لكل طلب أقصى عمر مقبول بالأيام، وهو قرار يكتبه الفريق بحسب طبيعة الدليل: سنة للسياسة المعتمدة لأن مراجعتها سنوية، وسبعة أيام لإعداد السيرفرات لأن التدقيق تشغيلي ويريد دليلاً قريباً من الحاضر، وربع سنة لاختبار الاستعادة لأن الهدف في نظام ISO ربع سنوي. - تاريخ التدقيق 15 نوفمبر 2026، أي بعد ثلاثة أسابيع من آخر تشغيل للجامع. والسكربت التالي، ونحفظه باسم `readiness.py`، يمر على الطلبات، ثم يتحقق من سلسلة الأدلة كما يفعل `verify.py` في مقال الجمع، ثم يختار عينة كما يختارها المدقق: ```python # Pre-audit check: for every item on the auditor's request list (PBC), find the newest evidence, check its age # against the audit date, read the collector's verdict, verify the evidence chain, and draw a reproducible sample. import datetime, glob, hashlib, json, pathlib, random, re, sys store = pathlib.Path(sys.argv[1] if len(sys.argv) > 1 else "store") pbc = json.load(open(sys.argv[2] if len(sys.argv) > 2 else "pbc.json", encoding="utf-8")) audit = datetime.date.fromisoformat(pbc["audit_date"]) def evidence_date(path, how): if how == "run": # evidence/2026-10-26T055343Z/web1/x.txt return datetime.date.fromisoformat(path.relative_to(store).parts[1][:10]) if how == "file_name": # 2026-10-26-risk-register.csv return datetime.date.fromisoformat(path.name[:10]) if how == "front_matter": # approved_on: 2026-10-20 m = re.search(r"^approved_on:\s*(\d{4}-\d{2}-\d{2})", path.read_text(encoding="utf-8"), re.M) return datetime.date.fromisoformat(m.group(1)) if m else None def collector_status(path): # the verdict the collector wrote for this file man = json.loads((store / path.relative_to(store).parts[0] / path.relative_to(store).parts[1] / "manifest.json").read_text()) rel = str(path.relative_to(store)).replace("\\", "/") return next((i["status"] for i in man["items"] if i["file"] == rel), "?") print(f"audit date {audit} store {store}") for r in pbc["requests"]: files = [pathlib.Path(p) for p in glob.glob(str(store / r["glob"]))] if not files: print(f"{r['id']} {r['control']:12} MISSING {r['ask']}") continue dated = sorted((evidence_date(f, r["date"]), f) for f in files) newest = dated[-1][0] if r["date"] == "run": # several runs a day: keep only the last run last_run = max(f.relative_to(store).parts[1] for f in files) latest = [f for f in files if f.relative_to(store).parts[1] == last_run] else: latest = [f for d, f in dated if d == newest] age = (audit - newest).days state = "READY" if age <= r["max_age_days"] else "STALE" note = "" if r["date"] == "run": verdicts = sorted({f"{f.parent.name}:{collector_status(f)}" for f in latest}) note = " ".join(verdicts) print(f"{r['id']} {r['control']:12} {state:8} newest {newest} ({age} days, max {r['max_age_days']}) {note}") # evidence chain, as in verify.py prev, chain = None, "ok" for m in sorted(store.glob("evidence/*/manifest.json")): data = json.loads(m.read_text(encoding="utf-8")) expected = hashlib.sha256(prev.read_bytes()).hexdigest() if prev else None if data["previous_manifest_sha256"] != expected: chain = f"BROKEN at {m.parent.name}" for i in data["items"]: if hashlib.sha256((store / i["file"]).read_bytes()).hexdigest() != i["sha256"]: chain = f"TAMPERED {i['file']}" prev = m print("evidence chain:", chain) # a reproducible sample, the way an auditor picks items: same seed, same sample runs = sorted(p.name for p in store.glob("evidence/*") if p.is_dir()) rng = random.Random(pbc["audit_date"]) print("sample:", rng.choice(runs), "/", rng.choice(["web1", "web2"]), "/", rng.choice(["ssh-effective-config", "time-sources", "admin-accounts"])) ``` في الكود أعلاه لاحظ التالي: - لأدلة الجامع يأخذ السكربت آخر تشغيل فقط، والسبب مشكلة واجهناها في النسخة الأولى منه: كانت التشغيلات الثلاثة في اليوم نفسه، فجمع السكربت أحكامها كلها في سطر واحد، فظهر لكل سيرفر «pass» و«fail» معاً، وهذا لا يفيد أحداً. - حكم الجامع يقرأ من ملف البيان نفسه وليس من الملف، لأن البيان هو الذي يقول هل نجح الفحص، والملف يقول ماذا جمع فقط. - العينة تختار بمولد عشوائي بذرته تاريخ التدقيق، فإذا أعاد أي شخص تشغيل السكربت بالتاريخ نفسه حصل على العينة نفسها، وهذا ما يجعل العينة قابلة للمراجعة. ونشغله على المخزن: ```bash docker run --rm -v "$PWD:/w" -w /w python:3.13.17-slim python readiness.py store ``` والمخرج سوف يكون كما يلي: ```text audit date 2026-11-15 store store R01 ECC 1-3-1 READY newest 2026-10-20 (26 days, max 365) R02 ECC 1-5-2 READY newest 2026-10-26 (20 days, max 90) R03 ECC 2-2-3-2 MISSING MFA status of every administrator account R04 ECC 2-3-3-4 STALE newest 2026-10-26 (20 days, max 7) web1:pass web2:pass R05 ECC 2-3-2 STALE newest 2026-10-26 (20 days, max 7) web1:error web2:fail R06 ECC 2-9-3-3 MISSING Last restore test record R07 ECC 1-8-3 MISSING Last internal review report presented to the committee R08 ECC 1-8-1 READY newest 2026-10-25 (21 days, max 92) evidence chain: BROKEN at 2026-10-26T075211Z sample: 2026-10-26T075211Z / web2 / time-sources ``` والشكل التالي يعرض النتيجة نفسها بالطريقة التي عرضها الفريق على المدير: ![جدول ثمانية طلبات: ثلاثة جاهزة، واثنان قديمان أحدهما بحكم web1:error web2:fail، وثلاثة مفقودة هي MFA واختبار الاستعادة وتقرير المراجعة الداخلية، وتحته سلسلة الأدلة مقطوعة عند 2026-10-26T075211Z والعينة المختارة](https://arabroot.io/content/images/2026/10/audit-readiness-04-readiness.webp) ثلاثة جاهزة واثنان قديمان وثلاثة مفقودة، وسلسلة مقطوعة، قبل ثلاثة أسابيع من التدقيق في المخرج أعلاه لاحظ التالي، سطراً سطراً: - **R01 وR02 وR08 جاهزة:** السياسة معتمدة في 20 أكتوبر، وسجل المخاطر عمره 20 يوماً، وخطة العمل من التقييم الذاتي عمرها 21 يوماً، وكلها داخل الحدود. - **R03 مفقود:** لا يوجد دليل على حالة MFA للمديرين، وهذا متوقع، فقد قيمت الشركة 2-2-3-2 «غير ملتزم» في تقييمها الذاتي، والجامع لا يجمع من مزود الهوية بعد. لكن المفقود هنا ليس الدليل فقط، وإنما الضابط نفسه، فالرد على هذا الطلب ليس ملفاً، وإنما خطة المعالجة بتاريخها ومالكها من سجل المخاطر. - **R04 قديم:** مصادر الوقت سليمة على السيرفرين، لكن آخر دليل عمره 20 يوماً والحد سبعة، والسبب أن الجامع في المختبر توقف بعد التجربة. وفي الواقع هذا السطر يعني أن الجامع اليومي لم يعمل منذ ثلاثة أسابيع ولم ينتبه أحد، وهذا بحد ذاته ملاحظة على الفعالية التشغيلية للجامع. - **R05 قديم، والأسوأ أنه مخالف:** آخر تشغيل يقول `web1:error` لأن الجامع فقد صلاحيته على web1، و`web2:fail` لأن دخول root مفتوح على web2، وهما الحالتان اللتان صنعناهما عمداً في مقال الجمع. ولاحظ أن الحالة «قديم» تخفي المشكلة الحقيقية، لذلك يطبع السكربت حكم الجامع بجانب العمر. - **R06 وR07 مفقودان:** لا يوجد محضر اختبار استعادة، ولا تقرير مراجعة داخلية معروض على لجنة، والأول ضابط غير مطبق، والثاني عمل حوكمة لم يحدث بعد. - **سلسلة الأدلة مقطوعة:** وهذا ما لم يتوقعه أحد. والسبب أن تجربة التعديل في مقال الجمع، حين عدلنا دليلاً ثم أعدنا حساب البيان لإخفاء التعديل، تركت أثرها في المخزن، والسكربت كشفها كما صمم. وفي الواقع لو رأى المدقق هذا السطر قبل أن تراه أنت فهو يعني أن كل أدلة الجامع موضع شك، لذلك لا تقم أبداً بتسليم مخزن أدلة قبل أن تتحقق من سلسلته، وإذا انقطعت فاشرح السبب كتابة، واعزل التشغيلات المتأثرة. - **العينة:** اختار السكربت دليل مصادر الوقت على web2 من التشغيل الثاني، وهو موجود وسليم، لكن التشغيل الثاني نفسه هو الذي انقطعت عنده السلسلة، فالعينة وقعت في المنطقة المشكوك فيها، وهذا ما يحدث في التدقيق الحقيقي أكثر مما تتمنى. ### نجرب: ماذا لو كان التدقيق بعد يومين فقط؟ غيرنا تاريخ التدقيق إلى 28 أكتوبر 2026 في نسخة من الملف، وشغلنا السكربت عليها بـ `python readiness.py store pbc-early.json`: ```text audit date 2026-10-28 store store R01 ECC 1-3-1 READY newest 2026-10-20 (8 days, max 365) R02 ECC 1-5-2 READY newest 2026-10-26 (2 days, max 90) R03 ECC 2-2-3-2 MISSING MFA status of every administrator account R04 ECC 2-3-3-4 READY newest 2026-10-26 (2 days, max 7) web1:pass web2:pass R05 ECC 2-3-2 READY newest 2026-10-26 (2 days, max 7) web1:error web2:fail R06 ECC 2-9-3-3 MISSING Last restore test record R07 ECC 1-8-3 MISSING Last internal review report presented to the committee R08 ECC 1-8-1 READY newest 2026-10-25 (3 days, max 92) evidence chain: BROKEN at 2026-10-26T075211Z sample: 2026-10-26T055343Z / web2 / admin-accounts ``` وهنا الدرس الذي جعلنا نطبع حكم الجامع بجانب كل سطر: R05 أصبح «READY» لأن عمره يومان، ومحتواه ما زال `web1:error web2:fail`. أي أن الجاهزية بمعنى «الدليل موجود وحديث» ليست الالتزام، والفحص الذي يقيس العمر وحده يعطيك ثقة كاذبة. ولاحظ أيضاً أن العينة تغيرت، لأن البذرة تاريخ التدقيق، وهذا مقصود: كل تدقيق له عينته، والعينة نفسها تعاد لنفس التدقيق. ## كيف يختار المدقق العينة؟ في نموذج إجراء التدقيق خطوة اسمها تحديد العينات والأدلة المطلوبة، ويقول النموذج إن تحديدها يجب أن يستند إلى النطاق، وإن نهجاً قائماً على المخاطر يجب أن يطبق. وهذا يعني في الواقع أمرين يجب أن تجهز لهما. الأول أن المدقق يختار العينة من مجتمع Population كامل، مثل كل الموظفين الذين غادروا خلال الفترة، أو كل السيرفرات في النطاق، لذلك أول ما يطلبه هو القائمة الكاملة، ثم يختار منها. وإذا كانت القائمة ناقصة فقد خسرت قبل أن يختار، فالسيرفر الذي ليس في سجل الأصول لن يختاره المدقق، لكنه إذا اكتشفه بطريقة أخرى فسوف يكتب ملاحظة أخطر من أي ملاحظة على سيرفر في السجل. والثاني أن النهج القائم على المخاطر يعني أن المدقق يختار العينة حيث يتوقع المشكلة: الحسابات المميزة قبل الحسابات العادية، والسيرفرات المكشوفة على الإنترنت قبل الداخلية، والفترة التي حدث فيها تغيير كبير قبل الفترة الهادئة. ولذلك لا تقم بتجهيز أفضل أدلتك فقط، فالمدقق الجيد يختار أسوأها، وجهز أدلة الأماكن التي تعرف أنها الأضعف، ومعها ما يبين أنك تعرفها وتعالجها. ### مثال كامل: عينة المغادرين أوضح مثال على اختبار العينة هو سحب صلاحيات من يغادر. فالضابط 1-9-5 في ECC يطلب أن تراجع صلاحيات العاملين وتلغى مباشرة عند انتهاء أو إنهاء خدمتهم. وكلمة «مباشرة» لا تحددها الضوابط بالساعات، لذلك يختبر المدقق على ما كتبته الشركة في سياستها، وفي سياسة الوصول الإداري التي كتبها الفريق في مقال السياسات بند صريح: يجب سحب صلاحية المدير في يوم انتهاء عمله، من مزود الهوية وليس من كل سيرفر. وهذا يعني أن السياسة نفسها هي المعيار الذي سوف تقاس عليه، فإذا كتبت فيها ما لا تستطيع تنفيذه، فقد كتبت ملاحظتك بيدك. ويسير الاختبار في التدقيق التشغيلي هكذا: 1. **المجتمع:** يطلب المدقق من الموارد البشرية، وليس من فريق التقنية، قائمة كل من انتهت خدمته خلال الفترة مع تاريخ آخر يوم عمل. والسبب أن فريق التقنية قد ينسى في قائمته الشخص نفسه الذي نسي أن يعطل حسابه. 2. **العينة:** في شركة من اثني عشر شخصاً قد يكون المغادرون خلال الفترة اثنين أو ثلاثة، وفي هذه الحالة يفحص المدقق الجميع، فلا معنى لعينة من مجتمع صغير. 3. **الدليل لكل شخص:** وقت تعطيل الحساب في مزود الهوية من سجل التدقيق فيه، وإزالة العضوية من مستودعات الكود والحساب السحابي، وإزالة مفتاح SSH ومجموعة sudo من كل سيرفر، وتذكرة الطلب التي بدأت كل ذلك. 4. **المقارنة:** تاريخ آخر يوم عمل مقابل وقت كل تعطيل، وأي فرق أكبر مما في السياسة استثناء يحتاج تفسيراً. ولاحظ ما تفترضه عبارة «من مزود الهوية وليس من كل سيرفر»: أن السيرفرات لا تعرف أي حساب إداري إلا عبر مزود الهوية. فإذا بقي على سيرفر حساب محلي في مجموعة sudo أنشئ قبل ربط السيرفرات بمزود الهوية، فإن تعطيل الحساب المركزي لا يلغيه، والسياسة مطبقة على الورق والصلاحية باقية في الواقع. وهذا ما يبحث عنه المدقق في الخطوة الثالثة. والخطوة الثالثة هي أيضاً التي تكشف إن كانت الأدلة تجمع يومياً أم لا. فتعطيل الحساب في مزود الهوية له سجل يحمل وقته، لكن عضوية مجموعة sudo على السيرفر ليس لها سجل بهذا الوضوح، ودليلها الوحيد صورة لحالة المجموعة في تاريخ معين. وهذا بالضبط ما يجمعه فحص `admin-accounts` في جامع الأدلة، الذي يسجل مخرج `getent group sudo` على كل سيرفر في كل تشغيل. فإذا غادر موظف في يوم ما، فتشغيل اليوم التالي للجامع يثبت أن اسمه لم يعد في المجموعة، أو يثبت أنه ما زال فيها. وفي الحالتين الدليل موجود ومؤرخ، والمدقق لا يحتاج أن يصدق أحداً. وفي فحص الجاهزية لم نضع هذا الطلب ضمن الطلبات الثمانية، لأن أحداً لم يغادر الشركة خلال فترة المختبر، والسكربت لا يستطيع أن يفحص مجتمعاً غير موجود. لكن هذا بالضبط ما يجب أن تجهز له: إذا كانت قائمة المغادرين فارغة فاكتب ذلك صراحة بخطاب من الموارد البشرية، فالقائمة الفارغة المؤكدة دليل، والقائمة التي لم يطلبها أحد ليست دليلاً. ## يوم التدقيق جلسات التدقيق ليست امتحاناً شفهياً، وإنما فحص لأدلة، والفرق كبير في كيفية التصرف. وفي القصة اتفق الفريق على قواعد بسيطة قبل اليوم الأول: - **شخص واحد ينسق:** يستقبل الطلبات أثناء الجلسات، ويسجلها برقم، ويعطي كل طلب مالكه وموعده، ويتأكد أن كل ما يسلم للمدقق مسجل في قائمة واحدة بتاريخ تسليمه. - **أجب عن السؤال المطروح فقط:** الإجابة الطويلة التي تتطوع فيها بتفاصيل لم يسأل عنها تفتح أسئلة جديدة، والإجابة الصحيحة القصيرة مع الدليل تغلق السؤال. - **«لا أعرف، وسوف أتحقق» إجابة مقبولة:** أما التخمين الذي يظهر خطؤه لاحقاً فيضر بثقة المدقق في كل الإجابات الأخرى. - **أر ولا تصف:** افتح الشاشة، وشغل الأمر، واعرض الإعداد الحي، فإعادة الأداء أمام المدقق أقوى دليل، كما رأينا في ترتيب الأساليب. - **لا تقم بإصلاح شيء أثناء الجلسة ثم تعرضه:** المدقق يعرف الفرق بين الضابط الذي يعمل منذ أشهر والضابط الذي أصلح قبل ساعة، وتاريخ الدليل يكشفه. والأفضل أن تقول: «هذه ملاحظة صحيحة، وهذه خطة معالجتها في سجل المخاطر». ## تسليم الأدلة: الدليل نفسه بيانات حساسة في المرحلة الثالثة من نموذج الإجراء، خطوة جمع الأدلة والتحقق منها، جملتان يتجاوزهما كثيرون: يجب نقل الأدلة بشكل آمن، ويجب ضمان أمن الأدلة المجمعة لتجنب تسريب البيانات. وحين نظر الفريق إلى ما سوف يسلمه فهم السبب: إعداد SSH الكامل لكل سيرفر، وإعداد nginx بمساراته الداخلية، وأسماء الحسابات المميزة، وأرقام الإصدارات لكل حزمة، وسجل مخاطر يقول بالضبط أين الضعف ومتى سوف يعالج. هذه الملفات معاً خريطة كاملة لمن يريد أن يهاجم الخدمة، وإرسالها في ملف مضغوط بالبريد الإلكتروني يصنع مخاطرة أكبر من أي ملاحظة قد يكتبها المدقق. وقد سلم الفريق الأدلة بخمس قواعد: - **مشاركة للقراءة فقط بمدة محددة:** مجلد على خدمة الشركة نفسها، بحساب للمدقق يقرأ ولا يعدل، وتنتهي صلاحيته بعد انتهاء التدقيق بمدة متفق عليها، وليس رابطاً عاماً يعمل لكل من يحمله. - **بصمة لكل ملف:** يرسل مع الأدلة ملف البيان الذي يحمل SHA-256 لكل ملف، كما يبنيه الجامع، فيستطيع المدقق أن يتحقق بنفسه أن ما فحصه هو ما سلم، وتستطيع الشركة أن تثبت لاحقاً ما الذي سلمته بالضبط. - **سجل تسليم:** لكل ملف رقم الطلب الذي يجيب عنه، وتاريخ التسليم، ومن سلمه. وهذا السجل نفسه هو ما يحتاجه المدقق لقائمة المرفقات في تقريره، كما سنرى. - **إخفاء ما لا يحتاجه الدليل:** الأسرار في ملفات الإعداد، مثل مفاتيح الواجهات أو كلمات مرور قواعد البيانات، تستبدل بعلامة قبل التسليم، ويكتب ذلك في سجل التسليم حتى لا يظن المدقق أن الملف عدل لإخفاء شيء. - **لا بيانات مرضى في أي دليل:** الخدمة تحفظ مواعيد مرضى، وأي لقطة شاشة من لوحة الإدارة أو مقتطف سجل قد يحمل اسماً أو رقم جوال. ونقل بيانات شخصية إلى طرف لا يحتاجها لغرض التدقيق يفتح سؤالاً تحت نظام حماية البيانات الشخصية، كما شرحنا في [مقال PDPL للخدمات المستضافة](https://arabroot.io/articles/%D8%AD%D9%85%D8%A7%D9%8A%D8%A9-%D8%A7%D9%84%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA-%D8%A7%D9%84%D8%B4%D8%AE%D8%B5%D9%8A%D8%A9-pdpl-%D9%84%D9%84%D8%AE%D8%AF%D9%85%D8%A7%D8%AA-%D8%A7%D9%84%D9%85%D8%B3%D8%AA%D8%B6%D8%A7%D9%81%D8%A9/)، فالدليل الذي يثبت أن السجلات تحفظ يكفيه عدد الأسطر وتاريخها، ولا يحتاج محتواها. وفي المقابل، اسأل المدقق كيف سوف يحفظ الأدلة عنده، وكم يحتفظ بها، وكيف يتلفها. وهذا سؤال لا يزعج المدقق الجيد، لأن نموذج الإجراء نفسه يطلب منه حماية الأدلة، والمدقق الذي لا يملك إجابة عنه يخبرك بشيء مهم عن جودة تدقيقه. ## الملاحظة، والرد الذي يغلقها الملاحظة الجيدة التي يكتبها المدقق، والرد الجيد الذي تكتبه أنت، لهما بنية معروفة، والشكل التالي يبينها على ملاحظة حقيقية من القصة: دخول root المفتوح على web2، الذي كشفه الجامع في تشغيله الثاني، ووقع في عينة المدقق: ![يمين: ما يكتبه المدقق من حالة ومعيار وسبب وأثر وتوصية عن دخول root على web2، ويسار: ما يكتبه الطرف الخاضع للتدقيق من مالك وتصحيح وسبب جذري وموعد ودليل إغلاق](https://arabroot.io/content/images/2026/10/audit-readiness-05-finding.webp) الرد الذي يعالج السبب الجذري يغلق الملاحظة، والرد الذي يعالج الحالة يؤجلها إلى التدقيق القادم والفرق الذي يجب أن تنتبه إليه في الرد بين التصحيح والسبب الجذري. فالتصحيح هو إعادة الإعداد إلى `PermitRootLogin no`، وهو ضروري لكنه لا يمنع التكرار، والسبب الجذري أن المطور احتاج دخولاً طارئاً ولم يجد طريقاً معتمداً، فإذا لم تعالج هذا فسوف يتكرر الأمر في الطارئ القادم. لذلك كان رد الشركة حساب طوارئ بإجراء استثناء مسجل كما في [سياسة الوصول الإداري](https://arabroot.io/articles/%D8%B3%D9%8A%D8%A7%D8%B3%D8%A7%D8%AA-%D8%A7%D9%84%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%B3%D9%8A%D8%A8%D8%B1%D8%A7%D9%86%D9%8A-%D9%82%D9%88%D8%A7%D9%84%D8%A8-%D9%88%D9%83%D9%8A%D9%81-%D8%AA%D9%83%D8%AA%D8%A8-%D8%B3%D9%8A%D8%A7%D8%B3%D8%A9-%D8%AA%D8%B7%D8%A8%D9%82/)، مع اختبار للإجراء نفسه، ودليل الإغلاق تشغيلات الجامع بعد الموعد ومحضر الاختبار. وهذا الرد هو نفسه الإجراء التصحيحي الذي يطلبه البند العاشر في ISO/IEC 27001 كما ذكرنا في [مقال ISO 27001](https://arabroot.io/articles/iso-27001-%D8%A8%D8%A7%D8%AF%D9%88%D8%A7%D8%AA-%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D8%A7%D9%84%D9%85%D8%B5%D8%AF%D8%B1-%D9%85%D9%86-%D8%A7%D9%84%D9%85%D8%AE%D8%A7%D8%B7%D8%B1-%D8%A7%D9%84%D9%89-%D8%A7%D9%84%D8%AA%D8%AF%D9%82%D9%8A%D9%82/#improvement)، فاكتبه بالشكل نفسه للاثنين. ولاحظ أيضاً أن الملاحظة التي يكتشفها الجامع قبل المدقق، ويكون لها تذكرة واستثناء أو إصلاح، تختلف كثيراً عن الملاحظة التي يكتشفها المدقق وحده. فالأولى تثبت أن ضابط المراقبة يعمل، والثانية تثبت أنه لا يعمل، والمدقق يكتب ذلك في تقريره. ## تقرير التدقيق: كيف تقرؤه قبل أن يصلك إذا كان المدقق يعمل بنموذج الهيئة، فأنت تستطيع أن ترى شكل التقرير قبل التدقيق. فقد حولنا [نموذج تقرير تدقيق الأمن السيبراني](https://cdn.nca.gov.sa/api/files/public/upload/d1621050-32da-48bd-9185-3120cc39e460%5FReport%5FCybersecurity-Audit%5FTemplate%5Far%5Fv0.4.pdf?ref=arabroot.io) إلى نص، فوجدناه من جزأين رئيسيين وملحقين يشرحان كل حقل. الجزء الأول ملخص التدقيق، وفيه أحد عشر حقلاً، منها معرف التدقيق، ويقترح الملحق أن يكون بنوع التدقيق والسنة والرقم الفريد مثل IT-2022-123، ونوع التدقيق بثلاث قيم: التصميم، والعمليات التشغيلية، أو كلاهما، ونطاقه، والوثائق المرجعية ومنها تقارير التدقيقات السابقة، ثم نتيجة التدقيق، ولها ثلاث قيم فقط: فعالة، أو فعالة جزئياً، أو غير فعالة. وآخر حقل ملخص ما تم تنفيذه، مثل الوثائق التي روجعت والمقابلات التي أجريت. وهذا الحقل الأخير هو المكان الذي يظهر فيه أسلوب الفحص، فإذا كان كله مقابلات فهذا ما سوف يقرؤه المستشفى ومن بعده أي جهة تراجع عمله. والجزء الثاني جدول لكل ملاحظة، وفيه أحد عشر حقلاً أيضاً: رقم فريد للملاحظة مرتبط بمعرف التدقيق، وعنوانها ووصفها، ودرجة أهميتها بثلاث قيم: منخفض أو متوسط أو مرتفع، ثم رمز التوصية واسمها ووصفها وأولويتها، ثم ثلاثة حقول هي التي تكتبها أنت عملياً: وصف خطة المعالجة، والجهة المسؤولة عن إجراءات المعالجة، والموعد النهائي لاتخاذ الإجراءات، وأخيراً تعليق. وفي آخر التقرير قائمة مرفقات، لكل مرفق رقمه واسم الملف ورقم الملاحظة التي يرتبط بها. وما يعنيه هذا عملياً ثلاثة أمور. الأول أن ردك على كل ملاحظة يجب أن يملأ الحقول الثلاثة: خطة بخطوات، وشخصاً باسمه وليس «فريق التقنية»، وتاريخاً محدداً وليس «قريباً». والثاني أن قائمة المرفقات تربط كل دليل برقم ملاحظة، فإذا كان سجل التسليم الذي ذكرناه منظماً بأرقام الطلبات فهو يسهل هذا الربط على المدقق، ويقلل احتمال أن يسقط دليل في الطريق. والثالث أن «فعالة جزئياً» هي النتيجة الأكثر واقعية لشركة في تدقيقها الأول، وفي القصة كان معروفاً قبل التدقيق أن ثلاثة ضوابط غير مطبقة، فالهدف الواقعي لم يكن «فعالة»، وإنما أن تكون كل ملاحظة معروفة مسبقاً وفي خطة معالجة لها مالك وموعد، فلا يجد المدقق ملاحظة لا يعرفها الفريق. ## بعد التدقيق: اللجنة، والمتابعة، والتدقيق القادم الضابط 1-8-3 لا ينتهي بتسلم التقرير، وإنما بعرضه على اللجنة الإشرافية والمسؤول الأول، بنطاقه وملاحظاته وتوصياته وإجراءاته التصحيحية وخطط معالجته. وفي شركة صغيرة قد تكون اللجنة الرئيس التنفيذي ومدير التقنية ومسؤول الأمن، والمهم أن يكون هناك محضر بالتاريخ والحضور والقرارات، وهذا المحضر نفسه هو الدليل الذي كان مفقوداً في الطلب R07 من فحص الجاهزية. ثم تدخل كل ملاحظة في المتابعة: في سجل المخاطر إذا كانت تعكس مخاطرة لم تعالج، وفي خطة العمل في أداة الامتثال بمالكها وموعدها، وفي نظام التذاكر بخطوات تنفيذها. وتذكر ما في نموذج الهيئة: أول خطوة في تنفيذ التدقيق القادم هي التحقق من معالجة ملاحظات التدقيق السابق. لذلك فالاستعداد للتدقيق القادم يبدأ في اليوم التالي لانتهاء هذا التدقيق، بإغلاق الإجراءات في مواعيدها، وبجمع دليل الإغلاق بالطريقة نفسها التي تجمع بها أي دليل آخر. ## وماذا عن مدقق ISO ومدقق SOC 2؟ كل ما سبق ينطبق على أي تدقيق، والاختلاف في المعيار الذي يدقق عليه، ومن يعطي النتيجة. فمدقق الجهة المانحة لشهادة ISO/IEC 27001 يبدأ عادة بوثيقة النطاق وبيان قابلية التطبيق، ويريد أن يرى أن نظام الإدارة دار دورة كاملة بتدقيق داخلي ومراجعة إدارة، كما شرحنا في [مقال ISO 27001](https://arabroot.io/articles/iso-27001-%D8%A8%D8%A7%D8%AF%D9%88%D8%A7%D8%AA-%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D8%A7%D9%84%D9%85%D8%B5%D8%AF%D8%B1-%D9%85%D9%86-%D8%A7%D9%84%D9%85%D8%AE%D8%A7%D8%B7%D8%B1-%D8%A7%D9%84%D9%89-%D8%A7%D9%84%D8%AA%D8%AF%D9%82%D9%8A%D9%82/)، والجهة المانحة الموثوقة معتمدة، وتستطيع أن تتحقق من اعتمادها لدى [المركز السعودي للاعتماد](https://saac.gov.sa/en/services/certification-bodies/?ref=arabroot.io). ومدقق SOC 2 محاسب قانوني يكتب رأياً عن ضوابط خدمتك لعملائك، والتحذير الذي نشرته مجلة المحاسبة من التقارير السريعة يعني لك شيئاً عملياً: اسأل عن أسلوب الفحص والعينات قبل أن توقع، فالتقرير الذي يعتمد على الاستفسار وحده قد يرفضه العميل الذي طلبه. وفي كل الأحوال، مخزن الأدلة المؤرخ والمسلسل، وسجل المخاطر بمالكيه، وخطة العمل بمواعيدها، تخدم كل المدققين بالطريقة نفسها. ## أخطاء شائعة - **جمع الأدلة في أسبوع التدقيق:** يثبت الحاضر فقط، ويفشل في أي عينة من الفترة. - **الاعتماد على الاستفسار:** «نحن نفعل ذلك» ليست دليلاً، وكلما زادت إجاباتك الشفهية ضعف التقرير. - **قياس الجاهزية بالعمر وحده:** كما رأينا في R05، الدليل الحديث قد يكون دليلاً على المخالفة. - **تسليم مخزن أدلة دون التحقق من سلسلته:** سطر «BROKEN» واحد يجعل كل الأدلة موضع شك. - **قائمة مجتمع ناقصة:** سجل أصول لا يضم كل السيرفرات يجعل كل عينة مشكوكاً فيها. - **إصلاحات أثناء الجلسة:** يكشفها تاريخ الدليل، وتضر بالثقة أكثر من الملاحظة نفسها. - **رد يعالج الحالة لا السبب:** الملاحظة تعود في التدقيق القادم، وأول خطوة فيه التحقق من الملاحظات السابقة. - **إرسال الأدلة في ملف مضغوط بالبريد:** الأدلة معاً خريطة للخدمة، ونموذج الإجراء نفسه يطلب نقلها بأمان. - **سياسة تعد بما لا ينفذ:** المدقق يختبر على ما كتبته أنت، فالبند الذي لا تستطيع تطبيقه ملاحظة جاهزة. - **تقرير بلا محضر لجنة:** الضابط 1-8-3 يطلب العرض، والعرض يحتاج دليلاً. ## قائمة تحقق قبل التدقيق بثلاثة أسابيع | السؤال | كيف تتحقق | | ------------------------------------------------------------ | ------------------------------------- | | هل طلبت خطة التدقيق ونوعه: تصميم أم تشغيل أم الاثنان؟ | عمود «نوع التدقيق» في سجل خطة التدقيق | | هل لكل طلب في القائمة رقم ومالك وموعد داخلي؟ | جدول متابعة الطلبات | | هل كل دليل يحمل تاريخه ومصدره؟ | أسماء الملفات ورؤوس الوثائق والبيانات | | هل الأدلة أحدث من الحد المقبول لكل نوع؟ | readiness.py | | هل قرأت حكم كل دليل وليس عمره فقط؟ | عمود حكم الجامع | | هل سلسلة الأدلة سليمة حتى المرساة؟ | verify.py والمرساة الخارجية | | هل قوائم المجتمع كاملة: الأصول، والمغادرون، والتغييرات؟ | سجل الأصول ونظام الموارد البشرية وGit | | هل الأدلة تسلم بمشاركة للقراءة فقط وبصمة لكل ملف وسجل تسليم؟ | ملف البيان وسجل التسليم | | هل خلت الأدلة من الأسرار وبيانات المرضى؟ | مراجعة كل ملف قبل رفعه | | هل الضوابط غير المطبقة لها خطة معالجة بمالك وموعد؟ | سجل المخاطر وخطة العمل | | هل ملاحظات التدقيق السابق مغلقة بدليل؟ | خطة المعالجة | | هل تقرير المراجعة الداخلية معروض على اللجنة بمحضر؟ | محضر اللجنة الإشرافية | ## الخلاصة - ECC تفرق بين مراجعة إدارة الأمن السيبراني في 1-8-1 والتدقيق المستقل في 1-8-2، وتطلب عرض النتائج على اللجنة في 1-8-3. - نموذج إجراء التدقيق من الهيئة يقسمه إلى ست مراحل، وأول خطوة في التنفيذ التحقق من معالجة الملاحظات السابقة. - الأساليب أربعة من الاستفسار إلى إعادة الأداء، والاستفسار وحده لا يكفي لأي ضابط مهم. - التدقيق التشغيلي يختار عينات من الفترة، والدليل اليومي المؤرخ هو ما يجيب عنها. - فحص الجاهزية في التجربة كشف ثلاثة طلبات مفقودة، ودليلين قديمين أحدهما يثبت مخالفة، وسلسلة أدلة مقطوعة، قبل أن يراها المدقق. - الرد على الملاحظة يعالج السبب الجذري بمالك وموعد ودليل إغلاق، وإلا عادت في التدقيق القادم. وبهذا تكتمل قصة شركة منصة الحجز في هذه المرحلة: من المصطلحات والأطر، إلى الضوابط وأدواتها، إلى الامتثال والمخاطر والأدلة، وصولاً إلى التدقيق. والمقالات كلها في البطاقات التالية: [![](https://arabroot.io/content/images/2026/10/security-frameworks-cover-cover.webp)دليلأطر الأمن السيبراني Frameworks: أيها تحتاج مؤسستك؟الفرق بين ECC وISO 27001 وNIST CSF وSOC 2 في الإلزام وطريقة الإثبات وما تحصل عليه، وأربعة أسئلة تحدد بها ما تحتاجه مؤسستك.](https://arabroot.io/articles/%D8%A7%D8%B7%D8%B1-%D8%A7%D9%84%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%B3%D9%8A%D8%A8%D8%B1%D8%A7%D9%86%D9%8A-ecc-%D9%88-iso-27001-%D9%88-nist-csf-%D9%88-soc-2/)[![](https://arabroot.io/content/images/2026/10/ecc-open-source-cover-cover.webp)دليلتحقيق ضوابط ECC بأدوات مفتوحة المصدر Open Sourceخريطة تربط كل ضابط فرعي في الضوابط الأساسية ECC بالأداة مفتوحة المصدر التي تحققه وبالمقال الذي شرحها، مع إثبات ضابطين بمخرج حقيقي.](https://arabroot.io/articles/%D8%AA%D8%AD%D9%82%D9%8A%D9%82-%D8%B6%D9%88%D8%A7%D8%A8%D8%B7-ecc-%D8%A8%D8%A7%D8%AF%D9%88%D8%A7%D8%AA-%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D8%A7%D9%84%D9%85%D8%B5%D8%AF%D8%B1/)[![](https://arabroot.io/content/images/2026/10/ciso-assistant-cover-cover.webp)دليلإدارة الامتثال Compliance مع CISO Assistant على سيرفركنشغل CISO Assistant ونحمل فيه ضوابط ECC-2:2024 ونقيم منصة حقيقية ونربطها بالضوابط والأدلة ونصدر التقرير، مع كل مشكلة واجهناها في الطريق.](https://arabroot.io/articles/%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%A7%D9%84%D8%A7%D9%85%D8%AA%D8%AB%D8%A7%D9%84-%D9%85%D8%B9-ciso-assistant/)[![](https://arabroot.io/content/images/2026/10/risk-register-cover-cover.webp)دليلسجل المخاطر Risk Register مع SimpleRisk على سيرفركنبني سجل مخاطر حقيقياً بنموذج الهيئة ثم بأداة SimpleRisk، ونرى لماذا أعطت الأداة كل المخاطر مستوى واحداً، وكيف تكتب منهجية تعطي الأرقام معناها.](https://arabroot.io/articles/%D8%B3%D8%AC%D9%84-%D8%A7%D9%84%D9%85%D8%AE%D8%A7%D8%B7%D8%B1-risk-register-%D9%85%D8%B9-simplerisk/)[![](https://arabroot.io/content/images/2026/10/evidence-collection-cover-cover.webp)دليلجمع أدلة الامتثال Evidence تلقائياً بدل لقطات الشاشةنبني جامع أدلة صغيراً يقرأ إعدادات السيرفرات عبر SSH ويحفظها بالهاش، ثم نجربه على تغيير مفاجئ ودليل معدل وجامع فقد صلاحيته بصمت.](https://arabroot.io/articles/%D8%AC%D9%85%D8%B9-%D8%A7%D8%AF%D9%84%D8%A9-%D8%A7%D9%84%D8%A7%D9%85%D8%AA%D8%AB%D8%A7%D9%84-%D8%AA%D9%84%D9%82%D8%A7%D8%A6%D9%8A%D8%A7/)[![](https://arabroot.io/content/images/2026/10/security-policies-cover-cover.webp)دليلسياسات الأمن السيبراني Policies: كيف تكتب سياسة تطبق فعلاً؟من أين تبدأ بقوالب السياسات العربية الرسمية، وكيف تحولها إلى صفحة يقرؤها الناس ويفحصها Git آلياً قبل أن يكتشف المدقق خاناتها الفارغة.](https://arabroot.io/articles/%D8%B3%D9%8A%D8%A7%D8%B3%D8%A7%D8%AA-%D8%A7%D9%84%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%B3%D9%8A%D8%A8%D8%B1%D8%A7%D9%86%D9%8A-%D9%82%D9%88%D8%A7%D9%84%D8%A8-%D9%88%D9%83%D9%8A%D9%81-%D8%AA%D9%83%D8%AA%D8%A8-%D8%B3%D9%8A%D8%A7%D8%B3%D8%A9-%D8%AA%D8%B7%D8%A8%D9%82/)[![](https://arabroot.io/content/images/2026/10/pdpl-hosting-cover-cover.webp)دليلحماية البيانات الشخصية PDPL للخدمات التي تستضيفهاما يعنيه نظام حماية البيانات الشخصية لمن يشغل خدمة على سيرفراته، من العقد مع العميل والإشعار بالتسرب إلى النسخ والسجلات والنقل للخارج.](https://arabroot.io/articles/%D8%AD%D9%85%D8%A7%D9%8A%D8%A9-%D8%A7%D9%84%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA-%D8%A7%D9%84%D8%B4%D8%AE%D8%B5%D9%8A%D8%A9-pdpl-%D9%84%D9%84%D8%AE%D8%AF%D9%85%D8%A7%D8%AA-%D8%A7%D9%84%D9%85%D8%B3%D8%AA%D8%B6%D8%A7%D9%81%D8%A9/)[![](https://arabroot.io/content/images/2026/10/iso27001-open-source-cover-cover.webp)دليلISO 27001 بأدوات مفتوحة المصدر من المخاطر إلى التدقيقكيف تبني شركة صغيرة نظام ISO/IEC 27001 على ما بنته لضوابط ECC، من النطاق وسجل المخاطر إلى بيان قابلية التطبيق والتدقيق الداخلي.](https://arabroot.io/articles/iso-27001-%D8%A8%D8%A7%D8%AF%D9%88%D8%A7%D8%AA-%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D8%A7%D9%84%D9%85%D8%B5%D8%AF%D8%B1-%D9%85%D9%86-%D8%A7%D9%84%D9%85%D8%AE%D8%A7%D8%B7%D8%B1-%D8%A7%D9%84%D9%89-%D8%A7%D9%84%D8%AA%D8%AF%D9%82%D9%8A%D9%82/) ## سجل التحديثات أكتوبر 2026: كتابة المقال، وقراءة قسم النطاق وقسم التطبيق والالتزام والمكون الفرعي 4-1 في ECC-2:2024، ونماذج إجراء التدقيق وتقريره وسجل خطته من صفحة أدوات الأمن السيبراني في الهيئة الوطنية للأمن السيبراني، وتجربة فحص الجاهزية على Python 3.13.17 بمخزن الأدلة الذي أنتجته مقالات المرحلة.