The Manchester Airports Group breach exposed 8.7 million customer records because attackers exploited the expanded attack surface that comes with remote work. When your team connects from coffee shops, home networks, and hotel lobbies, you're defending dozens of entry points instead of one perimeter. This guide walks you through building a defensive posture that assumes hostile networks and protects data in transit.
Why Remote Security Matters
Your Article 32 obligation to implement appropriate technical and organizational measures doesn't stop at your office firewall. The moment an employee opens a laptop on public Wi-Fi, you're transmitting personal data across infrastructure you don't control. Manchester Airports refused to pay the ransom demand, but the breach still triggered notification obligations under Article 33 and likely significant remediation costs.
Remote work is here to stay. Your security architecture must treat every connection as untrusted and every endpoint as a potential compromise point. If you're still relying on perimeter defenses alone, you're non-compliant the moment someone processes personal data outside your network.
Preparing for Implementation
Technical Requirements:
- VPN infrastructure with split-tunnel capability (WireGuard, OpenVPN, or commercial equivalent)
- Endpoint detection and response (EDR) platform with remote deployment capability
- Identity provider supporting FIDO2/WebAuthn for multi-factor authentication
- Mobile device management (MDM) or unified endpoint management (UEM) platform
- Certificate authority for device trust validation
Administrative Prerequisites:
- Inventory of all roles that process personal data remotely
- Classification of data types by sensitivity (contact information, special category data, financial records)
- List of approved remote work locations and prohibited network types
- Incident response contact tree for endpoint compromises
Policy Foundation: You'll need a remote work security policy that specifies mandatory controls. Don't make VPN use optional or rely on user judgment about when encryption is necessary. Your policy should state: VPN connection required before accessing any system containing personal data. No exceptions for "quick checks" or mobile access.
Step-by-Step Implementation
Phase 1: Deploy VPN with Forced Routing (Week 1)
Configure your VPN to establish before any other network traffic. On Windows, use the VPN profile XML to set <AlwaysOn>true</AlwaysOn> and <LockDown>true</LockDown>. On macOS, deploy a configuration profile with VPNOnDemandEnabled and appropriate rules.
Don't use split-tunnel for roles handling personal data unless you've documented the risk assessment. Full-tunnel adds latency but eliminates the risk of data leaking through the local connection during a man-in-the-middle attack.
Test your deployment on public Wi-Fi yourself. Connect to a coffee shop network, attempt to access your customer database without the VPN active, and verify that the connection fails. If you can reach internal resources without the VPN, your implementation has gaps.
Phase 2: Endpoint Protection with Remote Attestation (Week 2)
Deploy EDR agents that report health status before allowing network access. Configure your VPN or network access control to check:
- Agent running and updated within last 24 hours
- Operating system patches current within your defined window
- Disk encryption enabled and verified
- No known malware signatures present
Use your MDM to enforce these requirements automatically. On mobile devices, configure conditional access policies that block Exchange or SaaS access if the device fails health checks.
Set up alerting for devices that repeatedly fail attestation. This often indicates an employee trying to bypass controls or using an unmanaged personal device.
Phase 3: Implement Hardware-Backed MFA (Week 3)
Replace SMS and authenticator apps with FIDO2 security keys for any role with access to personal data. Distribute two keys per person (one primary, one backup stored securely).
Configure your identity provider to require the security key for:
- VPN authentication
- Access to systems containing personal data
- Administrative actions (password resets, permission changes)
Test the user experience during onboarding. Your security keys should work seamlessly with the VPN client. If users must authenticate twice (once for VPN, once for the key), you'll see compliance drop.
Phase 4: Network Isolation and Micro-Segmentation (Week 4)
Create separate network zones for remote workers based on data access needs. An employee who only processes contact information shouldn't have network routes to systems containing special category data.
Configure your VPN to assign different IP ranges based on role:
- Customer service: access to CRM and support ticketing only
- Marketing: access to analytics and email platforms
- Engineering: access to production systems with additional logging
Use firewall rules at the VPN gateway to enforce these boundaries. Log all connection attempts, especially denials, to detect lateral movement attempts.
Phase 5: Certificate-Based Device Trust (Week 4)
Issue client certificates to managed devices and configure your VPN to reject connections without valid certificates. This prevents an attacker who steals credentials from connecting using their own device.
Your certificate policy should include:
- 90-day validity period with automatic renewal
- Revocation checking before each VPN session
- Certificate pinning in the VPN client to prevent substitution attacks
Store certificates in the device's trusted platform module (TPM) or secure enclave where possible. This makes extraction significantly harder if the device is compromised.
Validation - How to Verify It Works
Functional Testing: Attempt to connect to your customer database from an unmanaged device. The connection should fail at the VPN layer before any application traffic is transmitted.
Connect through a public Wi-Fi network and run Wireshark on a separate device to capture traffic. You should see encrypted VPN traffic only, no plaintext DNS queries, no HTTP requests, no application protocols visible.
Test MFA bypass attempts. Try connecting with just username and password. Try using an old security key that's been deregistered. Both should fail immediately.
Compliance Verification: Pull VPN connection logs for the last 30 days. Every session accessing personal data should show:
- Successful device attestation before connection
- Valid client certificate presented
- MFA challenge completed with hardware token
- Connection duration and data transferred
Review your EDR console for any endpoints that haven't checked in within 48 hours. These represent gaps in your visibility and should trigger investigation.
Run a simulated personal data breach exercise. Assume an endpoint is compromised and walk through your Article 33 notification timeline. Can you identify what personal data was accessible from that device? Can you determine if exfiltration occurred? If you can't answer these questions within 72 hours, your logging isn't sufficient.
Ongoing Maintenance
Daily: Monitor EDR alerts for suspicious activity on remote endpoints. Prioritize alerts involving processes that access files containing personal data or unusual network connections during VPN sessions.
Weekly: Review VPN connection logs for anomalies, connections from unexpected geolocations, unusual connection times for specific roles, or repeated authentication failures followed by success.
Audit MDM compliance reports. Any device falling out of compliance should lose access until remediated.
Monthly: Test your VPN failover and redundancy. Your remote workforce can't wait hours for VPN restoration if the primary gateway fails.
Update your remote work security policy based on new threat intelligence. The Manchester Airports attackers used techniques that will evolve. Your controls must evolve with them.
Rotate your VPN server certificates and verify that client certificate renewal is working automatically.
Quarterly: Conduct tabletop exercises simulating endpoint compromise. Include scenarios where an employee's device is stolen, where malware is detected on a remote laptop, and where credentials are phished despite MFA.
Review your network segmentation rules. As roles change and new systems are deployed, verify that remote workers still have appropriate access, no more, no less.
Re-evaluate your VPN capacity. Remote work patterns shift, and you need headroom for peak usage without performance degradation that tempts users to bypass controls.
Your Article 32 obligation requires ongoing assessment of security measures. This isn't a one-time project. Every new remote work pattern, every new SaaS tool, every new data processing activity requires you to revisit these controls and verify they still provide adequate protection.
