মূল কন্টেন্টে যান

শেয়ার্ড WiFi অপারেটরদের জন্য GDPR ডেটা ধারণ: আপনি কতক্ষণ গেস্ট লগইন ডেটা এবং নেটওয়ার্ক লগ রাখতে পারেন

শেয়ার্ড WiFi পরিচালনাকারী DPO, নেটওয়ার্ক আর্কিটেক্ট এবং ভেন্যু অপারেটরদের জন্য একটি ব্যবহারিক UK সম্মতি নির্দেশিকা। এটি GDPR স্টোরেজ-সীমাবদ্ধতার সিদ্ধান্তগুলিকে শর্তসাপেক্ষ IPA ধারণ-বিজ্ঞপ্তি ব্যবস্থা থেকে আলাদা করে, তারপর কন্ট্রোলার-প্রসেসর বিশ্লেষণকে একটি ধারণ সময়সূচী, Article 28 চেকলিস্ট এবং মুছে ফেলার ওয়ার্কফ্লোতে রূপান্তর করে।

প্রকাশিত হালনাগাদ করা হয়েছে
📖 12 মিনিট পাঠ2,906 শব্দ3 সমাধানকৃত উদাহরণ10 মূল সংজ্ঞা

এই গাইডটি শুনুন

পডকাস্ট ট্রান্সক্রিপ্ট দেখুন
shared WiFi অপারেটরদের জন্য GDPR ডেটা ধারণ নীতি স্বাগতম। এই ব্রিফিংটি তাদের জন্য তৈরি করা হয়েছে যাদের হোটেল, শপিং গন্তব্য, কো-ওয়ার্কিং এস্টেট, স্টেডিয়াম এবং পাবলিক ভেন্যুতে ডেটা ধারণের সিদ্ধান্তগুলি কার্যকর করতে হয়। এখানে মূল বিষয়টি লক্ষ্য করুন। UK GDPR গেস্ট WiFi অপারেটরদের লগইন ডেটা বা নেটওয়ার্ক লগের জন্য কোনও নির্দিষ্ট সংখ্যক দিন বেঁধে দেয় না। Article 5 স্টোরেজ সীমাবদ্ধতা অনুযায়ী আপনাকে চিহ্নিতকরণযোগ্য ডেটা কেবল আপনার নথিবদ্ধ উদ্দেশ্যের জন্য যতক্ষণ প্রয়োজন তার বেশি সময় না রাখার নির্দেশ দেয়। এর অর্থ হল প্রতিটি রেকর্ডের জন্য একটি মাত্র সাধারণ সেটিং সাধারণত ভুল ডিজাইন হিসেবে গণ্য হয়। এস্টেট মডেলটি দিয়ে শুরু করুন। একটি হোটেল যা নিজস্ব অ্যাক্সেস, পরিষেবা নিশ্চিতকরণ এবং সুরক্ষার উদ্দেশ্যে একটি গেস্ট নেটওয়ার্ক পরিচালনা করে, তারা সাধারণত সেই উদ্দেশ্যগুলির জন্য কন্ট্রোলার সিদ্ধান্ত গ্রহণ করবে। একটি কো-ওয়ার্কিং অপারেটর তার সদস্যদের নেটওয়ার্কের জন্য একই কাজ করতে পারে। কিন্তু যেখানে অপারেটর একটি ভাড়াটে ব্যবসার জন্য একটি স্টাফ SSID প্রদান করে, সেখানে ভাড়াটে সিদ্ধান্ত নিতে পারে কেন কর্মচারীর পরিচয় সংক্রান্ত ডেটা সংগ্রহ করা হচ্ছে, এটি কতক্ষণ সংরক্ষণ করা হবে এবং কর্মীদের অনুরোধগুলি কীভাবে পরিচালনা করা হবে। সেই প্রসেসিংয়ে, অপারেটর একজন প্রসেসর হতে পারে। একই ডেটা বিভিন্ন উদ্দেশ্যের জন্য বিভিন্ন ক্ষমতায় পরিচালনা করা যেতে পারে। লেবেল নিয়ে বিতর্ক করার আগে উদ্দেশ্যটি ম্যাপ করুন। এরপর, আপনার ডেটা আলাদা করুন। কানেকশন মেটাডেটার মধ্যে ডিভাইসে অ্যাসাইন করা ঠিকানা, একটি ডিভাইস আইডেন্টিফায়ার, সেশনের শুরু এবং শেষের সময়, DHCP লিজ, RADIUS অ্যাকাউন্টিং এবং ট্রাফিকের মোট পরিমাণ অন্তর্ভুক্ত থাকতে পারে। একটি নাম-লগইন নেটওয়ার্কে, সেই রেকর্ডগুলি সাধারণত ব্যক্তিগত ডেটা হবে কারণ আপনি সেগুলিকে একজন ব্যক্তির সাথে সংযুক্ত করতে পারেন। একটি নির্দিষ্ট নিরাপত্তা এবং ঘটনা-প্রতিক্রিয়া (incident-response) উদ্দেশ্যের জন্য, ৩০ থেকে ৯০ দিনের একটি অপারেশনাল সময়কাল একটি আনুপাতিক সূচনা পয়েন্ট হতে পারে। এটি কোনও আইনি নিরাপদ আশ্রয় (safe harbour) নয়। আপনার ঘটনাগুলি কত দ্রুত চিহ্নিত করা যায়, আপনি যে সিস্টেমগুলিতে কোয়েরি করতে পারেন, অনুপ্রবেশের ঝুঁকি এবং আপনি যে নিয়ন্ত্রণগুলি ব্যবহার করেন তার বিপরীতে এটি যাচাই করুন। অথেনটিকেশন ডেটার জন্য নিজস্ব নিয়মের প্রয়োজন। একটি ইমেল ঠিকানা, নাম, মোবাইল নম্বর এবং সোশ্যাল-লগইন আইডেন্টিফায়ার একটি ফায়ারওয়াল ইভেন্টের মতো একই টাইমার অনুসরণ করা উচিত নয়। যদি একমাত্র উদ্দেশ্য একটি গেস্ট নেটওয়ার্কে অ্যাক্সেস প্রদান করা হয়, তবে অ্যাক্সেস শেষ হওয়ার পরে এবং কোনও সংক্ষিপ্ত, নথিবদ্ধ বিরোধের সময়কাল পার হয়ে গেলে এটি মুছে ফেলুন বা অপরিবর্তনীয়ভাবে ডি-আইডেন্টিফাই করুন। আপনি যদি এটি মার্কেটিংয়ের জন্য ব্যবহার করেন, তবে আপনাকে মার্কেটিংয়ের আইনি ভিত্তি এবং ইলেকট্রনিক-মার্কেটিং নিয়মগুলিকে সম্মান করতে হবে। সম্মতি প্রত্যাহার করার সাথে সাথে মার্কেটিং ব্যবহার বন্ধ হয়ে যায়। সেই ব্যক্তি যাতে পুনরায় মার্কেটিং বার্তা না পান তা নিশ্চিত করার জন্য শুধুমাত্র ন্যূনতম সাপ্রেশন রেকর্ড সংরক্ষণ করুন। অবস্থান এবং উপস্থিতি (presence) ডেটার জন্য আরও সুশৃঙ্খল ডিজাইনের প্রয়োজন। সংগৃহীত তথ্য যা সত্যিকার অর্থে বেনামী করা হয়েছে যাতে লোকেদের চিহ্নিত করা না যায়, তা ব্যক্তিগত ডেটা নয়। কিন্তু একজন ব্যক্তির নাম একটি টোকেন দিয়ে প্রতিস্থাপন করা তথ্যটিকে বেনামী করে তোলে না যদি আপনি টোকেনটি পুনরায় লিঙ্ক করতে পারেন। সনাক্তকরণযোগ্য ট্রেইলের জন্য, একটি সংক্ষিপ্ত অপারেশনাল সময়সীমা নির্ধারণ করুন, তারপরে তা একত্রিত করুন বা মুছে ফেলুন। একটি ভেন্যুর জন্য ৩০ দিনের ট্রেস পিরিয়ড কার্যকর হতে পারে যা সেই সময়ের মধ্যে অপারেশনাল সমস্যাগুলি তদন্ত করে। এর কারণটি নথিবদ্ধ করুন। বিস্তারিত মুভমেন্ট ট্রেইল সংরক্ষণ করবেন না এই আশায় যে সেগুলি পরবর্তীতে কার্যকর হতে পারে।অপব্যবহার এবং সিকিউরিটি লগের জন্য, বৈধ স্বার্থ উপযুক্ত হতে পারে তবে এটি স্বয়ংক্রিয় নয়। ICO-এর তিন-অংশের পরীক্ষাটি জিজ্ঞাসা করে: সিকিউরিটি উদ্দেশ্যটি কি বৈধ, এই ডেটা সংরক্ষণ করা কি প্রয়োজনীয়, এবং ব্যক্তির স্বার্থ কি আপনার স্বার্থকে ওভাররাইড করে? যুক্তিসঙ্গত প্রত্যাশা, ফিল্ডগুলির সংবেদনশীলতা, অ্যাক্সেস নিয়ন্ত্রণ এবং দীর্ঘ সময় ধরে ডেটা সংরক্ষণের ফলে যে ক্ষতি হতে পারে তা নথিবদ্ধ করুন। আপনার শেয়ার্ড পাবলিক অ্যাড্রেসের কারণে যদি কোনও অপব্যবহারের অভিযোগের জন্য আপনার ঐতিহাসিক অ্যাট্রিবিউশনের প্রয়োজন হয়, তবে একটি নির্দিষ্ট পরিবেশে ৩৬৫ দিনের নিয়ম সমর্থনযোগ্য হতে পারে। এটি কোনও সর্বজনীন GDPR ফ্লোর নয়। এটিকে একটি নথিবদ্ধ নীতিগত সিদ্ধান্ত হিসেবে তৈরি করুন, এটি পর্যালোচনা করুন এবং সংরক্ষিত ফিল্ডগুলি যতটা সম্ভব কমিয়ে দিন। এখন আসি UK Investigatory Powers Act প্রসঙ্গে, যা প্রায়শই IPA নামে সংক্ষিপ্ত করা হয়। এখানেই অনেক শেয়ার্ড WiFi নির্দেশিকা ভুল পথে চলে যায়। টেলিকমিউনিকেশন অপারেটরের আইনি সংজ্ঞা বেশ বিস্তৃত। সরকারের বর্তমান কোড অনুসারে, এর মধ্যে এমন প্রদানকারীরা অন্তর্ভুক্ত হতে পারে যারা হোটেল, বিমানবন্দরের লাউঞ্জ এবং গণপরিবহনের মতো জায়গায় অতিথি বা জনসাধারণের সদস্যদের যোগাযোগ পরিষেবাগুলিতে অ্যাক্সেস প্রদান করে। এটি শেয়ার্ড WiFi অপারেটরদের জন্য প্রশ্নটিকে প্রাসঙ্গিক করে তোলে। এর মানে এই নয় যে প্রতিটি ভেন্যুর স্বয়ংক্রিয়ভাবে বারো মাসের একটি বাধ্যবাধকতা রয়েছে। অফিসিয়াল নোটিশ কোডের ডিফল্ট অবস্থান হলো, কোনও অপারেটরকে ডেটা রিটেনশন নোটিশ না পাওয়া পর্যন্ত এই আইনের অধীনে ডেটা সংরক্ষণ করতে হবে না। ধারা ৮৭-এর অধীনে, একটি নোটিশ অবশ্যই প্রয়োজনীয় এবং আনুপাতিক হতে পারে, এতে অবশ্যই অপারেটর, ডেটা এবং সংরক্ষণের সময়কাল চিহ্নিত করতে হবে এবং এটি বারো মাসের বেশি সময়ের জন্য সংরক্ষণের দাবি করতে পারে না। আপনি যদি কোনও নোটিশ না পেয়ে থাকেন, তবে এমন কোনও অভ্যন্তরীণ নীতি লিখবেন না যা বলে যে IPA-এর অধীনে আপনাকে প্রতিটি নেটওয়ার্ক রেকর্ড এক বছরের জন্য রাখতে হবে। আইনটি এমন কথা বলে না। আপনি যদি কোনও নোটিশ পান, তবে অবিলম্বে বিশেষজ্ঞ আইনি পরামর্শদাতার সাথে যোগাযোগ করুন। কেবল প্রাসঙ্গিক যোগাযোগের ডেটা এবং আসলে নির্দিষ্ট করা সময়কাল সংরক্ষণ করুন। এটি আপনার তফসিলে আলাদা রাখুন। সরকারি কোডটি এমন ডেটা চিহ্নিত করে যা যোগাযোগের 'কে, কখন, কোথায় এবং কীভাবে' তা চিহ্নিত করতে সহায়তা করতে পারে। উদাহরণের মধ্যে রয়েছে সোর্স এবং ডেস্টিনেশন অ্যাড্রেস, পোর্ট, ইন্টারনেট অ্যাক্সেস সেশনের সময়, অ্যাক্সেস-পয়েন্টের পরিচয় এবং অ্যাক্সেস-পয়েন্টের অবস্থান। IPA প্রতিটি কনটেন্ট লগকে সংরক্ষণের লক্ষ্যে পরিণত করে না। কনটেন্ট একটি সম্পূর্ণ আলাদা বিভাগ। GDPR-এর উদ্দেশ্যে, একটি প্রযোজ্য আইনি বাধ্যবাধকতা অনুচ্ছেদ ৬-এর আইনি-বাধ্যবাধকতার ভিত্তি প্রদান করতে পারে। তবে আপনার তফসিলে সঠিক সংবিধিবদ্ধ রেফারেন্স এবং নোটিশের পরিধি থাকা প্রয়োজন। আপনার গোপনীয়তার তথ্যে যেখানে উপযুক্ত সেখানে সীমিত সংরক্ষণের বিষয়টি ব্যাখ্যা করা উচিত এবং নোটিশের সাথে যুক্ত গোপনীয়তার বাধ্যবাধকতাগুলি পালন করা উচিত। আইনি ভিত্তিটি অতিরিক্ত ডেটা সংগ্রহ করা বা অপ্রাসঙ্গিক মার্কেটিংয়ের জন্য সংরক্ষিত রেকর্ডগুলি ব্যবহার করাকে সমর্থন করে না।যদি কোনো ব্যক্তি ডেটা মুছে ফেলার জন্য অনুরোধ করেন তবে কী হবে? অনুরোধটি গ্রহণ করুন, আনুপাতিকভাবে পরিচয় যাচাই করুন, ডেটা ক্যাটাগরি এবং উদ্দেশ্য অনুযায়ী রেকর্ডগুলি চিহ্নিত করুন এবং ঢালাও প্রতিক্রিয়া না দিয়ে প্রতিটি ক্যাটাগরি আলাদাভাবে সিদ্ধান্ত নিন। ICO-এর মতে সাধারণ প্রতিক্রিয়া জানাতে এক মাস সময় লাগে। যে ডেটা আর প্রয়োজনীয় নয় তা মুছে ফেলুন। সম্মতি প্রত্যাহার করা হলে বা ব্যক্তি আপত্তি জানালে মার্কেটিং ডেটা ব্যবহার বন্ধ করুন। যেখানে আইনি বাধ্যবাধকতা প্রযোজ্য, অথবা যেখানে আইনি দাবি প্রতিষ্ঠা, প্রয়োগ বা রক্ষা করার জন্য ডেটা প্রয়োজনীয়, সেখানে সীমিত ছাড়ের বিষয়টি ব্যাখ্যা করুন এবং শুধুমাত্র এর দ্বারা যুক্তিযুক্ত ডেটা সংরক্ষণ করুন। ব্যাকআপ নিয়েও ভাবা দরকার। লাইভ সিস্টেম থেকে মুছে ফেলুন, ব্যাকআপ ডেটা ব্যবহার করা প্রতিরোধ করুন এবং ওভাররাইট করার সময়সূচী স্পষ্ট করুন। এটিকে একটি সিস্টেমে রূপান্তর করুন, কোনো পলিসি PDF নয়। আপনার ডেটা সংরক্ষণের সময়সূচীতে ডেটা ক্যাটাগরি, উদ্দেশ্য, কন্ট্রোলার বা প্রসেসরের ভূমিকা, বৈধ ভিত্তি, ডিফল্ট সময়কাল, ডেটা মুছে ফেলার ঘটনা, লিগ্যাল-হোল্ড ওভাররাইড এবং মালিকের নাম থাকা উচিত। অটোমেটেড পার্জ জব কনফিগার করুন। একটি পৃথক লিগ্যাল-হোল্ড সংগ্রহ রাখুন। ডেটা মুছে ফেলার লগগুলি পরীক্ষা করুন। DPO-কে একটি ত্রৈমাসিক ব্যতিক্রম রিপোর্ট প্রদান করুন যা স্বাভাবিক সময়কালের পরেও ধরে রাখা আইটেমগুলি এবং তার কারণ প্রদর্শন করে। Purple কনফিগারেবল ধারণ সময়কাল, অটোমেটেড পার্জ শিডিউল এবং অ্যাক্সেস ও মুছে ফেলার অনুরোধের ওয়ার্কফ্লো সহ সেই অপারেটিং মডেলটিকে সমর্থন করতে পারে। টেন্যান্ট এস্টেটের জন্য, স্টাফ SSID অনবোর্ড করার আগে একটি উদ্দেশ্য এবং ভূমিকা ম্যাট্রিক্স ব্যবহার করুন। তারপর যেখানে আপনি কোনো টেন্যান্টের নির্দেশাবলী অনুযায়ী প্রসেসিং করছেন সেখানে অনুচ্ছেদ ২৮-এর শর্তাবলী কার্যকর করুন। চুক্তিতে নথিভুক্ত নির্দেশাবলী, নিরাপত্তা, গোপনীয় স্টাফ অ্যাক্সেস, সাব-প্রসেসর, অধিকারের ক্ষেত্রে সহায়তা, ডেটা লঙ্ঘন এবং DPIA সমর্থন, পরিষেবা শেষে ফেরত বা মুছে ফেলা এবং অডিট অধিকার অন্তর্ভুক্ত থাকা উচিত। দ্রুত প্রশ্নাবলীতে যাওয়ার আগে, চারটি সাধারণ ব্যর্থতা এড়িয়ে চলুন। প্রথমত, ব্যাকআপ সংরক্ষণের সময়কালকে লাইভ-ডেটা সময়কাল হিসেবে ব্যবহার করবেন না। ব্যাকআপ হলো একটি স্থিতিস্থাপকতা নিয়ন্ত্রণ, কোনো সক্রিয় প্রোফাইল রাখার কারণ নয়। দ্বিতীয়ত, প্রতিটি ভেন্ডর কনফিগারেশনে একটি ১২ মাসের সংখ্যা কপি করবেন না। IPA নোটিশ, যদি থেকে থাকে, তা বৈধ পরিধি নির্ধারণ করে। তৃতীয়ত, গেস্টের সম্মতি, টেন্যান্ট স্টাফ অথেন্টিকেশন এবং নিরাপত্তার প্রমাণ একটি অভিন্ন এক্সপোর্টে একত্রিত করবেন না। পৃথক উদ্দেশ্য নির্ধারণ করে যে আপনি কোনো সাবজেক্টের অনুরোধে কীভাবে প্রতিক্রিয়া জানাবেন, টেন্যান্টের সাথে কীভাবে চুক্তি করবেন এবং কে রেকর্ডগুলি অনুসন্ধান করতে পারবেন। চতুর্থত, সংরক্ষণের সময়সূচীকে ম্যানুয়াল টাস্ক বানাবেন না। যদি সিকিউরিটি লিডকে প্রতিটি ত্রৈমাসিকের শেষে একটি ফোল্ডার মুছে ফেলার কথা মনে রাখতে হয়, তবে এটি কোনো কার্যকর নিয়ন্ত্রণ নয়। অটোমেটেড পার্জ জব, মেয়াদ শেষ হওয়ার তারিখ সহ ব্যতিক্রমী হোল্ড এবং সিস্টেম কখন ডেটা সরিয়েছে বা একত্রিত করেছে তা প্রদর্শনকারী একটি অডিট রিপোর্ট ব্যবহার করুন। যখন সংরক্ষণের সময়কাল পরিবর্তিত হয়, তখন গোপনীয়তার তথ্য, LIA এবং টেকনিক্যাল টাইমার একসাথে আপডেট করুন।তিনটি দ্রুত উত্তর। প্রথমত, আপনি কি একটি নির্দিষ্ট সময়ের জন্য অতিথি লগইন ডেটা রাখতে পারেন? হ্যাঁ, আপনি যদি একটি নির্দিষ্ট উদ্দেশ্যের বিপরীতে সঠিক সময়কালটিকে যুক্তিযুক্ত করতে পারেন। দ্বিতীয়ত, IPA এর অধীনে আপনাকে কি বারো মাস সংযোগের লগ সংরক্ষণ করতে হবে? শুধুমাত্র যদি একটি প্রযোজ্য রিটেনশন নোটিশের প্রয়োজন হয়, শুধুমাত্র আপনি শেয়ার্ড WiFi পরিচালনা করেন বলে নয়। তৃতীয়ত, প্রতিটি টেন্যান্টের কি একটি ডেটা প্রসেসিং চুক্তির প্রয়োজন আছে? যেখানেই আপনি তাদের নথিভুক্ত নির্দেশাবলীর উপর ভিত্তি করে টেন্যান্ট কর্মচারীদের ডেটা প্রসেস করছেন এমন একজন প্রসেসর হন, সেখানেই আপনার একটি Article 28 চুক্তির প্রয়োজন হবে। আপনি যদি যৌথভাবে উদ্দেশ্য এবং উপায় নির্ধারণ করেন, তবে পরিবর্তে একটি Article 26 জয়েন্ট-কন্ট্রোলার ব্যবস্থা মূল্যায়ন করুন। পরবর্তী ব্যবহারিক পদক্ষেপ হলো আপনার DPO, নেটওয়ার্ক লিড, বাণিজ্যিক মালিক এবং প্রতিটি প্রাসঙ্গিক টেন্যান্ট প্রতিনিধিকে একটি ওয়ার্কিং সেশনে নিয়ে আসা। ডেটার তালিকা তৈরি করুন। ভূমিকা নিশ্চিত করুন। সময়কাল সেট করুন। পার্জ কন্ট্রোল তৈরি করুন। একটি মুছে ফেলার অনুরোধ পরীক্ষা করুন। এবং যেকোনো IPA নোটিশ অবিলম্বে এসকলেট করুন। এভাবেই আপনি ভিজিটরদের আচরণের একটি অনির্দিষ্ট আর্কাইভ তৈরি না করে একটি প্রয়োজনীয় নেটওয়ার্ক রেকর্ড রাখতে পারেন। এই ব্রিফিংটি প্রযুক্তিগত তথ্য, কোনো আইনি পরামর্শ নয়। পলিসির উপর নির্ভর করার আগে আপনার এস্টেট, টেন্যান্ট চুক্তি এবং যেকোনো বিধিবদ্ধ নোটিশের সত্যতা যাচাই করতে যোগ্য আইনজীবীর পরামর্শ নিন।

আমাদের মূল সিরিজের অংশ: WiFi মার্কেটিং গাইড

শেয়ার্ড WiFi অপারেটরদের জন্য GDPR ডেটা ধারণ: আপনি কতক্ষণ গেস্ট লগইন ডেটা এবং নেটওয়ার্ক লগ রাখতে পারেন

UK GDPR-এর অধীনে, সনাক্তযোগ্য গেস্ট WiFi লগইন ডেটা এবং নেটওয়ার্ক লগ শুধুমাত্র নথিবদ্ধ উদ্দেশ্যে এবং তার বেশি সময় না রেখে সংরক্ষণ করুন। বেশিরভাগ অপারেশনাল সিকিউরিটি লগ একটি সংক্ষিপ্ত, পরীক্ষিত মেয়াদের জন্য যৌক্তিক হতে পারে, কোন সার্বজনীন নিয়ম নয়। একটি ১২ মাসের IPA মেয়াদ শুধুমাত্র তখনই প্রযোজ্য হয় যখন একটি প্রযোজ্য ডেটা রিটেনশন নোটিশে নির্দিষ্ট ডেটা রাখার প্রয়োজন হয়।1 7 9

একটি সমর্থনযোগ্য WiFi ডেটা রিটেনশন পলিসি কী?

একটি সমর্থনযোগ্য পলিসি প্রতিটি ডেটা ক্যাটাগরিকে একটি উদ্দেশ্য, একজন দায়বদ্ধ পক্ষ, একটি বৈধ ভিত্তি, একটি রিটেনশন মেয়াদ এবং একটি ডিলিট করার ইভেন্টের সাথে লিঙ্ক করে। এটি হলো Article 5(1)(e)-এর অপারেশনাল প্রকাশ: ব্যক্তিগত ডেটা প্রয়োজনের চেয়ে বেশি সময় ধরে সনাক্তযোগ্য রাখা যাবে না। ICO কোনো নির্দিষ্ট মেয়াদ নির্ধারণ করে দেয় না। আপনাকে এই মেয়াদের যৌক্তিকতা প্রমাণ করতে হবে, এটি নথিবদ্ধ করতে হবে, পর্যালোচনা করতে হবে এবং ডেটার আর প্রয়োজন না থাকলে তা মুছে ফেলতে হবে বা অ্যানোনিমাইজ করতে হবে।1

আইনি নোট: এটি একটি প্রযুক্তিগত কমপ্লায়েন্স নির্দেশিকা, কোনো আনুষ্ঠানিক আইনি পরামর্শ নয়। রিটেনশন শিডিউলের ওপর নির্ভর করার আগে আপনার এস্টেট মডেল, টেন্যান্ট চুক্তি এবং যেকোনো IPA নোটিশ যাচাই করতে একজন যোগ্যতাসম্পন্ন আইনজীবীর পরামর্শ নিন।

কেন শেয়ার্ড WiFi-এর ক্ষেত্রে কমপ্লায়েন্সের সমস্যাটি ভিন্ন?

Multi-Tenant WiFi এমন কিছু স্তর তৈরি করে যা একটি একক সাইটের গেস্ট নেটওয়ার্কে থাকে না। আপনি বাসিন্দা, সদস্য, গেস্ট এবং ভিজিটরদের জন্য একটি শেয়ার্ড অ্যাক্সেস লেয়ার পরিচালনা করতে পারেন, যেখানে একটি টেন্যান্ট এমপ্লয়ারকে Staff WiFi পরিষেবা প্রদান করছেন। আপনার নিজস্ব উদ্দেশ্যে, যেমন নেটওয়ার্ক সিকিউরিটি, সার্ভিস অ্যাসিউরেন্স এবং বিলিং বিরোধ ব্যবস্থাপনা, আপনি একজন কন্ট্রোলার হতে পারেন। শুধুমাত্র টেন্যান্টের নথিবদ্ধ নির্দেশাবলী অনুযায়ী প্রসেস করা কর্মচারী প্রমাণীকরণের জন্য, আপনি একজন প্রসেসর হতে পারেন। বাণিজ্যিক চুক্তির লেবেলটি এই বিষয়টি নির্ধারণ করে না।

ICO জানিয়েছে যে ভূমিকাটি নির্দিষ্ট প্রসেসিং অ্যাক্টিভিটির ওপর নির্ভর করে। যে পক্ষ ডেটা সংগ্রহের কারণ, আইনি ভিত্তি, ডেটা ক্যাটাগরি, প্রাপক, গোপনীয়তার তথ্য, অধিকার হ্যান্ডলিং বা রিটেনশন নির্ধারণ করে, সে সম্ভবত কন্ট্রোলার। একজন প্রসেসর টেকনিক্যাল পদ্ধতি, সিকিউরিটি কন্ট্রোল এবং ডিলিশন মেকানিক্স বেছে নিতে পারে কন্ট্রোলার না হয়েই, যতক্ষণ না এটি সামগ্রিক সিদ্ধান্তগুলি নিচ্ছে। একই ডেটাসেট তাই উদ্দেশ্য এবং ভূমিকা অনুসারে পৃথক হতে পারে। যদি উভয় পক্ষ যৌথভাবে উদ্দেশ্য এবং মাধ্যমগুলি নির্ধারণ করে, তবে সম্পর্কটিকে একটি সাধারণ প্রসেসর পরিষেবা হিসাবে বিবেচনা না করে একটি Article 26 যৌথ-কন্ট্রোলার ব্যবস্থা ব্যবহার করুন।4

শেয়ার্ড WiFi অ্যাক্টিভিটি সম্ভাব্য ভূমিকার প্রশ্ন ব্যবহারিক নিয়ন্ত্রণ
অপারেটরের নিজস্ব নেটওয়ার্কের জন্য গেস্ট স্প্ল্যাশ-পেজ প্রমাণীকরণ অপারেটর কি সংগ্রহ, নোটিশ এবং রিটেনশন নির্ধারণ করে? সেই উদ্দেশ্যে অপারেটরকে কন্ট্রোলার হিসেবে রেকর্ড করুন।
টেন্যান্ট কর্মচারীদের Staff WiFi প্রমাণীকরণ টেন্যান্ট কি জনসংখ্যা, অ্যাক্সেসের উদ্দেশ্য এবং রিটেনশন নির্ধারণ করে? অপারেটর টেন্যান্টের নির্দেশাবলী অনুসরণ করলে Article 28-এর শর্তাবলী ব্যবহার করুন।
ভাড়াটে-নেতৃত্বাধীন এনগেজমেন্ট ক্যাম্পেইন ভাড়াটে কি দর্শক এবং বার্তার উদ্দেশ্য নির্বাচন করেন? একটি পৃথক ভিত্তি ছাড়া অপারেটরের বিপণনের জন্য পুনরায় ব্যবহার প্রতিরোধ করুন।

এই বিশ্লেষণটি বিশেষ করে Hospitality, Retail, Healthcare এবং Transport এস্টেটের জন্য গুরুত্বপূর্ণ, যেখানে একটি শেয়ার্ড নেটওয়ার্ক একই ভবনে বেশ কয়েকটি স্বাধীন ব্যবসাকে পরিষেবা দিতে পারে।

আপনার কীভাবে ৫টি WiFi ডেটা ক্যাটাগরি শ্রেণিবদ্ধ করা উচিত?

কানেকশন মেটাডেটা-এর মধ্যে রয়েছে অ্যাসাইন করা IP অ্যাড্রেস, সোর্স MAC অ্যাড্রেস, সেশন শুরু এবং শেষের সময়, ট্রান্সফার করা বাইট, DHCP লিজ রেকর্ড এবং RADIUS অ্যাকাউন্টিং। একটি নামযুক্ত-লগইন পরিষেবাতে, এই ক্ষেত্রগুলি সাধারণত ব্যক্তিগত ডেটা হবে কারণ এগুলি কোনও ব্যক্তির সাথে লিঙ্ক করা যেতে পারে। নির্দিষ্ট নিরাপত্তা এবং ট্রাবলশুটিং উদ্দেশ্যের জন্য প্রয়োজনীয় ক্ষেত্রগুলি রাখুন। একটি প্রস্তাবিত ৩০ থেকে ৯০ দিনের অপারেশনাল উইন্ডো হল একটি প্রাথমিক নীতি, কোনও সংবিধিবদ্ধ নিরাপদ আশ্রয় নয়। আপনার ঘটনা-শনাক্তকরণের সময়, হুমকির মডেল এবং তদন্ত করার ক্ষমতা অনুমোদিত সময়কাল নির্ধারণ করা উচিত।1 6

গেস্ট প্রমাণীকরণ ডেটা-এর মধ্যে রয়েছে ইমেল ঠিকানা, নাম, ফোন নম্বর এবং প্রমাণীকরণ শনাক্তকারী। আপনি যদি শুধুমাত্র গেস্ট WiFi-এ কোনও ব্যক্তিকে অ্যাক্সেস দেওয়ার জন্য এটি সংগ্রহ করেন, তবে অ্যাক্সেসের উদ্দেশ্য সেশনের সাথেই শেষ হয়ে যায়। শুধুমাত্র যেখানে আপনি এটি ব্যাখ্যা করতে পারেন সেখানে একটি সংক্ষিপ্ত, নথিভুক্ত বিরোধ বা জালিয়াতির লেজ ধরে রাখুন। আপনি যদি একটি সচেতন-পছন্দের বিপণন অপ্ট-ইন সংগ্রহ করেন, তবে অ্যাক্সেস ডেটা থেকে বিপণনের রেকর্ড আলাদা করুন। সম্মতি প্রত্যাহার করা যেতে পারে, এবং ইলেকট্রনিক বিপণনের নিজস্ব নিয়মও রয়েছে। প্রত্যাহার বা আপত্তির পর, বিপণন বন্ধ করুন এবং পছন্দটিকে সম্মান জানাতে প্রয়োজনীয় ন্যূনতম দমন তথ্য সংরক্ষণ করুন।2 6

অবস্থান এবং উপস্থিতি ডেটা-এর ক্ষেত্রে কাঁচা শনাক্তযোগ্য ট্রেইল এবং সামগ্রিক আউটপুটগুলির মধ্যে একটি কঠিন পার্থক্য প্রয়োজন। আপনি যদি এটিকে একটি লগইনের সাথে পুনরায় লিঙ্ক করতে পারেন তবে একটি টোকেন বেনামী নয়। ICO বলে যে ছদ্মনামযুক্ত ডেটা সাধারণত ব্যক্তিগত ডেটাই থাকবে, অন্যদিকে যে ডেটা আর শনাক্তকরণের অনুমতি দেয় না তা স্টোরেজ-সীমাবদ্ধতা নিয়মের বাইরে রাখা যেতে পারে। যেখানে আপনার স্বল্পমেয়াদী অপারেশনাল বিশ্লেষণের প্রয়োজন সেখানে একটি ৩০-দিনের কাঁচা-ট্রেস পিরিয়ডের পরে অপরিবর্তনীয় একত্রীকরণ একটি বুদ্ধিমান নীতি প্যাটার্ন। একত্রীকরণ পদ্ধতিটি নথিভুক্ত করুন এবং পুনরায় শনাক্তকরণ সম্ভব কিনা তা পরীক্ষা করুন।1মার্কেটিং যোগাযোগের ইতিহাস-এর মধ্যে পাঠানো, খোলা, ক্লিক করা এবং পছন্দের পরিবর্তন অন্তর্ভুক্ত রয়েছে। সিকিউরিটি-লগ টাইমারটি উত্তরাধিকারসূত্রে নেবেন না। এটি শুধুমাত্র উল্লিখিত মার্কেটিং উদ্দেশ্যে, প্রযোজ্য আইনি ভিত্তিতে এবং একটি নথিভুক্ত পর্যালোচনার তারিখ সহ সংরক্ষণ করুন। নিচে দেওয়া ২৪ মাসের পর্যালোচনার সময়টি একটি প্রস্তাবিত কার্যকারী সীমা, কোনো ICO সময়সীমা নয়। কোনো ব্যক্তি তার সম্মতি প্রত্যাহার করেনি বলেই তার এনগেজমেন্ট প্রোফাইল সংরক্ষণ করে রাখবেন না। সম্মতি প্রত্যাহার করা হলে, মার্কেটিং ইতিহাস মুছে ফেলুন বা ডি-আইডেন্টিফাই (de-identify) করুন, যদি না কোনো আলাদা, নথিভুক্ত প্রয়োজনীয়তা থাকে। একটি অপ্ট-আউট সাপ্রেশন এন্ট্রি ভিন্ন: এটি ভবিষ্যতের বার্তা পাঠানো প্রতিরোধ করে।2 6

অপব্যবহার এবং সিকিউরিটি লগের মধ্যে ফায়ারওয়াল ডিনায়াল, DNS সিকিউরিটি ইভেন্ট এবং RADIUS অ্যাকাউন্টিং অন্তর্ভুক্ত থাকতে পারে। নেটওয়ার্ক এবং তথ্য সিকিউরিটি বৈধ স্বার্থকে সমর্থন করতে পারে, তবে এটি স্বয়ংক্রিয়ভাবে তা করে না। সংরক্ষণের মেয়াদ শুরু করার আগে উদ্দেশ্য, প্রয়োজনীয়তা এবং ভারসাম্য পরীক্ষা সম্পন্ন করুন। একটি ৩৬৫ দিনের সময়সূচী সমর্থনযোগ্য হতে পারে যেখানে একটি শেয়ার্ড পাবলিক আইপি অ্যাড্রেসের অর্থ হলো বিলম্বিত ঘটনা, দাবি বা সমন পরিচালনার জন্য আপনার অ্যাট্রিবিউশন প্রমাণের প্রয়োজন। এটি কোনো GDPR-এর ন্যূনতম সীমা নয়। ফিল্ডের সংখ্যা হ্রাস করুন, অ্যাক্সেস সীমিত করুন, অনুসন্ধানগুলি লগ করুন এবং আর্কিটেকচার বা ঝুঁকি পরিবর্তিত হলে বৈধ স্বার্থের মূল্যায়ন পর্যালোচনা করুন।1 6

শেয়ার্ড WiFi অপারেটরদের জন্য GDPR ডেটা ধারণ: আপনি কতক্ষণ গেস্ট লগইন ডেটা এবং নেটওয়ার্ক লগ রাখতে পারেন - retention decision…

সিদ্ধান্তের প্রবাহ: স্বয়ংক্রিয়ভাবে মুছে ফেলার নিয়ম সেট করার আগে আইডেন্টিফায়াবিলিটি, ভূমিকা, আইনি ভিত্তি এবং যেকোনো সংবিধিবদ্ধ নোটিশ নির্ধারণ করুন।

আপনি কী ধরণের সংরক্ষণের সময়সূচী গ্রহণ করতে পারেন?

নিচের সময়সূচীটি যুক্তরাজ্যের একটি শেয়ার্ড WiFi এস্টেটের জন্য একটি ব্যবহারের উপযোগী বেসলাইন। এটি উদ্দেশ্য অনুযায়ী উদ্দেশ্যমূলকভাবে বিভক্ত করা হয়েছে। কন্ট্রোলার এস্টেটের জন্য উদ্দেশ্য, আইনি ভিত্তি এবং ঝুঁকি মূল্যায়ন নথিভুক্ত করার পরেই এটি গ্রহণ করুন। একটি IPA নোটিশ, আইনি হোল্ড বা সক্রিয় দাবি একটি সাধারণ মুছে ফেলার তারিখকে ওভাররাইড করতে পারে, তবে তা শুধুমাত্র নির্দিষ্ট রেকর্ড এবং ব্যতিক্রমের যৌক্তিক মেয়াদের জন্য প্রযোজ্য।1 7 9

ডেটা বিভাগ উদ্দেশ্য এবং আইনি ভিত্তি প্রস্তাবিত ডিফল্ট সংরক্ষণ মুছে ফেলা বা পরিবর্তনের ইভেন্ট
কানেকশন মেটাডেটা এবং DHCP বা RADIUS সেশন ডেটা নেটওয়ার্ক সিকিউরিটি এবং ত্রুটি অনুসন্ধান - অনুচ্ছেদ 6(1)(f), LIA সাপেক্ষে ৯০ দিন ৯০ তম দিনে মুছে ফেলুন যদি না কোনো অনুমোদিত ঘটনা বা আইনি হোল্ড প্রযোজ্য হয়।
গেস্ট অ্যাক্সেস অথেন্টিকেশন ডেটা গেস্ট অ্যাক্সেস প্রদান করা এবং স্বল্পমেয়াদী বিরোধ নিষ্পত্তি করা - ডিজাইন অনুযায়ী অনুচ্ছেদ 6(1)(b) বা 6(1)(f) সেশন শেষ হওয়ার পর ৩০ দিন ৩০ তম দিনে শনাক্তকরণযোগ্য অ্যাক্সেস ডেটা মুছে ফেলুন।
অপরিশোধিত শনাক্তকরণযোগ্য লোকেশন ট্রেস স্বল্পমেয়াদী কার্যকারী বিশ্লেষণ - অনুচ্ছেদ 6(1)(f), LIA সাপেক্ষে ৩০ দিন ৩০ তম দিনে অপরিবর্তনীয়ভাবে একত্রিত করুন অথবা মুছে ফেলুন।
মার্কেটিং যোগাযোগ এবং এনগেজমেন্টের ইতিহাস সম্মতি বা অন্য কোনো নথিভুক্ত মার্কেটিং ভিত্তি সম্মতি প্রত্যাহার, আপত্তি বা ২৪ মাসের পর্যালোচনা, যেটি আগে ঘটে প্রোফাইলটি মুছে ফেলুন বা ডি-আইডেন্টিফাই (de-identify) করুন। প্রয়োজনে শুধুমাত্র একটি ন্যূনতম সাপ্রেশন রেকর্ড সংরক্ষণ করুন।
Security and abuse evidence Network security, defence of claims or an applicable legal duty 365 days only where the LIA documents the shared-address attribution need Purge at day 365 unless a specific hold or legal obligation applies.
Data specified in a valid IPA retention notice Compliance with the notice - Article 6(1)(c) Exact notice period, capped at 12 months Purge when notice-specific period ends, unless another documented basis applies.

৯০ দিনের কানেকশন সময়কাল এবং ৩৬৫ দিনের অপব্যবহারের সময়কাল নীতিগত সিদ্ধান্ত, কোনো বাধ্যতামূলক সংখ্যা নয়। এগুলো কেবল তখনই কার্যকর হয় যখন আপনার লিখিত LIA, গোপনীয়তা বিজ্ঞপ্তি, সিস্টেমের প্রমাণ এবং স্বয়ংক্রিয় মুছে ফেলার ডিজাইন সম্পূর্ণ মিলে যায়। একটি পাবলিক অথরিটিকে অবশ্যই পরীক্ষা করতে হবে যে তারা কোনো পাবলিক টাস্ক সম্পাদন করছে কিনা, কারণ সেই কাজের জন্য তারা লেজিটিমেট ইন্টারেস্টের ওপর নির্ভর করতে পারে না।[৬]

আপনার নির্দিষ্ট সেটআপ নিয়ে কোনো প্রশ্ন আছে?

আমাদের টিম ৮০,০০০ ভেন্যুতে ভেন্যু অপারেটর, IT ম্যানেজার এবং নেটওয়ার্ক ইঞ্জিনিয়ারদের সাথে কাজ করে। একটি ২০ মিনিটের কল বুক করুন এবং আপনার মতো অন্যরা কীভাবে এর সমাধান করেছেন তা আমরা আপনাকে দেখাব।

IPA কি একজন শেয়ার্ড WiFi অপারেটরকে ১২ মাসের জন্য লগ সংরক্ষণ করতে বাধ্য করে?

না, ডিফল্টভাবে নয়। টেলিযোগাযোগ অপারেটরের IPA সংজ্ঞা অত্যন্ত ব্যাপক। সরকারের ২০২৫ সালের নোটিশ কোড অনুযায়ী, এর মধ্যে এমন ব্যক্তিও অন্তর্ভুক্ত হতে পারেন যিনি কোনো গেস্ট বা সাধারণ জনগণকে এমন কোনো যোগাযোগ পরিষেবার অ্যাক্সেস দেন যা অন্য কোনো পরিষেবার সহায়ক, যার মধ্যে হোটেল বা অন্যান্য বাণিজ্যিক প্রাঙ্গণও অন্তর্ভুক্ত। এটি MDU, কো-ওয়ার্কিং বা পরিচালিত WiFi অপারেটরদের জন্য প্রাসঙ্গিক করে তোলে।[৮] [৯]

কিন্তু একই কোডে স্পষ্ট বলা হয়েছে যে ডিফল্ট অবস্থান হলো ডেটা রিটেনশন নোটিশ না দেওয়া পর্যন্ত এই আইনের অধীনে কোনো ডেটা সংরক্ষণের বাধ্যবাধকতা নেই। IPA ধারা ৮৭ এর অধীনে, স্বরাষ্ট্র সচিব কেবল তখনই একটি নোটিশ জারি করতে পারেন যখন প্রয়োজনীয়তাটি অত্যন্ত প্রয়োজনীয় ও আনুপাতিক হয় এবং একজন জুডিশিয়াল কমিশনার সেটি অনুমোদন করেন। নোটিশে অবশ্যই অপারেটর, ডেটা এবং সময়কাল চিহ্নিত থাকতে হবে। এটি ১২ মাসের বেশি সংরক্ষণের দাবি করতে পারে না। পরিষেবাটি টেলিযোগাযোগ অপারেটরের একটি সাধারণ সংজ্ঞার সাথে মিলে যেতে পারে কেবল এই কারণে "১২ মাসের জন্য সবকিছু সংরক্ষণ করুন" - এমন কোনো সাধারণ নীতি তৈরি করবেন না।[৭] [৯]

যেখানে একটি বৈধ নোটিশ আইনি বাধ্যবাধকতা তৈরি করে, সেখানে অনুচ্ছেদ ৬(১)(সি) মেনে চলার জন্য প্রয়োজনীয় প্রক্রিয়াকরণের জন্য UK GDPR আইনি ভিত্তি প্রদান করতে পারে। এটি কোনো চুক্তিভিত্তিক ভিত্তি নয়। ICO জানিয়েছে যে আপনাকে অবশ্যই নির্দিষ্ট আইনি বিধান চিহ্নিত করতে হবে, সিদ্ধান্তটি নথিভুক্ত করতে হবে এবং গোপনীয়তার তথ্যে উদ্দেশ্য ও আইনি ভিত্তি ব্যাখ্যা করতে হবে। এই নোটিশ কোনো গৌণ মার্কেটিং ব্যবহার বা অনির্দিষ্টকালের সংগ্রহের অনুমতি দেয় না।[৩]

অনুচ্ছেদ ২৮ এর ভাড়াটে চুক্তিতে কী কী থাকতে হবে?

আপনি যদি ভাড়াটে কর্মচারীদের ডেটা কেবল সেই ভাড়াটের নথিভুক্ত নির্দেশাবলীর ভিত্তিতেই প্রক্রিয়া করেন, তবে সেই প্রক্রিয়াকরণ শুরু করার আগে একটি অনুচ্ছেদ ২৮ ডেটা প্রসেসিং চুক্তি থাকতে হবে। চুক্তিতে বিষয়বস্তু ও সময়কাল, প্রকৃতি ও উদ্দেশ্য, ডেটার ধরন, ডেটা সাবজেক্টের ক্যাটাগরি এবং কন্ট্রোলারের অধিকার ও বাধ্যবাধকতা বর্ণনা করা উচিত। এরপর এতে নিচের কর্মক্ষম প্রতিশ্রুতিগুলো থাকতে হবে।[৫]

Article 28 obligation What to make operational on Staff WiFi
Documented instructions Store the tenant’s approved authentication, retention and disclosure instructions.
সাব-প্রসেসর প্রাসঙ্গিক সাব-প্রসেসর পরিবর্তন সম্পর্কে টেন্যান্টকে অবহিত করুন এবং সমমানের সুরক্ষা প্রদান করুন।
অধিকার সহায়তা অ্যাক্সেস, সংশোধন, মুছে ফেলা এবং আপত্তির অনুরোধগুলির জন্য হ্যান্ড-অফ নির্ধারণ করুন।
লঙ্ঘন এবং DPIA সমর্থন ঘটনা বিজ্ঞপ্তির রুট এবং নিরাপত্তা মূল্যায়ন সহায়তা সেট করুন।
চুক্তি শেষ হওয়ার পর ফেরত বা মুছে ফেলা ফেরত দেওয়া বা নিরাপদ মুছে ফেলা বেছে নিন, তবে ইউকে আইনের যেখানে একটি নির্দিষ্ট রেকর্ড রাখার প্রয়োজন রয়েছে তা ব্যতিক্রম হিসেবে গণ্য হবে।
অডিট এবং প্রমাণ সম্মতি প্রদর্শনের জন্য প্রয়োজনীয় তথ্য এবং অডিট অ্যাক্সেস প্রদান করুন।

যৌথ কন্ট্রোলার ব্যবস্থা আড়াল করতে অনুচ্ছেদ ২৮-এর চুক্তি ব্যবহার করবেন না। যদি অপারেটর এবং টেন্যান্ট যৌথভাবে সিদ্ধান্ত নেয় কেন কর্মচারীর বিশ্লেষণ ব্যবহার করা হবে, কোন ক্ষেত্রগুলি সংগ্রহ করা হবে এবং কতক্ষণ সেগুলি উপলব্ধ থাকবে, তবে এর পরিবর্তে অনুচ্ছেদ ২৬ মূল্যায়ন করুন।[৪]

কীভাবে আপনার একটি মুছে ফেলার অনুরোধ পরিচালনা করা উচিত?

অনুচ্ছেদ ১৭ অনুসারে মুছে ফেলা কোনো এক-ক্লিকের মুছে ফেলার ফাংশন নয়। একটি আনুপাতিক পরিচয় পরীক্ষা দিয়ে শুরু করুন। তারপরে উদ্দেশ্য এবং ভূমিকা অনুসারে ডেটা সন্ধান করুন: অতিথি অ্যাক্সেস, বিপণন, নিরাপত্তা, টেন্যান্টের নির্দেশনা এবং যেকোনো নোটিশ-নির্দিষ্ট ধরে রাখা। ICO বলছে যে আপনার অযথা বিলম্ব না করে এবং সর্বশেষে এক মাসের মধ্যে প্রতিক্রিয়া জানানো উচিত। যেখানে ডেটা আর প্রয়োজনীয় নয়, বা সম্মতি প্রত্যাহার করা হয়েছে, সেখানে লাইভ রেকর্ড থেকে এটি মুছে ফেলুন এবং যেখানে প্রয়োজন সেখানে প্রাসঙ্গিক প্রাপকদের অবহিত করুন।[২]

যেখানে একটি আইনি বাধ্যবাধকতা প্রযোজ্য হয়, অথবা আইনি দাবির প্রতিষ্ঠা, প্রয়োগ বা প্রতিরক্ষার জন্য ডেটা প্রয়োজনীয়, সেখানে মুছে ফেলার অধিকার সেই সীমা পর্যন্ত প্রযোজ্য নয়। সীমিত কারণটি স্পষ্টভাবে ব্যাখ্যা করুন। ধরে রাখা ডেটা আলাদা রাখুন, সম্পর্কহীন ব্যবহার প্রতিরোধ করুন এবং প্রাসঙ্গিক শেষ তারিখ প্রয়োগ করুন। ব্যাকআপের একটি স্পষ্ট উত্তরের প্রয়োজন: যেখানে বাস্তবসম্মত সেখানে মুছে ফেলার পরিধিতে ব্যাকআপগুলিও অন্তর্ভুক্ত করা উচিত। যদি অবিলম্বে ওভাররাইট করা অসম্ভব হয়, তবে ব্যাকআপ রেকর্ডটি ব্যবহারের বাইরে রাখুন এবং ওভাররাইটের সময়সূচী প্রকাশ করুন।[২]

শেয়ার্ড WiFi অপারেটরদের জন্য GDPR ডেটা ধারণ: আপনি কতক্ষণ গেস্ট লগইন ডেটা এবং নেটওয়ার্ক লগ রাখতে পারেন - data erasure reque…

একটি মুছে ফেলার ওয়ার্কফ্লোতে মুছে ফেলা হবে এমন ডেটা একটি নথিভুক্ত ব্যতিক্রমের অধীনে ধরে রাখা সংকীর্ণ রেকর্ড থেকে আলাদা করা উচিত।

বাস্তব ভেন্যুতে এটি কীভাবে কাজ করে?

আতিথেয়তা দৃশ্যপট: অতিথি অ্যাক্সেস এবং টেন্যান্ট কর্মীদের অ্যাক্সেস সহ একটি হোটেল

একটি ২০০ কক্ষের হোটেল দর্শকদের জন্য Guest WiFi পরিচালনা করে এবং তার রেস্তোরাঁ টেন্যান্টকে একটি Staff WiFi SSID সরবরাহ করে। হোটেলটি প্রক্রিয়াকরণের দুটি পৃথক রেকর্ড লেখে। এটি অতিথি প্রমাণীকরণ, ৯০ দিনের সংযোগের ডেটা এবং নিরাপত্তা তদন্তের জন্য কন্ট্রোলার হিসাবে কাজ করে। রেস্তোরাঁটি তার কর্মীদের SSID-এর জন্য কর্মচারী জনসংখ্যা, অ্যাক্সেসের শর্তাবলী এবং ধরে রাখার সিদ্ধান্ত নেয়, তাই হোটেলটি সেই প্রক্রিয়াকরণে অনুচ্ছেদ ২৮-এর শর্তাবলী প্রয়োগ করে। পরিমাপযোগ্য নিয়ন্ত্রণ হল একটি মাসিক প্রতিবেদন যা দেখায় যে ৯০ দিনের বেশি পুরানো প্রতিটি অতিথি সেশন পরিষ্কার করা হয়েছে, যেখানে যেকোনো ব্যতিক্রমের একটি ঘটনা বা নোটিশের রেফারেন্স রয়েছে।

খুচরা দৃশ্যপট: একটি পাবলিক ঠিকানায় একটি কেনাকাটার গন্তব্য

একটি রিটেইল ডেস্টিনেশন একাধিক ইউনিটে একটিমাত্র পাবলিক ইগ্রেস অ্যাড্রেস ব্যবহার করে। এর সিকিউরিটি LIA রেকর্ড করে যে কেন বিলম্বিত অপব্যবহারের অভিযোগগুলোর জন্য একটি নির্দিষ্ট সংযোগের অ্যাট্রিবিউশনের প্রয়োজন হতে পারে। এটি ৩৬৫ দিনের একটি সিকিউরিটি-এভিডেন্স শিডিউল সেট করে, তবে ডেটা একত্রিত বা অ্যাগ্রিগেশন করার আগে ৩০ দিনের জন্য শনাক্তকরণযোগ্য কাঁচা বা র লোকেশন ট্রেইলগুলো সংরক্ষণ করে। পরিমাপযোগ্য নিয়ন্ত্রণটি হলো একটি ত্রৈমাসিক LIA পর্যালোচনা এবং সেইসাথে একটি পরীক্ষা যা প্রমাণ করে যে একজন নিরাপত্তা বিশ্লেষক কোনো মেয়াদোত্তীর্ণ র লোকেশন ডেটা অ্যাক্সেস না করেই একটি অনুমোদিত ঘটনার পুনর্গঠন করতে পারেন।

ইভেন্ট সিনারিও: স্পন্সর-নিয়ন্ত্রিত দর্শক সহ একটি কনফারেন্স ভেন্যু

একটি কনফারেন্স সেন্টার অংশগ্রহণকারীদের অ্যাক্সেস প্রদান করে এবং স্পন্সররা আলাদা ব্র্যান্ডেড জার্নির মাধ্যমে অপ্ট-ইন সংগ্রহ করে। ভেন্যুটি পরিষেবা এবং সুরক্ষা ডেটার জন্য কন্ট্রোলার হিসেবে থাকে। প্রতিটি স্পন্সর তার নিজস্ব মার্কেটিং উদ্দেশ্য নিয়ন্ত্রণ করে এবং শুধুমাত্র সেই অপ্ট-ইনগুলোই তাদের পাওয়া উচিত যা ব্যবহার করার অধিকার তাদের আছে। পরিমাপযোগ্য নিয়ন্ত্রণটি হলো একটি ইভেন্ট-পূর্ব পরীক্ষা যা প্রমাণ করে যে একটি স্পন্সর জার্নিতে অপ্ট-আউট বা উইথড্র করলে তা সেই স্পন্সরের যোগাযোগ বন্ধ করে দেয়, কিন্তু ভেন্যুর সুরক্ষিতভাবে ধরে রাখা নির্দিষ্ট সিকিউরিটি এভিডেন্স মুছে ফেলে না।

এর পরে আপনার কী করা উচিত?

কোনো পলিসি টেমপ্লেট দিয়ে শুরু না করে একটি ৬০ মিনিটের রিটেনশন ওয়ার্কশপ দিয়ে শুরু করুন। আপনার DPO, নেটওয়ার্ক আর্কিটেক্ট, ভেন্যু অপারেশনস লিড এবং প্রতিটি প্রাসঙ্গিক টেন্যান্ট প্রতিনিধিদের সাথে রাখুন। স্প্ল্যাশ পেজ, DHCP, RADIUS, ফায়ারওয়াল, DNS এবং অ্যানালিটিক্স উপাদানগুলো থেকে আসা ফিল্ডগুলোর একটি টেবিল তৈরি করুন। প্রতিটি ফিল্ডের জন্য উদ্দেশ্য, কন্ট্রোলার বা প্রসেসর রোল, বৈধ ভিত্তি, রিটেনশন টাইমার, ডিলিট করার অ্যাকশন, অডিট মালিক এবং লিগ্যাল-হোল্ড প্রক্রিয়া নির্ধারণ করুন।

তারপর কাজটি করার জন্য সিস্টেমটি কনফিগার করুন। Purple কনফিগারযোগ্য রিটেনশন পিরিয়ড, স্বয়ংক্রিয় পার্জ শিডিউল, অ্যাক্সেস-রিকোয়েস্ট টুলিং এবং ইরেজার ওয়ার্কফ্লো প্রদান করে যা এই অপারেটিং মডেলটিকে সমর্থন করে। আপনার Guest WiFi পরিবেশকে যেকোনো টেন্যান্টের স্টাফ WiFi উদ্দেশ্য থেকে সম্পূর্ণ আলাদা রাখুন। যেখানে আপনি WiFi Analytics ব্যবহার করছেন, সেখানে শনাক্তকরণযোগ্য রিটেনশন উইন্ডো শেষ হওয়ার আগেই ডেটা অ্যাগ্রিগেট বা ডি-আইডেন্টিফাই করে ফেলুন। একটি ক্লাউড ওভারলে একটি ডিস্ট্রিবিউটেড এস্টেট জুড়ে ধারাবাহিকভাবে পলিসি প্রয়োগ করা সহজ করে তুলবে, ডিফল্টরূপে রেকর্ডের মেয়াদ দীর্ঘায়িত করবে না।

প্রাসঙ্গিক নিয়ন্ত্রণের জন্য, ডেটা-রিটেনশন ডিজাইনটিকে এর সাথে তুলনা করুন Hardening RADIUS against MD5 collision attacks (BlastRADIUS), Privacy by design: anonymising WiFi data for GDPR compliance এবং MDU WiFi tenant session tracking and abuse attribution। আরও বিস্তৃত প্রসঙ্গের জন্য দেখুন The definitive timeline of WiFi: from ALOHAnet to WiFi 7 and beyond, Guest WiFi Management: Smart Authentication & Segmentation, Cloud Wifi Management: Secure Enterprise Connectivity 2026 এবং Purple appoints Imani Butler as Growth Director, North America

প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী

GDPR এর অধীনে আমি কতক্ষণ guest WiFi লগইন ডেটা রাখতে পারি?

অ্যাক্সেস, বিরোধ, নিরাপত্তা বা অন্যান্য উল্লেখিত উদ্দেশ্য প্রয়োজনীয় থাকা পর্যন্ত এটি সংরক্ষণ করুন। শুধুমাত্র অ্যাক্সেস প্রমাণীকরণের জন্য একটি ব্যবহারিক সূচনা পয়েন্ট হলো সেশন শেষ হওয়া এবং সাথে একটি সংক্ষিপ্ত নথিবদ্ধ বিরোধের সময়কাল, যেমন ৩০ দিন। এটি একটি নীতিগত সিদ্ধান্ত, কোনো GDPR নিয়ম নয়। উদ্দেশ্য, আইনি ভিত্তি এবং মুছে ফেলার ঘটনাটি রেকর্ড করুন, তারপর পার্জ পরীক্ষা করুন।

UK Investigatory Powers Act কি WiFi সংযোগ রেকর্ডের ১২ মাস রাখার দাবি করে?

না। IPA প্রতিটি শেয়ার্ড WiFi অপারেটরের জন্য একটি স্বয়ংক্রিয় ১২ মাসের দায়িত্ব তৈরি করে না। একটি ডেটা ধারণ করার দায়িত্ব তখনই শুরু হয় যখন একটি প্রযোজ্য ডেটা ধারণের নোটিশ দেওয়া হয়। নোটিশটি প্রাসঙ্গিক যোগাযোগ ডেটা এবং ধারণের সময়কাল নির্ধারণ করে, যা ১২ মাসের বেশি হতে পারে না। আপনি যদি এমন নোটিশ পান তবে অবিলম্বে বিশেষজ্ঞের পরামর্শ নিন।7 9

স্টাফ WiFi-তে একজন ভাড়াটিয়ার কর্মীদের জন্য আমি কি কন্ট্রোলার নাকি প্রসেসর?

এটি প্রক্রিয়াকরণ কার্যক্রমের উপর নির্ভর করে। ভাড়াটিয়া যদি কর্মীদের জনসংখ্যা, উদ্দেশ্য, নোটিশ, অধিকার পরিচালনা এবং ধারণের সিদ্ধান্ত নেন এবং আপনি লিখিত নির্দেশাবলীর অধীনে পরিষেবাটি পরিচালনা করেন, তবে আপনি সম্ভবত সেই কার্যক্রমের জন্য প্রসেসর। আপনি যদি নিজের উদ্দেশ্যে সেই সিদ্ধান্তগুলো নেন, তবে আপনি কন্ট্রোলার। যেখানে উভয় পক্ষ যৌথভাবে অপরিহার্য উদ্দেশ্য এবং মাধ্যম নির্ধারণ করে, সেখানে যৌথ কন্ট্রোলারশিপ মূল্যায়ন করুন।4

একটি শেয়ার্ড WiFi নেটওয়ার্কে IP-address লগগুলির জন্য সঠিক ধারণের সময়কাল কত?

কোনো নির্ধারিত UK GDPR সময়কাল নেই। উল্লেখিত নিরাপত্তা এবং সমস্যা সমাধানের প্রয়োজনের সাথে সম্পর্কিত একটি আনুপাতিক সময়কাল নির্ধারণ করুন। এই নির্দেশিকাটি সংযোগ মেটাডেটার জন্য একটি প্রস্তাবিত ডিফল্ট হিসেবে ৯০ দিন ব্যবহার করে। শুধুমাত্র সেখানে এটি ৩৬৫ দিন পর্যন্ত বাড়ান যেখানে একটি নথিবদ্ধ LIA একটি প্রকৃত শেয়ার্ড-ঠিকানা বৈশিষ্ট্য বা দাবির প্রয়োজনকে সমর্থন করে, সাথে ফিল্ড মিনিমাইজেশন এবং অ্যাক্সেস নিয়ন্ত্রণ থাকে।1 6

ট্রাফিক ডেটা রাখার জন্য আইনি বাধ্যবাধকতা থাকলে কোনো মুছে ফেলার অনুরোধে আমার কী করা উচিত?

যে রেকর্ডগুলো আর প্রয়োজন নেই তা মুছে ফেলুন, তবে আইনি বাধ্যবাধকতার জন্য প্রয়োজনীয় সীমিত ডেটা এবং সময়কালটিই কেবল ধরে রাখুন। এক মাসের মধ্যে সাড়া দিন, প্রযোজ্য ছাড়টি ব্যাখ্যা করুন এবং ধারণকৃত ডেটা যাতে সম্পর্কহীন উদ্দেশ্যে ব্যবহার করা না হয় তা প্রতিরোধ করুন। ব্যাকআপের ক্ষেত্রেও একই সিদ্ধান্ত প্রয়োগ করুন তা মুছে ফেলে বা নির্ধারিত ওভাররাইট না হওয়া পর্যন্ত ব্যবহারের বাইরে রেখে।2 3

আমার কি প্রতিটি ভাড়াটে প্রতিষ্ঠানের সাথে একটি DPA প্রয়োজন?

যখনই আপনি কোনো ভাড়াটিয়ার লিখিত নির্দেশাবলী অনুযায়ী সেই ভাড়াটিয়ার কর্মচারীদের ডেটা প্রক্রিয়া করবেন, তখনই আপনার একটি Article 28 ডেটা প্রসেসিং চুক্তি প্রয়োজন। আপনি কেবল একটি বিল্ডিং শেয়ার করছেন বলেই এটির প্রয়োজন নেই। যদি উভয় পক্ষ মিলে উদ্দেশ্য এবং অপরিহার্য মাধ্যম নির্ধারণ করে, তবে তার পরিবর্তে একটি Article 26 যৌথ-কন্ট্রোলার ব্যবস্থার প্রয়োজন হতে পারে।4 5

একজন গেস্ট সম্মতি প্রত্যাহার না করা পর্যন্ত আমি কি মার্কেটিং ইতিহাস রাখতে পারি?

না। সক্রিয় সম্মতি স্টোরেজ সীমাবদ্ধতার (storage-limitation) বাধ্যবাধকতাকে দূর করে না। মার্কেটিং ইতিহাসের জন্য একটি পর্যালোচনা সময়সীমা নির্ধারণ ও নথিভুক্ত করুন, যেমন ২৪ মাসের একটি পর্যালোচনা, এবং যে ডেটা আর নির্দিষ্ট উদ্দেশ্যে প্রয়োজনীয় নয় তা মুছে ফেলুন বা ডি-আইডেন্টিফাই (de-identify) করুন। সম্মতি প্রত্যাহার বা আপত্তির ক্ষেত্রে, মার্কেটিং বন্ধ করুন এবং ব্যবহারকারীর পছন্দকে সম্মান জানাতে প্রয়োজনীয় ন্যূনতম ডেটা (suppression data) সংরক্ষণ করুন।1 2

References

মূল সংজ্ঞাসমূহ

স্টোরেজ সীমাবদ্ধতা

Article 5(1)(e) নীতি যার জন্য শনাক্তযোগ্য ব্যক্তিগত ডেটা তার প্রক্রিয়াকরণের উদ্দেশ্যের জন্য প্রয়োজনের চেয়ে বেশি সময় না রাখার প্রয়োজন হয়।

একটি কম্বল লগ-ধারণ নিয়মের পরিবর্তে প্রতিটি WiFi রেকর্ডের প্রকারের জন্য একটি অনুমোদিত টাইমারকে ন্যায্যতা দিতে এটি ব্যবহার করুন।

সংযোগ মেটাডেটা

একটি নেটওয়ার্ক অ্যাক্সেস সেশন সম্পর্কিত ডেটা, যেমন IP ঠিকানা, ডিভাইস শনাক্তকারী, সেশনের সময়, DHCP লিজ এবং RADIUS অ্যাকাউন্টিং রেকর্ড।

আপনি যখন সেশনটিকে একজন নামযুক্ত ব্যক্তির সাথে লিঙ্ক করতে পারেন তখন এটি ব্যক্তিগত ডেটা হয়ে উঠতে পারে।

DHCP লিজ

একটি নেটওয়ার্কের একটি ডিভাইসে একটি IP ঠিকানা বরাদ্দকারী একটি সময়-সীমাবদ্ধ রেকর্ড।

এটি ত্রুটি তদন্ত এবং অ্যাট্রিবিউশন সমর্থন করে, তবে এটির নিজস্ব ধারণ বিশ্লেষণ থাকা উচিত।

RADIUS অ্যাকাউন্টিং

একটি ডিভাইস নেটওয়ার্ক অ্যাক্সেস করার সময় তৈরি হওয়া প্রমাণীকরণ, অনুমোদন এবং অ্যাকাউন্টিং রেকর্ড।

একটি শেয়ার্ড WiFi তদন্তে প্রয়োজনীয় পরিচয়-টু-সেশন প্রমাণের জন্য এটি প্রায়শই কেন্দ্রীয় ভূমিকা পালন করে।

ছদ্মনামকরণ

একটি কৌশল যা ডেটাকে একটি টোকেন বা কোড দ্বারা প্রতিস্থাপন করে সরাসরি শনাক্তকরণ হ্রাস করে যখন একটি পুনঃ-শনাক্তকরণ লিঙ্ক সম্ভব থাকে।

এটি একটি সুরক্ষা ব্যবস্থা, GDPR ধারণের বাধ্যবাধকতা থেকে স্বয়ংক্রিয়ভাবে মুক্তি পাওয়ার উপায় নয়।

বেনামীকরণ

একটি রূপান্তর যা বাস্তবে শনাক্তকরণকে আর সম্ভব করে তোলে না।

কাঁচা অপারেশনাল পিরিয়ডের পরে এটি ব্যবহার করুন যখন আপনার কেবল সামগ্রিক WiFi বিশ্লেষণের প্রয়োজন হয়।

আইনসম্মত স্বার্থ মূল্যায়ন

একটি Article 6(1)(f) প্রক্রিয়াকরণের উদ্দেশ্যের জন্য একটি নথিভুক্ত উদ্দেশ্য, প্রয়োজনীয়তা এবং ভারসাম্য বিশ্লেষণ।

ন্যূনতম অপারেশনাল প্রয়োজনের বাইরে সুরক্ষা লগ রাখার আগে এটি সম্পূর্ণ করুন।

ডেটা ধারণের নোটিশ

একটি IPA সেকশন ৮৭ নোটিশ যার জন্য একটি নির্দিষ্ট টেলিযোগাযোগ অপারেটরকে একটি নির্দিষ্ট সময়ের জন্য নির্দিষ্ট প্রাসঙ্গিক যোগাযোগ ডেটা রাখা প্রয়োজন।

এটি একটি আইনি-বাধ্যবাধকতার ভিত্তি তৈরি করতে পারে, তবে এটি প্রতিটি গেস্ট WiFi অপারেটরের জন্য একটি স্বয়ংক্রিয় কর্তব্য নয়।

Article 28 ডেটা প্রক্রিয়াকরণ চুক্তি

একটি কন্ট্রোলারের নথিভুক্ত নির্দেশাবলীতে প্রসেসর দ্বারা পরিচালিত প্রক্রিয়াকরণ পরিচালনাকারী একটি চুক্তি।

ভাড়াটে স্টাফ WiFi প্রক্রিয়াকরণের জন্য এটি ব্যবহার করুন যেখানে ভাড়াটে কেন এবং কীভাবে তা নিয়ন্ত্রণ করে।

লিগ্যাল হোল্ড

একটি নির্দিষ্ট তদন্ত, দাবি বা আইনি বাধ্যবাধকতার জন্য প্রয়োজনীয় রেকর্ডগুলি মুছে ফেলা থেকে বিরত রাখতে ব্যবহৃত একটি নথিভুক্ত এবং সময়-সীমিত ব্যতিক্রম।

এটির কেবল প্রাসঙ্গিক মুছে ফেলার নিয়ম স্থগিত করা উচিত, সমস্ত ঐতিহাসিক WiFi ডেটা সংরক্ষণ করা নয়।

সমাধানকৃত উদাহরণসমূহ

একটি ২০০ কক্ষের হোটেল গেস্ট WiFi এবং তার রেস্তোরাঁ ভাড়াটিয়ার জন্য একটি স্টাফ WiFi SSID পরিচালনা করে। এর ধারণ সংক্রান্ত সিদ্ধান্তগুলি কীভাবে আলাদা করা উচিত?

দুটি প্রক্রিয়াকরণ রেকর্ড তৈরি করুন। হোটেল গেস্ট প্রমাণীকরণ, ৯০ দিনের সংযোগ ডেটা এবং নিজস্ব সুরক্ষা তদন্তের জন্য কন্ট্রোলার হিসাবে কাজ করে। রেস্তোরাঁ কর্মচারীর উদ্দেশ্য, জনসংখ্যা এবং ধারণ নির্ধারণ করে, তাই হোটেলটি Article 28 এর শর্তাবলীর অধীনে কাজ করে। একটি মাসিক পার্জ রিপোর্ট এবং প্রতিটি ব্যতিক্রমের জন্য একটি রেকর্ড করা কারণ সহ সম্মতি প্রমাণ করুন।

একটি খুচরা গন্তব্য বেশ কয়েকটি ইউনিট জুড়ে একটি পাবলিক ইগ্রেস ঠিকানা ব্যবহার করে। লোকেশন ট্রেইল অনির্দিষ্টকালের জন্য সংরক্ষণ না করে এটি কীভাবে অপব্যবহারের প্রমাণ সংরক্ষণ করতে পারে?

একটি LIA-তে অ্যাট্রিবিউশনের প্রয়োজনীয়তা নথিভুক্ত করুন, সুরক্ষার প্রমাণকে প্রয়োজনীয় ক্ষেত্রে সীমাবদ্ধ করুন এবং শুধুমাত্র যেখানে শেয়ার্ড-ঠিকানার প্রেক্ষাপট এটিকে সমর্থন করে সেখানে একটি ৩৬৫ দিনের পর্যালোচনাযোগ্য অপব্যবহার-লগ নীতি নির্ধারণ করুন। কাঁচা শনাক্তযোগ্য লোকেশন ট্রেইল ৩০ দিনের জন্য রাখুন, তারপর অপরিবর্তনীয়ভাবে সেগুলিকে একত্রিত করুন বা মুছে ফেলুন। একটি অনুমোদিত ঘটনার পরিস্থিতির বিপরীতে ত্রৈমাসিকভাবে প্রক্রিয়াটি পরীক্ষা করুন।

একটি সম্মেলন কেন্দ্র অ্যাক্সেস সরবরাহ করে যখন স্পনসররা আলাদাভাবে ব্র্যান্ডেড অপ্ট-ইন সংগ্রহ করে। ভেন্যুর কাছে কোন রেকর্ডগুলি থাকা উচিত?

পরিষেবা এবং নেটওয়ার্ক-নিরাপত্তা রেকর্ডগুলিকে ভেন্যুর কন্ট্রোলার-উদ্দেশ্য ডেটা হিসাবে বিবেচনা করুন। স্পনসরদের কেবল সেই অপ্ট-ইনগুলি দিন যা তারা তাদের নিজস্ব বিবৃত বিপণন উদ্দেশ্যের জন্য ব্যবহার করার অধিকারী। প্রতিটি ইভেন্টের আগে, পরীক্ষা করুন যে একজন স্পনসরের প্রত্যাহার স্পনসর যোগাযোগগুলিকে দমন করে এবং শুধুমাত্র ভেন্যুর সংকীর্ণভাবে ন্যায়সঙ্গত সুরক্ষার প্রমাণ সংরক্ষণ করে।

এই সিরিজে পড়া চালিয়ে যান

রিটার্ন ভিজিট বাড়াতে কীভাবে বিপণনে SMS ব্যবহার করবেন

এই প্রযুক্তিগত রেফারেন্স গাইডটি রূপরেখা দেয় কীভাবে এন্টারপ্রাইজ ভেন্যুগুলি বারবার ভিজিট বাড়াতে SMS মার্কেটিং ইঞ্জিনের সাথে WiFi অ্যানালিটিক্স সংহত করতে পারে। এটি রিয়েল-টাইম উপস্থিতি ডেটা ক্যাপচার করতে, শারীরিক আচরণের উপর ভিত্তি করে স্বয়ংক্রিয় SMS ক্যাম্পেইন ট্রিগার করতে এবং রিটার্ন রেটের উপর সরাসরি প্রভাব পরিমাপ করার জন্য প্রয়োজনীয় আর্কিটেকচারের বিবরণ দেয়। মার্কেটিং অটোমেশনের সাথে নেটওয়ার্ক অবকাঠামো সারিবদ্ধ করে, IT এবং অপারেশনস টিমগুলি গ্রাহক ধরে রাখার জন্য একটি উচ্চ-ফলনশীল চ্যানেল স্থাপন করতে পারে।

গাইডটি পড়ুন →

First-party data marketing: ব্যবসায়ের জন্য একটি পুঙ্খানুপুঙ্খ নির্দেশিকা

এই নির্দেশিকাটি ব্যাখ্যা করে যে কীভাবে এন্টারপ্রাইজ গেস্ট WiFi নেটওয়ার্কগুলি ব্যবহার করে একটি শক্তিশালী first-party data মার্কেটিং কৌশল তৈরি করা যায়। এটি captive portals-এর মাধ্যমে সুরক্ষিত ডেটা ক্যাপচারের জন্য প্রযুক্তিগত আর্কিটেকচার, GDPR-সম্মত সম্মতি ওয়ার্কফ্লো, CRM ইন্টিগ্রেশন প্যাটার্ন এবং স্বয়ংক্রিয় ক্যাম্পেইন ডেপ্লয়মেন্ট কভার করে। হসপিটালিটি, রিটেইল, ইভেন্ট এবং পাবলিক সেক্টর পরিবেশের ভেন্যু অপারেটররা নিষ্ক্রিয় দর্শকদের একটি উচ্চ মানের, নিজস্ব মার্কেটিং অডিয়েন্সে পরিণত করার জন্য কার্যকরী নির্দেশিকা পাবেন।

গাইডটি পড়ুন →

গ্রাহকের ডেটা ম্যানেজমেন্ট প্ল্যাটফর্ম: ব্যবসার জন্য একটি বিস্তৃত নির্দেশিকা

এই নির্দেশিকায় ব্যাখ্যা করা হয়েছে কীভাবে ভেন্যু অপারেটররা খণ্ডিত ভিজিটর ডেটাকে একত্রিত করতে একটি গ্রাহক ডেটা ম্যানেজমেন্ট প্ল্যাটফর্ম স্থাপন করতে পারে। এটি প্রযুক্তিগত আর্কিটেকচার, ইন্টিগ্রেশন কৌশল এবং ফার্স্ট-পার্টি ডেটা প্রোফাইল তৈরিতে Guest WiFi-এর গুরুত্বপূর্ণ ভূমিকা কভার করে।

গাইডটি পড়ুন →

আপনার নির্দিষ্ট সেটআপ নিয়ে কোনো প্রশ্ন আছে?

আমাদের টিম ৮০,০০০ ভেন্যুতে ভেন্যু অপারেটর, IT ম্যানেজার এবং নেটওয়ার্ক ইঞ্জিনিয়ারদের সাথে কাজ করে। একটি ২০ মিনিটের কল বুক করুন এবং আপনার মতো অন্যরা কীভাবে এর সমাধান করেছেন তা আমরা আপনাকে দেখাব।