Quasi-PII کیا ہے؟
GDPR آرٹیکل 4 کسی بھی ایسے ڈیٹا کا احاطہ کرتا ہے جو کسی شخص کی شناخت کر سکتا ہے۔ ڈیٹا کو براہ راست کسی کا نام لینے کی ضرورت نہیں۔ اسے صرف اضافی مراحل کے ذریعے شناخت ممکن بنانی ہے۔
اندرونی ملازم IDs ایک واضح مثال ہیں۔ "EMP-EU-123456" کی قدر لیں۔ وہ string کسی کا نام نہیں لیتا۔ لیکن HR سسٹم میں ایک سادہ lookup table ہے۔ EMP-EU-123456 Maria Schmidt، Senior Engineer، Munich سے جڑتا ہے۔ اس table تک رسائی رکھنے والا کوئی بھی اسے ڈھونڈ سکتا ہے۔ GDPR کے تحت، ID ذاتی ڈیٹا ہے۔
یہی قانون دیگر اندرونی کوڈز پر لاگو ہوتا ہے:
- کسٹمر اکاؤنٹ نمبر جو CRM ریکارڈز سے جڑتے ہیں
- پروجیکٹ کوڈ جو معاہدہ سسٹمز میں کلائنٹ کے ناموں سے جڑتے ہیں
- قانونی فائلوں میں case reference نمبر
- Medical record نمبر جو مریض کے ریکارڈز سے جڑتے ہیں
نام اور ای میل ہٹانا کافی نہیں ہے۔ اگر اندرونی IDs فائل میں رہیں تو دوبارہ شناخت صرف دو قدم دور ہے۔
یہ خلا جرمانوں کی طرف کیوں لے جاتا ہے
تمام GDPR جرمانوں کا 34% آرٹیکل 32 کے تحت ناکافی تکنیکی اقدامات پر مشتمل ہے۔ یہ اعداد و شمار DLA Piper 2025 GDPR سالانہ رپورٹ سے آتے ہیں۔ quasi-identifying اندرونی شناختوں کو پہچاننے میں ناکامی اس زمرے میں آتی ہے۔
EDPB نے 2024 میں 900 سے زیادہ consistency mechanism cases سنبھالے۔ Cross-border نفاذ کا مطلب ہے کہ مشترک ڈیٹا سیٹ میں ایک خلا کئی یورپی یونین ممالک میں مربوط کارروائی کا باعث بن سکتی ہے۔
معیاری PII ٹولز عالمی پیٹرن ڈھونڈتے ہیں: نام، ای میلز، فون نمبر، قومی IDs۔ وہ آپ کا اندرونی ID فارمیٹ نہیں جانتے۔ کوئی بھی ٹول نہیں جانتا جب تک آپ اسے نہ بتائیں۔ یہی خلا ہے۔
بغیر کوڈ کا Pattern Builder کیسے کام کرتا ہے
ایک عالمی logistics کمپنی کو بیرونی آڈٹ کے لیے ملازم ریکارڈز کو گمنام بنانا ہے۔ ان کے ملازم IDs اس فارمیٹ میں ہیں: EMP-[REGION]-[6 ہندسے]۔ تین مثالیں: EMP-EU-123456، EMP-APAC-789012، EMP-AMER-345678۔
tعمیل ٹیم AI pattern helper میں تین مثالیں درج کرتی ہے۔ AI واپس دیتا ہے:
- پیٹرن:
EMP-[A-Z]{2,4}-\d{6} - تینوں مثالوں سے مطابقت
- تجویز کردہ entity نام: EMPLOYEE-ID
- تجویز کردہ اگلا قدم: مزید region codes کے ساتھ test کریں
ٹیم دس مزید نمونے test کرتی ہے۔ پیٹرن ان سب پر کام کرتا ہے۔
وہ custom entity کو ٹیم کے مشترک GDPR preset میں محفوظ کرتے ہیں۔ آڈٹ پیکیج کی تمام 47 دستاویزات ایک بیچ میں processed ہوتی ہیں۔ ہر ملازم ID کو کردار پر مبنی label سے replace کیا جاتا ہے۔ آڈٹ فرم ایسی فائلیں پاتی ہے جو اب کسی بھی فرد سے جڑی نہیں ہیں۔
کسی انجینئرنگ مدد کی ضرورت نہیں۔ پوری ترتیب ایک گھنٹے سے کم میں ہو جاتی ہے۔
آگے کیا ہوتا ہے
ایک بار custom entity مشترک preset میں محفوظ ہو جائے، تمام ٹیم ممبران ایک ہی ترتیب استعمال کرتے ہیں۔ نئے عملے کو پہلے دن سے ہی ملتی ہے۔ Batch jobs، API calls، اور manual uploads سب ایک ہی پیٹرن لاگو کرتے ہیں۔
آڈٹ ٹریل دکھاتی ہے کہ ہر فائل کے لیے کون سا preset استعمال کیا گیا۔ اگر کوئی DPA آپ کے anonymization عمل کا ثبوت مانگے، تو آپ اسے دکھا سکتے ہیں۔
مکمل custom entity ترتیب ورک فلو کے لیے، تنظیمی گمنامی کے لیے کسٹم PII شناختیں دیکھیں۔ ٹیموں میں اس ترتیب کو مستقل رکھنے کے لیے، GDPR آڈٹ کے لیے anonymization مستقل مزاجی presets دیکھیں۔