In the conversation about NHS digital transformation, a great deal of attention falls on EPR procurement, cloud migration, and AI. Considerably less attention falls on a category of risk that is older, quieter, and more deeply embedded in daily NHS operations than any of those programmes.

Across many NHS Trusts, hundreds of Microsoft Access databases are in active use every day. They are being used by clinical, administrative, operational, and corporate teams to run processes that those teams depend on. Some of these databases have been running for over a decade. Most have no formal owner. Many contain patient-identifiable information. Almost none are documented in any asset register.

This is not a niche concern. It is a widespread feature of the NHS data landscape, and one that carries compounding risks across information governance, cybersecurity, data quality, and operational continuity. As NHS Trusts invest in modernising their data estates, the Access database estate cannot simply be treated as background noise. It needs to be surfaced, assessed, and systematically addressed.

Why Access Databases Are Everywhere

Microsoft Access established itself across the NHS for straightforward reasons. It was accessible to non-technical staff, it required no central IT involvement to set up, and it solved real operational problems quickly. A ward manager who needed to track equipment. A clinic coordinator who needed to manage appointment data not held in the PAS. A finance team member who needed to reconcile figures that two systems reported differently. Access provided a route to a working solution without the wait times and procurement complexity of going through IT.

The result, accumulated over decades, is an estate of locally created databases that are deeply embedded in daily workflows, often with no equivalent capability available elsewhere in the Trust's formal systems. They exist precisely because the formal systems did not fully meet the need. That is what makes them difficult to address: removing or replacing them requires understanding what they actually do, which in many cases only one or two people still know.

The problem is not that these databases were created. The problem is that they were never governed, never documented, and never accounted for in the Trust's understanding of its own data estate.

The Risks, Categorised

Information Governance and UK GDPR

Many Access databases in NHS settings contain patient-identifiable information. Appointment details, referral tracking, waiting list notes, patient contact records, clinical observations added locally to supplement formal system data. Under UK GDPR, personal data must be processed securely using appropriate technical and organisational measures. The ICO is explicit that this includes actively managing software vulnerabilities and using supported software.

An Access database sitting on a staff member's local drive or on a network share, with no access controls beyond a shared folder password, does not meet that standard. It cannot produce an audit trail of who accessed the data. It offers no encryption at rest. It has no formal data retention policy applied to it. If that database holds patient data, the Trust is processing that data in a way that falls materially short of its UK GDPR obligations, regardless of what the Trust's formal policies say.

The NHS Data Security Standard 8, which covers unsupported systems, is direct on this point. Senior Information Risk Owners are required to be informed when systems cannot be upgraded or secured, and to personally confirm that risks are being treated or formally tolerated. A Trust with hundreds of undocumented Access databases cannot demonstrate that process has been applied, because it does not know they all exist.

Cybersecurity and Unsupported Software

Microsoft Access 2016 and 2019 both reached end of support in October 2025. Access 2021 reaches end of support in October 2026. When a version moves out of support, Microsoft stops issuing security patches. Vulnerabilities discovered after that point remain permanently unpatched in those versions.

The NHS England National Cyber Security Operations Centre issues regular alerts about Microsoft Office vulnerabilities. Multiple high-severity remote code execution vulnerabilities affecting Microsoft Office products have been identified and flagged as actively exploited in 2025 alone. Access databases shared across network drives or accessed via legacy Office installations represent a potential attack surface that cannot be systematically monitored when the asset itself is undocumented.

NHS England's broader guidance on unsupported systems is clear: obsolete systems should be treated as unmanaged or untrusted, with network access restricted and a documented risk acceptance in place where immediate remediation is not possible. The practical reality in most Trusts is that this guidance has not been systematically applied to the Access database estate, because the estate has not been systematically inventoried.

Operational Continuity

Access databases are typically created and maintained by one individual or a small team. When that person leaves, transfers roles, or is absent, the operational process that depends on the database becomes fragile. There is no documentation. There is no handover. The person who inherits the task may not have the skills to maintain or modify the database, and may not even be aware of how it works.

In practice, this means that critical operational processes in NHS Trusts are running on single points of failure with no resilience. The database that tracks which patients have been contacted about an upcoming clinic. The one that manages the allocation of equipment across wards. The one that reconciles referral data between two systems that do not talk to each other. If any of these fail, or if the file becomes corrupted, the operational consequences can be immediate and significant.

Access is not designed for resilience. It has a maximum database size of 2GB, a practical performance ceiling considerably lower than that, no built-in backup mechanism, no transaction logging, and no capability for concurrent multi-user access without risk of data corruption. It was designed as a desktop productivity tool, not as the operational backbone of clinical or administrative processes.

Data Quality and Analytics Invisibility

Data held in Access databases is almost entirely invisible to analytics platforms. It does not feed into data warehouses, Power BI dashboards, or FDP pipelines. It is not subject to data quality monitoring. It exists in a parallel, undocumented layer of the Trust's data estate that official analytics outputs simply cannot see.

This creates a systematic gap between what the Trust's formal reporting says and what is actually happening operationally. If a clinical team is tracking patient progress in an Access database because the formal EPR does not capture what they need, those patients and that activity are invisible to any analytics built on the EPR data. Decisions made on the basis of formal data are being made with an incomplete picture.

The Lifecycle Problem

Unlike formally procured systems, Access databases have no lifecycle. There is no procurement process, no contract, no vendor relationship, no scheduled review, and no decommissioning plan. They accumulate indefinitely. The database that was created to solve a specific short-term problem in 2014 is likely still running in 2026, still holding data, still being used daily, and still entirely absent from any formal asset register.

The people who created them frequently left years ago. The processes they support have evolved, but the database has not. The data within them includes records from the original purpose and everything that accumulated afterwards. Retention periods have never been applied. Data that should have been deleted under the NHS Records Management Code of Practice 2021 is sitting in a file on a network share.

This is not a hypothetical scenario. It is the consistent finding when organisations conduct structured discovery of their Access database estate for the first time. The volume is larger than expected, the age of databases is greater than expected, the sensitivity of data held is higher than expected, and the number of people who understand what each database does is consistently lower than expected.

Structured discovery consistently finds an Access estate that is larger, older, more sensitive, and less understood than the Trust believed it to be.

Why This Is Hard to Address

NHS digital leaders are aware that Access databases represent a risk. The reason the problem persists is not ignorance. It is the practical difficulty of addressing it without first knowing the full scope.

You cannot remediate what you have not inventoried. And inventorying an Access estate spread across network drives, shared folders, local machines, and departmental servers in a multi-site Trust of any significant size is not a trivial exercise. It requires automated scanning tools capable of identifying Access files across the estate, followed by structured assessment of each database's content, usage, ownership, and operational criticality.

Once the inventory exists, remediation decisions can be made systematically. For each database there are four broad options: migrate the data and functionality to a supported platform such as Azure SQL or a Power Apps application; rebuild the capability within an existing system that should already be handling the relevant data; archive the data appropriately and decommission the database; or, for a small number of genuinely critical databases where migration is complex, document the risk formally and implement interim security controls while a migration is planned.

None of these options are quick. But they are all far less disruptive than the alternative, which is discovering the failure mode reactively when a database corrupts, when a breach occurs, or when a regulator asks for evidence of how patient data held in undocumented systems is being managed.

The Transition to Modern Alternatives

For NHS Trusts working within the Microsoft ecosystem, the natural successor technologies are well established. Azure SQL provides enterprise-grade database capability with proper access controls, encryption, backup, and audit logging. Power Apps and Dataverse allow the same kind of user-built application logic that Access provided, but with proper governance, multi-user access, mobile support, and integration into the broader Microsoft 365 environment.

For databases that primarily exist to bridge gaps between formal clinical systems, the EPR procurement process provides an opportunity to close those gaps at source. If the EPR implementation is designed with sufficient understanding of what the Access estate is actually doing, the number of legacy databases that need to be migrated rather than simply decommissioned can be significantly reduced.

This is one reason why Access database discovery should be a workstream within any current-state data architecture engagement, not an afterthought. The findings directly inform EPR scope, data migration planning, and the sequencing of transition roadmap activities.

What NHS Digital Leaders Should Do

1. Commission a structured discovery of your Access database estate. Automated scanning of network drives and shared folders will surface what asset registers cannot. The output should be a prioritised register of all databases by risk level, usage, ownership, and content sensitivity.

2. Apply the NHS Data Security Standard 8 framework to the findings. For databases that cannot be immediately remediated, document the risk formally with SIRO sign-off. Treat high-risk databases holding patient data as the priority for accelerated remediation.

3. Integrate Access database findings into EPR and data architecture planning. Understanding what Access databases are doing today helps define EPR scope, data migration requirements, and post-go-live capability gaps before rather than after implementation.

4. Establish a governance position that prevents new undocumented databases from being created. Clear policy, enforced through network controls and staff awareness, is the structural prevention mechanism. The remediation programme addresses the historical estate; governance prevents it accumulating again.

5. Do not wait for a breach or an audit finding to act. The regulatory exposure under UK GDPR and the DSPT is present now. Demonstrating that a Trust has a programme in place to address known legacy risks is a significantly stronger position than discovering the risks reactively.

Where VE3 Can Help

VE3 supports NHS Trusts through enterprise data architecture engagements that include structured discovery of legacy data environments, covering SQL estates, Access databases, in-house applications, and undocumented data flows. Our discovery work produces a prioritised remediation register that feeds directly into transition roadmap planning.

If your Trust is undertaking or planning a data architecture review, an EPR implementation, or a cloud migration programme and wants to understand the full scope of the estate it is working with, we would welcome the conversation.