The Compliance Playbook: GDPR এবং Guest WiFi ডেটা প্রাইভেসি

Purple-এর টেকনিক্যাল ব্রিফিংয়ে আপনাকে স্বাগত। আমি Purple-এর একজন সিনিয়র টেকনিক্যাল কনটেন্ট স্ট্র্যাটেজিস্ট, এবং আজ আমরা এমন একটি বিষয় আলোচনা করছি যা প্রতিটি আইটি ম্যানেজার, নেটওয়ার্ক আর্কিটেক্ট এবং ভেন্যু অপারেশনস ডিরেক্টরের সঠিকভাবে মেনে চলা প্রয়োজন: গেস্ট WiFi-এর জন্য GDPR সম্মতি। পরিস্থিতিটি একটু ব্যাখ্যা করা যাক। আপনি একটি হোটেল, রিটেল চেইন, স্টেডিয়াম বা কনফারেন্স সেন্টার পরিচালনা করেন। আপনি গেস্ট WiFi প্রদান করেন। যখনই একজন ভিজিটর কানেক্ট করেন, জেনারেল ডেটা প্রোটেকশন রেগুলেশন বা GDPR-এর অধীনে আপনি একজন ডেটা কন্ট্রোলার হয়ে ওঠেন। এটি একটি নির্দিষ্ট আইনি পদবি। এর সাথে যুক্ত থাকে বাস্তব দায়বদ্ধতা, জরিমানা এবং যদি আপনার কোনো ভুল হয়, তবে এর পিছনে থাকে ব্র্যান্ডের সুনাম নষ্ট হওয়ার আসল ঝুঁকি। ইনফরমেশন কমিশনারস অফিস বা ICO এই বিষয়ে অত্যন্ত স্পষ্ট: MAC অ্যাড্রেস, IP অ্যাড্রেস, সেশন টাইমস্ট্যাম্প এবং লোকেশন ডেটা সবই ব্যক্তিগত ডেটা হিসেবে গণ্য হবে যদি সেগুলোকে কোনো শনাক্তকরণযোগ্য ব্যক্তির সাথে লিঙ্ক করা যায়। একটি গেস্ট WiFi পরিবেশে সাধারণত এটি সবসময়ই করা সম্ভব। একজন গেস্ট আপনার স্প্ল্যাশ পেজে তাদের ইমেল অ্যাড্রেস টাইপ করার সাথে সাথেই সেই ডিভাইসটি সম্পর্কে আপনার সংগ্রহ করা অন্যান্য প্রতিটি ডেটা পয়েন্ট ব্যক্তিগত ডেটা হয়ে ওঠে। তাহলে চলুন টেকনিক্যাল আর্কিটেকচার নিয়ে আলোচনা করা যাক। এখানেই আসল বিবরণ লুকিয়ে আছে। আপনার Captive Portal - যে স্প্ল্যাশ পেজটি গেস্টরা অনলাইন হওয়ার আগে দেখতে পান - সেটি হলো আপনার প্রাথমিক সম্মতি ইন্টারফেস। এখানেই বেশিরভাগ ভেন্যু সবচেয়ে গুরুতর ভুলগুলো করে থাকে। সবচেয়ে সাধারণ ভুলটি হলো বান্ডলিং। এটি এমন একটি প্রক্রিয়া যেখানে কোনো ভেন্যু গেস্টদের অনলাইনে যাওয়ার শর্ত হিসেবে মার্কেটিং ইমেল গ্রহণ করতে বাধ্য করে। GDPR-এর আর্টিকেল ৭ অনুসারে, সম্মতি অবশ্যই মুক্তভাবে দিতে হবে। আপনি যদি মার্কেটিং সম্মতির সাথে নেটওয়ার্ক অ্যাক্সেস বান্ডেল করেন, তবে সেই সম্মতি মুক্তভাবে দেওয়া হয়েছে বলে গণ্য হয় না। অতএব এটি অবৈধ। সম্পূর্ণ অগ্রহণযোগ্য। আপনার Captive Portal-এ অন্তত দুটি আলাদা সম্মতির উপাদান থাকতে হবে। প্রথমটি বাধ্যতামূলক: নেটওয়ার্ক অ্যাক্সেসের জন্য আপনার পরিষেবার শর্তাবলী বা টার্মস অফ সার্ভিস গ্রহণ করা। দ্বিতীয়টি ঐচ্ছিক এবং ডিফল্টভাবে আনটিক করা থাকে: মার্কেটিং যোগাযোগ পাওয়ার সম্মতি। একজন গেস্টকে মার্কেটিং-এ সম্মতি না দিয়েই আপনার WiFi-এ কানেক্ট করতে পারার সুবিধা থাকতে হবে। তারা যদি তা না পারে, তবে আপনি নিয়ম লঙ্ঘন করছেন। GDPR-এর রেসিটাল ৩২ স্পষ্টভাবে আগে থেকে টিক দেওয়া বক্স বা প্রি-টিকড বক্স নিষিদ্ধ করে। সম্মতির কাঠামোর বাইরেও, ব্যবহারকারী কোনো ডেটা সাবমিট করার আগে আপনার পোর্টালে একটি স্পষ্ট গোপনীয়তা বিজ্ঞপ্তি বা প্রাইভেসি নোটিশ প্রদর্শন করতে হবে। GDPR-এর আর্টিকেল ১৩ অনুসারে, এই বিজ্ঞপ্তিতে ব্যাখ্যা করতে হবে যে আপনি কী ডেটা সংগ্রহ করছেন, কেন সংগ্রহ করছেন, কতক্ষণ রাখছেন এবং কার সাথে শেয়ার করছেন। এর সাথে আপনার সম্পূর্ণ প্রাইভেসি পলিসির একটি লিঙ্ক থাকতে হবে। এবং সবচেয়ে গুরুত্বপূর্ণ বিষয় হলো, আপনার সিস্টেমকে প্রতিটি সম্মতির ইভেন্ট লগ করতে হবে: কে সম্মতি দিয়েছে, কখন দিয়েছে, কিসের জন্য সম্মতি দিয়েছে এবং সেই মুহূর্তে তারা ঠিক কোন সংস্করণের প্রাইভেসি নোটিশটি দেখেছিল। কোনো রেগুলেটর বা নিয়ন্ত্রক সংস্থা তদন্ত করতে আসলে এই সম্মতির অডিট ট্রেইলটিই আপনার নিয়ম মেনে চলার প্রমাণ হিসেবে কাজ করবে। এবার আসুন আপনার গেস্ট WiFi নেটওয়ার্ক আসলে যে চার ধরনের ডেটা সংগ্রহ করে তা নিয়ে আলোচনা করি, কারণ এটি বেশিরভাগ টিমের ধারণার চেয়েও অনেক বেশি বিস্তৃত। প্রথম: রেজিস্ট্রেশন ডেটা। নাম, ইমেল অ্যাড্রেস, ফোন নম্বর, সোশ্যাল লগইন ক্রেডেনশিয়াল। এটি সেই ডেটা যা গেস্টরা আপনার Captive Portal-এ স্বপ্রণোদিতভাবে প্রদান করেন। এর আইনি ভিত্তি হলো সম্মতি, এবং এটি অত্যন্ত সুনির্দিষ্ট বা গ্র্যানুলার হতে হবে।দ্বিতীয়ত: ডিভাইস এবং সেশন ডেটা। MAC addresses, IP addresses, কানেকশন এবং ডিসকানেকশনের টাইমস্ট্যাম্প, সেশনের সময়কাল, স্থানান্তরিত ডেটা। আপনার নেটওয়ার্কের সাথে একটি ডিভাইস যুক্ত হওয়ার সাথে সাথেই এটি স্বয়ংক্রিয়ভাবে সংগ্রহ করা হয়। নেটওয়ার্ক নিরাপত্তা এবং সমস্যা সমাধানের জন্য বেসিক সেশন লগিং করার ক্ষেত্রে Legitimate interest প্রযোজ্য হতে পারে - তবে শুধুমাত্র তখনই যদি আপনি একটি Legitimate Interest Assessment পরিচালনা করে থাকেন এবং প্রমাণ করতে পারেন যে আপনার স্বার্থ ব্যবহারকারীর গোপনীয়তার অধিকারকে খর্ব করে না। তৃতীয়ত: লোকেশন ডেটা। আপনি যদি ফুটফল ট্র্যাক করতে, ডওয়েল টাইম পরিমাপ করতে, বা হিটম্যাপ তৈরি করতে WiFi অ্যানালিটিক্স ব্যবহার করেন, তবে আপনি লোকেশন ডেটা প্রসেস করছেন। এমনকি এটি আপনার ড্যাশবোর্ডে একত্রিত অবস্থায় থাকলেও, একটি পৃথক ডিভাইস থেকে প্রাথমিক সংগ্রহটি ব্যক্তিগত ডেটা হিসেবে গণ্য হয়। এর জন্য আপনার গোপনীয়তার নোটিশে স্পষ্ট প্রকাশ এবং অনেক ক্ষেত্রে, স্পষ্ট সম্মতির প্রয়োজন হয়। চতুর্থত: ব্যবহারের ডেটা। ব্রাউজিং আচরণ, অ্যাপ্লিকেশন ব্যবহারের ধরণ, ব্যান্ডউইথ ব্যবহার। আপনি যদি ট্রাফিক কন্টেন্ট পরিদর্শন বা লগিং করেন, তবে আপনার একটি অত্যন্ত স্পষ্ট আইনি ভিত্তি এবং সেই ডেটার চারপাশে শক্তিশালী নিরাপত্তা নিয়ন্ত্রণের প্রয়োজন। নেটওয়ার্ক আর্কিটেকচারের দৃষ্টিকোণ থেকে, সেগমেন্টেশন কোনোভাবেই আপোসযোগ্য নয়। আপনার গেস্ট WiFi ট্রাফিক অবশ্যই একটি ডেডিকেটেড VLAN - একটি ভার্চুয়াল লোকাল এরিয়া নেটওয়ার্ক - এর মধ্যে আইসোলেটেড থাকতে হবে যা আপনার কর্পোরেট নেটওয়ার্ক থেকে সম্পূর্ণ আলাদা। গেস্ট ডিভাইসগুলোকে যেকোনো অভ্যন্তরীণ সাবনেটে অ্যাক্সেস করা থেকে ব্লক করতে অ্যাক্সেস কন্ট্রোল লিস্ট ব্যবহার করুন। ক্লায়েন্ট আইসোলেশন সক্রিয় করুন যাতে গেস্ট ডিভাইসগুলো একে অপরের সাথে যোগাযোগ করতে না পারে। এটি কেবল একটি GDPR প্রয়োজনীয়তা নয়; এটি বেসিক নিরাপত্তা স্বাস্থ্যবিধি। অথেনটিকেশনের জন্য, আপনার ওয়্যারলেস LAN কন্ট্রোলারকে একটি ক্লাউড RADIUS সার্ভারের সাথে ইন্টিগ্রেট করুন। রিমোট অথেনটিকেশন ডায়াল-ইন ইউজার সার্ভিস - RADIUS - হলো এমন একটি প্রোটোকল যা এন্টারপ্রাইজ নেটওয়ার্কে অথেনটিকেশন, অথোরাইজেশন এবং অ্যাকাউন্টিং পরিচালনা করে। যখন একজন ব্যবহারকারী Captive Portal ফ্লো সম্পন্ন করেন, তখন প্ল্যাটফর্মটি কন্ট্রোলারে একটি RADIUS Access-Accept বার্তা পাঠায়, যা অ্যাক্সেস মঞ্জুর করে। এটি অথেনটিকেশন লেয়ার এবং ডেটা সংগ্রহ লেয়ারের মধ্যে একটি পরিষ্কার বিভাজন তৈরি করে। এনক্রিপশনের ক্ষেত্রে: আপনার হার্ডওয়্যার সমর্থন করলে আপনার গেস্ট SSID-এ WPA3 ব্যবহার করা উচিত। WPA3 সিমুলটেনিয়াস অথেনটিকেশন অফ ইকুয়ালস ব্যবহার করে, যা WPA2-এর ফোর-ওয়ে হ্যান্ডশেকে উপস্থিত দুর্বলতাগুলোকে দূর করে। সর্বনিম্ন হিসেবে, AES এনক্রিপশন সহ WPA2 প্রয়োগ করুন। এবং আপনার Captive Portal অবশ্যই একটি বৈধ TLS সার্টিফিকেট সহ HTTPS-এর মাধ্যমে পরিবেশন করা উচিত। HTTP-এর মাধ্যমে ব্যক্তিগত ডেটা সংগ্রহ করে এমন একটি ফর্ম পরিবেশন করা একটি গুরুতর নিরাপত্তা ব্যর্থতা। Purple-এর প্ল্যাটফর্ম Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme এবং Fortinet হার্ডওয়্যারে কাজ করে। সেই হার্ডওয়্যার-অ্যাগনস্টিক পদ্ধতির অর্থ হলো আপনার ছাদে কোন অ্যাক্সেস পয়েন্ট আছে তা বিবেচনা না করেই আপনি সামঞ্জস্যপূর্ণ কমপ্লায়েন্স নিয়ন্ত্রণ প্রয়োগ করতে পারেন। আসুন ডেটা রিটেনশনে চলে যাই, কারণ এখানেই সংস্থাগুলো সময়ের সাথে সাথে নীরবে ঝুঁকি জমা করে। GDPR-এর স্টোরেজ সীমাবদ্ধতার নীতি - Article 5(1)(e) - অনুযায়ী ব্যক্তিগত ডেটা যে উদ্দেশ্যে সংগ্রহ করা হয়েছিল তার চেয়ে বেশি সময় রাখা যাবে না। একটি সমর্থনযোগ্য বেসলাইন এইরকম দেখায়। সেশন লগ - IP addresses, MAC addresses, সংযোগের টাইমস্ট্যাম্প - ৩০ দিন পর মুছে ফেলা উচিত। নেটওয়ার্ক নিরাপত্তা লগ ১২ মাস পর্যন্ত সংরক্ষণ করা যেতে পারে। সম্মতি রেকর্ডগুলি পরিষেবা সম্পর্কের সময়কাল এবং সাধারণত শেষ ইন্টারঅ্যাকশনের পর দুই বছর পর্যন্ত রাখা আবশ্যক। মার্কেটিং প্রোফাইলগুলি কেবল ততক্ষণ পর্যন্ত সংরক্ষণ করা উচিত যতক্ষণ ব্যবহারকারীর সম্মতি বৈধ থাকে। একজন ব্যবহারকারী সম্মতি প্রত্যাহার করার মুহূর্তেই তাদের মার্কেটিং প্রোফাইল মুছে ফেলতে হবে। আর্কাইভ করা যাবে না। মুছে ফেলতে হবে। চ্যালেঞ্জটি হলো এই নীতিগুলি স্কেলে প্রয়োগ করা। আপনি যদি কয়েক ডজন বা শত শত ভেন্যু জুড়ে গেস্ট WiFi পরিচালনা করেন, তবে ম্যানুয়ালি ডেটা মুছে ফেলা সম্ভব নয়। আপনার এমন একটি প্ল্যাটফর্ম প্রয়োজন যা ধারণ নীতি প্রয়োগ স্বয়ংক্রিয় করে। Purple প্রতিটি ডেটা ক্যাটাগরির জন্য কাস্টমাইজযোগ্য রিটেনশন নিয়ম প্রয়োগ করে, যখন রেকর্ডগুলি তাদের রিটেনশন মেয়াদের শেষে পৌঁছায় তখন সেগুলি স্বয়ংক্রিয়ভাবে মুছে ফেলে। ৮০,০০০ লাইভ ভেন্যু এবং ৩৫০ মিলিয়ন অনন্য ব্যবহারকারী জুড়ে, স্কেলে সম্মতি বজায় রাখার একমাত্র উপায় হলো এই অটোমেশন। এখন আমি আপনাকে দুটি বাস্তব-জগতের সিনারিও সম্পর্কে জানাবো যেখানে এই নীতিগুলি একসাথে কাজ করে। সিনারিও এক: একটি ২০০-রুমের হোটেল। প্রোপার্টি টিম লয়্যালটি প্রোগ্রামের সাইন-আপ বাড়ানোর জন্য গেস্টদের ইমেল সংগ্রহ করতে চায়। তাদের বর্তমান সিস্টেমে অনলাইনে যাওয়ার জন্য গেস্টদের মার্কেটিং গ্রহণ করা আবশ্যক। এটি একটি স্পষ্ট GDPR লঙ্ঘন। এর সমাধানটি সহজ: আলাদা সম্মতির টিকবক্স সহ একটি কমপ্লায়েন্ট Captive Portal স্থাপন করুন। বাধ্যতামূলক টিকবক্সটি পরিষেবার শর্তাবলী কভার করে। ঐচ্ছিক, আনটিকড টিকবক্সটি মার্কেটিং সম্মতি কভার করে। বান্ডেলড পদ্ধতির তুলনায় হোটেলটি সম্ভবত মার্কেটিং অপ্ট-ইনগুলির কম র ভলিউম দেখতে পাবে - তবে তালিকার গুণমান এবং বৈধতা নাটকীয়ভাবে উন্নত হবে। যেসব গেস্ট সক্রিয়ভাবে অপ্ট-ইন করেন তারা পরবর্তী যোগাযোগের সাথে যুক্ত হওয়ার সম্ভাবনা উল্লেখযোগ্যভাবে বেশি থাকে। এবং গুরুতরভাবে, হোটেলটি আর ICO প্রয়োগকারী পদক্ষেপের ঝুঁকিতে থাকে না। সিনারিও দুই: একটি স্টেডিয়ামের IT টিম। তারা ভিড়ের ঘনত্ব নিরীক্ষণ এবং ইভেন্টগুলিতে নিরাপত্তা পরিচালনা করতে WiFi অ্যানালিটিক্স ব্যবহার করতে চায়। লিগ্যাল টিমের উদ্বেগ হলো সম্মতি ছাড়া ডিভাইসের অবস্থান ট্র্যাক করা একটি GDPR লঙ্ঘন। এর সমাধান দ্বিগুণ। প্রথমত, Captive Portal-এর গোপনীয়তা বিজ্ঞপ্তিতে স্পষ্টভাবে প্রকাশ করতে আপডেট করুন যে ভিড় ব্যবস্থাপনা এবং নিরাপত্তার উদ্দেশ্যে লোকেশন ডেটা প্রক্রিয়া করা হয়। দ্বিতীয়ত, ডেটা ক্লাউড অ্যানালিটিক্স প্ল্যাটফর্মে পৌঁছানোর আগে এজ-এ - অ্যাক্সেস পয়েন্টগুলিতেই - MAC address ছদ্মনামকরণ (pseudonymisation) প্রয়োগ করুন। এর মানে হলো অ্যানালিটিক্স সিস্টেম র MAC addresses-এর পরিবর্তে ছদ্মনামী আইডেন্টিফায়ার নিয়ে কাজ করে, যা গোপনীয়তার ঝুঁকি এবং নিয়ন্ত্রক ঝুঁকি উল্লেখযোগ্যভাবে হ্রাস করে। এখন আসুন বাস্তবায়নের ত্রুটি এবং ঝুঁকি হ্রাস নিয়ে আলোচনা করা যাক - যে বিষয়গুলি দলগুলিকে বিভ্রান্ত করে এমনকি যখন তারা মনে করে যে তারা এটি কভার করেছে। ত্রুটি এক: সম্মতি ক্লান্তি। আপনার পোর্টাল যদি খুব জটিল হয়, তবে ব্যবহারকারীরা হয় সংযোগটি ছেড়ে দেবেন বা অন্ধভাবে সবকিছুতে ক্লিক করবেন। এটি সহজ রাখুন। সহজ ভাষা ব্যবহার করুন। মূল্যের আদান-প্রদান স্পষ্টভাবে ব্যাখ্যা করুন: একটি ইমেল ঠিকানা এবং মাঝে মাঝে আপনার কাছ থেকে শোনার বিকল্পের বিনিময়ে দ্রুত, বিনামূল্যে WiFi। দ্বিতীয় সমস্যা: তথ্য অধিকারীদের (data subject) অধিকার প্রয়োগে ব্যর্থতা। GDPR-এর আর্টিকেল ১৫ থেকে ২২-এর অধীনে, ব্যবহারকারীদের তাদের ডেটা অ্যাক্সেস, সংশোধন, মুছে ফেলা এবং স্থানান্তরিত করার অধিকার রয়েছে। এর জন্য আপনার কাছে অবশ্যই একটি প্রক্রিয়া থাকতে হবে। একটি সেলফ-সার্ভিস প্রেফারেন্স সেন্টার যেখানে ব্যবহারকারীরা তাদের সম্মতি পরিচালনা করতে এবং Data Subject Access Requests - DSARs - জমা দিতে পারেন, তা হলো সর্বোত্তম মানদণ্ড। Purple-এর প্ল্যাটফর্ম ঠিক এই কাজটি সহজ করার জন্য প্রয়োজনীয় টুল সরবরাহ করে, যা ম্যানুয়াল হস্তক্ষেপ ছাড়াই DSARs-এর উত্তর দেওয়া সহজ করে তোলে। তৃতীয় সমস্যা: স্বাক্ষরবিহীন ভেন্ডর চুক্তি। আপনার গেস্ট WiFi প্ল্যাটফর্ম প্রদানকারী একজন ডেটা প্রসেসর (Data Processor)। তাদের কাছে কোনো ব্যক্তিগত ডেটা স্থানান্তরিত হওয়ার আগে, আপনার অবশ্যই একটি স্বাক্ষরিত ডেটা প্রসেসিং অ্যাডেন্ডাম (Data Processing Addendum) থাকতে হবে। এটি আপনার WiFi অ্যানালিটিক্স প্রদানকারী, আপনার CRM এবং আপনার ইমেল মার্কেটিং প্ল্যাটফর্মের ক্ষেত্রে প্রযোজ্য। কোনো DPA না থাকলে, কোনো ডেটা শেয়ার করা যাবে না। চতুর্থ সমস্যা: কোনো ডেটা ব্রিচ রেসপন্স প্ল্যান না থাকা। GDPR-এর আর্টিকেল ৩৩-এর অধীনে, আপনি ব্যক্তিগত ডেটা লঙ্ঘনের বিষয়ে জানতে পারার মুহূর্ত থেকেই ৭২ ঘণ্টার নোটিফিকেশন ক্লক চালু হয়ে যায়। আপনার তদন্ত সম্পূর্ণ না হলেও আপনাকে ৭২ ঘণ্টার মধ্যে ICO-কে অবহিত করতে হবে। এই সময়সীমাটি এখনই আপনার ইনসিডেন্ট রেসপন্স প্ল্যানের অন্তর্ভুক্ত করুন, এটি প্রয়োজন হওয়ার আগেই। ঠিক আছে - এবার কিছু দ্রুত প্রশ্নোত্তর। এগুলো হলো সেই প্রশ্ন যা আমরা সবচেয়ে বেশি পেয়ে থাকি। আমরা যদি কেবল অ্যানালিটিক্সের জন্য MAC অ্যাড্রেস সংগ্রহ করি, তবে কি আমাদের সম্মতির প্রয়োজন আছে? হ্যাঁ। যদি সেই অ্যানালিটিক্স কোনো ডিভাইস এবং তার ব্যবহারকারীর আচরণের সাথে যুক্ত করা যায়, তবে সেটি ব্যক্তিগত ডেটা হিসেবে গণ্য হয়। আপনার হয় স্পষ্ট সম্মতি প্রয়োজন, অথবা একটি শক্তিশালী অ্যানোনিমাইজেশন প্রক্রিয়া প্রয়োজন যা সংগ্রহের সাথে সাথেই কার্যকর হয়। সোশ্যাল মিডিয়া লগইন কি GDPR অনুগত? এটি হতে পারে, তবে সোশ্যাল প্ল্যাটফর্ম থেকে আপনি কী ডেটা পাচ্ছেন সে সম্পর্কে আপনাকে স্বচ্ছ হতে হবে এবং প্রাথমিক অথেন্টিকেশনের বাইরে সেই ডেটার যেকোনো ব্যবহারের জন্য আপনাকে আলাদা সম্মতি নিতে হবে। আমরা একটি ছোট ভেন্যু হলেও কি GDPR প্রযোজ্য হবে? হ্যাঁ। প্রতিষ্ঠানের আকার নির্বিশেষে GDPR প্রযোজ্য। ICO-এর কাছে একটিমাত্র অভিযোগই একটি তদন্ত শুরু করতে পারে। যেকোনো জরিমানার পরিমাণ আপনার আকারের সাথে আনুপাতিক হতে পারে, তবে তা মেনে চলার বাধ্যবাধকতা সম্পূর্ণ। আমাদের কি একটি Data Protection Impact Assessment প্রয়োজন? যদি আপনার গেস্ট WiFi স্থাপনায় বড় আকারের লোকেশন ট্র্যাকিং, আচরণগত প্রোফাইলিং বা সংবেদনশীল গোষ্ঠীগুলির ডেটা প্রসেসিং জড়িত থাকে, তবে GDPR আর্টিকেল ৩৫-এর অধীনে একটি DPIA আইনত বাধ্যতামূলক। এমনকি এটি যেখানে বাধ্যতামূলক নয়, সেখানেও এটি করা একটি ভালো অনুশীলন এবং এটি নিয়ন্ত্রক সংস্থার কাছে আপনার জবাবদিহিতা প্রদর্শন করে। আপনার পরবর্তী পদক্ষেপগুলির মাধ্যমে আমি শেষ করতে চাই। চারটি পদক্ষেপ যা আপনি এই সপ্তাহে নিতে পারেন। এক: আপনার বর্তমান Captive Portal অডিট করুন। মার্কেটিং সম্মতি নেটওয়ার্ক অ্যাক্সেসের শর্তাবলীর সাথে যুক্ত করা আছে কিনা তা পরীক্ষা করুন। যদি থেকে থাকে, আপনার পরবর্তী ICO অডিটের আগেই এটি সংশোধন করুন। দুই: আপনার ডেটা রিটেনশন সেটিংস পর্যালোচনা করুন। আপনার যদি স্বয়ংক্রিয়ভাবে ডেটা মুছে ফেলার পলিসি না থাকে, তবে প্রতি দিন পার হওয়ার সাথে সাথে আপনি ঝুঁকি বাড়াচ্ছেন। তিন: আপনার ভেন্ডর চুক্তিগুলি পরীক্ষা করুন। আপনার পক্ষে গেস্ট ডেটা প্রসেস করে এমন প্রতিটি থার্ড-পার্টি প্ল্যাটফর্মের সাথে আপনার একটি স্বাক্ষরিত ডেটা প্রসেসিং অ্যাডেন্ডাম (Data Processing Addendum) রয়েছে কিনা তা নিশ্চিত করুন। চার: একটি প্রেফারেন্স সেন্টার বা পছন্দ নির্ধারণ কেন্দ্র চালু করুন। আপনার অতিথিদের নিজেদের সম্মতি পরিচালনা করার এবং ডেটা সাবজেক্ট অ্যাক্সেস রিকোয়েস্ট (DSAR) জমা দেওয়ার একটি সেলফ-সার্ভিস উপায় প্রদান করুন। এটি ম্যানুয়ালি DSAR পরিচালনা করার কার্যগত ঝামেলা নাটকীয়ভাবে হ্রাস করে। Purple-এর ISO 27001 সার্টিফিকেশন রয়েছে, এটি GDPR এবং CCPA সম্মত এবং বিশ্বজুড়ে ৮০,০০০ ভেন্যুতে কাজ করে। আমরা শুধুমাত্র ২০২৪ সালেই ৪৪০ মিলিয়ন লগইন প্রসেস করেছি এবং ২৯ বিলিয়ন ডেটা পয়েন্ট সংগ্রহ করেছি - যা সবই ভেন্যু এবং তাদের ভিজিটর উভয়কেই সুরক্ষিত রাখার জন্য ডিজাইন করা একটি কমপ্লায়েন্স আর্কিটেকচারের অধীনে করা হয়েছে। আমাদের প্ল্যাটফর্ম সম্মতি লগিং, ডেটা রিটেনশন কার্যকর করা এবং DSAR ম্যানেজমেন্ট অটোমেট করে, যাতে আপনি কমপ্লায়েন্স স্প্রেডশীট পরিচালনা করার পরিবর্তে আপনার নেটওয়ার্ক চালানোর দিকে মনোযোগ দিতে পারেন। এই Purple টেকনিক্যাল ব্রিফিংয়ে যোগ দেওয়ার জন্য আপনাকে ধন্যবাদ। গেস্ট WiFi কমপ্লায়েন্স সংক্রান্ত আরও রিসোর্সের জন্য, purple.ai ভিজিট করুন। কমপ্লায়েন্ট থাকুন এবং সুরক্ষিত থাকুন।