Privacy/DPA & Controller/Processor Boundaries

“We are the processor” — for which processing activity?

A support agent processes customer tickets to answer support requests. The contract labels the vendor a processor for that service. Product now proposes reusing ticket text for unrelated internal model improvement, but there is no new documented customer instruction. The dangerous shortcut is to treat a contract label as permanent permission for every purpose. This lesson builds DPA Role, Instruction & Processing Boundary Register v1 so each processing activity carries its own purpose, role basis, instruction, DPA, subprocessor/transfer, retention/deletion, security and review evidence.

Boundary and decision route

AGN-009 owns the privacy/DPA controller-processor boundary for a processing activity. AGN-008 owns contract-suite concepts and AGN-010 owns IP/rights. Identify the activity; record purpose and data category; determine who actually decides purpose/means; bind role evidence; bind documented instruction and DPA version; check subprocessor/transfer and retention/deletion/security; preserve conflict/review states; then emit only a bounded auditable processing state.

Mental model: role is not a permanent company label

Under GDPR concepts, controller and processor are functional roles. Contract terms are useful evidence, but factual role depends on the real processing. A vendor can be a processor for support while a separate reuse purpose requires a fresh role assessment. The register is therefore processing-level, not merely vendor-level.

The 21 critical dimensions

The contract locks: 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. The Lab also exposes helper evidence: 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, and baseline_instruction_reused.

Keep Fact, Inference and Design separate

FACT: EDPB describes the controller as determining why/how processing occurs and the processor as processing on the controller's behalf under instructions. FACT: GDPR Article 28 requires a processor relationship to be governed by a contract/legal act and includes documented-instruction and subprocessor conditions. INFERENCE: because the role is functional, it should be evaluated at the level of the processing activity/purpose rather than copied from a contract label. DESIGN: MAKNOW's state vocabulary, escalation thresholds and exact retention/review workflow are local governance, not legal advice.

Baseline: support processing matches the instruction

processing_activity_id=support_ticket_reply, purpose=CUSTOMER_SUPPORT, controller=customer_org, processor=vendor_service, factual role evidence plus a current DPA, a current documented instruction, no subprocessor, EEA-only processing, consistent retention/deletion, current security evidence, no instruction conflict and no required review. The Lab emits PROCESSING_BOUNDARY_REVIEW_READY.

Mutation 1: switch purpose to INTERNAL_MODEL_IMPROVEMENT but keep the old instruction → HOLD_INSTRUCTION_PURPOSE_MISMATCH. Mutation 2: add a subprocessor marked APPROVED but no authorization evidence → HOLD_SUBPROCESSOR_AUTH_EVIDENCE_MISSING. Mutation 3: third-country transfer without safeguard evidence → HOLD_TRANSFER_SAFEGUARD_MISSING. Mutation 4: indefinite retention with the old deletion rule → HOLD_RETENTION_DELETION_CONFLICT.

Important failure modes

1. Treating a contract label as factual role proof. 2. Treating role as permanent for the vendor. 3. Accepting purpose change without instruction/DPA recomputation. 4. Processor action without documented instruction. 5. Subprocessor approval without authorization evidence. 6. Third-country transfer without safeguard evidence. 7. Contradictory retention/deletion. 8. Stale security evidence. 9. Stale DPA. 10. Hiding an instruction conflict under ALLOWED. 11. Skipping a required privacy review. 12. Reusing the baseline decision or instruction in transfer.

Do not collapse ALLOWED, REVIEW_REQUIRED and HOLD

ALLOWED is only defensible when role/instruction/DPA/subprocessor/transfer/retention/security evidence matches the same activity. REVIEW_REQUIRED means evidence is sufficient to move into privacy/legal review, not that the real deployment is legally approved. HOLD preserves missing, stale or contradictory decisive evidence. The lesson's job is not to label every real party; it is to keep the decision no stronger than visible evidence.

Experienced bridge: contract wording versus factual control

For harder cases, ask more than “what does the contract call us?” Who determines the purpose? Who determines essential means? Does the current action fit the documented instruction? Are subprocessor, transfer and retention states evidenced? If the vendor independently determines a new purpose, do not force the old processor label through the gate; reopen the role boundary for qualified privacy review.

Guided and independent practice

Run the baseline and map each decision gate to a visible field. Then mutate one dimension at a time: purpose change, missing instruction, contract-label-only role evidence, subprocessor without evidence, transfer without safeguard, retention/deletion conflict, stale DPA, and instruction conflict. Name the first broken gate. Finally rebuild the transfer workflow from new evidence; do not reuse the baseline decision or instruction.

What must be reconstructable?

A reviewer must be able to answer: what exact activity and purpose? What personal-data category? Who is controller/processor and what role evidence supports that? Which documented instruction and version? Which DPA/version? Which subprocessor and authorization evidence? What transfer context/safeguard? Are retention/deletion consistent? Is security evidence current? Is any purpose change or instruction conflict open? Is privacy review required? Why is the processing state not stronger than the evidence? Where is the audit trail?

Transfer: new subprocessor, new location, new retention

A second workflow introduces a new subprocessor, a different processing location and a different retention rule. Recompute role, instruction, subprocessor authorization, transfer safeguard and deletion state from the new evidence. If baseline_decision_reused=true or baseline_instruction_reused=true, fail. Only a fully recomputed case without unresolved conflict can reach TRANSFER_PRIVACY_REVIEW_READY.

References and freshness

FACT: EDPB Guidelines 07/2020 (final July 7, 2021) treats controller/processor as functional concepts and notes contract terms are not always decisive. FACT: GDPR Article 28 states documented-instruction, processor-contract and subprocessor-authorization requirements. INFERENCE: MAKNOW evaluates role per processing activity. DESIGN: exact escalation, retention values, review owner and jurisdiction policy are local. Recheck legal sources by 2026-11-14 or earlier on material change.