PII-HANDLING — Procedures for Personally Identifiable Information¶
Status: live · Version: 1.0.0 · Camada: 8
Purpose¶
Operational procedures for handling Tier-3 (Restricted) data containing PII. Implementation guide for PRIVACY-CONSTITUTION Principles 1-10.
PII categories¶
| Category | Examples |
|---|---|
| Direct identifiers | name, email, phone, government ID, ssh keys to user-owned servers |
| Indirect identifiers | DoB + zip + gender (re-identifiable in combination) |
| Sensitive | health, ethnicity, religion, sexual orientation, political views |
| Financial | account numbers, payment card data (PCI scope) |
| Behavioral | precise location, browsing history, device fingerprints |
Handling matrix¶
| Action | Allowed for | Procedure |
|---|---|---|
| Collect | role with lawful basis | Principle 1 + 2; minimization enforced |
| Store | tenant DB with encryption | field-level encryption for sensitive PII |
| Display | authorized session | masked by default (****@example.com); reveal on click |
| Transmit | within DPA boundary | TLS 1.3; never URL params |
| Log | NEVER plain | hash (HMAC-SHA256 with per-tenant key) |
| LLM input | NEVER raw | redact OR use vault refs (vault://user/<id>) |
| Export | with explicit request + verification | per DATA-RETENTION right-to-portability |
| Delete | on lawful request | cascading delete; key shredding for crypto-erasure |
Redaction patterns¶
When PII must appear in LLM context, redact:
before: "User john.doe@example.com requested refund of $42 on 2026-05-20"
after: "User <email:hash_abc123> requested refund of <amount:redacted> on <date:2026-05-20>"
Hashes are pseudonymous (consistent within story but not reversible).
Discovery + classification¶
When agent encounters new field that looks like PII:
1. Halt the current step
2. Tag the field with PII type
3. Up-classify the artifact to Tier 3
4. Emit pii_discovered audit event
5. Resume only if agent permitted for Tier 3 + has capsule grant
Right to be forgotten (deletion)¶
When a subject requests deletion: 1. Verify identity (per jurisdiction) 2. Locate all records (DATA-FLOW-MAP) 3. Cryptographic erasure for irreversible 4. Update audit log with deletion event (never delete the audit itself) 5. Notify downstream systems 6. Issue confirmation to subject 7. Complete within: 15 days (LGPD) / 30 days (GDPR)
Data subject access requests (DSAR)¶
- Verify identity
- Compile all data about subject (DATA-FLOW-MAP traversal)
- Format per regulation (JSON usually)
- Deliver via authenticated channel
- Complete within: 15 days (LGPD) / 30 days (GDPR)
Failure modes¶
| Mode | Action |
|---|---|
| PII in logs (plain) | rotate logs; INCIDENT SEV1; audit chain |
| PII in LLM context | retract; INCIDENT; vendor notification if cross-boundary |
| Failed identity verification | extra verification step; do not deny absent strong signal |
| Deletion incomplete (some records survived) | manual sweep; FIX-record; postmortem if recurring |
Cross-references¶
- PRIVACY-CONSTITUTION (sibling) — the 10 principles
- DATA-CLASSIFICATION (sibling) — Tier 3 definition
- DATA-BREACH-RESPONSE (sibling) — when something fails
- COMPLIANCE-REGISTER (sibling) — per-jurisdiction specifics
- DATA-RETENTION (sibling) — when to delete by default
- AUDIT-LOG (sibling) — what to log