فرض کنید کاربر درخواست حذف حساب میدهد. ردیف او از دیتابیس اصلی پاک میشود و تست سبز است؛ اما شمارهٔ موبایلش هنوز در ابزار پیامک، eventهای analytics، فایل خروجی تیم پشتیبانی، search index، صف retry و نسخهٔ بازیابیشده از backup حضور دارد. این شکست نشان میدهد تست حریم خصوصی داده یک تست دکمه یا اسکن امنیتی نیست؛ باید تصمیم حقوقی را در تمام چرخهٔ عمر داده به شواهد قابل تکرار تبدیل کند.
در این راهنما، تیم QA یاد میگیرد چگونه بدون ادعای ارائهٔ نظر حقوقی، شمول و الزامات تأییدشده را به سناریوهای اجرایی برای GDPR، CCPA و HIPAA تبدیل کند. از inventory و data flow تا notice، consent، حقوق اشخاص، retention، حذف، vendorها، breach، دادهٔ تست و CI پیش میرویم و یک نمونهٔ بومی برای محصول سلامت ایرانی میسازیم.
مرز مسئولیت: این مطلب آموزش تست نرمافزار است، نه مشاورهٔ حقوقی. دامنهٔ قانون، مبنای پردازش، استثناها، مهلتها و سازوکار انتقال باید برای محصول و حوزهٔ قضایی مشخص توسط مسئول حقوقی/DPO تأیید شود. QA سپس پیادهسازی و شواهد همان تصمیم را میآزماید.
تست حریم خصوصی چه چیزی را اثبات میکند؟
QA نمیتواند با چند test case بنویسد «سازمان GDPR compliant است». انطباق ترکیبی از حقوق، قرارداد، فرایند سازمانی، کنترل فنی و رفتار واقعی است. خروجی معتبر QA محدودتر و مفیدتر است: «Requirement نسخهٔ X در Scope مشخص، با داده و نقشهای تعریفشده، در Build مشخص آزموده شد؛ شواهد این است و این ریسکها باقی ماندهاند.»
حریم خصوصی و امنیت همپوشانی دارند، اما یکی نیستند. رمزنگاری و کنترل دسترسی میتوانند از افشای غیرمجاز جلوگیری کنند؛ بااینحال جمعآوری دادهٔ غیرضروری، استفاده برای هدف جدید، retention بیپایان یا رضایت فریبنده حتی در سامانهای امن نیز مسئلهٔ حریم خصوصی است. برای طراحی ارزیابی گستردهتر استانداردها، راهنمای تست انطباق را نیز ببینید.
اول شمول را تعیین کنید؛ نام قانون Test Case نیست
یک ماتریس Applicability بسازید. هر سطر باید قانون/قرارداد، محصول و بازار، نوع داده، نقش سازمان، فعالیت پردازش، استثنا، مالک تصمیم و تاریخ بازبینی را داشته باشد. «کاربر خارجی داریم» یا «داده سلامت است» بهتنهایی پاسخ شمول نیست.
| چارچوب | پرسش شمول | اشتباه رایج | تمرکز نمونهٔ QA |
|---|---|---|---|
| GDPR | آیا پردازش در چارچوب establishment اتحادیه است یا کالا/خدمت به اشخاص در اتحادیه عرضه یا رفتار آنان پایش میشود؟ نقش controller/processor چیست؟ | تبدیل آن به «هر دادهٔ هر شهروند اروپایی در هر جای جهان» | اصول پردازش، شفافیت، مبنا، حقوق شخص، privacy by design، security، breach و انتقال تأییدشده |
| CCPA، اصلاحشده با CPRA | آیا سازمان/فعالیت مشمول تعریف و آستانههاست و داده متعلق به مصرفکنندهٔ کالیفرنیاست؟ sale/share، service provider و استثناها چگونه تعیین شدهاند؟ | یکی گرفتن هر انتقال داده با sale یا نادیده گرفتن share و GPC | notice at collection، know/delete/correct، opt-out sale/share، limit و non-discrimination طبق Requirement |
| HIPAA | آیا سازمان covered entity یا business associate است و داده PHI/ePHI در دامنه است؟ قرارداد BA چه میگوید؟ | فرض اینکه هر اپ سلامت یا هر دادهٔ پزشکی خودکار مشمول HIPAA است | Privacy/Security/Breach Rules، minimum necessary، access، audit و safeguards تأییدشده |
| ایران و الزامات بخشی | کدام قانون، مقررهٔ بخشی، قرارداد و سیاست برای فعالیت و نوع داده اعمال میشود؟ | معادل دانستن یک مادهٔ داخلی با کل GDPR یا فرض نبود هیچ الزام | هدف، تناسب جمعآوری، صحت، دسترسی/اصلاح/حذف، رضایت صریح در موارد مربوط و الزامات بخشی |
GDPR: دامنه، اصل و حق را جدا کنید
متن اصلی Regulation (EU) 2016/679 مرجع نهایی است. مادهٔ ۳ دامنهٔ سرزمینی را تعریف میکند؛ مادهٔ ۵ اصولی مانند قانونمندی و شفافیت، محدودیت هدف، کمینهسازی، صحت، محدودیت نگهداری، تمامیت/محرمانگی و پاسخگویی را؛ فصل سوم حقوق اشخاص را؛ و مواد ۲۵، ۳۲، ۳۳ و ۳۵ به design/default، امنیت، اعلام breach و DPIA مربوطاند.
رضایت تنها مبنای ممکن پردازش در GDPR نیست. ابتدا حقوقی مبنای هر purpose را تعیین میکند؛ QA فقط در پردازشی که بر رضایت تکیه دارد، معتبر بودن مسیر کسب/پسگیری و اعمال آن را میآزماید. دادهٔ pseudonymized یا رمزشده نیز اگر امکان نسبتدادن مجدد داشته باشد لزوماً از قلمرو دادهٔ شخصی خارج نیست؛ توضیح رسمی کمیسیون اروپا دربارهٔ دادهٔ شخصی این تمایز را روشن میکند.
CCPA/CPRA: حقها و signal فنی را فراموش نکنید
CPRA قانون جداگانهای که جای CCPA را گرفته باشد نیست؛ CCPA را اصلاح کرده است. صفحهٔ رسمی دادستان کل کالیفرنیا دربارهٔ CCPA حقوق know، delete، opt-out از sale/share، correct، limit برای sensitive personal information و non-discrimination را شرح میدهد. برای کانال آنلاین، Global Privacy Control میتواند یک signal قابل آزمون باشد.
تیم QA نباید definition حقوقی sale، sharing یا sensitive information را از روی نام API حدس بزند. data flow و قرارداد طرف ثالث را به حقوقی میدهد، تصمیم را به Requirement نسخهدار تبدیل میکند و سپس بررسی میکند signal در همهٔ مسیرهای مربوط—مرورگر، app، anonymous session، authenticated account و SDKها—واقعاً اعمال میشود.
HIPAA: هر اپ سلامت مشمول نیست
طبق راهنمای رسمی CMS دربارهٔ HIPAA، قواعد برای Covered Entityها و Business Associateهای منطبق با تعریف اعمال میشود. اگر یک اپ این نقشها را ندارد، نتیجهٔ شمول ممکن است متفاوت باشد و قوانین یا قراردادهای دیگری مطرح شوند.
Privacy Rule استفاده و افشای PHI را پوشش میدهد؛ HIPAA Security Rule بر محرمانگی، تمامیت و دسترسپذیری ePHI و safeguardهای اداری، فیزیکی و فنی تمرکز دارد؛ و Breach Notification Rule فرایند ارزیابی و اعلان را تنظیم میکند. پیشنهادهای اصلاحی را تا نهایی و لازمالاجرا شدن با Rule جاری یکی نگیرید.
محصول ایرانی: قانون داخلی و تعهد فرامرزی را همزمان ببینید
برای فعالیت در ایران، مواد ۵۸ تا ۶۱ قانون تجارت الکترونیکی در WIPO Lex در بستر مبادلات الکترونیکی به دادهپیام شخصی، رضایت صریح برای دستههای ذکرشده، هدف مشخص، ضرورت و تناسب، صحت و دسترسی/اصلاح/محو میپردازد. این مواد را نباید معادل یک قانون جامع خارجی فرض کرد؛ متن فارسی معتبر، مقررات بخشی، قراردادها و آخرین وضعیت حقوقی باید جدا بررسی شوند.
یک شرکت ایرانی ممکن است علاوه بر قواعد داخلی، بهخاطر بازار هدف، نقش قراردادی یا پردازش برونمرزی تعهد دیگری داشته باشد. این تصمیم را از IP یا زبان رابط کاربری استنتاج نکنید. Legal Matrix باید محصول/بازار/نقش و تاریخ ارزیابی را ثبت کند.
از قانون تا Requirement قابل آزمون
عبارت «داده باید بهموقع حذف شود» برای تست کافی نیست. Requirement باید به این شکل شکسته شود:
- Source: ماده، مقرره، قرارداد یا سیاست و نسخه/تاریخ آن؛
- Applicability: محصول، نقش، jurisdiction، نوع شخص و نوع داده؛
- Processing purpose و basis: چرا و با کدام تصمیم تأییدشده پردازش میشود؛
- Trigger: درخواست، انقضای retention، withdraw، opt-out یا رخداد breach؛
- Expected state: حذف، restriction، export، تصحیح، suppression یا نگهداری مستثنا؛
- Deadline/exception: مقدار مصوب حقوقی و دلیل هر توقف؛
- Systems: همهٔ storeها، cacheها، queueها، logها، backupها و processorها؛
- Evidence: event، audit record، query کنترلشده، receipt و approval؛
- Owner: تیم پاسخگو برای اجرای control و تصمیم residual risk.
برای جلوگیری از تقلیل الزامات به checklist ثابت، از NIST Privacy Framework بهعنوان زبان مدیریت ریسک داوطلبانه استفاده کنید: فعالیت پردازش و اکوسیستم را بشناسید، governance را تعیین کنید و نتایج Control، Communicate و Protect را به Current/Target Profile وصل کنید. خود Framework قانون یا گواهی انطباق نیست.
پایهٔ تست: inventory، data flow و subject graph
فهرست داده و purpose
برای هر data element بنویسید: نام کسبوکاری، field/schema، دستهبندی حساسیت، شخص مرتبط، منبع، purpose، مبنا، مقصد، retention، محل ذخیره، processor، دسترسیها و owner. «PII» یک برچسب کافی نیست؛ شمارهٔ موبایل، شناسهٔ تبلیغاتی، IP، دادهٔ سلامت، موقعیت، لاگ رفتار و دادهٔ استنباطی ریسک و الزامات یکسان ندارند.
نقشهٔ جریان واقعی، نه فقط معماری روی اسلاید
Browser/App → API Gateway → Service → Database → Cache → Queue → Search → Analytics → Data Lake → Support Export → Vendor → Backup را دنبال کنید. network capture، code/config scan، schema catalog و log observation را با diagram مقایسه کنید. SDK تبلیغات یا crash reporting ممکن است مقصدی بسازد که در مستند طراحی نیست.
برای مخزنهای تحلیلی و مسیرهای export، کنترلهای مکمل در راهنمای امنیت و حریم خصوصی دریاچهٔ داده آمده است.
Subject graph
درخواست access/delete معمولاً با یک شناسه پیدا نمیشود. کاربر ممکن است UUID، شمارهٔ موبایل قدیم و جدید، ایمیل، device ID، شناسهٔ سفارش، شناسهٔ کیف پول و ticket پشتیبانی داشته باشد. Subject graph مشخص میکند چه کلیدهایی با چه confidence به یک شخص مربوطاند و کدام پیوند نیازمند بررسی انسانی است.
برای فارسی، شکلهای «ی/ی» و «ک/ک»، ارقام فارسی/عربی/لاتین، فاصله و نیمفاصله، پیششمارهٔ +98/0 و تغییر شماره را تست کنید. normalization نباید باعث ادغام دو فرد شود؛ fuzzy match بدون کنترل میتواند دادهٔ شخص دیگری را در export یا deletion وارد کند.
آزمون جمعآوری، notice و consent
Notice باید با رفتار واقعی همخوان باشد
در هر نقطهٔ جمعآوری بررسی کنید notice قابل دسترس و قابل فهم است و دستهٔ داده، purpose، گیرنده و انتخابهای مصوب را منعکس میکند. سپس با network/log/schema ثابت کنید محصول همان چیزی را میفرستد که اعلام کرده است. داشتن لینک سیاست حریم خصوصی، ارسال پنهان device ID به SDK را مجاز یا آزمونشده نمیکند.
رضایت را فقط جایی تست کنید که مبنا رضایت است
برای هر purpose مبتنی بر consent، این سناریوها را اجرا کنید:
- پیشفرض خاموش و اقدام affirmative مطابق Requirement؛
- تفکیک purposeها بهجای یک انتخاب اجباری مبهم؛
- ثبت نسخهٔ notice، زمان، کانال، subject و وضعیت؛
- withdraw به سادگی مسیر opt-in و بدون ادامهٔ پردازش مربوط؛
- همگامشدن انتخاب در app، web، backend و vendor؛
- رفتار کاربر مهمان، چند دستگاه، reinstall و پاکشدن cookie؛
- عدم ایجاد dark pattern در رنگ، ترتیب، تعداد کلیک و پیام خطا.
withdraw معمولاً پردازش قبلی را بهصورت جادویی نامعتبر نمیکند و همهٔ دادهها را هم لزوماً حذف نمیکند؛ رفتار دقیق از basis، purpose و retention Requirement میآید. Test Oracle را خود تیم QA اختراع نکند.
مجوزهای موبایل و SDKها
permission را در لحظهٔ نیاز درخواست کنید، denial و «دیگر نپرس» را بدون loop و اجبار مدیریت کنید و پس از revoke، fallback امن داشته باشید. دسترسی clipboard، contact، photo، precise location، notification content، screenshot/app switcher و backup دستگاه را بر اساس ریسک تست کنید. برای امنیت client و API، راهنمای تست امنیت اپلیکیشن موبایل را به این برنامه پیوند دهید.
تست حقوق اشخاص و درخواستهای حریم خصوصی
یک DSAR را workflow انتهابهانتها ببینید: intake → authentication/verification → scope → discovery → review/redaction → fulfillment/denial → downstream propagation → audit → closure. هر قانون همهٔ این حقوق را با تعریف یکسان نمیدهد؛ تنها سطرهای Legal Matrix را اجرا کنید.
دسترسی و export
- خروجی همهٔ storeهای در Scope را پوشش میدهد و دادهٔ فرد دیگر را ندارد.
- fieldها، source، purpose و recipient مطابق Requirement توضیح داده میشوند.
- فایل ساختیافته parse میشود، encoding فارسی سالم است و timestamp/timezone روشن است.
- لینک download محدود، یکبارمصرف یا منقضی و در برابر enumeration مقاوم است.
- redaction استثناها دادهٔ شخص دیگر یا راز امنیتی را محافظت میکند.
- partial failure پنهان نمیشود و پرونده بیدلیل Completed علامت نمیخورد.
تصحیح
تصحیح را فقط در profile screen نبینید. تغییر باید به source of truth و replicaهای مجاز برسد، cache را invalid کند و محاسبات مشتقشدهای را که Requirement شامل کرده دوباره بسازد. تضاد با رکورد قانونی/مالی باید به مسیر review یا exception برود، نه overwrite خاموش.
حذف و حق فراموششدن
یک deletion manifest بسازید: برای هر system حالت expected را Delete، Anonymize، Restrict، Retain-with-justification یا Not-present تعیین کنید. سناریوهای success، retry، timeout، vendor failure، legal hold، account recreation و restore از backup را اجرا کنید.
Soft delete پایان تست نیست. اگر رکورد قابل query، export، analytics یا support باشد هنوز پردازش ادامه دارد. از سوی دیگر، «حذف فوری همهٔ backupها» ممکن است معماری یا Requirement صحیح نباشد. سیاست مصوب میتواند backup را تا انقضا غیرقابل استفادهٔ عادی کند و پس از restore، tombstone/suppression را دوباره اعمال کند. QA باید همین رفتار و عدم بازگشت حساب حذفشده را در تمرین restore اثبات کند.
اعتراض، restriction، opt-out و GPC
حالت privacy preference را مثل state machine تست کنید. signal ورودی باید نسخهدار و audit شود، پردازشهای مربوط متوقف شوند، cache و audience تبلیغاتی بهروزرسانی شوند و vendor acknowledgment دریافت شود. GPC را در نخستین بازدید، user مهمان، login بعدی، چند subdomain و تغییر مرورگر آزمایش کنید؛ اعمال آن را از روی مخفی شدن banner نتیجه نگیرید—درخواستهای واقعی شبکه را ببینید.
احراز هویت بدون جمعآوری افراطی
تحویل export به مهاجم یک breach است؛ درخواست مدرک بیش از حد هم ریسک جدید میسازد. سطح verification را بر اساس حساسیت و سیاست مصوب تست کنید. پاسخها نباید وجود حساب فرد دیگر را لو دهند. rate limit، delegated/authorized agent، حساب قفلشده، کاربر فوتشده یا کودک تنها زمانی آزموده شوند که Requirement مربوط وجود دارد.
کمینهسازی، هدف و استفادهٔ ثانویه
برای هر field سه سؤال بپرسید: آیا جمع میشود؟ آیا لازم است؟ آیا فقط برای purpose مصوب استفاده میشود؟ سپس این تستها را بسازید:
- حذف field اختیاری از request و مشاهدهٔ ادامهٔ صحیح journey؛
- جلوگیری از ارسال field حساس به analytics، log، crash dump و notification؛
- مقایسهٔ payload واقعی با schema allowlist؛
- آزمون feature flag جدید برای reuse دادهٔ قدیمی؛
- بررسی default privacy-preserving برای حساب تازه؛
- کنترل query/export تا فقط ستون و بازهٔ لازم به role برسد؛
- آزمون دادهٔ مشتقشده و profileهایی که از چند source ساخته میشوند.
کمینهسازی فقط حذف فیلد فرم نیست. metadata، IP، header، device fingerprint، free-text، تصویر و دادهٔ telemetry نیز میتوانند شخص را شناسایی یا دربارهٔ او استنباط ایجاد کنند.
Retention و حذف انتهابهانتها
ساعت retention از کجا شروع میشود؟
Trigger را مشخص کنید: زمان جمعآوری، پایان قرارداد، آخرین فعالیت، closure پرونده یا رویداد حقوقی. timezone را ثابت کنید؛ اختلاف تهران و UTC یا سال کبیسه میتواند رکورد را زود یا دیر حذف کند. boundaryهای یک لحظه قبل، دقیقاً در deadline و یک لحظه بعد را تست کنید.
هر کپی یک تعهد است
Primary DB، read replica، cache، object storage، search index، message queue/DLQ، data warehouse/lake، feature store، log/APM، فایل spreadsheet، ایمیل support، vendor و backup را در manifest بیاورید. نتیجهٔ job مرکزی فقط وقتی سبز است که acknowledgment مقصدها و query کنترلشده آن را تأیید کنند.
Legal hold و استثنا
استثنا به معنی «کاری نکن و توضیح نده» نیست. scope، authority، reason code، approval، expiry و access محدود را ثبت کنید. وقتی hold تمام شد، deletion دوباره صف شود. کاربر باید پاسخ مناسب و مصوب بگیرد، بیآنکه اطلاعات محرمانه یا دادهٔ دیگران افشا شود.
طرف ثالث، انتقال و زنجیرهٔ پردازش
فهرست vendor را با مشاهدهٔ runtime تطبیق دهید: analytics، تبلیغات، پیامک، ایمیل، پرداخت، crash report، cloud، support و AI API. برای هرکدام purpose، داده، role قراردادی، region، retention، subprocessors، مسیر DSAR/deletion، incident contact و evidence را ثبت کنید.
QA دربارهٔ قانونی بودن سازوکار انتقال تصمیم نمیگیرد؛ configuration و مسیر واقعی را با تصمیم حقوقی میسنجد. region failover، disaster recovery، DNS، CDN، object replication و log destination ممکن است داده را خارج از مقصد پیشبینیشده ببرند. یک تست failure/failover اغلب تفاوت diagram و واقعیت را آشکار میکند.
کنترل دسترسی، audit و breach
دسترسی مؤثر
ماتریس Persona × Data × Action × Channel بسازید: خود کاربر، پشتیبان سطح ۱ و ۲، پزشک، تحلیلگر، ادمین، service account و vendor؛ در UI، API، export، database، object storage و admin tool. deny باید در لایهٔ واقعی داده enforce شود، نه فقط با مخفی کردن دکمه.
لاگ هم دادهٔ شخصی است
Audit باید چه کسی/سرویس، چه رکوردی، چه عملی، چه زمانی، از کدام channel و با چه نتیجهای را ثبت کند؛ اما نباید token، رمز، متن کامل پرونده یا payload حساس را بیدلیل کپی کند. tamper resistance، دسترسی، clock sync، retention و query incident را تست کنید. traceability خوب به معنی ثبت همهچیز نیست.
تمرین breach بدون آسیب
یک tabletop و simulation مجاز اجرا کنید: رخداد مصنوعی → detection → classification → containment → شمارش اشخاص/داده → risk assessment → تصمیم notification → آمادهسازی evidence → recovery. clock و escalation را بر اساس policy مصوب بسنجید. دادهٔ واقعی را برای شبیهسازی leak خارج نکنید و حملهٔ مخرب بدون authorization انجام ندهید.
دادهٔ تست بدون ساختن breach جدید
اصل پیشفرض: دادهٔ مصنوعی با referential integrity و edge caseهای واقعی. دادهٔ Production را صرفاً با تغییر نام «ناشناس» نخوانید. hashing سادهٔ شمارهٔ ملی یا موبایل، مخصوصاً در فضای مقادیر قابل حدس، anonymization قابل اتکا نیست.
برای انتخاب میان synthetic، masked و subset، راهنمای مدیریت دادهٔ تست را ببینید و برای ساخت corpusهای کنترلشده از تکنیکهای تولید دادهٔ تست استفاده کنید. در هر حالت:
- مجوز و owner داده روشن باشد؛
- محیط تست access، encryption، logging و retention مستقل داشته باشد؛
- export و snapshot خودکار تاریخ انقضا داشته باشند؛
- ticket، screenshot و ویدئو payload حساس را ماسک کنند؛
- seed مصنوعی همهٔ حروف/ارقام فارسی، طولها، چند حساب و تضاد شناسه را پوشش دهد؛
- پس از تست privacy، خود داده و artifactهای آن پاک شوند.
اتوماسیون و CI/CD
اتوماسیون برای invariants پایدار مناسب است، نه تفسیر حقوق:
- schema/contract test برای جلوگیری از field جدید بدون classification و owner؛
- payload allowlist برای analytics، log و vendor endpoint؛
- تست state machine رضایت/opt-out و نبود event ممنوع پس از آن؛
- DSAR fixture چندسیستمی و assertion برای عدم cross-user leakage؛
- retention job با clock کنترلشده و boundary test؛
- deletion manifest و acknowledgment همهٔ مقصدها؛
- secret/PII scanning در log و artifact با rule بازبینیشده؛
- policy/config check برای region، bucket، backup و access؛
- restore drill دورهای برای اطمینان از اعمال مجدد tombstoneها.
lane سبک را در PR، تست چندسرویسی را شبانه و restore/vendor/breach drill را دورهای اجرا کنید. waiver باید owner، دلیل، scope و expiry داشته باشد. برای طراحی lane و feedback، تست پیوسته در DevOps را به برنامه وصل کنید.
نمونهٔ ایرانی: پلتفرم نوبت و مشاورهٔ پزشکی
این سناریو فرضی است. محصول نام، شمارهٔ موبایل، کد ملی، اطلاعات نوبت، نسخه/شرح پزشکی، مکالمه، پرداخت ریالی و device telemetry دارد و از سرویس پیامک، PSP، analytics و زیرساخت ابری استفاده میکند.
گام ۱: ماتریس شمول
حقوقی مشخص میکند محصول در ایران زیر کدام قوانین و مقررات سلامت/تجارت/قرارداد است. اگر خدمت واقعاً به افراد در اتحادیه عرضه میشود یا نقش قراردادی با entity آمریکایی دارد، GDPR/HIPAA جدا ارزیابی میشوند؛ صرف نمایش انگلیسی یا ذخیرهٔ یک پروندهٔ پزشکی این نتیجه را خودکار نمیسازد. هر تصمیم owner و review date دارد.
گام ۲: جریان و purpose
برای کد ملی purpose احراز/پرونده، برای شماره purpose ورود و یادآوری، برای دادهٔ پزشکی purpose درمان و برای telemetry purpose پایداری تعیین میشود. payload واقعی نشان میدهد متن تشخیص اشتباهاً به crash reporter رفته و شمارهٔ موبایل در نام فایل support export مانده است؛ هر دو خارج از طراحی اصلاح میشوند.
گام ۳: حقوق و retention
Fixture یک بیمار با ارقام فارسی، حساب قدیمی و جدید و چند نوبت میسازد. access export باید تمام دادهٔ مصوب و فقط دادهٔ همان بیمار را بدهد. correction نباید رکورد پزشکی امضاشده را بیردپا overwrite کند؛ مسیر amendment طبق policy اجرا میشود. deletion برای marketing/analytics اعمال میشود، در حالی که رکورد دارای الزام نگهداری به حالت Restricted با reason/expiry میرود.
گام ۴: vendor و restore
پس از opt-out، پیام تبلیغاتی و event تبلیغاتی متوقف میشود اما OTP خدمت ادامه دارد، چون purposeها جدا هستند. سرویس پیامک و analytics acknowledgment میدهند. در restore backup آزمایشی، suppression ledger پیش از فعال شدن سرویس replay میشود تا حساب حذفشده دوباره قابل جستوجو نشود.
گام ۵: شواهد تصمیم
گزارش نهایی شامل Legal Requirement ID، data-flow نسخهدار، build، dataset مصنوعی، request/correlation ID، نتیجهٔ هر مقصد، screenshot ماسکشده، query کنترلشده، exception approval و residual risk است. این evidence pack از جملهٔ مبهم «حذف تست شد» بسیار قابل دفاعتر است.
معیارهای مفید برای برنامهٔ حریم خصوصی
- درصد processing activityهای دارای owner، purpose، basis و retention تأییدشده؛
- درصد destinationهای مشاهدهشده در runtime که در inventory ثبتاند؛
- پوشش Requirement به Test و Evidence، تفکیکشده بر ریسک؛
- نرخ DSAR کامل، ناقص، خطادار و overdue بر اساس policy؛
- درصد deletion مقصدها با acknowledgment و تعداد کپیهای orphan؛
- میانگین زمان کشف field/vendor جدید و تعیین owner؛
- waiverهای منقضی و legal holdهای بدون review؛
- نرخ leak دادهٔ حساس در log، analytics و test artifact؛
- زمان triage و کیفیت evidence در breach drill؛
- نرخ رگرسیون privacy پس از تغییر schema، SDK یا vendor.
«تعداد test case» یا «صفر شدن scanner finding» بهتنهایی outcome حریم خصوصی نیست. metric را با guardrail همراه کنید؛ سریعتر شدن DSAR نباید verification را ضعیف و کمشدن log نباید investigation را ناممکن کند.
خطاهای رایج
- یک checklist برای سه قانون: شمول، تعریفها، حقوق و استثناها متفاوتاند.
- QA بهعنوان وکیل: تیم تست Requirement را راستیآزمایی میکند، نه دامنهٔ قانون را حدس میزند.
- رضایت برای همهچیز: basis باید برای هر purpose تأیید شود.
- Privacy policy برابر رفتار: network، storage و vendor واقعی را مشاهده کنید.
- Soft delete برابر حذف: queryability، replica، analytics، vendor و restore را بسنجید.
- Encryption برابر anonymization: قابلیت link/re-identification را بررسی کنید.
- همهٔ اپهای سلامت برابر HIPAA: covered role و PHI/ePHI را از منبع رسمی تعیین کنید.
- هر انتقال برابر sale: definition و role قراردادی CCPA را حقوقی تعیین میکند.
- دادهٔ Production در QA: «فقط برای یک تست» هم processing و ریسک جدید میسازد.
- ثبت payload کامل برای evidence: مدرک انطباق نباید خودش محل نشت باشد.
- نادیده گرفتن failure: timeout، retry، partial completion و vendor outage هستهٔ privacy workflow هستند.
- تست یکباره: schema، SDK، قانون، قرارداد و معماری تغییر میکنند.
چکلیست نهایی تیم QA
- Applicability Matrix توسط مالک حقوقی تأیید و تاریخدار است.
- هر Requirement به منبع، purpose، role، deadline، exception و owner وصل است.
- inventory با جریان runtime و vendorهای واقعی تطبیق داده شده است.
- subject graph و normalization فارسی بدون cross-user match آزموده شدهاند.
- notice و رفتار جمعآوری/اشتراک همخواناند.
- consent/withdraw/opt-out فقط در دامنهٔ درست و در تمام channelها اعمال میشوند.
- access، correct، delete، restrict و portabilityِ applicable انتهابهانتها تست شدهاند.
- retention، queue، log، warehouse، vendor، backup و restore در manifest هستند.
- دسترسی مؤثر، audit کمینه و breach drill شواهد کافی دارند.
- داده و artifact تست مصنوعی/محافظتشدهاند و expiry دارند.
- regressionهای پایدار در lane مناسب CI اجرا میشوند.
- waiver، exception، legal hold و residual risk مالک و تاریخ بازبینی دارند.
سؤالات متداول
آیا تیم QA میتواند انطباق با GDPR، CCPA یا HIPAA را تأیید کند؟
QA میتواند پیادهسازی Requirementهای تأییدشده و کیفیت شواهد را تأیید کند؛ صدور نظر کلی حقوقی نیازمند بررسی دامنه، قرارداد، فرایندهای غیرفنی و استثناها توسط مسئولان مربوط است. گزارش دقیق Scope و residual risk از برچسب کلی «compliant» معتبرتر است.
آیا برای هر پردازش داده در GDPR رضایت لازم است؟
خیر. GDPR چند مبنای قانونی برای پردازش دارد. حقوقی باید basis هر purpose را مشخص کند. QA در موارد مبتنی بر consent، کسب رضایت معتبر، ثبت، granular choice و withdrawal را میآزماید و در مبانی دیگر رفتار متناظر را طبق Requirement بررسی میکند.
آیا حذف از دیتابیس اصلی برای تست حق حذف کافی است؟
معمولاً نه. cache، queue، search، analytics، data lake، log، export، vendor و backup باید طبق deletion manifest و استثناهای مصوب تعیین تکلیف شوند. تمرین restore باید نشان دهد دادهٔ حذفشده دوباره فعال نمیشود.
آیا دادهٔ سلامت در هر اپی مشمول HIPAA است؟
خیر. HHS شمول را به Covered Entity و Business Associate و دادهٔ PHI/ePHI در Scope پیوند میدهد. اپهای دیگر ممکن است زیر قواعد یا قراردادهای دیگری باشند. نقش و جریان داده را پیش از ساخت HIPAA test suite تعیین کنید.
بهترین داده برای تست حریم خصوصی چیست؟
پیشفرض مناسب، دادهٔ مصنوعی است که روابط، توزیع و edge caseهای لازم را بدون هویت واقعی بازسازی میکند. اگر masked/subset لازم است، risk assessment، مجوز، کنترل محیط، retention و آزمون re-identification باید مصوب و مستند باشد.
جمعبندی
تست حریم خصوصی موفق از banner رضایت یا vulnerability scan شروع نمیشود؛ از پاسخ روشن به «کدام داده، برای کدام شخص، با چه هدف و مبنا، در کدام سامانه و تحت کدام الزام» آغاز میشود. قانون و قرارداد را به Requirement نسخهدار تبدیل کنید، جریان واقعی و همهٔ کپیها را ببینید، حقوق اشخاص و failureها را انتهابهانتها اجرا کنید و evidence کمینه اما قابل ردیابی بسازید. در این چارچوب، QA ادعای حقوقی بزرگ نمیکند؛ شواهد فنی محکمی میسازد که محصول، حقوقی، امنیت و مدیریت بتوانند بر اساس آن تصمیم مسئولانه بگیرند.
