Privacy/DPA و Controller/Processor Boundaries

«ما Processor هستیم» برای کدام پردازش؟

یک support agent تیکت مشتری را برای پاسخ‌گویی پردازش می‌کند. قرارداد، vendor را برای این خدمت Processor می‌نامد. حال product team می‌خواهد همان متن تیکت را برای بهبود یک مدل داخلیِ نامرتبط دوباره استفاده کند، اما instruction مستند جدیدی وجود ندارد. اشتباه خطرناک این است که label قرارداد را مجوز دائمی برای هر purpose بگیریم. در این درس DPA Role, Instruction & Processing Boundary Register v1 را می‌سازیم تا هر processing activity به purpose، role basis، instruction، DPA، subprocessor/transfer، retention/deletion، security و privacy review خودش متصل بماند.

مرز درس و مسیر تصمیم

AGN-009 مالک مرز Privacy/DPA و Controller/Processor برای هر processing activity است. AGN-008 مالک مفاهیم MSA/SOW/SLA/Scope و AGN-010 مالک IP/Rights است. مسیر درست: activity را مشخص کن؛ purpose و data category را ثبت کن؛ ببین چه کسی purpose/means را تعیین می‌کند؛ role basis را از evidence بساز؛ instruction و DPA version را bind کن؛ subprocessor/transfer و retention/deletion/security را چک کن؛ conflict و review را نگه دار؛ سپس فقط یک state محدود و audit-friendly صادر کن.

مدل ذهنی: Role یک label دائمی شرکت نیست

در GDPR، controller و processor مفاهیم functional هستند. contract می‌تواند evidence مهمی باشد، اما factual role به processing واقعی وابسته است. ممکن است یک vendor برای support processor باشد، اما اگر برای reuse مستقلِ داده purpose و means خودش را تعیین کند، همان label قبلی کافی نیست. بنابراین register باید processing-level باشد، نه فقط vendor-level.

۲۱ بُعد بحرانی Register

Contract روی این فیلدها قفل است: processing_activity_id, purpose_id, personal_data_category, controller_entity, processor_entity, role_basis_ref, documented_instruction_ref, instruction_version, dpa_ref, dpa_version, subprocessor_id, subprocessor_authorization_state, transfer_context, retention_rule_ref, deletion_rule_ref, security_measure_ref, purpose_change_state, instruction_conflict_state, privacy_review_required, processing_state, audit_ref. Lab چند helper قابل‌مشاهده هم دارد: role_evidence_state, instruction_matches_purpose, instruction_current, decision_authority_state, subprocessor_evidence_ref, transfer_safeguard_ref, retention_deletion_consistent, security_evidence_current, dpa_current, legal_review_state, transfer_variant, transfer_recomputed, baseline_decision_reused, baseline_instruction_reused.

Fact، Inference و Design را جدا نگه دار

FACT: EDPB controller را entity تصمیم‌گیر درباره why/how پردازش می‌داند و processor را entityای که از طرف controller و تحت instruction عمل می‌کند. FACT: Article 28 برای رابطه processor قرارداد/سند حقوقی، documented instruction و شرایط subprocessor می‌خواهد. INFERENCE: چون role مفهومی functional است، role را باید در سطح processing activity/purpose دوباره ارزیابی کرد و contract label را oracle نگرفت. DESIGN: state vocabulary، escalation threshold، retention values و workflow review در MAKNOW محلی‌اند و جای legal advice را نمی‌گیرند.

Baseline: support processing مطابق instruction

processing_activity_id=support_ticket_reply، purpose=CUSTOMER_SUPPORT، controller=customer_org، processor=vendor_service، role basis بر اساس factual activity + DPA، documented instruction معتبر، DPA current، subprocessor=NONE، transfer=EEA_ONLY، retention/deletion سازگار، security current، conflict=NONE و review=NO است. نتیجه Lab PROCESSING_BOUNDARY_REVIEW_READY است.

Mutation 1: purpose را به INTERNAL_MODEL_IMPROVEMENT عوض کن ولی instruction قبلی را نگه دار → HOLD_INSTRUCTION_PURPOSE_MISMATCH. Mutation 2: subprocessor جدید را APPROVED بنویس اما evidence authorization نداشته باش → HOLD_SUBPROCESSOR_AUTH_EVIDENCE_MISSING. Mutation 3: transfer خارج از EEA بدون safeguard → HOLD_TRANSFER_SAFEGUARD_MISSING. Mutation 4: retention را indefinite کن ولی deletion rule قبلی را نگه دار → HOLD_RETENTION_DELETION_CONFLICT.

Failure modeهای مهم

1. contract label را factual role proof گرفتن. 2. role را برای کل vendor ثابت فرض کردن. 3. purpose change را بدون instruction/DPA recomputation پذیرفتن. 4. processor action بدون documented instruction. 5. subprocessor approval بدون authorization evidence. 6. third-country transfer بدون safeguard evidence. 7. retention/deletion متناقض. 8. security evidence stale. 9. DPA version stale. 10. instruction conflict را زیر ALLOWED پنهان کردن. 11. special-category/high-risk context را بدون required review عبور دادن. 12. transfer را با decision یا instruction baseline حل کردن.

ALLOWED، REVIEW_REQUIRED و HOLD را قاطی نکن

ALLOWED فقط وقتی معنی دارد که role/instruction/DPA/subprocessor/transfer/retention/security evidence با همان activity سازگار باشند. REVIEW_REQUIRED یعنی evidence کافی برای حرکت به privacy/legal review وجود دارد ولی authorization نهایی بیرون از Lab است. HOLD وقتی decisive evidence غایب، stale یا متناقض است. هدف lesson این نیست که هر مورد را processor یا controller اعلام کند؛ هدف این است که state قوی‌تر از evidence صادر نشود.

پل فرد باتجربه: contract wording در برابر factual control

برای caseهای پیچیده، از سؤال «قرارداد چه نوشته؟» یک قدم عقب برو: چه کسی purpose را تعیین کرده؟ چه کسی essential means را تعیین می‌کند؟ آیا action در instruction documented فعلی جا می‌گیرد؟ آیا subprocessor/transfer/retention در DPA و evidence عملیاتی پوشش دارد؟ اگر processor برای یک purpose جدید مستقل تصمیم بگیرد، از label قبلی برای عبور استفاده نکن؛ role boundary را دوباره به privacy counsel بده.

تمرین هدایت‌شده و مستقل

Baseline را اجرا کن و هر gate را به یک field وصل کن. بعد هر بار یک mutation بده: purpose change، حذف instruction، contract-label-only role basis، subprocessor بدون evidence، transfer بدون safeguard، retention/deletion conflict، DPA stale و instruction conflict. اولین gate شکسته را نام ببر. سپس transfer را از صفر بساز: workflow دوم subprocessor جدید، processing location متفاوت و retention متفاوت دارد؛ baseline decision و instruction قابل reuse نیستند.

چه چیزی باید بازسازی‌پذیر باشد؟

Reviewer باید بتواند پاسخ دهد: activity و purpose دقیقاً چیست؟ چه personal-data category درگیر است؟ controller/processor و role basis چه evidenceای دارند؟ documented instruction کدام version است؟ DPA کدام version؟ subprocessor چه authorization evidence دارد؟ transfer context و safeguard چیست؟ retention و deletion با هم سازگارند؟ security evidence current است؟ purpose change یا instruction conflict باز است؟ privacy review لازم است؟ چرا processing_state قوی‌تر از evidence نیست؟ audit trail کجاست؟

Transfer: subprocessor جدید، location جدید، retention جدید

در workflow دوم یک subprocessor اضافه شده، location پردازش عوض شده و retention rule متفاوت است. role، instruction، subprocessor authorization، transfer safeguard و deletion را از evidence جدید دوباره بساز. اگر baseline_decision_reused=true یا baseline_instruction_reused=true باشد، Lab باید fail کند. فقط وقتی recomputation کامل است و conflict باز نداریم، نتیجه می‌تواند TRANSFER_PRIVACY_REVIEW_READY شود.

منابع و تازگی

FACT: EDPB Guidelines 07/2020 (final 7 July 2021) controller/processor را functional concepts می‌داند و contractual terms را به‌تنهایی decisive نمی‌داند. FACT: GDPR Article 28 documented instructions، processor contract/legal act و controller authorization برای subprocessor را بیان می‌کند. INFERENCE: MAKNOW role را per-processing activity مدل می‌کند. DESIGN: exact escalation, retention, review owner و jurisdiction policy محلی است. منابع قانونی تا 2026-11-14 یا زودتر در تغییر مادی recheck شوند.