GDPR ডেটা রেসিডেন্সি নিয়ন্ত্রণে প্রতিশ্রুতি নয়, প্রমাণ দরকার

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

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

এই নিবন্ধটি AI অ্যাপ বিল্ডারের ক্রেতাদের জন্য একটি ব্যবহারিক মানদণ্ড দেয়। নির্দিষ্ট কোনো ট্রান্সফার, এখতিয়ার বা ঝুঁকির ধরন নিয়ে আইনজীবীর পরামর্শের বিকল্প এটি নয়।

অঞ্চল পিনিংয়ে প্রতিটি ডেটা শ্রেণি নির্ধারণ করতে হবে

সরবরাহকারী যখন ভৌগোলিক সীমা এবং এর আওতাভুক্ত ডেটা দুটিই নির্ধারণ করে, তখনই অঞ্চল পিনিং বিশ্বাসযোগ্য হয়। «EU হোস্টিং» বলতে বোঝাতে পারে প্রাথমিক ডেটাবেস ফ্রাঙ্কফুর্টে আছে, অথচ প্রম্পট অন্যত্র মডেল এন্ডপয়েন্টে যায়, লগ বৈশ্বিক অ্যানালিটিক্স সেবায় জমা হয় এবং ব্যাকআপ বিভিন্ন অঞ্চলে প্রতিলিপি হয়। সরবরাহকারী ডেটা প্রবাহের মানচিত্র না দেওয়া পর্যন্ত এই লেবেল খুব কমই বলে।

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

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

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

সেরা প্রমাণ তিনটি স্তর মিলিয়ে গড়ে ওঠে। চুক্তি বা অর্ডার ফর্মে নির্ধারিত অঞ্চল ও পরিবর্তন প্রক্রিয়া থাকে। আর্কিটেকচার নথি প্রতিটি ডেটা শ্রেণিকে সেবা ও অবস্থানের সঙ্গে মিলিয়ে দেয়। API উত্তর বা ডেপ্লয়মেন্ট রেকর্ডের মতো প্রযুক্তিগত নথি ক্রেতার নিজস্ব টেন্যান্টের সেটিং প্রমাণ করে।

উদাহরণ হিসেবে, সরবরাহকারীকে স্থিতিশীল কাঠামোর একটি টেন্যান্ট রেকর্ড দিতে বলুন:

{
  "tenant_id": "acme-eu",
  "workspace_region": "eu-central",
  "runtime_region": "eu-central",
  "backup_regions": ["eu-central", "eu-west"],
  "support_access_policy": "eea_only",
  "effective_at": "2026-07-01T00:00:00Z"
}

নামগুলো পণ্যভেদে আলাদা হবে। গুরুত্বপূর্ণ বিষয় হলো, রেকর্ডটি ওয়ার্কস্পেস, রানটাইম, ব্যাকআপ এবং সাপোর্ট নীতিকে একটি সবুজ «EU» ব্যাজে একীভূত না করে আলাদা করেছে। কে এসব মান বদলাতে পারে, ক্রেতা পরিবর্তন শনাক্ত করতে পারে কি না এবং স্থানান্তরের পর পুরোনো কপিগুলোর কী হয়, জিজ্ঞাসা করুন।

ব্যাকআপের জন্য আলাদা রেসিডেন্সি প্রতিশ্রুতি দরকার

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

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

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

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

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

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

সাবপ্রসেসর তালিকায় প্রকৃত শৃঙ্খল ব্যাখ্যা থাকতে হবে

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

GDPR Article 28 অনুযায়ী অন্য প্রসেসর নিয়োগের আগে প্রসেসরকে নির্দিষ্ট বা সাধারণ লিখিত অনুমোদন নিতে হয়। সাধারণ অনুমোদনের ক্ষেত্রে উদ্দেশ্যপ্রণোদিত সংযোজন বা প্রতিস্থাপন সম্পর্কে নিয়ন্ত্রককে জানাতে হয়, যাতে নিয়ন্ত্রক আপত্তি করতে পারে। প্রকিউরমেন্টের এ নিয়মকে অপারেশনাল চাহিদায় রূপ দেওয়া উচিত: স্থিতিশীল নিবন্ধন, ক্রেতা নজর রাখে এমন চ্যানেলে আগাম নোটিশ, নির্ধারিত নোটিশকাল ও স্পষ্ট আপত্তি প্রক্রিয়া।

প্রতিটি সাবপ্রসেসরের জন্য নিবন্ধনে পাঁচটি বিষয় থাকা উচিত:

• যে আইনি সত্তা ডেটা পায় বা অ্যাক্সেস করতে পারে
• সেবা ও সুনির্দিষ্ট প্রসেসিং উদ্দেশ্য
• ব্যক্তিগত ডেটার শ্রেণি ও প্রভাবিত পণ্যের বৈশিষ্ট্য
• সংরক্ষণ ও দূরবর্তী অ্যাক্সেসের দেশ
• প্রযোজ্য ট্রান্সফার মেকানিজম ও পরবর্তী সাবপ্রসেসর পথ

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

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

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

DPA-তে সেটিংকে বাধ্যবাধকতায় রূপ দিতে হবে

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

GDPR-এর Article 28(3)-এ নিয়ন্ত্রক-প্রসেসর চুক্তিতে থাকা প্রয়োজনীয় বিষয়গুলো রয়েছে: বিষয়বস্তু ও মেয়াদ, ধরন ও উদ্দেশ্য, ব্যক্তিগত ডেটার ধরন, ডেটা সাবজেক্টের শ্রেণি, গোপনীয়তা, নিরাপত্তা সহায়তা, ডিলিশন বা ফেরত এবং কমপ্লায়েন্স প্রদর্শনের জন্য প্রয়োজনীয় তথ্য। European Data Protection Board-এর Guidelines 07/2020 একটি গুরুত্বপূর্ণ সতর্কতা যোগ করে: প্রসেসিং চুক্তি কেবল GDPR পুনরাবৃত্তি করবে না। চাহিদাগুলো কীভাবে পূরণ হবে এবং কী মাত্রার নিরাপত্তা দরকার সে বিষয়ে নির্দিষ্ট তথ্য থাকবে।

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

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

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

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

SCCs কেবল ট্রান্সফারের চুক্তিগত অংশ সমাধান করে

Standard Contractual Clauses Article 46-এর ট্রান্সফার টুল দিতে পারে, কিন্তু তাতে সই করলেই প্রতিটি ট্রান্সফার বৈধ বা যথেষ্ট সুরক্ষিত প্রমাণ হয় না। ক্রেতাকে সঠিক মডিউল বাছতে, সংযোজনী পূরণ করতে, পরবর্তী ট্রান্সফারের মানচিত্র করতে এবং গন্তব্য ও ডেটার জন্য ক্লজগুলো বাস্তবে কাজ করে কি না মূল্যায়ন করতে হয়।

European Commission-এর 2021 SCCs পক্ষগুলোর ভূমিকার ভিত্তিতে চারটি মডিউল ব্যবহার করে। EEA-এর কোনো সাধারণ গ্রাহক EEA-এর বাইরে প্রসেসরের কাছে ডেটা পাঠালে Module 2 ব্যবহার করতে পারে। কোনো প্রসেসর তৃতীয় দেশে সাবপ্রসেসরের কাছে ডেটা পাঠালে Module 3 লাগতে পারে। কে রপ্তানিকারক, কে আমদানিকারক এবং ওই প্রসেসিংয়ের জন্য আমদানিকারক আগে থেকেই GDPR-এর আওতায় কি না তার ওপর সঠিক পছন্দ নির্ভর করে। তাই প্রতিটি চুক্তিতে Module 2 বসানোর বদলে আইনজীবীর পুরো শৃঙ্খল নিশ্চিত করা উচিত।

পূর্ণ করা সংযোজনীগুলো প্রমাণ। এতে পক্ষগুলোর নাম, ডেটা সাবজেক্ট, ডেটা শ্রেণি, সংবেদনশীল ডেটা ও সুরক্ষা, ট্রান্সফারের ঘনত্ব, উদ্দেশ্য, সংরক্ষণকাল, সক্ষম তদারকি কর্তৃপক্ষ, প্রযুক্তিগত ও সাংগঠনিক পদক্ষেপ এবং সাবপ্রসেসরের নাম থাকা উচিত। ফাঁকা সংযোজনী, «সব গ্রাহক ডেটা» ধরনের সাধারণ বর্ণনা বা পরে বিস্তারিত পূরণের প্রতিশ্রুতি ক্লজগুলোকে প্রকৃত সেবা থেকে বিচ্ছিন্ন রাখে।

EDPB-এর Recommendations 01/2020 ছয় ধাপের পদ্ধতি দেয়: ট্রান্সফার জানুন, ট্রান্সফার টুল চিহ্নিত করুন, তৃতীয় দেশের আইন বা চর্চা মূল্যায়ন করুন, প্রয়োজন হলে বাড়তি পদক্ষেপ নিন, আনুষ্ঠানিক ধাপ শেষ করুন এবং উপযুক্ত বিরতিতে পুনর্মূল্যায়ন করুন। সুপারিশগুলো তৃতীয় দেশ থেকে দূরবর্তী অ্যাক্সেসকেও ট্রান্সফার হিসেবে বিবেচনা করে। স্টোরেজ মানচিত্রে মনোযোগ দিলে ক্রেতারা এই বিষয়টি প্রায়ই মিস করেন।

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

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

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

সাপোর্ট অ্যাক্সেসে অপারেটর যেখানে বসে, সেখানেই প্রসেসিং হয়

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

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

«কোনো দেশের তালিকা ছাড়া বৈশ্বিক ফলো-দ্য-সান সাপোর্ট» নয়, প্রকিউরমেন্টের নাম-উল্লেখিত অ্যাক্সেস অবস্থান বা প্রয়োগযোগ্য অঞ্চল নীতি চাওয়া উচিত। প্রোডাকশন অ্যাক্সেস পেতে পারে এমন কর্মী, সহযোগী ও ঠিকাদার, তারা যেসব দেশ থেকে কাজ করে এবং EEA-বহির্ভূত প্রতিটি পথের ট্রান্সফার মেকানিজম সরবরাহকারীকে জানাতে হবে। জরুরি অ্যাক্সেসে অবস্থান-সীমা অতিক্রম করা গেলে ট্রিগার, অনুমোদনকারী, সময়সীমা ও ক্রেতাকে নোটিশ নথিভুক্ত করুন।

অনুমোদনের আগে বা প্রুফ অব কনসেপ্ট চলাকালে সাপোর্ট-অ্যাক্সেস পরীক্ষা চালান:

1. চুক্তিবদ্ধ EU অঞ্চলে একটি টেস্ট টেন্যান্ট তৈরি করুন এবং অনন্য কৃত্রিম গ্রাহক রেকর্ড যোগ করুন।
2. এমন একটি সাপোর্ট কেস খুলুন যাতে সাধারণত পরিদর্শন লাগত, কিন্তু টিকিটে রেকর্ডটি পেস্ট করবেন না।
3. সরবরাহকারীকে অ্যাক্সেস অনুরোধ, অনুমোদনকারী, অপারেটরের দেশ, প্রদত্ত ভূমিকা ও মেয়াদ শেষ দেখাতে বলুন।
4. সংবেদনশীল কনটেন্ট লগে কপি না করে সেশন লগে টেন্যান্ট, কাজ, সময় ও কারণ লেখা হয়েছে কি না নিশ্চিত করুন।
5. অ্যাক্সেস প্রত্যাহার করুন, তারপর প্রমাণ চাইুন যে ভূমিকা বা সেশন আর টেন্যান্টে পৌঁছাতে পারে না।

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

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

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

পরিবর্তন ও ঘটনার মধ্যেও প্রমাণ টিকে থাকতে হবে

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

অনুমোদন রেকর্ডে নিয়ন্ত্রণ-থেকে-প্রমাণ ম্যাট্রিক্স ব্যবহার করুন। প্রতিটি এন্ট্রিতে চারটি ক্ষেত্র দিন: নিয়ন্ত্রণ দাবি, চুক্তিগত প্রমাণ, প্রযুক্তিগত প্রমাণ ও নবায়নের ট্রিগার।

1. অনুমোদিত ওয়ার্কস্পেস ও রানটাইম অঞ্চলের জন্য, টেন্যান্ট অঞ্চল রেকর্ড ও ডেটা-ফ্লো ম্যাপের পাশে অর্ডার ফর্ম ও অবস্থান সূচি রাখুন। অঞ্চল বা আর্কিটেকচার বদলালে এগুলো নবায়ন করুন।
2. ব্যাকআপ অবস্থানের জন্য, ব্যাকআপ ও ডিলিশন সূচির সঙ্গে রিস্টোর টেস্ট রেকর্ড রাখুন। ব্যাকআপ প্রোভাইডার বা ডিজাস্টার রিকভারি বদলালে নবায়ন করুন।
3. অনুমোদিত সাবপ্রসেসর শৃঙ্খলের জন্য, DPA অনুমোদন ধারার সঙ্গে আর্কিটেকচারের সঙ্গে মেলানো নিবন্ধন রাখুন। সংযোজন বা প্রতিস্থাপনের নোটিশের পর পর্যালোচনা করুন।
4. তৃতীয় দেশের ট্রান্সফারের জন্য, ট্রান্সফার ইনভেন্টরি ও মূল্যায়নের সঙ্গে SCCs বা অ্যাডিকোয়েসি রেফারেন্স রাখুন। গন্তব্য, আইন বা অ্যাক্সেস বদলালে পর্যালোচনা করুন।
5. সাপোর্ট অবস্থানের জন্য, সাপোর্ট অ্যাক্সেস সূচির সঙ্গে অনুমোদন, সেশন ও প্রত্যাহারের লগ রাখুন। সাপোর্টের দেশ বা ভূমিকা বদলালে নবায়ন করুন।

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

নোটিফিকেশনের সীমা নির্ধারণ করুন। শুধু সেবার স্ট্যাটাস ইমেল পাঠানো নতুন সাবপ্রসেসরের পর্যালোচনা, প্রম্পট পাওয়া মডেল প্রোভাইডারের চেয়ে হালকা হতে পারে। নতুন ব্যাকআপ দেশ, বিস্তৃত সাপোর্ট অবস্থান, প্রশিক্ষণে ব্যবহারের পরিবর্তন বা চুক্তিবদ্ধ অঞ্চল অতিক্রম করা হলে, ক্রেতা মূল্যায়ন শেষ না করা পর্যন্ত নতুন সংবেদনশীল ডেপ্লয়মেন্ট থামাতে হবে।

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

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

চাহিদা থেকে পরীক্ষাযোগ্য উত্তর আসা উচিত

রেসিডেন্সির চাহিদা এমনভাবে লিখুন যাতে সরবরাহকারী হ্যাঁ, না বা প্রযোজ্য নয় বলতে পারে এবং নাম-উল্লেখিত আর্টিফ্যাক্ট সংযুক্ত করতে পারে। বিস্তৃত প্রশ্ন বিস্তৃত আশ্বাস আনে। «GDPR বিষয়ে আপনার পদ্ধতি বর্ণনা করুন» থেকে কয়েক পৃষ্ঠা ঝরঝরে লেখা মিলবে, অনুমোদনের প্রমাণ প্রায় মিলবে না। ডেটা, অবস্থান, আচরণ ও প্রমাণের সঙ্গে যুক্ত চাহিদা দ্রুত ঘাটতি প্রকাশ করে।

হোস্টিংয়ের জন্য কার্যকর চাহিদা হতে পারে: «সরবরাহকারী Schedule A-তে তালিকাভুক্ত দেশগুলোতে ছাড়া প্রোডাকশন গ্রাহক কনটেন্ট, প্রম্পট, তৈরি সোর্স কোড ও প্রমাণীকরণ রেকর্ড সংরক্ষণ বা প্রসেস করবে না, ব্যতিক্রম কেবল Schedule B-তে তালিকাভুক্ত ট্রান্সফার।» সূচিগুলো বাক্যটির মতোই গুরুত্বপূর্ণ। Schedule A অনুমোদিত সীমা নির্ধারণ করে। Schedule B সাধারণ অধিকার লুকিয়ে না রেখে পক্ষগুলোকে ব্যতিক্রমের নাম বলতে বাধ্য করে।

আলাদা নিয়ন্ত্রণের জন্য আলাদা চাহিদা ব্যবহার করুন। RFP বা নিরাপত্তা সংযোজনীতে নিচের প্রম্পটগুলো কার্যকর:

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

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

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

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

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

বিক্রয়-ভাষা নয়, দাবির স্কোর দিন

প্রতিটি গুরুত্বপূর্ণ ডেটা পথে তিন ধরনের প্রমাণ আছে কি না দেখে ক্রেতা রেসিডেন্সি প্রস্তুতির স্কোর দিতে পারে: বাধ্যতামূলক প্রতিশ্রুতি, বর্তমান সিস্টেমের বিবরণ এবং টেন্যান্ট-নির্দিষ্ট বা সাম্প্রতিক অপারেশনাল প্রমাণ। একটি স্তর অনুপস্থিত থাকলে সরবরাহকারী «GDPR-সম্মত» কি না তা নিয়ে অস্পষ্ট বিতর্কের বদলে সুনির্দিষ্ট অনুসরণমূলক প্রশ্ন তৈরি হয়।

চারটি সিদ্ধান্ত অবস্থা ব্যবহার করুন:

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

এই পদ্ধতি প্রকিউরমেন্টের দুটি খারাপ অভ্যাসও ঠেকায়। প্রথমটি হলো ইউরোপের বাইরে কর্মী আছে বলেই কোনো বৈশ্বিক সরবরাহকারীকে প্রত্যাখ্যান করা, যদিও সেই কর্মীরা ক্রেতার পরিবেশে পৌঁছাতে পারে না। দ্বিতীয়টি হলো মডেল রাউটিং বা সাপোর্ট অ্যাক্সেস না দেখে «EU হোস্টেড» পণ্য অনুমোদন করা। এখতিয়ারগত উপস্থিতি প্রেক্ষাপট। প্রকৃত ডেটা প্রবাহ ও প্রয়োগযোগ্য নিয়ন্ত্রণ এক্সপোজার নির্ধারণ করে।

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

Koder.ai বিভিন্ন দেশে AWS অবকাঠামোয় অ্যাপ্লিকেশন চালাতে পারে, কিন্তু ক্রেতার তবু প্রমাণ প্যাকে নির্বাচিত দেশ, অন্তর্ভুক্ত উপাদান ও অ্যাক্সেস পথের উল্লেখ চাইতে হবে। পণ্যের সক্ষমতা কথোপকথন শুরু করে, প্রকিউরমেন্টের প্রমাণ সেটি শেষ করে।

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

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