تطوير البرمجيات المتوافقة مع اللائحة العامة لحماية البيانات (GDPR): دليل عملي للشركات البريطانية والأوروبية

كل أسبوع نتحدث مع شركات بنت برمجياتها دون أن تولي اللائحة العامة لحماية البيانات (GDPR) اهتمامًا جديًا، وهي الآن تدفع ثمن ذلك — أحيانًا في الرسوم القانونية، وأحيانًا في إعادة الهيكلة الطارئة، وفي بعض الأحيان في غرامات هيئة مفوض المعلومات (ICO). عادةً ما تبدأ المحادثة بعبارة باتت مألوفة لدينا: «نعلم أننا بحاجة إلى ترتيب أوضاع الامتثال لدينا، لكننا لم تتح لنا الفرصة بعد.»

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

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

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

---

اللائحة العامة لحماية البيانات في جملة واحدة

اللائحة العامة لحماية البيانات (EU 2016/679) هي قانون حماية البيانات الذي يُطبَّق على أي منظمة تعالج البيانات الشخصية لأشخاص في الاتحاد الأوروبي أو المملكة المتحدة، بصرف النظر عن مقر تلك المنظمة. إذا كان لديك مستخدمون في الاتحاد الأوروبي أو المملكة المتحدة، فإنها تنطبق عليك.

من الناحية العملية، تتطلب ستة أشياء:

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

الغرامة القصوى للانتهاك الجسيم هي 20 مليون يورو أو 4% من حجم المبيعات السنوي العالمي — أيهما أعلى. أظهرت هيئة مفوض المعلومات (ICO) في المملكة المتحدة والسلطات الإشرافية في الاتحاد الأوروبي استعدادها لاستخدام هذه الأرقام. غُرِّمت شركة British Airways بمبلغ 20 مليون جنيه إسترليني. وغُرِّمت Amazon بمبلغ 746 مليون يورو. هذه ليست حالات استثنائية خاصة بالشركات متعددة الجنسيات المتهورة؛ فالشركات الصغيرة والمتوسطة تواجه التطبيق أيضًا، والضرر الذي يلحق بالسمعة جراء إشعار التطبيق العام قد يكون أكثر ضررًا من الغرامة نفسها.

---

الخصوصية بالتصميم: ما تعنيه من الناحية العملية

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

المبادئ السبعة الأساسية للخصوصية بالتصميم، مترجمةً إلى قرارات هندسية، تبدو هكذا:

1. استباقي لا ردّ فعل

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

2. الخصوصية كإعداد افتراضي

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

3. الخصوصية مدمجة في التصميم

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

4. الوظيفية الكاملة

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

5. الأمان الشامل

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

6. الرؤية والشفافية

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

7. احترام خصوصية المستخدم

ضع مصالح المستخدم في المقام الأول. بمصطلحات البرمجيات: تُطبَّق سياسات الاحتفاظ بالبيانات بواسطة التطبيق، لا تُترك للتنظيف اليدوي؛ ويتتابع الحذف عبر جميع الأنظمة بما في ذلك النسخ الاحتياطية والذاكرة المؤقتة.

---

الأساس القانوني لمعالجة البيانات

هذا هو المجال الذي نرى فيه في أغلب الأحيان سوء الفهم الجوهري في مشاريع البرمجيات — ليس لأن المطورين مهملون، بل لأن المفاهيم القانونية لها عواقب تقنية يسهل تفويتها.

تحدد اللائحة العامة لحماية البيانات ستة أسس قانونية لمعالجة البيانات الشخصية. الأربعة الأكثر صلة بمعظم منتجات البرمجيات هي:

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

السبب في أن اختيار الأساس الخاطئ يمثّل مشكلة تقنية لا مجرد مشكلة قانونية:

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

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

توصيتنا: وثِّق الأساس القانوني لكل نشاط من أنشطة معالجة البيانات في سجل أنشطة المعالجة (RoPA) قبل اتخاذ قرارات البنية التحتية. سيغيّر ذلك تلك القرارات.

---

تطبيق إدارة الموافقة

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

ما تتطلبه الموافقة الصحيحة

بموجب اللائحة العامة لحماية البيانات، يجب أن تكون الموافقة:

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

تطبيق موافقة ملفات تعريف الارتباط

يجب أن تفي لافتة ملفات تعريف الارتباط المتوافقة تقنيًا بما يلي:

1. حظر تحميل جميع السكريبتات غير الأساسية حتى تُمنح الموافقة — لا مجرد تعيين ملف تعريف الارتباط الذي يشير إلى التفضيل.
2. تسجيل الموافقة مع طابع زمني، وإصدار سياسة الخصوصية المعروضة، والفئات المحددة المقبولة.
3. السماح بموافقة تفصيلية حسب الفئة (ضرورية، وتحليلات، وتسويق، وتفضيلات).
4. توفير آلية لسحب الموافقة في أي وقت.

هذا يعني أن تكون إعدادات مدير العلامات الخاص بك مقيّدة خلف حالة الموافقة. إذا كنت تستخدم Google Tag Manager، فيجب أن تُطلق السكريبتات في فئتَي التحليلات والإعلانات فقط بعد ضبط إشارات الموافقة المقابلة. يُعدّ التطبيق الخاطئ لهذا الأمر — عرض لافتة ولكن تحميل السكريبتات على أي حال — أحد أكثر الانتهاكات شيوعًا التي نراها على أرض الواقع.

منصات إدارة الموافقة

بالنسبة لمعظم المشاريع، لا يُعدّ تطبيق إدارة الموافقة من الصفر الخيار الصحيح. الخيارات الرئيسية هي:

OneTrust — بمستوى المؤسسات، وقابل للتكوين بدرجة عالية، ويتكامل مع معظم منصات إدارة الموافقة وكتالوجات البيانات. مناسب للمنظمات الكبيرة ذات احتياجات الموافقة المعقدة.

Cookiebot (المعروف حاليًا بـ Usercentrics) — خيار جيد لمتوسطي السوق، يفحص ملفات تعريف الارتباط تلقائيًا ويصنّفها، وسهل التكامل عبر وسم السكريبت أو GTM.

التطبيق المخصص — مناسب للتطبيقات التي لديها تدفقات موافقة غير مألوفة (على سبيل المثال، برنامج SaaS للشركات B2B حيث يكون صاحب عمل المستخدم النهائي هو المتحكم في البيانات) أو حيث لا تناسب المنصات الحالية متطلبات تجربة المستخدم. يتطلب تصميمًا دقيقًا لمخطط سجل الموافقة.

مركز تفضيلات التسويق

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

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

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

---

الحد الأدنى من البيانات من الناحية العملية

الحد الأدنى من البيانات — المادة 5(1)(c) — هو المبدأ القائل بأنه يجب عليك جمع البيانات الشخصية الضرورية فقط للغرض المحدد الذي ذكرته. يبدو هذا واضحًا. لكن من الناحية العملية، يتطلب انضباطًا فعّالًا لأن الميل الطبيعي لفرق البرمجيات هو جمع أكبر قدر ممكن من البيانات «على حال إن كانت مفيدة لاحقًا».

جرد معلومات التعريف الشخصي وتصنيف البيانات

نقطة البداية هي معرفة البيانات الشخصية التي تجمعها فعليًا. جرد معلومات التعريف الشخصي (PII) هو فهرس منظم لكل نقطة بيانات يتعامل معها نظامك، مُوسوم بـ:

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

كثيرًا ما تُفاجئ هذه العملية الفرق. عناوين IP في سجلات الخادم لم يُفكر فيها أحد. سلاسل User-agent تُكتب في قاعدة بيانات جانب سجلات الحسابات. عناوين كاملة تُخزَّن لميزة توصيل تم إيقافها منذ ثمانية عشر شهرًا.

الأنماط المعمارية للحد الأدنى من البيانات

بما يتجاوز الجرد، ينبغي أن تجعل البنية التحتية نفسها الحد الأدنى من البيانات هو المسار الأقل مقاومة:

• افصل مخازن معلومات التعريف الشخصي عن مخازن المعاملات. إذا كانت قاعدة بيانات التحليلات لديك تربط مباشرةً بعناوين البريد الإلكتروني، فهذه مشكلة حد أدنى من البيانات. استخدم معرّفات مستعارة (pseudonymous) في خطوط أنابيب التحليلات واحتفظ بجدول التعيين في خدمة مقيّدة.
• اجمع البيانات عند الحاجة، لا بصورة تخمينية. لا تطلب رقم الهاتف عند إنشاء الحساب إذا كانت أرقام الهاتف مطلوبة فقط للمصادقة ثنائية العامل — اطلبه عندما يُفعِّل المستخدم المصادقة الثنائية 2FA.
• طبِّق الاحتفاظ في الكود، لا في وثائق السياسة. السياسة التي تقول إن البيانات تُحذف بعد عامين ليست امتثالًا. المهمة المجدولة التي تُطبّق الحذف بعد عامين مع سجلات تثبت ذلك، هي الامتثال.

---

حقوق أصحاب البيانات

تمنح اللائحة العامة لحماية البيانات الأفراد ثمانية حقوق. الأربعة التي تتطلب أكبر قدر من التطبيق التقني هي:

حق الوصول (طلب الوصول إلى البيانات)

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

التطبيق التقني: ابنِ طبقة تجميع بيانات يمكنها جمع البيانات المتعلقة بمستخدم من كل خدمة تحتفظ بها — قاعدة بيانات تطبيقك، ومنصة التحليلات، ونظام إدارة علاقات العملاء (CRM)، ونظام تذاكر الدعم — وتجميعها في ملف تصدير منظم. بالنسبة لمعظم التطبيقات، هذه مهمة هندسية غير هيّنة، وهذا بالضبط سبب ضرورة التخطيط لها في مرحلة البنية التحتية بدلًا من التعامل معها بصورة مرتجلة عند وصول طلب.

بالنسبة للتطبيقات ذات الحجم الكبير، يُعدّ بوابة طلبات الوصول إلى البيانات للخدمة الذاتية التي تُولّد الملف تلقائيًا تحسينًا لكل من الامتثال والعمليات.

حق المحو (الحق في أن يُنسى)

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

التطبيق التقني: يجب أن يتتابع الحذف في كل مكان توجد فيه البيانات. يعني هذا:

• قاعدة بيانات التطبيق (الحذف الفوري أو إخفاء هوية حقول معلومات التعريف الشخصي)
• النسخ الاحتياطية (عملية واضحة لاستبعاد سجلات بعينها من استعادة النسخ الاحتياطية، أو جدول احتفاظ بالنسخ الاحتياطية يُحدد المدة التي تستمر فيها البيانات المحذوفة)
• الذاكرة المؤقتة (إبطال صلاحية الذاكرة المؤقتة عند الحذف)
• الخدمات الخارجية (طلبات الحذف إلى نظام CRM، ومنصة البريد الإلكتروني، وأداة التحليلات، ونظام الدعم)
• البيانات المشتقة (مجموعات بيانات تدريب التعلم الآلي، وإجماليات التحليلات التي قد تحتوي على بيانات على مستوى الفرد)

حق قابلية النقل

يمكن للفرد طلب بياناته بتنسيق منظم وشائع الاستخدام يمكن للآلة قراءته — عادةً JSON أو CSV — بغرض نقله إلى خدمة أخرى.

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

حق التصحيح

يمكن للفرد طلب تصحيح البيانات الشخصية غير الدقيقة.

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

---

إقامة البيانات ومعالجو الجهات الخارجية

أحد أهم الانعكاسات التقنية وأقلّها تقديرًا في اللائحة العامة لحماية البيانات هو القيود المفروضة على نقل البيانات الشخصية خارج الاتحاد الأوروبي/المنطقة الاقتصادية الأوروبية (وخارج المملكة المتحدة بموجب اللائحة البريطانية).

المشهد في أعقاب حكم Schrems II

أبطل حكم Schrems II الصادر عن محكمة العدل الأوروبية عام 2020 إطار درع الخصوصية بين الاتحاد الأوروبي والولايات المتحدة، الذي كان سابقًا الآلية القانونية التي تتيح نقل البيانات الشخصية الأوروبية إلى معالجين في الولايات المتحدة. آلية الاستبدال هي البنود التعاقدية القياسية (SCCs) — بنود عقدية معتمدة مسبقًا يوقعها الطرفان قبل أي نقل للبيانات.

من الناحية العملية، هذا يعني أنك إذا كنت تستخدم أي أداة SaaS مقرها الولايات المتحدة — منصة تحليلات مستضافة في الولايات المتحدة، أو مراكز بيانات لمزود سحابة أمريكي، أو CRM مقره الولايات المتحدة — فأنت بحاجة إلى:

1. التحقق مما إذا كان البائع يتيح البنود التعاقدية القياسية (SCCs) (تتيحها معظم البائعين الرئيسيين).
2. تنفيذ تلك البنود قبل نقل البيانات الشخصية.
3. إجراء تقييم أثر النقل للتحقق من أن قوانين البلد المستلم لا تقوّض حمايات البنود التعاقدية القياسية.

مراجعة مزودي الخدمات السحابية ومجموعة SaaS

يجب أن توثّق مراجعة نقل البيانات كل خدمة خارجية ترسل إليها تطبيقك بيانات شخصية، وتسجّل لكل واحدة:

• آلية النقل القانوني (البنود التعاقدية القياسية، وقرار الملاءمة، والاستثناء)
• موقع (مواقع) مركز البيانات
• المعالجون الفرعيون الذين يستخدمهم ذلك البائع
• رابط اتفاقية معالجة البيانات (DPA) المنفَّذة

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

اتفاقيات معالجة البيانات

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

---

متطلبات الأمان بموجب اللائحة العامة لحماية البيانات

تُلزم المادة 32 المنظمات بتطبيق «تدابير تقنية وتنظيمية مناسبة» لضمان مستوى أمان يتناسب مع المخاطر. تتجنب اللائحة عمدًا تحديد معايير تقنية دقيقة — لكن ما يلي متفق عليه على نطاق واسع كمتطلبات أساسية لمعظم التطبيقات.

التشفير

• في وضع السكون: تشفير قاعدة البيانات (AES-256 هو المعيار الأساسي)، والنسخ الاحتياطية المشفرة، وتخزين الملفات المشفرة. تشفير على مستوى التطبيق للحقول الحساسة بشكل خاص (البيانات الصحية، والبيانات المالية) بحيث لا يستطيع مسؤولو قاعدة البيانات قراءتها بنص واضح.
• أثناء النقل: TLS 1.2 كحد أدنى، TLS 1.3 مُفضَّل. ترويسات HSTS. لا محتوى مختلط. مراقبة الشهادات.

إخفاء الهوية (Pseudonymisation)

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

ضوابط الوصول

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

تسجيل المراجعة

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

كشف الخروقات وقاعدة 72 ساعة

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

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

---

اللائحة البريطانية لحماية البيانات بعد خروج بريطانيا من الاتحاد الأوروبي

في أعقاب خروج بريطانيا من الاتحاد الأوروبي، لم تعد المملكة المتحدة خاضعة للائحة الأوروبية العامة لحماية البيانات. عوضًا عن ذلك، تنطبق اللائحة البريطانية لحماية البيانات (UK GDPR) — وهي اللائحة الأوروبية كما تم دمجها في القانون البريطاني مع بعض التعديلات — على المنظمات التي تعالج البيانات الشخصية للأشخاص في المملكة المتحدة.

من الناحية العملية، اللائحة البريطانية واللائحة الأوروبية متطابقتان جوهريًا في معظم الجوانب. تنطبق المبادئ والحقوق والأسس القانونية ذاتها، ومستويات غرامات مماثلة. الاختلافات العملية الرئيسية هي:

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

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

---

أخطاء اللائحة الشائعة في مشاريع البرمجيات

هذه هي الأنماط التي نراها أكثر ما نرى عند مراجعة قواعد الأكواد الحالية بحثًا عن ثغرات الامتثال:

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

لا توجد سياسات احتفاظ بالبيانات مطبَّقة في الكود. تقول سياسة الخصوصية إن البيانات تُحتفظ بها لثلاث سنوات. قاعدة البيانات تحتوي على سجلات تمتد لثماني سنوات دون مهمة حذف في الأفق. وثيقة السياسة التي لا يطبّقها التطبيق ليست امتثالًا — بل هي مسؤولية قانونية.

سكريبتات خارجية منسية تنقل البيانات إلى الولايات المتحدة. يضيف فريق التسويق أداة دردشة مباشرة. يضيف مطوّر أداة خريطة حرارية. يضيف مطوّر آخر خطًا من جهة خارجية. لا يظهر أيٌّ من هذه في سجل اتفاقية معالجة البيانات. كل واحدة منها تنقل عناوين IP للمستخدمين — وربما أكثر من ذلك — إلى خادم في الولايات المتحدة دون آلية نقل قانوني ودون أن يحجبها نظام إدارة الموافقة.

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

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

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

---

كيف نبني برمجيات متوافقة مع اللائحة في Cyberbeak

الخصوصية بالتصميم مدمجة في طريقة إدارتنا لكل مشروع، لا يُتعامل معها كمراجعة في مرحلة متأخرة.

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

بالنسبة للمشاريع التي تنطوي على معالجة عالية المخاطر — البيانات الصحية، والبيانات المالية، والتنميط الواسع النطاق، والبيانات المتعلقة بالأطفال — نُجري تقييمًا رسميًا لأثر حماية البيانات قبل بدء التطوير. يوثّق التقييم المخاطر والتدابير المخففة والمخاطر المتبقية، ويُراجعه من يشغل دور مسؤول حماية البيانات (DPO) لدى العميل (أو يمكننا توفير تلك الوظيفة كخدمة).

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

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

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

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

---

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

هل تحتاج الشركات الناشئة الصغيرة إلى القلق بشأن اللائحة العامة لحماية البيانات؟

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

ما هي الغرامات على انتهاكات اللائحة العامة لحماية البيانات؟

هناك مستويان. يُطبَّق المستوى الأدنى على انتهاكات الالتزامات كسجلات الموافقة، ومتطلبات معالج البيانات، وإشعارات الخصوصية — غرامات تصل إلى 10 ملايين يورو أو 2% من حجم المبيعات السنوي العالمي. يُطبَّق المستوى الأعلى على انتهاكات المبادئ الجوهرية للائحة — الأساس القانوني، والحد الأدنى من البيانات، وحقوق أصحاب البيانات، والتحويلات الدولية — غرامات تصل إلى 20 مليون يورو أو 4% من حجم المبيعات السنوي العالمي. لدى هيئة مفوض المعلومات هيكل غرامات مكافئ خاص بها بموجب اللائحة البريطانية، بحد أقصى 17.5 مليون جنيه إسترليني أو 4% من حجم الأعمال العالمي.

هل يُعدّ استخدام AWS (أو GCP أو Azure) متوافقًا مع اللائحة؟

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

هل نحتاج إلى مسؤول حماية البيانات؟

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

ما الذي تعنيه اللائحة البريطانية لحماية البيانات لأعمالنا بعد خروج بريطانيا من الاتحاد الأوروبي؟

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

---

إذا كنت تبني منتجًا جديدًا وتريد الحصول على متطلبات اللائحة العامة لحماية البيانات بشكل صحيح من البداية — أو إذا كان لديك تطبيق قائم يحتاج إلى مراجعة الامتثال — يمكننا المساعدة. تتضمن عملية الاكتشاف لدينا رسم خرائط تدفق البيانات وتقييم الخصوصية بالتصميم كأمر قياسي، وعملنا مع شركات في قطاعات التكنولوجيا المالية (fintech)، والتكنولوجيا الصحية (healthtech)، والتجارة الإلكترونية، وبرامج B2B SaaS لبناء أنظمة مفيدة فعلًا ومتوافقة فعلًا.

تواصل معنا لمناقشة مشروعك.