سياسة الاستجابة للحوادث الأمنية والإخطار بخرق أمن البيانات

تحدد سياسة Incident Response & Security Breach Notification Policy ("السياسة") الإطار الذي تتبعه ZynReach، المملوكة والمدارة بواسطة Zyntra Digital ("ZynReach" أو "الشركة" أو "نحن" أو "لنا") للتعامل مع الحوادث الأمنية والاشتباه في خروقات البيانات والحوادث السيبرانية التي قد تؤثر على أنظمة ZynReach أو البيانات التي تتم معالجتها من خلالها.

تهدف هذه السياسة إلى وضع إطار منظم من أجل:

• اكتشاف الحوادث الأمنية والإبلاغ عنها.
• تقييم طبيعة الحادث ونطاقه وتأثيره.
• احتواء الحوادث والحد من آثارها.
• التحقيق في الأسباب والآثار المحتملة.
• الحفاظ على الأدلة ذات الصلة.
• استعادة الأنظمة والخدمات بصورة آمنة.
• تحديد ما إذا كان الحادث يمثل Security Breach أو Personal Data Breach وفقًا للقانون المعمول به.
• تنفيذ الإخطارات المطلوبة قانونًا أو تعاقديًا.
• التواصل بصورة مناسبة مع العملاء والمتضررين.
• اتخاذ إجراءات تصحيحية لمنع تكرار الحادث.

تنطبق هذه السياسة على الحوادث التي قد تؤثر على موقع ZynReach ومنصتها والأنظمة والخدمات المرتبطة بها، وعلى الحوادث الناتجة عن مصادر متعددة، وذلك على النحو التالي:

• موقع ZynReach.
• منصة ZynReach.
• البنية التحتية التقنية.
• قواعد البيانات.
• أنظمة التخزين.
• الحسابات الإدارية.
• حسابات المستخدمين.
• واجهات API.
• خدمات الأطراف الثالثة.
• Sub-processors، بحسب الحالة.
• أنظمة البريد والاتصالات.
• النسخ الاحتياطية.
• الأنظمة الداخلية المتعلقة بتقديم الخدمة.
• هجمات إلكترونية.
• وصول غير مصرح به.
• تسريب بيانات.
• فقدان بيانات.
• كشف بيانات عن طريق الخطأ.
• برمجيات خبيثة.
• تصيد احتيالي.
• اختراق حساب.
• سوء استخدام الصلاحيات.
• أخطاء بشرية.
• أخطاء برمجية.
• سوء إعداد الأنظمة.
• ثغرات أمنية.
• حوادث لدى مزودي الخدمات.
• أي حدث آخر قد يؤثر بصورة جوهرية على سرية أو سلامة أو توافر المعلومات.

Security Incident: أي حدث أو مجموعة أحداث قد تؤثر على سرية أو سلامة أو توافر الأنظمة أو المعلومات أو الخدمات.

Security Breach: حادث أمني أدى أو يُحتمل أن يؤدي إلى وصول أو كشف أو تغيير أو فقدان أو تدمير غير مصرح به للمعلومات أو الأنظمة.

Personal Data Breach: خرق أمني يؤدي إلى تدمير أو فقدان أو تغيير أو كشف أو وصول غير مصرح به إلى بيانات شخصية، بالقدر الذي ينطبق فيه هذا التعريف بموجب القانون المعمول به.

Customer Data: البيانات التي يقوم العميل بإدخالها أو رفعها أو تخزينها أو معالجتها من خلال خدمات ZynReach.

Incident Response Team: الأشخاص أو الفرق التي تحددها ZynReach لإدارة الحوادث الأمنية والاستجابة لها.

Containment: الإجراءات المتخذة لاحتواء الحادث ومنع انتشاره أو الحد من تأثيره.

Recovery: إجراءات استعادة الأنظمة والبيانات والخدمات إلى حالة تشغيل آمنة.

تتبع ZynReach المبادئ التالية:

السرعة: تسعى الشركة إلى اكتشاف الحوادث والاستجابة لها في أسرع وقت عمليًا.

الدقة: لا يتم إصدار استنتاجات نهائية قبل توفر معلومات كافية، عندما تسمح طبيعة الحادث بذلك.

الحد من الضرر: تكون الأولوية لاحتواء الحادث وتقليل أثره.

حماية الأدلة: تسعى ZynReach إلى الحفاظ على المعلومات الفنية والأدلة اللازمة للتحقيق.

السرية: يتم تقييد المعلومات المتعلقة بالحوادث على أساس الحاجة إلى المعرفة.

الامتثال: تتم إدارة الحوادث بما يتوافق مع الالتزامات القانونية والتنظيمية والتعاقدية ذات الصلة.

تتبع ZynReach دورة استجابة للحوادث قد تشمل:

Detection → Triage → Assessment → Containment → Investigation → Eradication → Recovery → Notification → Post-Incident Review

وقد يتم تجاوز أو دمج بعض المراحل بحسب طبيعة الحادث.

قد يتم اكتشاف الحوادث من خلال:

ولا يعني إنشاء Alert أو اكتشاف نشاط غير اعتيادي أن Security Breach قد وقع بالفعل.

• أنظمة المراقبة.
• Security Monitoring.
• Audit Logs.
• Alerts.
• Vulnerability Detection.
• تقارير الموظفين.
• تقارير العملاء.
• تقارير المستخدمين.
• مزودي الخدمات.
• Sub-processors.
• الباحثين الأمنيين.
• الجهات الحكومية أو التنظيمية.
• مصادر أخرى موثوقة.

تشجع ZynReach الموظفين والمستخدمين والعملاء ومقدمي الخدمات على الإبلاغ عن الأنشطة الأمنية المشبوهة في أسرع وقت عمليًا.

وقد تشمل المؤشرات:

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

عند تلقي بلاغ أو اكتشاف حادث، تقوم ZynReach، بحسب الحالة، بتقييم:

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

يجوز لـZynReach تصنيف الحوادث وفق مستوى الخطورة.

المستوى 1 — منخفض: حادث محدود لا يؤثر بصورة جوهرية على الأنظمة أو البيانات. ومن أمثلته:

المستوى 2 — متوسط: حادث له تأثير محدود على نظام أو خدمة أو حسابات محددة.

المستوى 3 — مرتفع: حادث قد يؤثر على بيانات أو خدمة مهمة أو عدد من العملاء.

المستوى 4 — حرج: حادث واسع النطاق أو جوهري قد يؤثر على:

ويجوز تعديل التصنيف أثناء التحقيق مع ظهور معلومات جديدة.

• تنبيه أمني غير مؤكد.
• محاولة وصول فاشلة.
• نشاط مشبوه تم احتواؤه دون تأثير معروف.
• Customer Data.
• Personal Data.
• سرية أو سلامة البيانات.
• توافر الخدمة بصورة كبيرة.
• عدد كبير من العملاء.
• البنية التحتية الأساسية.

يجوز لـZynReach تشكيل فريق استجابة للحوادث يتناسب مع طبيعة الحادث، وقد يشمل:

وقد تستعين الشركة بخبراء أو مستشارين خارجيين عند الحاجة.

• Security.
• Engineering.
• Infrastructure / DevOps.
• IT.
• Privacy.
• Legal.
• Management.
• Customer Success.
• Communications.

يجوز لفريق الاستجابة، بالقدر اللازم والمصرح به، اتخاذ إجراءات مثل:

وقد تؤدي إجراءات الاحتواء إلى تأثير مؤقت على بعض الخدمات إذا كان ذلك ضروريًا لحماية الأنظمة أو البيانات.

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

تسعى ZynReach إلى احتواء الحوادث من خلال تدابير مناسبة لطبيعتها.

وقد تشمل:

ويتم اختيار الإجراء وفقًا للمخاطر والظروف.

• عزل الأنظمة.
• تعطيل الحسابات المخترقة.
• تغيير مفاتيح الوصول.
• إلغاء الجلسات.
• حظر عناوين أو مصادر ضارة.
• تقييد الصلاحيات.
• إيقاف مكون متأثر.
• تطبيق قواعد أمنية إضافية.

بعد الاحتواء الأولي، قد تقوم ZynReach بالتحقيق لتحديد:

وقد لا يكون من الممكن تحديد جميع تفاصيل الحادث بصورة فورية.

• كيف بدأ الحادث.
• متى بدأ.
• الأنظمة المتأثرة.
• البيانات المحتمل تعرضها.
• نطاق الوصول.
• مدة التعرض.
• ما إذا كان المهاجم لا يزال لديه وصول.
• الإجراءات التي تم اتخاذها.
• التدابير المطلوبة لمنع التكرار.

تسعى ZynReach، عندما يكون ذلك مناسبًا، إلى الحفاظ على الأدلة ذات الصلة، مثل:

ويتم التعامل مع الأدلة بطريقة مناسبة لطبيعة الحادث والمتطلبات القانونية.

• Logs.
• Audit Trails.
• System Events.
• Network Information.
• Authentication Records.
• ملفات النظام.
• مؤشرات الاختراق.
• المعلومات المتعلقة بالحسابات المتأثرة.

بعد فهم السبب الجذري، تعمل ZynReach، بحسب الإمكان، على إزالة أو معالجة مصدر الحادث.

وقد تشمل الإجراءات:

• تصحيح الثغرة.
• تحديث النظام.
• إلغاء صلاحيات غير مناسبة.
• تغيير مفاتيح أو بيانات اعتماد.
• إزالة البرمجيات الخبيثة.
• تعديل إعدادات الأمان.
• تحديث قواعد المراقبة.
• تحسين الضوابط التقنية.

بعد احتواء الحادث والقضاء على السبب، تعمل ZynReach على استعادة الأنظمة بصورة آمنة.

وقد تشمل عملية الاستعادة:

• التحقق من سلامة الأنظمة.
• التحقق من عدم استمرار التهديد.
• استعادة البيانات عند الحاجة.
• اختبار الخدمات.
• إعادة تفعيل الأنظمة تدريجيًا.
• زيادة المراقبة بعد الاستعادة.

لا يُعتبر كل Security Incident Personal Data Breach.

تقوم ZynReach بتقييم ما إذا كان الحادث قد أدى أو يحتمل أن يؤدي إلى:

ويتم تحديد التصنيف القانوني وفقًا للقانون والظروف الفعلية للحادث.

• الوصول غير المصرح به إلى البيانات الشخصية.
• الكشف غير المصرح به.
• فقدان البيانات.
• تغيير غير مصرح به.
• تدمير البيانات.
• التأثير على حقوق أو حريات الأفراد، عندما يكون ذلك معيارًا بموجب القانون المعمول به.

عندما تكون ZynReach ملزمة تعاقديًا أو قانونيًا بإخطار العميل بخرق يتعلق بـCustomer Data، تسعى الشركة إلى تقديم الإخطار وفقًا للمدة والآلية المنصوص عليها في الـDPA أو الاتفاقية المعمول بها.

وقد يتضمن الإخطار، بالقدر المتاح:

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

قد لا تتوفر جميع المعلومات المتعلقة بالحادث عند اكتشافه.

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

ولا يُشترط انتظار اكتمال التحقيق لإرسال إخطار عندما يكون الإخطار المبكر مطلوبًا قانونيًا أو تعاقديًا.

تحرص ZynReach على أن تكون الإخطارات:

وقد لا يتضمن الإخطار معلومات تفصيلية قد:

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

تلتزم ZynReach بالمواعيد التي يفرضها القانون أو الاتفاقيات ذات الصلة عندما تكون تلك المواعيد واجبة التطبيق.

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

• طبيعة الحادث.
• مدى التأثير.
• مستوى اليقين المتاح.
• الحاجة إلى الاحتواء.
• المتطلبات القانونية.
• الالتزامات التعاقدية.

عندما تعمل ZynReach بصفتها Processor نيابةً عن العميل، فإن العميل قد يكون الجهة المسؤولة قانونًا عن إخطار:

ولا تقوم ZynReach بإخطار أصحاب البيانات أو الجهات التنظيمية نيابةً عن العميل إلا عندما:

• أصحاب البيانات.
• الجهات التنظيمية.
• السلطات الحكومية.
• يكون ذلك مطلوبًا قانونًا؛ أو
• يكون مصرحًا به تعاقديًا؛ أو
• يطلب العميل ذلك وتسمح الظروف والقوانين بذلك.

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

ويتم تحديد:

بحسب الولاية القضائية وطبيعة الحادث.

• الجهة المختصة.
• نوع الإخطار.
• المهلة.
• المعلومات المطلوبة.
• آلية التقديم.

إذا كانت ZynReach ملزمة قانونًا بإخطار أصحاب البيانات مباشرة، يتم تقييم:

ولا يتم إخطار الأفراد في الحالات التي لا يفرض فيها القانون ذلك، ما لم تر ZynReach أن الإخطار مناسب أو ضروري في ظروف معينة.

• مستوى المخاطر.
• طبيعة البيانات.
• احتمالية الضرر.
• المتطلبات القانونية.
• وسائل الاتصال المتاحة.

لا يجوز إصدار بيانات عامة بشأن حادث أمني إلا من خلال الأشخاص أو الجهات المخولة بذلك.

وقد يتم التنسيق مع:

ويجب تجنب نشر معلومات قد تعرض أمن ZynReach أو عملائها لمزيد من المخاطر.

• الإدارة.
• القسم القانوني.
• فريق الأمن.
• فريق الخصوصية.
• فريق الاتصالات.

تتعامل ZynReach مع التحقيقات الأمنية باعتبارها معلومات حساسة.

ويجوز تقييد الوصول إلى:

على أساس الحاجة إلى المعرفة.

• تفاصيل الحادث.
• الأدلة.
• أسماء الأشخاص المتأثرين.
• معلومات العملاء.
• تفاصيل الأنظمة.
• نتائج التحقيق الأولية.

عندما يقع حادث أمني لدى Sub-processor يؤثر أو قد يؤثر على بيانات تتم معالجتها نيابةً عن ZynReach أو عملائها، تعمل ZynReach على:

وتخضع إدارة هذه الحالات أيضًا إلى Sub-processor Policy.

• الحصول على المعلومات المتاحة.
• تقييم التأثير.
• تحديد البيانات المتأثرة.
• تقييم المخاطر.
• اتخاذ تدابير احتواء مناسبة.
• تنفيذ الإخطارات المطلوبة وفقًا للـDPA والقانون.

إذا تم اختراق حساب مستخدم أو الاشتباه في اختراقه، يجوز لـZynReach اتخاذ إجراءات مثل:

• تعليق الحساب.
• إنهاء الجلسات النشطة.
• إعادة تعيين بيانات الدخول.
• فرض مصادقة إضافية.
• طلب التحقق من الهوية.
• مراجعة النشاط.
• إخطار المستخدم عند الحاجة.

يتحمل العميل مسؤولية:

ولا تتحمل ZynReach مسؤولية حادث ناتج حصريًا عن سلوك العميل أو مستخدميه، بالقدر الذي يسمح به القانون والعقد.

• حماية بيانات الدخول الخاصة به.
• إدارة مستخدميه.
• استخدام كلمات مرور قوية.
• استخدام MFA عندما تكون متاحة.
• عدم مشاركة بيانات الدخول.
• الإبلاغ عن الأنشطة المشبوهة.
• الالتزام بتعليمات الأمان الخاصة بالمنصة.

عند وقوع حادث يؤثر على Customer Data، تقدم ZynReach، بالقدر المعقول والمتاح ووفقًا للـDPA:

ولا تلتزم ZynReach بتقديم معلومات سرية أو أسرار تجارية أو معلومات أمنية حساسة لا يلزم تقديمها بموجب القانون أو العقد.

• معلومات عن الحادث.
• التعاون الفني المناسب.
• المعلومات اللازمة للامتثال.
• المساعدة في فهم طبيعة الحادث.
• التحديثات الجوهرية عند توفرها.

يتحمل كل طرف تكاليف الاستجابة التي تقع ضمن مسؤوليته وفقًا للقانون والعقد.

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

يجوز لـZynReach الاستعانة بـ:

عندما ترى الشركة أن ذلك مناسب لطبيعة الحادث.

• خبراء أمن سيبراني.
• مستشارين قانونيين.
• Forensic Specialists.
• مزودي خدمات استجابة للحوادث.
• شركات تقنية متخصصة.

يجوز لـZynReach التعاون مع الجهات الحكومية أو جهات إنفاذ القانون عندما:

وقد يتم تقييد المعلومات المقدمة إلى الحد المطلوب قانونًا.

• يكون ذلك مطلوبًا قانونًا.
• يكون ذلك ضروريًا للتحقيق.
• يكون ذلك مناسبًا لحماية العملاء أو المستخدمين.
• يسمح القانون بذلك.

قد تقوم ZynReach بتقييم:

ولا يعني وجود Incident أن ضررًا فعليًا قد وقع على جميع الأشخاص أو العملاء المحتمل تأثرهم.

• عدد الأفراد المتأثرين.
• أنواع البيانات.
• حساسية البيانات.
• مدة التعرض.
• احتمالية سوء الاستخدام.
• التأثير على الخدمة.
• المخاطر القانونية.
• المخاطر التشغيلية.

بعد انتهاء الحادث، قد تقوم ZynReach بتنفيذ إجراءات مثل:

• إصلاح الثغرات.
• تحديث الأنظمة.
• تعديل الصلاحيات.
• تحسين المراقبة.
• تعزيز المصادقة.
• تحسين إجراءات النسخ الاحتياطي.
• تحديث السياسات.
• تدريب الموظفين.
• تحسين إدارة الموردين.
• تحسين إجراءات الاستجابة.

بعد الحوادث المهمة، يجوز لـZynReach إجراء مراجعة ما بعد الحادث لتحديد:

• ما الذي حدث؟
• لماذا حدث؟
• ما الذي تم اكتشافه؟
• كيف تمت الاستجابة؟
• ما الذي نجح؟
• ما الذي يحتاج إلى تحسين؟
• ما الإجراءات التصحيحية المطلوبة؟
• ما الدروس المستفادة؟

يجوز لـZynReach الاحتفاظ بسجلات الحوادث التي تتضمن، بحسب الحالة:

وتخضع هذه السجلات لسياسات الاحتفاظ بالبيانات المعمول بها.

• تاريخ الحادث.
• مصدر البلاغ.
• التصنيف.
• الأنظمة المتأثرة.
• إجراءات الاحتواء.
• نتائج التحقيق.
• الإخطارات.
• الإجراءات التصحيحية.

يجوز لـZynReach اختبار إجراءات الاستجابة للحوادث من خلال:

ويتم استخدام نتائج الاختبارات لتحسين إجراءات الاستجابة عند الحاجة.

• Tabletop Exercises.
• اختبارات الاستعادة.
• اختبارات أمنية.
• محاكاة حوادث.
• اختبارات استمرارية الأعمال.

تُكمل هذه السياسة إجراءات Business Continuity وDisaster Recovery الخاصة بـZynReach.

فبينما تركز هذه السياسة على الاستجابة للحوادث الأمنية، قد تركز خطط استمرارية الأعمال والتعافي من الكوارث على:

• استعادة الخدمات.
• استعادة البيانات.
• تقليل زمن التوقف.
• استمرار العمليات.

لا تضمن ZynReach:

وتعتمد فعالية الاستجابة أيضًا على طبيعة التهديد والأنظمة المتأثرة ومعلومات الأطراف الثالثة والتعاون المتاح.

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

لا يشكل أي إخطار أو تعاون أو إجراء تتخذه ZynReach فيما يتعلق بحادث أمني:

ويتم تحديد المسؤولية وفقًا للوقائع والعقد والقانون المعمول به.

• إقرارًا بالمسؤولية القانونية.
• إقرارًا بوجود إهمال.
• تنازلًا عن أي دفاع قانوني.
• تنازلًا عن أي حق تعاقدي.
• إقرارًا بأن جميع البيانات قد تعرضت للوصول أو الكشف.

قد تحجب ZynReach أو تحد من الإفصاح عن بعض المعلومات المتعلقة بالحوادث عندما يكون الإفصاح عنها قد:

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

لا تعتبر كل ثغرة أمنية حادثًا أمنيًا أو خرقًا للبيانات.

تقوم ZynReach بتقييم الثغرات وفقًا لمستوى المخاطر وإمكانية الاستغلال والتأثير المحتمل.

وقد يتم:

• تسجيل الثغرة.
• تصنيفها.
• تحديد أولويتها.
• تطبيق إصلاح.
• مراقبتها.
• إخطار الأطراف المتأثرة عندما يكون ذلك مطلوبًا.

تشجع ZynReach الباحثين الأمنيين على الإبلاغ بصورة مسؤولة عن الثغرات التي قد تؤثر على خدماتها.

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

يجب على الموظفين والمتعاقدين:

• الإبلاغ الفوري عن الحوادث المشتبه بها.
• عدم التحقيق بصورة قد تؤدي إلى إتلاف الأدلة.
• عدم مشاركة تفاصيل الحادث مع أطراف غير مخولة.
• اتباع تعليمات فريق الاستجابة.
• حماية بيانات العملاء.
• الالتزام بسياسات الأمن والخصوصية.

تتم مراجعة هذه السياسة دوريًا أو عند حدوث:

• تغيير جوهري في البنية التقنية.
• تغيير جوهري في الخدمات.
• حادث أمني مهم.
• تغيير في القوانين.
• تغيير في متطلبات العملاء.
• تغيير في نموذج المخاطر.

يجوز لـZynReach تعديل هذه السياسة من وقت لآخر لتعكس:

ويتم نشر الإصدار المحدث من خلال القنوات المناسبة.

• التطورات التقنية.
• التغييرات القانونية.
• تحسينات الأمن.
• الدروس المستفادة من الحوادث.
• التغييرات التشغيلية.

في حال وجود تعارض بين هذه السياسة وأي اتفاقية مكتوبة وموقعة، تكون أحكام الاتفاقية هي الحاكمة، ما لم يفرض القانون الإلزامي خلاف ذلك.

وبالنسبة إلى Customer Data، يكون Data Processing Agreement (DPA) المرجع الأساسي فيما يتعلق بـ:

• مسؤوليات الأطراف.
• الإخطار بالحوادث.
• المواعيد.
• التعاون.
• معالجة البيانات.
• الالتزامات المتعلقة بالخرق.

لإبلاغ ZynReach عن حادث أمني أو اشتباه في خرق بيانات، يجب استخدام قنوات الاتصال الأمنية أو القانونية الرسمية التي تحددها الشركة على موقعها أو في الاتفاقية المبرمة مع العميل.

ويجب، قدر الإمكان، تضمين:

ولا ينبغي إرسال كلمات مرور أو مفاتيح API أو بيانات اعتماد سرية في رسالة البلاغ.

• اسم الجهة أو العميل.
• بيانات الاتصال.
• طبيعة الحادث.
• التاريخ والوقت التقريبي.
• الحساب أو الخدمة المتأثرة.
• البيانات التي يُعتقد أنها متأثرة.
• أي أدلة أو معلومات متاحة.

يوضح الجدول التالي بيانات سجل هذه الوثيقة:

• اسم الوثيقة — Incident Response & Security Breach Notification Policy
• الشركة — Zyntra Digital
• المنصة — ZynReach
• الموقع — zynreach.com
• الإصدار — 1.0
• تاريخ السريان — 31 أغسطس 2026
• التصنيف — Public / Legal / Security / Compliance
• المالك — Security / Legal / Privacy
• المراجعة — دوريًا أو عند حدوث تغيير جوهري
• الوثائق المرتبطة — DPA / Privacy Policy / Security & Trust Policy / Sub-processor Policy / Data Retention & Deletion Policy / Business Continuity & Disaster Recovery

تمثل هذه الوثيقة الإطار العام الذي تستخدمه ZynReach لإدارة الحوادث الأمنية والاستجابة لها والإخطار بها.

ولا تشكل هذه السياسة بحد ذاتها ضمانًا بأن ZynReach ستكتشف أو تمنع أو تحتوي جميع الحوادث الأمنية، كما لا تشكل إقرارًا بأن أي حادث معين يمثل خرقًا قانونيًا للبيانات.

تختلف التزامات الإخطار بحسب:

وعليه، يتم تحديد الالتزام النهائي بالإخطار ومحتواه وتوقيته وفقًا للقانون والاتفاقية والوقائع المتاحة في الحالة المعنية.

• الولاية القضائية.
• طبيعة البيانات.
• دور ZynReach كـController أو Processor.
• نوع الحادث.
• طبيعة المخاطر.
• الاتفاقية المبرمة مع العميل.
• المتطلبات القانونية والتنظيمية.