CommonGage Data Retention and Deletion Policy
Last updated: 2026-09-06
Principles
CommonGage retains data only as long as needed to provide the service. When a district's contract ends, or upon a verified deletion request, CommonGage will delete the district's data promptly and completely.
Retention Periods by Data Type
| Data Type | Retention Period | Basis |
|---|---|---|
| Active tenant data (events, deliverables, users, schools, zones) | Duration of active contract | Service delivery |
| Expired invite tokens | 30 days after expiry | Audit trail |
| Used invite tokens | 90 days after use | Audit trail |
| Calendar feed tokens (revoked) | Retained indefinitely, without the plaintext | Record that a subscription existed and when it stopped working |
| Attestation tokens (used) | Retained with used_at timestamp; token hash only (plaintext unrecoverable) | Proof that an attestation link was issued and used |
| RSVP tokens (used) | Retained with used_at timestamp; token hash only (plaintext unrecoverable) | Proof that an RSVP link was issued and used |
| Cloudflare Worker logs | 7 days (Cloudflare platform default) | Operational debugging |
| Neon query logs | 7 days (Neon platform default) | Operational debugging |
Contract Termination and Offboarding
When a district's contract ends:
- Grace period: Data is retained for 30 days after contract end to allow the district to export any needed records.
- Export window: Upon request during the grace period, CommonGage will provide a data export in CSV or JSON format covering events, deliverables, and school/zone structure.
- Deletion: At the end of the grace period (or sooner upon district request), CommonGage will delete all data associated with that tenant from the production database. This is a manual database operation performed by CommonGage operations staff at contract end — distinct from the automated, API-driven, anonymize-in-place erasure used for individual staff account deletion during an active contract (see "Staff Account Deletion," below). There is no self-service tenant-deletion feature in the product.
- Confirmation: CommonGage will provide written confirmation of deletion within 10 business days of the deletion being completed.
- Backups: Any database backups containing the district's data will be purged or overwritten within 30 days of the deletion date, in accordance with Neon's backup retention policy.
Data Deletion Requests (In-Contract)
Districts may request deletion of specific data types during an active contract (e.g., removing a staff user's account, deleting a specific event). CommonGage will honor such requests within 5 business days. Bulk deletion of a district's entire dataset during an active contract will be treated as an offboarding request (see above).
Student Data
CommonGage does not store student education records. If a district identifies that student PII has been inadvertently transmitted to CommonGage (e.g., via an iCal feed with student-identifiable event descriptions), CommonGage will work with the district to identify and delete the affected records within 72 hours of the request.
Staff Account Deletion
When a staff member leaves a district and an admin erases their account, CommonGage anonymizes the user record in place — it is never deleted from the users table.
Deletion was deliberately rejected in favor of anonymization for two reasons. First, the user row is referenced by everything that person created or was assigned in the district's operational record (events, deliverables, measures, expense entries); deleting the row would either cascade and destroy that organizational history, or null every reference and erase the fact that the actions were ever attributed to anyone. Second, an audit trail needs to be able to say "someone did this" even after it no longer needs to say "who" — anonymization preserves the former while removing the latter.
There is one deliberate exception, and it is worth stating plainly: governance actions are public records. Where a customer is a public body, the actions its board takes are subject to public-records and open-meetings obligations that exist independently of any individual's right to erasure. For those records the organization is obliged to retain who acted, named as recorded at the time — and a statutory retention obligation is not overridden by an erasure request. CommonGage therefore classifies every entry in its change history as either a public record or an operational one, and the two are treated differently:
| Class of entry | What it covers | Effect of erasure |
|---|---|---|
| Public record | Governance actions — the decisions a board takes | The actor's name as recorded is part of the record and is retained. Erasure does not remove it. |
| Operational | Everything else — staff working in the product | No retention obligation attaches. The actor's name is subject to the anonymization described above. |
The classification is enforced in the database rather than left to convention, so an entry cannot be reclassified by mistake, and no erasure path can reach a public record. If you are assessing this for a public body, the practical summary is that CommonGage will not destroy your board's records in response to an individual erasure request — and will not retain a staff member's name beyond what your operational record requires.
This same classification extends to a participant's own self-attested participation record. When a district's Participants module is enabled, a governance-category participant (e.g. a board member) may confirm their own hours for an event they attended. That self-attestation is recorded through the identical governance_participation / public_record classification described above — there is no second, separate mechanism for a self-reported record. A non-governance participant's (e.g. a volunteer's) self-attestation is participation / operational, and carries no retention obligation. The distinction this section draws is about what the record is — a governance action or not — never about who typed it.
On erasure:
- The user's email is replaced with a non-routable tombstone address unique to that user, and their display name is replaced with a generic placeholder.
- Their password hash, SSO identifier, zone/school assignment, and locale preference are cleared, and the account is deactivated.
- An
erased_attimestamp is set once, as the permanent proof-of-erasure record. It is never cleared or overwritten — including by a second erasure request against the same account, which is a no-op by construction. - Data the user created (events, flags, deliverables, engagement support records, measures) remains associated with the district tenant and is not deleted, as it represents the district's operational record — now correctly attributed to an anonymized, still-unique account rather than to a name.
- Password reset tokens for the account are deleted outright (not anonymized): they are pure authentication material with no organizational value.
- Invitations addressed to the person are handled by the same distinction. An unused invite is still live authentication material — whoever holds the token could stand up an account on that address — so it is deleted outright. A used invite is spent and records how the account came to exist, which is the organization's audit trail rather than the person's data, so the row is kept and the address on it is replaced with the same tombstone. Both are matched on the exact email address, not on a name.
- Zone leadership and assignment fields need no separate step. They reference the user account rather than storing a copy of the name, so anonymizing the account is what every reader of those fields resolves to.
Calendar Feed Tokens
Revoking a calendar subscription (Settings) sets a revoked_at timestamp; the token row itself is never deleted. Its token_hash cannot be turned back into the plaintext it was generated from, so the retained row carries no working credential — only the fact that a subscription existed, its label, when it was created, and last_used_at, the same shape used to tell a live subscription from a forgotten one before revoking it.
Communications Records
Communications module records (outbound press/outreach entries and inbound media scan results) are retained for the duration of the active contract, the same retention basis as calendar events and other operational data. Watch profiles (keyword sets for media scanning) follow the same lifecycle. On contract termination, Communications data is included in the tenant deletion described under "Contract Termination and Offboarding" above.
Subprocessor Retention
Data shared with subprocessors for service delivery (Anthropic for classification, Neon for storage) is subject to each subprocessor's own data processing terms:
- Neon: Data is retained in accordance with the Neon Data Processing Agreement. Point-in-time recovery backups are retained for up to 30 days.
- Anthropic: Event data sent for classification, Find questions sent for ordering into a structured search, and Communications watch topics sent for media monitoring, are not retained by Anthropic for training purposes under the API terms. Each request is stateless. Web searches the media-monitoring tool issues are additionally subject to Anthropic's handling of that feature.
Policy Review
This policy is reviewed annually or when a material change to the data model or subprocessor list occurs.