Data Retention Policy
How long we retain personal information and when we delete or de-identify it.
Nomi — Data Retention Policy
Document type: Internal operational policy (with user-facing summary in the Privacy Policy) Owner: Privacy Officer, Nomi Pty Ltd Last updated: 14 May 2026 Effective date: 14 May 2026 Review cycle: Annually, or when there is a material change to the Service, data processors, or regulatory environment.
1. Purpose
This Policy defines how long Nomi retains personal information and other data, and the controls that govern its secure deletion or de-identification. It operationalises Australian Privacy Principle (APP) 11.2, which requires destruction or de-identification of personal information once it is no longer needed for any purpose for which it may lawfully be used or disclosed.
2. Scope
This Policy applies to:
- all personal information Nomi collects in the course of operating the Service;
- all internal records, logs, and backups containing such information;
- all employees, contractors, and processors handling Nomi data.
It excludes data held outside Nomi's control — including messages on users' WhatsApp devices and messages stored on Meta's infrastructure after delivery — which is governed by WhatsApp's own retention practices.
3. Principles
- Minimisation by default. We collect only what we need and delete it as soon as it is no longer required.
- Justified retention. Every retention window is tied to a specific operational, legal, or contractual purpose.
- Demonstrable deletion. Deletion or de-identification is logged and auditable.
- De-identification over deletion where retention of statistical signal is operationally useful and individuals cannot be re-identified.
- Backup parity. Production deletions propagate to backups within the documented backup rotation window (see section 6).
4. Retention schedule
| # | Data category | Retention period | Trigger for deletion / de-identification | Lawful / operational basis |
|---|---|---|---|---|
| 1 | Account profile (display name, WhatsApp phone number, profile photo URL, password hash) | Active account + 30 days after deletion request | Account deletion confirmed by user, or 24 months of full inactivity | Service delivery; user consent |
| 2 | Matching data (interests, goals, free-text bio, city, professional context) | Active account + 30 days | Same as above | Service delivery |
| 3 | Conversation content routed through Nomi-facilitated introductions (text, media, timestamps, sender/recipient) | 90 days from last message in thread | Rolling deletion job; extended to 12 months only where flagged for trust & safety review | Service delivery; trust & safety |
| 4 | Match metadata (introductions offered, accepted, declined, muted, reported; ratings) | 24 months in identifiable form; de-identified aggregate thereafter | Time-based rolling deletion | Service quality, fraud prevention |
| 5 | Subscription and billing records (Stripe customer ID, plan, invoices, payment outcomes, GST records) | 7 years from end of financial year of the transaction | Time-based; archived to cold storage after 24 months | Income Tax Assessment Act 1997 (Cth); A New Tax System (Goods and Services Tax) Act 1999 (Cth) |
| 6 | Support correspondence (tickets, chat transcripts) | 36 months from ticket closure | Time-based | Service quality, dispute defence |
| 7 | Trust & safety reports involving suspected abuse, harassment, fraud, or illegal conduct | Up to 7 years | Closure of investigation + statutory limitation period | Legal claims defence; cooperation with law enforcement |
| 8 | Server access logs, application logs, and security telemetry (IP, user agent, request ID, event type) | 90 days online; 12 months in immutable security archive | Time-based | Security monitoring, incident response |
| 9 | Authentication events (logins, password changes, MFA enrolments) | 24 months | Time-based | Security, audit |
| 10 | Marketing consent and opt-out records | Until withdrawal; 24 months thereafter as proof-of-consent | Withdrawal + 24 months | Spam Act 2003 (Cth) record-keeping |
| 11 | Product analytics events (PostHog or equivalent) | 13 months identifiable; aggregated/anonymous indefinitely | Time-based rolling deletion | Product improvement |
| 12 | Error and crash diagnostics (Sentry or equivalent) | 90 days | Vendor-side rotation | Stability, troubleshooting |
| 13 | Backups and disaster-recovery snapshots | 35 days rolling (daily snapshots, 7-day retention; weekly snapshots, 35-day retention) | Snapshot rotation | Business continuity |
| 14 | Internal HR and contractor records | Per employment law (typically 7 years after engagement ends) | Time-based | Fair Work Act 2009 (Cth) |
| 15 | Legal hold data (any of the above categories subject to active litigation, regulatory inquiry, or law-enforcement request) | Until the hold is lifted by Legal | Manual release by General Counsel | Legal obligation |
A legal hold overrides every other retention window in this table. Once lifted, the data reverts to the applicable schedule.
5. Deletion and de-identification methods
| Method | When used |
|---|---|
| Hard deletion of records from production database | Profile, matching, and conversation data on account deletion or end of retention |
| Crypto-shredding (destruction of per-tenant encryption keys) | For at-rest encrypted blobs (media, backups) where row-level deletion is impractical |
| De-identification (removal of direct identifiers + k-anonymity ≥ 5 on quasi-identifiers) | Match metadata and analytics data retained for product insight beyond identifiable window |
| Vendor-side deletion (via processor API or written request) | Analytics, error monitoring, payment metadata held by processors |
Deletion jobs run nightly. Each run produces a deletion report retained for 24 months that records: category, record count, run timestamp, and operator (system or human).
6. Backups
Production backups follow the 35-day rotation in row 13. When a record is deleted from production, it is purged from active backups at the next rotation. Restoration from backup is only used for disaster recovery; any restore that resurrects records subject to a completed deletion request triggers an automatic re-deletion workflow.
7. Roles and responsibilities
| Role | Responsibility |
|---|---|
| Privacy Officer | Owns this Policy. Approves changes to the retention schedule. Responds to access, correction and deletion requests. |
| CTO / Engineering Lead | Implements deletion jobs, monitors execution, maintains the deletion log. |
| Trust & Safety Lead | Determines when content qualifies for extended retention (row 7). Approves and documents each extension. |
| General Counsel (or external counsel) | Initiates and releases legal holds. |
| All employees and contractors | Comply with this Policy; do not store production personal information on local devices or personal accounts. |
8. User deletion requests
When a user requests deletion (in-app, by email, or via WhatsApp):
- Identity is verified (control of the registered WhatsApp number or email).
- The user is informed of categories that will be retained beyond deletion (billing, legal hold, trust & safety) and the reasons.
- The account is hidden immediately; bio and matching fields are tombstoned within 24 hours.
- Full deletion of category 1–4 data is completed within 30 days of confirmation.
- A deletion receipt is sent to the user and a record entered in the deletion log.
9. Incident handling
If a retention failure is identified (e.g. records kept beyond their window), it is treated as a privacy incident, logged in the incident register, and remediated within 30 days. Material failures may trigger a notification under the Notifiable Data Breaches scheme administered by the Office of the Australian Information Commissioner.
10. Third-party processors
Each processor must:
- contractually commit to retention windows no longer than those in section 4 unless legally required;
- support documented deletion APIs or written deletion requests;
- be audited at onboarding and at least every 24 months.
A register of processors, the data categories they handle, retention configuration, and location of storage is maintained by the Privacy Officer.
11. Exceptions
Any deviation from this Policy requires written approval from the Privacy Officer and must be:
- justified by a specific operational, legal or contractual need;
- time-boxed;
- logged in the exceptions register;
- reviewed at the next annual policy review.
12. Review and version control
This Policy is reviewed at least annually and whenever:
- a new data category is introduced;
- a new processor is engaged;
- there is a material change in Australian privacy law or regulatory guidance;
- a notifiable data breach exposes a weakness in retention controls.
Version history is maintained in the document management system.
Approved by: [Name], Privacy Officer Next scheduled review: 14 May 2027