WiFi Data Retention Policy Template (Download)
Key Takeaways: A data retention policy defines how long each type of guest WiFi data is stored and when it is deleted. It is required under GDPR (storage limitation principle), expected under CCPA/CPRA, and is best practice under CASL. Most WiFi marketing deployments retain guest profiles for 24 months after last activity, session data for 12 months, and consent records for the duration of consent plus 3 years. This article provides a complete, customizable retention policy template with a section-by-section walkthrough, plus guidance on implementing automated deletion in MyWiFi.
A data retention policy is not a luxury compliance document. It is a required component of any WiFi marketing deployment that collects personal data.
Under GDPR Article 5(1)(e), personal data must be "kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed." Under CCPA, businesses must disclose retention criteria. Under CASL, consent records must be maintained for audit defense.
According to the European Data Protection Board's 2025 enforcement summary, failure to define or enforce data retention periods was cited in 23% of GDPR enforcement actions — making it one of the most common compliance failures.
This article provides a complete retention policy template for WiFi marketing, a walkthrough of each section, and implementation guidance.
The template
Below is a complete WiFi data retention policy template. Copy and customize it for each client deployment. Sections marked [CUSTOMIZE] require venue-specific values.
WiFi Guest Data Retention Policy
Organization: [CUSTOMIZE: Venue/company name] Effective date: [CUSTOMIZE: Date] Last reviewed: [CUSTOMIZE: Date] Policy owner: [CUSTOMIZE: Role/name responsible for data governance] Applicable regulations: [CUSTOMIZE: GDPR, CCPA, CASL, other]
1. Purpose
This policy defines the retention periods and deletion procedures for personal data collected through the guest WiFi system operated at [CUSTOMIZE: venue name/address]. It applies to all data collected through the captive portal, RADIUS accounting, presence detection, and associated marketing automation systems.
2. Scope
This policy covers:
- •Guest profile data (name, email, phone, social profile)
- •WiFi session data (timestamps, duration, bandwidth, AP association)
- •Device data (MAC address, device type, OS, browser)
- •Marketing engagement data (campaign opens, clicks, unsubscribes)
- •Consent records (marketing opt-in/opt-out records)
- •Presence analytics data (probe request detections, zone traffic)
- •Marketing campaign content and delivery records
3. Data categories and retention periods
| Data Category | Data Elements | Retention Period | Justification | Deletion Method |
|---|---|---|---|---|
| Guest profile | Name, email, phone, social ID | [CUSTOMIZE: 24 months] after last activity | Marketing relevance window | Automated purge |
| Session data | Timestamps, duration, bandwidth, AP | [CUSTOMIZE: 12 months] from session date | Analytics reporting period | Automated purge |
| Device data | MAC address, device type, OS | Same as associated guest profile | Linked to guest identity | Deleted with profile |
| Marketing engagement | Opens, clicks, conversions | Same as associated guest profile | Campaign attribution | Deleted with profile |
| Consent records | Opt-in timestamp, text, method | Duration of consent + [CUSTOMIZE: 3 years] after withdrawal | Regulatory audit defense | Manual review + deletion |
| Presence analytics | Aggregate zone traffic, dwell time | [CUSTOMIZE: 36 months] | Trend analysis (anonymized) | Automated purge |
| Probe request logs | Raw probe request data | [CUSTOMIZE: 30 days] | Real-time analytics only | Automated purge |
| Campaign content | Email/SMS templates, delivery logs | [CUSTOMIZE: 24 months] from last send | Compliance audit trail | Manual review + deletion |
4. Retention period rationale
Guest profiles (24 months after last activity): Research indicates that the probability of a lapsed guest returning drops to under 3% after 24 months of inactivity (based on MyWiFi Networks retention analysis across 75M+ guest connections). Retaining profiles beyond this period provides negligible marketing value while increasing data protection risk and storage costs.
Session data (12 months): Session data supports analytics reporting (year-over-year comparisons, seasonal trend analysis). Twelve months provides one full annual cycle for comparison. Session data older than 12 months is aggregated into analytics rollups before deletion — the aggregate data (average dwell time by month, total sessions by week) persists indefinitely as it is not personal data.
Consent records (consent duration + 3 years): Regulatory bodies can investigate compliance up to 3 years after a potential violation (CRTC under CASL, CPPA under CCPA). Maintaining consent records for 3 years after consent withdrawal provides audit defense.
Presence analytics (36 months): Aggregate, anonymized presence data (total visitors per zone, average dwell time per hour) is not personal data and can be retained indefinitely. Raw probe request logs containing MAC addresses are retained for 30 days only — sufficient for real-time analytics without creating a long-term surveillance record.
5. Automated deletion procedures
Monthly deletion job: An automated process runs on the [CUSTOMIZE: first/fifteenth] of each month to identify and delete data that has exceeded its retention period.
Deletion process:
- •Query all guest profiles where
last_activity_dateis older than the retention period - •Delete the guest profile and all associated data (sessions, device records, engagement records)
- •Retain the consent record separately (subject to its own retention period)
- •Log the deletion: number of profiles deleted, date, and confirmation of completion
- •Verify deletion in downstream systems (CRM, email service provider, exported files)
Pre-aggregation: Before deleting session data, the system computes and stores aggregate analytics (hourly/daily/weekly rollups) that do not contain personal data. These aggregates persist after individual session deletion.
6. Data subject deletion requests
When a data subject exercises their right to erasure (GDPR Article 17, CCPA Section 1798.105):
- •Verify the identity of the requester
- •Delete all personal data associated with the requester across all systems within [CUSTOMIZE: 30 days for GDPR, 45 days for CCPA]
- •Retain a record that a deletion request was received and executed (anonymized — no personal data, just the request ID and execution date)
- •Confirm deletion to the requester
7. Exceptions to deletion
Data may be retained beyond the standard retention period when:
- •Required by law (legal hold, regulatory investigation, court order)
- •Necessary for the establishment, exercise, or defense of legal claims
- •Anonymized beyond the possibility of re-identification (aggregate analytics)
All exceptions must be documented with the legal basis and expected duration.
8. Third-party data sharing and retention
When guest data has been shared with third parties (CRM, email service provider, advertising platforms):
- •Maintain a register of all third parties that received personal data
- •When data is deleted from the primary system, notify third parties and request deletion from their systems
- •Verify deletion confirmation from third parties
- •For advertising audience syncs (Facebook Custom Audiences, Google Customer Match): remove deleted profiles from the synced audience
9. Policy review
This policy is reviewed [CUSTOMIZE: annually / semi-annually] and updated to reflect changes in:
- •Applicable regulations
- •Business practices and data processing activities
- •Technology and system capabilities
- •Risk assessment outcomes
Review schedule: [CUSTOMIZE: Date of next review]
Walkthrough: Implementing the template
Step 1: Customize retention periods
The template provides recommended retention periods based on industry practice and regulatory requirements. Adjust based on:
- •Industry vertical: Healthcare venues may require shorter retention (HIPAA considerations). Financial services may require longer retention (regulatory record-keeping).
- •Client preference: Some clients prefer shorter retention for lower risk. Others prefer longer retention for larger marketing databases.
- •Regulatory requirements: GDPR does not specify exact periods but requires justification. Choose periods that are defensible as "necessary for the purpose."
Step 2: Configure automated deletion in MyWiFi
MyWiFi supports configurable data retention per location:
- •Navigate to Location Settings → Privacy & Compliance
- •Set the guest data retention period (recommended: 24 months after last activity)
- •Set the session data retention period (recommended: 12 months)
- •Enable automated deletion (the platform will purge expired data on the configured schedule)
- •Review the deletion log monthly to verify the process is running
Step 3: Document third-party data flows
Create a data flow map showing every system that receives guest data:
Captive Portal → MyWiFi Platform → [Email Provider] → [CRM] → [Advertising Platform]
→ [SMS Provider]
→ [Analytics/BI Tool]
→ [Exported CSV files]
For each recipient system, document:
- •What data is shared
- •The retention period in that system
- •The deletion mechanism
- •Whether automated deletion is possible
Step 4: Implement downstream deletion
When guest data is deleted from MyWiFi, it must also be deleted from downstream systems:
- •Email service provider (Mailchimp, ActiveCampaign, etc.): Use the provider's API to delete the contact. Many ESPs support webhook-triggered deletion.
- •CRM (HubSpot, Salesforce): Delete or anonymize the contact record.
- •Advertising platforms (Facebook, Google): Remove the contact from Custom Audiences. Facebook and Google automatically age out audience members, but explicit removal is best practice.
- •Exported CSV files: This is the hardest to control. Document a process for destroying exported files at retention expiration. Consider restricting CSV export for GDPR-zone deployments.
Step 5: Test the policy
After implementation, test the complete retention lifecycle:
- •Create a test guest profile
- •Wait for the retention period to expire (or temporarily set a short retention period for testing)
- •Verify the automated deletion job runs and deletes the profile
- •Verify deletion in all downstream systems
- •Verify the consent record is retained separately (not deleted with the profile)
- •Verify aggregate analytics are unaffected by the individual deletion
Retention period recommendations by regulation
| Regulation | Profile Data | Session Data | Consent Records | Probe Request Logs |
|---|---|---|---|---|
| GDPR | 12–24 months after last activity | 6–12 months | Duration + 3 years | 0–30 days (anonymize immediately if possible) |
| CCPA | 12–24 months (must disclose) | 12 months | Duration + 3 years | No specific requirement |
| CASL | 12–24 months after last activity | 12 months | Duration + 3 years (CRTC investigation window) | No specific requirement |
| No regulation (minimal risk) | 24–36 months | 12–24 months | Duration + 2 years | 30 days |
Conservative approach: Use the GDPR recommendations as the global baseline. They are the most restrictive and satisfy all other regulatory requirements.
Common retention mistakes
Mistake 1: No retention policy at all
The most common mistake. Data accumulates indefinitely, increasing breach risk, storage costs, and regulatory exposure. Even a simple "delete after 24 months" policy dramatically reduces risk.
Mistake 2: Retention policy exists but is not enforced
A written policy without automated deletion is a compliance risk, not a compliance control. Auditors and regulators look for evidence of enforcement, not just documentation.
Mistake 3: Deleting consent records with guest data
Consent records must be retained longer than guest data. If a regulatory investigation occurs after a guest's data is deleted, the consent record proves that the marketing was authorized. Deleting consent records with the guest data destroys this evidence.
Mistake 4: Forgetting downstream systems
Deleting data from the WiFi platform while leaving copies in the CRM, email provider, and exported spreadsheets does not satisfy the retention policy. Deletion must propagate to all systems.
Mistake 5: Not aggregating before deleting
Deleting session data without first computing aggregate analytics destroys historical trend data. Always aggregate (compute daily/weekly/monthly rollups) before purging individual session records.
FAQ
What retention period should I use if I operate in multiple jurisdictions? Use the shortest required retention period across all applicable jurisdictions as the default. If GDPR applies to any of your clients, use GDPR-level retention (12–24 months for profiles, 6–12 months for sessions) as the global baseline.
Does aggregate analytics data need a retention period? If the aggregate data is truly anonymous (no individual can be re-identified), it is not personal data and does not require a retention limit. The key test: can any individual be identified from the aggregate data? If not, retain indefinitely.
How do I handle retention for multi-location clients? Apply the same retention policy across all locations unless a specific location has a different regulatory requirement (e.g., a location in the EU requires stricter retention than a location in the US). MyWiFi supports per-location retention configuration.
What happens to marketing campaigns targeting deleted guests? Campaigns are not retroactively deleted, but the guest's profile is removed from future campaign audiences. Campaign delivery logs may be anonymized (campaign sent to [deleted guest], opened at [timestamp]) to maintain campaign performance metrics without personal data.
Should I keep data longer "just in case"? No. Retaining data beyond the justified period increases regulatory risk and breach impact without corresponding business value. Define the minimum retention period necessary for the stated purpose and enforce it.
Is this template sufficient for legal compliance? This template provides a comprehensive starting framework aligned with GDPR, CCPA, and CASL requirements. It is not legal advice. Have the customized policy reviewed by legal counsel familiar with the specific jurisdictions and industry regulations applicable to your deployment.