يتضمن معيار SACS-210 مجموعة واضحة من المتطلبات المرتبطة مباشرة بأمن البريد الإلكتروني ضمن الضوابط TPC1.20 إلى TPC1.24.
تشمل هذه المتطلبات تطبيق SPF وDKIM وDMARC، وفحص البريد الوارد من الإنترنت ضد الرسائل المزعجة، وفحص مرفقات البريد قبل السماح بها، واستخدام نطاق بريد إلكتروني خاص بالمؤسسة، إضافة إلى الحظر التلقائي لوحدات الماكرو في ملفات Microsoft Office القادمة من مصادر خارجية.
يمكن لـMicrosoft 365 دعم تنفيذ عدة أجزاء من هذه المتطلبات، لكن العلاقة الصحيحة ليست:
ترخيص Microsoft → امتثال SACS-210
بل:
متطلب SACS-210 → طبقة التنفيذ → القدرة التقنية → الحدود → الأدلة
وهذا الفرق مهم؛ لأن بعض الضوابط تُنفذ في DNS، وبعضها داخل Exchange Online، وبعضها يمكن تعزيزه باستخدام Microsoft Defender for Office 365، بينما يعتمد حظر وحدات الماكرو أساساً على Microsoft Office أو سياسات الأجهزة الطرفية، وليس على بوابة البريد وحدها.
ما متطلبات أمن البريد الإلكتروني في SACS-210؟
يمكن تلخيص الضوابط الخمسة المرتبطة مباشرة بالبريد الإلكتروني كما يلي:
| ضابط SACS-210 | المتطلب | نقطة التنفيذ الأساسية |
|---|---|---|
| TPC1.20 | تطبيق SPF وDKIM وDMARC | DNS + منصة البريد |
| TPC1.21 | فحص جميع الرسائل الواردة من الإنترنت باستخدام Anti-Spam | بوابة البريد / خدمة البريد السحابية |
| TPC1.22 | فحص جميع مرفقات البريد باستخدام Signature Analysis قبل السماح بها | Anti-Malware / Email Security |
| TPC1.23 | استخدام نطاق بريد خاص وعدم استخدام نطاقات عامة مثل Gmail وHotmail | نطاق المؤسسة + منصة البريد + السياسات |
| TPC1.24 | الحظر التلقائي لـMicrosoft Office macros في الملفات القادمة من مصادر خارجية | Microsoft Office / Endpoint |
المعيار هنا محايد من ناحية المنصة.
فهو لا يشترط Microsoft 365 أو Exchange Online أو Defender for Office 365 بالاسم.
لذلك يجب النظر إلى تقنيات Microsoft على أنها وسائل محتملة لتنفيذ المتطلبات، وليست المتطلبات نفسها.

TPC1.20: تطبيق SPF وDKIM وDMARC
يتطلب TPC1.20 تطبيق تقنيات:
- Sender Policy Framework أو SPF.
- DomainKeys Identified Mail أو DKIM.
- Domain-based Message Authentication, Reporting and Conformance أو DMARC.
وفي البيئات السحابية الحديثة، لا تتم إدارة هذه العناصر الثلاثة بالضرورة في موقع تقني واحد.
في بيئة Microsoft 365 مثلاً يكون النموذج عادة:
SPF → DNS
DKIM → Microsoft 365 + DNS
DMARC → DNS
ويجب تقييم الثلاثة معاً، وليس الاكتفاء بواحد منها.
SPF: تحديد مصادر الإرسال المصرح بها
يستخدم SPF لتحديد الأنظمة والخدمات المسموح لها بإرسال البريد نيابة عن نطاق المؤسسة.
في بيئة Microsoft 365، يتم نشر سجل SPF كـTXT record لدى مزود DNS أو مسجل النطاق.
لكن الخطأ الشائع هو افتراض أن نسخ سجل Microsoft 365 الافتراضي يكفي دائماً.
يجب أولاً حصر جميع المصادر الفعلية التي ترسل البريد باستخدام نطاق المؤسسة، مثل:
- Microsoft 365.
- أنظمة CRM.
- منصات التسويق.
- أنظمة التذاكر.
- تطبيقات ERP.
- نماذج المواقع.
- خدمات transactional email.
- أي أنظمة خارجية مصرح لها بالإرسال.
إذا لم تتم إضافة مصدر مشروع إلى SPF فقد يفشل التحقق من رسائله.
وفي المقابل، إنشاء أكثر من SPF record مستقل للنطاق نفسه قد يؤدي إلى أخطاء في التحقق.
لذلك يجب أن تكون للمؤسسة سياسة SPF واحدة متماسكة لكل نطاق إرسال، ويتم تحديثها عند تغير الخدمات.
DKIM: توقيع البريد الصادر
يضيف DKIM توقيعاً تشفيرياً إلى الرسائل الصادرة، بحيث يستطيع النظام المستلم التحقق من ارتباط الرسالة بالنطاق الموقّع ومن أن محتوى الرسالة لم يتغير بطريقة تؤدي إلى إبطال التوقيع.
في Microsoft 365، يتطلب إعداد DKIM للنطاقات المخصصة عادة جزأين:
- إعداد داخل Microsoft 365.
- سجلات DNS من نوع CNAME.
ويجب مراجعة كل نطاق أو subdomain يستخدم فعلياً للإرسال.
تفعيل DKIM لنطاق واحد لا يثبت أن جميع النطاقات المستخدمة من المؤسسة أصبحت مغطاة.
DMARC: ربط المصادقة بالنطاق الظاهر للمستلم
يعتمد DMARC على نتائج SPF وDKIM، ويضيف مفهوم Domain Alignment للتحقق من العلاقة بين النطاق الذي اجتاز المصادقة والنطاق الظاهر للمستلم في عنوان From.
كما يسمح لصاحب النطاق بنشر سياسة للتعامل مع الرسائل التي تفشل في التحقق واستلام تقارير تساعد على اكتشاف مصادر الإرسال المشروعة وغير المصرح بها.
هناك نقطة مهمة في SACS-210:
TPC1.20 يطلب تطبيق DMARC، لكنه لا يحدد قيمة Policy بعينها مثل p=none أو p=quarantine أو p=reject.
لذلك لا ينبغي استخدام عبارة مثل:
«DMARC مضبوط على quarantine، إذن المتطلب ناجح تلقائياً.»
النهج الأكثر دقة هو:
- حصر جميع مصادر الإرسال المشروعة.
- ضبط SPF.
- تفعيل DKIM.
- نشر DMARC.
- مراجعة نتائج authentication وalignment.
- تطوير DMARC policy بصورة مدروسة بعد التأكد من تدفقات البريد المشروعة.
- الاحتفاظ بأدلة الإعداد الفعلي.
TPC1.21: فحص البريد الوارد من الإنترنت ضد الرسائل المزعجة
يتطلب TPC1.21 فحص جميع رسائل البريد الواردة من الإنترنت باستخدام حماية Anti-Spam.
في بيئات Exchange Online، توفر Exchange Online Protection (EOP) طبقة أساسية تشمل قدرات مكافحة الرسائل المزعجة والبرمجيات الضارة.
وهذا يعني أن:
Microsoft Defender for Office 365 ليس شرطاً تلقائياً لمجرد تنفيذ نص TPC1.21.
السؤال العملي الذي يجب الإجابة عنه هو:
هل كل البريد الوارد من الإنترنت يمر فعلياً عبر حماية Anti-Spam نشطة ومضبوطة بالنطاق الصحيح؟
في Microsoft 365 يجب مراجعة عناصر مثل:
- Inbound anti-spam policies.
- Preset أو Custom security policies.
- إجراءات التعامل مع Spam.
- إجراءات High Confidence Spam.
- Quarantine.
- Allowed / Blocked Senders and Domains.
- Mail connectors.
- أي مسار Mail Flow قد يؤدي إلى تجاوز الفحص المعتاد.
وهنا يمثل النطاق Scope جزءاً أساسياً من التحقق.
وجود سياسة ممتازة تطبق على مجموعة محدودة فقط لا يثبت أن جميع الرسائل الواردة المنطبقة على TPC1.21 يتم فحصها.
TPC1.22: فحص مرفقات البريد وSignature Analysis
ينص TPC1.22 على فحص جميع مرفقات البريد باستخدام Signature Analysis قبل السماح بالمرفقات.
وهذه الصياغة مهمة لأنها تساعد على الفصل بين:
الفحص الأساسي المطلوب
و:
طبقات الحماية المتقدمة الإضافية
الفحص الأساسي: Anti-Malware
تقوم حماية Anti-Malware في Microsoft 365 بفحص الرسائل ومرفقات البريد بحثاً عن البرمجيات الضارة.
وتستخدم آليات تشمل اكتشاف البرمجيات الضارة المعروفة من خلال Signature Matching، إضافة إلى أساليب تحليل أخرى للكشف عن الملفات المشبوهة أو غير المعروفة.
لذلك يكون الـMapping الأكثر دقة:
TPC1.22 → فحص Anti-Malware للمرفقات بما يتضمن Signature-Based Detection
وليس:
TPC1.22 → Safe Attachments فقط
الحماية الإضافية: Safe Attachments
توفر Safe Attachments في Microsoft Defender for Office 365 طبقة حماية إضافية.
بعد الفحص الأساسي، يمكن لهذه التقنية تحليل المرفقات داخل بيئة افتراضية وعزلها عن المستخدم أثناء مراقبة السلوك قبل اتخاذ قرار التسليم.
يشار إلى هذا الأسلوب عادة بمفاهيم مثل:
- Detonation.
- Sandboxing.
- Behavioral analysis.
وهذا يعزز الحماية ضد التهديدات غير المعروفة أو المتخفية.
لكن يجب الحفاظ على الفرق التالي:
| طبقة الحماية | الوظيفة |
| Anti-Malware | Signature-based وHeuristic malware inspection |
| Safe Attachments | طبقة إضافية تعتمد على التحليل داخل بيئة افتراضية / Detonation |
لذلك لا ينبغي القول:
«Safe Attachments هي نفسها Signature Analysis المطلوبة في TPC1.22.»
الأصح أن يتم أولاً توثيق الفحص الأساسي، ثم إضافة Safe Attachments كطبقة حماية متقدمة عندما تكون مرخصة ومفعلة.
TPC1.23: استخدام نطاق بريد إلكتروني خاص بالمؤسسة
يشترط TPC1.23 استخدام Private Email Domain، ويمنع استخدام النطاقات العامة مثل Gmail وHotmail للبريد المؤسسي.
هذا المتطلب أيضاً ليس مرتبطاً بمنتج Microsoft بعينه.
يمكن للمؤسسة استخدام مزود بريد مؤسسي آخر، بشرط أن تستخدم نطاقها الخاص وأن تطبق الضوابط الأخرى المنطبقة.
في Microsoft 365 يكون التنفيذ المعتاد عبر:
- إضافة نطاق المؤسسة والتحقق منه.
- ضبط سجلات DNS المطلوبة.
- إنشاء mailboxes مؤسسية على النطاق الخاص.
- استخدام البريد المؤسسي في الأعمال الرسمية.
- منع الاعتماد التشغيلي على الحسابات الشخصية أو العامة.
مثلاً:
name@company.sa
يمثل نموذجاً لنطاق خاص بالمؤسسة، بخلاف استخدام حساب عام مثل Gmail أو Hotmail للعمل المؤسسي.
ويجب ألا تقتصر الأدلة على امتلاك النطاق فقط، بل يجب أن توضح أيضاً أن البريد المؤسسي يُدار ويستخدم من خلاله فعلياً.
TPC1.24: حظر وحدات الماكرو القادمة من مصادر خارجية
يتم أحياناً ربط TPC1.24 بصورة غير دقيقة مع إعدادات بوابة البريد.
لكن TPC1.24 ليس في الأساس Anti-Spam أو Exchange Online control.
المتطلب هو أن يتم الحظر التلقائي لـMicrosoft Office macros داخل الملفات القادمة من مصادر خارجية، بما في ذلك:
- الملفات التي تم تنزيلها من الإنترنت.
- مرفقات البريد الإلكتروني.
تصل الرسالة عبر البريد، لكن تنفيذ الحظر يحدث أساساً عند تفاعل Microsoft Office أو الجهاز الطرفي مع الملف.
تستخدم إصدارات Office المدعومة معلومات عن مصدر الملف، مثل Mark of the Web (MOTW)، للتعامل مع الملفات القادمة من مناطق غير موثوقة.
ويجب على المؤسسات التي تحتاج Enforcement مُداراً أن تراجع آلية الإدارة المناسبة لبيئتها، مثل:
- Office security policies.
- Group Policy.
- Microsoft Intune عندما يكون السيناريو والإصدار مدعومين.
- Endpoint security controls.
- Trusted Locations.
- Trusted Publishers عند وجود استثناءات تجارية مبررة.
النموذج الصحيح هو:
البريد يستقبل الملف → Office/Endpoint يحدد أن مصدره خارجي → سياسة Office أو Endpoint تتحكم في تشغيل Macro
وليس:
Exchange Online Anti-Malware Policy تمنع Macro مباشرة
ولهذا السبب أيضاً فإن Screenshot لـSafe Attachments وحدها لا تثبت TPC1.24.
الدليل يجب أن يرتبط بالسلوك الفعلي في Office أو على الجهاز الذي يمنع تشغيل الماكرو.

أين يدعم Microsoft 365 متطلبات SACS-210 وأين تنتهي حدوده؟
يمكن تلخيص العلاقة التقنية بصورة أدق في الجدول التالي:
| SACS-210 | قدرة Microsoft | التقييم |
| TPC1.20 | Custom Domain + DKIM في Microsoft 365 + SPF وDMARC في DNS | دعم قوي، لكن DNS جزء مستقل من التنفيذ |
| TPC1.21 | Exchange Online Protection Anti-Spam | دعم قوي إذا كان Mail Flow والنطاق صحيحين |
| TPC1.22 | Microsoft 365 Anti-Malware | دعم أساسي قوي لـSignature/Heuristic scanning |
| TPC1.22 — Enhancement | Defender for Office 365 Safe Attachments | حماية إضافية وليست آلية Signature Analysis الأساسية |
| TPC1.23 | Exchange Online مع Corporate Custom Domain | خيار تنفيذ قوي، لكن المتطلب Platform-Neutral |
| TPC1.24 | Office macro protection + Endpoint/Management Policy | خارج بوابة البريد نفسها |
الخلاصة التقنية هنا:
Microsoft 365 Email Security ليست مفتاح تشغيل واحداً.
قد يحتاج التنفيذ إلى ضبط عدة طبقات:
DNS → Exchange Online → Defender → Office → Endpoint Management
هل تحتاج Microsoft Defender for Office 365؟
ليس لجميع متطلبات SACS-210 الخاصة بالبريد.
ويجب الحفاظ على هذا الفرق عند تصميم البيئة التقنية، خصوصاً لدى المنشآت الصغيرة والمتوسطة.
Exchange Online Protection
توفر EOP طبقة الحماية الأساسية للبريد في Exchange Online، بما يشمل قدرات مثل:
- Anti-Spam.
- Anti-Malware.
- Malware attachment scanning.
- Quarantine.
- Mail filtering.
وهذه القدرات مرتبطة مباشرة بـTPC1.21 وبالجزء الأساسي من فحص المرفقات في TPC1.22.
Defender for Office 365
يضيف Defender for Office 365 قدرات متقدمة فوق تلك الطبقة، مثل:
- Safe Attachments.
- Safe Links.
- قدرات إضافية لمكافحة التصيد.
- قدرات Threat Investigation تختلف حسب الخطة.
Safe Attachments مفيدة بصورة خاصة لأنها تضيف التحليل السلوكي وDetonation بعد طبقة الفحص الأساسية.
لكن لا ينبغي استخدام العبارة:
«Defender for Office 365 إلزامي لتنفيذ TPC1.21 وTPC1.22.»
فـSACS-210 يحدد متطلبات أمنية وتقنية، ولا يفرض منتج Defender بالاسم.
أين يدخل Microsoft 365 Business Premium؟
بالنسبة إلى كثير من المنشآت السعودية الصغيرة والمتوسطة التي تعتمد Microsoft 365، يمكن أن يوفر Microsoft 365 Business Premium مجموعة مناسبة من قدرات الهوية والأجهزة والبريد الإلكتروني.
يتضمن Business Premium قدرات ومنتجات من بينها:
- Exchange business email.
- Microsoft Entra ID P1.
- Microsoft Intune Plan 1.
- Microsoft Defender for Business.
- Microsoft Defender for Office 365 Plan 1.
وتضيف Defender for Office 365 Plan 1 قدرات مثل Safe Attachments وSafe Links.
إذا كان Business Premium مناسباً للاحتياجات التقنية الأوسع للمؤسسة، يمكن مراجعة Microsoft 365 Business Premium من متجر نهر الامتثال.
لكن:
الترخيص يوفر القدرات؛ الترخيص لا يثبت الامتثال لـSACS-210.
فشراء Business Premium لا يقوم تلقائياً بـ:
- نشر SPF.
- تفعيل DKIM لكل نطاق.
- إعداد DMARC.
- مراجعة Mail Flow.
- ضبط Anti-Spam scope.
- التحقق من Anti-Malware.
- فرض Macro Blocking على الأجهزة.
يجب تنفيذ هذه العناصر فعلياً وتوثيقها.
ما الأدلة التي يجب تجهيزها لمتطلبات أمن البريد؟
لا يمكن إثبات تطبيق SACS-210 باسم المنتج أو فاتورة الترخيص فقط.
يجب أن توضح الأدلة ما هو مضبوط فعلياً وما هو قيد التشغيل.
| المتطلب | السياسة / العملية | دليل الإعداد | دليل التشغيل |
| TPC1.20 | مسؤوليات إدارة Email Authentication وتغييرها | SPF وDKIM وDMARC | DNS records ونتائج Validation |
| TPC1.21 | متطلبات Anti-Spam | سياسة Inbound Anti-Spam ونطاقها | Quarantine / Detection records |
| TPC1.22 | متطلبات فحص المرفقات | Anti-Malware / Attachment scanning configuration | سجلات ملفات محظورة أو محجورة |
| TPC1.23 | سياسة استخدام البريد المؤسسي | Domain ownership + mail configuration | حسابات بريد المؤسسة واستخدامها |
| TPC1.24 | سياسة External Macro Blocking | GPO / Office / Intune / Endpoint Policy | Endpoint verification / relevant security events |
هناك قاعدة مهمة هنا:
السياسة ≠ الإعداد التقني ≠ دليل التشغيل
قد تثبت Screenshot وجود إعداد محدد، لكنها لا تثبت وحدها:
- أن الإعداد يغطي النطاق الصحيح.
- أنه فعال الآن.
- أن كل الأنظمة ذات العلاقة مشمولة.
- أن العملية معتمدة.
- أن النتائج التشغيلية تتم متابعتها.
- أن أي استثناءات تم التحكم بها.
لذلك يجب ربط كل دليل بالمتطلب الذي يثبته.
لإعداد ملف أدلة أوسع قبل التقييم، راجع دليل الجاهزية لتدقيق CCC.
ولمراجعة التنفيذ التقني لبقية المتطلبات، استخدم قائمة التنفيذ التقني لمعيار SACS-210.
أخطاء شائعة في ربط أمن البريد بـSACS-210
تجنب هذه الادعاءات:
- «لقد نشرنا SPF، إذن TPC1.20 مكتمل.»
TPC1.20 يتطلب SPF وDKIM وDMARC. - «Defender for Office 365 مطلوب لكل ضوابط البريد.»
ليس صحيحاً؛ توجد متطلبات تنفذ في DNS، وأخرى توفر EOP لها قدرات أساسية، بينما TPC1.24 يقع أساساً على Office/Endpoint. - «Safe Attachments هي Signature Analysis المطلوبة في TPC1.22.»
Safe Attachments طبقة Detonation إضافية؛ أما Signature-Based Detection فتدخل في طبقة Anti-Malware الأساسية. - «حظر Macro يتم من Exchange Anti-Malware Policy.»
TPC1.24 يعتمد بصورة رئيسية على Office/Endpoint enforcement. - «DMARC
p=quarantineيعني أن التدقيق ناجح تلقائياً.»
المعيار يطلب تطبيق DMARC ولا يحدد هذه القيمة كشرط نجاح مستقل. - «Screenshot واحدة تثبت الضابط بالكامل.»
قد تكون Screenshot جزءاً من الدليل، لكنها لا تثبت دائماً النطاق والسياسة والتشغيل. - «اشترينا Microsoft 365 Business Premium، إذن تم تطبيق متطلبات البريد.»
شراء الترخيص لا يساوي تنفيذ الإعدادات المطلوبة.
MFA للبريد متطلب منفصل ضمن التحكم في الوصول
لا تنتهي حماية البريد عند TPC1.20–TPC1.24.
يطلب TPC1.12 بصورة منفصلة MFA في عدة حالات، ومنها الوصول إلى بريد المؤسسة عبر الويب أو الأجهزة المحمولة.
وهذا متطلب متعلق بالهوية والتحكم في الوصول، وليس إعداداً في بوابة Anti-Spam.
لذلك لا نعيد شرح Conditional Access هنا.
راجع بدلاً من ذلك دليل Microsoft Entra ID وSACS-210 للمؤسسات السعودية لفهم:
- MFA.
- Conditional Access.
- SSO.
- حدود الترخيص.
- أدلة الوصول.
وبذلك تبقى ملكية المحتوى واضحة:
Email Security → TPC1.20–TPC1.24
Microsoft Entra / Access Control → MFA وIdentity controls
خطوات عملية لتطبيق أمن البريد في SACS-210
يمكن ترتيب التنفيذ على النحو التالي:
- حدد كل نطاقات البريد ومصادر الإرسال المستخدمة فعلياً.
- اضبط SPF وDKIM وDMARC وتحقق منها.
- تأكد أن جميع رسائل الإنترنت الواردة تمر عبر Anti-Spam فعّال.
- تحقق من فحص المرفقات وSignature-Based Anti-Malware.
- حدد ما إذا كانت طبقات إضافية مثل Safe Attachments مناسبة للبيئة.
- تأكد أن العمل المؤسسي يستخدم نطاق البريد الخاص المعتمد.
- تحقق من حظر Office macros القادمة من مصادر خارجية على الأجهزة.
- اربط كل ضابط بإعداداته وسجلاته وأدلته التشغيلية.
إذا كان فريق تقنية المعلومات لديك يحتاج قائمة أوسع تشمل بقية ضوابط SACS-210، استخدم قائمة التنفيذ التقني لمعيار SACS-210.
أما إذا كانت لديك بيئة Microsoft 365 وبريد وأجهزة قائمة وتحتاج إلى تقييم الفجوات ومعالجتها، فراجع خدمة تنفيذ متطلبات CCC / SACS-210 على البيئة القائمة.
وإذا كانت المؤسسة تبدأ تجهيز البيئة من الصفر، يمكن مراجعة باقة CCC المتكاملة.
تقدم نهر الامتثال خدمات التنفيذ والدعم السيبراني والتوثيق والاستعداد، بينما يبقى التقييم الرسمي المستقل وإصدار شهادة CCC لدى جهة تدقيق مخولة وفق العملية المنطبقة.
وعند الوصول إلى مرحلة التقييم المستقل، يمكن مراجعة قائمة شركات تدقيق CCC المعتمدة.
الخلاصة
لا يمكن اختزال أمن البريد الإلكتروني في SACS-210 في عبارة:
«فعّل Defender»
أو:
«انشر SPF»
فالضوابط الخمسة تعمل في طبقات مختلفة:
TPC1.20 → مصادقة البريد
TPC1.21 → Anti-Spam للبريد الوارد
TPC1.22 → فحص المرفقات
TPC1.23 → نطاق بريد مؤسسي خاص
TPC1.24 → حظر Office macros من المصادر الخارجية
وفي بيئات Microsoft 365 قد يمتد التنفيذ عبر:
Public DNS → Exchange Online Protection → Defender for Office 365 → Office / Endpoint
لذلك السؤال الصحيح ليس:
«هل Microsoft 365 يجعل بريدنا ممتثلاً لـSACS-210؟»
بل:
«ما متطلب SACS-210 الذي نطبقه؟ أين يتم فرضه تقنياً؟ ما حدود المنصة؟ وما الدليل الذي يثبت أنه يعمل فعلاً؟»
هذا النهج يؤدي إلى تصميم تقني أكثر دقة، ويجعل ملف الأدلة أكثر وضوحاً وقابلية للتحقق أثناء الاستعداد للتقييم.
المراجع الرسمية
معيار SACS-210
Microsoft Learn
Microsoft 365 for business security overview
Set up SPF to identify valid email sources for your Microsoft 365 domain
How to use DKIM for email in your custom domain
Set up DMARC to validate email in Microsoft 365
Safe Attachments in Microsoft Defender for Office 365
Recommended settings for EOP and Microsoft Defender for Office 365 security
هل تحتاج مساعدة في متطلبات شهادة CCC لأرامكو؟
احصل على استشارة مجانية مع أحد خبرائنا.
علي الجبيلي
خبير سعودي رائد في مجال الأمن السيبراني وتقنية المعلومات، يتمتع بخبرة تزيد عن 20 عامًا في بناء برامج أمنية متكاملة للشركات السعودية الصغيرة والمتوسطة. متخصص في معيار أرامكو للأمن السيبراني للأطراف الثالثة (CCC)، والامتثال لمعايير الهيئة الوطنية للأمن السيبراني (NCA) الخاصة بأمن المعلومات، وتطبيق ضوابط أمنية تقنية للمؤسسات العاملة في قطاعات الإنشاءات والطاقة والتجارة.