حماية البيانات الشخصية PDPL للخدمات التي تستضيفها

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

وفي هذا المقال سوف نجيب عن هذه الأسئلة من النصوص الرسمية التي تنشرها الهيئة السعودية للبيانات والذكاء الاصطناعي سدايا SDAIA فقط، وهي نظام حماية البيانات الشخصية المعدل بالمرسوم الملكي (م/148)، ولائحته التنفيذية، ولائحة نقل البيانات الشخصية إلى خارج المملكة في إصدارها 2.0 بتاريخ أغسطس 2024، والأدلة الاسترشادية في المركز المعرفي على منصة حماية البيانات الشخصية، وكل رقم مادة في المقال نقلناه من النص نفسه. وقد لخصنا أهم مواد النظام للمنتجات التقنية في قسم الأنظمة في مقال أفكار المنتجات، أما هنا فالتركيز على من يشغل الخدمة ويستضيفها.

وفي هذا المقال سوف نتناول:

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

متى ينطبق النظام على خدمتك؟

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

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

من أنت: جهة التحكم أم جهة المعالجة؟

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

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

ماذا يكتب في الاتفاق بينك وبين عميلك؟

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

1. غرض المعالجة، وفئات البيانات الشخصية المعالجة، والمدة الزمنية للمعالجة.
2. التزام جهة المعالجة بإشعار جهة التحكم في حال تسرب البيانات دون تأخر غير مبرر.
3. توضيح ما إذا كانت جهة المعالجة تخضع لأنظمة دول أخرى، وأثر ذلك على التزامها بالنظام.
4. أن الإفصاح الذي توجبه الأنظمة في المملكة لا يحتاج موافقة مسبقة من جهة التحكم، مع إشعارها به.
5. تحديد جهات المعالجة الفرعية Sub-processors المتعاقدة مع جهة المعالجة، وأي طرف آخر سيفصح له عن البيانات.

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

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

الأمن: ضوابط الهيئة الوطنية أو أفضل الممارسات

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

دليلأطر الأمن السيبراني Frameworks: أيها تحتاج مؤسستك؟الفرق بين ECC وISO 27001 وNIST CSF وSOC 2 في الإلزام وطريقة الإثبات وما تحصل عليه، وأربعة أسئلة تحدد بها ما تحتاجه مؤسستك.دليلتحقيق ضوابط ECC بأدوات مفتوحة المصدر Open Sourceخريطة تربط كل ضابط فرعي في الضوابط الأساسية ECC بالأداة مفتوحة المصدر التي تحققه وبالمقال الذي شرحها، مع إثبات ضابطين بمخرج حقيقي.

تسربت البيانات: من يشعر من، ومتى؟

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

وفي الشكل أعلاه لاحظ التالي:

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

والسؤال التقني الذي يحدد قدرتك على الوفاء بالمهلة: هل تستطيع أن تجيب خلال يومين عن «ما البيانات التي تسربت، ولكم شخص؟». وهذا لا يمكن إلا إذا كان لديك سجل أنشطة معالجة يقول أين توجد كل فئة من البيانات، وسجل تدقيق يقول من وصل إلى ماذا، وقد شرحنا الثاني في سجل التدقيق Audit Trail، وشرحنا حفظ الأدلة قبل التنظيف في التحقيق الرقمي DFIR للمبتدئين.

سجل أنشطة المعالجة: الوثيقة التي تجيب عن كل سؤال

المادة الحادية والثلاثون من النظام والمادة الثالثة والثلاثون من اللائحة تلزمان جهة التحكم بسجل مكتوب لأنشطة معالجة البيانات الشخصية Records of Processing Activities، تحتفظ به طوال فترة المعالجة ثم خمس سنوات بعد انتهاء النشاط، وتتيحه للجهة المختصة عند طلبها، وحده الأدنى كما في اللائحة:

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

الاحتفاظ والإتلاف، والنسخ الاحتياطية

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

وهذا يضع أمامك سؤالاً تقنياً حقيقياً: إذا طلب مستخدم حذف بياناته، وكانت لديك نسخ احتياطية غير قابلة للتعديل لمدة 90 يوماً، كما ننصح في S3 Object Lock للحماية من برامج الفدية، فكيف تحذف منها؟ والحل العملي الذي تتبعه الفرق عادة أن تحدد مدة احتفاظ قصيرة ومعلنة للنسخ، وتوثق أن البيانات المحذوفة تختفي من النسخ بانتهاء دورتها، وتضمن ألا تستعاد البيانات المحذوفة إلى النظام الحي عند أي استعادة، وهذا قرار يوثق في سجل المعالجة ويراجعه المستشار النظامي، ولا تقم به بقرار فردي من الفريق التقني. وقد نشرت سدايا الدليل الاسترشادي لإتلاف البيانات الشخصية وإخفاء الهوية والترميز بطرق كل منها، ومنها التشفير مع حفظ المفاتيح منفصلة عن البيانات.

والسجلات Logs حالة خاصة، فالمادة التاسعة عشرة من اللائحة تطلب جمع الحد الأدنى من البيانات والاحتفاظ بالحد الأدنى، بينما يطلب الضابط الفرعي 2-12-3-5 في ECC الاحتفاظ بسجلات الأحداث الأمنية 12 شهراً على الأقل للجهات الملزمة بالضوابط. والطريقة المعقولة للجمع بينهما أن تقلل ما يدخل السجل من بيانات شخصية من البداية، كما سوف نفعل في التجربة التالية، ثم تحتفظ بالسجل المدة المطلوبة وتوثق ذلك في سجل المعالجة.

متى تخرج البيانات من المملكة دون أن تنتبه؟

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

والخطوات كما في النصوص:

1. الغرض: الفقرة الأولى من المادة 29 تسمح بالنقل تنفيذاً لاتفاقية تكون المملكة طرفاً فيها، أو لخدمة مصالح المملكة، أو تنفيذاً لالتزام يكون صاحب البيانات طرفاً فيه، أو لأغراض أخرى تحددها اللوائح، والمادة الثانية من لائحة النقل حددتها بالعمليات التشغيلية الضرورية للمعالجة المركزية، وتقديم خدمة أو منفعة لصاحب البيانات، والبحوث والدراسات العلمية.
2. الشروط: الفقرة الثانية من المادة 29 تشترط ألا يمس النقل الأمن الوطني أو مصالح المملكة الحيوية، وأن يتوافر في الخارج مستوى حماية لا يقل عن مستوى النظام بحسب تقويم تجريه الجهة المختصة، وأن يقتصر النقل على الحد الأدنى من البيانات. والمادة الثالثة من لائحة النقل تقول إن الجهة المختصة تنشر في موقعها الرسمي قائمة الدول والمنظمات التي توفر مستوى حماية مناسباً، وتراجعها كل أربع سنوات أو عند الاقتضاء.
3. أو الإعفاء بضمانات مناسبة: المادة الرابعة من لائحة النقل تحدد حالات يعفى فيها النقل من شرطي مستوى الحماية والحد الأدنى، بشرط ضمانات مناسبة هي البنود التعاقدية القياسية التي نشرتها سدايا في نموذج رسمي، أو القواعد المشتركة الملزمة لمجموعات الشركات متعددة الجنسيات، أو شهادة اعتماد من جهة مرخصة. ولاحظ أن عدة حالات من هذه الحالات تستثني البيانات الحساسة.
4. تقويم المخاطر: المادة السابعة من لائحة النقل تلزم جهة التحكم بتقويم مخاطر قبل النقل إذا اعتمدت على حالات الإعفاء، أو إذا نقلت بيانات حساسة بصفة مستمرة أو على نطاق واسع، ولها دليل استرشادي مستقل.

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

تجربة عملية: سجلات Nginx تحفظ بيانات شخصية دون أن تنتبه

أغلب الفرق التي تراجع قواعد بياناتها بحثاً عن البيانات الشخصية تنسى السجلات، مع أن السجل الافتراضي في Nginx يحفظ عنوان IP كاملاً، والرابط كاملاً بما فيه معاملات الاستعلام Query String، وكثير من التطبيقات تضع فيها بريداً أو رقم جوال أو رقم هوية. والتجربة التالية تبين ذلك بأرقام وهمية. نبدأ بسيرفر Nginx بالإعداد الافتراضي للسجل، ونحفظ الإعداد التالي باسم default.conf:

server {
    listen 80;
    location / { return 200 "ok\n"; }
}

ثم نشغله ونرسل طلبين مثل التي يرسلها أي تطبيق:

docker run -d --name pdpl-nginx -p 127.0.0.1:8080:80 \
  -v "$PWD/default.conf:/etc/nginx/conf.d/default.conf:ro" nginx:1.31.6-alpine
curl -s "http://127.0.0.1:8080/reset-password?email=sara%40example.com&phone=0551234567"
curl -s "http://127.0.0.1:8080/api/students?national_id=1012345678"
docker logs pdpl-nginx 2>/dev/null | tail -2

والمخرج سوف يكون كما يلي:

172.17.0.1 - - [25/Oct/2026:20:38:04 +0000] "GET /reset-password?email=sara%40example.com&phone=0551234567 HTTP/1.1" 200 3 "-" "curl/8.12.1" "-"
172.17.0.1 - - [25/Oct/2026:20:38:04 +0000] "GET /api/students?national_id=1012345678 HTTP/1.1" 200 3 "-" "curl/8.12.1" "-"

وهذا يعني أن كل سجل تحتفظ به 12 شهراً، وكل نسخة منه ترسلها إلى منصة سجلات مركزية، أصبح يحمل بريد المستخدم ورقم جواله ورقم هويته، ويدخل في نطاق الإتلاف والإشعار بالتسرب. والآن نقلل ما يدخل السجل بإعداد يحذف معاملات الاستعلام ويقصر عنوان IPv4 على أول ثلاثة أجزاء، ونستبدل default.conf بالتالي:

# PDPL minimisation: no query strings, IPv4 truncated to /24 in the access log
map $remote_addr $remote_addr_anon {
    ~(?P<net>\d+\.\d+\.\d+)\.\d+    $net.0;
    ~(?P<net6>[^:]+:[^:]+:[^:]+):   $net6::;
    default                         0.0.0.0;
}
log_format minimal '$remote_addr_anon - [$time_local] "$request_method $uri $server_protocol" '
                   '$status $body_bytes_sent "$http_user_agent"';

server {
    listen 80;
    access_log /var/log/nginx/access.log minimal;
    location / { return 200 "ok\n"; }
}

ثم نختبر الإعداد ونعيد تحميله ونرسل الطلبين نفسيهما:

docker exec pdpl-nginx nginx -t
docker exec pdpl-nginx nginx -s reload
curl -s "http://127.0.0.1:8080/reset-password?email=sara%40example.com&phone=0551234567"
curl -s "http://127.0.0.1:8080/api/students?national_id=1012345678"
docker logs pdpl-nginx 2>/dev/null | tail -2

والمخرج سوف يكون كما يلي:

172.17.0.0 - [25/Oct/2026:20:38:20 +0000] "GET /reset-password HTTP/1.1" 200 3 "curl/8.12.1"
172.17.0.0 - [25/Oct/2026:20:38:20 +0000] "GET /api/students HTTP/1.1" 200 3 "curl/8.12.1"

في الإعداد أعلاه لاحظ التالي:

• المتغير $uri هو المسار دون معاملات الاستعلام، بخلاف $request الذي يحمل الرابط كاملاً، وهذا وحده أزال البريد والجوال ورقم الهوية من السجل.
• الـ map يحول عنوان IPv4 مثل 172.17.0.1 إلى 172.17.0.0، فيبقى السجل مفيداً لمعرفة الشبكة التي جاء منها الطلب، ولا يحدد جهازاً بعينه، والسطر الثاني يقصر عنوان IPv6 على أول ثلاث مجموعات.
• حذفنا أيضاً الـ Referer، لأنه يحمل أحياناً رابط الصفحة السابقة بمعاملاتها.

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

172.17.0.0 - [25/Oct/2026:20:38:36 +0000] "GET /api/students/1012345678/grades HTTP/1.1" 200 3 "curl/8.12.1"

والحل هنا في تصميم الـ API نفسه وليس في Nginx: استخدم معرفات داخلية لا تدل على الشخص، مثل UUID، بدلاً من رقم الهوية في الروابط، وقد شرحنا ما لا يجب أن يدخل السجلات أصلاً في السجلات Logging للمطورين. وعند الانتهاء احذف الـ Container:

docker rm -f pdpl-nginx

قائمة تحقق لمكونات الخدمة المستضافة

هل تحتاج مسؤول حماية البيانات الشخصية؟

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

العقوبات كما وردت في النظام

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

ولاحظ أن نص المادة 35 في صيغته الأولى كان يتضمن عقوبة لمخالفة أحكام النقل إلى خارج المملكة، وقد حذفت في التعديل بالمرسوم الملكي (م/148)، لذلك اعتمد دائماً على النص المعدل الذي تنشره سدايا وليس على ملخصات قديمة.

أخطاء شائعة عند الفرق التقنية

• اعتبار النظام شأناً قانونياً لا يخص الفريق التقني: مهلة 72 ساعة وسجل المعالجة والإتلاف من النسخ الاحتياطية كلها أسئلة تقنية قبل أن تكون قانونية.
• إضافة مزود خارجي دون إشعار العملاء: كل خدمة جديدة تصلها بيانات شخصية تعاقد لاحق يحتاج موافقة مسبقة من جهة التحكم.
• نسيان السجلات ومنصات المراقبة: فيها عناوين IP ومعرفات وأحياناً بريد وأرقام جوال، فراجع ما يدخلها كما في التجربة.
• الحذف من قاعدة البيانات فقط: اللائحة تذكر النسخ الاحتياطية صراحة، فاكتب كيف تتعامل معها.
• الاعتماد على ملخص قديم: النظام عدل في 1444هـ، ولائحة النقل صدر منها إصدار 2.0 في أغسطس 2024، فارجع دائماً إلى المركز المعرفي على منصة سدايا.

الخلاصة

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

سجل التحديثات

أكتوبر 2026: كتابة المقال من نصوص نظام حماية البيانات الشخصية ولائحته التنفيذية ولائحة النقل إلى خارج المملكة (الإصدار 2.0) والأدلة الاسترشادية كما نشرتها سدايا، واختبار إعداد السجل على Nginx 1.31.6.