You've patched your production systems and hardened your cloud infrastructure. But what about the Oracle database running on Windows Server 2003 in the corner of your data center, the one processing records from 1978?
The Legal Aid Agency breach exposed approximately 250,000 records predating 2007, including National Insurance numbers, bank account details, and legal case information. This wasn't a failure of modern security controls, but a failure to address the attack surface that legacy systems create.
If you're running systems that predate your current security architecture, this checklist will help you assess your exposure before forensic analysts have to do it for you.
Prerequisites
Before starting this checklist, ensure you have:
- A complete asset inventory, including decommissioned-but-still-running systems
- Access to system administrators who understand your oldest production environments
- Authority to request forensic analysis if you discover gaps
- Documentation of data retention policies and legal hold requirements
Legacy System Security Checklist
1. Identify all systems processing personal data from before your current security baseline
Search your asset inventory for systems deployed before your organization adopted ISO/IEC 27001, NIST Cybersecurity Framework (CSF) 2.0, or your current security architecture. Include systems marked "to be retired" that are still processing data.
Good looks like: A spreadsheet listing every system by deployment date, operating system version, data types processed, and whether it meets current authentication standards.
2. Verify you can produce a complete data inventory for each legacy system within 72 hours
Test whether you can identify what personal data each system holds, how long it's been there, and what legal basis justifies its retention. The 72-Hour Notification Requirement under the General Data Protection Regulation (GDPR) doesn't pause while you figure out what was stolen.
Good looks like: Running a test exercise where you ask each system owner to produce a data map, and receiving accurate responses within one business day.
3. Confirm authentication controls meet current standards or document the exception
Legacy systems often lack multi-factor authentication, enforce weak password policies, or use shared accounts. Check whether each system implements controls equivalent to NIST SP 800-53 IA-2 (Identification and Authentication) and IA-5 (Authenticator Management).
Good looks like: Either implementing modern authentication (federated identity, MFA) or documenting why the system cannot be upgraded and what compensating controls you've deployed (network segmentation, Just-in-Time Access).
4. Validate that privileged access to legacy systems is logged and monitored
Attackers who compromise legacy systems often do so through privileged accounts. Verify that Privileged Access Management controls cover these systems and that your Security Information and Event Management platform ingests their logs.
Good looks like: Running a test query showing administrator login attempts, failed authentications, and data export operations for your oldest system, with alerts configured for anomalous activity.
5. Test whether your Computer Security Incident Response Team can perform forensic analysis on legacy systems
The Legal Aid Agency's forensic analysis revealed the breach was "significant and complex" with data that was "unstructured, fragmented, or incomplete." Can your team analyze systems running unsupported operating systems or proprietary databases?
Good looks like: Your incident response plan includes procedures for imaging legacy systems, and your team has tested forensic tools against your actual legacy environment within the past year.
6. Document what data predates your current retention policy
Many organizations adopted formal data retention policies in response to the GDPR or sector-specific requirements. Identify data that predates these policies and determine whether you still have a lawful basis to process it.
Good looks like: A register showing data categories by age, the original processing purpose, current legal basis, and scheduled deletion date or documented exception.
7. Verify network segmentation isolates legacy systems from modern infrastructure
Legacy systems should not share network segments with your cloud services, SaaS applications, or user workstations. Check whether your architecture implements defense-in-depth principles.
Good looks like: Network diagrams showing legacy systems in isolated VLANs with firewall rules restricting traffic to only necessary services, validated through penetration testing within the past 12 months.
8. Confirm backup and recovery procedures account for legacy system architecture
Can you restore a 15-year-old database to a clean environment for forensic analysis? Do your backup systems support the media formats and encryption standards these systems use?
Good looks like: Documented recovery procedures for each legacy system, tested annually, with recovery time objectives that account for obsolete hardware dependencies.
9. Assess whether legacy systems comply with current data protection requirements
The GDPR requires Data Minimisation, purpose limitation, and storage limitation. Systems designed before these requirements often violate them by default.
Good looks like: A gap analysis showing which GDPR principles each legacy system violates, with either remediation plans or documented legal grounds for continued processing.
10. Validate that Data Subject Access Requests can retrieve data from legacy systems
When someone exercises their rights under Article 15 of the GDPR, can you search your 1990s-era systems? The one-month response deadline doesn't account for technical debt.
Good looks like: A tested procedure for searching legacy systems by individual identifiers, with documented response times and escalation paths when technical limitations prevent timely responses.
11. Review vendor support status and patch availability
Systems running unsupported software create unmanaged risk. Document which systems no longer receive security updates and what compensating controls you've implemented.
Good looks like: A register of end-of-life dates for operating systems, databases, and applications, with risk acceptance documentation signed by appropriate executives for systems that cannot be upgraded.
12. Test whether your threat detection covers legacy system attack patterns
Modern Security Operations Centers often focus on cloud and endpoint threats. Verify that your detection rules cover lateral movement to legacy systems and data exfiltration methods that target older protocols.
Good looks like: Detection rules that trigger on SMBv1 traffic, legacy database export operations, and authentication to systems that should have no interactive users, tested through purple team exercises.
13. Confirm incident response playbooks address legacy system compromises
Your runbook for containing a cloud compromise won't work when attackers access a mainframe. Verify that your Computer Security Incident Response Team has procedures for legacy environments.
Good looks like: Incident response procedures that specify how to isolate legacy systems without disrupting critical business processes, including contact information for system administrators and vendors who understand obsolete platforms.
14. Document dependencies that prevent legacy system retirement
Many legacy systems persist because they support business processes that depend on their specific data formats or logic. Map these dependencies so you can prioritize migration efforts.
Good looks like: A dependency matrix showing which business processes, reporting requirements, or regulatory obligations require each legacy system, with executive sponsors identified for migration projects.
15. Establish a timeline for legacy system retirement or security enhancement
Every legacy system should have either a decommissioning date or documented security improvements. Neither "we'll get to it eventually" nor "it's too expensive to replace" constitutes a risk management strategy.
Good looks like: A board-approved roadmap showing retirement dates or specific security enhancements (re-platforming, data migration, enhanced monitoring) with allocated budget and assigned ownership.
Common Mistakes
Assuming "air-gapped" legacy systems are secure. If the system processes data, someone has network access to it. The Legal Aid Agency breach exploited vulnerabilities in IT systems that were presumably isolated from the internet.
Treating legacy systems as "too old to be interesting." Attackers target legacy systems precisely because they lack modern security controls. Data from 1978 still contains National Insurance numbers and bank account details.
Waiting for a breach to discover what legacy systems contain. Forensic analysis should happen before the incident, not after. The Legal Aid Agency's initial disclosure understated the breach scope because they didn't know what their legacy systems held.
Relying on "security through obscurity." The fact that only two people understand how your AS/400 processes data doesn't make it secure. It makes incident response impossible.
Next Steps
Schedule a legacy system security review within the next 30 days. Bring together your infrastructure team, data protection officer, and Computer Security Incident Response Team. Walk through this checklist for your three oldest production systems.
If you identify gaps, you have two paths: accelerate retirement or implement compensating controls. Neither is cheap, but both are cheaper than explaining to regulators why you couldn't produce a complete data inventory during breach notification.
The Legal Aid Agency strengthened authentication and access controls, improved security monitoring, and began retiring higher-risk legacy systems after their breach. You can implement these measures before forensic analysts tell you what data you lost.
