How Online SMS Platforms Should Handle Logs Under GDPR
A Technical Compliance Guide for Developers and Architects
GDPR core principles — mapped to SMS logging
Before touching a single line of code, understand the four principles that matter most when handling SMS logs. They are not abstract legal concepts; they directly dictate your engineering decisions.
- Purpose limitation (Art. 5(1)(b)): You collect SMS data solely for identity verification. Logs must not be reused for profiling, analytics, or resale. Every additional use requires a new lawful basis.
- Data minimisation (Art. 5(1)(c)): Logs should record that “an SMS was sent”, not its full content. If the verification code is logged, you are over-retaining personal data.
- Storage limitation (Art. 5(1)(e)): Verification codes and logs are not antiques. Automatic purging must be built in; indefinite retention is a violation.
- Integrity and confidentiality (Art. 5(1)(f)): Phone numbers and codes in logs must be encrypted or pseudonymised at rest. Plaintext storage is an unnecessary risk.
Three types of logs — and how to make each GDPR-ready
1. Web server access logs (NGINX / Apache)
What they typically contain: URL with phone number and code in query parameters, IP address, timestamp, User-Agent. If you have not configured your server, the full request URI is written directly to disk. This alone is a massive privacy leak and a violation of data minimisation.
Compliant approach: Intercept at the web server layer. Use a custom log format that masks query parameters. For NGINX:
The goal: the log file itself should never contain a real phone number or verification code. IP addresses can remain but must be protected as personal data.
2. Application business logs
Typical risk: Developers log complete SMS bodies, codes, and phone numbers to debug. These logs are then accessible by multiple departments and may persist in backups for months. That's a data breach waiting to happen.
Compliant approach: Configure your logging framework (Logback, Winston, etc.) with redaction rules. Use regex to mask the middle digits of phone numbers and replace any code with [REDACTED]. Example in a Java Logback pattern:
In development environments, you may keep raw data under strict access controls. But in staging and production, plaintext codes must never appear.
3. Database tables and backups
The risk: Your primary database, read replicas, full backups, and binary logs (binlog / WAL) each hold complete data. GDPR's right to erasure (Art. 17) hits a wall when you need to delete a user but cannot touch old backup files.
Compliant approach:
- Primary database: Set the verification code column to
NULLimmediately after successful verification. Keep only the status (e.g., “verified at”). - Backups: Use backup tools that support selective restoration or post-process wiping. Alternatively, restore backup to a staging instance, run deletion scripts, and replace the backup with a sanitised copy.
- Binlog / WAL: Do not retain them beyond the necessary failover window. Never treat them as long-term archives.
Log data classification and retention policy table
| Log Type | Contains Personal Data? | Max Retention | Compliant Handling |
|---|---|---|---|
| Web server access logs | Yes (IP, masked URL) | 30 days | Real-time phone number masking; no full request URI stored |
| Application delivery logs | Yes (status, masked phone) | 90 days | Log only delivery status, never plaintext code |
| Application error logs | Potentially | 30 days auto-purge | Automated scripts scan and redact any leaked codes weekly |
| Database main table | Yes (phone number, code) | Code: 5 min after verification | Field-level expiration; code set to NULL immediately |
| Database backups | Yes | 6 months, with selective deletion capability | Use backup tool that supports per-record deletion or post-processing |
Demonstrating compliance: DPIA and audit trail
A Data Protection Impact Assessment (DPIA) is not optional when processing phone numbers and verification codes. Below is a simplified DPIA template for an SMS verification module.
Simplified DPIA — SMS Verification Logging
| Data processed: | Phone number, verification code, IP address, timestamp |
| Purpose: | One-time password delivery to prove possession of phone number |
| Retention: | Code: 5 minutes; access logs: 30 days; backup: 6 months |
| Risks: | Accidental logging of plaintext codes; backup immutability; unauthorised access to log servers |
| Mitigations: | Real-time masking, field-level purging, encrypted backups, role-based access to logs |
Every redaction rule and automated purge job must be documented. When a supervisory authority asks, you must show that your log configuration files, database cleanup cron jobs, and backup procedures together form a complete compliance fabric.
Responding to a user's right to erasure — an SOP view
When a data subject requests deletion, you must follow a chain that reaches all corners of your infrastructure.
- Live database: Execute
UPDATE users SET phone='deleted-{uuid}', code=NULL WHERE .... Never just soft-delete without scrubbing. - Log aggregation: In your ELK / Loki / Splunk, search for the user's phone number and delete or overwrite the related log entries. Automated retention policies alone are not enough — you need on-demand deletion capability.
- Backups: At the next backup rotation, use selective-restore tools to rebuild backup files without the deleted user's data. Do not promise deletion if your backups remain untouched.
- Audit record: Log the time, executor, and systems involved in a compliance journal. This shows the regulator you actually performed the deletion.
Engineer's compliance checklist
- Minimise: Review all log configs — mask phone numbers (middle digits) and block verification codes entirely from plaintext logs.
- Short retention: Set automatic expiration on verification code fields (5 minutes) and web logs (30 days).
- Strong encryption: Use deterministic encryption for phone numbers at rest; encrypt all backups at disk level.
- Enable deletion: Practice a full user data deletion drill — verify that even your oldest backup can be sanitised.
- Document everything: Produce a DPIA and keep a living record of your log masking rules and retention schedules.
GDPR compliance is not a legal wrapper around your code. It is the code. Every log line, every backup file, every retention policy is a piece of evidence. Build them wisely, and your platform won't just say it's private — it will prove it.