نظام تذاكر الدعم الفني يُعدّ مستودعًا للبيانات الشخصية، لأن كل تذكرة تحمل اسم مُبلِّغ ورقم جواله وربما مرفقات حسّاسة. لذلك تنطبق عليه المبادئ العامة لحماية البيانات: جمع أقل قدر ممكن، تحديد الغرض، ضبط الصلاحيات، التشفير، تسجيل التدقيق، ومدة احتفاظ معلومة. تحقّق دائمًا من المتطلبات النافذة مع الجهة المختصة ومستشارك القانوني.
معظم فرق التقنية في السعودية تتعامل مع نظام التذاكر بوصفه أداة تشغيل، لا بوصفه سجلًّا للبيانات الشخصية. وهذا هو مصدر أغلب الفجوات. عمليًا، مركز الدعم يجمع بياناتٍ عن أشخاص طبيعيين كل يوم — موظفين، مستفيدين، عملاء — ويحتفظ بها سنوات، ويتيح الاطلاع عليها لعشرات المستخدمين. هذه بالضبط هي الخصائص التي تجعل النظام محلًّا للاعتبارات التي جاء بها نظام حماية البيانات الشخصية (PDPL).
هذا المقال يشرح المبادئ العامة المستقرّة في حماية البيانات وكيف تُترجَم إلى إعدادات ملموسة داخل منصة تذاكر الدعم الفني. وهو ليس استشارة قانونية، ولا يقتبس نصوص مواد أو مبالغ غرامات — تلك مسائل يُرجَع فيها إلى الجهة المختصة.
أين تختبئ البيانات الشخصية داخل نظام التذاكر؟
الخطأ الشائع أن يُحصر التفكير في حقل «اسم المُبلِّغ» وحده. البيانات الشخصية في نظام التذاكر موزّعة على طبقات متعددة، بعضها لا يظهر في الواجهة أصلًا. قبل أي عمل على الامتثال، ينبغي رسم خريطة لما يحتويه النظام فعلًا.
| الموضع | أمثلة على المحتوى | ملاحظة على الحساسية |
|---|---|---|
| حقول التذكرة الأساسية | الاسم، البريد، رقم الجوال، الرقم الوظيفي، الإدارة | معرّفات مباشرة — الأوضح والأسهل حوكمةً |
| نص الوصف والردود | شرح المشكلة بكلمات المستخدم، وقد يتضمن بيانات لم تُطلَب منه | الأخطر: نص حر لا يخضع لتحقّق |
| المرفقات | لقطات شاشة، صور هوية، فواتير، تقارير | قد تحمل بيانات أطراف ثالثة دون علمهم |
| البيانات الوصفية | عنوان IP، معرّف الجهاز، الطابع الزمني، الموقع التقريبي | تُجمع تلقائيًا وغالبًا تُنسى في التقييم |
| سجلات التدقيق | من فتح التذكرة، ومن اطّلع عليها، ومتى | بيانات شخصية عن الموظفين أنفسهم |
| التكاملات الصادرة | إشعارات بريد/رسائل نصية، مزامنة مع أنظمة أخرى | البيانات تغادر النظام إلى أطراف أخرى |
لاحظ الصف الثاني تحديدًا. حين تكتب لمستخدم «صف مشكلتك»، فأنت تفتح حقلًا لا تتحكّم في محتواه. مستخدم يشتكي من تعطّل نظام الرواتب قد يلصق كشف راتبه كاملًا في وصف التذكرة. هذا ليس خطأه — بل خطأ في تصميم النموذج والتوجيه.
المبادئ العامة التي ينبغي مراعاتها
هذه مبادئ مستقرّة في أدبيات حماية البيانات عمومًا، وهي الإطار الذهني الذي يُقاس عليه أي نظام يحتفظ ببيانات أشخاص. صياغتها هنا عامة ووصفية، لا نقلًا عن نص نظامي بعينه.
تقليل البيانات يبدأ من نموذج التذكرة
أرخص إجراء حماية على الإطلاق هو ألّا تجمع البيانات أساسًا. ما لا تملكه لا يُسرَّب منك، ولا يُطلب منك حذفه، ولا يكلّفك تشفيره. ولذلك فإن مراجعة نموذج فتح التذكرة تسبق — من حيث الأثر — أي استثمار في أدوات الحماية.
مثال افتراضي للتوضيح: نموذج «طلب دعم تقني» يطلب رقم الهوية الوطنية كحقل إلزامي. اسأل: ما الذي يفعله الفنّي بهذا الرقم لإصلاح طابعة؟ إن لم تكن هناك إجابة تشغيلية واضحة، فالحقل يجب أن يُحذف — لا أن يُشفَّر ويُدار ويُدقَّق عليه سنوات.
- راجع كل حقل واسأل: ما القرار التشغيلي الذي يتوقّف على هذا الحقل؟ إن لم يوجد، احذفه.
- حوّل الحقول الإلزامية غير الضرورية إلى اختيارية، ثم راقب: إن لم يملأها أحد ولم يتعطّل شيء، فقد ثبت أنها زائدة.
- استبدل النص الحر بقوائم منسدلة حيثما أمكن — القائمة تحصر المدخلات وتمنع الإفصاح العَرَضي.
- أضف تنبيهًا واضحًا أعلى حقل الوصف: «لا ترفق صور الهوية أو بيانات الحساب البنكي أو كلمات المرور».
- قيّد أنواع المرفقات وحجمها؛ منع رفع الصور في نماذج لا تحتاجها يقلّل التسريب العَرَضي كثيرًا.
- راجع الحقول المخفية التي يجمعها النظام تلقائيًا (IP، معرّف الجهاز) وقرّر: هل لها غرض تشغيلي؟
- اعرض إشعار الخصوصية عند نقطة الجمع نفسها، لا في صفحة منفصلة لا يزورها أحد.
- وثّق سبب وجود كل حقل في سجل بسيط — هذا المستند هو ما يُطلب منك حين تُسأل «لماذا تجمعون هذا؟».
من يرى ماذا، ولكم من الوقت؟
سؤالان يختصران معظم عمل الحوكمة في نظام التذاكر: سؤال الصلاحية وسؤال العمر. الأول يُجاب عنه بمصفوفة أدوار، والثاني بجدول احتفاظ. وكلاهما ينبغي أن يكون مكتوبًا ومطبَّقًا في النظام، لا مفهومًا ضمنيًّا في رؤوس الفريق.
| الدور | تذاكر قسمه | تذاكر الأقسام الأخرى | المرفقات | سجل التدقيق | التصدير |
|---|---|---|---|---|---|
| مقدّم الطلب | تذاكره فقط | لا | مرفقاته فقط | لا | لا |
| فنّي مستوى أول | قراءة وكتابة | لا | نعم | لا | لا |
| مشرف الفريق | كامل | قراءة عند التصعيد | نعم | قراءة | محدود ومسجَّل |
| مسؤول الخصوصية | قراءة | قراءة | عند الحاجة فقط | كامل | نعم ومسجَّل |
| مدير النظام | إعدادات لا محتوى | إعدادات لا محتوى | يُفضَّل الحجب | قراءة فقط | بموافقة مزدوجة |
انتبه لصفّ «مدير النظام». الافتراض السائد أن مدير النظام يجب أن يرى كل شيء، وهو افتراض يستحق المراجعة: إدارة الإعدادات لا تستلزم قراءة محتوى تذاكر الموارد البشرية. فصل «إدارة النظام» عن «الاطلاع على المحتوى» من أنضج ما يمكن فعله في هذا الباب، وقد فصّلناه في مقال إدارة صلاحيات المستخدمين داخل نظام التذاكر.
أما سؤال العمر فيتطلّب جدولًا يربط كل صنف بيانات بمدة، ثم آليةً تنفّذ الحذف تلقائيًا. الاعتماد على الحذف اليدوي معناه عمليًّا عدم الحذف. تفاصيل بناء هذا الجدول في سياسة الاحتفاظ ببيانات التذاكر وحذفها.
حقوق صاحب البيانات: هل نظامك جاهز للطلب؟
من المبادئ العامة المستقرّة أن لصاحب البيانات حقوقًا تجاه بياناته: أن يعلم بها، وأن يطّلع عليها، وأن يطلب تصحيحها أو إتلافها. ونطاق هذه الحقوق وشروط ممارستها واستثناءاتها مسائل تفصيلية تُراجَع في مصدرها النظامي — لكن الجاهزية التقنية لها مسألة هندسية بحتة تخصّك أنت.
الاختبار العملي بسيط: لو وصلك اليوم طلب من شخص يريد نسخة من كل ما لديك عنه، كم يستغرق تنفيذه؟ إن كانت الإجابة «أسابيع من البحث اليدوي في التذاكر والمرفقات والسجلات»، فالمشكلة ليست قانونية بل معمارية. النظام الذي لا يستطيع البحث عن شخص عبر كل سجلاته لن يستطيع الاستجابة لطلبه.
- هل يمكن البحث عن شخص واحد واسترجاع كل تذاكره ومرفقاته وردوده في عملية واحدة؟
- هل يشمل البحث السجلات المؤرشفة والنسخ الاحتياطية، أم يقتصر على القاعدة النشطة؟
- هل يمكن تصدير النتيجة في صيغة مقروءة تُسلَّم لصاحب الطلب دون كشف بيانات أشخاص آخرين وردت في التذكرة نفسها؟
- هل يوجد إجراء موثّق للتحقّق من هوية مقدّم الطلب قبل تسليم أي شيء؟
- هل يُسجَّل الطلب نفسه ومعالجته في سجل التدقيق؟
- هل يوجد مالك معلوم لهذه الطلبات، أم تدور بين الأقسام حتى تنتهي مهلتها؟
حين يقع التسريب: تدفّق الاستجابة
الإفصاح عن حوادث الاختراق مبدأ عام مستقرّ: من يحتفظ ببيانات الناس عليه إبلاغهم وإبلاغ الجهة المختصة إذا تعرّضت للخطر. أما التفاصيل — المهلة الدقيقة، وعتبة الإبلاغ، وصيغة البلاغ — فتُراجَع في مصدرها النظامي وقت وقوع الحادثة، لا من ذاكرة أحد. ما يعنينا هنا هو التدفّق الداخلي الذي يجب أن يكون جاهزًا قبل الحادثة.
الخطوة الثالثة هي التي تفصل الجهات المستعدّة عن غيرها. تفصيل ما يجب أن يحتويه السجل ومدة حفظه في سجلات التدقيق في أنظمة الدعم الفني.
المزوّد والاستضافة: مسؤوليتك لا تنتقل بالعقد
حين تشترك في نظام تذاكر سحابي، فأنت لم تُخرج البيانات من مسؤوليتك — أخرجتها من سيطرتك المباشرة فقط. المبدأ العام: الجهة التي تحدّد غرض المعالجة تبقى مسؤولة أمام أصحاب البيانات، ولو تمّت المعالجة على خوادم غيرها. لذلك فإن اختيار المزوّد قرار حماية بيانات بامتياز، لا قرار مشتريات.
ثلاثة أسئلة لا يصحّ توقيع عقد قبل الحصول على إجابات مكتوبة عنها: أين تُخزَّن البيانات جغرافيًّا ومن يستطيع الوصول إليها إداريًّا؟ ماذا يحدث للبيانات عند انتهاء العقد؟ وكيف يُبلَّغ العميل عند وقوع حادثة عند المزوّد؟ القائمة الكاملة في أسئلة الأمن والخصوصية لمزوّد النظام، ومسألة الموقع الجغرافي تحديدًا في استضافة نظام التذاكر داخل السعودية أم خارجها.
وللجهات الحكومية اعتبارات إضافية تتعلق بتصنيف البيانات وبيئة الاستضافة، وقد أُفردت في صفحة حلول القطاع الحكومي.
الأسئلة الشائعة
هل نظام التذاكر الداخلي للموظفين يخضع لاعتبارات حماية البيانات الشخصية؟
بيانات الموظفين بيانات شخصية بطبيعتها، وكونها داخلية لا ينفي عنها هذا الوصف. مبادئ تقليل الجمع وتقييد الوصول وتحديد مدة الاحتفاظ تنطبق على تذاكر الموظفين كما تنطبق على تذاكر العملاء. أما نطاق سريان النظام على حالتك تحديدًا فمسألة تُراجَع مع مستشارك القانوني.
هل يكفي التشفير وحده لتحقيق الامتثال؟
لا. التشفير ضابط واحد يعالج سرّية البيانات أثناء النقل والتخزين، ولا يعالج تقليل الجمع ولا تحديد الغرض ولا حقوق أصحاب البيانات ولا مدد الاحتفاظ. نظام مشفَّر بالكامل يجمع بيانات لا يحتاجها ويحتفظ بها إلى الأبد لا يزال بعيدًا عن المبادئ العامة. راجع تشفير بيانات التذاكر والمرفقات لفهم ما يغطّيه التشفير وما لا يغطّيه.
ما الفرق بين حذف التذكرة وتجهيل بياناتها؟
الحذف يزيل السجل كاملًا، فتفقد معه القيمة التحليلية والتاريخية. التجهيل يزيل المعرّفات الشخصية ويُبقي البيانات التشغيلية — التصنيف، زمن المعالجة، القسم — فتحتفظ بإحصاءاتك دون الاحتفاظ بالشخص. عمليًّا، التجهيل حلّ وسط مناسب لكثير من الحالات، بشرط أن يكون فعليًّا لا قابلًا للعكس بربط بسيط مع جدول آخر.
من يجب أن يملك ملف حماية البيانات في نظام التذاكر: التقنية أم الالتزام؟
كلاهما، بأدوار مختلفة. الالتزام يحدّد ما المطلوب ولماذا، والتقنية تحدّد كيف يُنفَّذ وتملك الأدوات. الفشل الشائع أن يُترك الملف لطرف واحد: فريق تقنية يبني ضوابط لا تعالج المخاطر الصحيحة، أو فريق التزام يكتب سياسة لا يمكن تطبيقها في النظام القائم. اجعل لكل ضابط مالكًا مسمّى من الجانبين.
هل نحتاج تقييم أثر على الخصوصية قبل تطبيق نظام تذاكر جديد؟
تقييم أثر الخصوصية ممارسة نافعة بذاتها بصرف النظر عن أي إلزام: تُجري تحليلًا مسبقًا لما ستجمعه ولماذا وما مخاطره وكيف تخفّضها. إجراؤه قبل التطبيق أرخص بكثير من إعادة هندسة نظام قائم. أما متى يكون إلزاميًّا وبأي صيغة فمسألة تُحسم بالرجوع إلى الجهة المختصة ومستشارك القانوني.