মুছে ফেলা ও অডিটের জন্য ডেটা রিটেনশন লিগ্যাল হোল ওয়ার্কফ্লো

প্রকৃত সমস্যা: সময়মতো মুছে ফেলুন, তবুও অডিটে উত্তীর্ণ হন

অধিকাংশ টিম একমত যে অনাবশ্যক হলে ডেটা মুছে ফেলা উচিত। এতে ঝুঁকি কমে, স্টোরেজ কমে এবং গোপনীয়তা নিয়ম মেনে চলা সহজ হয়। সমস্যা দেখা দেয় যখন কেউ প্রশ্ন করে, “আপনি কী প্রমাণ করতে পারবেন কী ঘটেছিল?” সেই প্রশ্ন আসতে পারে অডিটর, গ্রাহক অভিযোগ বা মামলায়।

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

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

“প্রমাণ রাখা” সবসময় পুরো ডেটা সখ্যা রেখে দেয়া নয়। প্রায়ই এর মানে হল এমন ছোট, নিরাপদ প্রমাণ রেখে দেওয়া যা অডিট সমর্থন করে কিন্তু মূল ব্যক্তিগত ডেটা পুনরায় তৈরি করে না। উদাহরণস্বরূপ, আপনি রাখতে পারেন:

• টাইমস্ট্যাম্পযুক্ত লগ যা দেখায় একটি রেকর্ড তৈরি, পরিবর্তন, অ্যাক্সেস বা মুছে ফেলা হয়েছে
• সেই সময় যে রিটেনশন রুলটি প্রয়োগ ছিল তা এবং কে অনুমোদন করেছে তা
• কী মুছে ফেলা হয়েছে এবং কখন তা দেখানো একটি ডিলিশন জব রিপোর্ট
• সংবেদনশীলতা ব্যতীত আইডেন্টিফায়ার্স বা হ্যাশ যা কনটেন্ট না দেখিয়েই ইন্টেগ্রিটি নিশ্চিত করে
• লিগ্যাল হোল নোটিশ, স্কোপ এবং রিলিজের তারিখ

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

এই নির্দেশিকা অপারেশনাল; আইনি পরামর্শ নয়। রিটেনশন পিরিয়ড এবং হোল ট্রিগারগুলোকে আপনার কেয়ারিং কনসাল্ট্যান্টদের সঙ্গে পর্যালোচনা করে শিল্প-বিধির সাথে মিলিয়ে নিন।

আপনার কাছে কী ডেটা আছে এবং কোথায় আছে তা ম্যাপ করুন

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

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

একটি সহজ উপায় হল প্রতিটি ডেটাসেট লিখে সেটা সম্পর্কে তিনটি প্রশ্নের উত্তর দেওয়া: এটি কোথায় তৈরি হয়, কোথায় কপি করা হয়, এবং কে এটি মুছতে পারে।

কোনগুলো ইনভেন্টরি করবেন (ছোট কিন্তু সম্পূর্ণ)

আপাতত সেই উৎসগুলোর উপর ফোকাস করুন যেগুলো পরে বিস্ময় সৃষ্টি করে:

• কাস্টমার ও অ্যাকাউন্ট ডেটা (প্রোফাইল, অর্ডার, বিলিং বিবরণ)
• ফাইল ও মেসেজ (আপলোড, অ্যাটাচমেন্ট, ইমেইল ও চ্যাট প্রতিলিপি)
• লগ ও ইভেন্ট (অ্যাপ লগ, অ্যাক্সেস লগ, অডিট লগ)
• ব্যাকআপ ও স্ন্যাপশট (স্বয়ংক্রিয় ব্যাকআপ, ধরে রাখা ডাটাবেস ডাম্প)
• পার্শ্ব কপি (এক্সপোর্ট, লোকাল ফাইল, শেয়ার্ড ড্রাইভ)

ওয়ার্কফ্লো-এর স্কোপ কী হবে তা নির্ধারণ করুন

প্রতিটি জায়গায় একসঙ্গে এক মতাভিন্ন আচরণ দরকার নয়। নির্ধারণ করুন ওয়ার্কফ্লো এখন কী কভার করে এবং পরে কী যোগ করা হবে।

একটি ব্যবহারিক প্রথম স্কোপ সাধারণত সেই সিস্টেমগুলোকে অন্তর্ভুক্ত করে যা আপনি নিয়ন্ত্রণ করেন (যেখানে আপনি সময়মতো মুছে ফেলতে পারেন), সেই সিস্টেমগুলো যেগুলোকে লিগ্যাল হোলে খোঁজা হবে, এবং সেই সিস্টেমগুলো যেগুলো ডিলিশনের পরে কেবলমাত্র অডিট প্রমাণ রাখে।

কোনটি আউট-অফ-স্কোপ তাও লিখে রাখুন (উদাহরণ: ল্যাপটপে ব্যক্তি-স্বত্বাভিমুখ নোট)। সেই ফাঁকগুলোঠাই থেকে সাধারণত “সবকিছু চিরকাল রাখি” মনোভাব শুরু হয়।

প্রধান শব্দাবলি (লোকেরা রূপে ব্যবহৃতভাবে)

ভুল বোঝাবুঝি প্রায়ই আসে যখন একেই শব্দ বিভিন্ন অর্থে ব্যবহার করা হয়। আগে থেকেই সংজ্ঞায় একমত হন যাতে ওয়ার্কফ্লো চালানো এবং রক্ষা করা সহজ হয়।

রিটেনশন বনাম ডিলিশন সময়সূচি

রিটেনশন সময়সূচি একটি প্রশ্নের উত্তর দেয়: প্রতিটি ডেটা টাইপ কতক্ষণ রাখবো? এটি সাধারণত আইন, চুক্তি বা ব্যবসায়িক প্রয়োজন অনুযায়ী নির্ধারিত। এটি স্পষ্ট হওয়া উচিত (উদাহরণ: সাপোর্ট টিকেট ২ বছর, ইনভয়েস ৭ বছর, অ্যাপ্লিকেশনের লগ ৩০ দিন)।

ডিলিশন সময়সূচি হল এক্সিকিউশন প্ল্যান। এটি উত্তর দেয়: কখন ডিলিশন হবে এবং কীভাবে চলবে? কিছু টিম নাইটলি ব্যাচে মুছে ফেলে, অন্যরা রোলিং ভিত্তিতে মুছে ফেলে, এবং অনেকেই ইভেন্ট-ভিত্তিক ডিলিশন ব্যবহার করে (যেমন “অ্যাকাউন্ট ক্লোজের ৩০ দিন পরে”)। রিটেনশন সময়সূচি হল নিয়ম; ডিলিশন সময়সূচি হল সেই নিয়ম প্রয়োগের রুটিন।

লিগ্যাল হোল এবং অডিট প্রয়োজনীয়তা

লিগ্যাল হোল হল একটি নির্দিষ্ট মামলা, অভিযোগ, তদন্ত বা মামলা সম্পর্কিত মুছে ফেলা স্থগিত করার একটি টার্গেটেড পদ্ধতি। এটি স্কোপ (কোন ব্যক্তি, অ্যাকাউন্ট, সিস্টেম বা তারিখ সীমা প্রযোজ্য) এবং মালিকানা (কে অনুমোদন করেছে) অন্তর্ভুক্ত করে। লিগ্যাল হোল মানে সব জায়গায় মুছে ফেলা বন্ধ করা নয়; বরং শুধু প্রভাবিত রেকর্ডগুলোর জন্য মুছে ফেলা থামানো।

অডিট প্রয়োজনীয়তা হল যা আপনাকে পরে দেখাতে হবে: কে কী করেছে, কখন হয়েছে, এবং কেন তা অনুমোদিত ছিল। অডিট সাধারণত প্রতিটি রেকর্ড চিরকাল রাখার চেয়ে একটি নিয়ন্ত্রিত, ধারাবাহিক প্রক্রিয়ার প্রমাণ দেখতে বেশি আগ্রহী।

ভাষাটি সহজ রাখুন:

• রিটেনশন সময়সূচি: প্রতিটি ডেটা টাইপের জন্য অনুমোদিত সংরক্ষণকাল
• ডিলিশন সময়সূচি: ট্রিগার এবং পদ্ধতি যা সময়মতো ডেটা মুছে দেয়
• লিগ্যাল হোল: কেস ভিত্তিক ব্যতিক্রম যা নির্দিষ্ট রেকর্ডের মুছে ফেলা সাময়িকভাবে ব্লক করে
• অডিট প্রমাণ: অনুমোদন, টাইমস্ট্যাম্প, স্কোপ, কারণ—সেই মেটাডেটা যা সিদ্ধান্ত ও কার্যক্রম প্রমাণ করে

এমন একটি রিটেনশন সময়সূচি তৈরি করুন যাকে মানুষ বাস্তবে অনুসরণ করতে পারে

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

ডেটা গ্রুপ করুন ব্যবসায়িক উদ্দেশ্যে অনুযায়ী, সিস্টেমের অবস্থানের উপর নয়। “ইনভয়েস” একটি স্পষ্ট ক্যাটেগরি, “টেবিল X-এর সারি” থেকে। ক্যাটেগরিগুলোর সংখ্যা সীমিত রাখুন যাতে ব্যস্ত কেউ দ্রুত স্ক্যান করতে পারে।

মালিকানা স্পষ্ট করুন। ফাইন্যান্স অনুমান করবে না সাপোর্টকে কি দরকার, সাপোর্ট HR নিয়ম নির্ধারণ করবে না। প্রতিটি ক্যাটেগরির জন্য একটি মালিক দিন যিনি পরিবর্তন অনুমোদন করবেন এবং প্রশ্নের উত্তর দেবেন।

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

অবশেষে, ব্যতিক্রমগুলো স্পষ্টভাবে লিখুন। এগুলোই মুছে ফেলা থামায়: বিবাদ, চার্জব্যাক, তদন্ত, এবং অ্যাক্টিভ লিগ্যাল হোল। যদি ব্যতিক্রম অস্পষ্ট হয়, মানুষ সবকিছুই ব্যতিক্রম ভাববে।

এই সহজ টেবিল ফর্ম্যাট অনেক টিম বাস্তবে ব্যবহার করে:

ধাপে ধাপে: ডিলিশন + লিগাল হোল ওয়ার্কফ্লো

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

কাজ করা একটি সাপ্তাহিক ক্রমানুসারে

1. রিটেনশন রুল তৈরি বা আপডেট করুন (মালিক সহ)। ডেটাসেট, কারণ (চুক্তি, কর, সাপোর্ট) এবং রিটেনশন পিরিয়ড নির্ধারণ করুন। কে অনুমোদন করেছে এবং কার্যকর তারিখ ক্যাপচার করুন।

2. নির্দিষ্ট স্কোপসহ ডিলিশন জব চালান। রুলগুলোকে স্বয়ংক্রিয় জবে রূপান্তর করুন যা নির্দিষ্ট ফিল্ড, টেবিল, ফাইল এবং সার্চ ইনডেক্স ডিলিট বা অ্যানোনিমাইজ করে। আপনার সংস্থায় “মুছে ফেলা” মানে কি (হার্ড ডিলিট, সফট ডিলিট বা অপরিবর্তনীয় অ্যানোনিমাইজেশন) এবং কোন সিস্টেম অন্তর্ভুক্ত তা স্পষ্ট করুন।

3. লিগ্যাল হোল লাগান (শুধু প্রাসঙ্গিক অংশ ফ্রিজ করুন)। কোনো বিবাদ, তদন্ত বা রেগুলেটর অনুরোধ এলে একটি হোল রেকর্ড তৈরি করুন যা একটি ব্যক্তি, অ্যাকাউন্ট, কেস আইডি, তারিখ পরিসীমা এবং ডেটা টাইপ টার্গেট করে। ডিলিশন জবকে কেবল মিল থাকা রেকর্ডগুলোই স্কিপ করতে হবে, পুরো ডাটাবেস নয়।

4. হোল মুক্ত করুন (তারপর নিরাপদে ডিলিশন আবার চালান)। লিগ্যাল নিশ্চিত করলে হোল শেষ চিহ্নিত করুন। ডিলিশন আবার চালানোর আগে স্কোপ সঠিক কিনা এবং কোনো নতুন হোল ওভারল্যাপ নেই কি না তা নিশ্চিত করুন।

5. প্রতিটি কর্ম লগ করুন। রিটেনশন পরিবর্তন, ডিলিশন রান, হোল বসানো, হোল মুক্ত করা এবং ম্যানুয়াল ব্যতিক্রম সবই লগ করুন। প্রতিটি এন্ট্রি-তে টাইমস্ট্যাম্প, অভিনেতা, অনুমোদনকারী, স্কোপ এবং আউটকাম (সফল বা ব্যর্থ) থাকা উচিত।

অনুমোদনই যেখানে ওয়ার্কফ্লো সাধারণত ভেঙে যায়। ভূমিকা পরিষ্কার রাখুন:

• ডেটা ওনার রিটেনশন রুল প্রস্তাব বা আপডেট করে
• লিগ্যাল/কমপ্লায়েন্স রুল ও সব লিগাল হোল অনুমোদন করে
• সিকিউরিটি/IT ডিলিশন পদ্ধতি নিশ্চিত করে এবং ব্যর্থতা মনিটর করে
• অপারেশনস নিয়মিত চেক চালায় এবং ব্যতিক্রমগুলো এলেভেট করে

উদাহরণ: একটি সাপোর্ট ম্যানেজার চ্যাট ট্রান্সক্রিপ্টের রিটেনশন ২৪ মাস থেকে ১২ মাসে বদলানোর সিদ্ধান্ত নেন অনুমোদনের পরে। সাপ্তাহিক ডিলিশন জব ১২ মাসের বেশি পুরনো ট্রান্সক্রিপ্টগুলো মুছে দেয়। দুই মাস পরে লিগ্যাল একজন গ্রাহকের বিরুদ্ধে বিবাদে হোল বসায়, তাই কেবল ওই গ্রাহকের ট্রান্সক্রিপ্টগুলো ফ্রিজ হয়; বাকিরা নির্ধারিত সময়মতো মুছে যায়।

কিভাবে লিগ্যাল হোল সবকিছু ফ্রিজ না করেই কাজ করে

একটি লিগাল হোল কেবল প্রাসঙ্গিক রেকর্ডগুলোই থামানো উচিত, নির্দিষ্ট সময় পর্যন্ত। যদি হোল হয়ে যায় “সবকিছুই থামান”, আপনি খরচ, ঝুঁকি এবং বিভ্রান্তি তৈরি করেন।

স্কোপ দিয়ে শুরু করুন। একটি হোল নির্দিষ্ট ব্যবহারকারী, অর্ডার, সাপোর্ট টিকেট, প্রকল্প, মেইলবক্স, ফোল্ডার বা তারিখ পরিসীমায় সীমাবদ্ধ হতে পারে যেমন “মার্চ ১ থেকে এপ্রিল ১৫ পর্যন্ত মেসেজ”। যত সংকীর্ণ স্কোপ হবে, তত সহজে রক্ষা করা যাবে এবং তত কম ডেটা রাখতে হবে।

আকস্মিক মুছে ফেলা প্রতিরোধ করতে হোল মেশিন-পঠনযোগ্য করুন। সাধারণত এর মানে প্রতিটি রেকর্ডে একটি হোল ফ্ল্যাগ এবং হোল আইডি রাখা (বা কেস বা অর্ডার অবজেক্টে) যাতে ডিলিশন জবের একটি কঠিন নিয়ম থাকে: যদি HoldActive = true হয় তবে ডিলিশন স্কিপ করুন এবং লগ করুন যে এটি হোলের কারণে স্কিপ হয়েছে।

হোল শুরু হওয়ার পরে নতুন ডেটা একটি সাধারণ ফাঁদ। শুরুতেই সিদ্ধান্ত নিন হোলটি হবে:

• স্ট্যাটিক: কেবল ইতিমধ্যে বিদ্যমান আইটেমগুলো
• অনগোয়িং: স্কোপ মিলে নতুন আইটেমও অন্তর্ভুক্ত

বিবাদের ক্ষেত্রে, অনগোয়িং হোল প্রায়ই নিরাপদ—উদাহরণ: “কেস চলতে থাকা অবস্থায় গ্রাহক X-এর নতুন টিকেটগুলিও”।

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

হোল ডকুমেন্ট করার সময় যথেষ্ট লিখুন “কেন” বোঝানোর জন্য কিন্তু অতিরিক্ত তথ্য শেয়ার করবেন না। সংক্ষিপ্ত রাখুন: অনুরোধকারী, তারিখ, স্কোপ এবং সাদাসিধে কারণ যেমন “বিলিং বিবাদ” বা “চাকরির দাবি”।

অডিট প্রমাণ: ডেটা মুছে ফেলার পর কী রাখা উচিত

অডিটর সাধারণত মুছে ফেলা ডেটা নিজেই চান না। তারা প্রমাণ চান যে আপনার প্রক্রিয়া নিয়ন্ত্রিত ছিল: কে সিদ্ধান্ত নিয়েছে, কী মুছে ফেলা হয়েছে, কখন হয়েছে এবং কেন তা অনুমোদিত ছিল।

ডিলিশন ইভেন্টগুলোকে আর্থিক লেনদেনের মতো লগ করুন। রেকর্ডটি কয়েক মাস পরে এমন প্রশ্নেও বোধগম্য থাকা উচিত, এমনকি টিমে না থাকা কাউকে দেখালেও।

প্রতিটি ডিলিশন (বা অ্যানোনিমাইজেশন) ইভেন্টের জন্য মৌলিক বিষয়গুলো ক্যাপচার করুন:

• নেওয়া পদক্ষেপ (delete, anonymize, archive, restore)
• অভিনেতা (ব্যবহারকারী, সার্ভিস অ্যাকাউন্ট, স্বয়ংক্রিয় জব নাম)
• টাইমস্ট্যাম্প একটি সঙ্গত টাইমজোনে
• কী প্রভাবিত হয়েছে (রেকর্ড টাইপ, কী বা আইডি, এবং গণনা)
• কারণ (রিটেনশন রুল নাম, রিকোয়েস্ট আইডি, টিকেট নম্বর, বা হোল রিলিজ রেফারেন্স)

অপারেশনাল প্রমাণও রাখুন যে জব রান করেছে এবং সম্পন্ন হয়েছে, কন্টেন্ট না রেখে:

• জব রান আইডি এবং স্ট্যাটাস (শুরু, সম্পন্ন, ব্যর্থ)
• গণনা: সিলেক্টেড ফর ডিলিট বনাম আসলে মুছে ফেলা হয়েছে
• ত্রুটি সারাংশ এবং পুনরায় চেষ্টা (যদি থাকে)
• মেটাডেটার কেবল আগে/পরে স্ন্যাপশট (উদাহরণ: টেবিল বা ক্যাটেগরির দ্বারা গণনা)

“ব্যাকআপে কপি রেখে দিন” মানসিকতা এড়াতে পুরো রেকর্ড অডিট ডাটাবেসে কপি না করুন। সেটি একটি দ্বিতীয় সিস্টেম তৈরি করে যাকে আপনাকেও মুছে যেতে হবে।

অডিট লগগুলোর জন্য একটি স্পষ্ট রিটেনশন পিরিয়ড ও অ্যাক্সেস নিয়ম রাখুন। অনেক টিম বিস্তারিত লগ ১২ থেকে ২৪ মাস রাখে, তারপর প্রয়োজনে একটি ছোট মাসিক সারাংশ বেশি সময় রেখে দেয়। অ্যাক্সেস সীমাবদ্ধ রাখুন (সিকিউরিটি, কমপ্লায়েন্স এবং কয়েকজন অ্যাডমিন) এবং লগের অ্যাক্সেসও লগ করুন।

অডিট সহজ করতে, কয়েকটি সরল রিপোর্ট প্রস্তুত করুন যা দ্রুত তৈরি করা যায়: একটি মাসিক ডিলিশন সারাংশ, একটি ব্যতিক্রম তালিকা (অ্যাকটিভ হোল, ব্লকড জব, অনসোলভড ব্যর্থতা), এবং শীর্ষ ডিলিশন কারণের ব্রেকডাউন।

উদাহরণ: যদি জুলাই মাসে ১,২৪০টি ক্লোজড অ্যাকাউন্ট মুছে ফেলা হয়, আপনার প্রমাণ হতে পারে একটি জব রান রেকর্ড যা দেখায় কে রান অনুমোদন করেছে, ব্যবহৃত রিটেনশন রুল, গণনা, কমপ্লিশন স্ট্যাটাস, এবং ১২টি অ্যাকাউন্টের ব্যতিক্রম তালিকা যেগুলো অ্যাকটিভ লিগ্যাল হোলের কারণে ব্লক ছিল।

সাধারণ ভুলভ্রান্তি যা “সবকিছু চিরকাল রাখার” কারণ হয়

অধিকাংশ রিটেনশন প্রোগ্রাম ব্যর্থ হয় একটি কারণে: যখন কিছু ঝুঁকিপূর্ণ মনে হয়, মানুষ মুছে ফেলা বন্ধ করে দেয়। তারপর “অস্থায়ী” ব্যতিক্রমগুলো জমে যায় যতক্ষণ না কিছুই আর যায় না।

একটি বড় ব্লাইন্ড স্পট হল ব্যাকআপ, রেপ্লিকা এবং আর্কাইভ স্টোরেজ। টিমগুলো প্রধান রেকর্ড মুছে ফেলে কিন্তু স্ন্যাপশট বা রিড রেপ্লিকায় পুরোনো কপি ভুলে যায়। আপনার নীতিতে স্পষ্ট করুন “মুছে ফেলা” মানে কী: প্রায়শই এর মানে হলো প্রডাকশন কপি দ্রুত মুছে ফেলা এবং ব্যাকআপগুলো আলাদা, নির্দিষ্ট টাইমলাইন অনুসারে পুরোনো হয়ে যাওয়া।

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

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

এক্সপোর্ট হল নীরব রিটেনশন কিলার। আপনি অ্যাপে ডেটা মুছে ফেলতে পারেন এবং তবুও তা চিরকাল স্প্রেডশীট, ইমেইল অ্যাটাচমেন্ট, শেয়ারড ড্রাইভ বা অ্যাড-হক BI এক্সট্র্যাক্টে বেঁচে থাকতে পারে।

কয়েকটি ব্যবহারিক সমাধান “সব কিছু রাখা” আচরণ রোধ করে:

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

লগিং একটি ভারসাম্যহীন কাজ: কম হলে আপনি প্রক্রিয়া প্রমাণ করতে পারবেন না; বেশি হলে আপনার লগই নিজেই একটি নতুন গোপনীয়তা সমস্যা হয়ে দাঁড়াবে।

নির্ভর করার আগে দ্রুত চেকলিস্ট

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

প্রক্রিয়াটি ব্যবহার করবে এমন লোকজন (লিগ্যাল, সিকিউরিটি, IT, এবং ডেটার ব্যবসায়িক মালিক) নিয়ে একটি ছোট টেবিলটপ অনুশীলন চালান।

পাঁচটি চেক যা বেশিরভাগ ব্যর্থতা ধরবে

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

যদি কোনো আইটেম উত্তর দিতে কষ্ট হয়, নিয়মিতভাবে কড়া করে নিন আগে এটি রেগুলেটর, অডিটর বা কোর্ট দ্বারা পরীক্ষিত হওয়ার আগে।

একটি ব্যবহারিক “প্রমাণ কর” ড্রিল

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

উদাহরণ দৃশ্যপট: অ্যাকাউন্ট ক্লোজ, তারপর একটি বিতর্ক

একজন গ্রাহক ১ মার্চে তাদের অ্যাকাউন্ট বন্ধ করেন। আপনার নীতি বলে: প্রোফাইল ডেটা ৩০ দিন পরে মুছে ফেলা হবে, সাপোর্ট কথোপকথন ৯০ দিন পরে মুছে যাবে, এবং ইনভয়েস ৭ বছর রাখা হবে (কর ও আর্থিক নিয়ম প্রায়শই এটি দাবি করে)।

২০ এপ্রিল একই গ্রাহক ফেব্রুয়ারির একটি ইনভয়েস নিয়ে বিলিং বিতর্ক জমা দেন। এখানে ওয়ার্কফ্লোটি স্পষ্টভাবে কাজ করা উচিত, ভয়ঙ্কর নয়।

আপনি একই সময়ে দুটি কাজ করবেন। আপনি সম্পর্কহীন সবকিছুর জন্য সাধারণ ডিলিশন চালিয়ে রাখবেন। একই সঙ্গে আপনি বিতর্ক প্রমাণ করার জন্য ছোট একটি রেকর্ড সেটে লিগ্যাল হোল বসাবেন।

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

যা আপনি প্রমাণ হিসেবে রাখবেন এবং হোল লাগাবেন:

• বিবাদের ইনভয়েস(গুলো) এবং পেমেন্ট স্ট্যাটাস
• রসিদ বা পেমেন্ট প্রসেসর রেফারেন্স
• বিবাদ সংক্রান্ত সাপোর্ট টিকেট(গুলো), অ্যাটাচমেন্টসহ
• ব্যতিক্রম হিসাবে কীভাবে বিলিং সেটিংস পরিবর্তন 되었 তার সংক্ষিপ্ত অডিট লগ

হোলটি টার্গেটেড হওয়া উচিত: কেবল ইনভয়েস এবং সম্পর্কিত সাপোর্ট টিকেট। গ্রাহকের পুরো অ্যাকাউন্ট যদি না লাগে তবে সেটি ফ্রিজ করা উচিত নয়।

বিবাদ সমাধান হলে, হোল মুক্ত করুন, ফলাফল লিখে রাখুন (অনুমোদিত, প্রত্যাখ্যাত, আংশিক রিফান্ড), এবং ধরে রাখা আইটেমগুলোর জন্য কোন মুশকিল ছিল তা মিটে গেলে মুছে ফেলার কাজ পুনরায় চালান।

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

পরবর্তী ধাপ: নীতিকে একটি পুনরাবৃত্তিযোগ্য ওয়ার্কফ্লোতে রূপান্তর করুন

একটি রিটেনশন নীতি তখনই কাজ করে যখন তা রুটিন কাজ হয়ে ওঠে। ছোট থেকে শুরু করুন, প্রমাণ করুন, তারপর বাড়ান। একটি ডেটা টাইপ বেছে নিন (উদাহরণ: সাপোর্ট টিকেট), একটি সিস্টেম এবং একটি রিপোর্ট যা দেখায় কী মুছে ফেলা হয়েছে, কী ধরে রাখা হয়েছে, এবং কেন।

২ থেকে ৪ সপ্তাহ একটি ছোট পাইলট চালান এবং ঘর্ষণ খুঁজুন: অস্পষ্ট মালিক, অনুপস্থিত অনুমোদন, এবং দেরিতে আসা হোল অনুরোধ। সেগুলো ঠিক করে নিন তারপর পরবর্তী সিস্টেমে প্রসারিত করুন।

একটি রোলআউট পরিকল্পনা যা চাপের মধ্যে টিকিয়ে রাখে:

• একটি স্পষ্ট নিয়ম ও মালিকসহ একটি ডেটাসেট বেছে নিন
• এক পৃষ্ঠার লিগ্যাল হোল পদ্ধতি লিখুন এবং সেটি অনুমোদন নিন
• একটি পর্যায়ক্রমিক হোল পর্যালোচনা রিমাইন্ডার যোগ করুন (মাসিক বা ত্রৈমাসিক)
• একটি অডিট-রেডি রিপোর্ট নির্ধারণ করুন এবং কে সই করবে তা ঠিক করুন
• প্রথমটি সফলভাবে চলার পরে পরবর্তী ডেটাসেটে প্রসারিত করুন

হোল পদ্ধতিটা এত সংক্ষিপ্ত রাখুন যে মানুষ তা ব্যবহার করবে। এক পৃষ্ঠা যথেষ্ট যদি এতে উত্তর থাকে: কে হোল অনুরোধ করতে পারে, কে অনুমোদন করে, কী থাকতে হবে (স্কোপ, কারণ, শুরু তারিখ), এবং শেষে কী ঘটে।

হোলগুলো ডিফল্টভাবে খুলে থাকা যাবেনা। রিমাইন্ডার যোগ করুন যা সিদ্ধান্ত নিতে বাধ্য করে: হোল নবায়ন করুন কারণসহ, সংকীর্ণ করুন, বা বন্ধ করুন।

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