This article is educational information, not legal or compliance advice. HIPAA compliance depends on your specific systems, data, workflows, and risk assessment, and requirements can change. If your organization handles protected health information (PHI), consult a qualified healthcare compliance professional or attorney before making decisions based on this article.
This is one of five deep-dives into keeping Access running well (and knowing when it's time to move on) — part of our Microsoft Access Modernization: The Complete Guide. See the others: Access performance tuning, Access VBA, Access forms, reports & queries, Access security, auditing & backups, and Microsoft Access and HIPAA.
Can Microsoft Access be used for HIPAA-covered data at all?
There's no blanket rule against it — HIPAA doesn't name specific software as compliant or non-compliant. What matters is whether the safeguards HIPAA's Security Rule requires are actually in place around however you store and access PHI, technically and administratively. The honest answer is that Access can technically hold PHI, but building and maintaining the required safeguards around it is significantly harder with Access than with tools built for this from the ground up — and the gap tends to widen, not narrow, as your usage grows.
Where does Access fall short of HIPAA's technical safeguard requirements?
A few specific, recurring gaps. Access has no built-in audit controls — HIPAA's Security Rule expects the ability to record and examine activity in systems containing PHI (who accessed or changed what, and when), and Access provides nothing like this natively; it would need custom-built VBA logging, which is possible but rarely implemented thoroughly and easy to get wrong. Access lacks granular access controls — HIPAA expects role-based, need-to-know access limits, and Access's permission model is coarse compared to what's typically expected for PHI systems. And Access has no built-in encryption at rest that meets typical compliance expectations for PHI storage without significant additional configuration, unlike systems designed for regulated data from the start.
What about a Business Associate Agreement (BAA) — does Microsoft offer one for Access?
This is a genuinely important distinction to understand, and it's easy to get confused here. Microsoft does offer BAAs covering various Microsoft 365 and Azure services for organizations handling PHI — but coverage varies by specific service, and this is exactly the kind of detail that changes and that you should confirm directly with Microsoft's current documentation or your Microsoft account team, not take from any single article, including this one. Whether your specific Access deployment and its data flows are covered by an applicable BAA is a question for your compliance advisor and Microsoft directly — don't assume either way.
What does a more compliance-appropriate target typically look like?
Systems built with the required safeguards as native features rather than custom bolt-ons: a proper server database or managed cloud database with built-in encryption at rest and in transit, granular role-based access control, and comprehensive audit logging as a platform capability. A custom web application built on top of one of these can also implement the administrative and technical safeguards (access reviews, session timeouts, detailed logging) more thoroughly and reliably than retrofitting them onto Access. This isn't a claim that any specific product is "HIPAA compliant" on its own — compliance is a property of your whole environment and practices, not a single piece of software — but the underlying platform matters a great deal to how achievable and maintainable that compliance actually is.
What should we actually do if we're running Access with PHI today?
Get a proper risk assessment from a qualified healthcare compliance professional — that's the right first step, not a migration decision made from a blog post. If that assessment identifies gaps consistent with what's described above (which is common), you'll have a concrete, prioritized list to act on, whether that's near-term compensating controls or a longer-term migration to a platform where the required safeguards are easier to implement and maintain properly.
Is this article legal or compliance advice?
No — to say it plainly a second time, because it matters: this is educational background, not a substitute for a qualified compliance assessment of your specific situation. HIPAA compliance decisions should be made with a qualified professional who can evaluate your actual systems, data flows, and risk profile, not from any general article.
What if we're not sure whether our data actually counts as PHI?
That uncertainty itself is common and worth resolving early, rather than assuming either way. Protected health information generally covers data that identifies an individual and relates to their health condition, care, or payment for care — but the exact boundary in a specific database (a patient name next to an appointment date, for instance, versus the same name in an unrelated context) is a determination a compliance professional makes for your actual schema and workflows, not something a general article can safely answer for you. If there's any real chance the data your Access database holds falls into that category, the safe default is to treat it as PHI until a qualified assessment says otherwise, rather than assuming it's fine and finding out later that it wasn't.
Does switching away from Access automatically make us HIPAA compliant?
No, and it's worth being direct about that. Compliance is a property of your whole environment — policies, training, access controls, incident response, business associate agreements, and more — not a single piece of software. Moving to a platform with better native safeguards (encryption, audit logging, role-based access) removes some of the harder technical obstacles Access presents and makes the rest of the work more achievable, but it doesn't substitute for the administrative and procedural side of compliance, which has to be built and maintained regardless of what database sits underneath it.
Not sure whether tuning is enough or it's time to migrate? Our instant estimator gives you a ballpark either way, or request an assessment and we'll give you an honest read.
Comments
Be the first to comment on this post.
