নিরাপত্তা governance — policy, ভূমিকা আর metric

১ · Governance কী, আর management থেকে তফাত কোথায়

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

Security governance হলো সেই কাঠামো, যা ঠিক করে নিরাপত্তা নিয়ে কে সিদ্ধান্ত নেবেন, কোন ঝুঁকি মানা হবে, কে জবাব দেবেন আর ফল কীভাবে যাচাই হবে। এটি কোনো software নয়। Security management হলো সেই দিকনির্দেশ অনুযায়ী প্রতিদিনের কাজ চালানো।

Board-এর কেন মাথাব্যথা

নিরাপত্তার ঘটনা শেষ পর্যন্ত ব্যবসার ঘটনা: আয় বন্ধ, গ্রাহকের আস্থা নষ্ট, নিয়ন্ত্রকের প্রশ্ন, মামলা। এসব ঝুঁকি নেওয়ার অধিকার কোনো system administrator-এর নেই। ঝুঁকি কতটা মানা হবে, সেই risk appetite ঠিক করা নেতৃত্বের কাজ, আর টাকা ও মানুষ বরাদ্দের ক্ষমতাও তাঁদের হাতে। ঝুঁকির ভাষা মনে না থাকলে পর্ব ০২ দেখে নিন।

২ · কে কী করেন: ভূমিকা, three lines আর RACI

ছোট প্রতিষ্ঠানে একজন মানুষ কয়েকটি ভূমিকা নিতে পারেন। তবে যিনি কাজ করেন, তিনিই নিজের কাজের চূড়ান্ত যাচাইকারী হলে separation of duties ভাঙে (পর্ব ০৩)।

Three lines model

Three lines model ভূমিকাগুলোকে সাজায়। Institute of Internal Auditors (IIA) ২০২০ সালের জুলাইয়ে পুরোনো “three lines of defense” ধারণাটি হালনাগাদ করে এই নাম দেয়। গার্মেন্টসের উদাহরণে ফ্লোর সুপারভাইজার প্রথম লাইন, কমপ্লায়েন্স বিভাগ দ্বিতীয়, আর মালিকপক্ষের কাছে সরাসরি রিপোর্ট করা internal audit তৃতীয়। বায়ারের auditor বাইরের নিশ্চয়তা।

IIA-র মডেল স্পষ্ট করে বলে, “line” কোনো কাঠামো নয়, ভূমিকার তফাত বোঝানোর ভাষা। আর দ্বিতীয় লাইন থাকলেও ঝুঁকি সামলানোর দায়িত্ব প্রথম লাইনেই থাকে। অর্থাৎ নিরাপত্তা দল আছে বলে IT দায়মুক্ত নয়।

RACI: এক ছকে দায়িত্ব

অনেক অফিসে শোনা যায়, “ওটা তো আমি ভেবেছিলাম IT দেখছে।” RACI ছক এই ফাঁক ধরে। প্রতিটি কাজের জন্য চারটি অক্ষর:

• R (Responsible): যিনি কাজটি করেন। একাধিক হতে পারেন।
• A (Accountable): যিনি শেষ জবাব দেন। ঠিক একজন।
• C (Consulted): কাজের আগে যাঁর মত নেওয়া হয়।
• I (Informed): কাজের পর যাঁকে জানানো হয়।

নিচের খেলনা যাচাইকারী একটি ছোট অফিসের ছক পরীক্ষা করে। চালিয়ে দেখুন কোন কাজগুলো আটকে যায়। এটি শুধু memory-র একটি table পড়ে।

// Toy RACI check on an in-memory table. No real system is touched.
// R = does the work, A = answers for it, C = asked first, I = told after.
const people = ["Owner", "CISO", "IT", "HR", "Audit"];
const raci = {
  "Approve security policy": ["A", "R", "C", "C", "I"],
  "Patch internet servers":  ["I", "A", "R", "-", "I"],
  "Remove leaver accounts":  ["-", "C", "R", "R", "I"],
  "Approve an exception":    ["A", "A", "C", "-", "I"],
  "Quarterly restore test":  ["-", "A", "-", "-", "I"],
  "Review access rights":    ["I", "A", "R", "C", "-"],
};

let problems = 0;
for (const [task, row] of Object.entries(raci)) {
  const a = people.filter((p, i) => row[i] === "A");
  const r = people.filter((p, i) => row[i] === "R");
  const notes = [];
  if (a.length === 0) notes.push("no accountable person");
  if (a.length > 1) notes.push("two accountable: " + a.join(" + "));
  if (r.length === 0) notes.push("nobody does the work");
  problems += notes.length;
  console.log((notes.length ? "FIX " : "ok  ") + task.padEnd(25) + notes.join("; "));
}
const load = people.map((p, i) =>
  p + ":" + Object.values(raci).filter(row => row[i] === "R").length);
console.log("Problems:", problems, "| R per person:", load.join(" "));

৩ · Policy, standard, procedure, guideline

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

ভালো নিয়মের পরীক্ষা সহজ: একজন নতুন কর্মী কি পড়ে বুঝবেন কী করতে হবে, আর কেউ কি মেপে বলতে পারবেন মানা হচ্ছে কি না? “সবাই নিরাপদ থাকবেন” কোনো নিয়ম নয়। আর যে নিয়ম কাজ আটকে দেয়, মানুষ তা ঘুরপথে এড়ান (পর্ব ৫৪); তখন অফিসের ফাইল ব্যক্তিগত WhatsApp-এ চলে যায় আর জন্ম নেয় shadow IT.

Acceptable use policy: এক পাতার কাঠামো

Acceptable use policy (AUP) কর্মীকে জানায়, অফিসের কম্পিউটার, email আর ডেটা কীভাবে ব্যবহার করা যাবে। এটি একটি কাঠামো মাত্র; নিজের প্রতিষ্ঠানের জন্য বানাতে হবে, আর নজরদারি ও শাস্তির অংশ HR আর আইনজীবী দেখে নেবেন।

1. উদ্দেশ্য আর পরিধি: স্থায়ী কর্মী, চুক্তিভিত্তিক কর্মী আর vendor, সবার জন্য।
2. Account: নিজের account অন্যকে দেওয়া যাবে না; MFA চালু রাখতে হবে।
3. ডেটা: Confidential ফাইল ব্যক্তিগত email, WhatsApp বা পেনড্রাইভে নেওয়া যাবে না।
4. ডিভাইস আর software: অনুমোদন ছাড়া software নয়; ব্যক্তিগত ফোন ব্যবহারের শর্ত।
5. AI tool: কোন tool অনুমোদিত, আর সেখানে কোন ডেটা দেওয়া যাবে না।
6. রিপোর্ট: সন্দেহজনক কিছু দেখলে কাকে জানাবেন; ভুল করলেও দ্রুত জানালে শাস্তি নয়, সহায়তা।
7. পর্যবেক্ষণের নোটিশ: অফিসের system-এ কী লগ করা হয়, আগেই পরিষ্কার করে জানানো।
8. ভঙ্গের ফল আর সই: কী ব্যবস্থা হতে পারে; পড়ে বুঝেছেন বলে কর্মীর স্বীকৃতি।

একটি policy-র জীবন

কাল্পনিক “উদাহরণ লিমিটেড”-এ ৫০ জন কর্মী কাজ করেন। হিসাব বিভাগ WhatsApp-এ বেতনের ফাইল পাঠাচ্ছিল। দেখুন একটি ডেটা-ব্যবহার policy কীভাবে খসড়া থেকে চালু হয়। “পরে” চেপে এগোন।

পর্যালোচনার চক্র

পুরোনো policy মিথ্যা কথা বলে। তাই সাধারণ নিয়ম হলো অন্তত বছরে একবার পর্যালোচনা, আর বড় পরিবর্তনে আগেভাগে: নতুন আইন, নতুন system, বড় ঘটনা, প্রতিষ্ঠান বদল। “বছরে একবার” একটি প্রচলিত অভ্যাস, সব জায়গার বাঁধা নিয়ম নয়; ISO/IEC 27001:2022 পরিকল্পিত বিরতিতে আর বড় পরিবর্তনে পর্যালোচনার কথা বলে। নিচের ট্র্যাকার একটি বানানো তারিখ ধরে হিসাব করে।

// Toy policy review tracker. "today" is a simulated date, not the real clock.
const today = "2026-11-01";
const soonDays = 60;
const dayNo = s => { const [y, m, d] = s.split("-").map(Number); return Date.UTC(y, m - 1, d) / 864e5; };
const addMonths = (s, n) => {
  const [y, m, d] = s.split("-").map(Number);
  return new Date(Date.UTC(y, m - 1 + n, d)).toISOString().slice(0, 10);
};

const policies = [
  { name: "Information security", owner: "CEO",  last: "2026-02-10", every: 12 },
  { name: "Acceptable use",       owner: "HR",   last: "2025-09-15", every: 12 },
  { name: "Backup standard",      owner: "IT",   last: "2026-01-05", every: 12 },
  { name: "Remote work",          owner: "",     last: "2024-06-01", every: 24 },
  { name: "Cloud use",            owner: "IT",   last: "2026-03-01", every: 12,
    changed: "2026-08-20" },   // moved payroll to a new cloud service
];

for (const p of policies) {
  const due = addMonths(p.last, p.every);
  const left = dayNo(due) - dayNo(today);
  let state = "OK";
  if (left < 0) state = `OVERDUE by ${-left} days`;
  else if (left <= soonDays) state = `DUE in ${left} days`;
  if (p.changed && dayNo(p.changed) > dayNo(p.last)) state = "REVIEW NOW: big change since last review";
  const who = p.owner || "NO OWNER";
  console.log(`${p.name.padEnd(21)} ${who.padEnd(9)} due ${due}  ${state}`);
}

৪ · Asset আর ডেটার শ্রেণিবিন্যাস

যা জানেন না, তা রক্ষা করতে পারবেন না। তাই শুরু asset inventory দিয়ে: কোন system, কোন ডেটা, কোন সেবা, আর প্রতিটির মালিক কে। তারপর সব কিছুকে সমান না ভেবে গুরুত্ব অনুযায়ী ভাগ করা হয়, ঠিক যেমন অফিসের চিঠি, নোটিশ বোর্ড আর আলমারির তালাবদ্ধ ফাইল একভাবে রাখা হয় না।

Data classification মানে ক্ষতির মাত্রা দেখে ডেটাকে শ্রেণিতে ভাগ করা আর প্রতিটির জন্য আচরণের নিয়ম ঠিক করা। কোনো একটিমাত্র বিশ্বস্বীকৃত ভাগ নেই; অনেকে চার স্তর, অনেকে তিন স্তর ব্যবহার করেন। স্তর কম রাখাই ভালো, নইলে কেউ মনে রাখবেন না।

শ্রেণি ঠিক করেন data owner, নিরাপত্তা দল নয়। ডেটাকে শ্রেণিতে ফেলার পর সব control-এর জোর কোথায় পড়বে তা সহজ হয়; বাজেটও সেখানেই যায়। ব্যক্তিগত তথ্যের আইনি দায় আলাদা, সেটি পর্ব ০৬ আর পর্ব ৭০-এ দেখুন।

৫ · Exception: নিয়মের বাইরে যাওয়ার নিয়ম

কোনো নিয়মই সব পরিস্থিতিতে মানা যায় না। পুরোনো software নতুন update নেয় না, vendor সময় চান। এখন দুটি পথ: চুপচাপ নিয়ম ভাঙা, অথবা লিখিত policy exception. প্রথম পথে ঝুঁকি অদৃশ্য থাকে, দ্বিতীয় পথে নেতৃত্ব জেনে ঝুঁকি নেন। পর্ব ৩২-এর risk exception এরই একটি বিশেষ রূপ।

নিচের কাল্পনিক অনুরোধে নিয়ম হলো “critical patch ৭ দিনে”, কিন্তু হিসাবের পুরোনো server-এর vendor জানুয়ারির আগে সংস্করণ দিতে পারছে না। ঝুঁকির ছক ৫×৫: সম্ভাবনা × প্রভাব।

৬ · কৌশল, roadmap আর বাজেট

Security strategy তিনটি প্রশ্নের উত্তর: এখন কোথায় আছি, ব্যবসার জন্য কোথায় থাকা দরকার, আর মাঝের ফাঁক কীভাবে পূরণ হবে। Security roadmap সেই উত্তরকে সময়ের ওপর সাজায়। Roadmap-এর প্রতিটি কাজের পাশে একটি ঝুঁকি থাকা চাই। ঝুঁকি না থাকলে প্রশ্ন করুন, কাজটি কেন হচ্ছে।

বাজেট আর business case

নেতৃত্ব জিজ্ঞেস করেন না “কোন firewall ভালো?”, তাঁরা জিজ্ঞেস করেন “টাকা দিলে কী বদলাবে?” তাই business case-এ থাকে: সমস্যা, ঝুঁকির মান, বিকল্প (কিছু না করাসহ), মোট খরচ (লাইসেন্সের সঙ্গে মানুষের সময়ও, যাকে বলে TCO), প্রত্যাশিত ফল, আর যে সিদ্ধান্ত চাওয়া হচ্ছে।

সংখ্যায় তুলনার একটি প্রচলিত উপায় ROSI. ধরুন বছরে প্রত্যাশিত ক্ষতি (ALE) ৪০ লাখ টাকা, একটি control তা ৭০% কমায়, আর বছরে খরচ ৫ লাখ।

ALE-এর হিসাব আর তার সীমা আসছে পর্ব ৬৮-তে। নিচের খেলনা allocator অনুমিত সংখ্যায় ROSI ধরে সাজায় আর ২০ লাখ টাকার মধ্যে বাছাই করে।

// Toy budget allocator. All numbers are assumed, in lakh taka per year.
// loss = expected yearly loss; cut = share of that loss the control removes.
const budget = 20;
const options = [
  { name: "MFA for all staff",     cost: 3,  loss: 20, cut: 0.6 },
  { name: "Tested offline backup", cost: 5,  loss: 40, cut: 0.7 },
  { name: "Managed EDR",           cost: 9,  loss: 25, cut: 0.5 },
  { name: "Staff training",        cost: 2,  loss: 6,  cut: 0.3 },
  { name: "Web app firewall",      cost: 6,  loss: 10, cut: 0.4 },
  { name: "Fancy threat feed",     cost: 8,  loss: 5,  cut: 0.2 },
];

const rows = options.map(o => {
  const saved = o.loss * o.cut;
  return { ...o, saved, rosi: (saved - o.cost) / o.cost };
}).sort((a, b) => b.rosi - a.rosi);

let left = budget, savedTotal = 0;
for (const r of rows) {
  const pct = Math.round(r.rosi * 100) + "%";
  if (r.rosi <= 0) { console.log(`skip ${r.name.padEnd(22)} ROSI ${pct}: costs more than it saves`); continue; }
  if (r.cost > left) { console.log(`wait ${r.name.padEnd(22)} ROSI ${pct}: only ${left} left`); continue; }
  left -= r.cost; savedTotal += r.saved;
  console.log(`fund ${r.name.padEnd(22)} ROSI ${pct}: cost ${r.cost}, saves ${r.saved.toFixed(1)}`);
}
const total = options.reduce((s, o) => s + o.loss, 0);
console.log(`Spent ${budget - left} of ${budget}. Loss ${total} -> ${(total - savedTotal).toFixed(1)}`);

৭ · KPI, KRI আর সহজ ভাষায় রিপোর্ট

গাড়ির ড্যাশবোর্ডের কথা ভাবুন। গতিমাপক বলে গাড়ি কতটা ভালো চলছে; ইঞ্জিনের সতর্ক বাতি বলে সামনে বিপদ আসছে। KPI (Key Performance Indicator) মাপে একটি control বা কর্মসূচি লক্ষ্য অনুযায়ী কাজ করছে কি না। KRI (Key Risk Indicator) জানায় ঝুঁকি সীমার দিকে যাচ্ছে কি না। সীমারেখা সব জায়গায় এক নয়; একই সংখ্যা এক অফিসে KPI, অন্য অফিসে KRI হতে পারে। আসল কথা, লক্ষ্য বা সীমা আছে কি না।

Vanity metric দেখতে ভালো, কিন্তু সিদ্ধান্ত বদলায় না। একটি সহজ পরীক্ষা: “এই সংখ্যা দ্বিগুণ হলে আমরা কী করব?” উত্তর না থাকলে সংখ্যাটি বাদ দিন। SOC-এর কাজের metric (MTTD ইত্যাদি) পর্ব ৬০-এ আছে; নেতৃত্বের জন্য সেগুলো থেকে অল্প কয়েকটি বেছে নিতে হয়। নিচের ড্যাশবোর্ডে সবুজ, হলুদ আর লাল সীমা আগে থেকে ঠিক করা।

// Toy KRI dashboard. Values are invented; the last number is this month.
// worseWhen: "high" means a bigger number is bad, "low" means a smaller one is.
const kris = [
  { name: "Admin accounts without MFA (%)", worseWhen: "high", amber: 2, red: 5, last3: [9, 6, 3] },
  { name: "Critical patches past 7 days",   worseWhen: "high", amber: 3, red: 8, last3: [2, 5, 11] },
  { name: "Restore tests passed (%)",       worseWhen: "low",  amber: 95, red: 80, last3: [100, 100, 100] },
  { name: "Leaver accounts open > 1 day",   worseWhen: "high", amber: 1, red: 3, last3: [0, 0, 0] },
  { name: "Unreviewed vendors with data",   worseWhen: "high", amber: 3, red: 6, last3: [1, 2, 2] },
  { name: "Emails blocked",                 worseWhen: "high", last3: [1200000, 1300000, 1250000] },
];

const counts = { GREEN: 0, AMBER: 0, RED: 0 };
for (const k of kris) {
  const [, before, now] = k.last3;
  if (k.amber === undefined) {
    console.log(`SKIP  ${k.name}: no threshold, no decision, so not a KRI`);
    continue;
  }
  const bad = k.worseWhen === "high" ? (x, t) => x >= t : (x, t) => x <= t;
  const status = bad(now, k.red) ? "RED" : bad(now, k.amber) ? "AMBER" : "GREEN";
  const worse = k.worseWhen === "high" ? now > before : now < before;
  const better = k.worseWhen === "high" ? now < before : now > before;
  const trend = worse ? "worse" : better ? "better" : "flat";
  counts[status]++;
  console.log(`${status.padEnd(5)} ${k.name.padEnd(31)} ${String(now).padStart(3)}  ${trend}`);
}
console.log("Summary:", JSON.stringify(counts));

কাঁচা সংখ্যা থেকে সিদ্ধান্ত

Board-কে সংখ্যা নয়, সিদ্ধান্ত দিতে হয়। ৫০টি internet-মুখী server-এর একটি কাল্পনিক উদাহরণ দেখুন। টাকার অঙ্কগুলো অনুমিত।

Patches installed : 4,120
Tickets closed    : 312
Board-এর কাছে এর অর্থ নেই

Internet-facing servers  : 50
Patched within 7 days    : 39
39 / 50 = 78%   target 95%

Past 7 days : 2 -> 5 -> 11
Red line    : 8
Status      : RED, worse

১১টির ৩টি গ্রাহক portal চালায়।
এক দিন বন্ধ ≈ ৬ লাখ টাকা।
কারণ: IT-তে একজন কম।

ক. কিছু না: খরচ ০
খ. বাইরের সেবা: বছরে ৬ লাখ
গ. প্রকৌশলী + মাসে ২ ঘণ্টা
   বন্ধ: বছরে ৭ লাখ (প্রস্তাব)

অনুমোদিত: বিকল্প গ
মালিক: COO
পরের লক্ষ্য: ৩-এর নিচে

৮ · ৫০ জনের প্রতিষ্ঠানের starter pack

ধরুন ৫০ জনের একটি প্রতিষ্ঠান: CISO নেই, IT-তে দুজন, অফিস ঢাকায়, ছোট শাখা চট্টগ্রামে। মোটা দলিল এখানে কাজে আসবে না। নিচের ন্যূনতম প্যাকেজ এক কোয়ার্টারে শুরু করা যায়। এটি একটি পরামর্শ, কোনো মানদণ্ডের নির্ধারিত তালিকা নয়।

৯ · NIST CSF-এর Govern আর বাংলাদেশের নিয়ন্ত্রক

NIST CSF 2.0 ২০২৪ সালের ২৬ ফেব্রুয়ারি প্রকাশিত হয়। এই version-এ Govern ষষ্ঠ Function হিসেবে যুক্ত হয়, আর আগের কিছু Category সেখানে সরে আসে। NIST-এর ভাষায়, Govern-এ প্রতিষ্ঠানের সাইবার ঝুঁকি ব্যবস্থাপনার কৌশল, প্রত্যাশা আর policy প্রতিষ্ঠিত, জানানো আর পর্যবেক্ষণ করা হয়। CSF ফল বলে দেয়, কীভাবে করতে হবে তা বলে না। এর ছয়টি Category:

বাংলাদেশের আর্থিক খাত

Sector regulator তার অধীনের প্রতিষ্ঠানের জন্য নিয়ম দেয়। Bangladesh Bank-এর দুটি দলিল সরাসরি পড়ে এখানে সংক্ষেপ করা হলো (২০২৬ সালের ৩১ অক্টোবর দেখা)। এটি পুরো চিত্র নয়, আর আইনি পরামর্শও নয়। নিজের প্রতিষ্ঠানে প্রযোজ্য কি না আর সর্বশেষ সার্কুলার কী, তা মূল দলিল আর পরিপালন বিভাগের সঙ্গে মিলিয়ে নিন।

• Guideline on ICT Security, Version 4.0 (২০২৩): ব্যাংক, NBFI, MFS আর payment সেবাসহ Bangladesh Bank-নিয়ন্ত্রিত প্রতিষ্ঠানের জন্য। Board-এর ভূমিকায় ICT কৌশল আর policy অনুমোদন আছে। ICT Security Policy board-এর অনুমোদিত আর সময়ে সময়ে পর্যালোচিত হওয়ার কথা বলা আছে। ICT Steering Committee আর ICT Security Committee গঠন, অন্তত বছরে একবার অভ্যন্তরীণ ও বাইরের IS audit আর ICT risk assessment-এর কথাও আছে। মানতে না পারার ব্যতিক্রমী ক্ষেত্রে নির্দিষ্ট মেয়াদের dispensation নেওয়ার ব্যবস্থাও আছে, যা অংশ ৫-এর ধারণার সঙ্গে মেলে।
• Cybersecurity Framework, Version 1.0 (২০২৬): BRPD-২ সার্কুলার নং ০২, ২৯ মার্চ ২০২৬; সার্কুলারে পরিপালনের সময়সীমা ৩১ ডিসেম্বর ২০২৬. কাঠামোটি NIST-এর ছয় Function-এর ওপর গড়া আর নিজেকে ন্যূনতম ভিত্তি (baseline) বলে। এতে যোগ্য CISO নিয়োগ আর তাঁর জন্য জনবল ও বাজেট অনুমোদনের কথা আছে, আর KPI হিসেবে MTTD, MTTR, critical vulnerability কমা ও প্রশিক্ষণ সম্পন্নের হার উদাহরণ দেওয়া আছে।

অন্য খাতের নিয়ন্ত্রকের নিয়ম আলাদা হতে পারে, এখানে সেগুলো যাচাই করা হয়নি। সাধারণ সাইবার আইনের জন্য পর্ব ০৬ দেখুন। Standard আর certification নিয়ে বিস্তারিত আসছে পর্ব ৬৯-এ।

১০ · AI-এর যুগে governance

AI খসড়া লিখতে, লম্বা দলিল সংক্ষেপ করতে আর জটিল রিপোর্টকে সহজ করতে দ্রুত। কিন্তু সে আপনার প্রতিষ্ঠানকে চেনে না, আর জবাবও দেবে না। Governance-এর মূল কাজই হলো জবাবদিহি, যা কোনো tool নিতে পারে না।

AI-এর লেখা policy হাতে পেলে

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