পুরোনো বা unsupported component পর্যালোচনা করা দরকার; শুধু বয়স দিয়ে নিরাপত্তার সমস্যা প্রমাণ হয় না।
লক্ষণ
আপডেটের পর হোয়াইট স্ক্রিন, ভাঙা ফর্ম, মিশ্র HTTP, ব্যাকআপ রিস্টোর টেস্ট নেই।
পরবর্তী ধাপ
ঘটা সমস্যা দেখে care plan ঠিক করুন
এই লেখার সিদ্ধান্ত বাস্তবে নিতে নিচের কাজগুলো পর্যায়ক্রমে করুন। এটি বাংলাদেশের ছোট ব্যবসার জন্য একটি বাস্তবায়নের ওয়ার্কশিট; কোনো নির্দিষ্ট প্রতিষ্ঠানের ফলাফল বা বাজারের গড় দাবি নয়। আপনার বর্তমান প্রক্রিয়া ও সীমাবদ্ধতা অনুযায়ী প্রয়োজন বদলাবে।
-
form নষ্ট, update conflict ও recovery-এর ঘাটতি লিখুন। plugin পুরোনো মানেই vulnerability প্রমাণ নয়।
-
কোন পরীক্ষা নিয়মিত এবং কোনটি জরুরি তা ঠিক করুন। supplier কীভাবে কাজের record রাখবেন জানুন।
-
renewal, form delivery ও restore প্রস্তুতি মাসে দেখুন। একই অস্থায়ী repair-এর বদলে repeated failure-এর মূল কারণ ঠিক করুন।
প্রস্তাব নেওয়ার আগে লিখুন
এখন কীভাবে কাজটি হচ্ছে, কোন ধাপে সমস্যা, কারা ব্যবহার করবেন এবং সঠিক ফল কেমন হবে লিখুন। কিছু test data রাখুন। supplier যেন একই উদাহরণে কাজ দেখাতে পারেন। recurring খরচ, তৃতীয় পক্ষের নির্ভরতা ও support-এর বাদ থাকা কাজ আলাদা করে জিজ্ঞাসা করুন।
কখন পরিকল্পনা বদলাবেন
প্রয়োজনীয় access না থাকলে, test ব্যর্থ হলে অথবা টিম দায়িত্ব নিতে না পারলে পরের ধাপে টাকা খরচ করার আগে সমস্যাটি সমাধান করুন। ছোট pilot-এর ফল দেখে সিদ্ধান্ত নিন। কাজের পরিধি বাড়লে সময় ও খরচ আবার সম্মত করুন; অপ্রমাণিত নিশ্চয়তার ওপর পরিকল্পনা করবেন না।