Data Retention & Archiving Policy
1. Introduction & Scope
This Data Retention and Archiving Policy ("Policy") governs the principles and procedures for retaining, archiving, and deleting data within the SafePick application ("Service"). This Policy applies to all data collected, processed, and stored through our services, including but not limited to user account information, operational logs, and generated content. The primary objectives of this Policy are to ensure data privacy, optimize application performance, manage storage costs, and comply with data management best practices while retaining necessary historical records for operational integrity, security auditing, and legal compliance.
2. Data Categories & Retention Schedule
To provide our Service effectively and securely, we categorize data based on its purpose and required longevity. The following schedule details the retention periods for key data categories in our live, operational Firestore database.
| Data Category | Live Retention Period | Archiving Action & Rationale |
|---|---|---|
| User Accounts (`users`) | Indefinite | Action: Retained until a user account is explicitly deleted. Rationale: Essential for user access and core application functionality. Deletion is handled separately as per Section 4. |
| Pickup Requests (`pickup_requests`) | 1 Year | Action: Archive to secure Cloud Storage, then purge from live database. Rationale: Balances the need for historical audit trails for parental access against the performance impact of retaining large datasets in the operational database. |
| Check-in/Out Logs (`check_ins`, `check_outs`) | 1 Year | Action: Archive to secure Cloud Storage, then purge from live database. Rationale: Critical for attendance reporting and security investigations. A one-year live retention period allows for comprehensive academic year analysis. |
| Vehicle Access Logs (`access_logs`) | 1 Year | Action: Archive to secure Cloud Storage, then purge from live database. Rationale: Essential for campus security audits and incident investigation. Retained live for one year to cover an entire operational cycle. |
| Digital Notices (`digital_notices`) | 1 Year | Action: Archive to secure Cloud Storage, then purge from live database. Rationale: Serves as a record of campus policy enforcement. Archived for long-term review if required. |
| System Notifications (`notifications`) | 90 Days | Action: Purge from live database. No archival. Rationale: Notifications are transient and time-sensitive. A 90-day retention is sufficient for user review without creating unnecessary data clutter. |
| Generated AI Content (`generated_content`) | Indefinite | Action: Retained as part of user-generated data. Rationale: This content is considered user work product and is retained until the associated user account is deleted. |
| Financial Transactions (`transactions`) | 7 Years | Action: Retained in a secure, audited financial database. Rationale: Required for legal, financial, and tax auditing purposes. This data is stored separately from the main operational database. |
3. Archiving & Purging Procedure
Process Overview
- Frequency: Automated archival and purging processes are scheduled to run on a monthly basis, typically on the first day of each calendar month.
- Identification: The system identifies all documents within a collection where the creation or event timestamp has exceeded the specified live retention period.
- Archival: For data designated for archiving, documents are programmatically exported into a compressed, structured format (e.g., `collection_name_YYYY-MM.json.gz`) and securely transferred to a long-term, cold-line storage bucket in Google Cloud Storage. This storage is optimized for infrequent access and long-term durability.
- Verification & Purge: After a successful and verified backup to Cloud Storage, the system permanently deletes the archived documents from the live Firestore collection. Data marked for purging without archival (e.g., Notifications) is deleted directly from the operational database.
Rationale
This tiered data management approach ensures that the primary operational database remains lean, fast, and cost-effective for high-frequency daily operations. Historical data remains securely stored and can be accessed for administrative, security, and compliance audits through specific request protocols, without impacting the performance of the live application for everyday users.
4. User Data Deletion
When a user account is deleted, either by the user or an administrator through the designated application interfaces, the following actions are triggered to ensure the complete and secure removal of personally identifiable information (PII):
- Immediate Deletion of Core Records: The user's primary profile from the `users` collection, their authentication record in Firebase Authentication, and any directly linked dependent accounts (e.g., a parent's children) are permanently and irrevocably deleted.
- Cascading Deletion of Associated Data: All data where the user is the primary owner is identified and permanently deleted. This includes, but is not limited to, pickup requests initiated by the user, vehicles registered under their name, and any saved AI-generated content.
- Anonymization of Log Data: In instances where a user's action must be preserved for system integrity (e.g., a guard who registered a vehicle for another user, a teacher who graded a student), the log entry itself will be retained. However, all personal identifiers linking the action to the deleted user (e.g., `issuedByName`, `registeredById`) will be anonymized or removed to break the direct link to the deleted individual's identity.
5. Policy Review and Updates
This Data Retention Policy is subject to periodic review and may be updated to reflect changes in our services, data processing practices, or applicable legal and regulatory requirements. We will review this policy at least annually. Significant changes will be communicated to users through in-app notifications or via the email address associated with their account.