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

كُتب هذا الدليل للمطورين وفرق الهندسة، لا للأقسام القانونية أو الامتثال. يُترجم متطلبات UK GDPR إلى قرارات تقنية ملموسة: ما الذي ينبغي تطبيقه، وكيف يتم ذلك، ولماذا توجد كل تدبير.

الخلاصة

  • تستوجب المادة 32 من UK GDPR “تدابير تقنية ملائمة” تتناسب مع حجم المخاطر. وبالنسبة لمعظم التطبيقات التي تعالج البيانات الشخصية، يعني ذلك التشفير في حالة السكون وأثناء النقل، والتخفية حيثما أمكن، وضوابط الوصول، وقدرة موثقة على اكتشاف الخروقات.
  • أكثر أخطاء المطورين شيوعاً التي تُولّد تعرضاً لـ GDPR: تسجيل البيانات الشخصية (PII) في مخرجات التصحيح، والحذف المنطقي للسجلات التي كان ينبغي حذفها فعلياً لاستيفاء حق الحذف، والإخفاق في إبرام اتفاقيات معالجة البيانات (DPA) مع كل خدمة طرف ثالث تلمس البيانات الشخصية.
  • تقليل البيانات قرار تصميمي يُتخذ على مستوى الحقول. إن لم يكن لديك مبرر موثق لجمع حقل وتخزينه، فلا تجمعه.
  • يستلزم حق الحذف الحذف الفعلي بشكل متتالي عبر جميع الأنظمة بما فيها النسخ الاحتياطية والمعالجون من أطراف ثالثة. لا يفي الحذف المنطقي بهذا الالتزام.

UK GDPR مقابل EU GDPR: ما الذي يتغير للمطورين

بعد خروج بريطانيا من الاتحاد الأوروبي، احتفظت المملكة المتحدة بإطار EU GDPR بوصفه “UK GDPR” من خلال قانون الاتحاد الأوروبي (الانسحاب) لعام 2018. وبالنسبة للمطورين، تظل المتطلبات التقنية متطابقة. الاختلافات إدارية: السلطة الإشرافية في المملكة المتحدة هي مكتب مفوض المعلومات (ICO) لا سلطة حماية البيانات الوطنية في الاتحاد الأوروبي، وتخضع عمليات النقل عبر الحدود بين المملكة المتحدة والاتحاد الأوروبي لقرار الكفاءة البريطاني (الذي تحافظ عليه الاتحاد الأوروبي حالياً، وإن كان يُراجع دورياً).

المضمون العملي لذلك: إن بنيت برمجياً تمتثل للمتطلبات التقنية لـ EU GDPR، فهي تستوفي المتطلبات التقنية لـ UK GDPR. والعكس صحيح كذلك. ستنشأ التباينات في إجراءات الإخطار وآليات النقل والإرشادات التنفيذية الخاصة بـ ICO، التي تختلف أحياناً في تركيزها عن إرشادات المجلس الأوروبي لحماية البيانات (EDPB).

المادة 32: ما الذي تشترطه فعلاً

تُلزم المادة 32 من UK GDPR المتحكمين والمعالجين بتطبيق “تدابير تقنية وتنظيمية ملائمة” لضمان مستوى أمني يتناسب مع المخاطر، مع مراعاة حالة التكنولوجيا وتكاليف التطبيق وطبيعة عمليات المعالجة ونطاقها وسياقها وأغراضها.

هذه الصياغة مرنة عمداً. معناها التطبيقي يتوقف على ملف مخاطرك، غير أن المادة 32(1) تُورد أربعة أمثلة محددة:

  1. تخفية وتشفير البيانات الشخصية
  2. القدرة على ضمان السرية والنزاهة والتوافر والمرونة المستمرة لأنظمة ومنظومات المعالجة
  3. القدرة على استعادة توافر البيانات الشخصية والوصول إليها في وقت مناسب عقب أي حادثة مادية أو تقنية
  4. عملية لاختبار وتقييم وتحليل فعالية التدابير الأمنية بصفة منتظمة

لا تعني “حالة التكنولوجيا” أنك ملزم بتطبيق الحل الأغلى أو الأحدث. بل تعني أنك لا تستطيع تبرير اعتماد أسلوب ضعيف (كاستخدام MD5 لتجزئة كلمات المرور) حين تكون أساليب أفضل بوضوح (كـ Argon2) راسخة وواسعة الانتشار وليست أعلى تكلفة بشكل ملحوظ.

التشفير في حالة السكون

كلمات المرور. لا تخزّن كلمات المرور أبداً بنص صريح، ولا تستخدم MD5 أو SHA-1 لتجزئتها، فكلاهما غير مناسب كلياً. استخدم bcrypt بمعامل عمل لا يقل عن 12، أو Argon2id بمعاملات مضبوطة لتستغرق على الأقل 100 مللي ثانية على خادمك. Argon2id هو التوصية الحالية لـ OWASP وهو الأفضل للتطبيقات الجديدة.

1# Argon2id with libsodium (Node.js example)
2const hash = await argon2.hash(password, {
3  type: argon2.argon2id,
4  memoryCost: 65536,   // 64 MB
5  timeCost: 3,
6  parallelism: 1
7});

تشفير قاعدة البيانات. فعّل التشفير في حالة السكون على مستوى قاعدة البيانات. جميع قواعد البيانات الكبرى والخدمات المدارة (PostgreSQL وMySQL وMongoDB Atlas وAWS RDS وAzure SQL) تدعم ذلك. يحمي التشفير الشفاف للبيانات (TDE) البيانات على القرص، لكنه لا يحمي من مستخدم قاعدة بيانات مخترَق يملك صلاحية الاستعلام. للحقول شديدة الحساسية (أرقام التأمين الوطني والسجلات الطبية وأرقام الحسابات المالية)، فكّر في تشفير الحقول على مستوى التطبيق باستخدام AES-256-GCM مع خدمة إدارة مفاتيح (AWS KMS أو Azure Key Vault أو HashiCorp Vault). يجب تخزين المفتاح بمعزل عن البيانات التي يشفرها.

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

ما ينبغي تجنبه. لا تخزّن البيانات الشخصية بنص صريح في ملفات السجل أو الملفات المؤقتة أو ذاكرة التخزين المؤقت للتطبيقات حيث قد لا يُطبَّق التشفير. راجع كل مسار كود يعالج البيانات الشخصية وتأكد من عدم الاحتفاظ بنسخ غير مشفرة دون قصد.

التشفير أثناء النقل

إعداد TLS. طبّق TLS 1.2 كحد أدنى مع TLS 1.3 كإعداد افتراضي حيثما كان مدعوماً. عطّل SSLv3 وTLS 1.0 وTLS 1.1 كلياً. على nginx:

1ssl_protocols TLSv1.2 TLSv1.3;
2ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
3ssl_prefer_server_ciphers off;

HSTS. اضبط رأس Strict-Transport-Security بقيمة max-age طويلة مع includeSubDomains. قيمة max-age لا تقل عن 31536000 (سنة واحدة) هي المعيار. سجّل في قائمة التحميل المسبق لـ HSTS إن سمح نشرك بذلك.

1Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

المحتوى المختلط. تقديم أي مورد (صور وسكريبتات وأوراق أنماط ومكالمات API) عبر HTTP من صفحة HTTPS يُنشئ ثغرة محتوى مختلط ويُضعف أمان النقل. اضبط سياسة أمان المحتوى لحجب المحتوى المختلط وافحص صفحتك عن أي موارد محملة بغير HTTPS.

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

تقليل البيانات في الكود

تقليل البيانات ليس تجريداً قانونياً، بل هو قرار تصميمي يُتخذ حقلاً حقلاً. قبل جمع أي بيانات شخصية، تساءل: هل يحتاج التطبيق فعلاً إلى هذه البيانات ليعمل؟ إن لم تستطع الإجابة بحالة استخدام محددة، فلا تجمعها.

في الممارسة يعني ذلك:

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

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

التخفية

تُحل التخفية محل المعلومات المعرِّفة مباشرة برمز أو معرّف لا يمكن من خلاله تحديد هوية الفرد دون الوصول إلى مفتاح أو جدول تعيين محفوظ بشكل منفصل. تُدرجها المادة 32 صراحةً ضمن التدابير التقنية الموصى بها، وتنص المادة 89 على تخفيف الالتزامات عند معالجة بيانات مُخفاة لأغراض البحث.

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

1import hmac, hashlib
2
3def pseudonymise(user_id: str, site_secret: str) -> str:
4    return hmac.new(
5        site_secret.encode(),
6        user_id.encode(),
7        hashlib.sha256
8    ).hexdigest()

يجب تخزين الملح بمعزل عن بيانات التحليل؛ بدونه لا يمكن عكس قيمة التجزئة لتحديد هوية الفرد. يعني ذلك أن نظام التحليل لا يحتوي إلا على معرفات مُخفاة، مما يُقلل من ملف مخاطر الاختراق.

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

حق الحذف: التطبيق الصحيح

يُعدّ حق الحذف (المادة 17) من أصعب التزامات GDPR تقنياً من حيث التطبيق السليم. المتطلبات محددة:

الحذف الفعلي لا المنطقي. وضع علامة is_deleted وتصفيتها من الاستعلامات لا يفي بحق الحذف. يجب إزالة البيانات فعلياً من قاعدة البيانات. ابنِ وظيفة الحذف الفعلي لكل كيان يحتوي بيانات شخصية.

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

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

  • قائمة موثقة بكل خدمة طرف ثالث تتلقى بيانات شخصية
  • آلية حذف مؤكدة لكل خدمة (مكالمة API أو تذكرة دعم أو معالجة آلية لطلبات أصحاب البيانات)
  • دليل على اكتمال الحذف

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

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

اكتشاف الخروقات ومتطلب الإخطار خلال 72 ساعة

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

ما ينبغي تسجيله لاكتشاف الخروقات. ينبغي أن يلتقط نظام التسجيل لديك:

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

ما لا ينبغي تسجيله. لا تسجّل قيم البيانات الشخصية في سجلات التطبيق. سجلات التصحيح التي تُدوّن هيئات الطلبات كاملة أو استعلامات قواعد البيانات مع قيم المعاملات المُعوَّضة أو بيانات النماذج التي يُدخلها المستخدم تُنشئ مستودعات ثانوية للبيانات الشخصية يصعب إدارتها وتقع هي نفسها ضمن نطاق GDPR. سجّل المعرفات (معرفات المستخدمين والجلسات والطلبات) لا القيم.

1# خاطئ: يسجّل عنوان البريد الإلكتروني الفعلي
2logger.debug(f"Login attempt for user {request.form['email']}")
3
4# صحيح: يسجّل معرّفاً فقط
5logger.debug(f"Login attempt, user_id={user.id}, request_id={request_id}")

التخطيط للاستجابة للخروقات. يُتيح التسجيل الاكتشافَ، لكنك بحاجة إلى عملية موثقة تحدد ما يجري عند اكتشاف خرق. من يُخطَر داخلياً؟ من يتخذ قرار إخطار ICO؟ ما المعلومات التي يجب أن يتضمنها إخطار ICO؟ ابنِ هذه العملية قبل أن تحتاج إليها.

امتثال واجهات برمجة التطبيقات (APIs) للأطراف الثالثة

المتحكم في مقابل المعالج. إن كنت تستخدم خدمة طرف ثالث تعالج البيانات الشخصية نيابةً عنك (مزود بريد إلكتروني تعاملي أو مزود بنية تحتية سحابية أو معالج مدفوعات)، فهي معالج للبيانات وأنت المتحكم. أنت مسؤول عن امتثالهم لـ UK GDPR في هذا السياق.

اتفاقيات معالجة البيانات. يجب عليك إبرام اتفاقية معالجة بيانات (DPA) مكتوبة مع كل خدمة طرف ثالث تعالج البيانات الشخصية نيابةً عنك. معظم مزودي SaaS الكبار (AWS وMailchimp وStripe وTwilio وSendGrid) يقدمون اتفاقيات DPA معيارية. وقّعها واحتفظ بها. إن عجز مزوّد عن تقديم DPA، لا يجوز لك استخدامه قانونياً لمعالجة البيانات الشخصية بموجب UK GDPR.

المعالجون الفرعيون. ينبغي أن تُدرج DPA مع المعالج معالجيه الفرعيين (الخدمات التي يستخدمها بدوره لمعالجة بياناتك). مثلاً، قد يستخدم مزود البريد الإلكتروني التعاملي بنية AWS التحتية. لست مُلزَماً بإبرام DPA مباشر مع المعالجين الفرعيين، لكنك بحاجة إلى معرفة من هم وأين تُعالَج البيانات جغرافياً لأغراض امتثال النقل.

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

التحكم في الوصول

مبدأ الحد الأدنى من الصلاحيات. يجب أن يمتلك مستخدمو قاعدة البيانات الذين يستخدمهم تطبيقك الحد الأدنى من الأذونات المطلوبة: القراءة والكتابة على جداول بعينها دون وصول إداري. أنشئ بيانات اعتماد قاعدة بيانات منفصلة للخدمات كثيفة القراءة (التقارير والتحليلات) وتلك كثيفة الكتابة (التطبيق الموجه للمستخدمين). يُحدّ ذلك من نصف قطر الدمار عند اختراق بيانات الاعتماد.

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

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

قائمة تحقق المطور: 10 ضوابط تقنية للتطبيق

  1. تجزئة كلمات المرور. استخدم bcrypt (معامل تكلفة 12+) أو Argon2id. أزل فوراً أي تجزئة بـ MD5 أو SHA-1.
  2. التشفير في حالة السكون. فعّل TDE على مستوى قاعدة البيانات وطبّق تشفير الحقول AES-256-GCM للبيانات الشخصية شديدة الحساسية مع مفاتيح في KMS مدار.
  3. إعداد TLS. طبّق TLS 1.2 كحد أدنى وTLS 1.3 كإعداد افتراضي وHSTS بـ max-age لمدة عام ومنع المحتوى المختلط.
  4. تدقيق تقليل البيانات. راجع كل حقل في مخطط قاعدة بياناتك يحتوي بيانات شخصية. أزل أو أوقف جمع أي حقل دون حالة استخدام موثقة وفاعلة.
  5. تطبيق الحذف الفعلي. ابنِ حذفاً متتالياً مُتحقَّقاً من صحته لجميع البيانات الشخصية المرتبطة بمستخدم. اختبر أن الحذف يُزيل السجلات فعلياً ولا يكتفي بوضع علامة عليها.
  6. جرد DPA للأطراف الثالثة. أدرج كل خدمة SaaS أو سحابية تتلقى بيانات شخصية. تحقق من وجود DPA موقّعة لكل خدمة. أزل أي خدمة لا تستطيع تقديمها.
  7. نظافة التسجيل. دقّق في سجلات التطبيق عن PII. أزل قيم البيانات الشخصية من مخرجات السجل على كل مستوى. سجّل المعرفات فقط.
  8. تسجيل اكتشاف الخروقات. طبّق تسجيلاً منظماً لأحداث المصادقة وفشل التفويض والوصول المجمّع إلى البيانات. اضبط تنبيهات للأنماط الشاذة.
  9. مراجعة التحكم في الوصول. دقّق في بيانات اعتماد قاعدة البيانات وأدوار التطبيق مقابل مبدأ الحد الأدنى من الصلاحيات. أزل الوصول الإداري من مستخدمي قاعدة بيانات التطبيق.
  10. تخفية التحليلات. استبدل معرفات المستخدمين المباشرة في مكالمات التحليل والتتبع للأطراف الثالثة بقيم مُجزَّأة بـ HMAC باستخدام سر خاص بالموقع.

النقاط الرئيسية

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

الأسئلة الشائعة

هل يسري UK GDPR إن كان جميع مستخدمي خارج المملكة المتحدة؟ يسري UK GDPR إن كنت مُقاماً في المملكة المتحدة بصرف النظر عن موقع مستخدميك. كما يسري على المنظمات خارج المملكة المتحدة التي تُقدم سلعاً أو خدمات لأشخاص في المملكة المتحدة أو ترصد سلوكهم. إن كنت مطوراً مقيماً في المملكة المتحدة تبني لجمهور غير بريطاني، يُطبَّق UK GDPR على أنشطتك التشغيلية.

هل التشفير إلزامي بموجب UK GDPR؟ التشفير مُدرج صراحةً في المادة 32(1)(أ) بوصفه تدبيراً موصى به. وليس متطلباً إلزامياً مطلقاً لأن اللوائح تشترط تدابير “ملائمة للمخاطر”. غير أنه من الناحية العملية، بالنسبة لأي تطبيق يتعامل مع البيانات الشخصية عبر الإنترنت، سيكون من الصعب جداً تبرير عدم تشفير البيانات أثناء النقل وفي حالة السكون أمام ICO. تعامل معه بوصفه إلزامياً.

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

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

هل نحتاج إلى مسؤول حماية بيانات؟ مسؤول حماية البيانات (DPO) إلزامي للسلطات العامة والمنظمات التي تعالج بيانات شخصية حساسة على نطاق واسع والمنظمات التي تجري مراقبة منهجية على نطاق واسع. وبالنسبة لمعظم شركات البرمجيات البريطانية، لا يُعدّ DPO إلزامياً لكنه مستحسن إن كنت تعالج كميات كبيرة من البيانات الشخصية. تُقدم ICO إرشادات محددة بشأن هذه العتبة على موقعها.

ما أقصى غرامة لعدم الامتثال لـ UK GDPR؟ يمكن لـ ICO فرض غرامات تصل إلى 17.5 مليون جنيه إسترليني أو 4% من إجمالي المبيعات السنوية العالمية (أيهما أعلى) للمخالفات الأشد خطورة. وتنطبق غرامات الشريحة الأدنى البالغة 8.7 مليون جنيه إسترليني أو 2% من المبيعات العالمية على المخالفات الأقل خطورة. وفي الواقع العملي، تقع معظم غرامات ICO أدنى بكثير من الحد الأقصى ويُضبط مقدارها وفق خطورة الخرق ومدى تعاون المنظمة والخطوات المتخذة لمعالجة المشكلة.