كيف يُحفظ الإصدار ومسار العمليات في مراجعة التقرير الموقع إلكترونيًا؟

ماذا ينبغي عمله عند مراجعة تقرير موقَّع إلكترونيًا؟

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

وبهذا يسهل العثور على التقرير الحالي؛ ولا تختفي النسخة القديمة صمتًا ولا تبدو كالإصدار الجديد. فالتوقيع الإلكتروني يدعم سلامة الإصدار الموقَّع. وعند تغيّر المحتوى تلزم دورة توقيع جديدة بدلًا من نقل التوقيع القديم إلى الملف الجديد.

بأي بنية يُحفظ سجل المراجعة؟

الجواب المختصر: يجب أن يكون كل إصدار منشور تحت هوية تقرير ثابتة كائنًا مستقلًا غير قابل للتعديل؛ وترتبط الإصدارات ببعضها بروابط «السابق» و«البديل».

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

أي أحداث يجب أن يسجلها أثر العمليات؟

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

• فتح طلب المراجعة ومبرره والسجل المصدر
• إنشاء المسودة والحقول المنقولة من الإصدار السابق
• تغييرات الحقول والمرفقات؛ ومرجع آمن للقيمتين القديمة والجديدة
• المراجعة الفنية والإعادة والموافقة وضوابط فصل المهام
• بصمة الملف المعروض للتوقيع ونتيجة عملية التوقيع
• الشهادة وحالة الإلغاء والطابع الزمني ونتيجة سياسة التحقق المستخدمة
• أحداث النشر والظهور في البوابة والتنزيل والتوزيع الخارجي
• انتقال الإصدار القديم إلى حالة «نُشرت مراجعة جديدة بدلًا منه»

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

كيف يُتحقق من التوقيعين القديم والجديد؟

يجب التحقق من كل إصدار بشكل مستقل. فحتى لو كان توقيع الإصدار القديم صحيحًا فهذا لا يعني أن الإصدار لا يزال حديثًا؛ وحداثة الإصدار الجديد لا تبطل دليل التوقيع القديم.

يوضح BTK أن التوقيع الإلكتروني الآمن يتيح كشف ما إذا عُدّلت البيانات الموقعة لاحقًا؛ وأنه على الطرف المتحقق فحص الشهادة المؤهلة وحالة السريان أو الإلغاء وقيود الاستخدام. ويحدد ETSI EN 319 102-1 V1.4.1 عملية التحقق، بينما يحدد ETSI TS 119 102-2 V1.4.1 التقرير المهيكل عن نتيجة التحقق. وعلى التطبيق أن يميز النتيجة على الأقل إلى صحيح, غير صحيح و غامضة/دليل ناقص ؛ وألا يعدّ خطأ الخدمة نجاحًا.

1. تُطابق بصمة الملف المطلوب وحاوية التوقيع.
2. تُقيَّم سلامة التوقيع وسلسلة الشهادات والحالة لحظة التوقيع وقيود الاستخدام.
3. تُفحص الطابع الزمني وأدلة التحقق طويل الأمد إن وُجدت.
4. تُربط النتيجة بسجل الإصدار مع وقت التحقق والسياسة/الإصدار وشرح الخطأ.
5. تحدد قاعدة عمل منفصلة حالة الحداثة أو البديلية أو الإلغاء أو المسودة.

ماذا يحمي الطابع الزمني وحزمة الأرشفة؟

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

يميز دليل BTK لملفات استخدام التوقيع الإلكتروني بين أشكال التوقيع الحاملة لبيانات التحقق وطويلة الأمد والأرشيفية. وينبغي أن تعالج استراتيجية الأرشفة تجديد الأدلة عند تقادم الأساليب التشفيرية أو السياسات كعملية مسجلة. فالتجديد لا يغيّر محتوى التقرير القديم؛ بل يضيف دليل حماية جديدًا مؤرخًا إلى حزمة الأدلة القائمة.

كيف يُعرض الإصدار القديم في البوابة والتوزيع؟

يجب إبراز المراجعة الحالية؛ مع بقاء الإصدار القديم قابلًا للعثور عليه للمستخدم المخوّل، وعرض حالته بوضوح «نُشرت مراجعة جديدة بدلًا منه».

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

لحقول عرض التحقق العام راجعوا دليل صفحة التحقق من التقرير عبر رمز QR يمكنكم الرجوع إليه.

كيف تُبنى الصلاحيات وأمن البيانات الشخصية؟

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

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

أي سيناريوهات يجب تجربتها في المرحلة التجريبية لدى VizyonTech؟

حل Vizyon Periyodik ، عند تقييمه، جرّب في عائلة تقارير واحدة السيناريوهات السلبية إلى جانب المراجعة الاعتيادية. فمعيار النجاح ليس فقط إنتاج ملف PDF جديد، بل أن يمنع النظام نشر إصدار خاطئ وإغلاق العمل بأدلة ناقصة.

1. جرّبوا تعديل الملف الموقَّع في موضعه؛ يجب على النظام طلب فتح مراجعة جديدة.
2. أرسلوا إلى الموافقة دون مبرر للتغيير؛ يجب أن يتوقف التدفق.
3. غيّروا بصمة الملف قبل التوقيع؛ يجب إلغاء عملية التوقيع.
4. افحصوا نتيجة التحقق عند تعذر الحصول على حالة الشهادة؛ يجب أن تبقى النتيجة غامضة.
5. افتحوا صفحة التحقق للمراجعة القديمة؛ يجب أن يظهر أنها ليست حديثة مع رابط الإصدار الجديد.
6. تتبعوا مهمة الإخطار وإثبات التسليم للنسخة القديمة الموزعة.

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