مخاطر الموردين Third-party Risk: ماذا تسأل قبل التعاقد

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

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

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

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

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

لماذا المورد داخل حدود ثقتك؟

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

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

لماذا صارت مخاطر المورد أهم من قبل؟

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

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

دورة حياة مخاطر المورد

إدارة مخاطر المورد ليست حدثاً واحداً قبل التوقيع، وإنما دورة تمتد من قبل العقد إلى بعده، والصورة التالية تبينها مع الضوابط المقابلة:

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

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

لا تعامل كل مورد سواء: التصنيف بالمخاطر

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

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

كيف يحسب السكربت الطبقة؟

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

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

تجربة عملية: من جرد الموردين إلى خطة تقييم

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

vendor,service,data_access,system_criticality,remote_access,hosts_in_ksa,certifications,subprocessors
مزود الدفع,بوابة الدفع,بيانات بطاقات,high,no,yes,PCI DSS; ISO 27001,2
مزود الاستضافة السحابية,استضافة التطبيق,كل البيانات,high,yes,yes,ISO 27001; SOC 2,5
مزود المراقبة المدار,SOC مدار,السجلات الأمنية,high,yes,yes,ISO 27001,1
مزود البريد,البريد الإلكتروني,مراسلات داخلية,medium,no,no,SOC 2,3
مزود التصميم,هوية بصرية,لا بيانات حساسة,low,no,no,,0
شركة الدعم الفني,صيانة الأجهزة,وصول للأجهزة,medium,yes,no,,0
مزود المحاسبة السحابي,المحاسبة,بيانات مالية,medium,no,yes,ISO 27001,2

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

"""Turns a vendor inventory into an inherent risk tier and the assessment depth each vendor needs.
   Tier is driven by what the vendor can reach and how critical it is, not by its size or logo.
   Certifications do NOT lower the tier (the risk is the same); they make the assessment lighter,
   because you can review an independent audit instead of running a full questionnaire.
   KSA flags surface ECC 4-1-3-2 / 4-2-3 must-haves so none is forgotten."""
import csv, sys

DATA = {"بيانات بطاقات": 3, "كل البيانات": 3, "بيانات مالية": 3, "السجلات الأمنية": 3,
        "مراسلات داخلية": 2, "وصول للأجهزة": 2, "لا بيانات حساسة": 0}
CRIT = {"high": 2, "medium": 1, "low": 0}

def tier(r):
    s = DATA.get(r["data_access"], 1) + CRIT.get(r["system_criticality"], 1)
    s += 1 if r["remote_access"] == "yes" else 0
    s += 1 if int(r.get("subprocessors") or 0) >= 3 else 0
    return "عالي High" if s >= 5 else "متوسط Medium" if s >= 3 else "منخفض Low", s

def assessment(r, t):
    certified = bool(r["certifications"].strip())
    if t.startswith("عالي"):
        return "مراجعة شهادة مستقلة + بنود كاملة + مراجعة سنوية" if certified else "تقييم كامل + بنود كاملة + مراجعة سنوية"
    if t.startswith("متوسط"):
        return "تأكيد الشهادة + بنود أساسية" if certified else "استبيان مختصر + بنود أساسية"
    return "جرد فقط + مراجعة عند التجديد"

rows = list(csv.DictReader(open(sys.argv[1], encoding="utf-8")))
print(f"{'vendor':24} {'tier':13} {'cert?':6} assessment")
for r in sorted(rows, key=lambda r: tier(r)[1], reverse=True):
    t, _ = tier(r)
    print(f"  {r['vendor'][:22]:22} {t:13} {'نعم' if r['certifications'].strip() else 'لا':6} {assessment(r, t)}")

print("\nKSA-specific flags:")
for r in rows:
    f = []
    if r["remote_access"] == "yes" and r["service"] == "SOC مدار":
        f.append("ECC 4-1-3-2: مركز المراقبة بالوصول عن بعد يجب أن يكون داخل المملكة بالكامل")
    if r["hosts_in_ksa"] == "no" and DATA.get(r["data_access"], 0) >= 2:
        f.append("ECC 4-2-3 / PDPL: يستضيف بيانات مهمة خارج المملكة، راجع ضوابط نقل البيانات")
    if r["remote_access"] == "yes" and not r["certifications"].strip():
        f.append("وصول عن بعد بلا شهادة مستقلة: شدد التقييم وبنود العقد")
    if f:
        print(f"  {r['vendor']}:")
        for x in f: print(f"     - {x}")

high = [r for r in rows if tier(r)[0].startswith("عالي")]
print(f"\nvendors: {len(rows)}; high tier: {len(high)}; no certification at all: "
      f"{sum(1 for r in rows if not r['certifications'].strip())}; remote access: {sum(1 for r in rows if r['remote_access']=='yes')}")

docker run --rm -v "$(pwd -W):/w" -w /w python:3.13.17-slim python score.py vendors.csv

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

vendor                   tier          cert?  assessment
  مزود الاستضافة السحابي عالي High     نعم    مراجعة شهادة مستقلة + بنود كاملة + مراجعة سنوية
  مزود المراقبة المدار   عالي High     نعم    مراجعة شهادة مستقلة + بنود كاملة + مراجعة سنوية
  مزود الدفع             عالي High     نعم    مراجعة شهادة مستقلة + بنود كاملة + مراجعة سنوية
  مزود البريد            متوسط Medium  نعم    تأكيد الشهادة + بنود أساسية
  شركة الدعم الفني       متوسط Medium  لا     استبيان مختصر + بنود أساسية
  مزود المحاسبة السحابي  متوسط Medium  نعم    تأكيد الشهادة + بنود أساسية
  مزود التصميم           منخفض Low     لا     جرد فقط + مراجعة عند التجديد

KSA-specific flags:
  مزود المراقبة المدار:
     - ECC 4-1-3-2: مركز المراقبة بالوصول عن بعد يجب أن يكون داخل المملكة بالكامل
  مزود البريد:
     - ECC 4-2-3 / PDPL: يستضيف بيانات مهمة خارج المملكة، راجع ضوابط نقل البيانات
  شركة الدعم الفني:
     - ECC 4-2-3 / PDPL: يستضيف بيانات مهمة خارج المملكة، راجع ضوابط نقل البيانات
     - وصول عن بعد بلا شهادة مستقلة: شدد التقييم وبنود العقد

vendors: 7; high tier: 3; no certification at all: 2; remote access: 3

في المخرج أعلاه لاحظ التالي:

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

التنبيهات الخاصة بالمملكة

أهم ما يفعله السكربت ليس التصنيف، وإنما أنه يرفع تلقائياً ضوابط يسهل نسيانها، والصورة التالية تبينها:

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

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

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

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

ماذا تسأل المورد قبل التعاقد؟

بعد أن عرفت طبقة كل مورد، يأتي سؤال ماذا تسأله، والصورة التالية تجمع مجالات الاستبيان الأمني للمورد:

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

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

الأدلة: لماذا تقرير التدقيق أثمن من الإجابة؟

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

وهنا فخ شائع: الشهادة بنطاق لا يخصك. فمورد قد يحمل شهادة ISO 27001 لمركز بياناته في بلد، والخدمة التي تشتريها تعمل من مركز آخر غير معتمد، أو الشهادة تغطي إدارة الأمن ولا تغطي التطبيق الذي يصلك. فلا تكتف بوجود الشهادة، واقرأ بيان النطاق Statement of Applicability وتاريخ الإصدار، فالشهادة دون نطاق يخصك ورقة لا تحميك.

ما تشترط في العقد

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

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

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

متى تقبل المخاطرة، ومن يقبلها؟

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

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

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

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

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

الطرف الرابع وسلسلة التوريد

مخاطرك لا تنتهي عند موردك المباشر، فموردك يعتمد بدوره على موردين، وهؤلاء على غيرهم، والصورة التالية تبين السلسلة:

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

والوجه الآخر من السلسلة هو سلسلة البرمجيات Software Supply Chain: المكتبات مفتوحة المصدر التي يبنى عليها منتج موردك، ومنتجك أنت. فثغرة في مكتبة يعتمد عليها الجميع، أو باب خلفي يزرعه مهاجم في مكتبة واسعة الانتشار، يصل إلى كل من يستخدمها. ويضع دليل NIST SP 800-161 لإدارة مخاطر سلسلة التوريد السيبرانية ممارسات لهذا، وأبسطها لك: اعرف ما يبنى عليه منتجك ومنتج موردك، وتابع نشرات الثغرات في هذه المكونات، كما شرحنا في مقال ترتيب أولوية الثغرات. فجزء من إدارة مخاطر الموردين أن تعرف ليس فقط من مورديك، وإنما مما صنعت منتجاتهم.

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

المتابعة المستمرة: المورد اليوم غير مورد الغد

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

وفي المؤسسات الكبيرة ظهرت أدوات مراقبة مخاطر الموردين المستمرة Continuous Monitoring التي تتابع سمعة الموردين وتسريباتهم آلياً، ولكن الشركة الصغيرة لا تحتاجها للبدء، فمتابعة بسيطة لإعلانات أهم عشرة موردين، واشتراك في تنبيهات منتجاتهم، يكفيان لتلتقط أهم الإشارات دون تكلفة. والمبدأ أهم من الأداة: المورد كائن حي يتغير، ومن يراقبه بين المراجعات يعرف بالمشكلة قبل أن تصل إليه عبره.

أخطاء شائعة

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

قائمة تحقق لكل مورد

الخلاصة

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

وأقرب المقالات إلى هذا الموضوع في المسار:

دليلسجل المخاطر Risk Register مع SimpleRisk على سيرفركنبني سجل مخاطر حقيقياً بنموذج الهيئة ثم بأداة SimpleRisk، ونرى لماذا أعطت الأداة كل المخاطر مستوى واحداً، وكيف تكتب منهجية تعطي الأرقام معناها.دليلضوابط الهيئة الوطنية للأمن السيبراني: أيها ينطبق عليك؟أي ضوابط الهيئة الوطنية للأمن السيبراني تنطبق على جهتك، وما الذي تضيفه كل مجموعة متخصصة فوق الضوابط الأساسية.دليلحماية البيانات الشخصية PDPL للخدمات التي تستضيفهاما يعنيه نظام حماية البيانات الشخصية لمن يشغل خدمة على سيرفراته، من العقد مع العميل والإشعار بالتسرب إلى النسخ والسجلات والنقل للخارج.دليلاستمرارية الأعمال BCP والتعافي من الكوارث DRP: الخطة والاختبارحولنا جرد عمليات شركة إلى طبقات تعاف بسكربت صغير، فكشف خدمة ظنها الفريق ثانوية وهي حرجة، وشرحنا MTD وRTO وRPO والموقع البديل.دليلخطة الاستجابة للحوادث Incident Response وكتيبات التشغيل Playbooksخطة استجابة وكتيبا حساب مخترق وفدية على NIST SP 800-61r3، مع مختبر نستعيد فيه البيانات من نسخة restic.دليلالضوابط الأساسية للأمن السيبراني NCA ECC بلغة بسيطةكيف تقرأ الضوابط الأساسية ECC دون أن تضيع في أرقامها، وعلى من تنطبق، وما المطلوب من جهتك فعلاً في كل مكون.

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

• أكتوبر 2026: كتابة المقال، وتصنيف موردين بسكربت على Python 3.13.17، بالاستناد إلى ضوابط ECC-2:2024 (المجال الرابع) وNIST SP 800-161.