Scope note: This article supports business planning but does not replace a current security, regulatory or legal assessment for the specific system.
Start with the current system, not the assumed design
Compliance risk, in the context of legacy systems, refers to the chance that an older application cannot meet current legal, regulatory or contractual obligations governing how data is handled, stored, accessed and deleted. The risk does not come from the system being old in itself. It arises because regulations change, expectations around data protection shift, and the technical capabilities that were adequate at the time of build may no longer satisfy what the law or your contracts now require.
In the UK, the most prominent framework is UK GDPR and the Data Protection Act 2018. These place obligations on data controllers around lawful processing, data minimisation, retention limits, subject access requests, security measures and the right to erasure. Other sectors carry additional rules: financial services firms answer to the FCA and its operational resilience requirements; healthcare organisations handle sensitive patient data under specific NHS and Caldecott principles; organisations holding payment card data must comply with PCI DSS standards.
Legacy systems create compliance exposure in several distinct ways. Older applications were often built without audit logging, meaning there is no reliable record of who accessed what data and when. Access controls may be coarse-grained, granting broad permissions rather than the principle of least privilege that regulators expect. Data may be stored in formats or structures that make it difficult to locate specific records for a subject access request or to confirm that data has been permanently deleted. Encryption standards that were acceptable a decade ago may now be considered inadequate. Integration points with other systems may transfer data in ways that are no longer documented or controlled.
The core problem is a mismatch: the system's technical design reflects the requirements and norms of the period in which it was built, but the organisation's compliance obligations have moved on. Unlike a straightforward feature gap, this mismatch is often invisible until a regulator asks a question, a customer submits a data request, or a contract requires evidence of controls that the system simply cannot provide.
| Assessment area | What to establish | Evidence to retain |
|---|---|---|
| Subject access requests and data location | Under UK GDPR, individuals can request a copy of all personal data an organisation holds about them. | Validated samples, reconciliation results, a named data owner and logged exceptions. |
| Audit trails and accountability | Regulators increasingly expect organisations to demonstrate not just that data is secure, but that they can account for who has accessed or modified it. | A named owner, current-state evidence, unresolved questions and a dated decision record. |
| Data retention and the right to erasure | Many legacy systems were designed to accumulate data indefinitely. | Validated samples, reconciliation results, a named data owner and logged exceptions. |
| Access control and role changes | Staff turnover, departmental restructures and changing responsibilities mean that access permissions need regular review. | Access records, test evidence, unresolved risks and the person accountable for remediation. |
Subject access requests and data location
Under UK GDPR, individuals can request a copy of all personal data an organisation holds about them. In a well-structured modern system, this is a query that can be executed against a clearly defined data model. In a legacy system, personal data may be scattered across multiple database tables, embedded in free-text fields, stored in flat files on a server, or duplicated across backup sets that are not easily searchable. The practical risk is not just failing to respond within the one-month deadline, but failing to locate all relevant data and therefore providing an incomplete response, which itself constitutes a breach.
Audit trails and accountability
Regulators increasingly expect organisations to demonstrate not just that data is secure, but that they can account for who has accessed or modified it. A legacy CRM or internal portal that records only the most recent state of a record, without a history of changes and the identity of the user who made them, cannot satisfy this expectation. When an organisation cannot produce an audit trail, it faces difficulty investigating internal incidents, responding to regulatory inquiries, or demonstrating the controls that its own policies claim to have in place.
Data retention and the right to erasure
Many legacy systems were designed to accumulate data indefinitely. There may be no mechanism to apply retention schedules, no way to flag records for deletion, and no process to ensure that backups are also purged in line with the live system. When an individual exercises their right to erasure, the organisation must be able to confirm that the data has been removed from all systems, including backups, within a reasonable timeframe. A legacy system without these capabilities forces the organisation into manual workarounds that are difficult to verify and hard to repeat at scale.
Access control and role changes
Staff turnover, departmental restructures and changing responsibilities mean that access permissions need regular review. Legacy systems often lack the role-based access control structures that make this manageable. Permissions may have been granted individually over years, with no central view of who can access what. When an employee leaves, there may be shared accounts that cannot be easily disabled, or API keys embedded in the system that continue to function. From a compliance perspective, the inability to demonstrate that access is restricted to those who need it is a material gap.
Third-party and supply-chain obligations
Commercial contracts increasingly include clauses requiring counterparties to maintain specific security standards, provide audit access, or notify of breaches within defined timeframes. If a legacy system processes data on behalf of a client or partner, and it cannot meet those contractual commitments, the organisation faces breach-of-contract risk alongside regulatory risk. This is particularly acute where a legacy system sits at the centre of a data-sharing arrangement and the contract predates current expectations.
Assuming past compliance guarantees present compliance
One of the most frequent errors is treating compliance as a one-time achievement. A system that met requirements when it was deployed may have drifted out of compliance as regulations changed, as the data it held evolved, or as the surrounding technical environment shifted. Compliance is not a property of the system at launch; it is an ongoing obligation that must be reassessed as conditions change.
Relying on undocumented staff knowledge
In many organisations, the only people who understand how a legacy system handles data are long-serving employees. Their knowledge is not written down, and the controls they apply informally are not codified in system design or policy. If those individuals leave, the organisation loses not just technical capability but the informal compliance safeguards that were never formalised. This represents both an operational and a regulatory vulnerability.
Treating compliance as purely a policy problem
Policies that describe how data should be handled are necessary but insufficient if the underlying system cannot enforce them. An organisation may have a robust data retention policy, but if the legacy system has no mechanism to implement it, the policy exists only on paper. Regulators assess controls in practice, not just in documentation. The gap between what the policy says and what the system can actually do is where compliance risk lives.
Key checks to carry out
- Data mapping: Can you produce a current, accurate record of what personal data the system holds, where it is stored, and how it flows to and from other systems?
- Audit capability: Does the system log who accessed or modified data, when, and from where? Can those logs be retrieved and reviewed without specialist intervention?
- Access control: Is access managed through defined roles, or has it accumulated on an ad-hoc basis? Can you produce a current list of who has access to what?
- Retention and deletion: Can the system apply retention rules, flag records for deletion, and confirm that deletions have been carried out across all storage including backups?
- Encryption and security: Are data at rest and data in transit protected using standards that a current security review would consider appropriate for the data classification involved?
- Integration documentation: Are all data flows between the legacy system and other applications documented, and do those flows comply with current data-sharing agreements?
- Incident response: If the system were breached, could you determine what data was affected, who accessed it, and when?
Questions to put to a supplier or internal team
- What personal data fields exist in the system, including any hidden in logs, exports or backup files?
- How would we fulfil a subject access request within the statutory timeframe using only what the system can provide?
- What would we need to do to demonstrate, to a regulator, that access is appropriately restricted?
- Are there any shared accounts, hardcoded credentials or API keys that are not managed through a central access control system?
- What is the realistic effort to add audit logging or improve access controls, and would those changes require changes to the database schema?
When to seek specialist review
This article outlines the structural relationship between legacy systems and compliance risk, but it does not constitute legal advice. Regulatory requirements change, and their application depends on the specific data, sector and contractual context of each organisation. Where a legacy system handles sensitive personal data, financial records, or health information, or where a compliance gap has been identified, the appropriate next step is to engage a current specialist in data protection or information security who can assess the system against the regulations and standards that apply at the time of review. The value of this article is in helping you ask the right questions before that review begins, not in replacing it.