UC-SEC-302: PII Data Privacy & Compliance (DPDP)
1. Metadata
| Property | Value |
|---|---|
| ID | UC-SEC-302 |
| Actor | Database / System |
| Trigger | Persistence of a record containing Student Name/ID |
| Pre-conditions | Field-level encryption keys initialized; Audit log table active |
| Post-conditions | PII fields encrypted at rest; Audit entry created |
| Side Effects | Increased CPU overhead for write operations (est. 2-5ms) |
2. Description
Standardizes the protection of Personally Identifiable Information (PII) to comply with international data protection laws (including India's DPDP Act), ensuring student privacy.
3. Success Scenario
- Ingestion: System receives a payload containing
student_nameandunique_id. - Detection: Data privacy middleware identifies these fields as "PII High."
- Encryption:
- System retrieves the rotating Data Encryption Key (DEK).
- Fields are encrypted using AES-256-GCM.
- Storage: The ciphertext (not plain text) is persisted to the database.
- Audit Logging: System records:
REASON: Data_Persistence, ACTOR: System, ACTION: Encrypt_Write, RESOURCE: Student_6782. - Access Control: On read, only users with 'VIEW_PII' permission trigger the decryption service.
4. Acceptance Criteria
- [ ] Zero-Leak: PII data must not appear in application logs or crash reports.
- [ ] Right to Erasure: Admin must be able to 'Purge Student' which deletes the DEK, rendering all previous logs unreadable.
- [ ] Key Rotation: Master keys must be rotated every 90 days without downtime.
5. Privacy Logic (Field Encryption)
flowchart LR
In[Input: Student PII] --> Detect{PII High?}
Detect -- Yes --> Encrypt[AES-256-GCM Encryption]
Encrypt --> Audit[Log: Encrypt_Write]
Audit --> Store[(Encrypted DB Storage)]