كيفية تقييم مزودي خدمات إدارة المشتريات الرقمية (DSPM): إطار عمل الاختيار الخاص بالمشتري المؤسسي

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

يقدم هذا الدليل إطارًا منظمًا ومحايدًا تجاه الموردين لتقييم منصات إدارة المخاطر الأمنية للبيانات (DSPM). وقد تم بناؤه استنادًا إلى أبعاد التقييم التي تستخدمها شركات التحليل مثل «فورستر» و«غارتنر» في Magic Quadrant «Wave» Magic Quadrant — وهي: الاكتشاف، والتصنيف، وتحليل المخاطر، ومعالجة المخاطر، وعمق التكامل، والنضج التشغيلي — ولكنه يحول هذه الأبعاد إلى منهجية عملية لتحديد الدرجات يمكن لفريقك تطبيقها أثناء عملية اختيار المرشحين النهائيين واختبار إثبات المفهوم. كما تؤكد إرشادات Cloud Security Alliance الخاصة بـ DSPM على أن التقييم الفعال يجب أن يتجاوز قوائم مراجعة الميزات ليقيّم أداء الحل في ضوء بيئة البيانات الفعلية الخاصة بك، وأنماط الوصول، والتزامات الامتثال.

سواء كنت مسؤول أمن المعلومات (CISO) تعمل على إعداد دراسة الجدوى، أو مسؤول حماية البيانات (DPO) تعمل على تحديد متطلبات الأدلة التنظيمية، أو مهندس أمن السحابة تقوم باختبار التحمل لتغطية واجهات برمجة التطبيقات (API)، أو مدير المشتريات تعمل على حساب التكلفة الإجمالية للملكية، فإن الإطار التالي يوفر لكل طرف معني مسارًا واضحًا ضمن عملية تقييم واحدة وموحدة.

اختبار الواقع لإثبات صحة الفكرة

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

مشكلة M365

إليكم سيناريو يتكرر في كل عملية تقييم لنظام إدارة حماية البيانات (DSPM) تقريبًا: يقوم العرض التوضيحي الذي يقدمه المورد بمسح موقع SharePoint تجريبي يحتوي على بضع مئات من المستندات وأذونات بسيطة. تبدو دقة التصنيف ممتازة — دقة تزيد عن 95% في الكشف عن المعلومات الشخصية (PII)، وتقييم مخاطر دقيق، وعدد ضئيل من النتائج الإيجابية الخاطئة. ثم تقوم بربط النظام ببيئة Microsoft 365 الفعلية الخاصة بك.

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

ما الذي يجب اختباره في نموذج إثبات المفهوم الفعلي

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

قم بمقارنة التصنيف مع المعايير المرجعية. قبل إجراء اختبار إثبات المفهوم (POC)، قم بتصنيف عينة تتراوح بين 200 و500 وثيقة يدويًّا عبر مستويات الحساسية المختلفة. بعد انتهاء عمليات المسح التي يقوم بها نظام DSPM، قارن تصنيفاته مع المعايير المرجعية الخاصة بك. احسب الدقة (ما هي النسبة المئوية للعناصر التي تم وضع علامة عليها والتي تعتبر حساسة بالفعل) ومعدل الاسترجاع (ما هي النسبة المئوية للعناصر الحساسة بالفعل التي تم العثور عليها). الموردون الذين لا يستطيعون تحقيق دقة تزيد عن 85% ومعدل استرجاع يزيد عن 80% على بياناتك الحقيقية في اختبار إثبات المفهوم (POC) المُحسّن سيحققون أداءً أسوأ في بيئة الإنتاج.

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

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

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

قم بإجراء الاختبار على نطاق بياناتك الفعلي. إذا كانت مؤسستك تمتلك 50 تيرابايت من البيانات موزعة بين M365 و AWS S3، فإن تجربة إثبات المفهوم (POC) التي تقوم بمسح 500 جيجابايت لا تثبت شيئًا بشأن الأداء أو مدة المسح أو كفاءة المسح التراكمي. احرص على أن يمثل نطاق تجربة إثبات المفهوم (POC) ما لا يقل عن 20% من حجم بياناتك الإنتاجية.

أسئلة يجب طرحها على الموردين

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

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

بشأن تحديد الأذونات: «عندما يصادف الماسح الضوئي الخاص بك ملفًا في SharePoint يكون الوصول الفعلي إليه مستمدًّا من مجموعة أمان متداخلة في Azure AD تتضمن مستخدمي ضيوف B2B، كيف يتم تحديد الأذونات الفعلية؟ اشرح لي بالتفصيل استدعاءات واجهة برمجة التطبيقات (API) المحددة ومنطق وراثة الأذونات.» يهدف هذا الاختبار إلى التحقق مما إذا كان تخطيط الوصول الخاص بالمورد يراعي الهوية فعليًّا أم أنه يعتمد على بيانات الأذونات الاسمية دون معالجة مسألة تداخل المجموعات.

بشأن تخصيص التصنيف: «لدينا أنواع من البيانات الحساسة الخاصة بقطاعنا لا تشملها مصنفات PII/PHI/PCI القياسية. ما هي الإجراءات المتبعة لإنشاء مصنفات مخصصة؟ وكم عدد عينات التدريب المطلوبة، وما هي مدة دورة الضبط المعتادة، وما هي الدقة التي يمكننا توقعها للأنواع المخصصة مقارنةً بالأنواع المدمجة؟» وهذا ما يميز الموردين الذين يمتلكون محركات تصنيف قابلة للتدريب فعليًّا عن أولئك الذين يقدمون قواعد مخصصة تعتمد على التعبيرات النمطية (regex) ويتم تسويقها على أنها تعلم آلي.

بشأن شفافية نموذج تقييم المخاطر: «كيف يتم حساب درجة المخاطر لديكم؟ ما هي المتغيرات التي تدخل في حساب الدرجة، وكيف يتم تقييمها، وهل يمكننا تعديل أوزانها؟ إذا كان هناك ملفان يحتويان على معلومات تعريف شخصية متطابقة، لكن أحدهما متاح لـ 5 مستخدمين والآخر لـ 5,000 مستخدم، فكيف يميز نموذج تقييم المخاطر لديكم بينهما؟» إن نظام تقييم المخاطر غير الشفاف الذي لا يمكن تفسيره أو تعديله لن يصمد أمام تدقيق مسؤول أمن المعلومات (CISO) لديكم أو أسئلة المدققين.

بشأن آليات التكامل: «أرني الحمولة الفعلية للحدث التي ترسلها منصتك إلى نظام SIEM. ما هي الحقول المضمنة؟ هل هو حدث منظم بنمط CEF/LEEF، أم ويب هوك بتنسيق JSON، أم ملف سجل نظام (syslog)؟ هل يمكننا تصفية الأحداث التي يتم إعادة توجيهها؟» إن الفرق بين تكامل نظام SIEM الذي يثري مركز العمليات الأمنية (SOC) الخاص بك، وتلك التي تغمره بأحداث غير قابلة للاستخدام، يتلخص في بنية الحمولة ودقة التصفية.

بشأن حدود الإجراءات التصحيحية: «ما هي الإجراءات التصحيحية التي يمكن لمنصتكم تنفيذها بشكل أصلي — ليس التوصية بها، بل تنفيذها فعليًّا؟ وبالنسبة لـ M365 على وجه التحديد، هل يمكنكم إلغاء رابط المشاركة، وتعديل أذونات الموقع، وتطبيق تصنيف الحساسية، وعزل ملف ما؟» تقدم العديد من منصات إدارة الأمان (DSPM) الإجراءات التصحيحية كميزة، لكنها في الواقع تقدم توصية يقوم شخص ما بتنفيذها يدويًّا عبر وحدة تحكم منفصلة.

بشأن النفقات التشغيلية: «بعد النشر الأولي، كم عدد ساعات العمل الكاملة (FTE) أسبوعيًا التي يقضيها عميل نموذجي بحجم شركتنا في ضبط التصنيف، وفرز النتائج الإيجابية الخاطئة، وتعديل السياسات، وصيانة التكامل؟ هل يدخل دعم الضبط في التكلفة أم أنه يُقدم كخدمة احترافية بتكلفة إضافية؟» إن التكلفة الإجمالية لملكية نظام إدارة التهديدات الرقمية (DSPM) تتألف في الغالب من التكاليف التشغيلية، وليس من رسوم الترخيص.

مواءمة متطلبات أصحاب المصلحة

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

رئيس قسم أمن المعلومات (CISO): إعداد تقارير المخاطر والتواصل مع مجلس الإدارة

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

DPO: أدلة الامتثال والاستعداد للتدقيق

يحتاج مسؤول حماية البيانات (DPO) إلى أن يعمل نظام إدارة سياسات البيانات (DSPM) كمحرك لإثبات الامتثال. قم بتقييم أطر السياسات المدمجة الخاصة باللائحة العامة لحماية البيانات (GDPR) وقانون خصوصية المستهلك في كاليفورنيا (CCPA) وقانون نقل التأمين الصحي والمسؤولية (HIPAA) ومعيار أمن بيانات صناعة بطاقات الدفع (PCI DSS)، وأي لوائح خاصة بالقطاع تخضع لها مؤسستك. اختبر ما إذا كانت المنصة قادرة على إنشاء تقارير جاهزة للتدقيق تربط نتائج البيانات بمتطلبات تنظيمية محددة — ليس مجرد لوحة معلومات للامتثال، بل أدلة قابلة للتصدير يمكن للمراجع تتبعها بدءًا من النتيجة مرورًا بالضوابط وصولًا إلى الإجراءات التصحيحية. سيحتاج مسؤول حماية البيانات أيضًا إلى دعم طلبات الوصول الخاصة بأصحاب البيانات: هل يمكن لمنصة إدارة حماية البيانات (DSPM) تحديد جميع حالات بيانات فرد معين عبر جميع المستودعات التي تم فحصها؟

مهندس أمن السحابة: تغطية واجهات برمجة التطبيقات (API) والأتمتة

يقوم مهندس أمن السحابة بتقييم مدى توافق نظام إدارة أمن البيانات (DSPM) مع البنية التحتية الحالية القائمة على «البنية التحتية كرمز» (Infrastructure-as-Code) وسير عمل أتمتة الأمن. ويحتاج المهندس إلى تغطية شاملة لواجهات برمجة التطبيقات (API) — ليس مجرد واجهة برمجة تطبيقات REST لاستخراج النتائج، بل القدرة على تشغيل عمليات الفحص، وتحديث السياسات، وتنفيذ الإجراءات التصحيحية برمجياً. قم بتقييم دعم webhook، وتوافر مزودي Terraform أو Pulumi، وتكامل مسار CI/CD. يهتم المهندس أيضًا بأداء الفحص: كم من الوقت يستغرق الفحص التراكمي، وما هو الحد الأقصى لمعدل استدعاء واجهة برمجة التطبيقات (API)، وهل تتوسع بنية الفحص أفقيًّا مع نمو أحجام البيانات؟

المشتريات: التكلفة الإجمالية للملكية

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

الأخطاء الشائعة التي يرتكبها المشترون

الشراء بناءً على نطاق الاكتشاف وحده

أكثر أخطاء التقييم شيوعًا هو تصنيف الموردين بناءً على عدد مخازن البيانات التي يمكنهم فحصها في المقام الأول. يُعد نطاق الاكتشاف أمرًا أساسيًا — فمعظم مزودي حلول إدارة المخاطر الأمنية للبيانات (DSPM) للشركات يغطون كبار مزودي خدمات البنية التحتية كخدمة (IaaS) و M365 و Google Workspace ومنصات قواعد البيانات الشائعة. أما ما يميز المزودين عن بعضهم البعض فهو عمق التصنيف، ووضع المخاطر في سياقها الصحيح، والقدرة على معالجة المشكلات. إن التقييم الذي يمنح وزنًا بنسبة 40% أو أكثر لعنصر الاكتشاف سيؤدي إلى اختيار المزود الذي يمتلك أطول قائمة بالموصلات، وهو ما لا يعني بالضرورة أنه المزود الذي يحقق أفضل النتائج الأمنية.

تخطي مرحلة POC باستخدام البيانات الفعلية

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

تجاهل التكاليف التشغيلية العامة

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

التعامل مع DSPM كبرنامج مستقل

لا تعمل إدارة سياسات الأمان (DSPM) بمعزل عن غيرها. فقيمتها تتضاعف أو تتضاءل حسب مدى تكاملها مع بنية الأمان الأوسع نطاقًا لديك. وتؤكد «تحالف أمن السحابة» (Cloud Security Alliance) على أن التنفيذ الفعال لـ DSPM يستفيد من وجود منصة SSE توفر قدرات داعمة مثل CSPM و SSPM و UEBA ومراقبة الأنشطة في الوقت الفعلي. قم بتقييم كل مورد لـ DSPM في سياق البنية الحالية لديك: هل يكمل نظام DLP لديك أم يكرر وظائفه؟ هل يمكنه تزويد CASB بالنتائج من أجل التنفيذ؟ هل يثري نظام SIEM الخاص بك ببيانات سياقية أم يكتفي بزيادة حجم التنبيهات؟

التقليل من أهمية حوكمة بيانات الذكاء الاصطناعي

مع قيام المؤسسات بنشر أدوات الذكاء الاصطناعي التوليدي، و«المساعدين الرقميين»، ومسارات RAG، تتوسع متطلبات حوكمة البيانات لتتجاوز فئات الامتثال التقليدية. وقد يفوت نظام إدارة حوكمة البيانات (DSPM) الذي يقتصر على تصنيف البيانات وفقًا لتصنيفات المعلومات الشخصية (PII) والمعلومات الصحية المحمية (PHI) ومعايير PCI، المتطلبات الناشئة المتعلقة بتحديد وحوكمة البيانات المتدفقة إلى مجموعات تدريب الذكاء الاصطناعي، ومسارات الضبط الدقيق، ومخازن التوليد المعززة بالاسترجاع. قم بتقييم ما إذا كان نظام إدارة أمن البيانات (DSPM) قادرًا على اكتشاف تعرض البيانات الحساسة لخدمات الذكاء الاصطناعي، وما إذا كانت تصنيفاته قابلة للتوسع بما يكفي لتغطية متطلبات الحوكمة الخاصة بالذكاء الاصطناعي.

تنظيم عملية التقييم

تساعد عملية التقييم المنضبطة على منع توسع نطاق المشروع والتوجيه الخاطئ الذي يفرضه الموردون.

الأسبوعان 1 و2: تحديد المتطلبات. قم بتشكيل لجنة التقييم الخاصة بك (رئيس أمن المعلومات أو من ينوب عنه، ومسؤول حماية البيانات، ومهندس أمن السحابة، وقسم المشتريات). حدد القدرات «الضرورية» مقابل «المرغوبة». قم بتخصيص جدول التقييم المرجح وفقًا لأولويات مؤسستك. قم بإعداد بيئة إثبات المفهوم (POC) ومجموعة بيانات الواقع الميداني.

الأسابيع 3–4: طلبات تقديم العروض (RFP) والفرز الأولي. قم بإصدار طلبات تقديم العروض الموجهة باستخدام الأسئلة الخاصة بالموردين الواردة في هذا الدليل. قم بتقييم الردود المكتوبة وفقًا لمعاييرك المرجحة. قم بتضييق الاختيار إلى ثلاثة أو أربعة موردين لتقديم العروض التوضيحية.

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

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

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