When ASOS customers received alarming "ASOS HACKED" alerts on their phones, the issue wasn't a typical hack. Attackers had breached third-party platforms used for customer communications, turning ASOS's mobile app into their broadcasting tool. ASOS confirmed unauthorized access, with basic personal information potentially exposed, though claims about its Snowflake environment remain unverified.
This isn't just a theoretical risk. Your push notification infrastructure, SMS gateways, and email service providers all operate outside your security perimeter but communicate in your name. Here's how to secure them before they become your liability.
The Problem: Your Communication Stack Is Someone Else's Server
Third-party communication platforms present a specific GDPR exposure. Under Article 28, these vendors are processors acting on your instructions. If they're compromised, you're still the controller facing notification obligations under Article 33 (72 hours to notify your supervisory authority) and Article 34 (direct notification to affected individuals if high risk exists).
The ASOS incident shows why mobile push notifications need special attention. Unlike email breaches that might take days to detect, unauthorized push alerts reach your entire user base instantly. By the time your team is aware, customers have seen the message, clicked unknown links, and started asking questions on social media.
What You Need Before Starting
Access and documentation:
- Inventory of all third-party platforms sending communications on your behalf (push notifications, SMS, email, in-app messages)
- Current processor agreements for each processor, including Article 28 requirements
- API keys, authentication tokens, and admin credentials for each platform
- Your existing incident response plan and notification templates
Technical requirements:
- Security Information and Event Management (SIEM) system or centralized logging
- API monitoring capability
- Access to your mobile app's notification service configuration (Firebase Cloud Messaging, Apple Push Notification service, or similar)
- Ability to implement IP allowlisting on your communication platforms
Team coordination:
- Designated incident response lead with authority to make containment decisions
- Legal counsel familiar with Article 33/34 notification requirements
- Communications lead who can draft customer notifications quickly
- Technical contact at each third-party processor (escalation path, not just support email)
Step-by-Step Implementation
Phase 1: Audit your communication processors (Week 1)
Start with discovery. Many organizations don't know every platform that can push messages to customers.
Check your mobile app codebase for notification SDKs. Review your marketing automation stack. Ask your customer support team what tools they use. Export a list of every service with write access to customer communication channels.
For each platform, verify you have a signed processor agreement that meets Article 28(3) requirements: written contract, processing only on documented instructions, confidentiality commitments, and obligation to assist with data subject rights and supervisory authority inquiries.
Document each platform's authentication method. Username/password isn't sufficient. You need multi-factor authentication on every administrative account, with hardware keys preferred over SMS codes.
Phase 2: Implement technical controls (Weeks 2-3)
Configure IP allowlisting on every communication platform that supports it. Your push notification provider should only accept API calls from your known server IP ranges. This won't stop a compromise of the platform itself, but it prevents attackers from using stolen credentials from outside your infrastructure.
Enable API rate limiting. If your app normally sends 1,000 push notifications per hour during peak times, set alerts at 1,500 and hard limits at 2,000. The ASOS attackers sent notifications to what appears to be the entire user base at once. Rate limits would've constrained the blast radius.
Implement logging for all communication API calls. Your SIEM should ingest:
- Authentication events (successful and failed logins)
- API calls to send messages (timestamp, content hash, recipient count)
- Configuration changes (new API keys, modified sender profiles)
- Administrative actions (user additions, permission changes)
Set up real-time alerts for anomalies: authentication from new locations, API calls outside business hours, sudden spikes in message volume, or configuration changes.
Phase 3: Build notification-specific incident response procedures (Week 4)
Your general incident response plan needs a specialized branch for communication platform breaches.
Create a decision tree: If unauthorized messages are sent, who has authority to disable the platform immediately? The ASOS team couldn't recall the notifications after they were sent. Document the exact steps to revoke API access, disable notification services, or suspend processor accounts. Include processor support phone numbers and escalation contacts.
Draft pre-approved notification templates. When you're 30 minutes into a breach, you don't want legal counsel wordsmithing Article 34 transparency obligations. Prepare templates for:
- In-app warnings (like ASOS's notice telling customers to disregard the alert)
- Email notifications to affected individuals
- Article 33 notifications to your supervisory authority
- Public statements if media coverage begins
Test your kill switch quarterly. Can you actually disable push notifications in under 10 minutes? Schedule a drill where your incident response lead must revoke access to a test notification platform while you time them.
Phase 4: Strengthen processor contracts (Ongoing)
Review your processor agreements for security audit rights. You need contractual authority to request SOC 2 reports, penetration test results, and incident response documentation from your vendors.
Require breach notification within specific timeframes. "Promptly" isn't sufficient. Your contract should state the processor must notify you within 4 hours of discovering unauthorized access to systems processing your data. This gives you time to meet your own 72-hour Article 33 obligation.
Add security requirements to your processor selection process. Before adopting a new communication platform, verify they support: IP allowlisting, hardware key authentication, API rate limiting, detailed audit logs, and role-based access control.
Validation: How to Verify It Works
Run a tabletop exercise simulating the ASOS scenario. At 5:00 a.m., an unauthorized push notification goes to your entire user base. Walk through your response:
- How quickly can your on-call engineer disable the notification platform?
- Who drafts the customer notification? Who approves it?
- Can you identify which customers received the unauthorized message?
- Do you have processor contact information readily accessible?
- Can you file an Article 33 notification with your supervisory authority within 72 hours?
Time each step. If your total response time exceeds 2 hours, you're reacting too slowly.
Test your monitoring alerts by having a trusted team member make an API call from an unauthorized IP or attempt to send a notification outside normal patterns. Verify the alert fires and reaches the right people.
Review your processor agreements annually. When vendors update their terms of service, confirm they haven't weakened security commitments or breach notification requirements.
Maintenance: Ongoing Tasks
Monthly:
- Review communication platform access logs for anomalies
- Verify all administrative accounts still belong to current employees
- Rotate API keys for notification services
Quarterly:
- Conduct tabletop exercises with different breach scenarios
- Test your ability to disable each communication platform
- Review and update incident response contact lists
Annually:
- Request SOC 2 reports from all communication vendors
- Audit processor agreements for Article 28 compliance
- Reassess whether you still need each third-party platform
The ASOS breach happened because communication platforms become invisible infrastructure. You configured them once, they work reliably, and you forget they're processors with access to customer data. Until threat actors remember for you.
Your push notification provider isn't just sending alerts. It's a processor under Article 28, a breach notification trigger under Article 33, and a direct line to every customer's phone. Treat it accordingly.
