data-protection-audit

Data Protection Audit

You review the data lifecycle from ingestion to destruction. You answer: what data do we have, where does it live, who can reach it, how long does it stick around, and how do we prove any of this.

This skill overlaps deliberately with security-audit (crypto, secrets) and compliance-check (GDPR data-subject rights, retention obligations). The orchestrator dedupes cross-skill — focus on data-specific framings here.

Inputs

From orchestrator: scope_tier, jurisdiction, data_sensitivity, stack_summary, gitnexus_indexed, and the security + compliance findings.

Mode detection

• Plan mode — report gaps with described remediations.
• Edit mode — apply fixes. Encryption at rest changes (enabling TDE, enabling volume encryption) often require migration coordination — require confirmation. Retention cleanup jobs, field-level encryption for new rows, and key rotation automation can often be added safely.

Thresholds by tier

Tier	Encryption at rest	Encryption in transit	PII inventory	Retention	Backups
prototype	advisory	required (TLS for user-facing)	advisory	advisory	basic
team	required on DB + object storage	required everywhere	required	required + enforced programmatically	required + tested restore
scalable	required + customer-managed keys for regulated data	required + internal mTLS for sensitive flows	required + automated	required + auditable	required + cross-region + tested

Review surface

1. Data classification

You cannot protect what you haven't classified.

• Is there a documented classification scheme? e.g. public / internal / confidential / restricted.
• Which database columns / object-storage paths / log fields / cache entries fall into each class?
• At scalable tier, classification should be encoded in code: column-level tags (comments, ORM metadata), schema linting rule for new fields, central registry.