Data Classification & Retention Policy
Governs how Finaisse classifies, handles, retains, and deletes data. Subordinate to the Information Security Policy.
| Policy owner | Security & Infrastructure Owner (Sekhar Prakash) |
| Applies to | All Finaisse and customer data across all environments |
| Effective | 2026-08-19 (v0.1 draft) |
| Review cadence | Annual + on major change |
| SOC 2 | C1, CC6.5, Privacy (P) |
1. Purpose
Ensure data is handled according to its sensitivity, that Restricted data (customer financial data) receives the strongest protection, and that data is retained no longer than needed.
2. Classification
| Class | Examples | Baseline handling |
|---|---|---|
| Public | Marketing content, public docs | No restriction |
| Internal | Product documentation, runbooks, this policy set | Authenticated access (finaisse-org GitHub org membership) |
| Confidential | Customer configuration, tenant metadata | Encrypted, access-controlled, audited |
| Restricted | Financial transactions, journals, invoices, reconciliations, PII | Encrypt at rest + in transit; strict least-privilege; full audit trail; tenant-isolated; defined retention/deletion |
Data lifecycle governed for every class: creation → processing → storage → archival → deletion.
3. Handling rules
- Restricted data must never be output in logs, error messages, or analytics labels; never sent to an external service except through a governed path (e.g. LLM calls under the AI posture, F-14); and never stored unencrypted.
- Secrets/credentials are never treated as data to store — they live in the secret store, never in source, logs, or images (see Secure SDLC).
- Tenant Restricted data is isolated per customer (dedicated database); cross-tenant access is prohibited and enforced (see Access Control, F-01).
- The observability design enforces this at the telemetry layer: no user/tenant-unbounded identifiers in metric labels; per-record data goes to the event store, not metrics (observability).
4. Encryption
- In transit: TLS at the edge; 🎯 Target — TLS ≥1.2 enforced everywhere incl. internal service-to-service, legacy protocols disabled.
- At rest: 🎯 Target (AWS) — AES-256 with customer-managed KMS keys (CMKs), per-service keys, automated rotation (F-18).
5. Retention & deletion
Known retention decisions (from the observability design):
| Data | Retention | Basis |
|---|---|---|
| Operational metrics | 13 months | Year-over-year comparison |
| Logs | 30 days | Incident investigation window |
| Usage events (raw) | 12 months, then dropped | Decided; DPA-covered |
| Usage rollups | 24 months | Long-term trends, no keystroke timing |
| Security audit logs | 🎯 Target — define (retention aligned to compliance needs) | Compliance/forensics |
| Customer Restricted data | 🎯 Target — define per contract/DPA + deletion on offboarding | DPDP/customer contract |
- 🎯 Target — retention is enforced by scheduled deletion jobs for each data class; ratify the customer-data and audit-log rows before the first production tenant.
- Customers retain ownership of their data and may request export or deletion per the Data Processing Agreement.
6. Privacy alignment
Finaisse acts as a data processor for customer data. India DPDP is the near-term baseline; GDPR and others apply as customers/regions require (see Framework & Cert Register). Data minimisation and purpose limitation apply to all processing, including AI workflows.
Revision history
| Version | Date | Author | Change |
|---|---|---|---|
| 0.1 | 2026-08-19 | Security & Infrastructure Owner | Initial draft |