Data Classification, Retention, Export و Deletion

خروجی محدود درس

مدیریت داده زمانی خطرناک می‌شود که Classification، Retention، Export و Deletion به چهار چک‌لیست جدا تبدیل شوند. خروجی محدود این درس ساخت یک مدل lifecycle محلی و قابل بازرسی است که برای هر رکورد synthetic، data class، purpose، owner، retention trigger/condition، export scope، deletion scope، hold state و evidence of disposition را به هم وصل می‌کند. مقصد evidence، Data Lifecycle Policy Evidence Record v1 است و محیط اجرایی SEC011-LAB1 کاملاً local و synthetic باقی می‌ماند.

این درس قانون یک کشور، دوره نگهداری قانونی واحد یا گواهی compliance تولید نمی‌کند. NIST Privacy Framework در این درس فقط برای مفاهیم risk-based privacy/data-processing lifecycle استفاده می‌شود. هیچ عددی که در fixture می‌بینید الزام حقوقی نیست؛ همه windowها با برچسب SYNTHETIC_INTERNAL_POLICY تعریف شده‌اند. Positive Evidence و Negative Evidence باید از اجرای محلی به دست آیند، نه از حدس یا متن از پیش‌پرشده.

1. Classification قبل از lifecycle policy

اولین خطا این است که همه داده‌ها را «داده» ببینیم و سپس یک retention یا export rule واحد روی همه اعمال کنیم. یک رکورد فقط با نام فیلدها تعریف نمی‌شود؛ purpose و owner نیز بخشی از تصمیم هستند. در fixture، سه کلاس محدود داریم: operational_profile، audit_event و attachment_metadata. این taxonomy جهانی نیست و فقط یک مدل آموزشی ثابت است.

در SEC011-LAB1 اگر یک رکورد با data_class=operational_profile به‌طور مصنوعی به audit_event تغییر کند، policy باید lifecycle متفاوتی برگرداند. این mutation نشان می‌دهد classification واقعاً روی تصمیم اثر دارد. اگر تغییر class هیچ اثری نداشته باشد، مدل فقط برچسب‌گذاری تزئینی انجام داده است.

2. Purpose و owner بخشی از boundary هستند

یک داده ممکن است از نظر شکل یکسان باشد ولی برای purpose دیگری پردازش شود. lifecycle record باید نشان دهد چه کسی owner تصمیم است و purpose اعلام‌شده چیست. داشتن copy از داده به‌تنهایی export authority ایجاد نمی‌کند و visibility نیز retention authority نمی‌سازد.

policy محلی هر data class را به purpose و owner مشخص bind می‌کند. mismatch بین record و policy با DENY_CLASS_PURPOSE_OWNER_MISMATCH رد می‌شود. هدف این check اثبات قانون یا compliance نیست؛ فقط از این shortcut جلوگیری می‌کند که «چون داده نزد سیستم است، هر lifecycle action مجاز است».

3. Retention یک trigger و exit condition می‌خواهد

عبارت‌هایی مثل «این داده را ۳۰ روز نگه می‌داریم» بدون trigger و authority قابل دفاع نیستند. ۳۰ روز از چه زمانی؟ چه کسی owner است؟ چه exceptionی وجود دارد؟ چه چیزی پایان retention را ثابت می‌کند؟ در این درس هر retention decision چهار جزء دارد: trigger، condition، policy_authority و exit_condition.

fixture از windowهای synthetic استفاده می‌کند؛ مثلاً synthetic_30d_after_case_close یا synthetic_180d_after_event. اینها legal requirement نیستند. Negative Evidence زمانی ایجاد می‌شود که رکورد class/purpose نامعتبر باشد یا retention rule وجود نداشته باشد. یک decision معتبر باید صریحاً بگوید که نتیجه فقط درون policy آموزشی همین fixture معتبر است.

4. Export یعنی authorization + minimization + provenance

توانایی خواندن داده به معنی اجازه export نیست. export request باید requester، purpose، data class و requested fields داشته باشد. policy سپس بررسی می‌کند آیا requester برای همان class مجاز است و آیا requested fields زیرمجموعه allowlist هستند.

در baseline، role:support-exporter فقط برای operational_profile و فقط برای فیلدهای محدود synthetic مجاز است. درخواست فیلد internal_trace عمداً بیش از scope است و باید DENY_EXPORT_FIELD_SCOPE بدهد. این یک probe دفاعی است؛ هیچ داده شخصی واقعی یا endpoint خارجی وجود ندارد.

5. Data possession ≠ export authority

یکی از shortcutهای رایج این است که سرویس چون داده را در اختیار دارد، خودکار حق export هم داشته باشد. SEC011-LAB1 این shortcut را مستقیم تست می‌کند. role:analytics-reader ممکن است در changed-context dataset یک consumer باشد، اما بدون policy row مستقل export مجاز نیست.

Evidence باید requester، requested fields، decision و policy basis را نگه دارد. اگر فقط فایل خروجی ذخیره شود ولی تصمیم authorization ثبت نشود، provenance ناقص است. Data Lifecycle Policy Evidence Record v1 باید observation و inference را جدا کند.

6. Deletion فقط UI invisibility نیست

حذف یک row از صفحه یا حتی primary table به‌تنهایی proof of disposition نیست. یک data lifecycle می‌تواند primary copy، derivative copy و backup boundary داشته باشد. این درس ادعا نمی‌کند backup باید فوری rewrite شود؛ فقط می‌خواهد scope deletion و evidence قابل مشاهده باشد.

در fixture اگر primary_disposed=true باشد اما derived_disposed=false و backup boundary ثبت نشده باشد، نتیجه DENY_DELETION_EVIDENCE_INCOMPLETE است. یک bounded completion زمانی پذیرفته می‌شود که primary و derivative owned copyها disposed باشند و backup boundary به‌صورت DOCUMENTED_EXPIRY_BOUNDARY ثبت شود. این تصمیم به معنی erasure جهانی نیست.

7. Hold یک governed state است، نه فراموش‌کردن policy

گاهی normal lifecycle باید موقتاً متوقف شود. hold نباید با حذف policy یا retention نامحدود اشتباه شود. hold به owner، reason و state صریح نیاز دارد. وقتی hold فعال است، deletion با DELETE_SUSPENDED_HOLD متوقف می‌شود و reason در evidence باقی می‌ماند.

Hold authority در این fixture SYNTHETIC_POLICY_HOLD است. این عبارت هیچ ادعای حقوقی ندارد. Negative Evidence مهم این است که حتی اگر بقیه deletion evidence کامل باشد، hold فعال باید حذف را متوقف کند.

8. Evidence of disposition باید قابل trace باشد

برای هر lifecycle action، evidence باید به record ID، data class، purpose، owner و observed decision وصل شود. عبارت «حذف شد» یا «export امن بود» بدون trace ضعیف است. evidence row در این درس ده ستون دارد: Data Class / Purpose / Owner / Retention Trigger / Retention Condition / Export Scope / Deletion Scope / Hold State / Observed Evidence / Residual Boundary.

evidence_row_complete() وجود همه ستون‌ها را بررسی می‌کند و field خالی را قبول نمی‌کند. این check جای review انسانی را نمی‌گیرد؛ فقط مانع از این می‌شود که artifact ناقص به‌عنوان proof نهایی عبور کند.

9. Positive Evidence

Baseline سه نوع evidence مثبت تولید می‌کند. اول، record با class/purpose/owner درست یک retention decision محدود می‌گیرد. دوم، export با requester و field scope درست ALLOW_EXPORT_MINIMIZED می‌شود. سوم، deletion با owned-copy disposition کامل و backup boundary مستند به DELETE_BOUNDED_DISPOSITION_RECORDED می‌رسد.

این Positive Evidence فقط رفتار fixture را نشان می‌دهد. از آن نمی‌توان نتیجه گرفت که سازمانی در production یا در jurisdiction خاص compliant است. عبارت production_proof=false در policy دقیقاً برای جلوگیری از همین overclaim وجود دارد.

10. Negative Evidence

Negative Evidence اجباری است. Probeهای اصلی شامل class mutation، over-broad export، hold-active deletion، incomplete disposition و missing evidence field هستند. هر probe باید قبل از اجرا prediction داشته باشد و بعد raw observable را نگه دارد.

هدف «شکستن سیستم» نیست؛ هدف دیدن control boundary در یک مدل harmless است. هیچ exploit، credential، personal data یا network target در lab وجود ندارد. اگر learner فقط happy path را ذخیره کند، artifact ناقص است.

11. Classification mutation

در mutation اول، یک رکورد از operational_profile به audit_event تغییر می‌کند. اگر purpose/owner به همان مقادیر قبلی بماند، evaluator باید mismatch را رد کند. اگر رکورد کامل به context جدید rebuild شود، retention rule باید از operational rule به audit rule تغییر کند.

این probe نشان می‌دهد policy به semantics وابسته است، نه صرفاً record ID. همچنین از copy/paste lifecycle جلوگیری می‌کند.

12. Over-broad export mutation

در mutation دوم، requester یک field خارج از allowlist می‌خواهد. درخواست باید رد شود حتی اگر requester برای class پایه مجاز باشد. این تفاوت بین authorization سطح action و minimization سطح field را واضح می‌کند.

ثبت denied export مهم است، چون بعداً owner می‌تواند ببیند کدام shortcut امتحان شده و چرا رد شده است. حذف این negative row باعث می‌شود review فقط success story ببیند.

13. Hold mutation

در mutation سوم، hold با reason و owner مصنوعی فعال می‌شود. deletion باید متوقف شود. بعد از رفع hold، policy اصلی دوباره قابل ارزیابی است. این sequence نشان می‌دهد hold exception policy را پاک نمی‌کند؛ فقط normal transition را در یک state governed متوقف می‌کند.

یک hold بدون reason یا owner معتبر نیست و با DENY_HOLD_METADATA_INCOMPLETE رد می‌شود. باز هم این metadata حقوقی واقعی نیست؛ فقط invariant آموزشی است.

14. Deletion scope و backup boundary

Deletion evidence باید owned copies را تفکیک کند. Primary و derivative copyها می‌توانند در model به DISPOSED برسند، درحالی‌که backup ممکن است تحت expiry boundary مستند باقی بماند. lesson به‌صراحت ادعا نمی‌کند backup فوراً پاک شده است.

Residual Boundary باید بنویسد که سیستم‌های خارج از fixture، retention قانونی، backup implementation واقعی و downstream copies توسط این lab اثبات نشده‌اند. این جمله محدودیت evidence را حفظ می‌کند.

15. Changed-context transfer

در transfer، dataset به یک analytics context synthetic منتقل می‌شود که ownerها و purposeها متفاوت‌اند. learner حق ندارد baseline retention یا export scope را کپی کند. باید lifecycle record را از صفر و بر اساس context جدید rebuild کند.

Template عمداً final_decision را خالی نگه می‌دارد. AI می‌تواند probe پیشنهاد دهد یا evidence مشاهده‌شده را مرتب کند، اما decisive conclusion، residual boundary و owner acceptance را نباید از طرف learner پر کند. استقلال transfer یک شرط completion است.

16. Assessment و blocking boundaries

Assessment retrieval، application، diagnosis، decision و transfer را پوشش می‌دهد. Application، diagnosis و transfer blocking هستند. پاسخ باید به evidence محلی trace شود و نباید jurisdiction-specific law اختراع کند.

اگر learner یک retention period را universal اعلام کند، possession را export authority بداند، UI invisibility را proof of deletion بداند یا NIST draft را requirement نهایی معرفی کند، پاسخ از boundary درس خارج شده است.

17. Source boundary و freshness

Authority این درس دقیقاً دو source frozen دارد: NIST-PF10 و NIST-PF11-STATUS. NIST-PF10 برای risk-based privacy/data-processing lifecycle concepts استفاده می‌شود، نه برای قانون jurisdiction-specific. NIST-PF11-STATUS فقط وضعیت پروژه update را ثبت می‌کند.

در current-source recheck تاریخ 2026-09-16، Version 1.0 همچنان سند نهایی voluntary/risk-based بود و صفحه رسمی Version 1.1 هنوز آن را Initial Public Draft/update project با final «Coming soon» نشان می‌داد. پس هیچ draft requirement در policy lab وارد نشده است.

18. Residual Risk

حتی اگر همه gateهای local PASS شوند، production privacy/security، legal compliance، jurisdiction-specific retention، واقعی‌بودن deletion across infrastructure و third-party copies اثبات نشده‌اند. Residual Risk باید این محدودیت‌ها را صریح نگه دارد.

جمع‌بندی

قاعده فشرده این درس چنین است: اول class/purpose/owner را مشخص کن؛ retention را با trigger و exit condition ببند؛ export را مستقل از possession authorize و minimize کن؛ deletion را با scope و disposition evidence ثابت کن؛ hold را state governed بدان؛ و هیچ requirement حقوقی را اختراع نکن. Data Lifecycle Policy Evidence Record v1 باید Positive Evidence، Negative Evidence، transfer و residual boundary را هم‌زمان نگه دارد.