رفتن به محتوا
پشتیبانی و تیکتینگ

پیش‌نویس اصلاحات PDPL عربستان: ذخیره داخلی، اطلاع نقض ۷۲ ساعته و اثر آن بر میز خدمت

پیش‌نویس اصلاحات PDPL سدایا که تا ۵ نوامبر ۲۰۲۶ به نظرسنجی گذاشته شده، ذخیره در داخل عربستان را قاعده می‌کند و اطلاع نقض ۷۲ ساعته را بدون آزمون آسیب می‌خواهد. اثرش بر تیکت‌ها و صندوق‌های ایمیل.

H
Hamze Zare Nasiri
۱۹ مهر ۱۴۰۵
پیش‌نویس اصلاحات PDPL عربستان: ذخیره داخلی، اطلاع نقض ۷۲ ساعته و اثر آن بر میز خدمت

نهاد ناظر داده عربستان می‌خواهد قواعد را دوباره تغییر دهد. سدایا (SDAIA) پیش‌نویس اصلاحات آیین‌نامه اجرایی قانون حفاظت از داده‌های شخصی (PDPL) را در سکوی نظرسنجی عمومی استطلاع گذاشته است و روزنامه رسمی ام‌القری می‌گوید مهلت ثبت نظر ۱۴ آبان ۱۴۰۵ (۵ نوامبر ۲۰۲۶) تمام می‌شود. خبر روزنامه رسمی فقط هدف را در یک جمله گفته است: روشن‌تر کردن رویه‌ها تا اشخاص و شرکت‌های مشمول قانون بتوانند واقعاً آن را رعایت کنند.

جزئیات در یادداشت ۸ اکتبر مؤسسه حقوقی Clyde & Co آمده که پیش‌نویس را ماده به ماده مرور می‌کند. سه تغییر مستقیم به سراغ سیستم‌هایی می‌رود که در یک شرکت معمولی بیشترین داده شخصی را دارند و کمترین توجه را می‌گیرند: میز خدمت (help desk) و سرور ایمیل.

پیش‌نویس چه چیزی را عوض می‌کند

همه این‌ها پیش‌نویس است و ممکن است بعد از نظرسنجی تغییر کند. به گفته Clyde & Co اگر تصویب شود، ۶۰ روز پس از انتشار در روزنامه رسمی اجرایی می‌شود. نکته‌هایی که برای تیم‌های IT و پشتیبانی مهم است، طبق همان یادداشت:

موضوعقاعده پیش‌نویس
ذخیره‌سازی (ماده ۲۳)کنترل‌کننده داده‌های شخصی را داخل عربستان نگه می‌دارد. انتقال و افشا به خارج طبق قواعد فعلی انتقال در PDPL همچنان ممکن است.
اطلاع نقض به سدایا (ماده ۲۴)ظرف ۷۲ ساعت از آگاهی از نقض، آسیب یا دسترسی غیرمجاز، چه احتمال آسیب باشد چه نباشد. اطلاع به خود افراد همچنان به ارزیابی آسیب بستگی دارد.
درخواست‌های سدایا (ماده ۳۶ مکرر)پاسخ ظرف ۲۰ روز کاری از دریافت. سدایا در صورت توجیه می‌تواند مهلت را تمدید کند.
درخواست صاحبان داده (ماده ۳)پاسخ ندادن در مهلت ۳۰ روزه یعنی درخواست رد شده تلقی می‌شود و فرد می‌تواند به سدایا شکایت کند.
ثبت ملی کنترل‌کنندگان (ماده ۳۴)ثبت برای نهادهای عمومی، کسانی که فعالیت اصلی‌شان پردازش داده شخصی است، پردازش‌کنندگان داده حساس و هر کسی که داده را به خارج می‌فرستد اجباری می‌شود.
بازاریابی (مواد ۲۸ و ۲۹)مدرک رضایت را نگه دارید، راه روشن برای پس گرفتن رضایت بدهید و پس از انصراف، پردازش را متوقف و داده را بدون تأخیر ناموجه نابود کنید.

ذخیره داخلی: نسخه اصلی تیکت‌های شما کجاست؟

ماده فعلی انتقال را در مطلب قبلی‌مان درباره محل نگهداری داده میز خدمت در قوانین امارات و عربستان بررسی کردیم. خلاصه‌اش این بود که میزبانی تیکت‌ها در خارج با کاغذبازی مجاز بود. پیش‌نویس پیش‌فرض را برعکس می‌کند. ذخیره در داخل عربستان قاعده می‌شود و سازوکارهای انتقال استثنایی که باید توجیهش کنید.

برای یک میز خدمت SaaS که در فرانکفورت یا ویرجینیا میزبانی می‌شود، سؤال ساده‌ای پیش می‌آید که فروشنده باید در یک ایمیل جوابش را بدهد: آیا منطقه سعودی دارید و آیا فایل‌های پیوست هم آنجاست، یا فقط پایگاه داده؟ اسکن کارت ملی و یادداشت پزشکی در پیوست‌ها می‌نشیند. همین سؤال درباره صندوق‌های ایمیل، نسخه‌های پشتیبان و نمایه جست‌وجویی که سیستم ایمیل یا تیکت کنار خودش می‌سازد هم صدق می‌کند.

ساعت ۷۲ ساعته بدون آزمون آسیب

امروز کنترل‌کننده اول تصمیم می‌گیرد که آیا نقض احتمالاً آسیبی دارد یا نه، بعد باید به سدایا خبر بدهد. پیش‌نویس این آزمون را برای اطلاع به ناظر حذف می‌کند. اگر کسی از یک کشور ناشناس وارد حساب یکی از کارشناسان پشتیبانی شود و یک بعدازظهر تیکت بخواند، مشمول است، چه چیزی بیرون برده باشد چه نه.

سختی ۷۲ ساعت معمولاً نوشتن اطلاعیه نیست. سختی این است که به‌موقع جواب بدهید «چه چیزهایی را دیدند؟». برای این کار سه چیز لازم است که بیشتر تیم‌ها روز حادثه می‌بینند ندارند:

  • گزارش دسترسی روی تیکت‌ها و صندوق‌ها که خواندن را هم ثبت کند، نه فقط ویرایش را، و بتوان آن را بر اساس حساب و بازه زمانی جست‌وجو کرد.
  • یک شخص مشخص که مسئول اطلاعیه باشد. پیش‌نویس نقش مسئول حفاظت داده (DPO) را هم گسترده‌تر می‌کند و اطلاع نقض را در فهرست وظایف او می‌گذارد.
  • تصمیمی از پیش گرفته‌شده درباره اینکه چه کسی کدام صف را ببیند. میز خدمتی که هر کارشناس همه تیکت‌ها را باز می‌کند، با یک رمز دزدیده‌شده کل آرشیو را لو می‌دهد.

مهلت‌هایی که صف پشتیبانی باید رعایت کند

دو مهلت تازه بیشتر مسئله صف است تا مسئله حقوقی. درخواست صاحب داده که ۳۰ روز بی‌پاسخ بماند رد شده حساب می‌شود و درخواست سدایا ظرف ۲۰ روز کاری جواب می‌خواهد. اگر این درخواست‌ها با ایمیل به یک صندوق مشترک برسند، پشت شکایت‌های ارسال کالا گم می‌شوند. برایشان نوع درخواست جدا، مسئول و موعدی بر اساس روزهای کاری تقویم سعودی تعریف کنید تا تعطیلی جمعه و شنبه و تعطیلات رسمی خودکار حساب شود.

تغییرات بازاریابی هم همین سمت را نشان می‌دهد. «رابطه قبلی داریم» دیگر به‌تنهایی کافی نیست. باید رضایت را نشان بدهید و انصراف را با حذف داده اجرا کنید، یعنی فهرست خبرنامه و CRM باید درباره اینکه چه کسی «نه» گفته هم‌نظر باشند.

پیش از ۱۴ آبان چه کنیم

  1. پیش‌نویس را در استطلاع بخوانید و اگر بندی روش کار شما را می‌شکند نظر بدهید. این مرحله ارزان‌ترین زمان برای این کار است.
  2. همه سیستم‌هایی را که داده شخصی ساکنان عربستان را نگه می‌دارند فهرست کنید و بنویسید نسخه اصلی، پیوست‌ها و پشتیبان هر کدام فیزیکی کجاست.
  3. بررسی کنید سیستم تیکت و ایمیل خواندن را ثبت می‌کند یا نه، و یک بار فعالیت یک حساب را در یک روز مشخص بیرون بکشید.
  4. برای درخواست‌های صاحبان داده و ناظر یک نوع درخواست با موعد روز کاری بسازید.
  5. ببینید در یکی از گروه‌های مشمول ثبت هستید یا نه، به‌خصوص اگر داده‌ای از عربستان خارج می‌شود.

نظر خود ما: اگر ذخیره داخلی قاعده شود، ساده‌ترین میز خدمت برای دفاع، میز خدمتی است که روی سروری که خودتان انتخاب می‌کنید اجرا شود. FanDesk با Docker قابل میزبانی شخصی است و موعد SLA را بر اساس تقویم کاری واقعی حساب می‌کند که مهلت‌های روز کاری بالا را پوشش می‌دهد. این به‌تنهایی کسی را منطبق نمی‌کند؛ ثبت رویدادها، قواعد دسترسی و کار DPO همچنان با شماست. به همین دلیل بسیاری از تیم‌ها ایمیل را هم روی سرور خودشان نگه می‌دارند، همان‌طور که در چرا ایمیل خودمیزبان در ۲۰۲۶ هنوز منطقی است نوشتیم.

این مطلب مشاوره حقوقی نیست. برای وضعیت خودتان از وکیلی بپرسید که هر روز با PDPL کار می‌کند.

پرسش‌های متداول

آیا اصلاحات PDPL اجرایی شده است؟

خیر. طبق ام‌القری پیش‌نویس تا ۵ نوامبر ۲۰۲۶ در استطلاع به نظرسنجی گذاشته شده است. به گفته Clyde & Co در صورت تصویب ۶۰ روز پس از انتشار در روزنامه رسمی اجرا می‌شود.

آیا پیش‌نویس نگهداری داده شخصی سعودی در خارج را ممنوع می‌کند؟

ذخیره در داخل را قاعده می‌کند، ولی انتقال و افشا به خارج طبق PDPL و سازوکارهای فعلی انتقال همچنان ممکن است. انتظار داشته باشید باید دلیل هر نسخه خارجی را مستند کنید.

کدام نقض‌ها باید ظرف ۷۲ ساعت گزارش شوند؟

طبق پیش‌نویس، هر نقض، آسیب یا دسترسی غیرمجاز باید ظرف ۷۲ ساعت از آگاهی به سدایا گزارش شود، چه احتمال آسیب باشد چه نباشد. اطلاع به خود افراد همچنان به ارزیابی آسیب بستگی دارد.

این تغییرات چه اثری بر میز خدمت دارد؟

تیکت‌ها اغلب اسکن مدرک هویتی، شماره تلفن و یادداشت سلامت دارند، پس میز خدمت زیر هر سه تغییر اصلی قرار می‌گیرد: محل ذخیره داده، سرعت گزارش دسترسی غیرمجاز، و مهلت‌های ۳۰ روزه و ۲۰ روز کاری.

FanDesk را ببینید

میز خدمت قابل میزبانی شخصی با تقویم SLA روز کاری، تا تیکت‌ها و پیوست‌هایشان روی سروری بمانند که خودتان انتخاب می‌کنید.

مشاهده FanDesk

اشتراک‌گذاری این مقاله