Lifecycle: draft
Privacy and Data Handling
Purpose and scope
Reduce problems individuals may experience from data processing while preserving the stated product purpose. This skill covers engineering decisions across collection, use, storage, sharing, inference, access, retention, and disposal; it does not provide legal advice or determine jurisdiction-specific compliance.
Triggers and prerequisites
Trigger when a change handles identifiers, account data, content, location, health or financial information, telemetry, logs, recordings, inferred attributes, model prompts/outputs, exports, or deletion/access workflows. Prerequisites: purpose, data subjects and roles, data classification, processing flow, retention/deletion policy, recipients, deployment jurisdictions, security controls, and privacy or legal owner where required.
Decision criteria
- Collect and retain the minimum data needed for a stated purpose and duration; convenience is not a purpose.
- Treat derived, linked, pseudonymous, and “non-sensitive” data as potentially identifying when combined with other data.
- Access, sharing, logging, and model/tool exposure are data processing events that need explicit boundaries and accountability.
- De-identification reduces risk but is not automatically irreversible; do not claim anonymity without evidence appropriate to the threat model.
Procedure
- State the user-facing purpose and expected benefit. Inventory each data field, source, transformation, recipient, storage location, access path, inference, log, export, backup, and deletion path.
- Classify data and identify affected individuals, vulnerable groups, reasonable expectations, misuse consequences, and cross-system linkage or re-identification risks.
- Challenge necessity: remove fields, shorten retention, aggregate, redact, process locally, or use a less identifying representation when the purpose still works. Record why each retained field is needed.
- Define access and sharing boundaries by role, tenant, purpose, environment, and support/debugging workflow. Check exports, analytics, model/tool calls, logs, backups, and third-party processors.
- Define lifecycle behavior: collection notice or control where applicable, correction, access, export, retention, deletion, legal hold, backup expiry, and recovery. Make failure and partial deletion visible.
- Check implementation for accidental collection, secrets or personal data in logs, broad queries, implicit joins, unsafe caches, copied environments, verbose errors, analytics defaults, and data crossing trust or jurisdiction boundaries.
- Test representative and adversarial cases: unauthorized subject, wrong tenant, deleted record, linked identifiers, redaction failure, export scope, retention boundary, backup restore, and downstream failure. Inspect actual payloads where safe.
- Review residual risk and tradeoffs with the privacy/security owner when impact, sensitivity, scale, or uncertainty warrants escalation. Do not substitute an engineering assumption for required review.
- Record purpose, fields and flows, controls, evidence, untested paths, retention/deletion assumptions, residual risk, owner, and the trigger for re-review.
Examples and counterexamples
Good: A diagnostic event records a bounded operation type and coarse outcome, excludes raw user content and identifiers not needed for the question, applies retention, and documents who can access it.
Bad: Log full requests “temporarily” for debugging without redaction, access controls, expiry, or a deletion plan.
Good: A search feature stores a short-lived tokenized identifier only where needed and separately tests tenant isolation, export behavior, and deletion.
Bad: Call data anonymous because names were removed while retaining a uniquely linkable combination of attributes.
Failure modes and recovery
If purpose, data classification, recipients, or retention is unknown, pause the change and resolve the uncertainty. If sensitive data was exposed or over-collected, contain access, preserve evidence, notify the responsible privacy/security process, and follow incident requirements; do not merely delete the visible log. If deletion is incomplete, identify copies and backups and record the residual state. If a less invasive design cannot meet the purpose, document the tradeoff and obtain the required owner decision.
Validation evidence and provenance
Claims in this skill map to graded findings in docs/research.md:
- Lifecycle-stage privacy controls (S2, Moderate structure): NIST Privacy Framework core functions; voluntary guidance, comprehensive coverage.
- Agent-specific privacy risks in inputs, outputs, and telemetry (S5, Moderate): NIST AI 600-1 generative-AI risk enumeration.
- Specific minimization rules (S2-built, Principled): derived from the framework, not evaluated as controls.
Source boundary: frameworks enumerate risk and structure; they do not certify any implementation as compliant with law or policy.
Confidence: medium for the risk structure; medium-low for completeness in any jurisdiction; legal review stays outside this skill's scope. Freshness: review when NIST publications, regulation, or the research base change.
Disconfirmation: a materially different authoritative privacy structure, or evidence that lifecycle controls miss a recurring leak class, would require revision.
Related skills and conflicts
Related: secure-coding-review, tool-authorization-audit, observability-and-instrumentation, data-migration-safety, api-contract-compatibility, requirements-to-acceptance, and knowledge-maintenance. This skill does not authorize collecting data, making legal compliance claims, weakening access controls, or exposing sensitive records for convenience.
1---2name: privacy-and-data-handling3description: Review software changes that collect, use, store, transmit, log, infer, share, or delete personal or sensitive data. Use to reduce privacy risk through purpose limitation, minimization, access control, retention, redaction, and lifecycle-aware design.4---56Lifecycle: `draft`78# Privacy and Data Handling910## Purpose and scope1112Reduce problems individuals may experience from data processing while preserving the stated product purpose. This skill covers engineering decisions across collection, use, storage, sharing, inference, access, retention, and disposal; it does not provide legal advice or determine jurisdiction-specific compliance.1314## Triggers and prerequisites1516Trigger when a change handles identifiers, account data, content, location, health or financial information, telemetry, logs, recordings, inferred attributes, model prompts/outputs, exports, or deletion/access workflows. Prerequisites: purpose, data subjects and roles, data classification, processing flow, retention/deletion policy, recipients, deployment jurisdictions, security controls, and privacy or legal owner where required.1718## Decision criteria1920- Collect and retain the minimum data needed for a stated purpose and duration; convenience is not a purpose.21- Treat derived, linked, pseudonymous, and “non-sensitive” data as potentially identifying when combined with other data.22- Access, sharing, logging, and model/tool exposure are data processing events that need explicit boundaries and accountability.23- De-identification reduces risk but is not automatically irreversible; do not claim anonymity without evidence appropriate to the threat model.2425## Procedure26271. State the user-facing purpose and expected benefit. Inventory each data field, source, transformation, recipient, storage location, access path, inference, log, export, backup, and deletion path.282. Classify data and identify affected individuals, vulnerable groups, reasonable expectations, misuse consequences, and cross-system linkage or re-identification risks.293. Challenge necessity: remove fields, shorten retention, aggregate, redact, process locally, or use a less identifying representation when the purpose still works. Record why each retained field is needed.304. Define access and sharing boundaries by role, tenant, purpose, environment, and support/debugging workflow. Check exports, analytics, model/tool calls, logs, backups, and third-party processors.315. Define lifecycle behavior: collection notice or control where applicable, correction, access, export, retention, deletion, legal hold, backup expiry, and recovery. Make failure and partial deletion visible.326. Check implementation for accidental collection, secrets or personal data in logs, broad queries, implicit joins, unsafe caches, copied environments, verbose errors, analytics defaults, and data crossing trust or jurisdiction boundaries.337. Test representative and adversarial cases: unauthorized subject, wrong tenant, deleted record, linked identifiers, redaction failure, export scope, retention boundary, backup restore, and downstream failure. Inspect actual payloads where safe.348. Review residual risk and tradeoffs with the privacy/security owner when impact, sensitivity, scale, or uncertainty warrants escalation. Do not substitute an engineering assumption for required review.359. Record purpose, fields and flows, controls, evidence, untested paths, retention/deletion assumptions, residual risk, owner, and the trigger for re-review.3637## Examples and counterexamples3839Good: A diagnostic event records a bounded operation type and coarse outcome, excludes raw user content and identifiers not needed for the question, applies retention, and documents who can access it.4041Bad: Log full requests “temporarily” for debugging without redaction, access controls, expiry, or a deletion plan.4243Good: A search feature stores a short-lived tokenized identifier only where needed and separately tests tenant isolation, export behavior, and deletion.4445Bad: Call data anonymous because names were removed while retaining a uniquely linkable combination of attributes.4647## Failure modes and recovery4849If purpose, data classification, recipients, or retention is unknown, pause the change and resolve the uncertainty. If sensitive data was exposed or over-collected, contain access, preserve evidence, notify the responsible privacy/security process, and follow incident requirements; do not merely delete the visible log. If deletion is incomplete, identify copies and backups and record the residual state. If a less invasive design cannot meet the purpose, document the tradeoff and obtain the required owner decision.5051## Validation evidence and provenance52Claims in this skill map to graded findings in [`docs/research.md`](../../docs/research.md):5354- Lifecycle-stage privacy controls (S2, Moderate structure): NIST Privacy Framework core functions; voluntary guidance, comprehensive coverage.55- Agent-specific privacy risks in inputs, outputs, and telemetry (S5, Moderate): NIST AI 600-1 generative-AI risk enumeration.56- Specific minimization rules (S2-built, Principled): derived from the framework, not evaluated as controls.5758Source boundary: frameworks enumerate risk and structure; they do not certify any implementation as compliant with law or policy.5960Confidence: medium for the risk structure; medium-low for completeness in any jurisdiction; legal review stays outside this skill's scope. Freshness: review when NIST publications, regulation, or the research base change.6162Disconfirmation: a materially different authoritative privacy structure, or evidence that lifecycle controls miss a recurring leak class, would require revision.63## Related skills and conflicts6465Related: `secure-coding-review`, `tool-authorization-audit`, `observability-and-instrumentation`, `data-migration-safety`, `api-contract-compatibility`, `requirements-to-acceptance`, and `knowledge-maintenance`. This skill does not authorize collecting data, making legal compliance claims, weakening access controls, or exposing sensitive records for convenience.
ChloeVPin