Retention with a purpose
GateCode separates short-lived operational detail from longer-lived security and aggregate reporting. The platform can preserve useful management metrics without needing to preserve collector and subject names indefinitely.
Default retention schedule
| Data | Default approach | Purpose |
|---|---|---|
| Active GateCode details | Kept while the authorisation is upcoming, active, revoked or recently expired. | Operational verification, user history and support. |
| Expired/revoked authorisation detail | Detailed collector, subject reference and template data are minimised after 90 days by the retention process. | Short-term audit/support followed by privacy minimisation. |
| Share tokens | Cryptographic token values are stored only as hashes; expired token rows are cleaned up after a 7-day operational grace period. | Secure collector-link operation and limited troubleshooting. |
| GateCode event detail | Detailed event metadata is minimised with old authorisation detail; actor linkage is further minimised after 12 months by default. | Security, auditability and dispute investigation. |
| Aggregated metrics | Counts can be retained after personal detail is minimised. | Trend reporting, service planning and organisation analytics without keeping collector names. |
| Account data | Kept while the account is active and then handled through the account closure/deletion process, subject to legal or security needs. | Account operation, contract and legal obligations. |
| Expired sessions | Deleted by the retention process once they are no longer valid. | Security and housekeeping. |
| Support and incident records | Kept for the period reasonably required to resolve the issue, evidence actions and meet contractual/legal obligations. | Support, security and accountability. |
Automated minimisation
GateCode includes a protected retention operation that aggregates eligible historical metrics, removes old expired share-token rows, minimises detailed authorisation fields and reduces old event metadata. It can be invoked by the platform owner or scheduled securely using the deployment environment.
Customer-specific requirements
Enterprise, school and regulated customers may agree a different retention requirement where there is a valid operational, legal or safeguarding reason. Any agreed variation should be documented in the customer agreement or data-processing schedule.
Legal holds and security events
Where data is genuinely required for an active legal claim, security investigation, safeguarding matter or regulatory obligation, deletion or minimisation may be paused for the affected records for as long as that purpose requires.