Purpose
This policy defines retention periods for different types of data and procedures for secure disposal when data is no longer needed.
Retention Principles
Minimisation: Collect and retain only necessary data Purpose Limitation: Retain data only for its intended purpose Transparency: Retention periods publicly documented Security: Data protected throughout its lifecycle Disposal: Secure deletion when no longer needed
Retention Periods
Operational Data
| Data Type | Retention Period | Justification | Storage Location |
|---|---|---|---|
| Audit logs (including IP addresses) | 90 days | Anti-abuse, diagnostics, security investigation, operational monitoring | Cloudflare KV, Durable Objects, Cloudflare Workers Logs (shipped to Grafana Loki) |
| Operational telemetry | 90 days | Performance monitoring | Cloudflare Workers Logs (shipped to Grafana Loki) |
| Challenge state | 5 minutes (provii-verifier) / 2 minutes (provii-issuer) | Active challenge lifetime | Cloudflare KV (auto-expires via TTL) |
| Nonce records | 5 minutes (provii-verifier) / 2 minutes (provii-issuer) | Replay protection | Cloudflare KV (auto-expires via TTL) |
Tiered retention: Standard audit log entries are retained for 90 days. Critical security events (such as detected attacks, replay attempts, and IP blocks) are retained for up to 365 days to support security investigation.
Docs Interactive Sandbox Data
The docs interactive sandbox introduced in Phase 0A maintains its own KV state under TTLs that are stricter than the production audit ceiling. The TTLs are enforced both client-side (cookie expiry) and server-side (Cloudflare KV TTL) and are documented here for transparency. Enforcement is in provii-agegate/src/docs/session.ts and the surrounding gateway handler modules.
| KV namespace and key prefix | Data | Retention | Justification | TTL mechanism |
|---|---|---|---|---|
DOCS_SESSIONS (docs-session:*) | __Host-docs_session server-side state, including HMAC-bound session_id and bearer | 15-minute sliding TTL, refreshed on activity, with a 4-hour hard cap from first issuance | Bounded session lifetime to limit blast radius of a session-cookie leak, balanced against developer ergonomics during sandbox exploration | Cookie Max-Age and KV expirationTtl on docs-session:*; hard cap enforced server-side |
DOCS_CRED_VERIFIER (docs-cred-v:*) | Verifier-credential cache for sandbox API explorer interactions | 1-hour KV TTL | Caching layer for sandbox credential lookups, sized to the typical sandbox exploration session | KV expirationTtl |
DOCS_CRED_ISSUER (docs-cred-i:*) | Issuer-credential cache for sandbox API explorer interactions | 1-hour KV TTL | Caching layer for sandbox credential lookups, sized to the typical sandbox exploration session | KV expirationTtl |
DOCS_CHALLENGES (docs-chal:*) | Sandbox challenge state for verification flow | 24-hour KV TTL | Allows a developer to start a challenge, leave the page, and return to complete it within the working day | KV expirationTtl |
MOBILE_INSTALL_ALLOWLIST (mwallet-sbx-*) | Mobile sandbox install entries | 7-day KV TTL | Per Decision 13, mobile sandbox install lifetime is bounded to one week to balance evaluation flexibility against credential-cloning risk | KV expirationTtl |
Hashed source IP audit entries (docs-audit:ip:*) | HMAC-SHA-256 keyed by PII_HASH_KEY | 90 days | Falls under the standard audit retention ceiling | KV expirationTtl |
| Audit and security telemetry | Gateway request logs, key-use events, credential-mint events | 90 days | Falls under the standard audit retention ceiling | Workers Logs retention in Grafana Loki plus KV expirationTtl |
Source-code reference: provii-agegate/src/docs/session.ts is the canonical TTL definition for the session and credential entries. The mobile install TTL is defined in the mobile gateway handler under the mwallet-sbx-* write path.
Cross-references: Docs Sandbox DPIA Section 1 (Data Processed) and Section 2 (Storage Limitation); DPA Docs Sandbox Addendum Section 3.5; ROPA Activities 2.5 and 2.6; Statement of Applicability ISO 27701:2019 A.7.4.5 and A.7.4.7 entries.
Development Data
| Data Type | Retention Period | Storage Location |
|---|---|---|
| Source code | Indefinite | Git (GitHub) |
| CI/CD logs | 90 days | GitHub Actions |
| Build artifacts | 90 days (signed releases: indefinite) | GitHub Releases |
| Test data | Deleted after test run | In-memory only |
Business Records
| Data Type | Retention Period | Justification |
|---|---|---|
| Contracts | 7 years after expiration | Legal requirement (AU) |
| Financial records | 7 years | Legal requirement (AU) |
| ISMS documents | Current + 3 years | ISO 27001, audits |
| Incident reports | 3 years | Lessons learned, audits |
What We DON’T Collect
Zero knowledge architecture means Maelstrom AI-operated services never persist to at-rest storage:
- Names, addresses, contact information
- Raw dates of birth
- Identity document data
- Biometric information
- Any other personally identifiable information (PII)
During credential issuance, the date of birth is transmitted once to the issuer API for Pedersen commitment computation. The DOB is processed ephemerally and immediately discarded. It is never written to persistent storage, databases, or audit logs. During age verification, no date of birth is transmitted; only a zero knowledge proof is presented to the verifier.
Therefore:
- No server-side PII retention policy needed (DOB is processed transiently during issuance and not written to persistent storage)
- No server-side PII disposal procedures needed (no PII stored to dispose)
- Significantly simplified compliance obligations
Disposal Procedures
Digital Data
Cloudflare KV:
// Automated deletion after retention period
await env.AUDIT_LOG.delete(key);
Ephemeral Data (KV TTL-based expiry for challenges and nonces):
- Auto-expires based on TTL (5 minutes provii-verifier, 2 minutes provii-issuer)
- No manual deletion needed
- Garbage collection automatic
Source Code / Git:
- Git history: Retained indefinitely (immutable by design)
- Sensitive data accidentally committed: Rewrite history + rotate secrets
- Repository deletion: Only with ISMS Owner approval
Cryptographic Material
Signing Keys:
- Retention: Until rotated + grace period (keys transition Active → Deprecated → Disabled)
- Disposal: In-memory key material zeroized on Drop; persistent encrypted material in KV deleted by administrator or rendered inaccessible via KEK rotation
- Offline backups: Physical destruction (shred or degauss)
Secrets (API keys, HMAC secrets):
- Retention: Until rotated
- Disposal: Delete from KV/secrets manager
- Never in source code (so can’t be “deleted” from Git history)
Physical Media
Devices (laptops, hard drives):
- Full disk encryption: Delete encryption keys (cryptographic erasure)
- Additional: Secure wipe (multiple passes) or physical destruction
- Company devices: Documented disposal in asset register
- Personal devices (BYOD): Individual responsibility (guidance provided)
Paper Documents (rare):
- Shredding (cross-cut shredder minimum)
- Sensitive documents: Witnessed destruction
Automated Deletion
Implementation
Audit Logs (Cloudflare Workers Logs in Grafana Loki + KV):
// Workers Logs are shipped to Grafana Loki at emit time
// Loki tenant retention: 90 days, applied automatically
// No manual cleanup needed
Audit Logs (KV):
// Per-entry TTLs with 90-day retention
// Automated cleanup via KV expiration
// Retention period aligned across all services (provii-verifier including hosted mode, provii-issuer)
Challenges and Nonces (KV with TTL):
// TTL-based expiration (provii-verifier: 300s, provii-issuer: 120s)
// Automatic cleanup via Cloudflare KV expiration
Legal Holds
If legal proceedings require data retention:
- Legal counsel notifies ISMS Owner
- Relevant data identified
- Automated deletion suspended for specific data
- Data preserved until hold lifted
- Normal disposal resumes after hold
Currently: No legal holds in effect
Data Subject Requests
Context: Zero knowledge architecture means we rarely have personal data
If we receive a request:
- Access request. Confirm we have no PII about requestor
- Deletion request. Confirm no PII to delete (IP logs deleted after 90 days automatically)
- Rectification request. Not applicable (no PII stored)
Response time: Within 30 days (Australian Privacy Act requirement)
Disposal Verification
For sensitive data disposal:
- Document what was disposed
- Method used
- Date of disposal
- Person responsible
- Verification (where applicable)
Asset Register: Updated to reflect disposed assets
Related Documents
- Asset Management Procedure
- Information Security Policy
- Statement of Applicability - Control A.8.10 (Information Deletion)
Document Information
- Version. 1.2
- Effective Date. 2025-01-13
- Last Updated. 2026-04-13 (Phase 0A docs sandbox: added DOCS_SESSIONS, DOCS_CRED_*, DOCS_CHALLENGES, MOBILE_INSTALL_ALLOWLIST KV TTLs)
- Owner. ISMS Owner
- Review Frequency. Annually
- Next Review. 2027-04-13
- Classification. Public