قد يكون تطبيقك آمناً ومع ذلك يخالف قانون حماية البيانات في البحرين

لماذا لا تمثّل المصادقة والتشفير والبنية التحتية الآمنة سوى جزء من حماية البيانات الشخصية.

لقد طبّقت بروتوكول HTTPS، وشفّرت قاعدة بياناتك، وضبطت التحكم في الوصول القائم على الأدوار، وأمّنت واجهات API لديك.

واجتاز تطبيقك اختباراته الأمنية.

لكن إليك سؤالاً:

هل أنت متأكد من أن تطبيقك يتعامل مع البيانات الشخصية بشكل قانوني؟

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

فقانون حماية البيانات الشخصية في البحرين (PDPL)، الصادر بموجب القانون رقم 30 لسنة 2018، يفرض التزامات تتجاوز أمن التطبيقات التقليدي.

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

لنرَ السبب.

الأمن لا يعني تلقائياً الامتثال لمتطلبات الخصوصية

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

فنحن نطبّق:

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

هذه التدابير أساسية، لكنها تعالج في المقام الأول كيفية حماية المعلومات من الوصول غير المصرّح به ومن التهديدات الأمنية.

أما تشريعات الخصوصية فتطرح أسئلة إضافية.

• لماذا نجمع هذه المعلومات؟
• هل نحتاج إلى كل حقل في قاعدة البيانات هذه؟
• كم من الوقت ينبغي أن نحتفظ بها؟
• مع من نشاركها؟
• ماذا يحدث عندما لا تعود المعلومات مطلوبة؟

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

المثال 1: جمع بيانات أكثر من اللازم

لنأخذ نموذج تسجيل مستخدم بسيطاً.

{
  "full_name": "Ahmed",
  "email": "[email protected]",
  "phone": "+973XXXXXXXX",
  "date_of_birth": "1995-01-01",
  "national_id": "XXXXXXXXX"
}

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

فلماذا يجمع رقم الهوية الوطنية أو تاريخ الميلاد؟

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

ومن المبادئ التي ينبغي أن يراعيها المطورون مبدأ تقليل البيانات: أي قصر الجمع على المعلومات الضرورية لغرض مشروع ومحدد.

وقد تكون بنية التسجيل الأنسب على النحو التالي:

{
  "email": "[email protected]",
  "password": "securely_processed_password"
}

وتعتمد الحقول المطلوبة فعلياً على غرض التطبيق والمتطلبات القانونية المعمول بها.

والدرس بسيط: كل حقل إضافي من البيانات الشخصية يُنشئ مسؤولية إضافية.

المثال 2: الاحتفاظ بالبيانات الشخصية إلى الأبد

تخيّل أن تطبيقك يخزّن سجلات نشاط المستخدمين.

CREATE TABLE user_activity (
    id BIGINT PRIMARY KEY,
    user_id BIGINT,
    ip_address VARCHAR(45),
    activity TEXT,
    created_at TIMESTAMP
);

يجمع التطبيق المعلومات باستمرار، لكن لا توجد سياسة للاحتفاظ بالبيانات.

وبعد خمس سنوات، لا تزال قاعدة البيانات تحتوي على سجلات تاريخية ربما لم تعد تخدم غرضها الأصلي.

ويثير ذلك عدة مخاوف:

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

ومن المناهج الهندسية العملية تحديد متطلبات الاحتفاظ أثناء تصميم النظام.

على سبيل المثال:

def process_expired_records(records, retention_policy):
    for record in records:
        if retention_policy.is_expired(record):
            retention_policy.apply_disposition(record)

وينبغي تحديد مدة الاحتفاظ المناسبة وطريقة التصرف في البيانات وفقاً لغرض البيانات والالتزامات القانونية المعمول بها والسياسات المؤسسية.

ينبغي أن يكون الاحتفاظ بالبيانات قراراً تصميمياً موثّقاً، لا نتيجة عَرَضية لبنية قاعدة البيانات.

المثال 3: مشاركة البيانات مع خدمات أطراف خارجية

نادراً ما تعمل التطبيقات الحديثة بشكل مستقل.

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

لنأخذ تطبيقاً يرسل معلومات العملاء إلى واجهة API خارجية.

await fetch("https://api.example.com/analyze", {
  method: "POST",
  headers: {
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    customerName: user.name,
    customerEmail: user.email,
    conversation: user.messages
  })
});

قد يكون طلب API مشفّراً وموثّقاً بشكل سليم.

ومع ذلك، تبقى أسئلة إضافية:

• هل المزوّد الخارجي مخوَّل بتلقي هذه المعلومات؟
• هل إرسال بيانات العملاء القابلة للتعريف بهم ضروري؟
• أين سيعالج المزوّد المعلومات ويخزّنها؟
• هل توجد ضمانات تعاقدية وتنظيمية مناسبة؟
• هل ينطوي النقل على ولاية قضائية أخرى؟

وبحسب الظروف، قد تصبح متطلبات قانون PDPL في البحرين المتعلقة بالمعالجة والنقل الدولي للبيانات ذات صلة.

ومن ممارسات التطوير الأكثر أماناً تقييم تدفقات البيانات الخارجية قبل التكامل مع خدمات الأطراف الخارجية.

على سبيل المثال، يمكن للمطورين إزالة المُعرّفات غير الضرورية قبل إرسال المعلومات متى سمحت حالة الاستخدام بذلك.

من المسؤول عن الامتثال لمتطلبات حماية البيانات؟

يطرح ذلك تحدياً مثيراً للاهتمام.

فالمطورون يفهمون الأنظمة.

وفرق الأمن تفهم المخاطر التقنية.

وفرق الشؤون القانونية والامتثال تفهم الالتزامات التنظيمية.

لكن من يضمن تنسيق هذه المسؤوليات؟

يعترف قانون PDPL في البحرين بدور يُعرف باسم مراقب حماية البيانات.

وبموجب المادة 10 من القانون، يؤدي مراقبو حماية البيانات مهام تشمل مساعدة المؤسسات في الوفاء بالتزاماتها المتعلقة بحماية البيانات، ومراقبة الامتثال، والتنسيق مع الجهة التنظيمية المختصة.

ويعترف الإطار التنظيمي بكلٍّ من المراقبين الداخليين والخارجيين.

ومراقب حماية البيانات الخارجي هو فرد أو كيان اعتباري مسجَّل يجوز تعيينه لأداء مسؤوليات الإشراف هذه.

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

ويربط هذا الدور المتطلبات التنظيمية بالعمليات المؤسسية والأنظمة التقنية المستخدمة في التعامل مع البيانات الشخصية.

ما الذي يمكن للمطورين فعله اليوم

لست بحاجة إلى أن تصبح خبيراً قانونياً لتبدأ في بناء تطبيقات بممارسات خصوصية أفضل.

فبضعة قرارات هندسية يمكن أن تُحدث فرقاً ملموساً.

1. احصر تدفقات بياناتك

افهم أين تدخل المعلومات الشخصية إلى تطبيقك، وأين تُخزَّن، وأي الخدمات تتلقاها، وكيف تُزال في نهاية المطاف.

2. قلّل الجمع

تجنّب جمع المعلومات الشخصية لمجرد أنها قد تكون مفيدة يوماً ما.

3. حدّد متطلبات الاحتفاظ

اعمل مع الأطراف المعنية في الأعمال والامتثال لوضع سياسات الاحتفاظ والحذف.

4. راجع عمليات التكامل مع الأطراف الخارجية

اعرف ما المعلومات الشخصية التي تغادر بنيتك التحتية، وأي مزوّدي الخدمات يعالجونها.

5. صمّم مع مراعاة الخصوصية منذ البداية

راعِ متطلبات حماية البيانات خلال تصميم البنية والتطوير بدلاً من الانتظار حتى مرحلة النشر.

6. أشرك الأطراف المعنية المناسبة

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

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

الصورة الأشمل

أصبحت هندسة الخصوصية جزءاً مهماً من تطوير البرمجيات الحديث.

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

ولذلك أصبح فهم متطلبات حماية البيانات وثيق الصلة ببنية البرمجيات بقدر المصادقة والتشفير وإدارة الوصول.

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

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

ويُمكّن هذا التسجيل فيرتيوثينكو من الاضطلاع بهذا الدور للمؤسسات التي تحتاج إلى إشراف خارجي على حماية البيانات.

أما بالنسبة إلى المطورين والفرق التقنية، فالخلاصة المهمة هي أن تطوير البرمجيات الآمنة والامتثال لمتطلبات الخصوصية لا ينبغي أن يعملا بمعزل عن بعضهما.

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

وكلاهما مهم.

---

المراجع

1. قانون حماية البيانات الشخصية في البحرين، القانون رقم 30 لسنة 2018
2. القرار رقم (46) لسنة 2022 بشأن مُراقبي حماية البيانات
3. هيئة حماية البيانات الشخصية، مملكة البحرين

الأمثلة التقنية توضيحية ولا تُعدّ استشارة قانونية.