Data Handling Judgment

data-handling-judgment

When to use

• A data category needs classification (PII / PHI / financial / public / pseudonymous / aggregate) and downstream retention, access, and transfer rules depend on the classification.
• A retention default is being set (or audited) and the question is how long is defensible, how long is useful, how long is dangerous.
• A cross-border transfer is proposed (analytics in US, support in Philippines, backup in EU) and the transfer-mechanism + sub-processor obligations need a read.
• A data-subject-rights (DSR) workflow is being designed: access, deletion, portability, correction, objection, automated-decision-objection.

Do NOT use as a regulatory-regime delta read (route to privacy-review (P6); this skill composes P6 for the regime floor), for contract-clause depth (route to contracts-cognition (P5)), or for data-loss-prevention tool administration / classifier-engine configuration.

Cognition cluster

• Mental model 28 — Inversion. "If this data category leaked in this form, who would we have to notify and what would the headline read?" The headline inversion forces honest classification ahead of operational convenience. See mental-models.md § 28.
• Mental model 1 — First principles. Strip every retention claim to: what purpose does keeping this another day serve, and whose risk does it grow? Most retention defaults are inherited from the previous system, not chosen. See mental-models.md § 1.
• Mental model 26 — Optionality. Aggressive retention preserves analytical optionality but forecloses deletion optionality and grows breach optionality for the attacker. Each retention choice is a trade. See mental-models.md § 26.
• Context-spine — regulatory-regime + customer-segment + product. Read regulatory-regime (J1) for floor (GDPR storage-limitation principle; HIPAA retention minimums for medical records; financial-regulator retention mandates). Read customer-segment for whose data sets the floor. Read product for which features actually need the data.

Cross-wing handoff

• Composes / cites J1 regulatory-regime for the floor read; this skill operationalises the regime obligations into classification / retention / transfer / DSR shape.
• Composed by P6 privacy-review — privacy-review flags that a classification / retention / transfer issue exists, this skill produces the operational answer.
• Hands off to Wing-2 ops skills for implementation (retention-job scheduling, DSR-runbook authoring) — this skill produces the policy shape, ops implements.

Procedure

Step 0: Bind the regime floor and the segment

Read J1 regulatory-regime for the customer-segment in scope. Note which regime mandates a minimum retention (HIPAA medical records: typically 6+ years state-dependent; financial: SOX, regulatory varies) vs which mandates a maximum (GDPR storage-limitation; CCPA "necessary purpose"). Both floors and ceilings can apply simultaneously and create a window.

Step 1: Classify the data category

For each data category in scope, assign a classification tier and rationale:

1. Public — already public or designed for publication; no confidentiality obligation.
2. Internal — company-confidential, not subject-specific; protected by trade-secret / commercial logic.
3. Pseudonymous — keyed to subject but not directly identifying; classification depends on re-identifiability (the GDPR test).
4. PII — directly identifying; subject to regime baseline.
5. Sensitive-PII — special-category (GDPR Art. 9), CCPA "sensitive personal information", financial-account, gov-ID.
6. PHI / regulated — HIPAA PHI, payment-card data (PCI), or sector-specific (children = COPPA, biometrics = state laws).

Rationale per category cites what makes it that tier, not just the label. Mis-classification downward is the canonical risk.

Step 2: Set retention with explicit purpose binding

For each data category × processing purpose, name:

1. Purpose — why we keep it (operational, analytical, legal-hold, contractual, regulatory-mandate).
2. Retention — how long for that purpose; named in calendar units, not "as needed".
3. End-state — at expiry: hard-delete, anonymise, aggregate-only, archive-with-access-restriction.
4. Authority — what makes the chosen retention defensible (regime mandate, contract obligation, documented operational need).

Default "indefinite" retention is the failure mode. Every category needs an explicit end-state.

Step 3: Cross-border-transfer judgment

For each transfer hop where data crosses a regime boundary:

1. Source regime vs destination regime — which subjects, which categories.
2. Mechanism — adequacy decision, SCC (with which version), BCR, derogation. Schrems-II-level transfer-impact assessment for transfers to non-adequate jurisdictions.
3. Government-access risk — destination jurisdiction's surveillance regime and the supplementary-measures shape (encryption with key-control, pseudonymisation before transfer, contractual challenge).
4. Sub-processor chain — every onward transfer is itself a transfer; map two hops deep, not one.

A transfer without a named mechanism + supplementary measures (where required) = an unauthorised transfer.

Step 4: Data-subject-rights workflow shape

For each regime × right (access, deletion, portability, correction, objection, automated-decision-objection), name:

1. Window — regime-mandated response time (GDPR: 1 month; CCPA: 45 days; HIPAA: 30 days for access).
2. Owner — named human / role responsible (not "the team").
3. Mechanism — how the subject submits, how identity is verified, how the response is delivered, how denials are reasoned.
4. Edge cases — joint-controller scenarios, third-party data within a subject's record, deletion-vs-legal-hold conflicts.

DSR workflows that exist only as a generic support-inbox process fail under every regime. Force named owners and windows.

Step 5: Validate the data-handling read before emitting

Before producing the artifact, verify three things:

1. Classification coverage — confirm every in-scope data category has a tier + cited rationale; un-rationalised tiers are guesses and must be re-run.
2. Retention binding — assert every category × purpose has a calendar-unit retention + named end-state + cited authority; "as needed" entries fail.
3. Transfer + DSR completeness — check every cross-border hop has a mechanism + supplementary-measures read; every applicable regime × right has a named owner + window. Gaps are surfaced, not smoothed.

All three must pass. If any fails, return to the failing step.

Step 6: Emit the data-handling-judgment artifact

Produce the data-handling-judgment note for the feature owner, ops lead, and counsel. The artifact operationalises the regime floor into policy that ops can implement and counsel can sign off.

Related Skills

WHEN to use this

• Classifying a new data category and setting downstream rules.
• Setting / auditing retention defaults against regime and purpose.
• Judging a cross-border-transfer mechanism + supplementary measures.
• Designing a DSR workflow with named owners and windows.

WHEN NOT to use this

• Regime-floor regulatory delta read — route to privacy-review (P6); this skill composes P6.
• Contract-clause redline depth — route to contracts-cognition (P5).
• Regime-floor surface — route to regulatory-regime (J1); this skill operationalises J1, doesn't replace it.
• DLP / classifier-engine tooling — out of scope.

When the agent should load this

• "How do we classify this field?"
• "How long do we keep this?"
• "Can we send this to the US / India / wherever?"
• "Design our DSR workflow."
• "Wie lange dürfen wir Logs aufbewahren?"

Output

1. classification-map.md — every in-scope data category × tier + cited rationale.
2. retention-policy.md — category × purpose × retention × end-state × authority.
3. transfer-register.md — cross-border hops × mechanism × supplementary measures × sub-processor chain (two-deep).
4. dsr-workflow.md — regime × right × window × owner × mechanism × edge cases.

Gotcha

• Pseudonymous ≠ anonymous. If re-identification is possible with reasonable means, it's still personal data under GDPR.
• Retention defaults inherited from the previous system are usually wrong; treat every category as a fresh decision.
• "Encryption in transit" is not a Schrems-II supplementary measure on its own; the question is who can access the keys in the destination jurisdiction.
• Joint-controllership is silently common (analytics, embedded widgets); name the controller relationship explicitly per hop.

Do NOT

• Do NOT issue privacy legal opinions; this skill produces operational policy, counsel signs it off.
• Do NOT classify by least-conservative tier to avoid operational burden; mis-classification downward is the canonical regulator finding.
• Do NOT set retention without a named end-state; "as needed" is not a retention.

Runnable example

Series-B SaaS with EU + US customer mix, adding a customer-success analytics integration.

• Step 0 — Regime floor: GDPR (EU subjects), CCPA (CA subset), no PHI. GDPR storage-limitation is the ceiling; no minimum-retention mandate applies.
• Step 1 — Classify: account-id = pseudonymous (low re-id); email = PII; usage-event = PII (linked to email); free-text-feedback = PII + potentially sensitive (subjects may include health / political content). Aggregate cohort metrics = anonymous if k-anonymity ≥ 50.
• Step 2 — Retention: usage-event for product-analytics = 18 months, hard-delete on expiry; usage-event for billing-dispute = 7 years (contractual + tax authority); free-text-feedback = 12 months, hard-delete; email-for-marketing = until consent withdrawn or 24 months inactive.
• Step 3 — Transfer: analytics vendor in US (no adequacy), SCC 2021 module 2 + supplementary measures (pseudonymisation of free-text-feedback before transfer, key-control retained in EU). Sub-processor chain: vendor uses logging service in US-only; ok within SCC.
• Step 4 — DSR: access (1 month, CS lead, in-app + verified-email submission); deletion (1 month, CS lead, soft-delete-then-hard-delete-30d unless legal-hold); portability (1 month, ops engineer, JSON export); objection-to-marketing (immediate, automated).
• Step 5 — Validate: every category tier rationalised; every retention category × purpose has end-state + authority; transfer hops have SCC + supplementary measures; DSR rights have owners + windows. Pass.
• Step 6 — Emit data-handling-judgment artifact; ops implements retention jobs and DSR runbook; counsel signs off on transfer-impact assessment.