Migration Security Reviews That Catch Exposure Before Attackers Do

In February 2025, a system was moved from behind a VPN to a publicly accessible network without a security review. This oversight left sensitive data, including identity documents, exposed for over a year. The breach was only discovered in June 2026. This wasn't due to a sophisticated attack but a simple network change that went unchecked. Here's a guide to ensure your team doesn't make the same mistake.

Preparation Before Migration

Before starting any migration, ensure you have:

• A current asset inventory detailing each system's network zone, data classification, and owner. If you're unsure about a system's contents, conduct a Data Discovery first.
• A Data Labeling scheme to identify Restricted Data, such as identity documents, so reviewers understand the stakes.
• Authority to block changes. Security reviewers must have the documented power to halt a change if necessary.
• Tooling access: Ensure access to your cloud or firewall configuration, an external scanner, your IdP admin console, and your SIEM.
• A named approver from data governance. For high-volume personal data, your Chief Privacy Officer (CPO) or delegate should sign off.

Implementing Security Reviews

1. Flag Network Changes

Classify any changes to a system's network zone, ingress rules, load balancer, DNS, or reverse proxy as security-relevant events. In your change management tool, add a field: "Does this change alter reachability from a less-trusted zone?" A "yes" or "unsure" answer triggers a full review.

2. Document Data Flow

Before migration, document the data stored, its classification, current access zones, and future access zones. For personal data at scale, this documentation supports your privacy impact assessment. Under GDPR Article 35, high-risk processing requires an assessment before starting. If residual risk remains high, Prior Consultation under Article 36 may be necessary.

3. Review All Functions

Don't just consider what the system is intended for; review all its functions. The DigiCert breach exposed an account registration feature that wasn't intended for external use. Enumerate every endpoint and feature:

• Review the application's route list or API specification.
• Check for self-service registration, password reset, invite flows, and default admin consoles.
• Disable unnecessary functions before the move.

4. Enforce Network Segmentation

Move systems to more exposed zones only if there's a documented business need. Keep internal archives behind a VPN or private endpoint. If external access is required, use a reverse proxy or web application firewall (WAF) in the public zone and keep the data store in a restricted segment. Apply deny-by-default firewall rules to limit exposure.

5. Apply Multifactor Authentication

Ensure multifactor authentication (MFA) is applied to every account path. Accounts created through externally accessible endpoints should not bypass MFA:

• Enforce MFA at the identity provider or gateway.
• Apply it to all accounts, including self-registered and service accounts.
• Disable self-registration on systems holding Restricted Data.
• Use explicit Access Provisioning tied to a named role to control data access.

6. Monitor Before Cutover

Set up SIEM alerts for blocked access attempts, new account creations, and bulk reads from the archive. Ensure logs are reaching the SIEM before going live to avoid unnoticed intrusions.

7. Conduct a Go/No-Go Gate

Before cutover, complete a signed checklist: data flow record, disabled unused functions, verified segmentation, enforced MFA, live alerts, and recorded data governance approval. Without these, don't proceed.

Validation: Test Your Security Measures

Don't rely on configuration differences alone. Test from an external perspective:

1. External scan: Confirm only intended ports respond from outside your network and from the VPN side.
2. Registration test: Attempt account creation through all external paths and expect a block and alert in your SIEM.
3. MFA test: Ensure MFA is required at first login for test accounts.
4. Zero-assignment test: Verify that accounts with no application assignment can't access data.
5. Alert test: Trigger each SIEM rule and confirm someone is notified.
6. Record results in the change ticket to support your accountability under GDPR Article 32.

Ongoing Maintenance

• Schedule external scans after every network change to catch drifts.
• Quarterly asset inventory reviews to ensure systems are in the correct network zones.
• Audit self-registration and MFA coverage at the IdP to catch enforcement gaps.
• Test your detection-to-containment path to ensure effective response.
• Maintain your Breach Register and 72-Hour Notification process as per GDPR Article 33.
• Apply Retention Rules to minimize the risk of data exposure.

Identity documents pose a risk even after exposure. Minimize their storage and inform affected individuals of protective steps they can take.