[Compliance] DSAR controls

[2witstudios]

Summary

Security/monitoring log governance needs explicit DSAR/erasure and data-residency controls across datasets beyond current account-deletion handling.

Evidence

• Account deletion path explicitly handles activity-log anonymization + AI usage delete, but not equivalent treatment for core monitoring/security datasets:
  • /Users/jono/production/PageSpace/apps/web/src/app/api/account/route.ts:243
• Core monitoring/security tables storing user-linked context:
  • system_logs, api_metrics, error_logs: /Users/jono/production/PageSpace/packages/db/src/schema/monitoring.ts:28
  • security_audit_log: /Users/jono/production/PageSpace/packages/db/src/schema/security-audit.ts:83
• No explicit residency control variables in env validation:
  • /Users/jono/production/PageSpace/packages/lib/src/config/env-validation.ts:8
• User-facing guidance currently says to prefer local models for residency concerns (advisory, not enforcement):
  • /Users/jono/production/PageSpace/apps/web/src/lib/onboarding/faq/content-other.ts:14

Why This Matters

Enterprise reviews typically require explicit controls and documented policy for:

• Right-to-erasure handling vs legal/security retention
• Dataset-by-dataset retention and legal hold behavior
• Data residency/egress constraints (including AI provider paths)

Proposed Work

1. Create a log-governance matrix by dataset (activity, security_audit, system_logs, api_metrics, error_logs, ai_usage).
2. Define DSAR behavior per dataset (delete, anonymize, retain under legal basis) and implement required jobs.
3. Define and enforce data-residency boundaries for log storage and AI-provider egress.
4. Publish policy + technical controls in docs.

Acceptance Criteria

• Governance matrix and DSAR policy are documented and implemented for all core log datasets.
• Residency/egress controls are explicit, testable, and documented.
• Compliance documentation is sufficient for enterprise security questionnaires.